Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2021-05-12 📝 Original message:Hi Ruben, Thanks for ...
📅 Original date posted:2021-05-12
📝 Original message:Hi Ruben,
Thanks for raising awareness about spacechains/BMM, I didn't have knowledge
it was relying on a fee-based English auction to mine side-blocks. IIUC,
it's another type of dynamic membership
multi-party signature where parties are block-signing with a fee proposal
instead of a PoW ? Though you still assume mainchain miners aren't
colluding and blindly applying the RBF policy
Effectively, if you can block RBF by opting-out, parties are not competing
anymore on feerate but on gaining propagation advantage in the tx-relay
topology. And such advantage is quite easy to
gain with a modified client, mass-connecting and not enforcing inventory
broadcast interval timers.
> As it stands, this bug gets in the way of being able to deploy
spacechains.
Noted, yet another good-point to transition towards full-rbf!
Cheers,
Antoine
Le mar. 11 mai 2021 à 17:16, Ruben Somsen <rsomsen at gmail.com> a écrit :
> Hi Antoine,
>
> Thanks for bringing this up.
>
> It seems spacechains[0] are impacted by this. Simply explained, the idea
> is to allow for fee-bidding Blind Merged Mining[1] by creating one
> transaction for each block, to which anyone can attach a block hash. The
> preferred mechanism utilizes sighash_anyprevout and is not affected, but
> there is also a practical variant that could be used without requiring the
> anyprevout soft fork, which unfortunately does seem to be impacted. Here's
> a brief description:
>
> TX0:
>
> input 0
>
> output 1a*
> output 1b
>
> TX1:
>
> input 1a*
>
> output 2a**
> output 2b
>
> TX2:
>
> input 2a**
>
> output 3a***
> output 3b
>
> Etc.
>
> Every TX has two outputs, one of which ("a") is used as the input for the
> next TX (these are pre-signed and act as a covenant), resulting in a
> continuous chain of transactions. The other output ("b") can be spent by
> anyone, and is meant to CPFP the parent TX and, importantly, be RBF
> replaceable by anyone. This allows whoever pays the highest CPFP fee to
> "win the RBF auction" and attach their TX to the output, containing the
> winning spacechain block hash.
>
> With inherited signalling, this works because each pre-signed TX is RBF
> enabled, so each CPFP transaction inherits RBF as well. But if inherited
> signalling does not function, the first person who makes a CPFP transaction
> can simply disable RBF and win the auction, thus breaking the intended
> fee-bidding mechanism.
>
> You can also find a diagram in this spacechains presentation (timestamped
> link): https://youtu.be/N2ow4Q34Jeg?t=2555
>
> As it stands, this bug gets in the way of being able to deploy spacechains.
>
> -- Ruben Somsen
>
>
>
> [0]
> https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302
>
> [1] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5
>
>
>
>
> On Sun, May 9, 2021 at 10:41 AM darosior via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Antoine,
>>
>>
>> Thank you for the disclosure.
>>
>>
>>
>> > * Onchain DLC/Coinswap/Vault : Those contract protocols have also
>> multiple stages of execution with time-sensitive transactions opening the
>> way to pinning attacks. Those protocols being non-deployed or in early
>> phase, I would recommend that any in-protocol competing transactions
>> explicitly signal RBF.
>>
>>
>> For what it's worth, Revault isn't vulnerable as all transactions signal
>> RBF and there is no way to sneak a non-signaling competing transaction (as
>> long as the CSV isn't matured yet).
>>
>>
>>
>> Thanks,
>>
>> Antoine (the other one)_______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210512/9045d4ec/attachment-0001.html>;
📝 Original message:Hi Ruben,
Thanks for raising awareness about spacechains/BMM, I didn't have knowledge
it was relying on a fee-based English auction to mine side-blocks. IIUC,
it's another type of dynamic membership
multi-party signature where parties are block-signing with a fee proposal
instead of a PoW ? Though you still assume mainchain miners aren't
colluding and blindly applying the RBF policy
Effectively, if you can block RBF by opting-out, parties are not competing
anymore on feerate but on gaining propagation advantage in the tx-relay
topology. And such advantage is quite easy to
gain with a modified client, mass-connecting and not enforcing inventory
broadcast interval timers.
> As it stands, this bug gets in the way of being able to deploy
spacechains.
Noted, yet another good-point to transition towards full-rbf!
Cheers,
Antoine
Le mar. 11 mai 2021 à 17:16, Ruben Somsen <rsomsen at gmail.com> a écrit :
> Hi Antoine,
>
> Thanks for bringing this up.
>
> It seems spacechains[0] are impacted by this. Simply explained, the idea
> is to allow for fee-bidding Blind Merged Mining[1] by creating one
> transaction for each block, to which anyone can attach a block hash. The
> preferred mechanism utilizes sighash_anyprevout and is not affected, but
> there is also a practical variant that could be used without requiring the
> anyprevout soft fork, which unfortunately does seem to be impacted. Here's
> a brief description:
>
> TX0:
>
> input 0
>
> output 1a*
> output 1b
>
> TX1:
>
> input 1a*
>
> output 2a**
> output 2b
>
> TX2:
>
> input 2a**
>
> output 3a***
> output 3b
>
> Etc.
>
> Every TX has two outputs, one of which ("a") is used as the input for the
> next TX (these are pre-signed and act as a covenant), resulting in a
> continuous chain of transactions. The other output ("b") can be spent by
> anyone, and is meant to CPFP the parent TX and, importantly, be RBF
> replaceable by anyone. This allows whoever pays the highest CPFP fee to
> "win the RBF auction" and attach their TX to the output, containing the
> winning spacechain block hash.
>
> With inherited signalling, this works because each pre-signed TX is RBF
> enabled, so each CPFP transaction inherits RBF as well. But if inherited
> signalling does not function, the first person who makes a CPFP transaction
> can simply disable RBF and win the auction, thus breaking the intended
> fee-bidding mechanism.
>
> You can also find a diagram in this spacechains presentation (timestamped
> link): https://youtu.be/N2ow4Q34Jeg?t=2555
>
> As it stands, this bug gets in the way of being able to deploy spacechains.
>
> -- Ruben Somsen
>
>
>
> [0]
> https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302
>
> [1] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5
>
>
>
>
> On Sun, May 9, 2021 at 10:41 AM darosior via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Antoine,
>>
>>
>> Thank you for the disclosure.
>>
>>
>>
>> > * Onchain DLC/Coinswap/Vault : Those contract protocols have also
>> multiple stages of execution with time-sensitive transactions opening the
>> way to pinning attacks. Those protocols being non-deployed or in early
>> phase, I would recommend that any in-protocol competing transactions
>> explicitly signal RBF.
>>
>>
>> For what it's worth, Revault isn't vulnerable as all transactions signal
>> RBF and there is no way to sneak a non-signaling competing transaction (as
>> long as the CSV isn't matured yet).
>>
>>
>>
>> Thanks,
>>
>> Antoine (the other one)_______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210512/9045d4ec/attachment-0001.html>;