This weird trick lets you replay the same signature two or more times on mainnet
11.7k sats \ 8 comments \ @supertestnet_phone 25 Feb 2023 bitcoin
Take a close look at these two bitcoin transactions:
https://mempool.space/tx/6a058ac5f1d0f0a353ed479dbd8a85c3e3055bd8974502ba32dcc6f8245847c6
https://mempool.space/tx/475eedbc136a8f4be61f348c3124960c2cf93fb03495d1589dbf38f1855c97dc
They both use the same signature to send sats out of the same bitcoin address, but in two different transactions.
That's normally not possible in bitcoin transactions. Signatures are supposed to be valid for one transaction only. Signature replayability is normally enabled by sighash_anyprevout, a soft fork which isn't live on bitcoin yet. E.g. last month Anthony Towns demonstrated it on signet, where sighash_anyprevout is already active:
https://mempool.space/signet/tx/2ba88276dee53abdff23258b7f5b8d41005c69f03dc9a5bb9d5cb7b7f41f3e45
https://mempool.space/signet/tx/ef8b3351def1163da97f51b8d2cba53c9671dfbd69ae4b1278506b9282bfbdea
But an important point is that sighash_anyprevout is a soft fork, meaning it's backward compatible, meaning you can technically already do it today, it's just not safe.
To do this on mainnet, Vman and I (mostly him) used a trick called pubkey derivation. A typical bitcoin address is the hash of a public key. To spend from it, you have to present the public key and compute a signature that proves you know the private key. But to accomplish this trick, Vman made a special bitcoin address that is the hash of a signature instead. To spend from this address, you have to provide the right signature and then compute a public key that makes the signature valid.
But this trick is not as good as sighash_anyprevout. Pubkey derivation is unsafe to rely on in mainnet transactions because replaying the signature in this manner turns the bitcoin address into an anyone-can-spend address. Sighash_anyprevout would let us replay signatures safely.
One of the cool things you can do with replayable signatures (the safe kind) is make a covenant. A signature normally commits to a transaction's outputs. If you can replay a signature, that ordinarily means you have to send money to the same outputs again. And such a restriction is a type of covenant, which enables many new features on bitcoin, e.g. see utxos.org for examples.
Unfortunately, the signature replayability that works on bitcoin today does not enable covenants. Outputs are not committed to when a signature lacks a fixed pubkey. Without that, it's just an anyone-can-spend address, and you can compute a pubkey that makes the sig valid no matter where the funds end up.
The point is: it's a cool trick! And it means covenants are already very close to a reality in bitcoin. We just need a tiny little softfork that makes signature replayability safe and then boom, bitcoin will have covenants and many new features that use them, like better vaults, better spacechains, and eltoo. Let's do it! Merge sighash_anyprevout over from signet to mainnet! Ask a dev to help you try it out today.
write
preview
related posts
2683 sats \ 0 replies \ @VzxPLnHqr 25 Feb 2023
In case anyone would like to see the reckless code that constructed these weird transactions, here you go: https://gist.github.com/VzxPLnHqr/acc4fd4ee399196e7723a7d36a90834b#file-pay2sig-sc
Building little custom transactions like this has taught me a lot and made it clearer as to why some constructions are not possible (such as due to a hash-cycle), or possible but insecure, such as the weird ones presented here.
Maybe somebody will come along and figure out how to derive the next public key such that they can sweep the remaining sats in that address!
reply
913 sats \ 1 reply \ @0260378aef 25 Feb 2023
Worth crediting arubi (aka fivepiece) for this basic idea (one of several similar interesting ideas he came up with a few years back): https://gist.github.com/fivepiece/f39de978f5fb94b08b54f33db5e42d9a
Interesting and fun example!
(oh i see the code does credit fivepiece so all good)
The idea of pubkey recovery used to make covenants is discussed here: https://arxiv.org/pdf/2006.16714.pdf Section 4.1-4.4 has an interesting summary of how it could work and why it doesn't work (circular reference problem), as well as then discussing a bit other possible solutions including ANYPREVOUT as you mention.
reply
416 sats \ 0 replies \ @VzxPLnHqr 25 Feb 2023
Thanks, yes I do have the link to arubi/fivepiece's gist in the code, but I should have made it more prominent, especially in my earlier comment here.
Thanks for the other pdf link as well.
reply
51 sats \ 2 replies \ @022fbc9cef 25 Feb 2023
Oh no, covenants? So good bye fungibility and welcome censorship? I am quite opposed to the idea of limiting where one can send from a given address. This would 100% lead to exchanges embedding whitelists with withdrawals and if those are recursive, bitcoin is screwed.
reply
610 sats \ 0 replies \ @supertestnet_phone OP 25 Feb 2023
Exchanges already have whitelists
I don't think covenants make them worse
The recipient creates the covenant, not the sender, so just don't create a covenant that restricts how you can spend your money
If your concern is that exchanges might require you to create a covenant address that matches their template, otherwise they won't let you withdraw, they can already do this thing that seems equivalent:
Exchanges can -- right now -- only let you withdraw to a 2 of 2 where they control one key
Then they'd get to veto any future expenditure you try to make
Are covenants worse than that?
Even if they are, just fall back on this: don't make a covenant encumbered address and exchanges can't harm you (except by refusing to send money to you, which they can also already do)
reply
0 sats \ 0 replies \ @VzxPLnHqr 25 Feb 2023
The same concern can also work in reverse, against the exchanges. For example, you could choose not to deposit to an exchange unless they prove to you that the deposit address commits to a covenant which meets your criteria.
Covenants, as a concept, are not inherently bad. There are good uses, and bad uses, and the judgment of good and bad is subjective.
Prudent bitcoiners should always request more information about where they are about to send their sats before they send them.
We already have phrases like:
  1. don't trust, verify
  2. not your node not your code
  3. not your keys not your coins
Maybe we need one for covenant-like transactions, so people remember to assess them before spending, but this is pretty much already handled by #1 above.
Just my 2 sats, and I reserve the right to change my opinion on the subject (so this comment is not a covenant...or is it? because the edit window on SN will close for it ..oh well).
reply
0 sats \ 1 reply \ @WeAreAllSatoshi 25 Feb 2023
This weird trick
What is this, buzzfeed? Lol interesting read though, thanks for sharing
reply
3 sats \ 0 replies \ @super_testnet 25 Feb 2023
lol yes, maybe stacker news should change its tagline to "like buzzfeed but it pays you bitcoin (bankers hate him!)"
reply