64 Byte Transactions - BitMEX Blog \ stacker news ~bitcoin

pull down to refresh

64 Byte Transactions - BitMEX Blog www.bitmex.com/blog/64-Byte-Transactions

607 sats \ 6 comments \ @Scoresby 7h bitcoin

BitMex Research has been going through the four vulnerabilities that the Great Consensus Cleanup would fix, and their most recent article is about the 64-byte transaction problem.

It's a pretty complicated problem that leads to an attack where someone could try to trick another person using an SPV node into believing they have been paid by hiding one transaction id inside another fake transaction id.

This attack does not seem that bad. The setup is extremely complicated, perhaps with a setup transaction with thousands of inputs and perhaps burning thousands of dollars, just to give you entropy in deciding the value of the output. Besides, SPV wallets are not that popular anymore anyway. People who expect to receive large value payments tend to know they need a full node to verify incoming payments. However, this attack is still feasible to pull off, especially if the tools are built to conduct it and therefore it's worth being aware of and to try to mitigate the risks here.

This new rule would leave Bitcoin with a rather quirky new rule, where 63 byte transactions and 65 byte transactions are ok, but 64 byte transactions would be banned. But it may be better to keen the bans on transactions as minimal as possible.

The fix for this problem that is proposed by the Great Consensus Cleanup makes me sad: it just bans transactions of exactly 64 bytes in size. This is an inelegant way to go about things (however, I freely acknowledge it is a hard problem to fix and there is likely not a better solution -- not casting shade on the Great Consensus Cleanup).

Achieving such a transaction involves quite a bit of complex set up and is preventable without a soft fork by updating SPV wallets to do a few more checks.

Because the attacks that come from this problem are of such low severity, I wonder if we aren't better just living with the problem.

view all related items

508 sats \ 1 reply \ @Murch 6h

Note that BIP 54 does not talk about transactions of 64 bytes, but rather proposes to forbid “Transactions whose witness-stripped serialized size is exactly 64 bytes”.

Still, perhaps I can alleviate you of some of your sadness: it seems very unlikely that anyone will come up with useful stripped transactions of 64-byte size.

Bitcoin transactions have to have at least one input, at least one output, and the header bytes. Without the witness data that leaves us with:

Header

version: 4 byte
locktime: 4 byte
input count: 1+ bytes
output count: 1+ bytes

Usually 10 bytes, unless you have a lot of inputs or outputs.

Input

outpoint:
- txid: 32 bytes
- vout: 4 bytes
input script length: 1+ bytes
input script: 0+ bytes
sequence: 4 bytes

In sum that’s at least 41 bytes, and that is for a transaction with an empty input script.

Output

amount: 8 bytes
output script length: 1+ bytes
output script: 0+ bytes

At least 9 bytes, even with an empty output script.

In Sum

So, a transaction with an empty input script and an empty output script already puts you at 60 bytes, and that means that you’d have to distribute a total of four bytes into input script and/or output script to land at exactly 64 bytes.

The only standard types of transactions that I can think of that would be affected have a single native segwit input (who have empty input scripts), and either a single P2A output (which has a 4 byte output script) or an OP_RETURN output with a 2-byte payload. The former transaction would pay all its money to fees or make it up for grabs per an anyone-can-spend anchor. The latter would pay all its money to fees, or burn it per the OP_RETURN output. Neither seems seem useful to me, but either could evade the block by simply increasing the payload by one byte (e.g., introducing another standard pattern for P2A with three bytes, if it is used frequently). So, we would fix a consensus bug at potentially introducing a 1-byte penalty to a couple tx patterns that don’t seem useful at this time.

0 sats \ 0 replies \ @Scoresby OP 6h

Thanks for the clarification and the info! This does alleviate my sadness a little.

However, I still don't see why it is better to introduce the specific block validation rule "Transactions whose witness-stripped serialized size is exactly 64 bytes are invalid" than to try to find a client-based solution that doesn't change add to block validation rules.

In general, I really like the GCC, and I'm hopeful that we will see progress on that front. Of all the various soft fork proposals I've heard about since Taproot, GCC is the most interesting to me.

102 sats \ 1 reply \ @SimpleStacker 7h

Live with it. This issue seems to highlight the difference between the technical background folks and the economic background folks. This seems like something better off solved with a market based solution (i.e. make sure you're running full node if you're accepting 64 byte txs) than a technical one.

0 sats \ 0 replies \ @Scoresby OP 7h

yes. that's an interesting way of putting it. It does seem like one could balance the trade-offs here and come up with a solution that works without banning transactions of one specific size.

0 sats \ 1 reply \ @winteryeti 7h

Agreed. Doesn't seem like they are addressing the real cause, just a quick band-aid to block the pattern which can be changed.

0 sats \ 0 replies \ @Scoresby OP 7h

I don't think "the pattern can be changed" -- it's a problem that is really specific to 64 byte transactions. But I do think it might be worth just living with the problem instead of having a weird rule that bans 64 byte transactions but allows 63 byte transactions and 65 byte transactions.