* [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY
@ 2016-11-02 17:30 Russell O'Connor
2016-11-03 3:35 ` Johnson Lau
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Russell O'Connor @ 2016-11-02 17:30 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 657 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY 2016-11-02 17:30 [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY Russell O'Connor @ 2016-11-03 3:35 ` Johnson Lau [not found] ` <E8BB95A5-09B3-443C-B197-29DA3C4767D8@xbt.hk> 2016-11-03 17:42 ` Ryan Grant 2 siblings, 0 replies; 8+ messages in thread From: Johnson Lau @ 2016-11-03 3:35 UTC (permalink / raw) To: Russell O'Connor, bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1530 bytes --] 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 <https://github.com/jl2012/bitcoin/commits/mast_v3_master> > On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@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 <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@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 2424 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <E8BB95A5-09B3-443C-B197-29DA3C4767D8@xbt.hk>]
* Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY [not found] ` <E8BB95A5-09B3-443C-B197-29DA3C4767D8@xbt.hk> @ 2016-11-03 4:19 ` Russell O'Connor 2016-11-03 7:37 ` Daniel Robinson 0 siblings, 1 reply; 8+ messages in thread From: Russell O'Connor @ 2016-11-03 4:19 UTC (permalink / raw) To: Johnson Lau; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1647 bytes --] 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@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@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@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > [-- Attachment #2: Type: text/html, Size: 2811 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY 2016-11-03 4:19 ` Russell O'Connor @ 2016-11-03 7:37 ` Daniel Robinson 2016-11-03 20:02 ` Russell O'Connor 2016-11-04 14:35 ` Tim Ruffing 0 siblings, 2 replies; 8+ messages in thread From: Daniel Robinson @ 2016-11-03 7:37 UTC (permalink / raw) To: Russell O'Connor, Bitcoin Protocol Discussion, Johnson Lau [-- Attachment #1: Type: text/plain, Size: 2607 bytes --] 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.) 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? 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"? On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev < bitcoin-dev@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@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@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@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 6751 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY 2016-11-03 7:37 ` Daniel Robinson @ 2016-11-03 20:02 ` Russell O'Connor 2016-11-04 14:35 ` Tim Ruffing 1 sibling, 0 replies; 8+ messages in thread From: Russell O'Connor @ 2016-11-03 20:02 UTC (permalink / raw) To: Daniel Robinson; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3647 bytes --] On Thu, Nov 3, 2016 at 3:37 AM, Daniel Robinson <danrobinson010@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@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@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@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@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 11567 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY 2016-11-03 7:37 ` Daniel Robinson 2016-11-03 20:02 ` Russell O'Connor @ 2016-11-04 14:35 ` Tim Ruffing 2016-11-07 19:30 ` Jeremy 1 sibling, 1 reply; 8+ messages in thread From: Tim Ruffing @ 2016-11-04 14:35 UTC (permalink / raw) To: bitcoin-dev Not a covenant but interesting nevertheless: _One_ of OP_CAT and OP_CHECKSIGFROMSTACKVERIFY alone is enough to implement "opt-in miner takes double-spend" [1]: You can create an output, which is spendable by everybody if you ever double-spend the output with two different transactions. Then the next miner will probably take your money (double-spending against your two or more contradicting transactions again). If you spend such an output, then the recipient may be willing to accept a zero-conf transaction, because he knows that you'll lose the money when you attempt double-spending (unless you are the lucky miner). See the discussion in [1] for details. The implementation using OP_CHECKSIGFROMSTACKVERIFY is straight- forward. You add a case to the script which allows spending if two valid signatures on different message under the public key of the output are given. What is less known I think: The same functionality can be achieved in a simpler way just using OP_CAT, because it's possible to turn Bitcoin's ECDSA to an "opt-in one-time signature scheme". With OP_CAT, you can create an output that is only spendable using a signature (r,s) with a specific already fixed first part r=x_coord(kG). Basically, the creator of this output commits on r (and k) already when creating the output. Now, signing two different transaction with the same r allows everybody to extract the secret key from the two signatures. The drawbacks of the implementation with OP_CAT is that it's not possible to make a distinction between legitimate or illegitimate double-spends (yet to be defined) but just every double-spend is penalized. Also, it's somewhat hackish and the signer must store k (or create it deterministically but that's a good idea anyway). [1] https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07122.html Best, Tim On Thu, 2016-11-03 at 07:37 +0000, Daniel Robinson via bitcoin-dev 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.) > > 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? > > 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"? > > On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev <bit > coin-dev@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@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 <bitc > > > > oin-dev@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-e > > > > lements-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@lists•linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY 2016-11-04 14:35 ` Tim Ruffing @ 2016-11-07 19:30 ` Jeremy 0 siblings, 0 replies; 8+ messages in thread From: Jeremy @ 2016-11-07 19:30 UTC (permalink / raw) To: Tim Ruffing, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6695 bytes --] I think the following implementation may be advantageous. It uses the same number of opcodes, without OP_CAT. Avoiding use of OP_CAT is still desirable as I think it will be difficult to agree on semantics for OP_CAT (given necessary measures to prevent memory abuse) than for OP_LEFT. Another option I would be in support of would be to have signature flags apply to OP_CHECKSIGFROMSTACK and all OP_CHECKSIG flags be ignored if they aren't meaningful... *<signature; SIGHASH_ALL><signatureTxnData>1. <pubkey> OP_DUP3<pubkey><signature; SIGHASH_ALL><signatureTxnData><pubkey><signature; SIGHASH_ALL><signatureTxnData>2. OP_CHECKSIGVERIFY<signatureTxnData><pubkey><signature; SIGHASH_ALL><signatureTxnData>3. OP_SHA256 OP_ROT OP_SIZE OP_SUB1 OP_LEFT<signature><sha256(signatureTxnData)><pubkey><signatureTxnData>4. OP_SWAP OP_ROT OP_CHECKSIGFROMSTACKVERIFY (with same argument order)* -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Fri, Nov 4, 2016 at 7:35 AM, Tim Ruffing via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Not a covenant but interesting nevertheless: _One_ of OP_CAT and > OP_CHECKSIGFROMSTACKVERIFY alone is enough to implement "opt-in miner > takes double-spend" [1]: > > You can create an output, which is spendable by everybody if you ever > double-spend the output with two different transactions. Then the next > miner will probably take your money (double-spending against your two > or more contradicting transactions again). > > If you spend such an output, then the recipient may be willing to > accept a zero-conf transaction, because he knows that you'll lose the > money when you attempt double-spending (unless you are the lucky > miner). See the discussion in [1] for details. > > The implementation using OP_CHECKSIGFROMSTACKVERIFY is straight- > forward. You add a case to the script which allows spending if two > valid signatures on different message under the public key of the > output are given. > > What is less known I think: > The same functionality can be achieved in a simpler way just using > OP_CAT, because it's possible to turn Bitcoin's ECDSA to an "opt-in > one-time signature scheme". With OP_CAT, you can create an output that > is only spendable using a signature (r,s) with a specific already fixed > first part r=x_coord(kG). Basically, the creator of this output commits > on r (and k) already when creating the output. Now, signing two > different transaction with the same r allows everybody to extract the > secret key from the two signatures. > > The drawbacks of the implementation with OP_CAT is that it's not > possible to make a distinction between legitimate or illegitimate > double-spends (yet to be defined) but just every double-spend is > penalized. Also, it's somewhat hackish and the signer must store k (or > create it deterministically but that's a good idea anyway). > > [1] https://www.mail-archive.com/bitcoin-development@lists. > sourceforge.net/msg07122.html > > Best, > Tim > > On Thu, 2016-11-03 at 07:37 +0000, Daniel Robinson via bitcoin-dev > 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.) > > > > 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? > > > > 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"? > > > > On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev <bit > > coin-dev@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@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 <bitc > > > > > oin-dev@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-e > > > > > lements-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@lists•linuxfoundation.org > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > _______________________________________________ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists•linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 10859 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY 2016-11-02 17:30 [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY Russell O'Connor 2016-11-03 3:35 ` Johnson Lau [not found] ` <E8BB95A5-09B3-443C-B197-29DA3C4767D8@xbt.hk> @ 2016-11-03 17:42 ` Ryan Grant 2 siblings, 0 replies; 8+ messages in thread From: Ryan Grant @ 2016-11-03 17:42 UTC (permalink / raw) To: Russell O'Connor, Bitcoin Protocol Discussion On Wed, Nov 2, 2016 at 1:30 PM, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > I'm interested in collecting and implementing other useful covenants, so if > people have ideas, please post them. I know of a good business case that could benefit from two nice features. As an example: Two parties have initiated a transaction designed with counterparty-minimization in mind. It uses MAST and has many different payout distributions. Both parties enter expecting to gain from the transaction, but both take on risk due to external factors. Because of the risks involved, there exist possible times when one party may wish to renegotiate the exit distribution, and might threaten to block any exit. Or, either party might get hit by the proverbial bus. During such times, the other party's eventual exit is protected by using a multisig which includes an oracle determination. The oracle's trusted role is bound to this example's unstated "external factors" in a very limited sense, and does not include broader concerns, such as determining whether a party to the transaction is of "sound mind and body". The singular term "oracle" hides a set of entities participating in m-of-n multisig, which we can name the "oracle-set". Transaction terms include a CLTV lasting perhaps several years, applied whenever the exit requires the oracle-set's signatures. Both parties may mutually select and sign one of the payout distributions, to exit early. The example, as I've described it so far, doesn't need anything other than MAST. It isn't a covenant, because it doesn't impose any forward restrictions when satisfied; despite the contractual complications of executing the oracle-set's signatures. As covenant features are considered across updated instances of what is otherwise a singular transaction, it's important that none carry into the final payout distribution, and that this is easy to verify. Features desired: - One party would like to unilaterally sell their participation in the transaction, to a previously unknown recipient, before the CLTV becomes valid. The other originating party's stored MAST should either continue to function, or require minimal replacements that can be deterministically applied using data visible on the blockchain. It should not be necessary to ask permission from - or coordinate online communication with - the other originating party. (This can also be viewed as a key rotation problem for any long-lasting multisig transaction.) - Both parties would like to mutually revoke rouge oracle-entities from the oracle-set, without exposing each other to any possible renegotiation of other terms. Note that these features affect each other, since if one party sells their participation after any oracle-entities have been revoked, then the revocations should not reset, but rather remain in effect, until a proper payout executes the final agreement in the contract. Of course, if there's a way to achieve these features with less risk than evaluating covenant logic, I would very much like to hear how to do so. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-11-07 19:30 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-02 17:30 [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY Russell O'Connor
2016-11-03 3:35 ` Johnson Lau
[not found] ` <E8BB95A5-09B3-443C-B197-29DA3C4767D8@xbt.hk>
2016-11-03 4:19 ` Russell O'Connor
2016-11-03 7:37 ` Daniel Robinson
2016-11-03 20:02 ` Russell O'Connor
2016-11-04 14:35 ` Tim Ruffing
2016-11-07 19:30 ` Jeremy
2016-11-03 17:42 ` Ryan Grant
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox