📅 Original date posted:2018-11-21
📝 Original message:If we sign the txids of all inputs, we should also explicitly commit to their values. Only this could fully eliminate any possible way to lie about input value to hardware wallets
> Does it make sense to keep SIGHASH_NONE?
SIGHASH_NONE should be kept. ANYONECANPAY|NONE allows donation of dust UTXOs to miners
> I think NONE without NOFEE doesn't make much sense…….
We might refuse to sign weird combinations like NOFEE|ALLINPUT|ALLOUTPUT. But to keep the consensus logic simple, we should just validate it as usual.
> OP_MASK seems a bit complicated to me. …...
Yes, it looks complicated to me, and it improves security only in some avoidable edge cases in SIGHASH_NOINPUT:
The common case: the exact masked script or address is reused. OP_MASK can’t prevent signature replay since the masked script is the same.
The avoidable case: the same public key is reused in different script templates. OP_MASK may prevent signature replay is the masked script is not the same.
The latter case is totally avoidable since one could and should use a different public key for different script.
It could be made much simpler as NOINPUT with/without SCRIPT. This again is only helpful in the avoidable case above, but it doesn’t bring too much complexity.
> I don't have a reason why, but committing to the scriptCode feels to me like it reduces the "hackiness" of NOINPUT a lot.
OP_MASK is designed to preserve the hackiness, while provide some sort of replay protection (only in avoidable cases). However, I’m not sure who would actually need NOINPUT with KNOWNSCRIPT
> On 21 Nov 2018, at 4:29 AM, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Mon, Nov 19, 2018 at 02:37:57PM -0800, Pieter Wuille via bitcoin-dev wrote:
>> Here is a combined proposal:
>> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
>> and SIGHASH_SCRIPTMASK.
>> * A new opcode OP_MASK is added, which acts as a NOP during execution.
>> * The sighash is computed like in BIP143, but:
>> * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
>> the subsequent opcode/push is removed.
>> * The scriptPubKey being spent is added to the sighash, unless
>> SIGHASH_SCRIPTMASK is set.
>> * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is set.
>> * hashPrevouts, hashSequence, and outpoint are set to null when
>> SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).
>
> Current flags are {ALL, NONE, SINGLE} and ANYONECANPAY, and the BIP143
> tx digest consists of the hash of:
>
> 1 nVersion
> 4 outpoint
> 5 input scriptCode
> 6 input's outpoint value
> 7 input's nSeq
> 9 nLocktime
> 10 sighash
>
> 2 hashPrevOuts (commits to 4,5,6; unless ANYONECANPAY)
> 3 hashSequence (commits to 7; only if ALL and not ANYONECANPAY)
> 8 hashOutputs
> - NONE: 0
> - SINGLE: {value,scriptPubKey} for corresponding output
> - otherwise: {value,scriptPubKey} for all outputs
>
> The fee is committed to by hashPrevOuts and hashOutputs, which means
> NOFEE is only potentially useful if ANYONECANPAY or NONE or SINGLE is set.
>
> For NOINPUT, (2),(3),(4) are cleared, and SCRIPTMASK (which munges (5))
> is only useful given NOINPUT, since (4) indirectly commits to (5).
>
> Given this implementation, NOINPUT effectively implies ANYONECANPAY,
> I think. (I think that is also true of BIP 118's NOINPUT spec)
>
> Does it make sense to treat this as two classes of options, affecting
> the input and output side:
>
> output: (pick one, using bits 0,1)
> * NONE -- don't care where the money goes
> * SINGLE -- want this output
> * ALL -- want exactly this set of outputs
>
> input: (pick one, using bits 4,5)
> * PARTIALSCRIPT -- spending from some tx with roughly this script (and
> maybe others; SCRIPTMASK|NOINPUT|ANYONECANPAY)
> * KNOWNSCRIPT -- spending from some tx with exactly this script (and
> maybe others; NOINPUT|ANYONECANPAY)
> * KNOWNTX -- spending from this tx (and maybe others; ANYONECANPAY)
> * ALL_INPUTS -- spending from exactly these txes
>
> combo: (flag, bit 6)
> * NOFEE -- don't commit to the fee
>
> I think NONE without NOFEE doesn't make much sense, and
> NOFEE|ALL|ALL_INPUTS would also be pretty weird. Might make sense to
> warn/error on signing when asking for those combinations, and maybe even
> to fail on validating them.
>
> (Does it make sense to keep SIGHASH_NONE? I guess SIGHASH_NONE|ALL_INPUTS
> could be useful if you just use sigs on one of the other inputs to commit
> to a useful output)
>
> FWIW, OP_MASK seems a bit complicated to me. How would you mask a script
> that looks like:
>
> OP_MASK IF <p> ENDIF <q> ...
>
> or:
>
> IF OP_MASK ENDIF <p> ...
>
> I guess if you make the rule be "for every OP_MASK in scriptCode the
> *immediately* subsequent opcode/push is removed (if present)" it would
> be fine though -- that would make OP_MASK in both the above not have
> any effect. (Maybe a more explicit name like "MASK_PUSH_FOR_SIGHASH"
> or something might be good?)
>
> I don't have a reason why, but committing to the scriptCode feels to me
> like it reduces the "hackiness" of NOINPUT a lot.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Johnson Lau [ARCHIVE] /
npub1fy…p2mv9
2023-06-07 18:15:16
in reply to nevent1q…kj8f
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Published at
2023-06-07 18:15:16Event JSON
{
"id": "4cc43ee08b77ea303539271cd904dc7d295d6dfb3e72ae1c50267476198e04bd",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686161716,
"kind": 1,
"tags": [
[
"e",
"1bd7a781e2cfd166ff9a33b1bac5fde47a675384fad1a2f913ed308d62699fea",
"",
"root"
],
[
"e",
"aae6845216e0b6f0e24820d9301fb94f1e0ad65484f2f7ff341b788104f2952b",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2018-11-21\n📝 Original message:If we sign the txids of all inputs, we should also explicitly commit to their values. Only this could fully eliminate any possible way to lie about input value to hardware wallets\n\n\u003e Does it make sense to keep SIGHASH_NONE?\nSIGHASH_NONE should be kept. ANYONECANPAY|NONE allows donation of dust UTXOs to miners\n\n\u003e I think NONE without NOFEE doesn't make much sense…….\nWe might refuse to sign weird combinations like NOFEE|ALLINPUT|ALLOUTPUT. But to keep the consensus logic simple, we should just validate it as usual.\n\n\u003e OP_MASK seems a bit complicated to me. …...\nYes, it looks complicated to me, and it improves security only in some avoidable edge cases in SIGHASH_NOINPUT:\n\nThe common case: the exact masked script or address is reused. OP_MASK can’t prevent signature replay since the masked script is the same.\n\nThe avoidable case: the same public key is reused in different script templates. OP_MASK may prevent signature replay is the masked script is not the same.\n\nThe latter case is totally avoidable since one could and should use a different public key for different script.\n\nIt could be made much simpler as NOINPUT with/without SCRIPT. This again is only helpful in the avoidable case above, but it doesn’t bring too much complexity.\n\n\u003e I don't have a reason why, but committing to the scriptCode feels to me like it reduces the \"hackiness\" of NOINPUT a lot.\nOP_MASK is designed to preserve the hackiness, while provide some sort of replay protection (only in avoidable cases). However, I’m not sure who would actually need NOINPUT with KNOWNSCRIPT\n\n\u003e On 21 Nov 2018, at 4:29 AM, Anthony Towns via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e On Mon, Nov 19, 2018 at 02:37:57PM -0800, Pieter Wuille via bitcoin-dev wrote:\n\u003e\u003e Here is a combined proposal:\n\u003e\u003e * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,\n\u003e\u003e and SIGHASH_SCRIPTMASK.\n\u003e\u003e * A new opcode OP_MASK is added, which acts as a NOP during execution.\n\u003e\u003e * The sighash is computed like in BIP143, but:\n\u003e\u003e * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode\n\u003e\u003e the subsequent opcode/push is removed.\n\u003e\u003e * The scriptPubKey being spent is added to the sighash, unless\n\u003e\u003e SIGHASH_SCRIPTMASK is set.\n\u003e\u003e * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is set.\n\u003e\u003e * hashPrevouts, hashSequence, and outpoint are set to null when\n\u003e\u003e SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).\n\u003e \n\u003e Current flags are {ALL, NONE, SINGLE} and ANYONECANPAY, and the BIP143\n\u003e tx digest consists of the hash of:\n\u003e \n\u003e 1 nVersion\n\u003e 4 outpoint\n\u003e 5 input scriptCode\n\u003e 6 input's outpoint value\n\u003e 7 input's nSeq\n\u003e 9 nLocktime\n\u003e 10 sighash\n\u003e \n\u003e 2 hashPrevOuts (commits to 4,5,6; unless ANYONECANPAY)\n\u003e 3 hashSequence (commits to 7; only if ALL and not ANYONECANPAY)\n\u003e 8 hashOutputs\n\u003e - NONE: 0\n\u003e - SINGLE: {value,scriptPubKey} for corresponding output\n\u003e - otherwise: {value,scriptPubKey} for all outputs\n\u003e \n\u003e The fee is committed to by hashPrevOuts and hashOutputs, which means\n\u003e NOFEE is only potentially useful if ANYONECANPAY or NONE or SINGLE is set.\n\u003e \n\u003e For NOINPUT, (2),(3),(4) are cleared, and SCRIPTMASK (which munges (5))\n\u003e is only useful given NOINPUT, since (4) indirectly commits to (5). \n\u003e \n\u003e Given this implementation, NOINPUT effectively implies ANYONECANPAY,\n\u003e I think. (I think that is also true of BIP 118's NOINPUT spec)\n\u003e \n\u003e Does it make sense to treat this as two classes of options, affecting\n\u003e the input and output side:\n\u003e \n\u003e output: (pick one, using bits 0,1)\n\u003e * NONE -- don't care where the money goes\n\u003e * SINGLE -- want this output\n\u003e * ALL -- want exactly this set of outputs\n\u003e \n\u003e input: (pick one, using bits 4,5)\n\u003e * PARTIALSCRIPT -- spending from some tx with roughly this script (and\n\u003e maybe others; SCRIPTMASK|NOINPUT|ANYONECANPAY)\n\u003e * KNOWNSCRIPT -- spending from some tx with exactly this script (and\n\u003e maybe others; NOINPUT|ANYONECANPAY)\n\u003e * KNOWNTX -- spending from this tx (and maybe others; ANYONECANPAY)\n\u003e * ALL_INPUTS -- spending from exactly these txes\n\u003e \n\u003e combo: (flag, bit 6)\n\u003e * NOFEE -- don't commit to the fee\n\u003e \n\u003e I think NONE without NOFEE doesn't make much sense, and\n\u003e NOFEE|ALL|ALL_INPUTS would also be pretty weird. Might make sense to\n\u003e warn/error on signing when asking for those combinations, and maybe even\n\u003e to fail on validating them.\n\u003e \n\u003e (Does it make sense to keep SIGHASH_NONE? I guess SIGHASH_NONE|ALL_INPUTS\n\u003e could be useful if you just use sigs on one of the other inputs to commit\n\u003e to a useful output)\n\u003e \n\u003e FWIW, OP_MASK seems a bit complicated to me. How would you mask a script\n\u003e that looks like:\n\u003e \n\u003e OP_MASK IF \u003cp\u003e ENDIF \u003cq\u003e ...\n\u003e \n\u003e or:\n\u003e \n\u003e IF OP_MASK ENDIF \u003cp\u003e ...\n\u003e \n\u003e I guess if you make the rule be \"for every OP_MASK in scriptCode the\n\u003e *immediately* subsequent opcode/push is removed (if present)\" it would\n\u003e be fine though -- that would make OP_MASK in both the above not have\n\u003e any effect. (Maybe a more explicit name like \"MASK_PUSH_FOR_SIGHASH\"\n\u003e or something might be good?)\n\u003e \n\u003e I don't have a reason why, but committing to the scriptCode feels to me\n\u003e like it reduces the \"hackiness\" of NOINPUT a lot.\n\u003e \n\u003e Cheers,\n\u003e aj\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "7922587f38b3707963e83f185f9c916cf23dc1ea5d35a8cd3a401271639eaa6efc4e013ab2fe31f4a101c2856dabf1a6e39ce1c5550f3ac3e6283fd718090fad"
}