They concluded that micro-payments are not possible for high-value products that need to be delivered quickly. Paying the same payment request twice is currently not possible as it could result in someone in the middle taking the funds. Schroder noted the difference between donations with lightning and blockchain donation addresses, as the latter can't be reused. The conversation then shifted to lower value products that are delivered slowly over long periods of time, such as water, natural gas, electricity, internet, parking meters, or digital content. Russell explained that there is no security hole where one party can reroute the payment instead of receiving the offer during the actual payment process. Schroder inquired about redundancy measures, which are possible but require multinode realtime failover, which has not been implemented yet. Privacy concerns with lightning were also discussed. While with blockchain payments, a refund can be returned without knowing the customer's identity, with lightning, the payer reveals their identity to the payee by offering a refund payment request. A more complex scheme using round-trip payments was suggested, but it requires the payer to know the amount of the refund. However, a smaller return onion could fix this issue. In an email exchange between Rusty Russell and Andy Schroder, the limitations of lightning payments were further explored. Currently, paying the same payment request twice is not possible, as it invites anyone in the middle to take the funds. There were discussions on potentially changing the way payment hashes work to allow for repeated payments in version 1.1. Additionally, the idea of allowing for amount adjustments while the payment is unresolved was discussed, which would enable incremental payments from the sender to the recipient.Rusty Russell and Christian Decker also discussed the possibility of paying the same payment request twice. It was noted that currently, this is not possible as it can be an opportunity for someone in the middle to take the funds. However, with version 1.1, they may change the payment hashes to make this possible. They also discussed the idea of allowing for amount adjustments while the payment has not been resolved, which could enable incremental payments from the sender to the recipient. However, careful implementation is necessary to avoid new DoS vectors.Andy Schroder and Rusty Russell had a conversation regarding the feasibility of high-frequency payments and micro-payments. It was noted that micro-payments are not possible for high-value products that need to be delivered quickly. Paying the same payment request twice is not possible currently as it could result in someone taking the funds. The payment route going down only happens during the actual payment process, not everything related to the payment request. Privacy concerns were raised with refund addresses revealing the payer's identity to the payee. The need for a flag in BOLT 11 to indicate a refund address was discussed. The purpose of different tagged fields in BOLT 11 was explained, including distinguishing payments from different payers and the use of the n field when key recovery is not possible.Andy Schroder is exploring the possibility of implementing micro-payments with his fuel pump using Lightning. He has concerns about the smallest volume that can be individually paid for and the protocol for repeated payments. Rusty Russell suggests changing the payment hashes in version 1.1 to allow for repeated payments. They also discuss the possibility of adjusting the payment amount before it is resolved, enabling incremental payments. However, careful implementation is needed to prevent potential DoS attacks. The lack of a refund address option in BOLT 11 compared to BIP 70 is questioned by Andy Schroder. He mentions adapting his fuel pump to use Lightning and requiring a refund address due to pre-payment requirements. Rusty Russell suggests adding a flag in BOLT 11 to indicate the need for a refund address and including the refund information in the payment onion itself. The inclusion of a refund address option in BIP 70 is seen as useful for many other use cases.