Date: Fri, 27 Mar 2020 01:46:15 +0000
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
Precedence: list

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