How do you imagine preventing an attacker from spending all your coins at once and sending most of their value to fee? E.g. you have three 1 BTC outputs which require that the output be a 1 BTC payment to address bc1apple. A transaction which spends all three at once to a single 1 BTC bc1apple would comply, and yet turning 2 BTC to fees is probably not what you intended to permit.
In my opinion that BIP is essentially focused on a single use case but it kinda pretends to be more generic. The single use case absolutely requires no malleability, and that ends up creating a lot of limitations. But even without that, additional flexibility is difficult to get right. I think it would be worth the time to do it right. The protocol's author disagrees and instead believes he'll be able to ram it down the network's throat really quickly if he keeps it narrowed to his use case.
I hope the network does not deploy that proposal.
Topic: OP_CHECKTEMPLATEVERIFY - page 2. (Read 973 times)
I'm surprised there isn't already a discussion here about op_ctv. This is BIP 119: https://github.com/bitcoin/bips/blob/0042dec548f8c819df7ea48fdeec78af21974384/bip-0119.mediawiki
I'd like to specifically talk about the requirement of specifying an exact number of inputs that are required to spend the output. I understand the necessity of specifying exact inputs, but I don't understand the use case for specifying a number of inputs without specifying the exact inputs to spend. In addition, the BIP recognizes that committing to the sequences hash makes committing to a number of inputs "strictly redundant", but says doing so makes it easier to construct StandardTemplateHashes from the script.
Can anyone expand on what is said in the "Rationale: Committing to the number of inputs" section in the BIP?
The use case I'm concerned with is creating a timelocked cold wallet where arbitrary funds can be spent, but within some time-period the transaction can be reversed (for example, by a different higher priority key or by a multisig wallet with more keys than were used by the transaction being reversed). Requiring that op_ctv specify a specific number of inputs makes that use-case not generally possible or at best not efficient, since the wallet can contain many inputs, and in order to spend, you'd have to either have to spend each input one at a time, or you would have to have a large script that specifies optional op_ctv spends for every possible number of inputs you expect the wallet to have, which is obviously a bit of a pain and can go wrong if the wallet ends up having more inputs than you built the script for.
Why not make specifying the number of inputs an optional thing so that some people can use it when its necessary and some can omit it when its not?
I'd like to specifically talk about the requirement of specifying an exact number of inputs that are required to spend the output. I understand the necessity of specifying exact inputs, but I don't understand the use case for specifying a number of inputs without specifying the exact inputs to spend. In addition, the BIP recognizes that committing to the sequences hash makes committing to a number of inputs "strictly redundant", but says doing so makes it easier to construct StandardTemplateHashes from the script.
Can anyone expand on what is said in the "Rationale: Committing to the number of inputs" section in the BIP?
The use case I'm concerned with is creating a timelocked cold wallet where arbitrary funds can be spent, but within some time-period the transaction can be reversed (for example, by a different higher priority key or by a multisig wallet with more keys than were used by the transaction being reversed). Requiring that op_ctv specify a specific number of inputs makes that use-case not generally possible or at best not efficient, since the wallet can contain many inputs, and in order to spend, you'd have to either have to spend each input one at a time, or you would have to have a large script that specifies optional op_ctv spends for every possible number of inputs you expect the wallet to have, which is obviously a bit of a pain and can go wrong if the wallet ends up having more inputs than you built the script for.
Why not make specifying the number of inputs an optional thing so that some people can use it when its necessary and some can omit it when its not?
Jump to: