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
110
111
112
113
114
115
116
117
118
|
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 1896F13EB;
Thu, 3 Oct 2019 10:33:54 +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 69881189;
Thu, 3 Oct 2019 10:33:53 +0000 (UTC)
Received: by mail-ed1-f50.google.com with SMTP id f20so1958045edv.8;
Thu, 03 Oct 2019 03:33:53 -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=63bNKWxh3uKk7QOmVCHuU5suOus0H7KJcBswx6cFbq0=;
b=OS3IWElytJt7NOimbGhqFIjNWHtpYmumJRRBM5aqMsDfJHaupLlLWaAf8Sb4Xxh+w+
7x7j/4sk5KGi9gGnwlVTuRojhrDxs0m+0z2e+lWprM8t6qGJQLbeTpzJtEJLYS0tQQtp
vD/QzoVBU8AeEZmAikwWqXrM6+LeQe0bZnlqkXHWeaQg0DJ9FaacMh/zWMPRQbrLPrqj
JkVkQF4bOGfabVuJgG59zF0Q7hTR3Bjg0ht9VG5/hpfT+r4v74FviV5pH8ZONKi2AL3+
11n+6AdBTMzC/5NpXYQykF7GKulUwyk4jCRWbLpevaPxy09SH0RGUR5+GxYmjCqPekJV
FYNg==
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=63bNKWxh3uKk7QOmVCHuU5suOus0H7KJcBswx6cFbq0=;
b=DbKQ7kkuiGQbYe/RGmI1NnAOl85h4TdH+gTqRh1pPHl1dUFh30Nhvp5usKY4NGSdl4
EkMEnKNPPWSXxUrhZ+4QMQMDdgTeLJZa34cSRxLyzq4oXfVtuks5PbFgoaRIPTfz121a
sw0HjYakAzDf2m8bcVoq1vRB+U/INPD1oDXdxyORqHT4PGWnjNiOg2VOvN0m6D04pSDU
CDQPyKDihO+S1gQ2qqkiZrzHDS8rOVMUfWyN/wOXTR3VewUefItOOnw6/o4YdfjSVsCk
AOJs49vYelXM+3mG36oli/wgx/BYISLvcF3GFMkeAxOzzoro4t2H8eiV8z/QHt1kzzkm
XP8Q==
X-Gm-Message-State: APjAAAUEz0arwUU1X90fpvhIkKocGjjPMXVdjaoS2bmhRfjPNae8qBXK
E3/HnOnt7Nj1IX/Ct4xCddc=
X-Google-Smtp-Source: APXvYqzjADeGgzqFj8rPG/aYD+qYXpI6PY/nyO/gaVwait/b51zMDkIzNWKu0X8WZukx4VQgcPGmpw==
X-Received: by 2002:a50:da44:: with SMTP id a4mr8778559edk.120.1570098832033;
Thu, 03 Oct 2019 03:33:52 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:437:6ae2:fddc:d532])
by smtp.gmail.com with ESMTPSA id h38sm391970edh.13.2019.10.03.03.33.51
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 03 Oct 2019 03:33:51 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Chris Stewart <chris@suredbits.com>
In-Reply-To: <bMt69zMSAH_2zekGjg56k6MWFMwWkjKMdUjqHQ5eN7c5ONixWZ0s2wW4HmILeVjImt6Z2K5fPa6GKGLP_HWThCzFIIu53wvEKTDrGg-YpOQ=@protonmail.com>
References: <87wodp7w9f.fsf@gmail.com>
<CAFQwNuxdfMNBGyM5Y4nMb46GNigxFTFCv3X09jZd4fjNPckw4Q@mail.gmail.com>
<bMt69zMSAH_2zekGjg56k6MWFMwWkjKMdUjqHQ5eN7c5ONixWZ0s2wW4HmILeVjImt6Z2K5fPa6GKGLP_HWThCzFIIu53wvEKTDrGg-YpOQ=@protonmail.com>
Date: Thu, 03 Oct 2019 12:01:58 +0200
Message-ID: <87imp66tbd.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
Cc: Christian Decker via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about
noinput / anyprevout
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, 03 Oct 2019 10:33:54 -0000
ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> Good morning lists,
>
> Let me summarize concerns brought up:
>
> * Chris concern, is that an ordinary UTXO that is not allocated for `SIGHASH_NOINPUT` use, is inadvertently spent using `SIGHASH_NOINPUT`.
> * My concern, is that unless a UTXO allocated for `SIGHASH_NOINPUT` use, is *indeed* used with SIGHASH_NOINPUT`, it should look exactly the same as any other SegWit v1 output.
>
> I propose the below instead:
>
> * Do ***NOT*** allocate SegWit v16 for `SIGHASH_NOINPUT`.
> * Instead, allocate SegWit v1 Tapscript v16 for `SIGHASH_NOINPUT`.
>
> Then, on usage:
>
> * Exchange hoards can be protected by simple MuSig bip-schnorr SegWit v1 outputs, or a NUMS Taproot internal point with a MAST branch Tapscript v0 `OP_CHECKSIG_ADD` sequence.
> * Decker-Russell-Osuntokun constructions are backed by a n-of-n MuSig Taproot internal point, with a MAST branch containing a Tapscript v16 with `OP_1 OP_CHECKSIG`.
>
> This solves both concerns:
>
> * Ordinary UTXOs not allocated for `SIGHASH_NOINPUT` use simply do not commit to any Taproot that has a Tapscript v16 branch, and thus `SIGHASH_NOINPUT` is unuseable to claim it.
> * If a UTXO used for an offchain protocol ends up in a cooperative-resolution state, nobody has to know that a Tapscript v16 branch existed that could have used `SIGHASH_NOINPUT`.
>
> Again, my objection to output tagging is that it is **publicly visible** as soon as the funding transaction is confirmed onchain that this is a special output used for a Decker-Russell-Osuntokun construction, greatly damaging privacy.
> But if this fact is kept secret *unless* the very specific case of unilateral uncooperative enforcement, then it is quite fine with me.
>
> Would this alternate proposal hold better muster?
Intriguing idea, this would be an invisible tagging, since the opt-in to
noinput and friends is hidden inside the committed script, which only
gets revealed whenever we actually need it.
For eltoo this would mean that the funding output would be invisibly
tagged, and the cooperative close would use the taproot pubkey, while
the uncooperative close, which would require noinput opt-in, reveals the
script, proving prior opt-in, and provides a matching signature.
If I'm not mistaken this would require AJ's alternative pubkey encoding
(0x01 or 0x00 prefixed pubkey) to make the opt-in visible, correct?
|
