Post
Topic
Board Development & Technical Discussion
Merits 5 from 2 users
Re: Proof of Work transaction puzzle, based on DER signature size
by
kTimesG
on 25/07/2025, 18:28:10 UTC
⭐ Merited by vapourminer (4) ,stwenhao (1)
Quote
since we need to compute hashSequences
For some sighashes you need it, for others you don't. Check how SIGHASH_SINGLE with SIGHASH_ANYONECANPAY is computed, based on examples.

How about this:

Inputs:
   #0 Sponsor, SIGHASH_NONE
   #1 Puzzle PoWhatever
Outputs (mutable to whatever we want)
   #0 OP_RETURN ""
   #1 Transfer

Sponsor signed:
   - input #0 and #1 prevouts (assuming SIGHASH_ANYONECANPAY was not used)
   - lockTime, TX version, and of course its own input

NOT signed by sponsor:
   - nSequence of other inputs
   - outputs

Puzzle signs with SIGHASH_SINGLE:
   - input #0 and #1 prevouts (assuming SIGHASH_ANYONECANPAY was not used)
   - lockTime, TX version, and of course its own input
   - output #1

NOT signed:
    - nSequence of other inputs (immutable, signed by sponsor)
    - output #0

This disables hashSequence and allows modifying nSequence of the puzzle input, correct?

If we also add ANYONE_CAN_PAY, wouldn't this allow to attach the grinded signature arbitrarily to other inputs? For example: let's assume this scenario:

- I'm grinding a solution for 64 bits, signed with "anyone can pay"
- a bad actor sees it in mempool, and, assuming the existence of a whale sponsor partial TX (which is impossible to know if it exists) for that same puzzle, can simply steal my signature and replace the TX

Another big problem I see with this is output #0 being left totally mutable. No one signs it or even cares whats in there. I can think of possible interferences on it.