📅 Original date posted:2018-05-25
📝 Original message:While you have rescind your concern, I’d like to point out that it’s strictly a problem of SIGHASH_NOINPUT, not graftroot (or script delegation in general).
For example, we could modify graftroot. Instead of signing the (script), we require it to sign (outpoint | script). That means a graftroot signature would never be valid for more than one UTXO.
> On 24 May 2018, at 1:52 AM, Andrew Poelstra via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Wed, May 23, 2018 at 01:50:13PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>>
>> Graftroot also break blind signature schemes. Consider a protocol such as [1]
>> where some party has a bunch of UTXOs all controlled (in part) by the same
>> key X. This party produces blind signatures on receipt of new funds, and can
>> only verify the number of signatures he produces, not anything about what he
>> is signing.
>>
>> BTW, the same concern holds for SIGHASH_NOINPUT, which I'd also like to be
>> disable-able. Maybe we should extend one of ZmnSCPxj's suggestions to include
>> a free "flags" byte or two in the witness?
>>
>> (I also had the same concern about signature aggregation. It seems like it's
>> pretty hard to preserve the "one signature = at most one input" invariant of
>> Bitcoin, but I think it's important that it is preserved, at least for
>> outputs that need it.)
>>
>> Or maybe, since it appears it will require a space hit to support optional
>> graftroot anyway, we should simply not include it in a proposal for Taproot,
>> since there would be no opportunity cost (in blockchain efficiency) to doing
>> it later.
>>
>> [1] https://github.com/apoelstra/scriptless-scripts/pull/1
>>
>
> On further thought, I rescind this concern (ditto for SIGHASH_NOINPUT) (but
> not for aggregate sigs, they still interact badly with blind signatures).
>
> As long as graftroot (and NOINPUT) sigs commit to the public key, it is
> possible for a server to have unique keys for every output, even while
> retaining the same private key, and thereby ensure that "one sig can spend
> only one output" holds. To do this, suppose the server has a BIP32 xpubkey
> (xG, cc). A blind signer using the private key x can be made to sign not
> only for xG, but also for any publicly-derived child keys of (xG, cc).
>
> Here is a simple scheme that does this:
>
> 1. Signer provides a nonce R = kG
>
> 2. Challenger computes bip32 tweak h, chooses blinders alpha and beta,
> and computes:
> R' = R + alpha*G + beta*P
> e = H(P + hG || R' || tx)
> e' = e + beta
> and sends e' to the signer.
>
> 3. Signer replies with s = k + xe' (= k + beta*x + (x + h)e - he)
>
> 4. Challenger unblinds this as s' = s + alpha + he
>
> (This blind signature scheme is vulnerable to Wagner's attack, though see
> Schnorr 2004 [1] for mitigations that are perfectly compatible with this
> modified BIP32ish scheme.)
>
> I'm unsure whether key-prefixing is _actually_ necessary for this, but it
> makes the security argument much clearer since the messagehash contains
> some data which can be made unique per-utxo and is committed in the chain.
>
>
> Andrew
>
>
> [1] http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8ECEF929559865FD68D1D873555D18FE?doi=10.1.1.68.9836&rep=rep1&type=pdf
>
>
> --
> Andrew Poelstra
> Mathematics Department, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> "A goose alone, I suppose, can know the loneliness of geese
> who can never find their peace,
> whether north or south or west or east"
> --Joanna Newsom
>
> _______________________________________________
> 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:12:25
in reply to nevent1q…24ux
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Seen on
wss://relay.noswhere.comPublished at
2023-06-07 18:12:25Event JSON
{
"id": "d4e9b2dab42e21093525d482fe411a99a06b04589671badf1a7077d7c157f64b",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686161545,
"kind": 1,
"tags": [
[
"e",
"e26b3d683cd7b5bec12686847cb6e45848c3e2dbd7f6b99e59a94b1bc41269f6",
"",
"root"
],
[
"e",
"d98f1e64a5872f1b9304a5fc34e4845db4b761c4ec241d7723557ed0315cc46b",
"",
"reply"
],
[
"p",
"ee55eb03423bd4db01d5c92ad434d52c602d9da1de37ed37cc5bf7d2a13a4cab"
]
],
"content": "📅 Original date posted:2018-05-25\n📝 Original message:While you have rescind your concern, I’d like to point out that it’s strictly a problem of SIGHASH_NOINPUT, not graftroot (or script delegation in general).\n\nFor example, we could modify graftroot. Instead of signing the (script), we require it to sign (outpoint | script). That means a graftroot signature would never be valid for more than one UTXO.\n\n\u003e On 24 May 2018, at 1:52 AM, Andrew Poelstra via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e On Wed, May 23, 2018 at 01:50:13PM +0000, Andrew Poelstra via bitcoin-dev wrote:\n\u003e\u003e \n\u003e\u003e Graftroot also break blind signature schemes. Consider a protocol such as [1]\n\u003e\u003e where some party has a bunch of UTXOs all controlled (in part) by the same\n\u003e\u003e key X. This party produces blind signatures on receipt of new funds, and can\n\u003e\u003e only verify the number of signatures he produces, not anything about what he\n\u003e\u003e is signing.\n\u003e\u003e \n\u003e\u003e BTW, the same concern holds for SIGHASH_NOINPUT, which I'd also like to be\n\u003e\u003e disable-able. Maybe we should extend one of ZmnSCPxj's suggestions to include\n\u003e\u003e a free \"flags\" byte or two in the witness?\n\u003e\u003e \n\u003e\u003e (I also had the same concern about signature aggregation. It seems like it's\n\u003e\u003e pretty hard to preserve the \"one signature = at most one input\" invariant of\n\u003e\u003e Bitcoin, but I think it's important that it is preserved, at least for\n\u003e\u003e outputs that need it.)\n\u003e\u003e \n\u003e\u003e Or maybe, since it appears it will require a space hit to support optional\n\u003e\u003e graftroot anyway, we should simply not include it in a proposal for Taproot,\n\u003e\u003e since there would be no opportunity cost (in blockchain efficiency) to doing\n\u003e\u003e it later.\n\u003e\u003e \n\u003e\u003e [1] https://github.com/apoelstra/scriptless-scripts/pull/1 \n\u003e\u003e \n\u003e \n\u003e On further thought, I rescind this concern (ditto for SIGHASH_NOINPUT) (but\n\u003e not for aggregate sigs, they still interact badly with blind signatures).\n\u003e \n\u003e As long as graftroot (and NOINPUT) sigs commit to the public key, it is\n\u003e possible for a server to have unique keys for every output, even while\n\u003e retaining the same private key, and thereby ensure that \"one sig can spend\n\u003e only one output\" holds. To do this, suppose the server has a BIP32 xpubkey\n\u003e (xG, cc). A blind signer using the private key x can be made to sign not\n\u003e only for xG, but also for any publicly-derived child keys of (xG, cc).\n\u003e \n\u003e Here is a simple scheme that does this:\n\u003e \n\u003e 1. Signer provides a nonce R = kG\n\u003e \n\u003e 2. Challenger computes bip32 tweak h, chooses blinders alpha and beta,\n\u003e and computes:\n\u003e R' = R + alpha*G + beta*P\n\u003e e = H(P + hG || R' || tx)\n\u003e e' = e + beta\n\u003e and sends e' to the signer.\n\u003e \n\u003e 3. Signer replies with s = k + xe' (= k + beta*x + (x + h)e - he)\n\u003e \n\u003e 4. Challenger unblinds this as s' = s + alpha + he\n\u003e \n\u003e (This blind signature scheme is vulnerable to Wagner's attack, though see\n\u003e Schnorr 2004 [1] for mitigations that are perfectly compatible with this\n\u003e modified BIP32ish scheme.)\n\u003e \n\u003e I'm unsure whether key-prefixing is _actually_ necessary for this, but it\n\u003e makes the security argument much clearer since the messagehash contains\n\u003e some data which can be made unique per-utxo and is committed in the chain.\n\u003e \n\u003e \n\u003e Andrew\n\u003e \n\u003e \n\u003e [1] http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8ECEF929559865FD68D1D873555D18FE?doi=10.1.1.68.9836\u0026rep=rep1\u0026type=pdf\n\u003e \n\u003e \n\u003e -- \n\u003e Andrew Poelstra\n\u003e Mathematics Department, Blockstream\n\u003e Email: apoelstra at wpsoftware.net\n\u003e Web: https://www.wpsoftware.net/andrew\n\u003e \n\u003e \"A goose alone, I suppose, can know the loneliness of geese\n\u003e who can never find their peace,\n\u003e whether north or south or west or east\"\n\u003e --Joanna Newsom\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": "63b73372a23aead0f82a1c625b24b08eebb08d65de58b9417190c75c601f0af37be97e4fde09a010da999a52f84cd42258a91a0427eb8f9e48bcf0915a1578c6"
}