Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo
ZmnSCPxj writes: >> cooperative close: >> * when all parties mutually agree to close the channel >> * close the channel with a layer one transaction which finalizes the outputs >> from the most recent channel output state >> * should be optimized for privacy and low on-chain fees > > Of note is that a close of an update mechanism does not require the > close of any hosted update mechanisms, or more prosaically, "close of > channel factory does not require close of hosted channels". This is > true for both unilateral and cooperative closes. > > Of course, the most likely reason you want to unilaterally close an > outer mechanism is if you have some contract in some deeply-nested > mechanism that will absolute-locktime expire "soon", in which case you > have to close everything that hosts it. But for example if a channel > factory has channels A B C and only A has an HTLC that will expire > soon, while the factory and A have to close, B and C can continue > operation, even almost as if nothing happened to A. Indeed this is something that I think we already mentioned back in the duplex micropayment channel days, though it was a bit hidden and only mentioned HTLCs (though the principle carries over for other structures built on the raw update mechanism): > The process simply involves one party creating the teardown > transaction, both parties signing it and committing it to the > blockchain. HTLC outputs which have not been removed by agreement can > be copied over to the summary transaction such that the same timelocks > and resolution rules apply. Notice that in the case of eltoo the settlement transaction is already the same as the teardown transaction in DMC. >> membership change (ZmnSCPxj ritual): >> * when channel parties want to leave or add new members to the channel >> * close and reopen a new channel via something like a channel splicing >> transaction to the layer one blockchain >> * should be optimized for privacy and low on-chain fees paid for by parties >> entering and leaving the channel > > Assuming you mean that any owned funds will eventually have to be > claimed onchain, I suppose this is doable as splice-out. > > But note that currently we have some issues with splice-in. > > As far as I can tell (perhaps Lisa Neigut can correct me, I believe > she is working on this), splice-in has the below tradeoffs: > > 1. Option 1: splice-in is async (other updates can continue after all > participants have sent the needed signatures for the splice-in). > Drawback is that spliced-in funds need to be placed in a temporary > n-of-n, meaning at least one additional tx. Indeed this is the first proposal I had back at the Milan spec meeting, and you are right that it requires stashing the funds in a temporary co-owned output to make sure the transition once we splice in is atomic. Batching could help here, if we have 3 participants joining they can coordinate to set the funds aside together and then splice-in at the same time. The downside is the added on-chain transaction, and the fact that the funds are not operational until they reach the required depth (I don't think we can avoid this with the current security guarantees provided by Bitcoin). Notice that there is still some uncertainty regarding the confirmation of the splice-in even though the funds were stashed ahead of time, and we may end up in a state where we assumed that the splice-in will succeed, but the fees we attached turn out to be too low. In this case we built a sandcastle that collapses due to our foundation being washed away, and we'd have to go back and agree on re-splicing with corrected fees (which a malicious participant might sabotage) or hope the splice eventually confirms. > 2. Option 2: splice-in is efficient (only the splice-in tx appears onchain). > Drawback is that subsequent updates can only occur after the splice-in tx > is deeply confirmed. > * This can be mitigated somewhat by maintaining a pre-splice-in > and post-splice-in mechanism, until the splice-in tx is deeply > confirmed, after which the pre-splice-in version is discarded. > Updates need to be done on *both* mechanisms until then, and any > introduced money is "unuseable" anyway until the splice-in tx > confirms deeply since it would not exist in the pre-splice-in > mechanism yet. This is the more complex variant we discussed during the last face-to-face in Australia, and it seemed to me that people were mostly in favor of doing it this way. It adds complexity since we maintain multiple variants (making it almost un-implementable in LN-penalty), however the reduced footprint, and the uncertainty regarding confirmations in the first solution are strong arguments in favor of this option. > But perhaps a more interesting thing (and more in keeping with my > sentiment "a future where most people do not typically have > single-signer ownership of coins onchain") would be to transfer funds > from one
Re: [Lightning-dev] Proposal for Stuckless Payment
Ohayou Hiroki-san, I agree this possibility. Of note is that this also helps support: 1. Cross-currency swaps without premium-free American Call Option. Exchanges will demand for a premium to be paid for revelation of the second preimage. 2. Non-custodial Escrow. The second preimage is shared between the escrow and the payer. Both will also just as well be served by using points. Regards, ZmnSCPxj > > I explained Stuckless Payments on the basis of PTLCs before and some people > understood that this is a proposal that can be accomplished after PTLCs are > introduced. But this can also be accomplished using HTLC variants that are > not compatible with BOLT 1.x HTLCs. For simplicity, I'd like to describe them > in Miniscript policies (http://bitcoin.sipa.be/miniscript/). > > # The BOLT #3 offered HTLC policy > or(pk(key_revocation),and(pk(key_remote),or(pk(key_local),hash160(H > -> > or(pk(key_revocation),and(pk(key_remote),or(pk(key_local),and(hash160(H),hash160(H) > > # The BOLT #3 received HTLC policy > or(pk(key_revocation),and(pk(key_remote),or(and(pk(key_local),hash160(H)),older(1008 > -> > or(pk(key_revocation),and(pk(key_remote),or(and(pk(key_local),and(hash160(H),hash160(H))),older(1008 > > In both cases, I just changed `hash160(H)` to `and(hash160(H), hash160(H))`. > The notation seems to refer to the same `H`, but these are different. One is > provided by payer and the other is provided by payee. So we don't necessarily > have to wait for PTLCs. > > Regards, > Hiroki > > 2019年6月27日(木) 18:45 Hiroki Gondo : > > > Hi ZmnSCPxj and Bastien, > > > > When I was putting together this proposal, I thought it would be difficult > > for me to consider all the security and privacy issues. I am very glad that > > you raised the possible issues. > > > > > So my opinion, it is best to retain this property of "D does not know > > > payer A". > > > > I agree with your opinion too. I thought there was no problem if the ACK > > and the PoP were responses of the HTLCs and the key respectively. But, > > > > > The added communication round may allow intermediate node to guess the > > > payer. > > > > > With addition of new ACK-key turnaround, intermediate node can measure > > > time from send of ACK to receive of key, and guess its distance to payer. > > > > Right. > > > > > A can select another route (e.g. D -> E -> F -> A) and can create the ACK > > > onion packet during the setup phase. > > > A can then embed this ACK packet inside the last hop payload of the > > > *add_htlc* onion packet. > > > When D receives it, it simply sends that onion to the indicated recipient > > > (E) which will unwrap and forward. > > > This way D doesn't learn anything about A, and intermediate nodes aren't > > > included in the ACK route so > > > they don't learn anything either. > > > > I think this is likely to be an improvement. This could also be generalized > > as a case where a packet we send goes back to us via a given node. I need > > to understand more precisely the limitations of the onion packet including > > new specs under development. In the process, I will also consider > > combination of this proposal with AMP and new routing algorithms > > (Trampoline, Rendezvous). > > > > Regards, > > Hiroki ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Stuckless Payment
Hi all, I explained Stuckless Payments on the basis of PTLCs before and some people understood that this is a proposal that can be accomplished after PTLCs are introduced. But this can also be accomplished using HTLC variants that are not compatible with BOLT 1.x HTLCs. For simplicity, I'd like to describe them in Miniscript policies (http://bitcoin.sipa.be/miniscript/). # The BOLT #3 offered HTLC policy or(pk(key_revocation),and(pk(key_remote),or(pk(key_local),hash160(H -> or(pk(key_revocation),and(pk(key_remote),or(pk(key_local),and(hash160(H),hash160(H) # The BOLT #3 received HTLC policy or(pk(key_revocation),and(pk(key_remote),or(and(pk(key_local),hash160(H)),older(1008 -> or(pk(key_revocation),and(pk(key_remote),or(and(pk(key_local),and(hash160(H),hash160(H))),older(1008 In both cases, I just changed `hash160(H)` to `and(hash160(H), hash160(H))`. The notation seems to refer to the same `H`, but these are different. One is provided by payer and the other is provided by payee. So we don't necessarily have to wait for PTLCs. Regards, Hiroki 2019年6月27日(木) 18:45 Hiroki Gondo : > Hi ZmnSCPxj and Bastien, > > When I was putting together this proposal, I thought it would be difficult > for me to consider all the security and privacy issues. I am very glad that > you raised the possible issues. > > > So my opinion, it is best to retain this property of "D does not know > payer A". > > I agree with your opinion too. I thought there was no problem if the ACK > and the PoP were responses of the HTLCs and the key respectively. But, > > > The added communication round may allow intermediate node to guess the > payer. > > > With addition of new ACK-key turnaround, intermediate node can measure > time from send of ACK to receive of key, and guess its distance to payer. > > Right. > > > A can select another route (e.g. D -> E -> F -> A) and can create the ACK > > onion packet during the setup phase. > > A can then embed this ACK packet inside the last hop payload of the > > *add_htlc* onion packet. > > When D receives it, it simply sends that onion to the indicated recipient > > (E) which will unwrap and forward. > > This way D doesn't learn anything about A, and intermediate nodes aren't > > included in the ACK route so > > they don't learn anything either. > > I think this is likely to be an improvement. This could also be > generalized as a case where a packet we send goes back to us via a given > node. I need to understand more precisely the limitations of the onion > packet including new specs under development. In the process, I will also > consider combination of this proposal with AMP and new routing algorithms > (Trampoline, Rendezvous). > > Regards, > Hiroki > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
