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 #0This 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
. Now, I will get my reward just fine (since my output's signed) but the actor gets 100x bigger reward from whale input.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.