š
Original date posted:2019-10-03
š Original message:Good morning Ethan,
> To avoid derailing the NO_INPUT conversation, I have changed the
> subject to OP_CAT.
>
> Responding to:
> """
>
> - `SIGHASH` flags attached to signatures are a misdesign, sadly
> retained from the original BitCoin 0.1.0 Alpha for Windows design, on
> par with:
> [..]
>
> - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> [..]
> """
>
> OP_CAT is an extremely valuable op code. I understand why it was
> removed as the situation at the time with scripts was dire. However
> most of the protocols I've wanted to build on Bitcoin run into the
> limitation that stack values can not be concatenated. For instance
> TumbleBit would have far smaller transaction sizes if OP_CAT was
> supported in Bitcoin. If it happens to me as a researcher it is
> probably holding other people back as well. If I could wave a magic
> wand and turn on one of the disabled op codes it would be OP_CAT. Of
> course with the change that size of each concatenated value must be 64
> Bytes or less.
Why 64 bytes in particular?
It seems obvious to me that this 64 bytes is most suited for building Merkle trees, being the size of two SHA256 hashes.
However we have had issues with the use of Merkle trees in Bitcoin blocks.
Specifically, it is difficult to determine if a hash on a Merkle node is the hash of a Merkle subnode, or a leaf transaction.
My understanding is that this is the reason for now requiring transactions to be at least 80 bytes.
The obvious fix would be to prepend the type of the hashed object, i.e. add at least one byte to determine this type.
Taproot for example uses tagged hash functions, with a different tag for leaves, and tagged hashes are just prepend-this-32-byte-constant-twice-before-you-SHA256.
This seems to indicate that to check merkle tree proofs, an `OP_CAT` with only 64 bytes max output size would not be sufficient.
Or we could implement tagged SHA256 as a new opcode...
Regards,
ZmnSCPxj
>
> On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev
> bitcoin-dev at lists.linuxfoundation.org wrote:
>
>
> > Good morning lists,
> > Let me propose the below radical idea:
> >
> > - `SIGHASH` flags attached to signatures are a misdesign, sadly retained from the original BitCoin 0.1.0 Alpha for Windows design, on par with:
> > - 1 RETURN
> > - higher-`nSequence` replacement
> > - DER-encoded pubkeys
> > - unrestricted `scriptPubKey`
> > - Payee-security-paid-by-payer (i.e. lack of P2SH)
> > - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > - transaction malleability
> > - probably many more
> >
> > So let me propose the more radical excision, starting with SegWit v1:
> >
> > - Remove `SIGHASH` from signatures.
> > - Put `SIGHASH` on public keys.
> >
> > Public keys are now encoded as either 33-bytes (implicit `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type, followed by pubkey coordinate).
> > `OP_CHECKSIG` and friends then look at the public key to determine sighash algorithm rather than the signature.
> > As we expect public keys to be indirectly committed to on every output `scriptPubKey`, this is automatically output tagging to allow particular `SIGHASH`.
> > However, we can then utilize the many many ways to hide public keys away until they are needed, exemplified in MAST-inside-Taproot.
> > I propose also the addition of the opcode:
> >
> > <sighash> <pubkey> OP_SETPUBKEYSIGHASH
> >
> >
> > - `sighash` must be one byte.
> > - `pubkey` may be the special byte `0x1`, meaning "just use the Taproot internal pubkey".
> > - `pubkey` may be 33-byte public key, in which case the `sighash` byte is just prepended to it.
> > - `pubkey` may be 34-byte public key with sighash, in which case the first byte is replaced with `sighash` byte.
> > - If `sighash` is `0x00` then the result is a 33-byte public key (the sighash byte is removed) i.e. `SIGHASH_ALL` implicit.
> >
> > This retains the old feature where the sighash is selected at time-of-spending rather than time-of-payment.
> > This is done by using the script:
> >
> > <pubkey> OP_SETPUBKEYSIGHASH OP_CHECKSIG
> >
> >
> > Then the sighash can be put in the witness stack after the signature, letting the `SIGHASH` flag be selected at time-of-signing, but only if the SCRIPT specifically is formed to do so.
> > This is malleability-safe as the signature still commits to the `SIGHASH` it was created for.
> > However, by default, public keys will not have an attached `SIGHASH` byte, implying `SIGHASH_ALL` (and disallowing-by-default non-`SIGHASH_ALL`).
> > This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they are allowed only if the output specifically says they are allowed.
> > Would this not be a superior solution?
> > Regards,
> > ZmnSCPxj
> >
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-07 18:20:53
in reply to nevent1qā¦8rcy
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 18:20:53Event JSON
{
"id": "7a93b95690ab873a9d8ce176524377c8ce58e0f5d762b61d3aa42136bd165c5b",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686162053,
"kind": 1,
"tags": [
[
"e",
"f5d60e0633c44726e87082df690527208a1c985e5db057ee7f891f220507de3a",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
Original date posted:2019-10-03\nš Original message:Good morning Ethan,\n\n\n\u003e To avoid derailing the NO_INPUT conversation, I have changed the\n\u003e subject to OP_CAT.\n\u003e\n\u003e Responding to:\n\u003e \"\"\"\n\u003e\n\u003e - `SIGHASH` flags attached to signatures are a misdesign, sadly\n\u003e retained from the original BitCoin 0.1.0 Alpha for Windows design, on\n\u003e par with:\n\u003e [..]\n\u003e\n\u003e - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends\n\u003e [..]\n\u003e \"\"\"\n\u003e\n\u003e OP_CAT is an extremely valuable op code. I understand why it was\n\u003e removed as the situation at the time with scripts was dire. However\n\u003e most of the protocols I've wanted to build on Bitcoin run into the\n\u003e limitation that stack values can not be concatenated. For instance\n\u003e TumbleBit would have far smaller transaction sizes if OP_CAT was\n\u003e supported in Bitcoin. If it happens to me as a researcher it is\n\u003e probably holding other people back as well. If I could wave a magic\n\u003e wand and turn on one of the disabled op codes it would be OP_CAT. Of\n\u003e course with the change that size of each concatenated value must be 64\n\u003e Bytes or less.\n\nWhy 64 bytes in particular?\n\nIt seems obvious to me that this 64 bytes is most suited for building Merkle trees, being the size of two SHA256 hashes.\n\nHowever we have had issues with the use of Merkle trees in Bitcoin blocks.\nSpecifically, it is difficult to determine if a hash on a Merkle node is the hash of a Merkle subnode, or a leaf transaction.\nMy understanding is that this is the reason for now requiring transactions to be at least 80 bytes.\n\nThe obvious fix would be to prepend the type of the hashed object, i.e. add at least one byte to determine this type.\nTaproot for example uses tagged hash functions, with a different tag for leaves, and tagged hashes are just prepend-this-32-byte-constant-twice-before-you-SHA256.\n\nThis seems to indicate that to check merkle tree proofs, an `OP_CAT` with only 64 bytes max output size would not be sufficient.\n\nOr we could implement tagged SHA256 as a new opcode...\n\nRegards,\nZmnSCPxj\n\n\n\u003e\n\u003e On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev\n\u003e bitcoin-dev at lists.linuxfoundation.org wrote:\n\u003e\n\u003e\n\u003e \u003e Good morning lists,\n\u003e \u003e Let me propose the below radical idea:\n\u003e \u003e\n\u003e \u003e - `SIGHASH` flags attached to signatures are a misdesign, sadly retained from the original BitCoin 0.1.0 Alpha for Windows design, on par with:\n\u003e \u003e - 1 RETURN\n\u003e \u003e - higher-`nSequence` replacement\n\u003e \u003e - DER-encoded pubkeys\n\u003e \u003e - unrestricted `scriptPubKey`\n\u003e \u003e - Payee-security-paid-by-payer (i.e. lack of P2SH)\n\u003e \u003e - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends\n\u003e \u003e - transaction malleability\n\u003e \u003e - probably many more\n\u003e \u003e\n\u003e \u003e So let me propose the more radical excision, starting with SegWit v1:\n\u003e \u003e\n\u003e \u003e - Remove `SIGHASH` from signatures.\n\u003e \u003e - Put `SIGHASH` on public keys.\n\u003e \u003e\n\u003e \u003e Public keys are now encoded as either 33-bytes (implicit `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type, followed by pubkey coordinate).\n\u003e \u003e `OP_CHECKSIG` and friends then look at the public key to determine sighash algorithm rather than the signature.\n\u003e \u003e As we expect public keys to be indirectly committed to on every output `scriptPubKey`, this is automatically output tagging to allow particular `SIGHASH`.\n\u003e \u003e However, we can then utilize the many many ways to hide public keys away until they are needed, exemplified in MAST-inside-Taproot.\n\u003e \u003e I propose also the addition of the opcode:\n\u003e \u003e\n\u003e \u003e \u003csighash\u003e \u003cpubkey\u003e OP_SETPUBKEYSIGHASH\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e - `sighash` must be one byte.\n\u003e \u003e - `pubkey` may be the special byte `0x1`, meaning \"just use the Taproot internal pubkey\".\n\u003e \u003e - `pubkey` may be 33-byte public key, in which case the `sighash` byte is just prepended to it.\n\u003e \u003e - `pubkey` may be 34-byte public key with sighash, in which case the first byte is replaced with `sighash` byte.\n\u003e \u003e - If `sighash` is `0x00` then the result is a 33-byte public key (the sighash byte is removed) i.e. `SIGHASH_ALL` implicit.\n\u003e \u003e\n\u003e \u003e This retains the old feature where the sighash is selected at time-of-spending rather than time-of-payment.\n\u003e \u003e This is done by using the script:\n\u003e \u003e\n\u003e \u003e \u003cpubkey\u003e OP_SETPUBKEYSIGHASH OP_CHECKSIG\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Then the sighash can be put in the witness stack after the signature, letting the `SIGHASH` flag be selected at time-of-signing, but only if the SCRIPT specifically is formed to do so.\n\u003e \u003e This is malleability-safe as the signature still commits to the `SIGHASH` it was created for.\n\u003e \u003e However, by default, public keys will not have an attached `SIGHASH` byte, implying `SIGHASH_ALL` (and disallowing-by-default non-`SIGHASH_ALL`).\n\u003e \u003e This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they are allowed only if the output specifically says they are allowed.\n\u003e \u003e Would this not be a superior solution?\n\u003e \u003e Regards,\n\u003e \u003e ZmnSCPxj\n\u003e \u003e\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "67f6ef0321a1198ee2f995616ea5203590bd4f99b9852142ca37ffda7d4f8b9e3fb7f9f5dee08c2a4a46b16ab7c0cd0d9348820ba4ee2dbc1912fe39b8fb8c85"
}