Ruben Somsen [ARCHIVE] on Nostr: 📅 Original date posted:2021-05-11 📝 Original message:Hi Antoine, Thanks for ...
📅 Original date posted:2021-05-11
📝 Original message: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/20210511/15b9d16c/attachment-0001.html>;
📝 Original message: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/20210511/15b9d16c/attachment-0001.html>;