Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 25/07/2025, 14:25:41 UTC
⭐ Merited by stwenhao (1)
This is how a signed message looks like:

Code:
SZ
        // TX version
 4 VER  01000000
        // SHA256 of all inputs UTXOs
32 HPO  b0a785c30ed3f3a97b7deefb932db2f78f8913617d39934ccb49c36f355ec15d
        // SHA256 of all inputs nSequence
32 HS   e8421900817cfe6d5377a71cb681de004f52792ef448ff3c41d15a233e230b0a
        // UTXO of the input we're signing
32 UTXO 01280bc5682e0cbe78108912437ab583daa49a8fe66e995001a22a44aec2a3ab
 4 VOUT 05000000
        // redeem script
41 RSCR 288201379f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac
        // output amount
 8 AMNT 18e4030000000000
        // nSequence of signed input
 4 NSEQ ffffffff
        // SHA256 of all the outputs
32   OH e7b3e254a82a35a3f9fe591f002e4ae01c88a7eed71d177eaecddaa15167dfe0
        // TX lockTime
 4   LT 00000000
        // signature type (HASH_ALL)
 4  SIG 01000000

As you can see, the nSequence of all the inputs are hashed together and are used right from the first message block.

The problem is when the SHA256(outputs) needs to be updated, as it also indirectly requires the 3rd message block to be SHA256'ed as well.