{"type":"rich","version":"1.0","author_name":"npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","author_url":"https://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-10-04\n📝 Original message:Good point -- in our discussion, we called it OP_FFS -- Fold Functional\nStream, and it could be initialized with a different integer to select for\ndifferent functions. Therefore the stream processing opcodes would be\ngeneric, but extensible.\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n\n\nOn Fri, Oct 4, 2019 at 12:00 AM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Jeremy,\n\u003e\n\u003e \u003e Awhile back, Ethan and I discussed having, rather than OP_CAT, an\n\u003e OP_SHA256STREAM that uses the streaming properties of a SHA256 hash\n\u003e function to allow concatenation of an unlimited amount of data, provided\n\u003e the only use is to hash it.\n\u003e \u003e\n\u003e \u003e You can then use it perhaps as follows:\n\u003e \u003e\n\u003e \u003e // start a new hash with item\n\u003e \u003e OP_SHA256STREAM  (-1) -\u003e [state]\n\u003e \u003e // Add item to the hash in state\n\u003e \u003e OP_SHA256STREAM n [item] [state] -\u003e [state]\n\u003e \u003e // Finalize\n\u003e \u003e OP_SHA256STREAM (-2) [state] -\u003e [Hash]\n\u003e \u003e\n\u003e \u003e \u003c-1\u003e OP_SHA256STREAM \u003ctag\u003e \u003csubnode 2\u003e \u003csubnode 3\u003e \u003c3\u003e OP_SHA256STREAM\n\u003e \u003c-2\u003e OP_SHA256STREAM\n\u003e \u003e\n\u003e \u003e Or it coul\n\u003e \u003e\n\u003e\n\u003e This seems a good idea.\n\u003e\n\u003e Though it brings up the age-old tension between:\n\u003e\n\u003e * Generically-useable components, but due to generalization are less\n\u003e efficient.\n\u003e * Specific-use components, which are efficient, but which may end up not\n\u003e being useable in the future.\n\u003e\n\u003e In particular, `OP_SHA256STREAM` would no longer be useable if SHA256\n\u003e eventually is broken, while the `OP_CAT` will still be useable in the\n\u003e indefinite future.\n\u003e In the future a new hash function can simply be defined and the same\n\u003e technique with `OP_CAT` would still be useable.\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e \u003e --\n\u003e \u003e @JeremyRubin\n\u003e \u003e\n\u003e \u003e On Thu, Oct 3, 2019 at 8:04 PM Ethan Heilman \u003ceth3rs at gmail.com\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e I hope you are having an great afternoon ZmnSCPxj,\n\u003e \u003e \u003e\n\u003e \u003e \u003e You make an excellent point!\n\u003e \u003e \u003e\n\u003e \u003e \u003e I had thought about doing the following to tag nodes\n\u003e \u003e \u003e\n\u003e \u003e \u003e || means OP_CAT\n\u003e \u003e \u003e\n\u003e \u003e \u003e `node = SHA256(type||SHA256(data))`\n\u003e \u003e \u003e so a subnode would be\n\u003e \u003e \u003e `subnode1 = SHA256(1||SHA256(subnode2||subnode3))`\n\u003e \u003e \u003e and a leaf node would be\n\u003e \u003e \u003e `leafnode = SHA256(0||SHA256(leafdata))`\n\u003e \u003e \u003e\n\u003e \u003e \u003e Yet, I like your idea better. Increasing the size of the two inputs to\n\u003e \u003e \u003e OP_CAT to be 260 Bytes each where 520 Bytes is the maximum allowable\n\u003e \u003e \u003e size of object on the stack seems sensible and also doesn't special\n\u003e \u003e \u003e case the logic of OP_CAT.\n\u003e \u003e \u003e\n\u003e \u003e \u003e It would also increase performance. SHA256(tag||subnode2||subnode3)\n\u003e \u003e \u003e requires 2 compression function calls whereas\n\u003e \u003e \u003e SHA256(1||SHA256(subnode2||subnode3)) requires 2+1=3 compression\n\u003e \u003e \u003e function calls (due to padding).\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003eOr we could implement tagged SHA256 as a new opcode...\n\u003e \u003e \u003e\n\u003e \u003e \u003e I agree that tagged SHA256 as an op code that would certainty be\n\u003e \u003e \u003e useful, but OP_CAT provides far more utility and is a simpler change.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Thanks,\n\u003e \u003e \u003e Ethan\n\u003e \u003e \u003e\n\u003e \u003e \u003e On Thu, Oct 3, 2019 at 7:42 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e\n\u003e wrote:\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Good morning Ethan,\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e To avoid derailing the NO_INPUT conversation, I have changed the\n\u003e \u003e \u003e \u003e \u003e subject to OP_CAT.\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e Responding to:\n\u003e \u003e \u003e \u003e \u003e \"\"\"\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e -   `SIGHASH` flags attached to signatures are a misdesign, sadly\n\u003e \u003e \u003e \u003e \u003e     retained from the original BitCoin 0.1.0 Alpha for Windows\n\u003e design, on\n\u003e \u003e \u003e \u003e \u003e     par with:\n\u003e \u003e \u003e \u003e \u003e     [..]\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e -   `OP_CAT` and `OP_MULT` and `OP_ADD` and friends\n\u003e \u003e \u003e \u003e \u003e     [..]\n\u003e \u003e \u003e \u003e \u003e     \"\"\"\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     OP_CAT is an extremely valuable op code. I understand why it\n\u003e was\n\u003e \u003e \u003e \u003e \u003e     removed as the situation at the time with scripts was dire.\n\u003e However\n\u003e \u003e \u003e \u003e \u003e     most of the protocols I've wanted to build on Bitcoin run into\n\u003e the\n\u003e \u003e \u003e \u003e \u003e     limitation that stack values can not be concatenated. For\n\u003e instance\n\u003e \u003e \u003e \u003e \u003e     TumbleBit would have far smaller transaction sizes if OP_CAT\n\u003e was\n\u003e \u003e \u003e \u003e \u003e     supported in Bitcoin. If it happens to me as a researcher it is\n\u003e \u003e \u003e \u003e \u003e     probably holding other people back as well. If I could wave a\n\u003e magic\n\u003e \u003e \u003e \u003e \u003e     wand and turn on one of the disabled op codes it would be\n\u003e OP_CAT. Of\n\u003e \u003e \u003e \u003e \u003e     course with the change that size of each concatenated value\n\u003e must be 64\n\u003e \u003e \u003e \u003e \u003e     Bytes or less.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Why 64 bytes in particular?\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e It seems obvious to me that this 64 bytes is most suited for\n\u003e building Merkle trees, being the size of two SHA256 hashes.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e However we have had issues with the use of Merkle trees in Bitcoin\n\u003e blocks.\n\u003e \u003e \u003e \u003e Specifically, it is difficult to determine if a hash on a Merkle\n\u003e node is the hash of a Merkle subnode, or a leaf transaction.\n\u003e \u003e \u003e \u003e My understanding is that this is the reason for now requiring\n\u003e transactions to be at least 80 bytes.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e The obvious fix would be to prepend the type of the hashed object,\n\u003e i.e. add at least one byte to determine this type.\n\u003e \u003e \u003e \u003e Taproot for example uses tagged hash functions, with a different tag\n\u003e for leaves, and tagged hashes are just\n\u003e prepend-this-32-byte-constant-twice-before-you-SHA256.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e This seems to indicate that to check merkle tree proofs, an `OP_CAT`\n\u003e with only 64 bytes max output size would not be sufficient.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Or we could implement tagged SHA256 as a new opcode...\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Regards,\n\u003e \u003e \u003e \u003e ZmnSCPxj\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev\n\u003e \u003e \u003e \u003e \u003e     bitcoin-dev at lists.linuxfoundation.org wrote:\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e Good morning lists,\n\u003e \u003e \u003e \u003e \u003e \u003e Let me propose the below radical idea:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e -   `SIGHASH` flags attached to signatures are a misdesign,\n\u003e sadly retained from the original BitCoin 0.1.0 Alpha for Windows design, on\n\u003e par with:\n\u003e \u003e \u003e \u003e \u003e \u003e     -   1 RETURN\n\u003e \u003e \u003e \u003e \u003e \u003e     -   higher-`nSequence` replacement\n\u003e \u003e \u003e \u003e \u003e \u003e     -   DER-encoded pubkeys\n\u003e \u003e \u003e \u003e \u003e \u003e     -   unrestricted `scriptPubKey`\n\u003e \u003e \u003e \u003e \u003e \u003e     -   Payee-security-paid-by-payer (i.e. lack of P2SH)\n\u003e \u003e \u003e \u003e \u003e \u003e     -   `OP_CAT` and `OP_MULT` and `OP_ADD` and friends\n\u003e \u003e \u003e \u003e \u003e \u003e     -   transaction malleability\n\u003e \u003e \u003e \u003e \u003e \u003e     -   probably many more\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e So let me propose the more radical excision, starting with\n\u003e SegWit v1:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e -   Remove `SIGHASH` from signatures.\n\u003e \u003e \u003e \u003e \u003e \u003e -   Put `SIGHASH` on public keys.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e Public keys are now encoded as either 33-bytes (implicit\n\u003e `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type,\n\u003e followed by pubkey coordinate).\n\u003e \u003e \u003e \u003e \u003e \u003e `OP_CHECKSIG` and friends then look at the public key to\n\u003e determine sighash algorithm rather than the signature.\n\u003e \u003e \u003e \u003e \u003e \u003e As we expect public keys to be indirectly committed to on every\n\u003e output `scriptPubKey`, this is automatically output tagging to allow\n\u003e particular `SIGHASH`.\n\u003e \u003e \u003e \u003e \u003e \u003e However, we can then utilize the many many ways to hide public\n\u003e keys away until they are needed, exemplified in MAST-inside-Taproot.\n\u003e \u003e \u003e \u003e \u003e \u003e I propose also the addition of the opcode:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \u003csighash\u003e \u003cpubkey\u003e OP_SETPUBKEYSIGHASH\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e -   `sighash` must be one byte.\n\u003e \u003e \u003e \u003e \u003e \u003e -   `pubkey` may be the special byte `0x1`, meaning \"just use\n\u003e the Taproot internal pubkey\".\n\u003e \u003e \u003e \u003e \u003e \u003e -   `pubkey` may be 33-byte public key, in which case the\n\u003e `sighash` byte is just prepended to it.\n\u003e \u003e \u003e \u003e \u003e \u003e -   `pubkey` may be 34-byte public key with sighash, in which\n\u003e case the first byte is replaced with `sighash` byte.\n\u003e \u003e \u003e \u003e \u003e \u003e -   If `sighash` is `0x00` then the result is a 33-byte public\n\u003e key (the sighash byte is removed) i.e. `SIGHASH_ALL` implicit.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e This retains the old feature where the sighash is selected at\n\u003e time-of-spending rather than time-of-payment.\n\u003e \u003e \u003e \u003e \u003e \u003e This is done by using the script:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \u003cpubkey\u003e OP_SETPUBKEYSIGHASH OP_CHECKSIG\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e Then the sighash can be put in the witness stack after the\n\u003e signature, letting the `SIGHASH` flag be selected at time-of-signing, but\n\u003e only if the SCRIPT specifically is formed to do so.\n\u003e \u003e \u003e \u003e \u003e \u003e This is malleability-safe as the signature still commits to the\n\u003e `SIGHASH` it was created for.\n\u003e \u003e \u003e \u003e \u003e \u003e However, by default, public keys will not have an attached\n\u003e `SIGHASH` byte, implying `SIGHASH_ALL` (and disallowing-by-default\n\u003e non-`SIGHASH_ALL`).\n\u003e \u003e \u003e \u003e \u003e \u003e This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`,\n\u003e as they are allowed only if the output specifically says they are allowed.\n\u003e \u003e \u003e \u003e \u003e \u003e Would this not be a superior solution?\n\u003e \u003e \u003e \u003e \u003e \u003e Regards,\n\u003e \u003e \u003e \u003e \u003e \u003e ZmnSCPxj\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e bitcoin-dev mailing list\n\u003e \u003e \u003e \u003e \u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e \u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e Lightning-dev mailing list\n\u003e \u003e \u003e \u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e _______________________________________________\n\u003e \u003e \u003e Lightning-dev mailing list\n\u003e \u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191004/709217b1/attachment.html\u003e"}