ZmnSCPxj <zmnsc...@protonmail.com> writes: >> That is very much how I was planning to implement it anyway, using a >> trigger transaction to separate timeout start and the actual >> update/settlement pairs (cfr. eltoo paper Section 4.2). So for eltoo >> there shouldn't be an issue here :-) > > My understanding is that a trigger transaction is not in fact > necessary for Decker-Russell-Osuntokun: any update transaction could > spend the funding transaction output directly, and thereby start the > relative timelock. At least, if we could arrange the funding > transaction output to be spendable directly using `SIGHASH_NOINPUT` or > variants thereof.
This is the case in which we don't have a pre-signed settlement transaction (or in this case refund transaction) that uses a relative timelock. In order to have a refund transaction we would need to have the first update and settlement pair be signed before funding (otherwise the funder isn't sure she is getting her funds back). Since that first update and settlement pair do not need to be rebound (they can only ever be bound to the funding transaction) they can be signed without noinput/anyprevoutanyscript. If we use output tagging we would mandate that this first update must be published, so that the funding output is indistinguishable from a normal output, and the first update switches from non-noinput/anyprevoutanyscript to enabling it. Collaborative closes are still indistinguishable, unilateral closes require the switch, but then would be identifiable anyway. The one downside I can see is that we now mandate that unilateral closes also publish the first update, which is a bit annoying. >> While I do agree that we should keep outputs as unidentifiable as >> possible, I am starting to question whether that is possible for >> off-chain payment networks since we are gossiping about the existence of >> channels and binding them to outpoints to prove their existence anyway. > > * Lightning supports unpublished channels, so we do not gossip some outpoints > even though they are in fact channels underneath. > * I confess the existence of unpublished channels in the spec fails to > summon any reaction other than incredulity from me, but they exist > nonetheless, my incredulity notwithstanding. That is true, we do however selectively tell others about the channel's existence (in invoices, our peers, ...) so I wouldn't consider that to be the most secret information :-) As for why they exist: nodes need to have the option of not announcing their channels to reduce the noise in the network with channels that are unlikely to be useable in order to forward payments. If every node were to announce their channels we'd have a much larger routing table, mostly consisting of unusable channels going to leafs in the network. Furthermore, the sheer threat that there might be unannounced channels adds uncertainty for attackers trying to profile nodes: "I see only my channel with my peer, but he might have unannounced channels, so I can't really tell whether the payment I forwarded to it is destined for it or one of its unannounced peers". > * Historical channels that have been cooperatively closed are no longer > normally gossiped, so the fact that they used to be channels is no longer > widely broadcast, and may eventually be forgotten by most or all of the > network. > * This means anyone who wants to record the historical use of Lightning > will have to retain the information themselves, rather than delegating it to > fullnodes everywhere. Good point, it requires storing the ephemeral data from gossip, that's not all that hard, but I agree that it puts up a small barrier for newcomers. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
