📅 Original date posted:2018-05-25
📝 Original message:> On 24 May 2018, at 10:08 AM, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Thu, May 24, 2018 at 1:58 AM, Pieter Wuille via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Thanks everyone who commented so far, but let me clarify the context
>> of this question first a bit more to avoid getting into the weeds too
>> much.
>
> since the signer(s) could have signed an arbitrary
> transaction instead, being able to delegate is strictly less powerful.
>
Actually, we could introduce graftroot-like delegation to all existing and new P2PK and P2PKH UTXOs with a softfork:
1. Define SIGHASH_GRAFTROOT = 0x40. New rules apply if (nHashType & SIGHASH_GRAFTROOT)
2. The third stack item MUST be at least 64 bytes, with 32-byte R and 32-byte S, followed by a script of arbitrary size. It MUST be a valid signature for the script with the original public key.
3. The remaining stack items MUST solve the script
Conceptually this could be extended to arbitrary output types, not just P2PK and P2PKH. But it might be too complicated to describe here.
(We can’t do this in P2WPKH and P2WSH due to the implicit CLEANSTACK rules. But nothing could stop us to do it by introducing another witness structure (which is invisible to current nodes) and store the extra graftroot signatures and scripts)
A graftroot design like this is a strict subset of existing signature checking rules. If this is dangerous, the existing signature checking rules must be dangerous. This also doesn’t have any problem with blind signature, since the first signature will always sign the outpoint, with or without ANYONECANPAY. (As I pointed out in my reply to Andrew, his concern applies only to SIGHASH_NOINPUT, not graftroot)
======
With the example above, I believe there is no reason to make graftroot optional, at the expense of block space and/or reduced privacy. Any potential problem (e.g. interaction with blind signature) could be fixed by a proper rules design.
Johnson Lau [ARCHIVE] /
npub1fy…p2mv9
2023-06-07 20:12:27
in reply to nevent1q…ncaf
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Published at
2023-06-07 20:12:27Event JSON
{
"id": "3ef6235c50fdb2d6cbc88b1b2342a50982d6c0e0baa09d58f40789abdfa5f949",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686161547,
"kind": 1,
"tags": [
[
"e",
"e26b3d683cd7b5bec12686847cb6e45848c3e2dbd7f6b99e59a94b1bc41269f6",
"",
"root"
],
[
"e",
"a59525798105781c0d14eb0823137fd0f08f4d5d03d6c16687233a0b84f2f0d7",
"",
"reply"
],
[
"p",
"ee55eb03423bd4db01d5c92ad434d52c602d9da1de37ed37cc5bf7d2a13a4cab"
]
],
"content": "📅 Original date posted:2018-05-25\n📝 Original message:\u003e On 24 May 2018, at 10:08 AM, Gregory Maxwell via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e On Thu, May 24, 2018 at 1:58 AM, Pieter Wuille via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e Thanks everyone who commented so far, but let me clarify the context\n\u003e\u003e of this question first a bit more to avoid getting into the weeds too\n\u003e\u003e much.\n\u003e \n\u003e since the signer(s) could have signed an arbitrary\n\u003e transaction instead, being able to delegate is strictly less powerful.\n\u003e \n\n\nActually, we could introduce graftroot-like delegation to all existing and new P2PK and P2PKH UTXOs with a softfork:\n\n1. Define SIGHASH_GRAFTROOT = 0x40. New rules apply if (nHashType \u0026 SIGHASH_GRAFTROOT)\n\n2. The third stack item MUST be at least 64 bytes, with 32-byte R and 32-byte S, followed by a script of arbitrary size. It MUST be a valid signature for the script with the original public key.\n\n3. The remaining stack items MUST solve the script\n\nConceptually this could be extended to arbitrary output types, not just P2PK and P2PKH. But it might be too complicated to describe here.\n\n(We can’t do this in P2WPKH and P2WSH due to the implicit CLEANSTACK rules. But nothing could stop us to do it by introducing another witness structure (which is invisible to current nodes) and store the extra graftroot signatures and scripts)\n\nA graftroot design like this is a strict subset of existing signature checking rules. If this is dangerous, the existing signature checking rules must be dangerous. This also doesn’t have any problem with blind signature, since the first signature will always sign the outpoint, with or without ANYONECANPAY. (As I pointed out in my reply to Andrew, his concern applies only to SIGHASH_NOINPUT, not graftroot)\n\n\n======\n\nWith the example above, I believe there is no reason to make graftroot optional, at the expense of block space and/or reduced privacy. Any potential problem (e.g. interaction with blind signature) could be fixed by a proper rules design.",
"sig": "bb07fab9e7b7c5c1c362a1b6c697811ed06fb93e21909cb01a6343acf57605d96848fb667f19260a121261a88fc580c9fdd60d2ac1e75deace474693344e105b"
}