📅 Original date posted:2018-05-23
📝 Original message:On Tue, May 22, 2018 at 11:17:42AM -0700, Pieter Wuille via bitcoin-dev wrote:
>
> Given the recent discussions about Taproot [1] and Graftroot [2], I
> was wondering if a practical deployment needs a way to explicitly
> enable or disable the Graftroot spending path. I have no strong
> reasons why this would be necessary, but I'd like to hear other
> people's thoughts.
>
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
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180523/fe3efcc5/attachment.sig>;
Andrew Poelstra [ARCHIVE] /
npub1ae…z5t04
2023-06-07 18:12:24
in reply to nevent1q…fw6g
Author Public Key
npub1ae27kq6z802dkqw4ey4dgdx493szm8dpmcm76d7vt0ma9gf6fj4svz5t04Published at
2023-06-07 18:12:24Event JSON
{
"id": "3b0f239fa981efd00844d2ce55db00e693c34099462ea0d3c3d77c6946d1f302",
"pubkey": "ee55eb03423bd4db01d5c92ad434d52c602d9da1de37ed37cc5bf7d2a13a4cab",
"created_at": 1686161544,
"kind": 1,
"tags": [
[
"e",
"e26b3d683cd7b5bec12686847cb6e45848c3e2dbd7f6b99e59a94b1bc41269f6",
"",
"root"
],
[
"e",
"8b1931346caee1f9805c624d32f3f982318317b8f2a4cfa896b01dc046d3d842",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-05-23\n📝 Original message:On Tue, May 22, 2018 at 11:17:42AM -0700, Pieter Wuille via bitcoin-dev wrote:\n\u003e \n\u003e Given the recent discussions about Taproot [1] and Graftroot [2], I\n\u003e was wondering if a practical deployment needs a way to explicitly\n\u003e enable or disable the Graftroot spending path. I have no strong\n\u003e reasons why this would be necessary, but I'd like to hear other\n\u003e people's thoughts.\n\u003e\n\nGraftroot also break blind signature schemes. Consider a protocol such as [1]\nwhere some party has a bunch of UTXOs all controlled (in part) by the same\nkey X. This party produces blind signatures on receipt of new funds, and can\nonly verify the number of signatures he produces, not anything about what he\nis signing.\n\nBTW, the same concern holds for SIGHASH_NOINPUT, which I'd also like to be\ndisable-able. Maybe we should extend one of ZmnSCPxj's suggestions to include\na free \"flags\" byte or two in the witness?\n\n(I also had the same concern about signature aggregation. It seems like it's\npretty hard to preserve the \"one signature = at most one input\" invariant of\nBitcoin, but I think it's important that it is preserved, at least for\noutputs that need it.)\n\nOr maybe, since it appears it will require a space hit to support optional\ngraftroot anyway, we should simply not include it in a proposal for Taproot,\nsince there would be no opportunity cost (in blockchain efficiency) to doing\nit later.\n\n[1] https://github.com/apoelstra/scriptless-scripts/pull/1 \n\n-- \nAndrew Poelstra\nMathematics Department, Blockstream\nEmail: apoelstra at wpsoftware.net\nWeb: https://www.wpsoftware.net/andrew\n\n\"A goose alone, I suppose, can know the loneliness of geese\n who can never find their peace,\n whether north or south or west or east\"\n --Joanna Newsom\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180523/fe3efcc5/attachment.sig\u003e",
"sig": "3c8d941acdfaf3cb270ff44f5e619f52e394d982fac7606c2d779f24c9cb26948642f3fa19bd2c947f81d33c4894fb56ed0f785a47cd525ab90e922acf46b0ca"
}