Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Christian,

> > -   A standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction Output, confirmed onchain
> > -   A "translator transaction" spending the above and paying out to a SegWit v16 output-tagged output, kept offchain.
> > -   Decker-Russell-Osuntokun update transaction, signed with `SIGHASH_NOINPUT` spending the translator transaction output.
> > -   Decker-Russell-Osuntokun state transaction, signed with `SIGHASH_NOINPUT` spending the update transaction output.
>
> 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.


> > Again, the more important point is that special blockchain
> > constructions should only be used in the "bad" unilateral close case.
> > In the cooperative case, we want to use simple plain
> > bip-schnorr-signed outputs getting spent to further bip-schnor/Taproot
> > SegWit v1 addresses, to increase the anonymity set of all uses of
> > Decker-Russell-Osuntokun and other applications that might use
> > `SIGHASH_NOINPUT` in some edge case (but which resolve down to simple
> > bip-schnorr-signed n-of-n cases when the protocol is completed
> > successfully by all participants).
>
> 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.
* 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.

>
> Not the strongest argument I know, but there's little point in talking
> ideal cases when we need to weaken that later again.

The point of ideal cases is to strive to approach them, not necessarily achieve them.
Just as a completely unbiased rational reasoner is almost impossible to achieve, does not mean we should give up all attempts to reduce bias.

Outpoints that used to be channels, but have now been closed using cooperative closes, will potentially no longer be widely gossiped as having once been channels, thus it may happen that they will eventually be forgotten by most of the network as once having been channels.
But if the outpoints of those channels are specially marked, then that cannot be forgotten, as the initial block download thereafter will have that history indelibly etched forevermore.

Regards,
ZmnSCPxj