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 <[email protected]> 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
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
