path: root/be/6806a6743124bfdb006c83c1f167b1bdcceced

Return-Path: <rsomsen@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E5623C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 15:12:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id D232989611
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 15:12:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id L+QrXxzb70tC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 15:12:47 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com
 [209.85.210.68])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 3A29F895FA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 15:12:47 +0000 (UTC)
Received: by mail-ot1-f68.google.com with SMTP id j16so10069683otl.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 08:12:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=uDw1OR5yVnCHNirJK6zpTNkenQS/1X46FZH/48PczXo=;
 b=HVzKw3Dwuxji5y977EGb3T1jsxBDlkCBTHisM2XZ+73DKxNpXUgu6vz0o1cp4i91mh
 HcYe7UqKtxyiIamgOo+Y38Ku8m0KXmOyCujJapt+41Kphoe3uhHz9g3y1ggyVDMmyKjg
 Kv3fu+jwtzygPYAc0iC2wOje8MsC8jP8w6gB9/wDKIInl14mtVS/IqOlJFzYZupg5Uq0
 1CzWBviqIyaoB0dqxc6Peth7vXovonGhDzuRRM2yE7wTu+G9gJagMCBntrbyEPcQxyqz
 WaH0DAC7eVs1K3fXalQUjfHntrDYsCr0huE1mBu9/lQHFTBGvcOsFSiEKwBdIafE027p
 rTaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=uDw1OR5yVnCHNirJK6zpTNkenQS/1X46FZH/48PczXo=;
 b=cLtHo2LcYV4H47FS5D5B5T+wLRdf1JqDUg1wiKU7XY4Rvcb3hy81DfSXEChCLHOEfM
 2+iL4vIziX5RAjBmcxTQjcIBKn0qRFACRLshTDeUqkDp/kjGbgk3cWQLGKwcVBYr6uWU
 J+uUwiUoBjJ7EHGsopwQ0XlCBh6dIxce6/dg3YdaZeOjYNOSvBDpTjhR18LdT0iVsJlc
 3brHdw4YQycgeQquG+KZVBrLRifan63jiGWv+OCsyEhBHUNYHCa6vjcl1105eflbb2Ga
 VwubIXUZEmXxqt8CuffQrsFmkLh4LuoOMs1vVtAN8iAH07iSNSGuEODnbKfmvjBjgdU5
 pYYg==
X-Gm-Message-State: ANhLgQ0hLs/tWdK6+M8eQFowS/PVSjWJNHi4C1PpQa9JtyftP2mXpch1
 yja9vuPpif9s7LiFYd/InDotHMxz+HlLnAa/ga8=
X-Google-Smtp-Source: ADFU+vugBds0wHIHb4KJkboWLv/vbp7it5JCNDqsJZvbVtaAOerRQCG+rrrs1+3cbk0LmsU+hxmOQGGYeuAdbANPCbs=
X-Received: by 2002:a9d:6c19:: with SMTP id f25mr9503023otq.371.1585321966253; 
 Fri, 27 Mar 2020 08:12:46 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <j37G_ywUw4UA7J2iEXurAk8Vq-QA3toUz3sakqEiYHqbpqF1DEK0riorbuZW_UkMCkNS-KKCDNPec7ogpchdg8hYPjPh_gzAGwfbY72e_p4=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Fri, 27 Mar 2020 16:12:33 +0100
Message-ID: <CAPv7TjbQ1WLxDJdufTwYttXz0asdBjAcCTDiMcdvm8xfdUv6=g@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000a750d605a1d78846"
X-Mailman-Approved-At: Fri, 27 Mar 2020 15:14:34 +0000
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: Fri, 27 Mar 2020 15:12:49 -0000

--000000000000a750d605a1d78846
Content-Type: text/plain; charset="UTF-8"

Hi ZmnSCPxj,

I appreciate the input.

>Any standardness issue can be fixed by embedding it in a P2WSH / P2SH, you
can use an `OP_TRUE` `redeemScript`, for instance.

Good point. I guess the conversation I recall reading must have been about
avoiding p2sh in order to lower the tx size.

>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

I believe this is solved by inherited signalling. As long as the kickoff tx
is RBF enabled (and unconfirmed), any transaction spending it automatically
inherits its RBF status. See:
https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#Summary

>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 tx
hits the chain, you'd probably just want to "refresh" the UTXO by agreeing
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
costly 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 refresh ("insurance"), since the actual owner isn't at fault.

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 remembered
> that this alters the txid, causing the settlement tx to become invalid.
> What I am suggesting should be functionally the same (albeit less
> space-efficient): 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 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 you
> cry 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 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 not RBF-flagged).
> Thus, some portion of mempools will contain this poisoned low-fee child
> transaction and prevent the parent from being confirmed (because the
> parent+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 to
> give each participant its own attach-your-fees output that only that
> participant 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
> updating only the later stages, until the last stage is confirmable, so the
> kickoff being broadcast simply creates a "dead man walking" statechain.
> However, the implementation complexity would probably increase
> tremendously.
>
>
> Regards,
> ZmnSCPxj
>

--000000000000a750d605a1d78846
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi=C2=A0ZmnSCPxj,<div><br></div><div>I appreciate the inpu=
t.=C2=A0=C2=A0<br></div><div><br></div><div>&gt;Any standardness issue can =
be fixed by embedding it in a P2WSH / P2SH, you can use an `OP_TRUE` `redee=
mScript`, for instance.<br><div><br></div><div>Good point. I guess the conv=
ersation I recall reading must have been about avoiding p2sh in order to lo=
wer the tx size.</div><div></div><div><br></div><div>&gt;broadcast a non-RB=
F child transaction with tiny fee, so that it and its parent transaction wi=
ll be accepted into mempools but would not be replaceable</div><div><br></d=
iv><div>I believe this is solved by inherited signalling. As long as the ki=
ckoff tx is RBF enabled (and unconfirmed), any transaction spending it auto=
matically inherits its RBF status. See:=C2=A0<a>https://github.com/bitcoin/=
bips/blob/master/bip-0125.mediawiki#Summary</a><br></div><div><a><br></a></=
div><div><a>&gt;</a>The broadcasting of the kickoff simply means that the f=
irst stage cannot be easily changed</div><div><br></div><div>I see what you=
&#39;re saying. Yeah, it does ruin the stages. If the kickoff tx hits the c=
hain, you&#39;d probably just want to &quot;refresh&quot; the UTXO by agree=
ing with the statechain entity to spend it to a new statechain 2-of-2 UTXO =
on-chain, thus removing all prior owners. Ideally you&#39;d want it to be m=
ore costly to CPFP the kickoff tx than it is to refresh the UTXO, so the de=
fender is at an advantage. The statechain entity should probably pay for ev=
ery refresh (&quot;insurance&quot;), since the actual owner isn&#39;t at fa=
ult.</div><div><br></div><div>Cheers,</div><div>Ruben</div><div><br></div><=
/div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Fri, Mar 27, 2020 at 2:46 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPx=
j@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">Good morning Ruben,<br>
<br>
&gt; Hey Christian,<br>
&gt;<br>
&gt; Thanks for chiming in :)<br>
&gt;<br>
&gt; &gt;It might be worth adopting the late fee binding we have in eltoo<b=
r>
&gt;<br>
&gt; That is where my thinking originally went as well, but then I remember=
ed that this alters the txid, causing the settlement tx to become invalid. =
What I am suggesting should be functionally the same (albeit less space-eff=
icient): 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 consider=
ed for Lightning as well at some point. Do you happen to recall if there wa=
s some kind of non-standardness issue with it?<br>
<br>
Any standardness issue can be fixed by embedding it in a P2WSH / P2SH, you =
can use an `OP_TRUE` `redeemScript`, for instance.<br>
<br>
Using an `OP_TRUE` `redeemScript` would allow any third party to make you c=
ry by opportunistically spending such an output.<br>
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).<br>
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).<br>
Which I suppose is an argument for Full RBF aka ignore-the-RBF-flag-and-alw=
ays-RBF.<br>
<br>
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.<br>
<br>
--<br>
<br>
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 &quot;dead man walking&quot; statech=
ain.<br>
However, the implementation complexity would probably increase tremendously=
.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000a750d605a1d78846--