Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
Good morning Lloyd, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, May 19, 2019 6:28 PM, Lloyd Fournier wrote: > Hi ZmnSCPxj, > > Sorry for the late reply I only recently had time to review your comments. > I didn't really get your motivation for multiple secrets. In my mind, having > the last hop put collateral into the HTLC to make a Collateralized HTLC > solves the problem without any extra complexity (your original example > captures this perfectly). The exchange node itself must impose the collateral: it cannot trust any other node to impose the collateral on its behalf. Remember, the intent is that the route is known only by the payer; the exchange should not know which node is the last node. Otherwise, the exchange node can censor payments. So: 1. The exchange node cannot know if its direct next hop is last or not (if it could know, then it could censor). So we must require that the swap protocol can be operated without the payer and payee being direct peers of the exchange. 2. The exchange node needs to ensure that the ultimate payee will provide collateral. It cannot depend on any other node enforcing that the ultimate payee will provide collateral (it should not trust the network). Thus the need for multiple secrets. The route is from payer -> exchange -> payee -> exchange. Multiple hop nodes may be inserted between the above participants. Two secrets are demanded from payer to exchange to payee. Only one secret is demanded from payee to exchange. As a concrete example, suppose 1 BTC is equivalent to 1 WJT. And we agree to a 10% collateral in the exchange. 1. Payer acquires a payment hash from payee and a exchange hash from exchange. 2. Payer routes from itself to exchange to payee. It releases 1 BTC, requiring both the exchange and payment preimages. 3. On reaching the exchange, it verifies the exchange rate and the collateral value, as well as that it knows the preimage of the exchange hash. It releases 11000 WJT to the next node (which might ***not*** be the payee: remember, we do not want the exchange to know who the final payee is, and this is still onion-routed), requiring both the exchange and payment preimage. 4. On reaching the payee, it checks the value is correct and that it knows the preimage of the payment hash. It releases 1000 WJT (the collateral) to the next node (which might ***not*** be the exchange: we do not want payees to become prejudiced against certain exchanges either, and this is still onion-routed). This time, it requires only the exchange preimage. 5. On reaching the exchange once again, it claims the collateral by revealing the exchange preimage. 6. The payee learns the exchange preimage and can claim the payment value, and reclaim the collateral, by releasing the payment preimage and exchange preimages immediately. Having multiple hops means an exchange cannot determine who is the ultimate payer and ultimate payee, and cannot impose any reasonable censorship policy. Thus the exchange cannot operate as if the second-to-last hop can be relied upon to impose the collateral rule on the payee: the exchange must impose this collateral itself! > You wrote: > > > The exchange can insist on getting a short timelock for receiving the > > collateral (i.e. limit the time horizon that the exchange hash is valid), > > to reduce the time horizon in which the payee can pay or not pay the > > collateral for the exchange (as before the payee releases the collateral, > > it still has the option of doing or not doing the swap, i.e. American > > Option). > > I think this unnecessary. The "free option" time isn't limited by a timelock > (if it was, we wouldn't have solved the problem). The option is limited by > the exchange's willingness to wait for the other party to sign the state > update (assuming the exchange signs first). The minor point I was trying to > make was that normally when routing payments etc you can be willing to wait > for minutes or hours for the other party to come back online if they went > offline during a state update. But if you are doing a swap and your partner > is meant to be signing a collateralized HTLC you shouldn't wait; you should > force settlement to the blockchain within a few seconds. As soon as the state > gets onto the blockchain the other party has lost any chance of getting an > option. What? All payments are still HTLCs. HTLCs are onchain contracts. The original formulation pointed out that HTLCs, by themselves (even directly onchain) can form an American Call Option. When we force settlement on the blockchain, we just publish the same HTLCs we use offchain on the blockchain. Thus any contract that takes effect offchain takes effect onchain. That includes any American Call Option formed out of HTLCs. Forcing it onchain just means you can no longer cancel the contract but are *forced* to wait out any timelock
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
Hi ZmnSCPxj, Sorry for the late reply I only recently had time to review your comments. I didn't really get your motivation for multiple secrets. In my mind, having the last hop put collateral into the HTLC to make a *Collateralized HTLC* solves the problem without any extra complexity (your original example captures this perfectly). You wrote: The exchange can insist on getting a short timelock for receiving the > collateral (i.e. limit the time horizon that the exchange hash is valid), > to reduce the time horizon in which the payee can pay or not pay the > collateral for the exchange (as before the payee releases the collateral, > it still has the option of doing or not doing the swap, i.e. American > Option). I think this unnecessary. The "free option" time isn't limited by a timelock (if it was, we wouldn't have solved the problem). The option is limited by the exchange's willingness to wait for the other party to sign the state update (assuming the exchange signs first). The minor point I was trying to make was that normally when routing payments etc you can be willing to wait for minutes or hours for the other party to come back online if they went offline during a state update. But if you are doing a swap and your partner is meant to be signing a collateralized HTLC you shouldn't wait; you should force settlement to the blockchain within a few seconds. As soon as the state gets onto the blockchain the other party has lost any chance of getting an option. At a glance, the simplest way to enable this functionality is to add a new field to the "update_add_htlc" BOLT message [1] like "collateral_amount_sat". The receiver of "collateral_amount_sat" would have to contribute that amount to the HTLC (if they are willing to go through with the update). Obviously you should only ever agree to do this if you are last hop or are willing to risk your collateral on the honest behaviour of nodes further down. I was actually wondering if this could be a useful feature outside of swaps. e.g. if there is a new node without much reputation who you are routing a payment to, you could demand that they put up collateral into the HLTC to receive the payment. This might help prevent attacks where people try and tie up funds by receiving large payments they never release the secrets for. WRT to your final comments, it sounds a bit like [2] which also mentions that their protocol can make atomic swaps fungible. 1. https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc 2. Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability: https://eprint.iacr.org/2018/472.pdf Cheers, Lloyd On Mon, May 6, 2019 at 2:51 PM ZmnSCPxj wrote: > Good morning Lloyd, > > I think the most generic solution is to require multiple hashlocks. > One hashlock for the payee, the other for the exchange. > > Payer acquires an exchange hash from the exchange, plus specs of the > collateral. > Then payer routes to the payee via the exchange using two hashlocks > (hashlock for the payment hash, hashlock for the exchange hash) and from > the payee to the exchange. > The exchange onion hop includes the information that the cross-currency > swap is allowed by pointing at the hashlock that the exchange hash is on. > The exchange verifies that it is one of the exchange hashes it has issued > and it releases the agreed amount to the next hop, plus the collateral > agreed upon. > > The payee onion hop includes the information that it should proceed to > give a single hashlock to succeeding hops, as well as the agreed-upon > collateral to the exchange. > The exchange receives the payment with a single hashlock containing the > value of the collateral. > It verifies that the collateral value is equal to the agreed collateral > for that payment, then releases the exchange preimage. > The payee can then release its preimage once it has acquired the exchange > preimage. > > The above is similar to your solution, as it effectively means the payee > offers collateral to the exchange, which it can only reclaim by properly > completing the payment protocol. > The exchange can insist on getting a short timelock for receiving the > collateral (i.e. limit the time horizon that the exchange hash is valid), > to reduce the time horizon in which the payee can pay or not pay the > collateral for the exchange (as before the payee releases the collateral, > it still has the option of doing or not doing the swap, i.e. American > Option). > The advantage is that it can go over multiple hops, and the exchange and > payee do not know each other (but the payer does). > Disadvantage is that it requires two hashlocks, which is rather obvious on > the protocol and signals "this payment is a cross-currency exchange > payment!" to all intermediate nodes; also, it still allows a short time > duration for American Option shenanigans. > > The Route Maker solution by CJP is plausible, to me, only if the exchan
