Quote from: stwenhao on Today at 05:50:03 PM

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. 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.

kTimesG

Posts

Merits