I'm currently building a Lightning platform for online sellers. I have found that timing can be very problematic: For example, two people want to buy the last item in stock or a unique item like a particular watch. Both proceed to checkout and receive a Lightning invoice. If both pay, the seller would have the problem to reimburse one buyer. Would it be possible for the buyers to receive a refund "automatically" at the protocol level? Or better yet, would it be possible to condition the sale of an item on only one buyer winning (e.g. by using some tweaked hash(preimage), or something like that)?

Would it be possible in any way to implement (minor) Lightning protocol changes within a Lightning subnetwork if necessary? If my platform is an app with a Lightning node itself, then I could imagine that people using this app could live in this bubble with the modified protocol, or will it be a big hassle for me to implement something like this? (I want users to create payment channels and participate in the Lightning network - at least after the purchase of an item has been properly settled!)

1 Answer 1


I don't see why it needs to be at protocol level. Your node can simply not solve the second HTLC that arrives, you can keep track of items and possible conflicts when solving it. If you fail the HTLC, then no money is transferred and no refund is needed, this is relatively easy to do with any current implementation.

  • Also, this problem is not unique to Lightning, but rather an artifact of the checkout process.
    – Murch
    Apr 12, 2022 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.