From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Anthony Towns <aj@erisian•com.au>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>,
"lightning-dev@lists•linuxfoundation.org"
<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
Date: Wed, 13 Mar 2019 06:41:47 +0000 [thread overview]
Message-ID: <gs0Aizmvb8U11-Uz4RUqrEwgu00deU3JRhwHWbPjn8g1lZV3iaydqoYP3tldfrflHRC2HHJEZtAOVeYdaOW-chMcRdPVSiNYmqT6jSPnL1c=@protonmail.com> (raw)
In-Reply-To: <20190313014143.ifffshwdux2jt7w5@erisian.com.au>
Good morning aj,
First off, I have little to no idea of the issues at the lower-level Bitcoin.
In any case ---
> - alternatively, we could require every script to have a valid signature
> that commits to the input. In that case, you could do eltoo with a
> script like either:
>
> <A> CHECKSIGVERIFY <B> CHECKSIG
> or <P> CHECKSIGVERIFY <Q> CHECKSIG
>
>
> where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
> a key they both know the private key for. In the first case, Alice
> would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
> Bob would just do a SIGHASH_ALL sig with his own key. In the second,
> Alice and Bob would share partial NOINPUT sigs of the tx with P, and
> finish that when they wanted to publish.
>
> This is a bit more costly than a key path spend: you have to reveal
> the taproot point to do a script (+33B) and you have two signatures
> instead of one (+65B) and you have to reveal two keys as well
> (+66B), plus some script overhead. If we did the <P,Q> variant,
> we could provide a "PUSH_TAPROOT_KEY" opcode that would just push
> the taproot key to stack, saving 33B from pushing P as a literal,
> but you can't do much better than that. All in all, it'd be about 25%
> overhead in order to prevent cheating. [0]
>
> I think that output tagging doesn't provide a workable defense against the
> third party malleability via a deeper-than-the-CSV-delay reorg mentioned
> earlier; but requiring a non-NOINPUT sig does: you'd have to replace
> the non-NOINPUT sig to make state 5 spend state 3 instead of state 4,
> and only the holders of the appropriate private key can do that.
At my point of view, if a NONINPUT sig is restricted and cannot be used to spend an "ordinary" 2-of-2, this is output tagging regardless of exact mechanism.
So the restriction to add a non-NOINPUT sig in addition to a NOINPUT sig is still output tagging, as a cooperative close would still reveal that the output is not a 2-of-2.
Ideally, historical data of whether onchain coin was used in Lightning or not should be revealed as little as possible.
So in a cooperative close (which we hope, to be a common case), ideally the spend should look no different from an ordinary 2-of-2 spend.
Of course if the channel is published on Lightning, those who participated in Lightning at the time will learn of it, but at least the effort to remember this information is on those who want to remember this fact.
Now, this can be worked around by adding a "kickoff" transaction that spends the eltoo setup transaction.
The eltoo setup transaction outputs to an ordinary 2-of-2.
The kickoff outputs to an output that allows NOINPUT.
Then the rest of the protocol anchors on top of the kickoff.
The kickoff is kept offchain, until a non-cooperative close is needed.
Of course, as it is not a NOINPUT itself, it must need onchain fees attached to it.
This of course complicates fees, as we know.
Alternately maybe the kickoff can be signed with `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` so that it is possible to add a fee-paying UTXO to it.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2019-03-13 6:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-13 1:41 [bitcoin-dev] " Anthony Towns
2019-03-13 6:41 ` ZmnSCPxj [this message]
2019-03-13 11:10 ` [bitcoin-dev] [Lightning-dev] " Anthony Towns
2019-03-14 5:22 ` ZmnSCPxj
2019-03-14 7:24 ` Anthony Towns
2019-03-14 7:55 ` ZmnSCPxj
2019-03-14 12:00 ` Christian Decker
2019-03-20 0:22 ` Rusty Russell
2019-03-20 3:33 ` Rusty Russell
2019-03-20 7:38 ` ZmnSCPxj
2019-03-20 8:07 ` ZmnSCPxj
2019-03-21 8:37 ` Johnson Lau
2019-03-21 9:06 ` Anthony Towns
2019-03-21 10:05 ` ZmnSCPxj
2019-03-21 11:55 ` Anthony Towns
2019-03-22 1:59 ` ZmnSCPxj
2019-03-22 2:58 ` Anthony Towns
2019-03-22 7:46 ` ZmnSCPxj
2019-03-22 4:23 ` Johnson Lau
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='gs0Aizmvb8U11-Uz4RUqrEwgu00deU3JRhwHWbPjn8g1lZV3iaydqoYP3tldfrflHRC2HHJEZtAOVeYdaOW-chMcRdPVSiNYmqT6jSPnL1c=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--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