> Op 1 jun 2026, om 19:46 heeft jeremy <[email protected]> het volgende 
> geschreven:
> 
> Esteemed Colleagues,
> As a result of some of my research on 64-byte transactions, I'd like to 
> discuss an alternative soft fork proposal that preserves the ability to 
> encode 64-byte transactions while offering protection to SPV users (who must 
> make a small patch to validate the path property).
> The rule, stated simply, is:
> A block is invalid if any Merkle Tree 64-byte preimage has the exact byte 
> structure of a minimal one-input, one-output, witness stripped transaction.
> [With the miracle of GPT,] I've drafted a relatively complete BIP for 
> discussion.

I like the idea of fixing the problem as close to the (merkle, haha) root of 
the problem. But is there a more elegant and succinct way to implement 
IsForbiddenMerkleInternalNodePreimage64?

Otherwise I prefer to wait 80 years for a proper fix, rather than add this 
complexity to consensus code. Even if we can't have the 64 byte exception 
(which I still prefer).

After 2106, the fix can be a simple tweak to the leaf hash calculation:

 if (!hardfork) return tx.getHash().ToUint256();

// Fix Merkle tree, and drop the separate witness commitment by committing
// witness data directly in the transaction Merkle tree.
return (HashWriter{TaggedHash("TaggedWtxid")} << 
TX_WITH_WITNESS(tx)).GetSHA256();

Here's a rough sketch:
https://github.com/Sjors/bitcoin/tree/2026/06/merkle


The upgrade mechanism isn't important in this context, but I implemented the 
following rules:

1. a new header format, growing timestamp from 32 to 64 bits
  - mask one byte to use for nonce space, if we think two billion years is 
enough

2. the block version must be negative, if and only if it uses the new header 
format
  - let's the header/block deserialiser know in the first 4 bytes how long the 
header is 
  - current nodes will reject such blocks, because BIP34 deployment burned 
nVersion < 2
    - therefore it's not used for signalling or nonce grinding
  - no historical blocks have a negative version

3. new headers must have timestamp >= 2^32 
  - makes it a clean break both ways
  - maybe require old headers can't connect to a new header

- Sjors

> static bool IsForbiddenMerkleInternalNodePreimage64(const unsigned char p[64])
> {
>     // Minimal 64-byte legacy transaction shape:
>     //
>     //   4 bytes   nVersion
>     //   1 byte    vin count = 0x01
>     //   36 bytes  prevout
>     //   1 byte    scriptSig length = x
>     //   x bytes   scriptSig
>     //   4 bytes   nSequence
>     //   1 byte    vout count = 0x01
>     //   8 bytes   nValue
>     //   1 byte    scriptPubKey length = y
>     //   y bytes   scriptPubKey
>     //   4 bytes   nLockTime
>     //
>     // Since the fixed overhead is 60 bytes, x + y must equal 4.
> 
>     if (p[4] != 0x01) {
>         return false;
>     }
> 
>     const unsigned int x = p[41];
> 
>     switch (x) {
>     case 0:
>         if (p[46] != 0x01) return false;
>         if (p[55] != 0x04) return false;
>         break;
> 
>     case 1:
>         if (p[47] != 0x01) return false;
>         if (p[56] != 0x03) return false;
>         break;
> 
>     case 2:
>         if (p[48] != 0x01) return false;
>         if (p[57] != 0x02) return false;
>         break;
> 
>     case 3:
>         if (p[49] != 0x01) return false;
>         if (p[58] != 0x01) return false;
>         break;
> 
>     case 4:
>         if (p[50] != 0x01) return false;
>         if (p[59] != 0x00) return false;
>         break;
> 
>     default:
>         return false;
>     }
> 
>     const size_t value_pos = 47 + x;
>     const uint64_t raw_value = ReadLE64(p + value_pos);
> 
>     if (raw_value > 
> static_cast<uint64_t>(std::numeric_limits<int64_t>::max())) {
>         return false;
>     }
> 
>     const int64_t nValue = static_cast<int64_t>(raw_value);
> 
>     if (!MoneyRange(nValue)) {
>         return false;
>     }
> 
>     return true;
> }
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/bitcoindev/8FEEF72A-92A3-48A9-AC49-43107D17B090%40sprovoost.nl.

Reply via email to