<p>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.</p>

CC BY-SA 4.0
2022-04-12T15:10:58.713Z
Also, this problem is not unique to Lightning, but rather an artifact of the checkout process.
Murch
CC BY-SA 4.0
2022-04-12T14:05:53.933Z
2022-04-12T14:05:53.933Z
Davidson Souza
<p>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 &quot;automatically&quot; 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)?</p>
<p>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!)</p>

<lightning-network><protocol><payment><hash-time-locked-contract><invoices>
Lightning protocol modification for app
Olympus
# Lightning protocol modification for app

(Asked by: username_0 on 2022-04-11)

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!)

**Tags:** lightning-network, protocol, payment, hash-time-locked-contract, invoices


---

## 1 answers

### Answer by username_1 on 2022-04-12. Score: 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.

> **Comments:**
> **username_2**: Also, this problem is not unique to Lightning, but rather an artifact of the checkout process.  

---

