From: Anthony Towns <aj@erisian•com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
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: Thu, 14 Mar 2019 17:24:56 +1000 [thread overview]
Message-ID: <20190314072456.br2leoiae6zs2jv2@erisian.com.au> (raw)
In-Reply-To: <Au1N1itlfJk5MRV-KoKfmL9BgOGBW1Pdq9vRr-PBVVJfpRngTmpuTmbF5wCAkBSsUvMt3maA3e-VVr-WDDdwh2-XVeCOLjxVsOxABm7cfpU=@protonmail.com>
On Thu, Mar 14, 2019 at 05:22:59AM +0000, ZmnSCPxj via Lightning-dev wrote:
> When reading through your original post I saw you mentioned something about output tagging somehow conflicting with Taproot, so I assumed Taproot is not useable in this case.
I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput),
so if you used a tagged output, you could do everything normal taproot
address could, but also do noinput sigs for them.
So you might have:
funding tx -> cooperative claim
funding tx -> update 3 [TAGGED] -> settlement 3 -> claim
funding tx -> update 3 [TAGGED] ->
update 4 [TAGGED,NOINPUT] ->
settlement 4 [TAGGED,NOINPUT] ->
claim [NOINPUT]
In the cooperative case, no output tagging needed.
For the unilateral case, you need to tag all the update tx's, because
they *could* be spend by a later update with a NOINPUT sig, and if
that actually happens, then the settlement tx also needs to use a
NOINPUT sig, and if you're using scriptless scripts to resolve HTLCs,
claiming/refunding the HTLCs needs a partially-pre-signed tx which also
needs to be a NOINPUT sig, meaning the settlement tx also needs to be
tagged in that case.
You'd only need the script path for the last case where there actually
are multiple updates, but because you have to have a tagged output in the
second case anyway, maybe you've already lost privacy and always using
NOINPUT and the script path for update and settlement tx's would be fine.
> However, it is probably more likely that I simply misunderstood what you said, so if you can definitively say that it would be possible to hide the clause "or a NOINPUT sig from A with a non-NOINPUT sig from B" behind a Taproot then I am fine.
Yeah, that's my thinking.
> Minor pointless reactions:
> > 5. if you're using scriptless scripts to do HTLCs, you'll need to
> > allow for NOINPUT sigs when claiming funds as well (and update
> > the partial signatures for the non-NOINPUT cases if you want to
> > maximise privacy), which is a bit fiddly
> If I remember accurately, we do not allow bilateral/cooperative close when HTLC is in-flight.
> However, I notice that later you point out that a non-cheating unilateral close does not need NOINPUT, so I suppose. the above thought applies to that case.
Yeah, exactly.
Trying to maximise privacy there has the disadvantage that you have to
do a new signature for every in-flight HTLC every time you update the
state, which could be a lot of signatures for very active channels.
Cheers,
aj
next prev parent reply other threads:[~2019-03-14 7:25 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 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2019-03-13 11:10 ` Anthony Towns
2019-03-14 5:22 ` ZmnSCPxj
2019-03-14 7:24 ` Anthony Towns [this message]
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=20190314072456.br2leoiae6zs2jv2@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--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