Date: Sat, 28 Mar 2020 02:20:33 +0000
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
Precedence: list

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