Topic: Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) (Read 182 times)
July 19, 2021, 01:54:31 PM
Gotcha. Well, I suppose the limitations of bitcoin Script are a bit orthogonal to the opcode I'm looking for feedback on.
July 15, 2021, 05:36:08 PM
What do you mean by "the presignature"? In any case, I realized what I was missing. Right the OP_CTV call appears in the script which is what is put into ScriptSig.
I mean the input to OP_CTV, whatever it's called:
Code:
uint256 GetStandardTemplateHashEmptyScript(const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
const uint32_t input_index) {
auto h = CHashWriter(SER_GETHASH, 0)
<< tx.nVersion
<< tx.nLockTime
<< uint32_t(tx.vin.size())
<< sequences_hash
<< uint32_t(tx.vout.size())
<< outputs_hash
<< input_index;
return h.GetSHA256();
}
What do you mean "match" here? Are you talking about transaction inputs here?
Yeah.
Both OP_CTV and OP_CD should be able to ensure the transaction sends the coins to one of a particular set of destinations. What kind of complex conditions can't you do with bitcoin?
Well, technically you can make a condition today that explicitly spells out a bunch of addresses belonging to a service you could send to, but wouldn't it be much easier on smart-contact writers, and resulting tx's being much smaller, if you could, say, pass a master public key instead to make the inputs match *any* of its derived addresses (I can see this being particularly useful for e.g. Bitpay)?
July 15, 2021, 01:35:07 PM
> the scriptsig is not only in the main transaction hash but also inside the presignature
What do you mean by "the presignature"? In any case, I realized what I was missing. Right the OP_CTV call appears in the script which is what is put into ScriptSig.
> is the redeem script the one limiting the destinations, but according to your reply it's the outputs hash in the presignature
Yes, that's right, its the commitment to the outputs that constrains the eventual destination of the coins.
> usually in a smart contract you want to make conditions that the output hashes match those coming from, for example, an exchange
What do you mean "match" here? Are you talking about transaction inputs here? Both OP_CTV and OP_CD should be able to ensure the transaction sends the coins to one of a particular set of destinations. What kind of complex conditions can't you do with bitcoin?
What do you mean by "the presignature"? In any case, I realized what I was missing. Right the OP_CTV call appears in the script which is what is put into ScriptSig.
> is the redeem script the one limiting the destinations, but according to your reply it's the outputs hash in the presignature
Yes, that's right, its the commitment to the outputs that constrains the eventual destination of the coins.
> usually in a smart contract you want to make conditions that the output hashes match those coming from, for example, an exchange
What do you mean "match" here? Are you talking about transaction inputs here? Both OP_CTV and OP_CD should be able to ensure the transaction sends the coins to one of a particular set of destinations. What kind of complex conditions can't you do with bitcoin?
July 14, 2021, 12:36:48 PM
> The BIP (119) says P2SH is unsuitable for this,
What BIP119 says is that P2SH is incompatible with OP_CTV if the opcode does end up requiring a commitment to the scriptSig hash. I must admit I don't quite understand where the hash cycle occurs there.
What BIP119 says is that P2SH is incompatible with OP_CTV if the opcode does end up requiring a commitment to the scriptSig hash. I must admit I don't quite understand where the hash cycle occurs there.
It's probably because the scriptsig is not only in the main transaction hash but also inside the presignature. So you can't fill in something else in the preimage's srcriptsig's place because unlike for the main transaction hash, there's no scriptPubKey we can fill in the place with, making it impossible to make the presignature.
> so this limiting script that's supposed to act as a smart contract will be a raw redeem script?
I don't think I quite understand your question. Would you mind elaborating?
I don't think I quite understand your question. Would you mind elaborating?
In other words, is the redeem script the one limiting the destinations, but according to your reply it's the outputs hash in the presignature.
> There's also the major issue of barring simple arithmetic and crypto (hash160) differences between addresses, the scripting system can't filter addresses based on complex conditions.
Not sure I follow this either. Are you saying OP_CTV bars arithmetic? Or are you talking about bitcoin Script in general?
Not sure I follow this either. Are you saying OP_CTV bars arithmetic? Or are you talking about bitcoin Script in general?
Bitcoin script is limited to basic expressions which makes it bad for trying to filter which transactions are allowed for a UTXO, because usually in a smart contract you want to make conditions that the output hashes match those coming from, for example, an exchange or other service (something that requires at least a turing-complete language). That's well beyond the capabilities of bitcoin script.
July 13, 2021, 11:11:34 PM
> All this is supposed to limit address that the outputs can be spent to by using a script, but how?
What OP_CTV actually does is limit the *transactions* that can be sent to only ones with that specific set of attributes. The set of attributes chosen is intended to ensure that there exists only a single transaction that can fulfill the template. The "outputs hash" in the list is what limits the addresses the transaction sends to.
OP_CTV is basically just one step beyond a pre-signed transaction. With presigned transactions, you require some countersigner to sign a set of transactions that become the only possible transactions you can use to utilize one or more outputs. With OP_CTV, you get rid of the need for some countersigner and can ensure that a set of transactions are the only ways to spend particular outputs.
By contrast, OP_CD is more flexible and there is flexibility allowed in the transactions that can spend outputs locked by a script that uses OP_CD.
> The BIP (119) says P2SH is unsuitable for this,
What BIP119 says is that P2SH is incompatible with OP_CTV if the opcode does end up requiring a commitment to the scriptSig hash. I must admit I don't quite understand where the hash cycle occurs there.
> so this limiting script that's supposed to act as a smart contract will be a raw redeem script?
I don't think I quite understand your question. Would you mind elaborating?
> There's also the major issue of barring simple arithmetic and crypto (hash160) differences between addresses, the scripting system can't filter addresses based on complex conditions.
Not sure I follow this either. Are you saying OP_CTV bars arithmetic? Or are you talking about bitcoin Script in general?
What OP_CTV actually does is limit the *transactions* that can be sent to only ones with that specific set of attributes. The set of attributes chosen is intended to ensure that there exists only a single transaction that can fulfill the template. The "outputs hash" in the list is what limits the addresses the transaction sends to.
OP_CTV is basically just one step beyond a pre-signed transaction. With presigned transactions, you require some countersigner to sign a set of transactions that become the only possible transactions you can use to utilize one or more outputs. With OP_CTV, you get rid of the need for some countersigner and can ensure that a set of transactions are the only ways to spend particular outputs.
By contrast, OP_CD is more flexible and there is flexibility allowed in the transactions that can spend outputs locked by a script that uses OP_CD.
> The BIP (119) says P2SH is unsuitable for this,
What BIP119 says is that P2SH is incompatible with OP_CTV if the opcode does end up requiring a commitment to the scriptSig hash. I must admit I don't quite understand where the hash cycle occurs there.
> so this limiting script that's supposed to act as a smart contract will be a raw redeem script?
I don't think I quite understand your question. Would you mind elaborating?
> There's also the major issue of barring simple arithmetic and crypto (hash160) differences between addresses, the scripting system can't filter addresses based on complex conditions.
Not sure I follow this either. Are you saying OP_CTV bars arithmetic? Or are you talking about bitcoin Script in general?
July 13, 2021, 07:38:20 PM
I believe the exact format for the hashed input of OP_CTV is the following:
All this is supposed to limit address that the outputs can be spent to by using a script, but how? The BIP (119) says P2SH is unsuitable for this, so this limiting script that's supposed to act as a smart contract will be a raw redeem script? There's also the major issue of barring simple arithmetic and crypto (hash160) differences between addresses, the scripting system can't filter addresses based on complex conditions.
nVersion
nLockTime
scriptSig hash (maybe!)
input count
sequences hash
output count
outputs hash
input index
nLockTime
scriptSig hash (maybe!)
input count
sequences hash
output count
outputs hash
input index
All this is supposed to limit address that the outputs can be spent to by using a script, but how? The BIP (119) says P2SH is unsuitable for this, so this limiting script that's supposed to act as a smart contract will be a raw redeem script? There's also the major issue of barring simple arithmetic and crypto (hash160) differences between addresses, the scripting system can't filter addresses based on complex conditions.
July 13, 2021, 01:31:42 PM
I have been working on a proposal for an opcode I call OP_CONSTRAINDESTINATION. The purpose of the opcode is to allow a spend-path to restrict the destination address that an output's coins can be directed to. When the destination address is something like a P2SH address, this allows step-wise covenant scripts (where one script must lead to another).
This involves both specifying particular addresses the output is allowed to send coins to, as well as constraining the amount of the fee that output is allowed to contribute to. For example, if you had an output that contains 1000 satoshi, you could specify that a maximum of ~100 sats of that output go to the miner fee and the other ~900 sats must go to one of a list of specified addresses (~ meaning approximately, because the fee is specified relative to recent median fee rates - details in the proposal).
This opcode has a few different applications, but my primary motivation for creating this opcode is to create more flexible wallet vaults, which are basically wallet setups where you can cancel a payment for a predefined period of time (sometimes called the unvaulting time). These can be used to create far more secure cold wallet setups without a lot of the downsides. Some more info for the uninitiated https://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-vaults/.
To compare this opcode to OP_CHECKTEMPLATEVERIFY, wallet vaults that can be created with OP_CTV must be created in specified chunks: the address is explicitly tied to a particular utxo sent to it. To retrieve coins from the vault, the output must be spent by one of a specific set of transactions (potentially one per spend path). Outputs cannot be arbitrarily combined into a transaction, and there is no flexibility whatsoever in deciding options at the time of spending from the vault - all options must be premeditated and encoded into the address itself when sending money to the vault. This has some related foot-gun scenarios, where the wallet vault has addresses that if sent to would generally result in burning those coins, unless done in a very specific way by the owner of the vault.
By contrast, OP_CD allows a lot more flexibility because it only constrains the address to be sent to from the vault, but doesn't put additional constraints on the transaction. This means that outputs can be combined into a single transaction like you would expect in a normal transaction. It also means that external users (people who don't own the vault) can safely send money directly into the vault without coins being burned.
I have the proposal for this opcode up here: https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md . I'd love to hear what people think about it, what problems it might have that I've missed, or other issues or suggestions surrounding this. I'd also appreciate any input that would help me improve the presentation of the opcode.
Thanks!
This involves both specifying particular addresses the output is allowed to send coins to, as well as constraining the amount of the fee that output is allowed to contribute to. For example, if you had an output that contains 1000 satoshi, you could specify that a maximum of ~100 sats of that output go to the miner fee and the other ~900 sats must go to one of a list of specified addresses (~ meaning approximately, because the fee is specified relative to recent median fee rates - details in the proposal).
This opcode has a few different applications, but my primary motivation for creating this opcode is to create more flexible wallet vaults, which are basically wallet setups where you can cancel a payment for a predefined period of time (sometimes called the unvaulting time). These can be used to create far more secure cold wallet setups without a lot of the downsides. Some more info for the uninitiated https://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-vaults/.
To compare this opcode to OP_CHECKTEMPLATEVERIFY, wallet vaults that can be created with OP_CTV must be created in specified chunks: the address is explicitly tied to a particular utxo sent to it. To retrieve coins from the vault, the output must be spent by one of a specific set of transactions (potentially one per spend path). Outputs cannot be arbitrarily combined into a transaction, and there is no flexibility whatsoever in deciding options at the time of spending from the vault - all options must be premeditated and encoded into the address itself when sending money to the vault. This has some related foot-gun scenarios, where the wallet vault has addresses that if sent to would generally result in burning those coins, unless done in a very specific way by the owner of the vault.
By contrast, OP_CD allows a lot more flexibility because it only constrains the address to be sent to from the vault, but doesn't put additional constraints on the transaction. This means that outputs can be combined into a single transaction like you would expect in a normal transaction. It also means that external users (people who don't own the vault) can safely send money directly into the vault without coins being burned.
I have the proposal for this opcode up here: https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md . I'd love to hear what people think about it, what problems it might have that I've missed, or other issues or suggestions surrounding this. I'd also appreciate any input that would help me improve the presentation of the opcode.
Thanks!
Jump to: