1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5D391FF7;
Thu, 14 Mar 2019 07:25:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C4BD282B;
Thu, 14 Mar 2019 07:25:05 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1h4Kjc-00070B-Rd; Thu, 14 Mar 2019 17:25:02 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 14 Mar 2019 17:24:56 +1000
Date: Thu, 14 Mar 2019 17:24:56 +1000
From: Anthony Towns <aj@erisian.com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <20190314072456.br2leoiae6zs2jv2@erisian.com.au>
References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au>
<gs0Aizmvb8U11-Uz4RUqrEwgu00deU3JRhwHWbPjn8g1lZV3iaydqoYP3tldfrflHRC2HHJEZtAOVeYdaOW-chMcRdPVSiNYmqT6jSPnL1c=@protonmail.com>
<20190313111050.qj3s6utpl2x34sam@erisian.com.au>
<Au1N1itlfJk5MRV-KoKfmL9BgOGBW1Pdq9vRr-PBVVJfpRngTmpuTmbF5wCAkBSsUvMt3maA3e-VVr-WDDdwh2-XVeCOLjxVsOxABm7cfpU=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Au1N1itlfJk5MRV-KoKfmL9BgOGBW1Pdq9vRr-PBVVJfpRngTmpuTmbF5wCAkBSsUvMt3maA3e-VVr-WDDdwh2-XVeCOLjxVsOxABm7cfpU=@protonmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 14 Mar 2019 07:29:59 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 07:25:06 -0000
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
|
