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
|
Return-Path: <decker.christian@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 273DCC0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 17:14:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 1437786D79
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 17:14:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id SSTcI_UXaE_k
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 17:14:58 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com
[209.85.221.53])
by fraxinus.osuosl.org (Postfix) with ESMTPS id B09B986D56
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 17:14:57 +0000 (UTC)
Received: by mail-wr1-f53.google.com with SMTP id h9so8770863wrc.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 10:14:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:subject:in-reply-to:references:date:message-id:mime-version;
bh=tUoV+oi0K45xUzUL4XnEhovtYPKTl9E4KvOSkhIZoIs=;
b=P1AvYM2dk0XM/xfpseXRmsYZlXPM18ToV/c3FNTF6++hsj08wwYWtjMm+bwZkCPx7b
OULXGpoH8lYVa07QQm8nkUy/5IduDwrib7rCj4vX3g75sEChWgWaIZ698qkAzq1MHa7E
d39+GuMS9l1orR8k/1nBQoBWAO6AskO14nM3bhqjf1pGu9/+cohL/67/OzNasRh4AVQi
Fbgzbtt5BP48usi9msAq4LEliL83SdYmwJMN+eqcnBw4LNHmoGV2snN8nWpw21NqDv73
3Ttg0mF+0X3nNMgVNvxm1mrjqYmrPZCwKe4umkNBr3By6TH0XlRwiFLYM5+HeCk6i8yL
ggig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:subject:in-reply-to:references:date
:message-id:mime-version;
bh=tUoV+oi0K45xUzUL4XnEhovtYPKTl9E4KvOSkhIZoIs=;
b=Uk+rvTMIwaUjQFj0qsGxrP/JCuYbXuwmztw0W2ZHrnRlo11wwAwNR1wJg0FXnsjPxH
sOSHJU4UgtJJ+72qsvl1z1PZhVwihn31S7nT/tZwhMJBcv74RrXS/5ovJKBmPF/JLUyb
/U6Cyq6bVtlDj6dzncOGRqrQt7tysUhXjihvlmVZgYmJh9btp7QepMj+5FC6pE6lQv7v
oDKYjuhNstuDK2MQzpE72ZCtkhyikroJqztcXaD1vLTsR5y1lpn9cL5g4kgO7lSwAjPy
QCEvuuUQ8XeyrhM2cy0nX2SmeLATPcKlYMxe1aNfoyyyvbWqSy2IHLrkAFAFF5pNv7cf
jAuA==
X-Gm-Message-State: ANhLgQ3+a3zA9gFpRMcHANfZuZmMifGA8/oNAZq/tIwOLnBx8UpphdXb
Y8mT8Hn6oHyJ1oITS4A+NVI=
X-Google-Smtp-Source: ADFU+vsEKOlqm1L/s6+riu2jHTtLOWK6bgU1UBU3Qa8JwQK2qGJackmmynIY5BYpTlng5RNwJBKESw==
X-Received: by 2002:adf:dd86:: with SMTP id x6mr10334397wrl.169.1585242895913;
Thu, 26 Mar 2020 10:14:55 -0700 (PDT)
Received: from localhost (243.86.254.84.ftth.as8758.net. [84.254.86.243])
by smtp.gmail.com with ESMTPSA id 71sm4718928wrc.53.2020.03.26.10.14.54
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 26 Mar 2020 10:14:55 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
tom@commerceblock.com,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPv7TjZ45VD_5sGSFiQxmt981uDodq28mHOW=2LYLofXams43w@mail.gmail.com>
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
<79753214-9d5e-40c7-97ac-1d4e9ea3c64e@www.fastmail.com>
<CAPv7TjZ45VD_5sGSFiQxmt981uDodq28mHOW=2LYLofXams43w@mail.gmail.com>
Date: Thu, 26 Mar 2020 18:12:44 +0100
Message-ID: <87369v6nw3.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] Statechain implementations
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 26 Mar 2020 17:14:59 -0000
Ruben Somsen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
writes:
> Regarding modification 1, I agree with ZmnSCPxj that
> Decker-Wattenhofer is your next best option, given that eltoo is not
> yet available. But if you are going to use a kickoff transaction, keep
> in mind that every previous owner will have a copy of it. Because of
> this, you can't include a fee, and will instead need to have a second
> output for CPFP. This way a previous owner will at least have to pay
> the fee if they want to publish it. Note that it's still an
> improvement, because even if the kickoff transaction gets posted, it
> basically becomes no different than what it would have been, had you
> not used a kickoff transaction at all.
It might be worth adopting the late fee binding we have in eltoo by
having the kickoff transaction input spending the funding tx signed with
sighash_single. This works because we only have 1 input and 1 output
that we really care about, and can allow others to attach fees at
will. That'd at least remove the need to guess the feerate days or
months in advance and thus having to overestimate.
> Regarding modification 2, I like it a lot conceptually. It hadn't
> occurred to me before, and it's a clear security improvement. The only
> question is something Greg Sanders mentioned: whether it's enough to
> justify the added complexity of using 2P ECDSA. The alternative would
> be to simply use a regular 2-of-2 multisig (until Schnorr arrives,
> possibly).
Wouldn't that result in a changing pubkey at each update, and thus
require an onchain move to be committed?
> I'm looking forward to seeing statechains become a reality.
That'd indeed be great :-)
Cheers,
Christian
|
