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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5B1A6C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Mar 2020 01:46:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 4AE43888D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Mar 2020 01:46:23 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id E0wiwBQ0KzJW
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Mar 2020 01:46:21 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by whitealder.osuosl.org (Postfix) with ESMTPS id 267BC88783
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Mar 2020 01:46:21 +0000 (UTC)
Date: Fri, 27 Mar 2020 01:46:15 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1585273578;
bh=Pj8NZbgXaVU02LPOTrdTRJFEF8AJOXm6opLuykosAW0=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=miqwARwNz2Z+uEuEYtdS4X7xBo2DJiHN+tfpTb1j+TE3KwxQVwOe+0Wyy4pgNsWNa
tmyaQySfqw5d3WqVUUT72oZkg24LQqShIm3KDrHcB3zKLHxEeUw6Nl3GMoTv0SBRB/
H0P1JiVfukk4ldbGmriiuFSI4PwPe0O0/tqUFF+U=
To: Ruben Somsen <rsomsen@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <j37G_ywUw4UA7J2iEXurAk8Vq-QA3toUz3sakqEiYHqbpqF1DEK0riorbuZW_UkMCkNS-KKCDNPec7ogpchdg8hYPjPh_gzAGwfbY72e_p4=@protonmail.com>
In-Reply-To: <CAPv7TjbAfLHFZgSvCTSG2rS6oZinyd6VWrT3U8Y++PL=Jm6igA@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>
<87369v6nw3.fsf@gmail.com>
<CAB3F3Dt0z5bDMpzRGGJxJV8KpCk_4XGF23MGmYVkLppRbG7Wnw@mail.gmail.com>
<CAPv7TjbAfLHFZgSvCTSG2rS6oZinyd6VWrT3U8Y++PL=Jm6igA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "tom@commerceblock.com" <tom@commerceblock.com>,
Greg Sanders <gsanders87@gmail.com>
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: Fri, 27 Mar 2020 01:46:23 -0000
Good morning Ruben,
> Hey Christian,
>
> Thanks for chiming in :)
>
> >It might be worth adopting the late fee binding we have in eltoo
>
> That is where my thinking originally went as well, but then I remembered =
that this alters the txid, causing the settlement tx to become invalid. Wha=
t I am suggesting should be functionally the same (albeit less space-effici=
ent): a secondary output that can be spent by anyone, which can be used to =
fee bump the kickoff tx with CPFP. I believe this same idea was considered =
for Lightning as well at some point. Do you happen to recall if there was s=
ome kind of non-standardness issue with it?
Any standardness issue can be fixed by embedding it in a P2WSH / P2SH, you =
can use an `OP_TRUE` `redeemScript`, for instance.
Using an `OP_TRUE` `redeemScript` would allow any third party to make you c=
ry by opportunistically spending such an output.
For example your Bitcoin-network peer could notice you broadcasting such a =
transaction with an `OP_TRUE` output, see you spend that output with a CPFP=
-RBF-ed child transaction, then instead of further broadcasting the child t=
ransaction, instead broadcast a non-RBF child transaction with tiny fee, so=
that it and its parent transaction will be accepted into mempools but woul=
d not be replaceable with a higher-feerate child transaction (because not R=
BF-flagged).
Thus, some portion of mempools will contain this poisoned low-fee child tra=
nsaction and prevent the parent from being confirmed (because the parent+ch=
ild fees are not enough to justify being put in a block).
Which I suppose is an argument for Full RBF aka ignore-the-RBF-flag-and-alw=
ays-RBF.
The solution that I remember being proposed for this in Lightning was to gi=
ve each participant its own attach-your-fees output that only that particip=
ant can spend, which works for Lightning because the set of participants in=
a channel is permanently fixed, but probably not for statechains.
--
The broadcasting of the kickoff simply means that the first stage cannot be=
easily changed, and you might still be able to make further updates by upd=
ating only the later stages, until the last stage is confirmable, so the ki=
ckoff being broadcast simply creates a "dead man walking" statechain.
However, the implementation complexity would probably increase tremendously=
.
Regards,
ZmnSCPxj
|
