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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
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 6533CC0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Mar 2020 02:20:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 5B9AC887E0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Mar 2020 02:20:42 +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 9es-Cywx0UAu
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Mar 2020 02:20:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by whitealder.osuosl.org (Postfix) with ESMTPS id 8E40487EBE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Mar 2020 02:20:40 +0000 (UTC)
Date: Sat, 28 Mar 2020 02:20:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1585362037;
bh=ZEFzTZvflpD4MPLqhqD6+7P4lmohn3qSiiRiozUfaeQ=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=H+yp475lxaWxKdk9wwP6Acj+/pL8h5FP9qv7+UyPHmaaDoW47MsoKNtvthbhgCVTE
VlnsVXvEXsl2xJxrBcEkDWj6MdbJgU+I+UL6oqWHkQiKLzXPJs1D5niGoHqpm+0fgt
z/SHBUNsh98L9tDjp+8sM+sz45nr+pEecj2FWE1M=
To: Ruben Somsen <rsomsen@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <YRSNEVWhWha9PJIxY-xCyNS8f85XWaD5Wk6EexcMpi_KFpm6QVr0VKO04m0qlhdE6JCVC0yFXL9dkemqz7L6QX-pJx2psJtyIzWO-9MAPC4=@protonmail.com>
In-Reply-To: <CAPv7TjbQ1WLxDJdufTwYttXz0asdBjAcCTDiMcdvm8xfdUv6=g@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>
<j37G_ywUw4UA7J2iEXurAk8Vq-QA3toUz3sakqEiYHqbpqF1DEK0riorbuZW_UkMCkNS-KKCDNPec7ogpchdg8hYPjPh_gzAGwfbY72e_p4=@protonmail.com>
<CAPv7TjbQ1WLxDJdufTwYttXz0asdBjAcCTDiMcdvm8xfdUv6=g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"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: Sat, 28 Mar 2020 02:20:42 -0000
Good morning Ruben,
> >The broadcasting of the kickoff simply means that the first stage cannot=
be easily changed
>
> I see what you're saying. Yeah, it does ruin the stages. If the kickoff t=
x hits the chain, you'd probably just want to "refresh" the UTXO by agreein=
g with the statechain entity to spend it to a new statechain 2-of-2 UTXO on=
-chain, thus removing all prior owners. Ideally you'd want it to be more co=
stly to CPFP the kickoff tx than it is to refresh the UTXO, so the defender=
is at an advantage. The statechain entity should probably pay for every re=
fresh ("insurance"), since the actual owner isn't at fault.
Actually, thinking a little more, it seems that you can try to ensure that =
the first stage never drops to 0 relative locktime.
Then if somebody broadcasts the kick-off, the current owner can ask the sta=
techain entity to sign an alternative to the first stage, with 0 relative l=
ocktime, that can now be a new funding transaction to anchor a (actually ne=
w, but logically a continuation) statechain.
Regards,
ZmnSCPxj
>
> Cheers,
> Ruben
>
> On Fri, Mar 27, 2020 at 2:46 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> > 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 remembe=
red that this alters the txid, causing the settlement tx to become invalid.=
What I am suggesting should be functionally the same (albeit less space-ef=
ficient): 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 conside=
red for Lightning as well at some point. Do you happen to recall if there w=
as some 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 y=
ou cry by opportunistically spending such an output.
> > For example your Bitcoin-network peer could notice you broadcasting suc=
h 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 chi=
ld transaction, instead broadcast a non-RBF child transaction with tiny fee=
, so that it and its parent transaction will be accepted into mempools but =
would not be replaceable with a higher-feerate child transaction (because n=
ot RBF-flagged).
> > Thus, some portion of mempools will contain this poisoned low-fee child=
transaction and prevent the parent from being confirmed (because the paren=
t+child 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=
-always-RBF.
> >
> > The solution that I remember being proposed for this in Lightning was t=
o give each participant its own attach-your-fees output that only that part=
icipant can spend, which works for Lightning because the set of participant=
s in a channel is permanently fixed, but probably not for statechains.
> >
> > --
> >
> > The broadcasting of the kickoff simply means that the first stage canno=
t be easily changed, and you might still be able to make further updates by=
updating only the later stages, until the last stage is confirmable, so th=
e kickoff being broadcast simply creates a "dead man walking" statechain.
> > However, the implementation complexity would probably increase tremendo=
usly.
> >
> > Regards,
> > ZmnSCPxj
|
