From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Ruben Somsen <rsomsen@gmail•com>
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
Date: Sat, 28 Mar 2020 02:20:33 +0000 [thread overview]
Message-ID: <YRSNEVWhWha9PJIxY-xCyNS8f85XWaD5Wk6EexcMpi_KFpm6QVr0VKO04m0qlhdE6JCVC0yFXL9dkemqz7L6QX-pJx2psJtyIzWO-9MAPC4=@protonmail.com> (raw)
In-Reply-To: <CAPv7TjbQ1WLxDJdufTwYttXz0asdBjAcCTDiMcdvm8xfdUv6=g@mail.gmail.com>
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 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.
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 statechain entity to sign an alternative to the first stage, with 0 relative locktime, that can now be a new funding transaction to anchor a (actually new, 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 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
next prev parent reply other threads:[~2020-03-28 2:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 13:52 Tom Trevethan
2020-03-26 1:20 ` ZmnSCPxj
2020-03-26 3:55 ` Albert
2020-03-26 12:36 ` Ruben Somsen
2020-03-26 17:12 ` Christian Decker
2020-03-26 17:17 ` Greg Sanders
2020-03-26 18:53 ` Ruben Somsen
2020-03-27 1:46 ` ZmnSCPxj
2020-03-27 15:12 ` Ruben Somsen
2020-03-28 2:20 ` ZmnSCPxj [this message]
2020-03-26 14:52 ` Bob McElrath
2020-03-27 17:10 ` Bob McElrath
2020-03-28 2:42 ` ZmnSCPxj
2020-03-28 17:38 ` Ruben Somsen
2020-03-28 17:42 ` Ruben Somsen
2020-03-30 1:25 ` ZmnSCPxj
2020-03-31 10:35 ` David A. Harding
2020-03-31 11:41 ` Tom Trevethan
2020-04-02 22:56 ` Tom Trevethan
2020-04-03 16:37 ` Nadav Kohen
2020-04-04 12:07 ` ZmnSCPxj
2020-04-05 14:17 ` Bob McElrath
2020-04-05 18:24 ` ZmnSCPxj
2020-04-05 21:25 ` Tom Trevethan
2020-05-07 14:54 ` Tom Trevethan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='YRSNEVWhWha9PJIxY-xCyNS8f85XWaD5Wk6EexcMpi_KFpm6QVr0VKO04m0qlhdE6JCVC0yFXL9dkemqz7L6QX-pJx2psJtyIzWO-9MAPC4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gsanders87@gmail$(echo .)com \
--cc=rsomsen@gmail$(echo .)com \
--cc=tom@commerceblock$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox