They concluded that for high value products that are delivered quickly, micro-payments are not possible. With the fuel delivery system, the smallest volume of product that could be individually paid for would be on the order of a hundred mL. Paying the same payment request twice is an invitation for anyone in the middle to just take your funds, hence it is not currently possible. Schroder notes the difference between donations with lightning and blockchain donation addresses because the latter can't be reused, which might be worth pointing out in the BIP for newcomers. The conversation then moves on to how lower value products that are delivered slowly over long periods of time such as water, natural gas, electricity, internet, parking meters or digital content can be managed. Russell explains that it's only during the actual payment process, which involves a series of steps where parties have to make an offer and exchange preimages of hash X. There is no security hole where one party can pretend not to receive the offer, but instead, reroute the payment some other way.Schroder asks about redundancy measures, which are more than possible, but require multinode realtime failover, which he believes hasn't been implemented yet. The conversation then moves on to the limitations of privacy with lightning. With blockchain payments, one can return a refund to the customer without always knowing who they are; however, with lightning, the payer will reveal their identity to the payee by offering a refund payment request. There's a more complex scheme that's possible, using round-trip payments, but unfortunately, for security reasons, each encrypted hop contains the amount it expects to be sent. This doesn't work if the payer doesn't know how much you're going to refund. However, they note that a smaller return onion can fix this issue, which has been added to the lightning-rfc brainstorming page.