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
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 542021469;
Thu, 14 Mar 2019 12:01:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com
[209.85.208.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 27F1C82F;
Thu, 14 Mar 2019 12:01:25 +0000 (UTC)
Received: by mail-ed1-f50.google.com with SMTP id d6so3805475eds.2;
Thu, 14 Mar 2019 05:01:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:in-reply-to:references:date:message-id
:mime-version; bh=vuhPnIC/DUoFDAJ/M7VI5hOBCO/DiMblOO1c9LNQzbQ=;
b=MbJLWObVGQJUiRa2dGvVwHEH+ysd+4oCssyBwXs8hzPk5Pr9ltc2yuBEIKmybCPa7V
xBf3JE26d57k6cltRqUNBhP18Pt0dGiKOzo1G1EqdSkj13hS7Y3aAKM3bGGB+SNbpI38
+o8Rw12bYXHHn0FZg81FA1/+hRRlK0ROUOlnrhXiMiFVNqR8u1+LCAakL8olkbCVf0IS
mdWC3qwLGA2O9w9EHebi07di870pPl/CS91PDKt0bKgq090qSNlJ4pLkzTRzP2oWlXyZ
I3nVJBqXspehb2KnC4mh+1SXb9sQbk6b/wtjj8IU/0ARiFmahRNysawLECEmShWyiyNd
ZDMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
:message-id:mime-version;
bh=vuhPnIC/DUoFDAJ/M7VI5hOBCO/DiMblOO1c9LNQzbQ=;
b=oG8IT/wa7XR8yQYqSaz5pBuqqHTIeEygRPL9XsHI4beGYrZ70PbcUmPQnBA292puqh
jdXM2CpBq3Y7+8UEeibhMNWhaY9Qhm+VcG9aN3rQXBsO3tTL3++N0clOpMW739JKkVF/
6u1mOs9263eztklXmZRDP0iH5gJ8wBylibGPgIEZQ1bnEncdMMc0s0CJ3Iwz6fBA2FRi
FmpNG3Rg0dApDvb9XMEqvLXoJ/Pj3649O2S/lUUue3IyzRt6fsNMSCYZE8+8QUFvHrAG
zeTGnAop0lmq1mumeCT+yftGlXSfEuFzZavTVVak/6cRF+IL/OCa6T8cj3LNWuLxvZFC
nJaA==
X-Gm-Message-State: APjAAAUO/rRt1LfG4EojL0AsvZ0JlUO6MtNOeTtNlZxfi6x9PvpzXXga
KN4S6Qfwv4OfBwWWcB0xA7A=
X-Google-Smtp-Source: APXvYqwDUZ6NXbA9mXHn6/3CTe6YH1+A6ZC3s+a0CKztVR9FVwUggSosOJ54tW/ZV5n2G4TExiH/dg==
X-Received: by 2002:a17:906:54d:: with SMTP id
k13mr2654079eja.207.1552564883543;
Thu, 14 Mar 2019 05:01:23 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:c11f:6203:8f52:52eb])
by smtp.gmail.com with ESMTPSA id
m30sm1402654eda.84.2019.03.14.05.01.22
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 14 Mar 2019 05:01:22 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: Anthony Towns <aj@erisian.com.au>, ZmnSCPxj <ZmnSCPxj@protonmail.com>
In-Reply-To: <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>
<20190314072456.br2leoiae6zs2jv2@erisian.com.au>
Date: Thu, 14 Mar 2019 13:00:56 +0100
Message-ID: <87mulx3bt3.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE 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 12:11:36 +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 12:01:26 -0000
Anthony Towns <aj@erisian.com.au> writes:
> 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.
I might be missing something here, but how do you bind update 3 to the
funding tx output, when that output is not tagged? Do we keep each
update in multiple separate states, one bound to the funding tx output
and another signed with noinput? If that's the case we just doubled our
storage and communication requirements for very little gain. An
alternative is to add a trigger transaction that needs to be published
in a unilateral case, but that'd increase our on-chain footprint.
|
