From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Christian Decker <decker.christian@gmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
"lightning-dev\\@lists.linuxfoundation.org"
<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout
Date: Tue, 01 Oct 2019 15:35:34 +0000 [thread overview]
Message-ID: <4zx7e_vHQr58myY5w_-bAjTk04LTGNknZudZs4wbUiOIoVKhL69M7k1eELCSuoBND2CtVXXzDFBHW4351cttIh80eP8jiaoO8cmbSefZmj4=@protonmail.com> (raw)
In-Reply-To: <87tv8s7djq.fsf@gmail.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
next prev parent reply other threads:[~2019-10-01 15:35 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-30 13:23 Christian Decker
2019-09-30 16:00 ` ZmnSCPxj
2019-09-30 23:28 ` ZmnSCPxj
2019-10-01 14:26 ` Christian Decker
2019-10-01 14:45 ` Anthony Towns
2019-10-01 15:42 ` ZmnSCPxj
2019-10-01 14:20 ` Christian Decker
2019-10-01 15:35 ` ZmnSCPxj [this message]
2019-10-03 9:42 ` Christian Decker
2019-10-01 12:23 ` Chris Stewart
2019-10-01 13:31 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2019-10-03 10:01 ` Christian Decker
2019-10-03 9:57 ` Christian Decker
[not found] ` <CACJVCgJ9PL-2jTS71--tXsa=QkK+f5_ciYLwv468WUno=XXAig@mail.gmail.com>
2019-10-01 14:27 ` Ethan Heilman
2019-10-01 15:14 ` Chris Stewart
2019-10-03 10:30 ` Christian Decker
2019-10-01 15:59 ` [bitcoin-dev] " Anthony Towns
2019-10-02 2:03 ` ZmnSCPxj
2019-10-03 1:47 ` [bitcoin-dev] [Lightning-dev] " Anthony Towns
2019-10-03 3:07 ` ZmnSCPxj
2019-10-03 15:05 ` [bitcoin-dev] OP_CAT was " Ethan Heilman
2019-10-03 23:42 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2019-10-04 0:48 ` Ethan Heilman
2019-10-04 5:02 ` Jeremy
2019-10-04 7:00 ` ZmnSCPxj
2019-10-04 18:33 ` Jeremy
2019-10-04 11:15 ` Peter Todd
2019-10-04 18:40 ` Jeremy
2019-10-05 15:49 ` Peter Todd
2019-10-06 8:46 ` ZmnSCPxj
2019-10-06 9:12 ` Peter Todd
2019-10-06 7:02 ` Lloyd Fournier
2019-10-09 16:56 ` Andrew Poelstra
2019-10-02 15:11 ` [bitcoin-dev] " s7r
2019-10-03 11:08 ` Christian Decker
2019-10-05 10:06 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='4zx7e_vHQr58myY5w_-bAjTk04LTGNknZudZs4wbUiOIoVKhL69M7k1eELCSuoBND2CtVXXzDFBHW4351cttIh80eP8jiaoO8cmbSefZmj4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=decker.christian@gmail$(echo .)com \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox