📅 Original date posted:2016-11-03
📝 Original message:On Thu, Nov 3, 2016 at 3:37 AM, Daniel Robinson <danrobinson010 at gmail.com>
wrote:
> Really cool!
>
> How about "poison transactions," the other covenants use case proposed by
> Möser, Eyal, and Sirer? (I think OP_CHECKSIGFROMSTACKVERIFY will also make
> it easier to check fraud proofs, the other prerequisite for poison
> transactions.)
>
I admit I didn't study their poison transactions very carefully. It seemed
specific to Bitcoin-NG.
> Seems a little wasteful to do those two "unnecessary" signature checks,
> and to have to construct the entire transaction data structure, just to
> verify a single output in the transaction. Any plans to add more flexible
> introspection opcodes to Elements, such as OP_CHECKOUTPUTVERIFY?
>
I used to be hesitant to the idea of adding transaction introspection
operations, because the script design seemed to be deliberately avoiding
doing that. One of the big takeaways from this work, for me at least, is
that since the transaction data is so easily recoverable anyways, adding
transaction introspection operations isn't really going to provide any more
power to script; it will just save everyone a bunch of work. There are no
specific plans to put transaction introspection opcodes into Elements at
this moment, but I feel that the door for that possibility is wide open now.
Really minor nit: "Notice that we have appended 0x83 to the end of the
> transaction data"—should this say "to the end of the signature"?
>
Probably should reed "Notice that we have appended 0x83000000 to the end of
the transaction data". I'll make an update.
>
> On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Right. There are minor trade-offs to be made with regards to that design
> point of OP_CHECKSIGFROMSTACKVERIFY. Fortunately this covenant
> construction isn't sensitive to that choice and can be made to work with
> either implementation of OP_CHECKSIGFROMSTACKVERIFY.
>
> On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
>
> Interesting. I have implemented OP_CHECKSIGFROMSTACKVERIFY in a different
> way from the Elements. Instead of hashing the data on stack, I directly put
> the 32 byte hash to the stack. This should be more flexible as not every
> system are using double-SHA256
>
> https://github.com/jl2012/bitcoin/commits/mast_v3_master
>
>
> On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> It is possible to implement covenants using two script extensions: OP_CAT
> and OP_CHECKSIGFROMSTACKVERIFY. Both of these op codes are already
> available in the Elements Alpha sidechain, so it is possible to construct
> covenants in Elements Alpha today. I have detailed how the construction
> works in a blog post at <https://blockstream.com/2016/
> 11/02/covenants-in-elements-alpha.html>. As an example, I've constructed
> scripts for the Moeser-Eyal-Sirer vault.
>
> I'm interested in collecting and implementing other useful covenants, so
> if people have ideas, please post them.
>
> If there are any questions, I'd be happy to answer.
>
> --
> Russell O'Connor
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161103/f9640dd7/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 17:54:14
in reply to nevent1q…qt7y
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 17:54:14Event JSON
{
"id": "c8ba5b5057d1704f8b2d5cee77ad268179d816e01ac96ca5d8a0192530e7a432",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686160454,
"kind": 1,
"tags": [
[
"e",
"61f5e2d52a76b3becccbcade7f95e36346221f1a7928d7d866ff31e2f47d30b0",
"",
"root"
],
[
"e",
"823e89e04e708abe299b4291b398d085214089cf163fa2c85e8190b6cd732bc1",
"",
"reply"
],
[
"p",
"b90b519fa120ae6837fed0d6880430a41a8534ade8e6417c784830e97dfe8ac6"
]
],
"content": "📅 Original date posted:2016-11-03\n📝 Original message:On Thu, Nov 3, 2016 at 3:37 AM, Daniel Robinson \u003cdanrobinson010 at gmail.com\u003e\nwrote:\n\n\u003e Really cool!\n\u003e\n\u003e How about \"poison transactions,\" the other covenants use case proposed by\n\u003e Möser, Eyal, and Sirer? (I think OP_CHECKSIGFROMSTACKVERIFY will also make\n\u003e it easier to check fraud proofs, the other prerequisite for poison\n\u003e transactions.)\n\u003e\n\nI admit I didn't study their poison transactions very carefully. It seemed\nspecific to Bitcoin-NG.\n\n\n\u003e Seems a little wasteful to do those two \"unnecessary\" signature checks,\n\u003e and to have to construct the entire transaction data structure, just to\n\u003e verify a single output in the transaction. Any plans to add more flexible\n\u003e introspection opcodes to Elements, such as OP_CHECKOUTPUTVERIFY?\n\u003e\n\nI used to be hesitant to the idea of adding transaction introspection\noperations, because the script design seemed to be deliberately avoiding\ndoing that. One of the big takeaways from this work, for me at least, is\nthat since the transaction data is so easily recoverable anyways, adding\ntransaction introspection operations isn't really going to provide any more\npower to script; it will just save everyone a bunch of work. There are no\nspecific plans to put transaction introspection opcodes into Elements at\nthis moment, but I feel that the door for that possibility is wide open now.\n\nReally minor nit: \"Notice that we have appended 0x83 to the end of the\n\u003e transaction data\"—should this say \"to the end of the signature\"?\n\u003e\n\nProbably should reed \"Notice that we have appended 0x83000000 to the end of\nthe transaction data\". I'll make an update.\n\n\n\u003e\n\u003e On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Right. There are minor trade-offs to be made with regards to that design\n\u003e point of OP_CHECKSIGFROMSTACKVERIFY. Fortunately this covenant\n\u003e construction isn't sensitive to that choice and can be made to work with\n\u003e either implementation of OP_CHECKSIGFROMSTACKVERIFY.\n\u003e\n\u003e On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau \u003cjl2012 at xbt.hk\u003e wrote:\n\u003e\n\u003e Interesting. I have implemented OP_CHECKSIGFROMSTACKVERIFY in a different\n\u003e way from the Elements. Instead of hashing the data on stack, I directly put\n\u003e the 32 byte hash to the stack. This should be more flexible as not every\n\u003e system are using double-SHA256\n\u003e\n\u003e https://github.com/jl2012/bitcoin/commits/mast_v3_master\n\u003e\n\u003e\n\u003e On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Hi all,\n\u003e\n\u003e It is possible to implement covenants using two script extensions: OP_CAT\n\u003e and OP_CHECKSIGFROMSTACKVERIFY. Both of these op codes are already\n\u003e available in the Elements Alpha sidechain, so it is possible to construct\n\u003e covenants in Elements Alpha today. I have detailed how the construction\n\u003e works in a blog post at \u003chttps://blockstream.com/2016/\n\u003e 11/02/covenants-in-elements-alpha.html\u003e. As an example, I've constructed\n\u003e scripts for the Moeser-Eyal-Sirer vault.\n\u003e\n\u003e I'm interested in collecting and implementing other useful covenants, so\n\u003e if people have ideas, please post them.\n\u003e\n\u003e If there are any questions, I'd be happy to answer.\n\u003e\n\u003e --\n\u003e Russell O'Connor\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\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\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161103/f9640dd7/attachment.html\u003e",
"sig": "4e63558ee7b7a08c475dc39c55aaf0440a8f2e72fa6618eee0c46e1369a9fa1d3027269168d43538b9b9b951278e30a4c32c8baf116f2202c91551e46cee8315"
}