* [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) @ 2021-07-21 5:56 Billy Tetrud 2021-07-25 5:38 ` David A. Harding 0 siblings, 1 reply; 33+ messages in thread From: Billy Tetrud @ 2021-07-21 5:56 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2819 bytes --] Hi All, 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 <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 <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! [-- Attachment #2: Type: text/html, Size: 2964 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-21 5:56 [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) Billy Tetrud @ 2021-07-25 5:38 ` David A. Harding 2021-07-25 19:49 ` Billy Tetrud 0 siblings, 1 reply; 33+ messages in thread From: David A. Harding @ 2021-07-25 5:38 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2303 bytes --] On Tue, Jul 20, 2021 at 10:56:10PM -0700, Billy Tetrud via bitcoin-dev wrote: > This involves [...] constraining the amount of the fee that output is > allowed to contribute to. [...] fee is specified relative to recent > median fee rates - details in the proposal). Here are the relevant details: > The medianFeeRate is defined as the median fee rate per vbyte for the > most recent windowLength blocks. The maxFeeContribution is defined as > medianFeeRate * 2^feeFactor of the fee. Note that this is a limitation > on the fee, not on the fee-rate. If feeFactor is -1, > maxFeeContribution is 0. First, I don't think we want full nodes to have to store the feerate for every transaction in a 3,000 block window (~2.5 million txes, assuming all segwit). I'm sure you could tweak this proposal to require a much smaller dataset. Second, I think this requires careful consideration of how it might affect the incentives for miners. Miners can include many small high-fee pay-to-self transactions in their blocks to raise the median feerate, but this puts them at increased risk of fee sniping from other miners, which may incentivize fee-raisers to centralize their mining, which is ultimately bad. I'm not sure that's a huge concern with this proposal, but I think it and other incentive problems require consideration. Finally, I think this fee mechanism is redundant. For any case where this opcode will be used, you'll want to have two things: 1. A mutual spend clause (e.g. a multisignature taproot keypath spend) where all parties agree on a spend of the output and so can set an appropriate feerate at that time. You want this because it'll be the most efficient way to spend. 2. A fee override that allows paying additional fees beyond what OP_CONSTRAINDESTINATION allows, either through attaching an additional input or through CPFP. You want this because you will know more about feerate conditions at spend time than you did when you created the receiving script. If you have the ability to choose feerates through the above mechanisms, you don't need a constrained feerate mechanism that might be manipulable by miners. (I haven't looked closely at the rest of your proposal; the above just caught my attention.) -Dave [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-25 5:38 ` David A. Harding @ 2021-07-25 19:49 ` Billy Tetrud 2021-07-26 0:05 ` David A. Harding 2021-07-26 21:08 ` James MacWhyte 0 siblings, 2 replies; 33+ messages in thread From: Billy Tetrud @ 2021-07-25 19:49 UTC (permalink / raw) To: David A. Harding, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 7092 bytes --] Thanks for taking a look at the proposal David. I appreciate it. > I don't think we want full nodes to have to store the feerate for every transaction in a 3,000 block window That's a good point. It would probably be just as good to find the median fee-rate for each block and store that, then calculate the average of those stored per-block median numbers. Do you think that would be sufficiently cheap to store? > Miners can include many small high-fee pay-to-self transactions in their blocks to raise the median feerate Definitely a reasonable thing to consider. One point I want to make about that tho is that the opcode only limits how much of a particular output can be put towards the transaction fee - for the vast majority of transactions using this opcode, a lower fee would be used and the limit would be irrelevant (and therefore raising the median fee rate would not affect those transactions). The point of limiting the fee is to limit an attacker's ability to grief a victim by sending all their funds as transaction fee. So the only situations where miners would gain something from raising the fee rate is for griefing situations, which should be so rare as to be completely insignificant to miners. If griefing is not rare, something else is pretty broken. > I think this fee mechanism is redundant See above, but to break down that situation a bit further, these are the two situations I can think of: 1. The opcode limits user/group A to send the output to user/group B 2. The opcode limits user A to send from one address they own to another address they own. In case 1, user/group A could be the attacker that attempts to direct as much of the outputs as possible towards the fee (instead of the agreed upon recipient user/group B). In case 2, the attacker would be someone that steals a key from the user (eg in the case the attacker gets access to 1 key of the wallet vault keys) and attempts to grief them by making a transaction with the highest possible fee. In both these scenarios, the fee limit helps limit the amount of damage these attackers could do to their victim. Without a fee limit, these attack vectors could spend up to the full output amount as fee, which could be very damaging. > A mutual spend clause Have you considered the use case of wallet vaults? I designed this opcode primarily with wallet vaults in mind. In such a case there is a "mutual spend clause" of a kind - but all the keys may be owned by a single individual. One of the keys would be kept close at hand, and other keys would be kept in more secure and more difficult-to-access places (like a safe in a remote location). While the key-spend-path would be cheapest on chain, traveling to get the key itself might often be more expensive than using the script spend-path (because it takes time and effort to travel to those locations and access the keys). It might be informative to take a look at these wallet vault scripts <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md> that could use this opcode or the larger vision <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/README.md> I have for wallet vaults (which involves 2 other new opcodes). There are certainly also multi-user multisig use cases for OP_CD that have similar properties to this single-user use case. > A fee override that allows paying additional fees .. through attaching an additional input or through CPFP I definitely agree those are desirable mechanisms. To reiterate what I said above, the fee limitation is there to limit griefing attack vectors that spend an unreasonable amount of a particular output towards the fee. Spending *other* outputs (via either of those mechanisms) towards a transaction's fee is perfectly acceptable and doesn't undermine the purpose of the fee limitation. At its core, the limitation is there because the miner is another destination that the output's funds can be sent to, and while it wouldn't be wise to prevent an output from being spent as fee at all (because then the output is unspendable on its own, or with any other similarly constrained outputs), if OP_CD allowed spending the entire output as a fee then it wouldn't be successful in constraining the destination to the listed addresses. Do you see my points here, or do you still think the limitation is redundant? Thanks, BT On Sat, Jul 24, 2021 at 10:39 PM David A. Harding via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Tue, Jul 20, 2021 at 10:56:10PM -0700, Billy Tetrud via bitcoin-dev > wrote: > > This involves [...] constraining the amount of the fee that output is > > allowed to contribute to. [...] fee is specified relative to recent > > median fee rates - details in the proposal). > > Here are the relevant details: > > > The medianFeeRate is defined as the median fee rate per vbyte for the > > most recent windowLength blocks. The maxFeeContribution is defined as > > medianFeeRate * 2^feeFactor of the fee. Note that this is a limitation > > on the fee, not on the fee-rate. If feeFactor is -1, > > maxFeeContribution is 0. > > First, I don't think we want full nodes to have to store the feerate for > every transaction in a 3,000 block window (~2.5 million txes, assuming > all segwit). I'm sure you could tweak this proposal to require a much > smaller dataset. > > Second, I think this requires careful consideration of how it might > affect the incentives for miners. Miners can include many small high-fee > pay-to-self transactions in their blocks to raise the median feerate, > but this puts them at increased risk of fee sniping from other miners, > which may incentivize fee-raisers to centralize their mining, which is > ultimately bad. I'm not sure that's a huge concern with this proposal, > but I think it and other incentive problems require consideration. > > Finally, I think this fee mechanism is redundant. For any case where > this opcode will be used, you'll want to have two things: > > 1. A mutual spend clause (e.g. a multisignature taproot keypath > spend) where all parties agree on a spend of the output and so > can set an appropriate feerate at that time. You want this > because it'll be the most efficient way to spend. > > 2. A fee override that allows paying additional fees beyond what > OP_CONSTRAINDESTINATION allows, either through attaching an > additional input or through CPFP. You want this because you > will know more about feerate conditions at spend time than you > did when you created the receiving script. > > If you have the ability to choose feerates through the above mechanisms, > you don't need a constrained feerate mechanism that might be > manipulable by miners. > > (I haven't looked closely at the rest of your proposal; the above just > caught my attention.) > > -Dave > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 8332 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-25 19:49 ` Billy Tetrud @ 2021-07-26 0:05 ` David A. Harding [not found] ` <SN7PR18MB3981DC1CD23B90367045995FD2E89@SN7PR18MB3981.namprd18.prod.outlook.com> 2021-07-26 21:08 ` James MacWhyte 1 sibling, 1 reply; 33+ messages in thread From: David A. Harding @ 2021-07-26 0:05 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1839 bytes --] On Sun, Jul 25, 2021 at 12:49:38PM -0700, Billy Tetrud wrote: > find the median fee-rate for each block and store that, then calculate > the average of those stored per-block median numbers. One datapoint per block seems fine to me and it works much nicer with pruned nodes. > So the only situations where miners would gain something > from raising the fee rate is for griefing situations, which should be so > rare as to be completely insignificant to miners. I don't believe the problem scope can be reduced this way. Although we we often look at miners as separate from users, it's important to remember that every miner is also a user of Bitcoin and ever user of Bitcoin may also someday be a miner. Users may also employ miners directly via out-of-band payments. In your usecase of vaults, we can imagine Bob is attempting to store 100,000 BTC. He designs his vault to allow spending on fees up to 10x the 3,000 block median fee. Mallory steals Bob's encumbered spending key. Mallory could immediately go to a miner and offer them a 50/50 split on the 10x fees over the median (~10,000 sat?), or Mallory could take a bit more time and work with a cartel of miners to raise the median over a period of three weeks (3k blocks) to 10,000 BTC/transaction, allowing them to take all of Bob's coins in fees. > if OP_CD allowed spending the entire output as a fee then it wouldn't > be successful in constraining the destination to the listed addresses. The alternative is to never allow OP_CD to spend any of the UTXOs it encumbers to fees, requiring all fees be paid via another mechanism. Since satisfactory designs are going to provide those other mechanisms anyway, it seems to me that there's no need for OP_CD to manage fees. That said, I don't have a real strong opinion here. -Dave [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <SN7PR18MB3981DC1CD23B90367045995FD2E89@SN7PR18MB3981.namprd18.prod.outlook.com>]
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) [not found] ` <SN7PR18MB3981DC1CD23B90367045995FD2E89@SN7PR18MB3981.namprd18.prod.outlook.com> @ 2021-07-26 20:18 ` Billy Tetrud 0 siblings, 0 replies; 33+ messages in thread From: Billy Tetrud @ 2021-07-26 20:18 UTC (permalink / raw) To: Randy Fox; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6564 bytes --] > it's important to remember that every miner is also a user of Bitcoin and ever user of Bitcoin may also someday be a miner That's certainly true. One good quantification for how much of a problem this could be is to calculate the cost of the attack vs the damage done in the attack. So let me try to estimate that: Miners could collectively shift the fee rate up by sending payments to themselves, like you said. However, each one represents an opportunity cost of a low-value transaction. Given a bell curve distribution of transaction fee-rates, filling 15% of each block with these self-pay transactions could raise the median fee rate by about 1/4 of a standard deviation, or something probably around a 5% increase in median fee rate. This would lose miners approximately 5% of the fees for the blocks they did this for. So in order to do 1-to-1 damage (which would have them break even on the attack), there would have to be enough of these transactions to fill up maybe 1% of 3000 blocks (if we assume these transactions will generally have 10 times the fee-rate of the displaced low-value transactions). That would be on the order of hundreds of thousands of transactions. A shorter sample window would be easier to abuse this way, but even still likely at least hundreds of transactions would be needed to make up the difference. Manipulating fees this way has diminishing returns, meaning that filling a smaller percent of a block with high-fee self-payment transactions would lead to a greater increase in the median fee rate per amount of fees lost. Something interesting about this attack is that a successful attack would make the next attack easier, because mining these transactions from stolen keys would also help raise the median fee-rate a bit (tho only a fraction of the self-pay transactions that would still be necessary for the next round of attacks). And the above is a situation with 100% dishonest miners. With fewer dishonest miners, say 25%, the attack would have a much lower ROI. For the wallet vault use case, this is still a security improvement over a normal wallet, since in a normal wallet, a stolen key means all your funds can be stolen, but in an OP_CD wallet vault the attackers are still limited in how much can be stolen via the fee, stealing via the fee requires paying miners a cut to receive back some of the fee, and stealing extra (via raising the median fee rate) has a real cost placed on the miners. For multi-party scenarios, I think the fee limit might be slightly less effective. Eg in contracts where some money is promised to be sent to another person's address (e.g. congestion controlled payments), if a miner controls the sending address that miner can simply send the maximum fee to gain more money directly. The limit is still partially effective, but its definitely worth noting that malicious miners can abuse the fee limit mechanism. I would think manipulating the median fee rate is just as difficult in this scenario tho. > pay-to-self transactions .. puts them at increased risk of fee sniping from other miners, which may incentivize fee-raisers to centralize their mining This is an interesting point I forgot to respond to from your first email. I think even without the threat of fee-sniping, fee raisers would want to cartelize because coordinating the timing of attacks would reduce their collective costs. Tho fee-sniping would increase this pressure, I agree. It seems like cartels like this would have to get near the range of being able to 51% attack to really be effective tho. > The alternative is to never allow OP_CD to spend any of the UTXOs it encumbers to fees I agree that functionally this would work ok. However, both other mechanisms (gathering keys for a multisig spend or CPFP / adding other inputs) are likely to often be more expensive than letting the UTXO contribute to the fee directly. Also, it would complicate usability of these outputs, sometimes even making them unspendable by the user directly (in the case they don't have access to external outputs to contribute to the fee). In any case, I've updated my proposal with some of the things we've discussed. Thanks! @Randy What are you agreeing with? On Mon, Jul 26, 2021 at 5:59 AM Randy Fox <mrkingfoxx@hotmail•com> wrote: > Agree. > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > On Sunday, July 25, 2021, 7:07 PM, David A. Harding via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > On Sun, Jul 25, 2021 at 12:49:38PM -0700, Billy Tetrud wrote: > > find the median fee-rate for each block and store that, then calculate > > the average of those stored per-block median numbers. > > One datapoint per block seems fine to me and it works much nicer with > pruned nodes. > > > So the only situations where miners would gain something > > from raising the fee rate is for griefing situations, which should be so > > rare as to be completely insignificant to miners. > > I don't believe the problem scope can be reduced this way. Although we > we often look at miners as separate from users, it's important to > remember that every miner is also a user of Bitcoin and ever user of > Bitcoin may also someday be a miner. Users may also employ miners > directly via out-of-band payments. > > In your usecase of vaults, we can imagine Bob is attempting to store > 100,000 BTC. He designs his vault to allow spending on fees up to 10x > the 3,000 block median fee. Mallory steals Bob's encumbered spending > key. Mallory could immediately go to a miner and offer them a 50/50 > split on the 10x fees over the median (~10,000 sat?), or Mallory could > take a bit more time and work with a cartel of miners to raise the > median over a period of three weeks (3k blocks) to 10,000 > BTC/transaction, allowing them to take all of Bob's coins in fees. > > > if OP_CD allowed spending the entire output as a fee then it wouldn't > > be successful in constraining the destination to the listed addresses. > > The alternative is to never allow OP_CD to spend any of the UTXOs it > encumbers to fees, requiring all fees be paid via another mechanism. > Since satisfactory designs are going to provide those other mechanisms > anyway, it seems to me that there's no need for OP_CD to manage fees. > That said, I don't have a real strong opinion here. > > > -Dave > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 8417 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-25 19:49 ` Billy Tetrud 2021-07-26 0:05 ` David A. Harding @ 2021-07-26 21:08 ` James MacWhyte 2021-07-27 0:41 ` Billy Tetrud 1 sibling, 1 reply; 33+ messages in thread From: James MacWhyte @ 2021-07-26 21:08 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 698 bytes --] Hi Billy! See above, but to break down that situation a bit further, these are the > two situations I can think of: > > 1. The opcode limits user/group A to send the output to user/group B > 2. The opcode limits user A to send from one address they own to > another address they own. > > I'm trying to think of a good use case for this type of opcode. In these examples, an attacker who compromises the key for user A can't steal the money because it can only be sent to user B. So if the attacker wants to steal the funds, they would need to compromise the keys of both user A and user B. But how is that any better than a 2-of-2 multisig? Isn't the end result exactly the same? James [-- Attachment #2: Type: text/html, Size: 1256 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-26 21:08 ` James MacWhyte @ 2021-07-27 0:41 ` Billy Tetrud 2021-07-27 11:18 ` Zac Greenwood 0 siblings, 1 reply; 33+ messages in thread From: Billy Tetrud @ 2021-07-27 0:41 UTC (permalink / raw) To: James MacWhyte; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3411 bytes --] Hey James, In the examples you mentioned, what I was exploring was a mechanism of attack by which the attacker could steal user A's key and use that key to send a transaction with the maximum possible fee. User B would still receive some funds (probably), but if the fee could be large, the attacker would either do a lot of damage to user B (griefing) or could make an agreement with a miner to give back some of the large fee (theft). But as for use cases, the proposal mentions a number of use cases <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#motivation> and most overlap with the use cases of op_ctv <https://utxos.org/uses/> (Jeremy Rubin's website for op_ctv has a lot of good details, most of which are also relevant to op_cd). The use case I'm most interested in is wallet vaults. This opcode can be used to create a wallet vault where the user only needs to use, for example, 1 key to spend funds, but the attacker must steal 2 or more keys to spend funds. The benefits of a 2 key wallet vault like this vs a normal 2-of-2 multisig wallet are that not only does an attacker have to steal both keys (same level of security), but also the user can lose one key and still recover their funds (better redundancy) and also that generally the user doesn't need to access their second key - so that can remain in a much more secure location (which would also probably make that key harder to steal). The only time the second key only comes into play if one key is stolen and the attacker attempts to send a transaction. At that point, the user would go find and use his second key (along with the first) to send a revoke transaction to prevent the attacker from stealing their funds. This is somewhat akin to a lightning watchtower scenario, where your wallet would watch the chain and alert you about an unexpected transaction, at which point you'd manually do a revoke (vs a watchtower's automated response). You might be interested in taking a look at this wallet vault design <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md> that uses OP_CD or even my full vision <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> of the wallet vault I want to be able to create. With a covenant opcode like this, its possible to create very usable and accessible but highly secure wallets that can allow normal people to hold self custody of their keys without fear of loss or theft and without the hassle of a lot of safe deposit boxes (or other secure seed storage locations). Cheers, BT On Mon, Jul 26, 2021 at 2:08 PM James MacWhyte <macwhyte@gmail•com> wrote: > Hi Billy! > > See above, but to break down that situation a bit further, these are the >> two situations I can think of: >> >> 1. The opcode limits user/group A to send the output to user/group B >> 2. The opcode limits user A to send from one address they own to >> another address they own. >> >> I'm trying to think of a good use case for this type of opcode. In these > examples, an attacker who compromises the key for user A can't steal the > money because it can only be sent to user B. So if the attacker wants to > steal the funds, they would need to compromise the keys of both user A and > user B. > > But how is that any better than a 2-of-2 multisig? Isn't the end result > exactly the same? > > James > [-- Attachment #2: Type: text/html, Size: 4404 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-27 0:41 ` Billy Tetrud @ 2021-07-27 11:18 ` Zac Greenwood 2021-07-27 17:21 ` Billy Tetrud 0 siblings, 1 reply; 33+ messages in thread From: Zac Greenwood @ 2021-07-27 11:18 UTC (permalink / raw) To: Billy Tetrud, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4689 bytes --] Hi Billy, On the topic of wallet vaults, are there any plans to implement a way to limit the maximum amount to be sent from an address? An example of such limit might be: the maximum amount allowed to send is max(s, p) where s is a number of satoshi and p a percentage of the total available (sendable) amount. A minimum value may be imposed on the percentage to ensure that the address can be emptied within a reasonable number of transactions. The second parameter s allows a minimum permitted amount. (This is necessary because with only the percentage parameter the minimum permitted amount converges to zero, making it impossible to empty the address). There may be other ways too. In my view, such kind of restriction would be extremely effective in thwarting the most damaging type of theft being the one where all funds are swept in a single transaction. Zac On Tue, 27 Jul 2021 at 03:26, Billy Tetrud via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Hey James, > > In the examples you mentioned, what I was exploring was a mechanism of > attack by which the attacker could steal user A's key and use that key to > send a transaction with the maximum possible fee. User B would still > receive some funds (probably), but if the fee could be large, the attacker > would either do a lot of damage to user B (griefing) or could make an > agreement with a miner to give back some of the large fee (theft). > > But as for use cases, the proposal mentions a number of use cases > <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#motivation> and > most overlap with the use cases of op_ctv <https://utxos.org/uses/> (Jeremy > Rubin's website for op_ctv has a lot of good details, most of which are > also relevant to op_cd). The use case I'm most interested in is wallet > vaults. This opcode can be used to create a wallet vault where the user > only needs to use, for example, 1 key to spend funds, but the attacker must > steal 2 or more keys to spend funds. The benefits of a 2 key wallet vault > like this vs a normal 2-of-2 multisig wallet are that not only does an > attacker have to steal both keys (same level of security), but also the > user can lose one key and still recover their funds (better redundancy) and > also that generally the user doesn't need to access their second key - so > that can remain in a much more secure location (which would also probably > make that key harder to steal). The only time the second key only comes > into play if one key is stolen and the attacker attempts to send a > transaction. At that point, the user would go find and use his second key > (along with the first) to send a revoke transaction to prevent the attacker > from stealing their funds. This is somewhat akin to a lightning watchtower > scenario, where your wallet would watch the chain and alert you about an > unexpected transaction, at which point you'd manually do a revoke (vs a > watchtower's automated response). You might be interested in taking a look > at this wallet vault design > <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md> > that uses OP_CD or even my full vision > <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> of the > wallet vault I want to be able to create. > > With a covenant opcode like this, its possible to create very usable and > accessible but highly secure wallets that can allow normal people to hold > self custody of their keys without fear of loss or theft and without the > hassle of a lot of safe deposit boxes (or other secure seed storage > locations). > > Cheers, > BT > > > > > > On Mon, Jul 26, 2021 at 2:08 PM James MacWhyte <macwhyte@gmail•com> wrote: > >> Hi Billy! >> >> See above, but to break down that situation a bit further, these are the >>> two situations I can think of: >>> >>> 1. The opcode limits user/group A to send the output to user/group B >>> 2. The opcode limits user A to send from one address they own to >>> another address they own. >>> >>> I'm trying to think of a good use case for this type of opcode. In these >> examples, an attacker who compromises the key for user A can't steal the >> money because it can only be sent to user B. So if the attacker wants to >> steal the funds, they would need to compromise the keys of both user A and >> user B. >> >> But how is that any better than a 2-of-2 multisig? Isn't the end result >> exactly the same? >> >> James >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 6536 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-27 11:18 ` Zac Greenwood @ 2021-07-27 17:21 ` Billy Tetrud 2021-07-28 4:57 ` Zac Greenwood 0 siblings, 1 reply; 33+ messages in thread From: Billy Tetrud @ 2021-07-27 17:21 UTC (permalink / raw) To: Zac Greenwood; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8119 bytes --] Hi Zac, I haven't heard of any proposal for limiting the amount that can be sent from an address. I assume you mean limiting the amount that can be sent in a period of time - eg something that would encode that for address A, only X bitcoin can be sent from the address in a given day/week/etc, is that right? That would actually be a somewhat difficult thing to do in the output-based system Bitcoin uses, and would be easier in an account based system like Ethereum. The problem is that each output is separate, and there's no concept in bitcoin of encumbering outputs together. What you could do is design a system where coins would be combined in a single output, and then encumber that output with a script that allows a limited amount of coin be sent to a destination address and requires all other bitcoins be returned to sender in a new change output that is also timelocked. That way, the new change output can't be used again until the timelock expires (eg a week). However, to ensure this wallet works properly, any deposit into the wallet would have to also spend the wallet's single output, so as to create a new single output at that address. So 3rd parties wouldn't be able to arbitrarily send money in (or rather, they could, but each output would have its own separate spending limit). > such kind of restriction would be extremely effective in thwarting the most damaging type of theft being the one where all funds are swept in a single transaction It would. However a normal wallet vault basically already has this property - a thief can't simply sweep funds instantly, but instead the victim will see an initiated transaction and will be able to reverse it within a delay time-window. I don't think adding a spending limit would add meaningful security to a delayed-send wallet vault like that. But it could be used to increase the security of a wallet vault that can be instantly spent from - ie if the attacker successfully steals funds, then the victim has time to go gather their additional keys and move the remaining (unstolen) funds into a new wallet. OP_CD could potentially be augmented to allow specifying limit amounts for each destination, which would allow you to create a wallet like this. It would be a bit of an awkward wallet to use tho, since you couldn't receive directly into it from a 3rd party and you also couldn't keep separate outputs (which is bad for privacy). An alternate way of doing this that you don't need any new opcodes for would be to have a 3rd party service that signs multisig transactions from a wallet only up to a limit. The end-user could have additional keys such that the 3rd party can't prevent them from accessing that (if they turn uncooperative), and the 3rd party would only have a single key so they can't steal funds, but the user would sign a transaction with one key, and the 3rd party with another as long as the spending limit hasn't been reached. This wouldn't have much counterparty risk, but would be a less awkward wallet than what I described above - meaning anyone could send funds into the wallet without defeating the spending limit, and privacy could be kept intact (minus the fact that the 3rd party would know what your outputs are). BT On Tue, Jul 27, 2021 at 4:18 AM Zac Greenwood <zachgrw@gmail•com> wrote: > Hi Billy, > > On the topic of wallet vaults, are there any plans to implement a way to > limit the maximum amount to be sent from an address? > > An example of such limit might be: the maximum amount allowed to send is > max(s, p) where s is a number of satoshi and p a percentage of the total > available (sendable) amount. > > A minimum value may be imposed on the percentage to ensure that the > address can be emptied within a reasonable number of transactions. The > second parameter s allows a minimum permitted amount. (This is necessary > because with only the percentage parameter the minimum permitted amount > converges to zero, making it impossible to empty the address). > > There may be other ways too. In my view, such kind of restriction would be > extremely effective in thwarting the most damaging type of theft being the > one where all funds are swept in a single transaction. > > Zac > > > On Tue, 27 Jul 2021 at 03:26, Billy Tetrud via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Hey James, >> >> In the examples you mentioned, what I was exploring was a mechanism of >> attack by which the attacker could steal user A's key and use that key to >> send a transaction with the maximum possible fee. User B would still >> receive some funds (probably), but if the fee could be large, the attacker >> would either do a lot of damage to user B (griefing) or could make an >> agreement with a miner to give back some of the large fee (theft). >> >> But as for use cases, the proposal mentions a number of use cases >> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#motivation> and >> most overlap with the use cases of op_ctv <https://utxos.org/uses/> (Jeremy >> Rubin's website for op_ctv has a lot of good details, most of which are >> also relevant to op_cd). The use case I'm most interested in is wallet >> vaults. This opcode can be used to create a wallet vault where the user >> only needs to use, for example, 1 key to spend funds, but the attacker must >> steal 2 or more keys to spend funds. The benefits of a 2 key wallet vault >> like this vs a normal 2-of-2 multisig wallet are that not only does an >> attacker have to steal both keys (same level of security), but also the >> user can lose one key and still recover their funds (better redundancy) and >> also that generally the user doesn't need to access their second key - so >> that can remain in a much more secure location (which would also probably >> make that key harder to steal). The only time the second key only comes >> into play if one key is stolen and the attacker attempts to send a >> transaction. At that point, the user would go find and use his second key >> (along with the first) to send a revoke transaction to prevent the attacker >> from stealing their funds. This is somewhat akin to a lightning watchtower >> scenario, where your wallet would watch the chain and alert you about an >> unexpected transaction, at which point you'd manually do a revoke (vs a >> watchtower's automated response). You might be interested in taking a look >> at this wallet vault design >> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md> >> that uses OP_CD or even my full vision >> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> of the >> wallet vault I want to be able to create. >> >> With a covenant opcode like this, its possible to create very usable and >> accessible but highly secure wallets that can allow normal people to hold >> self custody of their keys without fear of loss or theft and without the >> hassle of a lot of safe deposit boxes (or other secure seed storage >> locations). >> >> Cheers, >> BT >> >> >> >> >> >> On Mon, Jul 26, 2021 at 2:08 PM James MacWhyte <macwhyte@gmail•com> >> wrote: >> >>> Hi Billy! >>> >>> See above, but to break down that situation a bit further, these are the >>>> two situations I can think of: >>>> >>>> 1. The opcode limits user/group A to send the output to user/group B >>>> 2. The opcode limits user A to send from one address they own to >>>> another address they own. >>>> >>>> I'm trying to think of a good use case for this type of opcode. In >>> these examples, an attacker who compromises the key for user A can't steal >>> the money because it can only be sent to user B. So if the attacker wants >>> to steal the funds, they would need to compromise the keys of both user A >>> and user B. >>> >>> But how is that any better than a 2-of-2 multisig? Isn't the end result >>> exactly the same? >>> >>> James >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > [-- Attachment #2: Type: text/html, Size: 10248 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-27 17:21 ` Billy Tetrud @ 2021-07-28 4:57 ` Zac Greenwood 2021-07-28 17:57 ` Billy Tetrud 0 siblings, 1 reply; 33+ messages in thread From: Zac Greenwood @ 2021-07-28 4:57 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 11380 bytes --] Hi Billy, Thank you for your comprehensive reply. My purpose was to find out whether a proposal to somehow limit the amount being sent from an address exists and to further illustrate my thoughts by giving a concrete example of how this might work functionally without getting to deep into the technicalities. As for your assumption: for an amount limit to have the desired effect, I realize now that there must also exist some limit on the number of transactions that will be allowed from the encumbered address. Taking a step back, a typical use case would be a speculating user intending to hodl bitcoin but who still wishes to be able to occasionally transact minor amounts. Ideally, such user should optionally still be able to bypass the rate limit and spend the entire amount in a single transaction by signing with an additional private key (multisig). During the setup phase, a user sends all their to-be-rate-limited coin to a single address. When spending from this rate limited address, any change sent to the change address must be rate limited as well using identical parameters. I believe that’s also what you’re suggesting. I believe that a smart wallet should be able to set up and maintain multiple rate-limited addresses in such a way that their aggregate behaviour meets any rate-limiting parameters as desired by the user. This ought to alleviate your privacy concerns because it means that the wallet will be able to mix outputs. The options for the to-be implemented rate-limiting parameters vary from completely arbitrary to more restrictive. Completely arbitrary parameters would allow users to set up a rate limit that basically destroys their funds, for instance rate-limiting an address to an amount of 1 satoshi per 100 blocks. More restrictive rate limits would remove such footgun and may require that only a combination of parameters are allowed such that all funds will be spendable within a set number of blocks (for instance 210,000). As for the rate-limiting parameters, in addition to a per-transaction maximum of (minimum amount in satoshi or a percentage of the total amount stored at the address), also the transaction frequency must be limited. I would propose this to be expressed as a number of blocks before a next transaction can be sent from the encumbered address(es). I believe such user-enabled rate-limiting is superior to one that requires a third party. As an aside, I am not sure how a vault solution would be able to prevent an attacker who is in possession of the vaults’ private key from sabotaging the user by replacing the user transaction with one having a higher fee every time the user attempts to transact. I am probably missing something here though. Zac On Tue, 27 Jul 2021 at 19:21, Billy Tetrud <billy.tetrud@gmail•com> wrote: > Hi Zac, > > I haven't heard of any proposal for limiting the amount that can be sent > from an address. I assume you mean limiting the amount that can be sent in > a period of time - eg something that would encode that for address A, only > X bitcoin can be sent from the address in a given day/week/etc, is that > right? That would actually be a somewhat difficult thing to do in the > output-based system Bitcoin uses, and would be easier in an account based > system like Ethereum. The problem is that each output is separate, and > there's no concept in bitcoin of encumbering outputs together. > > What you could do is design a system where coins would be combined in a > single output, and then encumber that output with a script that allows a > limited amount of coin be sent to a destination address and requires all > other bitcoins be returned to sender in a new change output that is also > timelocked. That way, the new change output can't be used again until the > timelock expires (eg a week). However, to ensure this wallet works > properly, any deposit into the wallet would have to also spend the wallet's > single output, so as to create a new single output at that address. So 3rd > parties wouldn't be able to arbitrarily send money in (or rather, they > could, but each output would have its own separate spending limit). > > > such kind of restriction would be extremely effective in thwarting the > most damaging type of theft being the one where all funds are swept in a > single transaction > > It would. However a normal wallet vault basically already has this > property - a thief can't simply sweep funds instantly, but instead the > victim will see an initiated transaction and will be able to reverse it > within a delay time-window. I don't think adding a spending limit would add > meaningful security to a delayed-send wallet vault like that. But it could > be used to increase the security of a wallet vault that can be instantly > spent from - ie if the attacker successfully steals funds, then the victim > has time to go gather their additional keys and move the remaining > (unstolen) funds into a new wallet. > > OP_CD could potentially be augmented to allow specifying limit amounts for > each destination, which would allow you to create a wallet like this. It > would be a bit of an awkward wallet to use tho, since you couldn't receive > directly into it from a 3rd party and you also couldn't keep separate > outputs (which is bad for privacy). > > An alternate way of doing this that you don't need any new opcodes for > would be to have a 3rd party service that signs multisig transactions from > a wallet only up to a limit. The end-user could have additional keys such > that the 3rd party can't prevent them from accessing that (if they turn > uncooperative), and the 3rd party would only have a single key so they > can't steal funds, but the user would sign a transaction with one key, and > the 3rd party with another as long as the spending limit hasn't been > reached. This wouldn't have much counterparty risk, but would be a less > awkward wallet than what I described above - meaning anyone could send > funds into the wallet without defeating the spending limit, and privacy > could be kept intact (minus the fact that the 3rd party would know what > your outputs are). > > BT > > On Tue, Jul 27, 2021 at 4:18 AM Zac Greenwood <zachgrw@gmail•com> wrote: > >> Hi Billy, >> >> On the topic of wallet vaults, are there any plans to implement a way to >> limit the maximum amount to be sent from an address? >> >> An example of such limit might be: the maximum amount allowed to send is >> max(s, p) where s is a number of satoshi and p a percentage of the total >> available (sendable) amount. >> >> A minimum value may be imposed on the percentage to ensure that the >> address can be emptied within a reasonable number of transactions. The >> second parameter s allows a minimum permitted amount. (This is necessary >> because with only the percentage parameter the minimum permitted amount >> converges to zero, making it impossible to empty the address). >> >> There may be other ways too. In my view, such kind of restriction would >> be extremely effective in thwarting the most damaging type of theft being >> the one where all funds are swept in a single transaction. >> >> Zac >> >> >> On Tue, 27 Jul 2021 at 03:26, Billy Tetrud via bitcoin-dev < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> >>> Hey James, >>> >>> In the examples you mentioned, what I was exploring was a mechanism of >>> attack by which the attacker could steal user A's key and use that key to >>> send a transaction with the maximum possible fee. User B would still >>> receive some funds (probably), but if the fee could be large, the attacker >>> would either do a lot of damage to user B (griefing) or could make an >>> agreement with a miner to give back some of the large fee (theft). >>> >>> But as for use cases, the proposal mentions a number of use cases >>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#motivation> and >>> most overlap with the use cases of op_ctv <https://utxos.org/uses/> (Jeremy >>> Rubin's website for op_ctv has a lot of good details, most of which are >>> also relevant to op_cd). The use case I'm most interested in is wallet >>> vaults. This opcode can be used to create a wallet vault where the user >>> only needs to use, for example, 1 key to spend funds, but the attacker must >>> steal 2 or more keys to spend funds. The benefits of a 2 key wallet vault >>> like this vs a normal 2-of-2 multisig wallet are that not only does an >>> attacker have to steal both keys (same level of security), but also the >>> user can lose one key and still recover their funds (better redundancy) and >>> also that generally the user doesn't need to access their second key - so >>> that can remain in a much more secure location (which would also probably >>> make that key harder to steal). The only time the second key only comes >>> into play if one key is stolen and the attacker attempts to send a >>> transaction. At that point, the user would go find and use his second key >>> (along with the first) to send a revoke transaction to prevent the attacker >>> from stealing their funds. This is somewhat akin to a lightning watchtower >>> scenario, where your wallet would watch the chain and alert you about an >>> unexpected transaction, at which point you'd manually do a revoke (vs a >>> watchtower's automated response). You might be interested in taking a look >>> at this wallet vault design >>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md> >>> that uses OP_CD or even my full vision >>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> of the >>> wallet vault I want to be able to create. >>> >>> With a covenant opcode like this, its possible to create very usable and >>> accessible but highly secure wallets that can allow normal people to hold >>> self custody of their keys without fear of loss or theft and without the >>> hassle of a lot of safe deposit boxes (or other secure seed storage >>> locations). >>> >>> Cheers, >>> BT >>> >>> >>> >>> >>> >>> On Mon, Jul 26, 2021 at 2:08 PM James MacWhyte <macwhyte@gmail•com> >>> wrote: >>> >>>> Hi Billy! >>>> >>>> See above, but to break down that situation a bit further, these are >>>>> the two situations I can think of: >>>>> >>>>> 1. The opcode limits user/group A to send the output to user/group >>>>> B >>>>> 2. The opcode limits user A to send from one address they own to >>>>> another address they own. >>>>> >>>>> I'm trying to think of a good use case for this type of opcode. In >>>> these examples, an attacker who compromises the key for user A can't steal >>>> the money because it can only be sent to user B. So if the attacker wants >>>> to steal the funds, they would need to compromise the keys of both user A >>>> and user B. >>>> >>>> But how is that any better than a 2-of-2 multisig? Isn't the end result >>>> exactly the same? >>>> >>>> James >>>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> [-- Attachment #2: Type: text/html, Size: 16676 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-28 4:57 ` Zac Greenwood @ 2021-07-28 17:57 ` Billy Tetrud 2021-07-28 22:30 ` Jeremy 2021-07-31 20:01 ` [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood 0 siblings, 2 replies; 33+ messages in thread From: Billy Tetrud @ 2021-07-28 17:57 UTC (permalink / raw) To: Zac Greenwood; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 14416 bytes --] Hi Zac, > a smart wallet should be able to set up and maintain multiple rate-limited addresses in such a way that their aggregate behaviour meets any rate-limiting parameters as desired by the user I think that would be possible if there was a way to say "within the last B blocks, this output can only spend to addresses other than X,Y,Z an amount less than C coins minus however much coins have been spent by those addresses in the last B blocks". This would require that full nodes keep around information about which addresses have been spent from recently, so that information is accessible during script execution. This could be made a bit less heavy by requiring countable transactions to run some particular opcode (so only opted-in transactions would need to be stored). > This ought to alleviate your privacy concerns because it means that the wallet will be able to mix outputs. The ability to mix outputs isn't a privacy issue. The ability to keep outputs separate is the privacy issue. For rate-limiting to work, the outputs must be associated with eachother so that rate limiting can take them all into account. It seems to me that its fundamentally impossible to do this while keeping outputs uncorrelated. > such user-enabled rate-limiting is superior to one that requires a third party. Removing a 3rd party certainly has upsides. However, using a 3rd party would be able to solve the privacy issue by keeping outputs uncorrelated (in different addresses) to the outside world. Trade offs. In any case, if you want to continue talking about rate-limiting transactions, it might be a good idea to start a new thread for that, since its a bit off topic for this one. > how a vault solution would be able to prevent an attacker who is in possession of the vaults’ private key from sabotaging the user by replacing the user transaction with one having a higher fee every time the user attempts to transact A wallet vault has multiple keys. If one key is stolen, the user can use two keys to override the attacker's transaction. If two keys are stolen, the user can use three keys. Etc. The attacker must have as many keys as the user can use in order to successfully steal funds. This can happen in one of these kinds of ways: A. The attacker steals all keys. B. The attacker steals half the keys and ensures that the victim doesn't have access to those keys (eg the attacker steals the only copy of half the keys). C. The attacker steals any key and incapacitates the victim for the entire cooldown period, so they can't use any of their keys. In case C, it would be useful to have rate limiting actually. On Tue, Jul 27, 2021 at 9:57 PM Zac Greenwood <zachgrw@gmail•com> wrote: > Hi Billy, > > Thank you for your comprehensive reply. My purpose was to find out whether > a proposal to somehow limit the amount being sent from an address exists > and to further illustrate my thoughts by giving a concrete example of how > this might work functionally without getting to deep into the > technicalities. > > As for your assumption: for an amount limit to have the desired effect, I > realize now that there must also exist some limit on the number of > transactions that will be allowed from the encumbered address. > > Taking a step back, a typical use case would be a speculating user > intending to hodl bitcoin but who still wishes to be able to occasionally > transact minor amounts. > > Ideally, such user should optionally still be able to bypass the rate > limit and spend the entire amount in a single transaction by signing with > an additional private key (multisig). > > During the setup phase, a user sends all their to-be-rate-limited coin to > a single address. When spending from this rate limited address, any change > sent to the change address must be rate limited as well using identical > parameters. I believe that’s also what you’re suggesting. > > I believe that a smart wallet should be able to set up and maintain > multiple rate-limited addresses in such a way that their aggregate > behaviour meets any rate-limiting parameters as desired by the user. This > ought to alleviate your privacy concerns because it means that the wallet > will be able to mix outputs. > > The options for the to-be implemented rate-limiting parameters vary from > completely arbitrary to more restrictive. > > Completely arbitrary parameters would allow users to set up a rate limit > that basically destroys their funds, for instance rate-limiting an address > to an amount of 1 satoshi per 100 blocks. > > More restrictive rate limits would remove such footgun and may require > that only a combination of parameters are allowed such that all funds will > be spendable within a set number of blocks (for instance 210,000). > > As for the rate-limiting parameters, in addition to a per-transaction > maximum of (minimum amount in satoshi or a percentage of the total amount > stored at the address), also the transaction frequency must be limited. I > would propose this to be expressed as a number of blocks before a next > transaction can be sent from the encumbered address(es). > > I believe such user-enabled rate-limiting is superior to one that requires > a third party. > > As an aside, I am not sure how a vault solution would be able to prevent > an attacker who is in possession of the vaults’ private key from sabotaging > the user by replacing the user transaction with one having a higher fee > every time the user attempts to transact. I am probably missing something > here though. > > Zac > > > On Tue, 27 Jul 2021 at 19:21, Billy Tetrud <billy.tetrud@gmail•com> wrote: > >> Hi Zac, >> >> I haven't heard of any proposal for limiting the amount that can be sent >> from an address. I assume you mean limiting the amount that can be sent in >> a period of time - eg something that would encode that for address A, only >> X bitcoin can be sent from the address in a given day/week/etc, is that >> right? That would actually be a somewhat difficult thing to do in the >> output-based system Bitcoin uses, and would be easier in an account based >> system like Ethereum. The problem is that each output is separate, and >> there's no concept in bitcoin of encumbering outputs together. >> >> What you could do is design a system where coins would be combined in a >> single output, and then encumber that output with a script that allows a >> limited amount of coin be sent to a destination address and requires all >> other bitcoins be returned to sender in a new change output that is also >> timelocked. That way, the new change output can't be used again until the >> timelock expires (eg a week). However, to ensure this wallet works >> properly, any deposit into the wallet would have to also spend the wallet's >> single output, so as to create a new single output at that address. So 3rd >> parties wouldn't be able to arbitrarily send money in (or rather, they >> could, but each output would have its own separate spending limit). >> >> > such kind of restriction would be extremely effective in thwarting the >> most damaging type of theft being the one where all funds are swept in a >> single transaction >> >> It would. However a normal wallet vault basically already has this >> property - a thief can't simply sweep funds instantly, but instead the >> victim will see an initiated transaction and will be able to reverse it >> within a delay time-window. I don't think adding a spending limit would add >> meaningful security to a delayed-send wallet vault like that. But it could >> be used to increase the security of a wallet vault that can be instantly >> spent from - ie if the attacker successfully steals funds, then the victim >> has time to go gather their additional keys and move the remaining >> (unstolen) funds into a new wallet. >> >> OP_CD could potentially be augmented to allow specifying limit amounts >> for each destination, which would allow you to create a wallet like this. >> It would be a bit of an awkward wallet to use tho, since you couldn't >> receive directly into it from a 3rd party and you also couldn't keep >> separate outputs (which is bad for privacy). >> >> An alternate way of doing this that you don't need any new opcodes for >> would be to have a 3rd party service that signs multisig transactions from >> a wallet only up to a limit. The end-user could have additional keys such >> that the 3rd party can't prevent them from accessing that (if they turn >> uncooperative), and the 3rd party would only have a single key so they >> can't steal funds, but the user would sign a transaction with one key, and >> the 3rd party with another as long as the spending limit hasn't been >> reached. This wouldn't have much counterparty risk, but would be a less >> awkward wallet than what I described above - meaning anyone could send >> funds into the wallet without defeating the spending limit, and privacy >> could be kept intact (minus the fact that the 3rd party would know what >> your outputs are). >> >> BT >> >> On Tue, Jul 27, 2021 at 4:18 AM Zac Greenwood <zachgrw@gmail•com> wrote: >> >>> Hi Billy, >>> >>> On the topic of wallet vaults, are there any plans to implement a way to >>> limit the maximum amount to be sent from an address? >>> >>> An example of such limit might be: the maximum amount allowed to send is >>> max(s, p) where s is a number of satoshi and p a percentage of the total >>> available (sendable) amount. >>> >>> A minimum value may be imposed on the percentage to ensure that the >>> address can be emptied within a reasonable number of transactions. The >>> second parameter s allows a minimum permitted amount. (This is necessary >>> because with only the percentage parameter the minimum permitted amount >>> converges to zero, making it impossible to empty the address). >>> >>> There may be other ways too. In my view, such kind of restriction would >>> be extremely effective in thwarting the most damaging type of theft being >>> the one where all funds are swept in a single transaction. >>> >>> Zac >>> >>> >>> On Tue, 27 Jul 2021 at 03:26, Billy Tetrud via bitcoin-dev < >>> bitcoin-dev@lists•linuxfoundation.org> wrote: >>> >>>> Hey James, >>>> >>>> In the examples you mentioned, what I was exploring was a mechanism of >>>> attack by which the attacker could steal user A's key and use that key to >>>> send a transaction with the maximum possible fee. User B would still >>>> receive some funds (probably), but if the fee could be large, the attacker >>>> would either do a lot of damage to user B (griefing) or could make an >>>> agreement with a miner to give back some of the large fee (theft). >>>> >>>> But as for use cases, the proposal mentions a number of use cases >>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#motivation> and >>>> most overlap with the use cases of op_ctv <https://utxos.org/uses/> (Jeremy >>>> Rubin's website for op_ctv has a lot of good details, most of which are >>>> also relevant to op_cd). The use case I'm most interested in is wallet >>>> vaults. This opcode can be used to create a wallet vault where the user >>>> only needs to use, for example, 1 key to spend funds, but the attacker must >>>> steal 2 or more keys to spend funds. The benefits of a 2 key wallet vault >>>> like this vs a normal 2-of-2 multisig wallet are that not only does an >>>> attacker have to steal both keys (same level of security), but also the >>>> user can lose one key and still recover their funds (better redundancy) and >>>> also that generally the user doesn't need to access their second key - so >>>> that can remain in a much more secure location (which would also probably >>>> make that key harder to steal). The only time the second key only comes >>>> into play if one key is stolen and the attacker attempts to send a >>>> transaction. At that point, the user would go find and use his second key >>>> (along with the first) to send a revoke transaction to prevent the attacker >>>> from stealing their funds. This is somewhat akin to a lightning watchtower >>>> scenario, where your wallet would watch the chain and alert you about an >>>> unexpected transaction, at which point you'd manually do a revoke (vs a >>>> watchtower's automated response). You might be interested in taking a look >>>> at this wallet vault design >>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md> >>>> that uses OP_CD or even my full vision >>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> of the >>>> wallet vault I want to be able to create. >>>> >>>> With a covenant opcode like this, its possible to create very usable >>>> and accessible but highly secure wallets that can allow normal people to >>>> hold self custody of their keys without fear of loss or theft and without >>>> the hassle of a lot of safe deposit boxes (or other secure seed storage >>>> locations). >>>> >>>> Cheers, >>>> BT >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Jul 26, 2021 at 2:08 PM James MacWhyte <macwhyte@gmail•com> >>>> wrote: >>>> >>>>> Hi Billy! >>>>> >>>>> See above, but to break down that situation a bit further, these are >>>>>> the two situations I can think of: >>>>>> >>>>>> 1. The opcode limits user/group A to send the output to >>>>>> user/group B >>>>>> 2. The opcode limits user A to send from one address they own to >>>>>> another address they own. >>>>>> >>>>>> I'm trying to think of a good use case for this type of opcode. In >>>>> these examples, an attacker who compromises the key for user A can't steal >>>>> the money because it can only be sent to user B. So if the attacker wants >>>>> to steal the funds, they would need to compromise the keys of both user A >>>>> and user B. >>>>> >>>>> But how is that any better than a 2-of-2 multisig? Isn't the end >>>>> result exactly the same? >>>>> >>>>> James >>>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists•linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>> [-- Attachment #2: Type: text/html, Size: 21448 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-28 17:57 ` Billy Tetrud @ 2021-07-28 22:30 ` Jeremy 2021-07-30 18:42 ` Billy Tetrud 2021-07-31 20:01 ` [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood 1 sibling, 1 reply; 33+ messages in thread From: Jeremy @ 2021-07-28 22:30 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 433 bytes --] High level feedback: you should spec out the opcodes as separate pieces of functionality as it sounds like OP_CD is really 3 or 4 opcodes in one (e.g., amounts to outputs, output addresses, something with fees). One major drawback of your approach is that all transactions are twice as large as they might otherwise need to be for simple things like congestion control trees, since you have to repeat all of the output data twice. [-- Attachment #2: Type: text/html, Size: 1137 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-28 22:30 ` Jeremy @ 2021-07-30 18:42 ` Billy Tetrud 2021-11-01 1:19 ` Billy Tetrud 0 siblings, 1 reply; 33+ messages in thread From: Billy Tetrud @ 2021-07-30 18:42 UTC (permalink / raw) To: Jeremy, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3520 bytes --] Thanks for taking another look Jeremy. That's an interesting idea to split it up into simpler opcodes, however there are some limitations/considerations there. For example, with output addresses, I added specifying amounts to outputs in order to make script evaluation simpler and eliminate a potential DOS vector. I wrote about this in the section 'Specifying values sent to each output <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#specifying-values-sent-to-each-output>'. Originally, I designed OP_CD without specifying what amounts an input contributes to what outputs, but it seemed like this would require calculating various combinations of inequalities, which could get expensive in scenarios where many inputs had overlapping destinations. See the examples under the OP_CD section in this commit <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/commit/9b2257410b5f0fc991f68e774c3faf601c02cc5d> . Maybe there's an elegant and cheap way of verifying that a number of inputs that have destination address limitations is within limits, but if so I don't know how to do that. If there was a good way to do that, then I wouldn't want to propose the ability to validate that specific amounts go to specific outputs. So unless there's a simple and dos-vector-free way of evaluating what addresses an input goes to without knowing what amounts an input contributes to each output, I don't think these functionalities should be separated. And about a fee-limit opcode, that could certainly be done on its own. However, a version of OP_CD that doesn't specify fees would have to take the fee-limit into account, and the calculation for the stand-alone fee-limit operation would be moot for that output. So I think it could make sense to split the fee limit off from the rest of OP_CD. I'm curious to know what others think of that. > all transactions are twice as large as they might otherwise need to be for simple things like congestion control trees, since you have to repeat all of the output data twice Well, the transaction wouldn't be quite twice as large. Each output would add 9 bytes to the transaction, and outputs already are a minimum of about 30 bytes I think? So for transactions with a lot of outputs, it could make the transaction about 1/3 larger. I'll add a section on this into my proposal. Perhaps it would be a reasonable optimization to allow omitting an output value in cases where the entire output amount is contributed by that input. This would reduce the overhead of specifying output amounts to 2 bytes for most outputs (1 byte for the index, another to indicate the full value), meaning that it would only make the transaction about 7% larger. What do you think about that idea? On Wed, Jul 28, 2021 at 3:30 PM Jeremy via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > High level feedback: > > you should spec out the opcodes as separate pieces of functionality as it > sounds like OP_CD is really 3 or 4 opcodes in one (e.g., amounts to > outputs, output addresses, something with fees). > > One major drawback of your approach is that all transactions are twice as > large as they might otherwise need to be for simple things like congestion > control trees, since you have to repeat all of the output data twice. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 5423 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 2021-07-30 18:42 ` Billy Tetrud @ 2021-11-01 1:19 ` Billy Tetrud 0 siblings, 0 replies; 33+ messages in thread From: Billy Tetrud @ 2021-11-01 1:19 UTC (permalink / raw) To: Jeremy, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3945 bytes --] FYI I broke out the fee limiting functionality from OP_CD into an opcode called OP_LIMITFEECONTRIBUTION <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/lfc/bip-limit-fee-contribution.md> as Jeremy suggested. On Fri, Jul 30, 2021 at 1:42 PM Billy Tetrud <billy.tetrud@gmail•com> wrote: > Thanks for taking another look Jeremy. That's an interesting idea to split > it up into simpler opcodes, however there are some > limitations/considerations there. > > For example, with output addresses, I added specifying amounts to outputs > in order to make script evaluation simpler and eliminate a potential DOS > vector. I wrote about this in the section 'Specifying values sent to each > output > <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#specifying-values-sent-to-each-output>'. > Originally, I designed OP_CD without specifying what amounts an input > contributes to what outputs, but it seemed like this would require > calculating various combinations of inequalities, which could get expensive > in scenarios where many inputs had overlapping destinations. See the > examples under the OP_CD section in this commit > <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/commit/9b2257410b5f0fc991f68e774c3faf601c02cc5d> > . > > Maybe there's an elegant and cheap way of verifying that a number of > inputs that have destination address limitations is within limits, but if > so I don't know how to do that. If there was a good way to do that, then I > wouldn't want to propose the ability to validate that specific amounts go > to specific outputs. So unless there's a simple and dos-vector-free way of > evaluating what addresses an input goes to without knowing what amounts an > input contributes to each output, I don't think these functionalities > should be separated. > > And about a fee-limit opcode, that could certainly be done on its own. > However, a version of OP_CD that doesn't specify fees would have to take > the fee-limit into account, and the calculation for the stand-alone > fee-limit operation would be moot for that output. > > So I think it could make sense to split the fee limit off from the rest of > OP_CD. I'm curious to know what others think of that. > > > all transactions are twice as large as they might otherwise need to be > for simple things like congestion control trees, since you have to repeat > all of the output data twice > > Well, the transaction wouldn't be quite twice as large. Each output would > add 9 bytes to the transaction, and outputs already are a minimum of about > 30 bytes I think? So for transactions with a lot of outputs, it could make > the transaction about 1/3 larger. I'll add a section on this into my > proposal. > > Perhaps it would be a reasonable optimization to allow omitting an output > value in cases where the entire output amount is contributed by that input. > This would reduce the overhead of specifying output amounts to 2 bytes for > most outputs (1 byte for the index, another to indicate the full value), > meaning that it would only make the transaction about 7% larger. What do > you think about that idea? > > On Wed, Jul 28, 2021 at 3:30 PM Jeremy via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> High level feedback: >> >> you should spec out the opcodes as separate pieces of functionality as it >> sounds like OP_CD is really 3 or 4 opcodes in one (e.g., amounts to >> outputs, output addresses, something with fees). >> >> One major drawback of your approach is that all transactions are twice as >> large as they might otherwise need to be for simple things like congestion >> control trees, since you have to repeat all of the output data twice. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > [-- Attachment #2: Type: text/html, Size: 6076 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-07-28 17:57 ` Billy Tetrud 2021-07-28 22:30 ` Jeremy @ 2021-07-31 20:01 ` Zac Greenwood 2021-08-02 4:40 ` Billy Tetrud 2021-08-10 2:17 ` ZmnSCPxj 1 sibling, 2 replies; 33+ messages in thread From: Zac Greenwood @ 2021-07-31 20:01 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6288 bytes --] Hi list, I'd like to explore whether it is feasible to implement new scripting capabilities in Bitcoin that enable limiting the output amount of a transaction based on the total value of its inputs. In other words, to implement the ability to limit the maximum amount that can be sent from an address. Two use cases come to mind: UC1: enable a user to add additional protection their funds by rate-limiting the amount they are able to send during a certain period (measured in blocks). A typical use case might be a user that intends to hodl their bitcoin, but still wishes to occasionally send small amounts. This avoids an attacker from sweeping all their funds in a single transaction, allowing the user to become aware of the theft and intervene to prevent further theft. UC2: exchanges may wish to rate-limit addresses containing large amounts of bitcoin, adding warm- or hot-wallet functionality to a cold-storage address. This would enable an exchange to drastically reduce the number of times a cold wallet must be accessed with private keys that enable access to the full amount. In a typical setup, I'd envision using multisig such that the user has two sets of private keys to their encumbered address (with a "set" of keys meaning "one or more" keys). One set of private keys allows only for sending with rate-limiting restrictions in place, and a s second set of private keys allowing for sending any amount without rate-limiting, effectively overriding such restriction. The parameters that define in what way an output is rate-limited might be defined as follows: Param 1: a block height "h0" indicating the first block height of an epoch; Param 2: a block height "h1" indicating the last block height of an epoch; Param 3: an amount "a" in satoshi indicating the maximum amount that is allowed to be sent in any epoch; Param 4: an amount "a_remaining" (in satoshi) indicating the maximum amount that is allowed to be sent within the current epoch. For example, consider an input containing 100m sats (1 BTC) which has been rate-limited with parameters (h0, h1, a, a_remaning) of (800000, 800143, 500k, 500k). These parameters define that the address is rate-limited to sending a maximum of 500k sats in the current epoch that starts at block height 800000 and ends at height 800143 (or about one day ignoring block time variance) and that the full amount of 500k is still sendable. These rate-limiting parameters ensure that it takes at minimum 100m / 500k = 200 transactions and 200 x 144 blocks or about 200 days to spend the full 100m sats. As noted earlier, in a typical setup a user should retain the option to transact the entire amount using a second (set of) private key(s). For rate-limiting to work, any change output created by a transaction from a rate-limited address must itself be rate-limited as well. For instance, expanding on the above example, assume that the user spends 200k sats from a rate-limited address a1 containing 100m sats: Start situation: At block height 800000: rate-limited address a1 is created; Value of a1: 100.0m sats; Rate limiting params of a1: h0=800000, h1=800143, a=500k, a_remaining=500k; Transaction t1: Included at block height 800100; Spend: 200k + fee; Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k. Result: Value at destination address: 200k sats; Rate limiting params at destination address: none; Value at change address a2: 99.8m sats; Rate limiting params at change address a2: h0=800000, h1=800143, a=500k, a_remaining=300k. In order to properly enforce rate limiting, the change address must be rate-limited such that the original rate limit of 500k sats per 144 blocks cannot be exceeded. In this example, the change address a2 were given the same rate limiting parameters as the transaction that served as its input. As a result, from block 800100 up until and including block 800143, a maximum amount of 300k sats is allowed to be spent from the change address. Example continued: a2: 99.8 sats at height 800100; Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; Transaction t2: Included at block height 800200 Spend: 400k + fees. Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. Result: Value at destination address: 400k sats; Rate limiting params at destination address: none; Value at change address a3: 99.4m sats; Rate limiting params at change address a3: h0=800144, h1=800287, a=500k, a_remaining=100k. Transaction t2 is allowed because it falls within the next epoch (running from 800144 to 800287) so a spend of 400k does not violate the constraint of 500k per epoch. As could be seen, the rate limiting parameters are part of the transaction and chosen by the user (or their wallet). This means that the parameters must be validated to ensure that they do not violate the intended constraints. For instance, this transaction should not be allowed: a2: 99.8 sats at height 800100; Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k; Transaction t2a: Included at block height 800200; Spend: 400k + fees; Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k. This transaction t2a attempts to shift the epoch forward by 20 blocks such that it starts at 800124 instead of 800144. Shifting the epoch forward like this must not be allowed because it enables spending more that the rate limit allows, which is 500k in any epoch of 144 blocks. It would enable overspending: t1: spend 200k at 800100 (epoch 1: total: 200k); t2a: spend 400k at 800200 (epoch 2: total: 400k); t3a: spend 100k at 800201 (epoch 2: total: 500k); t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for epoch 2). Specifying the rate-limiting parameters explicitly at every transaction allows the user to tighten the spending limit by setting tighter limits or for instance by setting a_remainder to 0 if they wish to enforce not spending more during an epoch. I will stop here because I would like to gauge interest in this idea first before continuing work on other aspects. Two main pieces of work jump to mind: Define all validations; Describe aggregate behaviour of multiple (rate-limited) inputs, proof that two rate-limited addresses cannot spend more than the sum of their individual limits. Zac [-- Attachment #2: Type: text/html, Size: 7469 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-07-31 20:01 ` [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood @ 2021-08-02 4:40 ` Billy Tetrud 2021-08-10 2:17 ` ZmnSCPxj 1 sibling, 0 replies; 33+ messages in thread From: Billy Tetrud @ 2021-08-02 4:40 UTC (permalink / raw) To: Zac Greenwood, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 10705 bytes --] Hey Zac, I think this could be a useful opcode. It kinda seems like UC1 and UC2 are basically the same use case: using rate-limiting to reduce risk of theft or mistake. I think this could be a helpful addition to a good wallet setup. I don't quite understand why you'd want to define a specific span of blocks for the rate limit. Why not just specify the size of the window (in blocks) to rate limit within, and the limit? You mentioned change addresses, however, with the parameters you defined, there would be no way to connect together the change address with the original address, meaning they would have completely separate rate limits, which wouldn't work since the change output would ignore the previous rate limit. I can think of the following options: A. You could always send change back to the *same* address. This is the simplest option, and the only downside I can think of is exposing the public key of an address. I'm not quite sure what the consensus is on the dangers of exposing the public key. It theoretically reduces quantum resistance a bit, but I think I read that some of taproot's mechanisms expose the bare public key, so maybe consensus has changed about that in recent years? B. Have some way to specify connected addresses in the output. This has the edge case that one of the addresses wouldn't be able to specify all the addresses that it should be connected with, because it would create a hash loop (ie if you had address A and B that should be connected, you can create address A and then specify that address B be connected to address A, but address A cannot specify its connection to B because A was created before B was created). You wouldn't want one address to be able to simply define a connection to another address, because this would open up attack vectors where people could encumber other people's addresses with rate limits connected to theirs. You could define connections based on signatures, which could be done without creating a hash loop, however it would require exposing the public keys of other addresses when you do that, at which point you might as well go with option A. C. You could specify that rate limits follow a certain output. Eg, if you create a transaction with destination output 1 and change output 2, your rate limiting opcode could specify that output 2 should inherit the rate limit. These inherited rate limits could all be connected together automatically. Another consideration is what to use for a receive-address. I would say the simplest option here is to receive at an address that contains an existing output already. If you allowed receiving at an address that contains no coins, you'd have to specify at least one other address to connect it with. This could work, but I don't see any advantage to it, since you don't gain any privacy by creating a new address if you're going to immediately programmatically tie it to the other addresses. One thing to consider is the cost of carrying around and checking these rate limits. Ideally it should be a very small amount of data carried around in the UTXO set, and be very cheap to verify when the opcode comes up. I think it would make sense for such an opcode to only be able to track rate-limits over short spans, like a month or less. Allowing the user to specify an arbitrary window over which to track a rate-limit seems like something that would probably open up a dos vector or other node resource usage abuse attacks. It might be useful enough to simply rate limit over each epoch (two weeks), but having a small set of options could also be useful (eg 1 day, 1 week, or 1 month). In any case, I'd be interested in seeing you write a BIP for this. Of course, don't take my word as community interest. I'm reasonably new to the bitcoin dev community, so definitely don't jump the gun based on my interest. On Sat, Jul 31, 2021 at 2:51 PM Zac Greenwood via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Hi list, > > I'd like to explore whether it is feasible to implement new scripting > capabilities in Bitcoin that enable limiting the output amount of a > transaction based on the total value of its inputs. In other words, to > implement the ability to limit the maximum amount that can be sent from an > address. > > Two use cases come to mind: > > UC1: enable a user to add additional protection their funds by > rate-limiting the amount they are able to send during a certain period > (measured in blocks). A typical use case might be a user that intends to > hodl their bitcoin, but still wishes to occasionally send small amounts. > This avoids an attacker from sweeping all their funds in a single > transaction, allowing the user to become aware of the theft and intervene > to prevent further theft. > > UC2: exchanges may wish to rate-limit addresses containing large amounts > of bitcoin, adding warm- or hot-wallet functionality to a cold-storage > address. This would enable an exchange to drastically reduce the number of > times a cold wallet must be accessed with private keys that enable access > to the full amount. > > In a typical setup, I'd envision using multisig such that the user has two > sets of private keys to their encumbered address (with a "set" of keys > meaning "one or more" keys). One set of private keys allows only for > sending with rate-limiting restrictions in place, and a s second set of > private keys allowing for sending any amount without rate-limiting, > effectively overriding such restriction. > > The parameters that define in what way an output is rate-limited might be > defined as follows: > > Param 1: a block height "h0" indicating the first block height of an epoch; > Param 2: a block height "h1" indicating the last block height of an epoch; > Param 3: an amount "a" in satoshi indicating the maximum amount that is > allowed to be sent in any epoch; > Param 4: an amount "a_remaining" (in satoshi) indicating the maximum > amount that is allowed to be sent within the current epoch. > > For example, consider an input containing 100m sats (1 BTC) which has been > rate-limited with parameters (h0, h1, a, a_remaning) of (800000, 800143, > 500k, 500k). These parameters define that the address is rate-limited to > sending a maximum of 500k sats in the current epoch that starts at block > height 800000 and ends at height 800143 (or about one day ignoring block > time variance) and that the full amount of 500k is still sendable. These > rate-limiting parameters ensure that it takes at minimum 100m / 500k = 200 > transactions and 200 x 144 blocks or about 200 days to spend the full 100m > sats. As noted earlier, in a typical setup a user should retain the option > to transact the entire amount using a second (set of) private key(s). > > For rate-limiting to work, any change output created by a transaction from > a rate-limited address must itself be rate-limited as well. For instance, > expanding on the above example, assume that the user spends 200k sats from > a rate-limited address a1 containing 100m sats: > > Start situation: > At block height 800000: rate-limited address a1 is created; > Value of a1: 100.0m sats; > Rate limiting params of a1: h0=800000, h1=800143, a=500k, a_remaining=500k; > > Transaction t1: > Included at block height 800100; > Spend: 200k + fee; > Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k. > > Result: > Value at destination address: 200k sats; > Rate limiting params at destination address: none; > Value at change address a2: 99.8m sats; > Rate limiting params at change address a2: h0=800000, h1=800143, a=500k, > a_remaining=300k. > > In order to properly enforce rate limiting, the change address must be > rate-limited such that the original rate limit of 500k sats per 144 blocks > cannot be exceeded. In this example, the change address a2 were given the > same rate limiting parameters as the transaction that served as its input. > As a result, from block 800100 up until and including block 800143, a > maximum amount of 300k sats is allowed to be spent from the change address. > > Example continued: > a2: 99.8 sats at height 800100; > Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; > > Transaction t2: > Included at block height 800200 > Spend: 400k + fees. > Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. > > Result: > Value at destination address: 400k sats; > Rate limiting params at destination address: none; > Value at change address a3: 99.4m sats; > Rate limiting params at change address a3: h0=800144, h1=800287, a=500k, > a_remaining=100k. > > Transaction t2 is allowed because it falls within the next epoch (running > from 800144 to 800287) so a spend of 400k does not violate the constraint > of 500k per epoch. > > As could be seen, the rate limiting parameters are part of the transaction > and chosen by the user (or their wallet). This means that the parameters > must be validated to ensure that they do not violate the intended > constraints. > > For instance, this transaction should not be allowed: > a2: 99.8 sats at height 800100; > Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k; > > Transaction t2a: > Included at block height 800200; > Spend: 400k + fees; > Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k. > > This transaction t2a attempts to shift the epoch forward by 20 blocks such > that it starts at 800124 instead of 800144. Shifting the epoch forward like > this must not be allowed because it enables spending more that the rate > limit allows, which is 500k in any epoch of 144 blocks. It would enable > overspending: > > t1: spend 200k at 800100 (epoch 1: total: 200k); > t2a: spend 400k at 800200 (epoch 2: total: 400k); > t3a: spend 100k at 800201 (epoch 2: total: 500k); > t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for epoch > 2). > > Specifying the rate-limiting parameters explicitly at every transaction > allows the user to tighten the spending limit by setting tighter limits or > for instance by setting a_remainder to 0 if they wish to enforce not > spending more during an epoch. > > I will stop here because I would like to gauge interest in this idea first > before continuing work on other aspects. Two main pieces of work jump to > mind: > > Define all validations; > Describe aggregate behaviour of multiple (rate-limited) inputs, proof that > two rate-limited addresses cannot spend more than the sum of their > individual limits. > > Zac > > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 12418 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-07-31 20:01 ` [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood 2021-08-02 4:40 ` Billy Tetrud @ 2021-08-10 2:17 ` ZmnSCPxj 2021-08-13 11:02 ` Zac Greenwood 1 sibling, 1 reply; 33+ messages in thread From: ZmnSCPxj @ 2021-08-10 2:17 UTC (permalink / raw) To: Zac Greenwood, Bitcoin Protocol Discussion fromGood morning Zac, With some work, what you want can be implemented, to some extent, today, without changes to consensus. The point you want, I believe, is to have two sets of keys: * A long-term-storage keyset, in "cold" storage. * A short-term-spending keyset, in "warm" storage, controlling only a small amount of funds. What you can do would be: * Put all your funds in a single UTXO, with an k-of-n of your cold keys (ideally P2TR, or some P2WSH k-of-n). * Put your cold keys online, and sign a transaction spending the above UTXO, and spending most of it to a new address that is a tweaked k-of-n of your cold keys, and a smaller output (up to the limit you want) controlled by the k-of-n of your warm keys. * Keep this transaction offchain, in your warm storage. * Put your cold keys back offline. * When you need to spend using your warm keys, bring the above transaction onchain, then spend from the budget as needed. If you need to have some estimated amount of usable funds for every future unit of time, just create a chain of transactions with future `nLockTime`. nLocktime +1day nLockTime +2day +------------+ +------------+ +------------+ cold UTXO -->| cold TXO|-->| cold TXO|-->| cold TXO|--> etc. | | | | | | | warm TXO| | warm TXO| | warm TXO| +------------+ +------------+ +------------+ Pre-sign the above transactions, store the pre-signed transactions in warm storage together with your warm keys. Then put the cold keys back offline. Then from today to tomorrow, you can spend only the first warm TXO. From tomorrow to the day after, you can spend only the first two warm TXOs. And so on. If tomorrow your warm keys are stolen, you can bring the cold keys online to claim the second cold TXO and limit your fund loss to only just the first two warm TXOs. The above is bulky, but it has the advantage of not using any special opcodes or features (improving privacy, especially with P2TR which would in theory allow k-of-n/n-of-n to be indistinguishable from 1-of-1), and using just `nLockTime`, which is much easier to hide since most modern wallets will set `nLockTime` to recent block heights. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-10 2:17 ` ZmnSCPxj @ 2021-08-13 11:02 ` Zac Greenwood 2021-08-14 1:50 ` ZmnSCPxj 0 siblings, 1 reply; 33+ messages in thread From: Zac Greenwood @ 2021-08-13 11:02 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3944 bytes --] Hi ZmnSCPxj, Thank you for your insightful response. Perhaps I should take a step back and take a strictly functional angle. Perhaps the list could help me to establish whether the proposed functionality is: Desirable; Not already possible; Feasible to implement. The proposed functionality is as follows: The ability to control some coin with two private keys (or two sets of private keys) such that spending is limited over time for one private key (i.e., it is for instance not possible to spend all coin in a single transaction) while spending is unrestricted for the other private key (no limits apply). No limits must apply to coin transacted to a third party. Also, it must be possible never having to bring the unrestricted private key online unless more than the limit imposed on the restrictive private key is desired to be spent. Less generally, taking the perspective of a hodler: the user must be able to keep one key offline and one key online. The offline key allows unrestricted spending, the online key is limited in how much it is allowed to spend over time. Furthermore, the spending limit must be intuitive. Best candidate I believe would be a maximum spend per some fixed number of blocks. For instance, the restrictive key may allow a maximum of 100k sats per any window of 144 blocks. Ofcourse the user must be able to set these parameters freely. I look forward to any feedback you may have. Zac On Tue, 10 Aug 2021 at 04:17, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote: > fromGood morning Zac, > > > With some work, what you want can be implemented, to some extent, today, > without changes to consensus. > > The point you want, I believe, is to have two sets of keys: > > * A long-term-storage keyset, in "cold" storage. > * A short-term-spending keyset, in "warm" storage, controlling only a > small amount of funds. > > What you can do would be: > > * Put all your funds in a single UTXO, with an k-of-n of your cold keys > (ideally P2TR, or some P2WSH k-of-n). > * Put your cold keys online, and sign a transaction spending the above > UTXO, and spending most of it to a new address that is a tweaked k-of-n of > your cold keys, and a smaller output (up to the limit you want) controlled > by the k-of-n of your warm keys. > * Keep this transaction offchain, in your warm storage. > * Put your cold keys back offline. > * When you need to spend using your warm keys, bring the above transaction > onchain, then spend from the budget as needed. > > > If you need to have some estimated amount of usable funds for every future > unit of time, just create a chain of transactions with future `nLockTime`. > > nLocktime +1day nLockTime +2day > +------------+ +------------+ +------------+ > cold UTXO -->| cold TXO|-->| cold TXO|-->| cold TXO|--> etc. > | | | | | | > | warm TXO| | warm TXO| | warm TXO| > +------------+ +------------+ +------------+ > > Pre-sign the above transactions, store the pre-signed transactions in warm > storage together with your warm keys. > Then put the cold keys back offline. > > Then from today to tomorrow, you can spend only the first warm TXO. > From tomorrow to the day after, you can spend only the first two warm TXOs. > And so on. > > If tomorrow your warm keys are stolen, you can bring the cold keys online > to claim the second cold TXO and limit your fund loss to only just the > first two warm TXOs. > > The above is bulky, but it has the advantage of not using any special > opcodes or features (improving privacy, especially with P2TR which would in > theory allow k-of-n/n-of-n to be indistinguishable from 1-of-1), and using > just `nLockTime`, which is much easier to hide since most modern wallets > will set `nLockTime` to recent block heights. > > Regards, > ZmnSCPxj > > [-- Attachment #2: Type: text/html, Size: 7630 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-13 11:02 ` Zac Greenwood @ 2021-08-14 1:50 ` ZmnSCPxj 2021-08-16 11:17 ` Zac Greenwood 0 siblings, 1 reply; 33+ messages in thread From: ZmnSCPxj @ 2021-08-14 1:50 UTC (permalink / raw) To: Zac Greenwood; +Cc: Bitcoin Protocol Discussion Good morning Zac, > Hi ZmnSCPxj, > > Thank you for your insightful response. > > Perhaps I should take a step back and take a strictly functional angle. Perhaps the list could help me to establish whether the proposed functionality is: > > Desirable; > Not already possible; > Feasible to implement. > > The proposed functionality is as follows: > > The ability to control some coin with two private keys (or two sets of private keys) such that spending is limited over time for one private key (i.e., it is for instance not possible to spend all coin in a single transaction) while spending is unrestricted for the other private key (no limits apply). No limits must apply to coin transacted to a third party. > > Also, it must be possible never having to bring the unrestricted private key online unless more than the limit imposed on the restrictive private key is desired to be spent. > > Less generally, taking the perspective of a hodler: the user must be able to keep one key offline and one key online. The offline key allows unrestricted spending, the online key is limited in how much it is allowed to spend over time. > > Furthermore, the spending limit must be intuitive. Best candidate I believe would be a maximum spend per some fixed number of blocks. For instance, the restrictive key may allow a maximum of 100k sats per any window of 144 blocks. Ofcourse the user must be able to set these parameters freely. My proposal does not *quite* implement a window. However, that is because it uses `nLockTime`. With the use of `nSequence` in relative-locktime mode, however, it *does* implement a window, sort of. More specifically, it implements a timeout on spending --- if you spend using a presigned transaction (which creates an unencumbered specific-valued TXO that can be arbitrarily spent with your online keyset) then you cannot get another "batch" of funds until the `nSequence` relative locktime passes. However, this *does* implement a window that limits a maximum value spendable per any window of the relative timelock you select. The disadvantage is that `nSequence` use is a lot more obvious and discernible than `nLockTime` use. Many wallets today use non-zero `nLockTime` for anti-fee-sniping, and that is a good cover for `nLockTime` transactions. I believe Dave Harding proposed that wallets should also use, at random, (say 50-50) `nSequence`-in-relative-locktime-mode as an alternate anti-fee-sniping mechanism. This alternate anti-fee-sniping would help cover `nSequence` use. Note that my proposal does impose a maximum limit on the number of windows. With `nSequence`-in-relative-locktime-mode the limit is the number of times that the online keyset can spend. After spending that many windows, the offline keyset has to be put back online to generate a new set of transactions. It has the massive massive advantage that you can implement it today without any consensus change, and I think you can expect that consensus change will take a LONG time (xref SegWit, Taproot). Certainly the functionality is desirable. But it seems it can be implemented with Bitcoin today. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-14 1:50 ` ZmnSCPxj @ 2021-08-16 11:17 ` Zac Greenwood 2021-08-16 11:48 ` ZmnSCPxj 0 siblings, 1 reply; 33+ messages in thread From: Zac Greenwood @ 2021-08-16 11:17 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5742 bytes --] Hi ZmnSCPxj, Thank you for your counterproposal. I fully agree that as a first step we must establish whether the proposed functionality can be implemented without making any changes to consensus. Your counterproposal is understandably more technical in nature because it explores an implementation on top of Bitcoin as-is. However I feel that for a fair comparison of the functionality of both proposals a purely functional description of your proposal is essential. If I understand your proposal correctly, then I believe there are some major gaps between yours and mine: Keys for unrestricted spending: in my proposal, they never have to come online unless spending more than the limit is desired. In your proposal, these keys are required to come online in several situations. Presigning transactions: not required in my proposal. Wouldn’t such presigning requirement be detrimental for the usability of your proposal? Does it mean that for instance the amount and window in which the transaction can be spent is determined at the time of signing? In my proposal, there is no limit in the number of transactions per window. Number of windows: limited in your proposal, unlimited in mine. There are probably additional gaps that I am currently not technically able to recognize. I feel that the above gaps are significant enough to state that your proposal does not meet the basic requirements of my proposal. Next to consider is whether the gap is acceptable, weighing the effort to implement the required consensus changes against the effort and feasibility of implementing your counterproposal. I feel that your counterproposal has little chance of being implemented because of the still considerable effort required and the poor result in functional terms. I also wonder if your proposal is feasible considering wallet operability. Considering all the above, I believe that implementing consensus changes in order to support the proposed functionality would preferable over your counterproposal. I acknowledge that a consensus change takes years and is difficult to achieve, but that should not be any reason to stop exploring the appetite for the proposed functionality and perhaps start looking at possible technical solutions. Zac On Sat, 14 Aug 2021 at 03:50, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote: > Good morning Zac, > > > > Hi ZmnSCPxj, > > > > Thank you for your insightful response. > > > > Perhaps I should take a step back and take a strictly functional angle. > Perhaps the list could help me to establish whether the proposed > functionality is: > > > > Desirable; > > Not already possible; > > Feasible to implement. > > > > The proposed functionality is as follows: > > > > The ability to control some coin with two private keys (or two sets of > private keys) such that spending is limited over time for one private key > (i.e., it is for instance not possible to spend all coin in a single > transaction) while spending is unrestricted for the other private key (no > limits apply). No limits must apply to coin transacted to a third party. > > > > Also, it must be possible never having to bring the unrestricted private > key online unless more than the limit imposed on the restrictive private > key is desired to be spent. > > > > Less generally, taking the perspective of a hodler: the user must be > able to keep one key offline and one key online. The offline key allows > unrestricted spending, the online key is limited in how much it is allowed > to spend over time. > > > > Furthermore, the spending limit must be intuitive. Best candidate I > believe would be a maximum spend per some fixed number of blocks. For > instance, the restrictive key may allow a maximum of 100k sats per any > window of 144 blocks. Ofcourse the user must be able to set these > parameters freely. > > My proposal does not *quite* implement a window. > However, that is because it uses `nLockTime`. > > With the use of `nSequence` in relative-locktime mode, however, it *does* > implement a window, sort of. > More specifically, it implements a timeout on spending --- if you spend > using a presigned transaction (which creates an unencumbered > specific-valued TXO that can be arbitrarily spent with your online keyset) > then you cannot get another "batch" of funds until the `nSequence` relative > locktime passes. > However, this *does* implement a window that limits a maximum value > spendable per any window of the relative timelock you select. > > The disadvantage is that `nSequence` use is a lot more obvious and > discernible than `nLockTime` use. > Many wallets today use non-zero `nLockTime` for anti-fee-sniping, and that > is a good cover for `nLockTime` transactions. > I believe Dave Harding proposed that wallets should also use, at random, > (say 50-50) `nSequence`-in-relative-locktime-mode as an alternate > anti-fee-sniping mechanism. > This alternate anti-fee-sniping would help cover `nSequence` use. > > Note that my proposal does impose a maximum limit on the number of windows. > With `nSequence`-in-relative-locktime-mode the limit is the number of > times that the online keyset can spend. > After spending that many windows, the offline keyset has to be put back > online to generate a new set of transactions. > > It has the massive massive advantage that you can implement it today > without any consensus change, and I think you can expect that consensus > change will take a LONG time (xref SegWit, Taproot). > > Certainly the functionality is desirable. > But it seems it can be implemented with Bitcoin today. > > Regards, > ZmnSCPxj > > [-- Attachment #2: Type: text/html, Size: 9558 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-16 11:17 ` Zac Greenwood @ 2021-08-16 11:48 ` ZmnSCPxj 2021-08-30 14:43 ` Zac Greenwood 0 siblings, 1 reply; 33+ messages in thread From: ZmnSCPxj @ 2021-08-16 11:48 UTC (permalink / raw) To: Zac Greenwood; +Cc: Bitcoin Protocol Discussion Good morning Zac, > Thank you for your counterproposal. I fully agree that as a first step we must establish whether the proposed functionality can be implemented without making any changes to consensus. > > Your counterproposal is understandably more technical in nature because it explores an implementation on top of Bitcoin as-is. However I feel that for a fair comparison of the functionality of both proposals a purely functional description of your proposal is essential. > > If I understand your proposal correctly, then I believe there are some major gaps between yours and mine: > > Keys for unrestricted spending: in my proposal, they never have to come online unless spending more than the limit is desired. In your proposal, these keys are required to come online in several situations. Correct, that is indeed a weakness. It is helpful to see https://zmnscpxj.github.io/bitcoin/unchained.html Basically: any quorum of signers can impose any rules that are not implementable on the base layer, including the rules you desire. That quorum is the "offline keyset" in my proposal. > > Presigning transactions: not required in my proposal. Wouldn’t such presigning requirement be detrimental for the usability of your proposal? Does it mean that for instance the amount and window in which the transaction can be spent is determined at the time of signing? In my proposal, there is no limit in the number of transactions per window. No. Remember, the output is a simple 1-of-1 or k-of-n of the online keyset. The online keyset can spend that wherever and however, including paying it out to N parties, or paying part of the limit to 1 party and then paying the remainder back to the same onchain keyset so it can access the funds in the future. Both cases are also available in your proposal, and the latter case (pay out part of the limit to a single output, then keep the rest back to the same onchain keyset) can be used to add an indefinite number of transactions per window. > > Number of windows: limited in your proposal, unlimited in mine. Correct, though you can always have a fairly large number of windows ("640kB ought to be enough for anybody"). > > There are probably additional gaps that I am currently not technically able to recognize. It requires a fair amount of storage for the signatures at minimum, though that may be as small as 64 bytes per window. 1Mb of storage for signatures would allow 16,384 windows, assuming you use 1-day windows that is about 44.88 years, probably more than enough that a one-time onlining of the offline keys (or just print out the signatures on paper or display as a QR code, whatever) is acceptable. > I feel that the above gaps are significant enough to state that your proposal does not meet the basic requirements of my proposal. > > Next to consider is whether the gap is acceptable, weighing the effort to implement the required consensus changes against the effort and feasibility of implementing your counterproposal. > > I feel that your counterproposal has little chance of being implemented because of the still considerable effort required and the poor result in functional terms. I also wonder if your proposal is feasible considering wallet operability. See above, particularly the gap that does not, in fact, exist. > > Considering all the above, I believe that implementing consensus changes in order to support the proposed functionality would preferable over your counterproposal. > > I acknowledge that a consensus change takes years and is difficult to achieve, but that should not be any reason to stop exploring the appetite for the proposed functionality and perhaps start looking at possible technical solutions. You can also look into the "covenant" opcodes (`OP_CHECKSIGFROMSTACK`, `OP_CHECKTEMPLATEVERIFY`, etc.), I think JeremyRubin has a bunch of them listed somewhere, which may be used to implement something similar without requiring presigning. Since the basic "just use `nSequence`" scheme already implements what you need, what the covenant opcodes buy you is that you do not need the offline keyset to be onlined and there is no need to keep signatures, removing the remaining gaps you identified. With a proper looping covenant opcode, there is also no limit on the number of windows. The issue with the covenant opcodes is that there are several proposals with overlapping abilities and different tradeoffs. This is the sort of thing that invites bikeshed-painting. I suggest looking into the covenant opcodes and supporting those instead of your own proposal, as your application is very close to one of the motivating examples for covenants in the first place. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-16 11:48 ` ZmnSCPxj @ 2021-08-30 14:43 ` Zac Greenwood 2021-08-31 9:00 ` ZmnSCPxj 0 siblings, 1 reply; 33+ messages in thread From: Zac Greenwood @ 2021-08-30 14:43 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8254 bytes --] Hi ZmnSCPxj, > I suggest looking into the covenant opcodes and supporting those instead of your own proposal, as your application is very close to one of the motivating examples for covenants in the first place. I believe it is not the right approach to take a proposal, chop off key aspects of its functionality, and rely to some future change in Bitcoin that may perhaps enable implementing some watered down version of the intended functionality. In my opinion the right order would be to first discuss the unmodified proposal on a functional level and gauge community interest, then move forward to discuss technical challenges for the *unmodified* proposal instead of first knee-capping the proposal in order to (presumably) reduce cost of implementation. I believe that we both recognize that the proposed functionality would be beneficial. I believe that your position is that functionality close to what I have in mind can be implemented using covenants, albeit with some gaps. For me personally however these gaps would not be acceptable because they severely hurt the predictability and intuitiveness of the behavior of the functionality for the end-user. But as noted, I believe at this point it is premature to have this discussion. Perhaps you could help me understand what would be required to implement the *unmodified* proposal. That way, the community will be able to better assess the cost (in terms of effort and risk) and weigh it against the perceived benefits. Perhaps *then* we find that the cost could be significantly reduced without any significant reduction of the benefits, for instance by slightly compromising on the functionality such that no changes to consensus would be required for its implementation. (I am skeptical that this would be possible though). The cost reduction must be carefully weighed against the functional gaps it creates. I am aware that my proposal must be well-defined functionally before being able to reason about its benefits and implementational aspects. I believe that the proposed functionality is pretty straightforward, but I am happy to come up with a more precise functional spec. However, such effort would be wasted if there is no community interest for this functionality. So far only few people have engaged with this thread, and I am not sure that this is because there is no interest in the proposal or because most people just lurk here and do not feel like giving their opinion on random proposals. It would be great however to learn about more people's opinions. As a reminder, the proposed functionality is to enable a user to limit the amount that they able to spent from an address within a certain time-frame or window (defined in number of blocks) while retaining the ability to spend arbitrary amounts using a secondary private key (or set of private keys). The general use case is to prevent theft of large amounts while still allowing a user to spend small amounts over time. Hodlers as well as exchanges dealing with cold, warm and hot wallets come to mind as users who could materially benefit from this functionality. Zac On Mon, Aug 16, 2021 at 1:48 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote: > Good morning Zac, > > > Thank you for your counterproposal. I fully agree that as a first step > we must establish whether the proposed functionality can be implemented > without making any changes to consensus. > > > > Your counterproposal is understandably more technical in nature because > it explores an implementation on top of Bitcoin as-is. However I feel that > for a fair comparison of the functionality of both proposals a purely > functional description of your proposal is essential. > > > > If I understand your proposal correctly, then I believe there are some > major gaps between yours and mine: > > > > Keys for unrestricted spending: in my proposal, they never have to come > online unless spending more than the limit is desired. In your proposal, > these keys are required to come online in several situations. > > Correct, that is indeed a weakness. > > It is helpful to see https://zmnscpxj.github.io/bitcoin/unchained.html > Basically: any quorum of signers can impose any rules that are not > implementable on the base layer, including the rules you desire. > That quorum is the "offline keyset" in my proposal. > > > > > Presigning transactions: not required in my proposal. Wouldn’t such > presigning requirement be detrimental for the usability of your proposal? > Does it mean that for instance the amount and window in which the > transaction can be spent is determined at the time of signing? In my > proposal, there is no limit in the number of transactions per window. > > No. > Remember, the output is a simple 1-of-1 or k-of-n of the online keyset. > The online keyset can spend that wherever and however, including paying it > out to N parties, or paying part of the limit to 1 party and then paying > the remainder back to the same onchain keyset so it can access the funds in > the future. > Both cases are also available in your proposal, and the latter case (pay > out part of the limit to a single output, then keep the rest back to the > same onchain keyset) can be used to add an indefinite number of > transactions per window. > > > > > Number of windows: limited in your proposal, unlimited in mine. > > Correct, though you can always have a fairly large number of windows > ("640kB ought to be enough for anybody"). > > > > > There are probably additional gaps that I am currently not technically > able to recognize. > > It requires a fair amount of storage for the signatures at minimum, though > that may be as small as 64 bytes per window. > 1Mb of storage for signatures would allow 16,384 windows, assuming you use > 1-day windows that is about 44.88 years, probably more than enough that a > one-time onlining of the offline keys (or just print out the signatures on > paper or display as a QR code, whatever) is acceptable. > > > I feel that the above gaps are significant enough to state that your > proposal does not meet the basic requirements of my proposal. > > > > Next to consider is whether the gap is acceptable, weighing the effort > to implement the required consensus changes against the effort and > feasibility of implementing your counterproposal. > > > > I feel that your counterproposal has little chance of being implemented > because of the still considerable effort required and the poor result in > functional terms. I also wonder if your proposal is feasible considering > wallet operability. > > See above, particularly the gap that does not, in fact, exist. > > > > > Considering all the above, I believe that implementing consensus changes > in order to support the proposed functionality would preferable over your > counterproposal. > > > > I acknowledge that a consensus change takes years and is difficult to > achieve, but that should not be any reason to stop exploring the appetite > for the proposed functionality and perhaps start looking at possible > technical solutions. > > You can also look into the "covenant" opcodes (`OP_CHECKSIGFROMSTACK`, > `OP_CHECKTEMPLATEVERIFY`, etc.), I think JeremyRubin has a bunch of them > listed somewhere, which may be used to implement something similar without > requiring presigning. > > Since the basic "just use `nSequence`" scheme already implements what you > need, what the covenant opcodes buy you is that you do not need the offline > keyset to be onlined and there is no need to keep signatures, removing the > remaining gaps you identified. > With a proper looping covenant opcode, there is also no limit on the > number of windows. > > The issue with the covenant opcodes is that there are several proposals > with overlapping abilities and different tradeoffs. > This is the sort of thing that invites bikeshed-painting. > > I suggest looking into the covenant opcodes and supporting those instead > of your own proposal, as your application is very close to one of the > motivating examples for covenants in the first place. > > Regards, > ZmnSCPxj > [-- Attachment #2: Type: text/html, Size: 8887 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-30 14:43 ` Zac Greenwood @ 2021-08-31 9:00 ` ZmnSCPxj 2021-08-31 14:09 ` Zac Greenwood 0 siblings, 1 reply; 33+ messages in thread From: ZmnSCPxj @ 2021-08-31 9:00 UTC (permalink / raw) To: Zac Greenwood; +Cc: Bitcoin Protocol Discussion Good morning Zac, > Perhaps you could help me understand what would be required to implement the *unmodified* proposal. That way, the community will be able to better assess the cost (in terms of effort and risk) and weigh it against the perceived benefits. Perhaps *then* we find that the cost could be significantly reduced without any significant reduction of the benefits, for instance by slightly compromising on the functionality such that no changes to consensus would be required for its implementation. (I am skeptical that this would be possible though). The cost reduction must be carefully weighed against the functional gaps it creates. For one, such output need to be explicitly visible, to implement the "change outputs must also be rate-limited". A tx spending a rate-limited output has to know that one of the outputs is also a rate-limited output. This flagging needs to be done by either allocating a new SegWit version --- a resource that is not lightly allocated, there being only 30 versions left if my understanding is correct --- or blessing yet another anyone-can-spend `scriptPubKey` template, something we want to avoid which is why SegWit has versions (i.e. we want SegWit to be the last anyone-can-spend `scriptPubKey` template we bless for a **long** time). Explicit flagging is bad as well for privacy, which is another mark against it. Notice how Taproot improves privacy by making n-of-n indistinguishable from 1-of-1 (and with proper design or a setup ritual, k-of-n can be made indistinguishable from 1-of-1). Notice as well that my first counterproposal is significantly more private than explicit flagging, and my second coutnerproposal is also more private if wallets change their anti-fee-sniping mitigation. This privacy loss represented by explicit flagging will be resisted by some people, especially those that use a bunch of random letters as a pseudonym (because duh, privacy). (Yes, people can just decide not to use the privacy-leaking explicitly-flagged outputs, but that reduces the anonymity set of people who *are* interested in privacy, so people who are interested in privacy will prefer that other people do not leak their privacy so they can hide among *those* people as well.) You also probably need to keep some data with each output. This can be done by explicitly storing that data in the output directly, rather than a commitment to that data --- again, the "change outputs must also be rate-limited" requirement needs to check those data. The larger data stored with the output is undesirable, ideally we want each output to just be a commitment rather than contain any actual data, because often a 20-byte commitment is smaller than the data that needs to be stored. For example, I imagine that your original proposal requires, for change outputs, to store: * The actual rate limit. * The time frame of the rate limit. * The reduced rate limit, since we spent an amount within a specific time frame (i.e. residual limit) which is why this is a change output. * How long that time frame lasts. * A commitment to the keys that can spend this. Basically, until the residual limit expires, we impose the residual limit, then after the expiry of the residual limit we go back to the original rate limit. The commitment to the keys itself takes at least 20 bytes, and if you are planning a to support k-of-n then that takes at least 32 bytes. If this was not explicitly tagged, then a 32 byte commitment to all the necessary data would have been enough, but you do need the explicit tagging for the "change outputs must be rate-limited too". Note as well that the residual needs to be kept with the output. Bitcoin Core does not store transactions in a lookup table, it stores individual *outputs*. While the residual can be derived from the transaction, we do not have a transaction table. Thus, we need to explicitly put it on the output itself, directly, since we only have a lookup table for the unspent outputs, not individual transactions. (well there is `txindex` but that is an option for each node, not something consensus code can rely on) So yes, that "change outputs must also be rate-limited" is the big sticking point, and a lot of the "gaps" you worry about occur when we drop this bit. Drop this bit and you can implement it today without any consensus code change, and with privacy good enough to prevent people with random letters as pseudonym from trying to stop you. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-31 9:00 ` ZmnSCPxj @ 2021-08-31 14:09 ` Zac Greenwood 2021-08-31 14:22 ` ZmnSCPxj 0 siblings, 1 reply; 33+ messages in thread From: Zac Greenwood @ 2021-08-31 14:09 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5936 bytes --] Hi ZmnSCPxj, Thank you for your helpful response. We're on the same page concerning privacy so I'll focus on that. I understand from your mail that privacy would be reduced by this proposal because: * It requires the introduction of a new type of transaction that is different from a "standard" transaction (would that be P2TR in the future?), reducing the anonymity set for everyone; * The payment and change output will be identifiable because the change output must be marked encumbered on-chain; * The specifics of how the output is encumbered must be visible on-chain as well reducing privacy even further. I don't have the technical skills to judge whether these issues can somehow be resolved. In functional terms, the output should be spendable in a way that does not reveal that the output is encumbered, and produce a change output that cannot be distinguished from a non-change output while still being encumbered. Perhaps some clever MAST-fu could somehow help? I imagine that the offered functionality does not justify the above mentioned privacy reductions, so unless these can be addressed, without functional modification this proposal sadly seems dead in the water. Thanks again. Zac On Tue, Aug 31, 2021 at 11:00 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote: > Good morning Zac, > > > > Perhaps you could help me understand what would be required to implement > the *unmodified* proposal. That way, the community will be able to better > assess the cost (in terms of effort and risk) and weigh it against the > perceived benefits. Perhaps *then* we find that the cost could be > significantly reduced without any significant reduction of the benefits, > for instance by slightly compromising on the functionality such that no > changes to consensus would be required for its implementation. (I am > skeptical that this would be possible though). The cost reduction must be > carefully weighed against the functional gaps it creates. > > For one, such output need to be explicitly visible, to implement the > "change outputs must also be rate-limited". > A tx spending a rate-limited output has to know that one of the outputs is > also a rate-limited output. > > This flagging needs to be done by either allocating a new SegWit version > --- a resource that is not lightly allocated, there being only 30 versions > left if my understanding is correct --- or blessing yet another > anyone-can-spend `scriptPubKey` template, something we want to avoid which > is why SegWit has versions (i.e. we want SegWit to be the last > anyone-can-spend `scriptPubKey` template we bless for a **long** time). > > Explicit flagging is bad as well for privacy, which is another mark > against it. > Notice how Taproot improves privacy by making n-of-n indistinguishable > from 1-of-1 (and with proper design or a setup ritual, k-of-n can be made > indistinguishable from 1-of-1). > Notice as well that my first counterproposal is significantly more private > than explicit flagging, and my second coutnerproposal is also more private > if wallets change their anti-fee-sniping mitigation. > This privacy loss represented by explicit flagging will be resisted by > some people, especially those that use a bunch of random letters as a > pseudonym (because duh, privacy). > > (Yes, people can just decide not to use the privacy-leaking > explicitly-flagged outputs, but that reduces the anonymity set of people > who *are* interested in privacy, so people who are interested in privacy > will prefer that other people do not leak their privacy so they can hide > among *those* people as well.) > > You also probably need to keep some data with each output. > This can be done by explicitly storing that data in the output directly, > rather than a commitment to that data --- again, the "change outputs must > also be rate-limited" requirement needs to check those data. > > The larger data stored with the output is undesirable, ideally we want > each output to just be a commitment rather than contain any actual data, > because often a 20-byte commitment is smaller than the data that needs to > be stored. > For example, I imagine that your original proposal requires, for change > outputs, to store: > > * The actual rate limit. > * The time frame of the rate limit. > * The reduced rate limit, since we spent an amount within a specific time > frame (i.e. residual limit) which is why this is a change output. > * How long that time frame lasts. > * A commitment to the keys that can spend this. > > Basically, until the residual limit expires, we impose the residual limit, > then after the expiry of the residual limit we go back to the original rate > limit. > > The commitment to the keys itself takes at least 20 bytes, and if you are > planning a to support k-of-n then that takes at least 32 bytes. > If this was not explicitly tagged, then a 32 byte commitment to all the > necessary data would have been enough, but you do need the explicit tagging > for the "change outputs must be rate-limited too". > > Note as well that the residual needs to be kept with the output. > Bitcoin Core does not store transactions in a lookup table, it stores > individual *outputs*. > While the residual can be derived from the transaction, we do not have a > transaction table. > Thus, we need to explicitly put it on the output itself, directly, since > we only have a lookup table for the unspent outputs, not individual > transactions. > > (well there is `txindex` but that is an option for each node, not > something consensus code can rely on) > > So yes, that "change outputs must also be rate-limited" is the big > sticking point, and a lot of the "gaps" you worry about occur when we drop > this bit. > Drop this bit and you can implement it today without any consensus code > change, and with privacy good enough to prevent people with random letters > as pseudonym from trying to stop you. > > Regards, > ZmnSCPxj > > [-- Attachment #2: Type: text/html, Size: 6533 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-31 14:09 ` Zac Greenwood @ 2021-08-31 14:22 ` ZmnSCPxj 2021-09-01 15:15 ` Zac Greenwood 0 siblings, 1 reply; 33+ messages in thread From: ZmnSCPxj @ 2021-08-31 14:22 UTC (permalink / raw) To: Zac Greenwood; +Cc: Bitcoin Protocol Discussion Good morning Zac, > Hi ZmnSCPxj, > > Thank you for your helpful response. We're on the same page concerning privacy so I'll focus on that. I understand from your mail that privacy would be reduced by this proposal because: > > * It requires the introduction of a new type of transaction that is different from a "standard" transaction (would that be P2TR in the future?), reducing the anonymity set for everyone; > * The payment and change output will be identifiable because the change output must be marked encumbered on-chain; > * The specifics of how the output is encumbered must be visible on-chain as well reducing privacy even further. > > I don't have the technical skills to judge whether these issues can somehow be resolved. In functional terms, the output should be spendable in a way that does not reveal that the output is encumbered, and produce a change output that cannot be distinguished from a non-change output while still being encumbered. Perhaps some clever MAST-fu could somehow help? I believe some of the covenant efforts may indeed have such clever MAST-fu integrated into them, which is why I pointed you to them --- the people developing these (aj I think? RubenSomsen?) might be able to accommodate this or some subset of the desired feature in a sufficiently clever covenant scheme. There are a number of such proposals, though, so I cannot really point you to one that seems likely to have a lot of traction. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-31 14:22 ` ZmnSCPxj @ 2021-09-01 15:15 ` Zac Greenwood 0 siblings, 0 replies; 33+ messages in thread From: Zac Greenwood @ 2021-09-01 15:15 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3982 bytes --] Hi ZmnSCPxj, The rate-limiting algorithm would be relatively straightforward. I documented the rate-limiting part of the algorithm below, perhaps they can evoke new ideas of how to make this MAST-able or otherwise implement this in a privacy preserving way. Something like the following: => Create an output at block height [h0] with the following properties: Serving as input at any block height, the maximum amount is limited to [limit] sats; // This rule introduces [limit] and is permanent and always copied over to a change output Serving as input at a block height < [h0 + window], the maximum amount is limited to [limit - 0] sats; // [limit - 0] to emphasize that nothing was spent yet and no window has started. => A transaction occurs at block height [h1], spending [h1_spent]. The payment output created at [h1] is not encumbered and of value [h1_spent]; // Note, this is the first encumbered transaction so [h1] is the first block of the first window The change output created at block height [h1] must be encumbered as follows: Serving as input at any block height, the maximum amount is limited to [limit] sats; // Permanent rule repeats Serving as input at a block height < [h1 + window], the maximum amount is limited to [limit - h1_spent] // Second permanent rule reduces spendable amount until height [h1 + window] by [h1_spent] => A second transaction occurs at block height [h2], spending [h2_spent]. The payment output created at [h2] is not encumbered and of value [h2_spent]; // Second transaction, so a second window starts at [h2] The change output created at block height [h2] must be encumbered as follows: Serving as input at any block height, the maximum amount is limited to [limit] sats; // Permanent rule repeats Serving as input at a block height < [h1 + window], the max amount is limited to [limit - h1_spent - h2_spent] // Reduce spendable amount between [h1] and [h1 + window] by an additional [h2_spent] Serving as input in range [h1 + window] <= block height < [h2 + window], the max amount is limited to [limit - h2_spent] // First payment no longer inside this window so [h1_spent] no longer subtracted ... and so on. A rule that pertains to a block height < the current block height can be abandoned, keeping the number of rules equal to the number of transactions that exist within the oldest still active window. Zac On Tue, Aug 31, 2021 at 4:22 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote: > Good morning Zac, > > > Hi ZmnSCPxj, > > > > Thank you for your helpful response. We're on the same page concerning > privacy so I'll focus on that. I understand from your mail that privacy > would be reduced by this proposal because: > > > > * It requires the introduction of a new type of transaction that is > different from a "standard" transaction (would that be P2TR in the > future?), reducing the anonymity set for everyone; > > * The payment and change output will be identifiable because the change > output must be marked encumbered on-chain; > > * The specifics of how the output is encumbered must be visible on-chain > as well reducing privacy even further. > > > > I don't have the technical skills to judge whether these issues can > somehow be resolved. In functional terms, the output should be spendable in > a way that does not reveal that the output is encumbered, and produce a > change output that cannot be distinguished from a non-change output while > still being encumbered. Perhaps some clever MAST-fu could somehow help? > > I believe some of the covenant efforts may indeed have such clever MAST-fu > integrated into them, which is why I pointed you to them --- the people > developing these (aj I think? RubenSomsen?) might be able to accommodate > this or some subset of the desired feature in a sufficiently clever > covenant scheme. > > There are a number of such proposals, though, so I cannot really point you > to one that seems likely to have a lot of traction. > > Regards, > ZmnSCPxj > [-- Attachment #2: Type: text/html, Size: 4778 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value @ 2021-08-01 8:09 Zac Greenwood 2021-08-02 9:32 ` Zac Greenwood 0 siblings, 1 reply; 33+ messages in thread From: Zac Greenwood @ 2021-08-01 8:09 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6653 bytes --] [Resubmitting to list with minor edits. My previous submission ended up inside an existing thread, apologies.] Hi list, I'd like to explore whether it is feasible to implement new scripting capabilities in Bitcoin that enable limiting the output amount of a transaction based on the total value of its inputs. In other words, to implement the ability to limit the maximum amount that can be sent from an address. Two use cases come to mind: UC1: enable a user to add additional protection their funds by rate-limiting the amount that they are allowed to send during a certain period (measured in blocks). A typical use case might be a user that intends to hodl their bitcoin, but still wishes to occasionally send small amounts. Rate-limiting avoids an attacker from sweeping all the users' funds in a single transaction, allowing the user to become aware of the theft and intervene to prevent further thefts. UC2: exchanges may wish to rate-limit addresses containing large amounts of bitcoin, adding warm- or hot-wallet functionality to a cold-storage address. This would enable an exchange to drastically reduce the number of times a cold wallet must be accessed with private keys that give access to the full amount. In a typical setup, I'd envision using multisig such that the user has two sets of private keys to their encumbered address (with a "set" of keys meaning "one or more" keys). One set of private keys allows only for sending with rate-limiting restrictions in place, and a second set of private keys allowing for sending any amount without rate-limiting, effectively overriding such restriction. The parameters that define in what way an output is rate-limited might be defined as follows: Param 1: a block height "h0" indicating the first block height of an epoch; Param 2: a block height "h1" indicating the last block height of an epoch; Param 3: an amount "a" in satoshi indicating the maximum amount that is allowed to be sent in any epoch; Param 4: an amount "a_remaining" (in satoshi) indicating the maximum amount that is allowed to be sent within the current epoch. For example, consider an input containing 100m sats (1 BTC) which has been rate-limited with parameters (h0, h1, a, a_remaining) of (800000, 800143, 500k, 500k). These parameters define that the address is rate-limited to sending a maximum of 500k sats in the current epoch that starts at block height 800000 and ends at height 800143 (or about one day ignoring block time variance) and that the full amount of 500k is still sendable. These rate-limiting parameters ensure that it takes at minimum 100m / 500k = 200 transactions and 200 x 144 blocks or about 200 days to spend the full 100m sats. As noted earlier, in a typical setup a user should retain the option to transact the entire amount using a second (set of) private key(s). For rate-limiting to work, any change output created by a transaction from a rate-limited address must itself be rate-limited as well. For instance, expanding on the above example, assume that the user spends 200k sats from a rate-limited address a1 containing 100m sats: Start situation: At block height 800000: rate-limited address a1 is created; Value of a1: 100.0m sats; Rate limiting params of a1: h0=800000, h1=800143, a=500k, a_remaining=500k; Transaction t1: Included at block height 800100; Spend: 200k + fee; Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k. Result: Value at destination address: 200k sats; Rate limiting params at destination address: none; Value at change address a2: 99.8m sats; Rate limiting params at change address a2: h0=800000, h1=800143, a=500k, a_remaining=300k. In order to properly enforce rate limiting, the change address must be rate-limited such that the original rate limit of 500k sats per 144 blocks cannot be exceeded. In this example, the change address a2 were given the same rate limiting parameters as the transaction that served as its input. As a result, from block 800100 up until and including block 800143, a maximum amount of 300k sats is allowed to be spent from the change address. Example continued: a2: 99.8 sats at height 800100; Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; Transaction t2: Included at block height 800200 Spend: 400k + fees. Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. Result: Value at destination address: 400k sats; Rate limiting params at destination address: none; Value at change address a3: 99.4m sats; Rate limiting params at change address a3: h0=800144, h1=800287, a=500k, a_remaining=100k. Transaction t2 is allowed because it falls within the next epoch (running from 800144 to 800287) so a spend of 400k does not violate the constraint of 500k per epoch. As could be seen, the rate limiting parameters are part of the transaction and chosen by the user (or their wallet). This means that the parameters must be validated to ensure that they do not violate the intended constraints. For instance, this transaction should not be allowed: a2: 99.8 sats at height 800100; Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k; Transaction t2a: Included at block height 800200; Spend: 400k + fees; Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k. This transaction t2a attempts to shift the epoch forward by 20 blocks such that it starts at 800124 instead of 800144. Shifting the epoch forward like this must not be allowed because it enables spending more that the rate limit allows, which is 500k in any epoch of 144 blocks. It would enable overspending: t1: spend 200k at 800100 (epoch 1: total: 200k); t2a: spend 400k at 800200 (epoch 2: total: 400k); t3a: spend 100k at 800201 (epoch 2: total: 500k); t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for epoch 2). Specifying the rate-limiting parameters explicitly at every transaction allows the user to tighten the spending limit by setting tighter limits or for instance by setting a_remainder to 0 if they wish to enforce not spending more during an epoch. A second advantage of explicitly specifying the four rate-limiting parameters with each transaction is that it allows the system to fully validate the transaction without having to consider any previous transactions within an epoch. I will stop here because I would like to gauge interest in this idea first before continuing work on other aspects. Two main pieces of work jump to mind: Define all validations; Describe aggregate behaviour of multiple (rate-limited) inputs, proof that two rate-limited addresses cannot spend more than the sum of their individual limits. Zac [-- Attachment #2: Type: text/html, Size: 7801 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-01 8:09 Zac Greenwood @ 2021-08-02 9:32 ` Zac Greenwood 2021-08-03 18:12 ` Billy Tetrud 0 siblings, 1 reply; 33+ messages in thread From: Zac Greenwood @ 2021-08-02 9:32 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 10547 bytes --] [Note: I've moved your reply to the newly started thread] Hi Billy, Thank you for your kind and encouraging feedback. I don't quite understand why you'd want to define a specific span of blocks > for the rate limit. Why not just specify the size of the window (in blocks) > to rate limit within, and the limit? To enable more straightforward validation logic. You mentioned change addresses, however, with the parameters you defined, > there would be no way to connect together the change address with the > original address, meaning they would have completely separate rate limits, > which wouldn't work since the change output would ignore the previous rate > limit. The rate-limiting parameters must be re-specified for each rate-limited input. So, a transaction that has a rate-limited input is only valid if its output is itself rate-limited such that it does not violate the rate-limiting constraints of its input. In my thread-starter, I gave the below example of a rate-limited address a2 that serves as input for transaction t2: a2: 99.8 sats at height 800100; Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; Transaction t2: Included at block height 800200 Spend: 400k + fees. Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. Note how transaction t2 re-specifies the rate-limiting parameters. Validation must ensure that the re-specified parameters are within bounds, i.e., do not allow more spending per epoch than the rate-limiting parameters of its input address a2. Re-specifying the rate-limiting parameters offers the flexibility to further restrict spending, or to disable any additional spending within the current epoch by setting a_remaining to zero. Result: Value at destination address: 400k sats; Rate limiting params at destination address: none; Value at change address a3: 99.4m sats; Rate limiting params at change address a3: h0=800144, h1=800287, a=500k, a_remaining=100k. As a design principle I believe it makes sense if the system is able to verify the validity of a transaction without having to consider any transactions that precede its inputs. As a side-note, doing away with this design principle would however enable more sophisticated rate-limiting (such as rate-limiting per sliding window instead of rate-limiting per epoch having a fixed start and end block), but while at the same time reducing the size of per rate-limiting transaction (because it would enable specifying the rate-limiting parameters more space-efficiently). To test the waters and to keep things relatively simple, I chose not to go into this enhanced form of rate-limiting. I haven't gone into how to process a transaction having multiple rate-limited inputs. The easiest way to handle this case is to not allow any transaction having more than one rate-limited input. One could imagine complex logic to handle transactions having multiple rate-limited inputs by creating multiple rate-limited change addresses. However at first glance I don't believe that the marginal added functionality would justify the increased implementation complexity. I'd be interested in seeing you write a BIP for this. Thank you, but sadly my understanding of Bitcoin is way too low to be able to write a BIP and do the implementation. However I see tremendous value in this functionality. Favorable feedback of the list regarding the usefulness and the technical feasibility of rate-limiting functionality would of course be an encouragement for me to descend further down the rabbit hole. Zac On Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw@gmail•com> wrote: > [Resubmitting to list with minor edits. My previous submission ended up > inside an existing thread, apologies.] > > Hi list, > > I'd like to explore whether it is feasible to implement new scripting > capabilities in Bitcoin that enable limiting the output amount of a > transaction based on the total value of its inputs. In other words, to > implement the ability to limit the maximum amount that can be sent from an > address. > > Two use cases come to mind: > > UC1: enable a user to add additional protection their funds by > rate-limiting the amount that they are allowed to send during a certain > period (measured in blocks). A typical use case might be a user that > intends to hodl their bitcoin, but still wishes to occasionally send small > amounts. Rate-limiting avoids an attacker from sweeping all the users' > funds in a single transaction, allowing the user to become aware of the > theft and intervene to prevent further thefts. > > UC2: exchanges may wish to rate-limit addresses containing large amounts > of bitcoin, adding warm- or hot-wallet functionality to a cold-storage > address. This would enable an exchange to drastically reduce the number of > times a cold wallet must be accessed with private keys that give access to > the full amount. > > In a typical setup, I'd envision using multisig such that the user has two > sets of private keys to their encumbered address (with a "set" of keys > meaning "one or more" keys). One set of private keys allows only for > sending with rate-limiting restrictions in place, and a second set of > private keys allowing for sending any amount without rate-limiting, > effectively overriding such restriction. > > The parameters that define in what way an output is rate-limited might be > defined as follows: > > Param 1: a block height "h0" indicating the first block height of an epoch; > Param 2: a block height "h1" indicating the last block height of an epoch; > Param 3: an amount "a" in satoshi indicating the maximum amount that is > allowed to be sent in any epoch; > Param 4: an amount "a_remaining" (in satoshi) indicating the maximum > amount that is allowed to be sent within the current epoch. > > For example, consider an input containing 100m sats (1 BTC) which has been > rate-limited with parameters (h0, h1, a, a_remaining) of (800000, 800143, > 500k, 500k). These parameters define that the address is rate-limited to > sending a maximum of 500k sats in the current epoch that starts at block > height 800000 and ends at height 800143 (or about one day ignoring block > time variance) and that the full amount of 500k is still sendable. These > rate-limiting parameters ensure that it takes at minimum 100m / 500k = 200 > transactions and 200 x 144 blocks or about 200 days to spend the full 100m > sats. As noted earlier, in a typical setup a user should retain the option > to transact the entire amount using a second (set of) private key(s). > > For rate-limiting to work, any change output created by a transaction from > a rate-limited address must itself be rate-limited as well. For instance, > expanding on the above example, assume that the user spends 200k sats from > a rate-limited address a1 containing 100m sats: > > Start situation: > At block height 800000: rate-limited address a1 is created; > Value of a1: 100.0m sats; > Rate limiting params of a1: h0=800000, h1=800143, a=500k, a_remaining=500k; > > Transaction t1: > Included at block height 800100; > Spend: 200k + fee; > Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k. > > Result: > Value at destination address: 200k sats; > Rate limiting params at destination address: none; > Value at change address a2: 99.8m sats; > Rate limiting params at change address a2: h0=800000, h1=800143, a=500k, > a_remaining=300k. > > In order to properly enforce rate limiting, the change address must be > rate-limited such that the original rate limit of 500k sats per 144 blocks > cannot be exceeded. In this example, the change address a2 were given the > same rate limiting parameters as the transaction that served as its input. > As a result, from block 800100 up until and including block 800143, a > maximum amount of 300k sats is allowed to be spent from the change address. > > Example continued: > a2: 99.8 sats at height 800100; > Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; > > Transaction t2: > Included at block height 800200 > Spend: 400k + fees. > Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. > > Result: > Value at destination address: 400k sats; > Rate limiting params at destination address: none; > Value at change address a3: 99.4m sats; > Rate limiting params at change address a3: h0=800144, h1=800287, a=500k, > a_remaining=100k. > > Transaction t2 is allowed because it falls within the next epoch (running > from 800144 to 800287) so a spend of 400k does not violate the constraint > of 500k per epoch. > > As could be seen, the rate limiting parameters are part of the transaction > and chosen by the user (or their wallet). This means that the parameters > must be validated to ensure that they do not violate the intended > constraints. > > For instance, this transaction should not be allowed: > a2: 99.8 sats at height 800100; > Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k; > > Transaction t2a: > Included at block height 800200; > Spend: 400k + fees; > Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k. > > This transaction t2a attempts to shift the epoch forward by 20 blocks such > that it starts at 800124 instead of 800144. Shifting the epoch forward like > this must not be allowed because it enables spending more that the rate > limit allows, which is 500k in any epoch of 144 blocks. It would enable > overspending: > > t1: spend 200k at 800100 (epoch 1: total: 200k); > t2a: spend 400k at 800200 (epoch 2: total: 400k); > t3a: spend 100k at 800201 (epoch 2: total: 500k); > t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for epoch > 2). > > Specifying the rate-limiting parameters explicitly at every transaction > allows the user to tighten the spending limit by setting tighter limits or > for instance by setting a_remainder to 0 if they wish to enforce not > spending more during an epoch. A second advantage of explicitly specifying > the four rate-limiting parameters with each transaction is that it allows > the system to fully validate the transaction without having to consider any > previous transactions within an epoch. > > I will stop here because I would like to gauge interest in this idea first > before continuing work on other aspects. Two main pieces of work jump to > mind: > > Define all validations; > Describe aggregate behaviour of multiple (rate-limited) inputs, proof that > two rate-limited addresses cannot spend more than the sum of their > individual limits. > > Zac > [-- Attachment #2: Type: text/html, Size: 12590 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-02 9:32 ` Zac Greenwood @ 2021-08-03 18:12 ` Billy Tetrud 2021-08-04 10:48 ` Zac Greenwood 0 siblings, 1 reply; 33+ messages in thread From: Billy Tetrud @ 2021-08-03 18:12 UTC (permalink / raw) To: Zac Greenwood; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 13240 bytes --] > To enable more straightforward validation logic. > within the current epoch Ah I see, this is all limited to within a single epoch. I think that sufficiently limits the window of time in which nodes have to store information for rate limited outputs. However, I don't see how specifying block ranges simplifies the logic - wouldn't this complicate the logic with additional user-specified constraints? It also prevents the output from being able to be rate limited over the span of multiple epochs, which would seem to make it a lot more difficult to use for certain types of wallets (eg cold wallets). I think I see the logic of your 'remaining' parameter there. If you start with a single rate-limited input, you can split that into many outputs, only one of which have a 'remaining' balance. The rest can simply remain unspendable for the rest of the epoch. That way these things don't need to be tied together. However, that doesn't solve the problem of 3rd parties being able to send money into the wallet. > I don't believe that the marginal added functionality would justify the increased implementation complexity Perhaps, but I think there is a lot of benefit in allowing these kinds of things to operate as similarly as possible to normal transactions, for one because of usability reasons. If each opcode has its own quirks that are not intuitively related to their purpose (eg if a rate-limited wallet had no way to get a receiving address), it would confuse end-users (eg who wonder how to get a receiving address and how they can ask people to send money into their wallet) or require a lot of technical complexity in applications (eg to support something like cooperatively connecting with their wallet so that a transaction can be made that creates a new single-output for the wallet). A little complexity in this opcode can save a lot of external complexity here I think. > my understanding of Bitcoin is way too low to be able to write a BIP and do the implementation You might be able to find people willing to help. I would be willing to help write the BIP spec. I'm not the right person to help with the implementation, but perhaps you could find someone else who is. Even if the BIP isn't adopted, it could be a starting point or inspiration for someone else to write an improved version. On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <zachgrw@gmail•com> wrote: > [Note: I've moved your reply to the newly started thread] > > Hi Billy, > > Thank you for your kind and encouraging feedback. > > I don't quite understand why you'd want to define a specific span of >> blocks for the rate limit. Why not just specify the size of the window (in >> blocks) to rate limit within, and the limit? > > > To enable more straightforward validation logic. > > You mentioned change addresses, however, with the parameters you defined, >> there would be no way to connect together the change address with the >> original address, meaning they would have completely separate rate limits, >> which wouldn't work since the change output would ignore the previous rate >> limit. > > > The rate-limiting parameters must be re-specified for each rate-limited > input. So, a transaction that has a rate-limited input is only valid if its > output is itself rate-limited such that it does not violate the > rate-limiting constraints of its input. > > In my thread-starter, I gave the below example of a rate-limited address > a2 that serves as input for transaction t2: > > a2: 99.8 sats at height 800100; > Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; > > Transaction t2: > Included at block height 800200 > Spend: 400k + fees. > Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. > > Note how transaction t2 re-specifies the rate-limiting parameters. > Validation must ensure that the re-specified parameters are within bounds, > i.e., do not allow more spending per epoch than the rate-limiting > parameters of its input address a2. Re-specifying the rate-limiting > parameters offers the flexibility to further restrict spending, or to > disable any additional spending within the current epoch by setting > a_remaining to zero. > > Result: > Value at destination address: 400k sats; > Rate limiting params at destination address: none; > Value at change address a3: 99.4m sats; > Rate limiting params at change address a3: h0=800144, h1=800287, a=500k, > a_remaining=100k. > > As a design principle I believe it makes sense if the system is able to > verify the validity of a transaction without having to consider any > transactions that precede its inputs. As a side-note, doing away with this > design principle would however enable more sophisticated rate-limiting > (such as rate-limiting per sliding window instead of rate-limiting per > epoch having a fixed start and end block), but while at the same time > reducing the size of per rate-limiting transaction (because it would enable > specifying the rate-limiting parameters more space-efficiently). To test > the waters and to keep things relatively simple, I chose not to go into > this enhanced form of rate-limiting. > > I haven't gone into how to process a transaction having multiple > rate-limited inputs. The easiest way to handle this case is to not allow > any transaction having more than one rate-limited input. One could imagine > complex logic to handle transactions having multiple rate-limited inputs by > creating multiple rate-limited change addresses. However at first glance I > don't believe that the marginal added functionality would justify the > increased implementation complexity. > > I'd be interested in seeing you write a BIP for this. > > > Thank you, but sadly my understanding of Bitcoin is way too low to be able > to write a BIP and do the implementation. However I see tremendous value in > this functionality. Favorable feedback of the list regarding the usefulness > and the technical feasibility of rate-limiting functionality would of > course be an encouragement for me to descend further down the rabbit hole. > > Zac > > > On Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw@gmail•com> wrote: > >> [Resubmitting to list with minor edits. My previous submission ended up >> inside an existing thread, apologies.] >> >> Hi list, >> >> I'd like to explore whether it is feasible to implement new scripting >> capabilities in Bitcoin that enable limiting the output amount of a >> transaction based on the total value of its inputs. In other words, to >> implement the ability to limit the maximum amount that can be sent from an >> address. >> >> Two use cases come to mind: >> >> UC1: enable a user to add additional protection their funds by >> rate-limiting the amount that they are allowed to send during a certain >> period (measured in blocks). A typical use case might be a user that >> intends to hodl their bitcoin, but still wishes to occasionally send small >> amounts. Rate-limiting avoids an attacker from sweeping all the users' >> funds in a single transaction, allowing the user to become aware of the >> theft and intervene to prevent further thefts. >> >> UC2: exchanges may wish to rate-limit addresses containing large amounts >> of bitcoin, adding warm- or hot-wallet functionality to a cold-storage >> address. This would enable an exchange to drastically reduce the number of >> times a cold wallet must be accessed with private keys that give access to >> the full amount. >> >> In a typical setup, I'd envision using multisig such that the user has >> two sets of private keys to their encumbered address (with a "set" of keys >> meaning "one or more" keys). One set of private keys allows only for >> sending with rate-limiting restrictions in place, and a second set of >> private keys allowing for sending any amount without rate-limiting, >> effectively overriding such restriction. >> >> The parameters that define in what way an output is rate-limited might be >> defined as follows: >> >> Param 1: a block height "h0" indicating the first block height of an >> epoch; >> Param 2: a block height "h1" indicating the last block height of an epoch; >> Param 3: an amount "a" in satoshi indicating the maximum amount that is >> allowed to be sent in any epoch; >> Param 4: an amount "a_remaining" (in satoshi) indicating the maximum >> amount that is allowed to be sent within the current epoch. >> >> For example, consider an input containing 100m sats (1 BTC) which has >> been rate-limited with parameters (h0, h1, a, a_remaining) of (800000, >> 800143, 500k, 500k). These parameters define that the address is >> rate-limited to sending a maximum of 500k sats in the current epoch that >> starts at block height 800000 and ends at height 800143 (or about one day >> ignoring block time variance) and that the full amount of 500k is still >> sendable. These rate-limiting parameters ensure that it takes at minimum >> 100m / 500k = 200 transactions and 200 x 144 blocks or about 200 days to >> spend the full 100m sats. As noted earlier, in a typical setup a user >> should retain the option to transact the entire amount using a second (set >> of) private key(s). >> >> For rate-limiting to work, any change output created by a transaction >> from a rate-limited address must itself be rate-limited as well. For >> instance, expanding on the above example, assume that the user spends 200k >> sats from a rate-limited address a1 containing 100m sats: >> >> Start situation: >> At block height 800000: rate-limited address a1 is created; >> Value of a1: 100.0m sats; >> Rate limiting params of a1: h0=800000, h1=800143, a=500k, >> a_remaining=500k; >> >> Transaction t1: >> Included at block height 800100; >> Spend: 200k + fee; >> Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k. >> >> Result: >> Value at destination address: 200k sats; >> Rate limiting params at destination address: none; >> Value at change address a2: 99.8m sats; >> Rate limiting params at change address a2: h0=800000, h1=800143, a=500k, >> a_remaining=300k. >> >> In order to properly enforce rate limiting, the change address must be >> rate-limited such that the original rate limit of 500k sats per 144 blocks >> cannot be exceeded. In this example, the change address a2 were given the >> same rate limiting parameters as the transaction that served as its input. >> As a result, from block 800100 up until and including block 800143, a >> maximum amount of 300k sats is allowed to be spent from the change address. >> >> Example continued: >> a2: 99.8 sats at height 800100; >> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; >> >> Transaction t2: >> Included at block height 800200 >> Spend: 400k + fees. >> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. >> >> Result: >> Value at destination address: 400k sats; >> Rate limiting params at destination address: none; >> Value at change address a3: 99.4m sats; >> Rate limiting params at change address a3: h0=800144, h1=800287, a=500k, >> a_remaining=100k. >> >> Transaction t2 is allowed because it falls within the next epoch (running >> from 800144 to 800287) so a spend of 400k does not violate the constraint >> of 500k per epoch. >> >> As could be seen, the rate limiting parameters are part of the >> transaction and chosen by the user (or their wallet). This means that the >> parameters must be validated to ensure that they do not violate the >> intended constraints. >> >> For instance, this transaction should not be allowed: >> a2: 99.8 sats at height 800100; >> Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k; >> >> Transaction t2a: >> Included at block height 800200; >> Spend: 400k + fees; >> Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k. >> >> This transaction t2a attempts to shift the epoch forward by 20 blocks >> such that it starts at 800124 instead of 800144. Shifting the epoch forward >> like this must not be allowed because it enables spending more that the >> rate limit allows, which is 500k in any epoch of 144 blocks. It would >> enable overspending: >> >> t1: spend 200k at 800100 (epoch 1: total: 200k); >> t2a: spend 400k at 800200 (epoch 2: total: 400k); >> t3a: spend 100k at 800201 (epoch 2: total: 500k); >> t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for epoch >> 2). >> >> Specifying the rate-limiting parameters explicitly at every transaction >> allows the user to tighten the spending limit by setting tighter limits or >> for instance by setting a_remainder to 0 if they wish to enforce not >> spending more during an epoch. A second advantage of explicitly specifying >> the four rate-limiting parameters with each transaction is that it allows >> the system to fully validate the transaction without having to consider any >> previous transactions within an epoch. >> >> I will stop here because I would like to gauge interest in this idea >> first before continuing work on other aspects. Two main pieces of work jump >> to mind: >> >> Define all validations; >> Describe aggregate behaviour of multiple (rate-limited) inputs, proof >> that two rate-limited addresses cannot spend more than the sum of their >> individual limits. >> >> Zac >> > [-- Attachment #2: Type: text/html, Size: 15511 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-03 18:12 ` Billy Tetrud @ 2021-08-04 10:48 ` Zac Greenwood 2021-08-05 6:39 ` Billy Tetrud 0 siblings, 1 reply; 33+ messages in thread From: Zac Greenwood @ 2021-08-04 10:48 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 19499 bytes --] > Ah I see, this is all limited to within a single epoch. No, that wouldn't be useful. A maximum amount is allowed to be spent within EVERY epoch. Consider an epoch length of 100 blocks with a spend limit of 200k per epoch. The following is allowed: epoch1 (800101 - 800200): spend 120k in block 800140. Remaining for epoch1: 80k; epoch1 (800101 - 800200): spend another 60k in block 800195. Remaining for epoch1: 20k; epoch2 (800201 - 800300): spend 160k in block 800201. Remaining for epoch2: 40k. Since the limit pertains to each individual epoch, it is allowed to spend up to the full limit at the start of any new epoch. In this example, the spending was as follows: 800140: 120k 800195: 60k 800201: 160k. Note that in a span of 62 blocks a total of 340k sats was spent. This may seem to violate the 200k limit per 100 blocks, but this is the result of using a per-epoch limit. This allows a maximum of 400k to be spent in 2 blocks llke so: 200k in the last block of an epoch and another 200k in the first block of the next epoch. However this is inconsequential for the intended goal of rate-limiting which is to enable small spends over time from a large amount and to prevent theft of a large amount with a single transaction. To explain the proposed design more clearly, I have renamed the params as follows: epochStart: block height of first block of the current epoch (was: h0); epochEnd: block height of last block of the current epoch (was: h1); limit: the maximum total amount allowed to be spent within the current epoch (was: a); remain: the remaining amount allowed to be spent within the current epoch (was: a_remaining); Also, to illustrate that the params are specific to a transaction, I will hence precede the param with the transaction name like so: tx8_limit, tx31c_remain, tx42z_epochStart, ... etc. For simplicity, only transactions with no more than one rate-limited input are considered, and with no more than two outputs: one rate-limited change output, and a normal (not rate-limited) output. Normally, a simple transaction generates two outputs: one for a payment to a third party and one for the change address. Again for simplicity, we demand that a transaction which introduces rate-limiting must have only a single, rate-limited output. The validation rule might be: if a transaction has rate-limiting params and none of its inputs are rate-limited, then there must be only a single (rate-limited) output (and no second or change output). Consider rate limiting transactions tx1 having one or more normal (non rate-limited) inputs: tx1 gets included at block height 800004; The inputs of tx1 are not rate-limited => tx1 must have only a single output which will become rate-limited; params: tx1_epochStart=800001, tx1_epochEnd=800100, tx1_limit=200k, tx1_remain=200k; => This defines that an epoch has 100 blocks and no more than 200k sats may be spent in any one epoch. Within the current epoch, 200k sats may still be spent. This transaction begins to rate-limit a set of inputs, so it has a single rate-limited output. Let's explore transactions that have the output of tx1 as their input. I will denote the output of tx1 as "out1". tx2a has out1 as its only input; tx2a spends 50k sats and gets included at block height 803050; tx2a specifies the following params for its change output "chg2a": chg2a_epochStart=803001, chg2a_epochEnd=803100; chg2a_limit=200k, chg2a_remain=150k. To enforce rate-limiting, the system must validate the params of the change output chg2a to ensure that overspending is not allowed. The above params are allowed because: => 1. the epoch does not become smaller than 100 blocks [(chg2a_epochEnd - chg2a_epochStart) >= (tx1_epochEnd - tx1_epochStart)] => 2. tx1_limit has not been increased (ch2a_limit <= tx1_limit) => 3. the amount spent (50k sats) does not exceed tx1_remain AND does not exceed chg2a_limit; => 4. chg2a_remain" is 50k sats less than chg2a_limit. A transaction may also further constrain further spending like so: tx2b has out1as its only input; tx2b spends 8k sats and gets included at block height 808105; tx2b specifies the following params for its change output "chg2b": chg2b_epochStart=808101, chg2b_epochEnd=808250; chg2b_limit=10k, chg2b_remain=0. These params are allowed because: => 1. the epoch does not become smaller than100 blocks. It is fine to increase the epoch to 150 blocks because it does not enable exceeding the original rate-limit; => 2. the limit (chg2b_limit) has been decreased to 10k sats, further restricting the maximum amount allowed to be spent within the current and any subsequent epochs; => 3. the amount spent (10k sats) does not exceed tx1_remain AND does not exceed chg2b_limit; => 4. chg2b_remain has been set to zero, meaning that within the current epoch (block height 808101 to and including 808250), tx2b cannot be used as a spending input to any transaction. Starting from block height 808251, a new epoch will start and the rate-limited output of tx2b may again be used as an input for a subsequent rate-limited transaction tx3b. This transaction tx3b must again be accompanied by params that do not violate the rate-limit as defined by the params of tx2b and which are stored with output out2b. So, the epoch of tx3b must be at minimum 150 blocks, the maximum that is allowed to be spent per epoch is at most 10k sats, and chg3b_remain must be decreased by at least the amount spent by tx3b. From the above, the rate-limiting mechanics should hopefully be clear and full set of validation rules could be defined in a more generalized way with little additional effort. Note that I conveniently avoided talking about how to represent the parameters within transactions or outputs, simply because I currently lack enough understanding to reason about this. I am hoping that others may offer help. Zac On Tue, Aug 3, 2021 at 8:12 PM Billy Tetrud <billy.tetrud@gmail•com> wrote: > > To enable more straightforward validation logic. > > within the current epoch > > Ah I see, this is all limited to within a single epoch. I think that > sufficiently limits the window of time in which nodes have to store > information for rate limited outputs. However, I don't see how specifying > block ranges simplifies the logic - wouldn't this complicate the logic with > additional user-specified constraints? It also prevents the output from > being able to be rate limited over the span of multiple epochs, which would > seem to make it a lot more difficult to use for certain types of wallets > (eg cold wallets). > > I think I see the logic of your 'remaining' parameter there. If you start > with a single rate-limited input, you can split that into many outputs, > only one of which have a 'remaining' balance. The rest can simply remain > unspendable for the rest of the epoch. That way these things don't need to > be tied together. However, that doesn't solve the problem of 3rd parties > being able to send money into the wallet. > > > I don't believe that the marginal added functionality would justify the > increased implementation complexity > > Perhaps, but I think there is a lot of benefit in allowing these kinds of > things to operate as similarly as possible to normal transactions, for one > because of usability reasons. If each opcode has its own quirks that are > not intuitively related to their purpose (eg if a rate-limited wallet had > no way to get a receiving address), it would confuse end-users (eg who > wonder how to get a receiving address and how they can ask people to send > money into their wallet) or require a lot of technical complexity in > applications (eg to support something like cooperatively connecting with > their wallet so that a transaction can be made that creates a new > single-output for the wallet). A little complexity in this opcode can save > a lot of external complexity here I think. > > > my understanding of Bitcoin is way too low to be able to write a BIP and > do the implementation > > You might be able to find people willing to help. I would be willing to > help write the BIP spec. I'm not the right person to help with the > implementation, but perhaps you could find someone else who is. Even if the > BIP isn't adopted, it could be a starting point or inspiration for someone > else to write an improved version. > > On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <zachgrw@gmail•com> wrote: > >> [Note: I've moved your reply to the newly started thread] >> >> Hi Billy, >> >> Thank you for your kind and encouraging feedback. >> >> I don't quite understand why you'd want to define a specific span of >>> blocks for the rate limit. Why not just specify the size of the window (in >>> blocks) to rate limit within, and the limit? >> >> >> To enable more straightforward validation logic. >> >> You mentioned change addresses, however, with the parameters you defined, >>> there would be no way to connect together the change address with the >>> original address, meaning they would have completely separate rate limits, >>> which wouldn't work since the change output would ignore the previous rate >>> limit. >> >> >> The rate-limiting parameters must be re-specified for each rate-limited >> input. So, a transaction that has a rate-limited input is only valid if its >> output is itself rate-limited such that it does not violate the >> rate-limiting constraints of its input. >> >> In my thread-starter, I gave the below example of a rate-limited address >> a2 that serves as input for transaction t2: >> >> a2: 99.8 sats at height 800100; >> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; >> >> Transaction t2: >> Included at block height 800200 >> Spend: 400k + fees. >> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. >> >> Note how transaction t2 re-specifies the rate-limiting parameters. >> Validation must ensure that the re-specified parameters are within bounds, >> i.e., do not allow more spending per epoch than the rate-limiting >> parameters of its input address a2. Re-specifying the rate-limiting >> parameters offers the flexibility to further restrict spending, or to >> disable any additional spending within the current epoch by setting >> a_remaining to zero. >> >> Result: >> Value at destination address: 400k sats; >> Rate limiting params at destination address: none; >> Value at change address a3: 99.4m sats; >> Rate limiting params at change address a3: h0=800144, h1=800287, a=500k, >> a_remaining=100k. >> >> As a design principle I believe it makes sense if the system is able to >> verify the validity of a transaction without having to consider any >> transactions that precede its inputs. As a side-note, doing away with this >> design principle would however enable more sophisticated rate-limiting >> (such as rate-limiting per sliding window instead of rate-limiting per >> epoch having a fixed start and end block), but while at the same time >> reducing the size of per rate-limiting transaction (because it would enable >> specifying the rate-limiting parameters more space-efficiently). To test >> the waters and to keep things relatively simple, I chose not to go into >> this enhanced form of rate-limiting. >> >> I haven't gone into how to process a transaction having multiple >> rate-limited inputs. The easiest way to handle this case is to not allow >> any transaction having more than one rate-limited input. One could imagine >> complex logic to handle transactions having multiple rate-limited inputs by >> creating multiple rate-limited change addresses. However at first glance I >> don't believe that the marginal added functionality would justify the >> increased implementation complexity. >> >> I'd be interested in seeing you write a BIP for this. >> >> >> Thank you, but sadly my understanding of Bitcoin is way too low to be >> able to write a BIP and do the implementation. However I see tremendous >> value in this functionality. Favorable feedback of the list regarding the >> usefulness and the technical feasibility of rate-limiting functionality >> would of course be an encouragement for me to descend further down the >> rabbit hole. >> >> Zac >> >> >> On Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw@gmail•com> wrote: >> >>> [Resubmitting to list with minor edits. My previous submission ended up >>> inside an existing thread, apologies.] >>> >>> Hi list, >>> >>> I'd like to explore whether it is feasible to implement new scripting >>> capabilities in Bitcoin that enable limiting the output amount of a >>> transaction based on the total value of its inputs. In other words, to >>> implement the ability to limit the maximum amount that can be sent from an >>> address. >>> >>> Two use cases come to mind: >>> >>> UC1: enable a user to add additional protection their funds by >>> rate-limiting the amount that they are allowed to send during a certain >>> period (measured in blocks). A typical use case might be a user that >>> intends to hodl their bitcoin, but still wishes to occasionally send small >>> amounts. Rate-limiting avoids an attacker from sweeping all the users' >>> funds in a single transaction, allowing the user to become aware of the >>> theft and intervene to prevent further thefts. >>> >>> UC2: exchanges may wish to rate-limit addresses containing large amounts >>> of bitcoin, adding warm- or hot-wallet functionality to a cold-storage >>> address. This would enable an exchange to drastically reduce the number of >>> times a cold wallet must be accessed with private keys that give access to >>> the full amount. >>> >>> In a typical setup, I'd envision using multisig such that the user has >>> two sets of private keys to their encumbered address (with a "set" of keys >>> meaning "one or more" keys). One set of private keys allows only for >>> sending with rate-limiting restrictions in place, and a second set of >>> private keys allowing for sending any amount without rate-limiting, >>> effectively overriding such restriction. >>> >>> The parameters that define in what way an output is rate-limited might >>> be defined as follows: >>> >>> Param 1: a block height "h0" indicating the first block height of an >>> epoch; >>> Param 2: a block height "h1" indicating the last block height of an >>> epoch; >>> Param 3: an amount "a" in satoshi indicating the maximum amount that is >>> allowed to be sent in any epoch; >>> Param 4: an amount "a_remaining" (in satoshi) indicating the maximum >>> amount that is allowed to be sent within the current epoch. >>> >>> For example, consider an input containing 100m sats (1 BTC) which has >>> been rate-limited with parameters (h0, h1, a, a_remaining) of (800000, >>> 800143, 500k, 500k). These parameters define that the address is >>> rate-limited to sending a maximum of 500k sats in the current epoch that >>> starts at block height 800000 and ends at height 800143 (or about one day >>> ignoring block time variance) and that the full amount of 500k is still >>> sendable. These rate-limiting parameters ensure that it takes at minimum >>> 100m / 500k = 200 transactions and 200 x 144 blocks or about 200 days to >>> spend the full 100m sats. As noted earlier, in a typical setup a user >>> should retain the option to transact the entire amount using a second (set >>> of) private key(s). >>> >>> For rate-limiting to work, any change output created by a transaction >>> from a rate-limited address must itself be rate-limited as well. For >>> instance, expanding on the above example, assume that the user spends 200k >>> sats from a rate-limited address a1 containing 100m sats: >>> >>> Start situation: >>> At block height 800000: rate-limited address a1 is created; >>> Value of a1: 100.0m sats; >>> Rate limiting params of a1: h0=800000, h1=800143, a=500k, >>> a_remaining=500k; >>> >>> Transaction t1: >>> Included at block height 800100; >>> Spend: 200k + fee; >>> Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k. >>> >>> Result: >>> Value at destination address: 200k sats; >>> Rate limiting params at destination address: none; >>> Value at change address a2: 99.8m sats; >>> Rate limiting params at change address a2: h0=800000, h1=800143, a=500k, >>> a_remaining=300k. >>> >>> In order to properly enforce rate limiting, the change address must be >>> rate-limited such that the original rate limit of 500k sats per 144 blocks >>> cannot be exceeded. In this example, the change address a2 were given the >>> same rate limiting parameters as the transaction that served as its input. >>> As a result, from block 800100 up until and including block 800143, a >>> maximum amount of 300k sats is allowed to be spent from the change address. >>> >>> Example continued: >>> a2: 99.8 sats at height 800100; >>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; >>> >>> Transaction t2: >>> Included at block height 800200 >>> Spend: 400k + fees. >>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. >>> >>> Result: >>> Value at destination address: 400k sats; >>> Rate limiting params at destination address: none; >>> Value at change address a3: 99.4m sats; >>> Rate limiting params at change address a3: h0=800144, h1=800287, a=500k, >>> a_remaining=100k. >>> >>> Transaction t2 is allowed because it falls within the next epoch >>> (running from 800144 to 800287) so a spend of 400k does not violate the >>> constraint of 500k per epoch. >>> >>> As could be seen, the rate limiting parameters are part of the >>> transaction and chosen by the user (or their wallet). This means that the >>> parameters must be validated to ensure that they do not violate the >>> intended constraints. >>> >>> For instance, this transaction should not be allowed: >>> a2: 99.8 sats at height 800100; >>> Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k; >>> >>> Transaction t2a: >>> Included at block height 800200; >>> Spend: 400k + fees; >>> Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k. >>> >>> This transaction t2a attempts to shift the epoch forward by 20 blocks >>> such that it starts at 800124 instead of 800144. Shifting the epoch forward >>> like this must not be allowed because it enables spending more that the >>> rate limit allows, which is 500k in any epoch of 144 blocks. It would >>> enable overspending: >>> >>> t1: spend 200k at 800100 (epoch 1: total: 200k); >>> t2a: spend 400k at 800200 (epoch 2: total: 400k); >>> t3a: spend 100k at 800201 (epoch 2: total: 500k); >>> t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for epoch >>> 2). >>> >>> Specifying the rate-limiting parameters explicitly at every transaction >>> allows the user to tighten the spending limit by setting tighter limits or >>> for instance by setting a_remainder to 0 if they wish to enforce not >>> spending more during an epoch. A second advantage of explicitly specifying >>> the four rate-limiting parameters with each transaction is that it allows >>> the system to fully validate the transaction without having to consider any >>> previous transactions within an epoch. >>> >>> I will stop here because I would like to gauge interest in this idea >>> first before continuing work on other aspects. Two main pieces of work jump >>> to mind: >>> >>> Define all validations; >>> Describe aggregate behaviour of multiple (rate-limited) inputs, proof >>> that two rate-limited addresses cannot spend more than the sum of their >>> individual limits. >>> >>> Zac >>> >> [-- Attachment #2: Type: text/html, Size: 22748 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-04 10:48 ` Zac Greenwood @ 2021-08-05 6:39 ` Billy Tetrud 2021-08-05 14:22 ` Zac Greenwood 0 siblings, 1 reply; 33+ messages in thread From: Billy Tetrud @ 2021-08-05 6:39 UTC (permalink / raw) To: Zac Greenwood; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 22581 bytes --] > A maximum amount is allowed to be spent within EVERY epoch. It sounds like you're proposing an opcode that takes in epochStart and epochEnd as parameters. I still don't understand why its useful to specify those as absolute block heights. You mentioned that this enables more straightforward validation logic, but I don't see how. Eg, if you have a UTXO encumbered by rateLimit(epochStart = 800100, epochEnd = 800200, limit = 100k, remain = 100k), what happens if you don't spend that UTXO before block 800200? Is the output no longer rate limited then? Or is the opcode calculating 800200-800100 = 100 and applying a rate limit for the next epoch? If the first, then the UTXO must be spent within one epoch to remain rate limited. If the second, then it seems nearly identical to simply specifying window=100 as a parameter instead of epochStart and epochEnd. > then there must be only a single (rate-limited) output This rule would make transactions tricky if you're sending money into someone else's wallet that may be rate limited. If the requirement is that only you yourself can send money into a rate limited wallet, then this point is moot but it would be ideal to not have such a requirement. This is how I'd imagine creating an opcode like this: rateLimit(windowSize = 144 blocks, limit = 100k sats) This would define that the epoch is 1 day's worth of blocks. This would evenly divide bitcoin's retarget period and so each window would start and end at those dividing lines (eg the first 144 blocks of the retargetting period, then the second, then the third, etc). When this output is spent, it ensures that there's a maximum of 100k sats is sent to addresses other than the originating address. It also records the amount spent in the current 144 block window for that address (eg by simply recording the already-spent amount on the resulting UTXO and having an index that allows looking up UTXOs by address and adding them up). That way, when any output from that address is spent again, if a new 144 block window has started, the limit is reset, but if its still within the same window, the already-spent amounts for UTXOs from that address are added up and subtracted from the limit, and that number is the remaining limit a subsequent transaction needs to adhere to. This way, 3rd party could send transactions into an address like this, and multiple outputs can be combined and used to spend to arbitrary outputs (up to the rate limit of course). On Wed, Aug 4, 2021 at 3:48 AM Zac Greenwood <zachgrw@gmail•com> wrote: > > Ah I see, this is all limited to within a single epoch. > > No, that wouldn't be useful. A maximum amount is allowed to be spent > within EVERY epoch. > > Consider an epoch length of 100 blocks with a spend limit of 200k per > epoch. The following is allowed: > > epoch1 (800101 - 800200): spend 120k in block 800140. Remaining for > epoch1: 80k; > epoch1 (800101 - 800200): spend another 60k in block 800195. Remaining for > epoch1: 20k; > epoch2 (800201 - 800300): spend 160k in block 800201. Remaining for > epoch2: 40k. > > Since the limit pertains to each individual epoch, it is allowed to spend > up to the full limit at the start of any new epoch. In this example, the > spending was as follows: > > 800140: 120k > 800195: 60k > 800201: 160k. > > Note that in a span of 62 blocks a total of 340k sats was spent. This may > seem to violate the 200k limit per 100 blocks, but this is the result of > using a per-epoch limit. This allows a maximum of 400k to be spent in 2 > blocks llke so: 200k in the last block of an epoch and another 200k in the > first block of the next epoch. However this is inconsequential for the > intended goal of rate-limiting which is to enable small spends over time > from a large amount and to prevent theft of a large amount with a single > transaction. > > To explain the proposed design more clearly, I have renamed the params as > follows: > > epochStart: block height of first block of the current epoch (was: h0); > epochEnd: block height of last block of the current epoch (was: h1); > limit: the maximum total amount allowed to be spent within the current > epoch (was: a); > remain: the remaining amount allowed to be spent within the current epoch > (was: a_remaining); > > Also, to illustrate that the params are specific to a transaction, I will > hence precede the param with the transaction name like so: > tx8_limit, tx31c_remain, tx42z_epochStart, ... etc. > > For simplicity, only transactions with no more than one rate-limited input > are considered, and with no more than two outputs: one rate-limited change > output, and a normal (not rate-limited) output. > > Normally, a simple transaction generates two outputs: one for a payment to > a third party and one for the change address. Again for simplicity, we > demand that a transaction which introduces rate-limiting must have only a > single, rate-limited output. The validation rule might be: if a transaction > has rate-limiting params and none of its inputs are rate-limited, then > there must be only a single (rate-limited) output (and no second or change > output). > > Consider rate limiting transactions tx1 having one or more normal (non > rate-limited) inputs: > > tx1 gets included at block height 800004; > The inputs of tx1 are not rate-limited => tx1 must have only a single > output which will become rate-limited; > params: tx1_epochStart=800001, tx1_epochEnd=800100, tx1_limit=200k, > tx1_remain=200k; > => This defines that an epoch has 100 blocks and no more than 200k sats > may be spent in any one epoch. Within the current epoch, 200k sats may > still be spent. > > This transaction begins to rate-limit a set of inputs, so it has a single > rate-limited output. > Let's explore transactions that have the output of tx1 as their input. I > will denote the output of tx1 as "out1". > > tx2a has out1 as its only input; > tx2a spends 50k sats and gets included at block height 803050; > tx2a specifies the following params for its change output "chg2a": > chg2a_epochStart=803001, chg2a_epochEnd=803100; > chg2a_limit=200k, chg2a_remain=150k. > > To enforce rate-limiting, the system must validate the params of the > change output chg2a to ensure that overspending is not allowed. > > The above params are allowed because: > => 1. the epoch does not become smaller than 100 blocks [(chg2a_epochEnd - > chg2a_epochStart) >= (tx1_epochEnd - tx1_epochStart)] > => 2. tx1_limit has not been increased (ch2a_limit <= tx1_limit) > => 3. the amount spent (50k sats) does not exceed tx1_remain AND does not > exceed chg2a_limit; > => 4. chg2a_remain" is 50k sats less than chg2a_limit. > > A transaction may also further constrain further spending like so: > > tx2b has out1as its only input; > tx2b spends 8k sats and gets included at block height 808105; > tx2b specifies the following params for its change output "chg2b": > chg2b_epochStart=808101, chg2b_epochEnd=808250; > chg2b_limit=10k, chg2b_remain=0. > > These params are allowed because: > => 1. the epoch does not become smaller than100 blocks. It is fine to > increase the epoch to 150 blocks because it does not enable exceeding the > original rate-limit; > => 2. the limit (chg2b_limit) has been decreased to 10k sats, further > restricting the maximum amount allowed to be spent within the current and > any subsequent epochs; > => 3. the amount spent (10k sats) does not exceed tx1_remain AND does not > exceed chg2b_limit; > => 4. chg2b_remain has been set to zero, meaning that within the current > epoch (block height 808101 to and including 808250), tx2b cannot be used as > a spending input to any transaction. > > Starting from block height 808251, a new epoch will start and the > rate-limited output of tx2b may again be used as an input for a subsequent > rate-limited transaction tx3b. This transaction tx3b must again be > accompanied by params that do not violate the rate-limit as defined by the > params of tx2b and which are stored with output out2b. So, the epoch of > tx3b must be at minimum 150 blocks, the maximum that is allowed to be spent > per epoch is at most 10k sats, and chg3b_remain must be decreased by at > least the amount spent by tx3b. > > From the above, the rate-limiting mechanics should hopefully be clear and > full set of validation rules could be defined in a more generalized way > with little additional effort. > > Note that I conveniently avoided talking about how to represent the > parameters within transactions or outputs, simply because I currently lack > enough understanding to reason about this. I am hoping that others may > offer help. > > Zac > > > On Tue, Aug 3, 2021 at 8:12 PM Billy Tetrud <billy.tetrud@gmail•com> > wrote: > >> > To enable more straightforward validation logic. >> > within the current epoch >> >> Ah I see, this is all limited to within a single epoch. I think that >> sufficiently limits the window of time in which nodes have to store >> information for rate limited outputs. However, I don't see how specifying >> block ranges simplifies the logic - wouldn't this complicate the logic with >> additional user-specified constraints? It also prevents the output from >> being able to be rate limited over the span of multiple epochs, which would >> seem to make it a lot more difficult to use for certain types of wallets >> (eg cold wallets). >> >> I think I see the logic of your 'remaining' parameter there. If you start >> with a single rate-limited input, you can split that into many outputs, >> only one of which have a 'remaining' balance. The rest can simply remain >> unspendable for the rest of the epoch. That way these things don't need to >> be tied together. However, that doesn't solve the problem of 3rd parties >> being able to send money into the wallet. >> >> > I don't believe that the marginal added functionality would justify the >> increased implementation complexity >> >> Perhaps, but I think there is a lot of benefit in allowing these kinds of >> things to operate as similarly as possible to normal transactions, for one >> because of usability reasons. If each opcode has its own quirks that are >> not intuitively related to their purpose (eg if a rate-limited wallet had >> no way to get a receiving address), it would confuse end-users (eg who >> wonder how to get a receiving address and how they can ask people to send >> money into their wallet) or require a lot of technical complexity in >> applications (eg to support something like cooperatively connecting with >> their wallet so that a transaction can be made that creates a new >> single-output for the wallet). A little complexity in this opcode can save >> a lot of external complexity here I think. >> >> > my understanding of Bitcoin is way too low to be able to write a BIP >> and do the implementation >> >> You might be able to find people willing to help. I would be willing to >> help write the BIP spec. I'm not the right person to help with the >> implementation, but perhaps you could find someone else who is. Even if the >> BIP isn't adopted, it could be a starting point or inspiration for someone >> else to write an improved version. >> >> On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <zachgrw@gmail•com> wrote: >> >>> [Note: I've moved your reply to the newly started thread] >>> >>> Hi Billy, >>> >>> Thank you for your kind and encouraging feedback. >>> >>> I don't quite understand why you'd want to define a specific span of >>>> blocks for the rate limit. Why not just specify the size of the window (in >>>> blocks) to rate limit within, and the limit? >>> >>> >>> To enable more straightforward validation logic. >>> >>> You mentioned change addresses, however, with the parameters you >>>> defined, there would be no way to connect together the change address with >>>> the original address, meaning they would have completely separate rate >>>> limits, which wouldn't work since the change output would ignore the >>>> previous rate limit. >>> >>> >>> The rate-limiting parameters must be re-specified for each rate-limited >>> input. So, a transaction that has a rate-limited input is only valid if its >>> output is itself rate-limited such that it does not violate the >>> rate-limiting constraints of its input. >>> >>> In my thread-starter, I gave the below example of a rate-limited address >>> a2 that serves as input for transaction t2: >>> >>> a2: 99.8 sats at height 800100; >>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; >>> >>> Transaction t2: >>> Included at block height 800200 >>> Spend: 400k + fees. >>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. >>> >>> Note how transaction t2 re-specifies the rate-limiting parameters. >>> Validation must ensure that the re-specified parameters are within bounds, >>> i.e., do not allow more spending per epoch than the rate-limiting >>> parameters of its input address a2. Re-specifying the rate-limiting >>> parameters offers the flexibility to further restrict spending, or to >>> disable any additional spending within the current epoch by setting >>> a_remaining to zero. >>> >>> Result: >>> Value at destination address: 400k sats; >>> Rate limiting params at destination address: none; >>> Value at change address a3: 99.4m sats; >>> Rate limiting params at change address a3: h0=800144, h1=800287, a=500k, >>> a_remaining=100k. >>> >>> As a design principle I believe it makes sense if the system is able to >>> verify the validity of a transaction without having to consider any >>> transactions that precede its inputs. As a side-note, doing away with this >>> design principle would however enable more sophisticated rate-limiting >>> (such as rate-limiting per sliding window instead of rate-limiting per >>> epoch having a fixed start and end block), but while at the same time >>> reducing the size of per rate-limiting transaction (because it would enable >>> specifying the rate-limiting parameters more space-efficiently). To test >>> the waters and to keep things relatively simple, I chose not to go into >>> this enhanced form of rate-limiting. >>> >>> I haven't gone into how to process a transaction having multiple >>> rate-limited inputs. The easiest way to handle this case is to not allow >>> any transaction having more than one rate-limited input. One could imagine >>> complex logic to handle transactions having multiple rate-limited inputs by >>> creating multiple rate-limited change addresses. However at first glance I >>> don't believe that the marginal added functionality would justify the >>> increased implementation complexity. >>> >>> I'd be interested in seeing you write a BIP for this. >>> >>> >>> Thank you, but sadly my understanding of Bitcoin is way too low to be >>> able to write a BIP and do the implementation. However I see tremendous >>> value in this functionality. Favorable feedback of the list regarding the >>> usefulness and the technical feasibility of rate-limiting functionality >>> would of course be an encouragement for me to descend further down the >>> rabbit hole. >>> >>> Zac >>> >>> >>> On Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw@gmail•com> wrote: >>> >>>> [Resubmitting to list with minor edits. My previous submission ended up >>>> inside an existing thread, apologies.] >>>> >>>> Hi list, >>>> >>>> I'd like to explore whether it is feasible to implement new scripting >>>> capabilities in Bitcoin that enable limiting the output amount of a >>>> transaction based on the total value of its inputs. In other words, to >>>> implement the ability to limit the maximum amount that can be sent from an >>>> address. >>>> >>>> Two use cases come to mind: >>>> >>>> UC1: enable a user to add additional protection their funds by >>>> rate-limiting the amount that they are allowed to send during a certain >>>> period (measured in blocks). A typical use case might be a user that >>>> intends to hodl their bitcoin, but still wishes to occasionally send small >>>> amounts. Rate-limiting avoids an attacker from sweeping all the users' >>>> funds in a single transaction, allowing the user to become aware of the >>>> theft and intervene to prevent further thefts. >>>> >>>> UC2: exchanges may wish to rate-limit addresses containing large >>>> amounts of bitcoin, adding warm- or hot-wallet functionality to a >>>> cold-storage address. This would enable an exchange to drastically reduce >>>> the number of times a cold wallet must be accessed with private keys that >>>> give access to the full amount. >>>> >>>> In a typical setup, I'd envision using multisig such that the user has >>>> two sets of private keys to their encumbered address (with a "set" of keys >>>> meaning "one or more" keys). One set of private keys allows only for >>>> sending with rate-limiting restrictions in place, and a second set of >>>> private keys allowing for sending any amount without rate-limiting, >>>> effectively overriding such restriction. >>>> >>>> The parameters that define in what way an output is rate-limited might >>>> be defined as follows: >>>> >>>> Param 1: a block height "h0" indicating the first block height of an >>>> epoch; >>>> Param 2: a block height "h1" indicating the last block height of an >>>> epoch; >>>> Param 3: an amount "a" in satoshi indicating the maximum amount that is >>>> allowed to be sent in any epoch; >>>> Param 4: an amount "a_remaining" (in satoshi) indicating the maximum >>>> amount that is allowed to be sent within the current epoch. >>>> >>>> For example, consider an input containing 100m sats (1 BTC) which has >>>> been rate-limited with parameters (h0, h1, a, a_remaining) of (800000, >>>> 800143, 500k, 500k). These parameters define that the address is >>>> rate-limited to sending a maximum of 500k sats in the current epoch that >>>> starts at block height 800000 and ends at height 800143 (or about one day >>>> ignoring block time variance) and that the full amount of 500k is still >>>> sendable. These rate-limiting parameters ensure that it takes at minimum >>>> 100m / 500k = 200 transactions and 200 x 144 blocks or about 200 days to >>>> spend the full 100m sats. As noted earlier, in a typical setup a user >>>> should retain the option to transact the entire amount using a second (set >>>> of) private key(s). >>>> >>>> For rate-limiting to work, any change output created by a transaction >>>> from a rate-limited address must itself be rate-limited as well. For >>>> instance, expanding on the above example, assume that the user spends 200k >>>> sats from a rate-limited address a1 containing 100m sats: >>>> >>>> Start situation: >>>> At block height 800000: rate-limited address a1 is created; >>>> Value of a1: 100.0m sats; >>>> Rate limiting params of a1: h0=800000, h1=800143, a=500k, >>>> a_remaining=500k; >>>> >>>> Transaction t1: >>>> Included at block height 800100; >>>> Spend: 200k + fee; >>>> Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k. >>>> >>>> Result: >>>> Value at destination address: 200k sats; >>>> Rate limiting params at destination address: none; >>>> Value at change address a2: 99.8m sats; >>>> Rate limiting params at change address a2: h0=800000, h1=800143, >>>> a=500k, a_remaining=300k. >>>> >>>> In order to properly enforce rate limiting, the change address must be >>>> rate-limited such that the original rate limit of 500k sats per 144 blocks >>>> cannot be exceeded. In this example, the change address a2 were given the >>>> same rate limiting parameters as the transaction that served as its input. >>>> As a result, from block 800100 up until and including block 800143, a >>>> maximum amount of 300k sats is allowed to be spent from the change address. >>>> >>>> Example continued: >>>> a2: 99.8 sats at height 800100; >>>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; >>>> >>>> Transaction t2: >>>> Included at block height 800200 >>>> Spend: 400k + fees. >>>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. >>>> >>>> Result: >>>> Value at destination address: 400k sats; >>>> Rate limiting params at destination address: none; >>>> Value at change address a3: 99.4m sats; >>>> Rate limiting params at change address a3: h0=800144, h1=800287, >>>> a=500k, a_remaining=100k. >>>> >>>> Transaction t2 is allowed because it falls within the next epoch >>>> (running from 800144 to 800287) so a spend of 400k does not violate the >>>> constraint of 500k per epoch. >>>> >>>> As could be seen, the rate limiting parameters are part of the >>>> transaction and chosen by the user (or their wallet). This means that the >>>> parameters must be validated to ensure that they do not violate the >>>> intended constraints. >>>> >>>> For instance, this transaction should not be allowed: >>>> a2: 99.8 sats at height 800100; >>>> Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k; >>>> >>>> Transaction t2a: >>>> Included at block height 800200; >>>> Spend: 400k + fees; >>>> Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k. >>>> >>>> This transaction t2a attempts to shift the epoch forward by 20 blocks >>>> such that it starts at 800124 instead of 800144. Shifting the epoch forward >>>> like this must not be allowed because it enables spending more that the >>>> rate limit allows, which is 500k in any epoch of 144 blocks. It would >>>> enable overspending: >>>> >>>> t1: spend 200k at 800100 (epoch 1: total: 200k); >>>> t2a: spend 400k at 800200 (epoch 2: total: 400k); >>>> t3a: spend 100k at 800201 (epoch 2: total: 500k); >>>> t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for >>>> epoch 2). >>>> >>>> Specifying the rate-limiting parameters explicitly at every transaction >>>> allows the user to tighten the spending limit by setting tighter limits or >>>> for instance by setting a_remainder to 0 if they wish to enforce not >>>> spending more during an epoch. A second advantage of explicitly specifying >>>> the four rate-limiting parameters with each transaction is that it allows >>>> the system to fully validate the transaction without having to consider any >>>> previous transactions within an epoch. >>>> >>>> I will stop here because I would like to gauge interest in this idea >>>> first before continuing work on other aspects. Two main pieces of work jump >>>> to mind: >>>> >>>> Define all validations; >>>> Describe aggregate behaviour of multiple (rate-limited) inputs, proof >>>> that two rate-limited addresses cannot spend more than the sum of their >>>> individual limits. >>>> >>>> Zac >>>> >>> [-- Attachment #2: Type: text/html, Size: 25857 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-05 6:39 ` Billy Tetrud @ 2021-08-05 14:22 ` Zac Greenwood 2021-08-10 0:41 ` Billy Tetrud 0 siblings, 1 reply; 33+ messages in thread From: Zac Greenwood @ 2021-08-05 14:22 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 25788 bytes --] Hi Billy, > It sounds like you're proposing an opcode No. I don’t have enough knowledge of Bitcoin to be able to tell how (and if) rate-limiting can be implemented as I suggested. I am not able to reason about opcodes, so I kept my description at a more functional level. > I still don't understand why its useful to specify those as absolute block heights I feel that this a rather uninteresting data representation aspect that’s not worth going back and forth about. Sure, specifying the length of the epoch may also be an option, although at the price of giving up some functionality, and without much if any gains. By explicitly specifying the start and end block of an epoch, the user has more flexibility in shifting the epoch (using alternate values for epochStart and epochEnd) and simultaneously increasing the length of an epoch. These seem rather exotic features, but there’s no harm in retaining them. > if you have a UTXO encumbered by rateLimit(epochStart = 800100, epochEnd = 800200, limit = 100k, remain = 100k), what happens if you don't spend that UTXO before block 800200? The rate limit remains in place. So if this UTXO is spent in block 900000, then at most 100k may be spent. Also, the new epoch must be at least 100 blocks and remain must correctly account for the actual amount spent. > This is how I'd imagine creating an opcode like this: > rateLimit(windowSize = 144 blocks, limit = 100k sats) This would require the system to bookkeep how much was spent since the first rate-limited output. It is a more intuitive way of rate-limiting but it may be much more difficult to implement, which is why I went with the epoch-based rate limiting solution. In terms of functionality, I believe the two solutions are nearly identical for all practical purposes. Your next section confuses me. As I understand it, using an address as input for a transaction will always spends the full amount at that address. That’s why change addresses are required, no? If Bitcoin were able to pay exact amounts then there wouldn’t be any need for change outputs. Zac On Thu, 5 Aug 2021 at 08:39, Billy Tetrud <billy.tetrud@gmail•com> wrote: > > A maximum amount is allowed to be spent within EVERY epoch. > > It sounds like you're proposing an opcode that takes in epochStart and > epochEnd as parameters. I still don't understand why its useful to specify > those as absolute block heights. You mentioned that this enables more > straightforward validation logic, but I don't see how. Eg, if you have a > UTXO encumbered by rateLimit(epochStart = 800100, epochEnd = 800200, limit > = 100k, remain = 100k), what happens if you don't spend that UTXO before > block 800200? Is the output no longer rate limited then? Or is the opcode > calculating 800200-800100 = 100 and applying a rate limit for the next > epoch? If the first, then the UTXO must be spent within one epoch to remain > rate limited. If the second, then it seems nearly identical to simply > specifying window=100 as a parameter instead of epochStart and epochEnd. > > > then there must be only a single (rate-limited) output > > This rule would make transactions tricky if you're sending money into > someone else's wallet that may be rate limited. If the requirement is that > only you yourself can send money into a rate limited wallet, then this > point is moot but it would be ideal to not have such a requirement. > > This is how I'd imagine creating an opcode like this: > > rateLimit(windowSize = 144 blocks, limit = 100k sats) > > This would define that the epoch is 1 day's worth of blocks. This would > evenly divide bitcoin's retarget period and so each window would start and > end at those dividing lines (eg the first 144 blocks of the retargetting > period, then the second, then the third, etc). > > When this output is spent, it ensures that there's a maximum of 100k sats > is sent to addresses other than the originating address. It also records > the amount spent in the current 144 block window for that address (eg by > simply recording the already-spent amount on the resulting UTXO and having > an index that allows looking up UTXOs by address and adding them up). That > way, when any output from that address is spent again, if a new 144 block > window has started, the limit is reset, but if its still within the same > window, the already-spent amounts for UTXOs from that address are added up > and subtracted from the limit, and that number is the remaining limit a > subsequent transaction needs to adhere to. > > This way, 3rd party could send transactions into an address like this, and > multiple outputs can be combined and used to spend to arbitrary outputs (up > to the rate limit of course). > > On Wed, Aug 4, 2021 at 3:48 AM Zac Greenwood <zachgrw@gmail•com> wrote: > >> > Ah I see, this is all limited to within a single epoch. >> >> No, that wouldn't be useful. A maximum amount is allowed to be spent >> within EVERY epoch. >> >> Consider an epoch length of 100 blocks with a spend limit of 200k per >> epoch. The following is allowed: >> >> epoch1 (800101 - 800200): spend 120k in block 800140. Remaining for >> epoch1: 80k; >> epoch1 (800101 - 800200): spend another 60k in block 800195. Remaining >> for epoch1: 20k; >> epoch2 (800201 - 800300): spend 160k in block 800201. Remaining for >> epoch2: 40k. >> >> Since the limit pertains to each individual epoch, it is allowed to spend >> up to the full limit at the start of any new epoch. In this example, the >> spending was as follows: >> >> 800140: 120k >> 800195: 60k >> 800201: 160k. >> >> Note that in a span of 62 blocks a total of 340k sats was spent. This may >> seem to violate the 200k limit per 100 blocks, but this is the result of >> using a per-epoch limit. This allows a maximum of 400k to be spent in 2 >> blocks llke so: 200k in the last block of an epoch and another 200k in the >> first block of the next epoch. However this is inconsequential for the >> intended goal of rate-limiting which is to enable small spends over time >> from a large amount and to prevent theft of a large amount with a single >> transaction. >> >> To explain the proposed design more clearly, I have renamed the params as >> follows: >> >> epochStart: block height of first block of the current epoch (was: h0); >> epochEnd: block height of last block of the current epoch (was: h1); >> limit: the maximum total amount allowed to be spent within the current >> epoch (was: a); >> remain: the remaining amount allowed to be spent within the current epoch >> (was: a_remaining); >> >> Also, to illustrate that the params are specific to a transaction, I will >> hence precede the param with the transaction name like so: >> tx8_limit, tx31c_remain, tx42z_epochStart, ... etc. >> >> For simplicity, only transactions with no more than one rate-limited >> input are considered, and with no more than two outputs: one rate-limited >> change output, and a normal (not rate-limited) output. >> >> Normally, a simple transaction generates two outputs: one for a payment >> to a third party and one for the change address. Again for simplicity, we >> demand that a transaction which introduces rate-limiting must have only a >> single, rate-limited output. The validation rule might be: if a transaction >> has rate-limiting params and none of its inputs are rate-limited, then >> there must be only a single (rate-limited) output (and no second or change >> output). >> >> Consider rate limiting transactions tx1 having one or more normal (non >> rate-limited) inputs: >> >> tx1 gets included at block height 800004; >> The inputs of tx1 are not rate-limited => tx1 must have only a single >> output which will become rate-limited; >> params: tx1_epochStart=800001, tx1_epochEnd=800100, tx1_limit=200k, >> tx1_remain=200k; >> => This defines that an epoch has 100 blocks and no more than 200k sats >> may be spent in any one epoch. Within the current epoch, 200k sats may >> still be spent. >> >> This transaction begins to rate-limit a set of inputs, so it has a single >> rate-limited output. >> Let's explore transactions that have the output of tx1 as their input. I >> will denote the output of tx1 as "out1". >> >> tx2a has out1 as its only input; >> tx2a spends 50k sats and gets included at block height 803050; >> tx2a specifies the following params for its change output "chg2a": >> chg2a_epochStart=803001, chg2a_epochEnd=803100; >> chg2a_limit=200k, chg2a_remain=150k. >> >> To enforce rate-limiting, the system must validate the params of the >> change output chg2a to ensure that overspending is not allowed. >> >> The above params are allowed because: >> => 1. the epoch does not become smaller than 100 blocks [(chg2a_epochEnd >> - chg2a_epochStart) >= (tx1_epochEnd - tx1_epochStart)] >> => 2. tx1_limit has not been increased (ch2a_limit <= tx1_limit) >> => 3. the amount spent (50k sats) does not exceed tx1_remain AND does not >> exceed chg2a_limit; >> => 4. chg2a_remain" is 50k sats less than chg2a_limit. >> >> A transaction may also further constrain further spending like so: >> >> tx2b has out1as its only input; >> tx2b spends 8k sats and gets included at block height 808105; >> tx2b specifies the following params for its change output "chg2b": >> chg2b_epochStart=808101, chg2b_epochEnd=808250; >> chg2b_limit=10k, chg2b_remain=0. >> >> These params are allowed because: >> => 1. the epoch does not become smaller than100 blocks. It is fine to >> increase the epoch to 150 blocks because it does not enable exceeding the >> original rate-limit; >> => 2. the limit (chg2b_limit) has been decreased to 10k sats, further >> restricting the maximum amount allowed to be spent within the current and >> any subsequent epochs; >> => 3. the amount spent (10k sats) does not exceed tx1_remain AND does not >> exceed chg2b_limit; >> => 4. chg2b_remain has been set to zero, meaning that within the current >> epoch (block height 808101 to and including 808250), tx2b cannot be used as >> a spending input to any transaction. >> >> Starting from block height 808251, a new epoch will start and the >> rate-limited output of tx2b may again be used as an input for a subsequent >> rate-limited transaction tx3b. This transaction tx3b must again be >> accompanied by params that do not violate the rate-limit as defined by the >> params of tx2b and which are stored with output out2b. So, the epoch of >> tx3b must be at minimum 150 blocks, the maximum that is allowed to be spent >> per epoch is at most 10k sats, and chg3b_remain must be decreased by at >> least the amount spent by tx3b. >> >> From the above, the rate-limiting mechanics should hopefully be clear and >> full set of validation rules could be defined in a more generalized way >> with little additional effort. >> >> Note that I conveniently avoided talking about how to represent the >> parameters within transactions or outputs, simply because I currently lack >> enough understanding to reason about this. I am hoping that others may >> offer help. >> >> Zac >> >> >> On Tue, Aug 3, 2021 at 8:12 PM Billy Tetrud <billy.tetrud@gmail•com> >> wrote: >> >>> > To enable more straightforward validation logic. >>> > within the current epoch >>> >>> Ah I see, this is all limited to within a single epoch. I think that >>> sufficiently limits the window of time in which nodes have to store >>> information for rate limited outputs. However, I don't see how specifying >>> block ranges simplifies the logic - wouldn't this complicate the logic with >>> additional user-specified constraints? It also prevents the output from >>> being able to be rate limited over the span of multiple epochs, which would >>> seem to make it a lot more difficult to use for certain types of wallets >>> (eg cold wallets). >>> >>> I think I see the logic of your 'remaining' parameter there. If you >>> start with a single rate-limited input, you can split that into many >>> outputs, only one of which have a 'remaining' balance. The rest can simply >>> remain unspendable for the rest of the epoch. That way these things don't >>> need to be tied together. However, that doesn't solve the problem of 3rd >>> parties being able to send money into the wallet. >>> >>> > I don't believe that the marginal added functionality would justify >>> the increased implementation complexity >>> >>> Perhaps, but I think there is a lot of benefit in allowing these kinds >>> of things to operate as similarly as possible to normal transactions, for >>> one because of usability reasons. If each opcode has its own quirks that >>> are not intuitively related to their purpose (eg if a rate-limited wallet >>> had no way to get a receiving address), it would confuse end-users (eg who >>> wonder how to get a receiving address and how they can ask people to send >>> money into their wallet) or require a lot of technical complexity in >>> applications (eg to support something like cooperatively connecting with >>> their wallet so that a transaction can be made that creates a new >>> single-output for the wallet). A little complexity in this opcode can save >>> a lot of external complexity here I think. >>> >>> > my understanding of Bitcoin is way too low to be able to write a BIP >>> and do the implementation >>> >>> You might be able to find people willing to help. I would be willing to >>> help write the BIP spec. I'm not the right person to help with the >>> implementation, but perhaps you could find someone else who is. Even if the >>> BIP isn't adopted, it could be a starting point or inspiration for someone >>> else to write an improved version. >>> >>> On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <zachgrw@gmail•com> wrote: >>> >>>> [Note: I've moved your reply to the newly started thread] >>>> >>>> Hi Billy, >>>> >>>> Thank you for your kind and encouraging feedback. >>>> >>>> I don't quite understand why you'd want to define a specific span of >>>>> blocks for the rate limit. Why not just specify the size of the window (in >>>>> blocks) to rate limit within, and the limit? >>>> >>>> >>>> To enable more straightforward validation logic. >>>> >>>> You mentioned change addresses, however, with the parameters you >>>>> defined, there would be no way to connect together the change address with >>>>> the original address, meaning they would have completely separate rate >>>>> limits, which wouldn't work since the change output would ignore the >>>>> previous rate limit. >>>> >>>> >>>> The rate-limiting parameters must be re-specified for each rate-limited >>>> input. So, a transaction that has a rate-limited input is only valid if its >>>> output is itself rate-limited such that it does not violate the >>>> rate-limiting constraints of its input. >>>> >>>> In my thread-starter, I gave the below example of a rate-limited >>>> address a2 that serves as input for transaction t2: >>>> >>>> a2: 99.8 sats at height 800100; >>>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; >>>> >>>> Transaction t2: >>>> Included at block height 800200 >>>> Spend: 400k + fees. >>>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. >>>> >>>> Note how transaction t2 re-specifies the rate-limiting parameters. >>>> Validation must ensure that the re-specified parameters are within bounds, >>>> i.e., do not allow more spending per epoch than the rate-limiting >>>> parameters of its input address a2. Re-specifying the rate-limiting >>>> parameters offers the flexibility to further restrict spending, or to >>>> disable any additional spending within the current epoch by setting >>>> a_remaining to zero. >>>> >>>> Result: >>>> Value at destination address: 400k sats; >>>> Rate limiting params at destination address: none; >>>> Value at change address a3: 99.4m sats; >>>> Rate limiting params at change address a3: h0=800144, h1=800287, >>>> a=500k, a_remaining=100k. >>>> >>>> As a design principle I believe it makes sense if the system is able to >>>> verify the validity of a transaction without having to consider any >>>> transactions that precede its inputs. As a side-note, doing away with this >>>> design principle would however enable more sophisticated rate-limiting >>>> (such as rate-limiting per sliding window instead of rate-limiting per >>>> epoch having a fixed start and end block), but while at the same time >>>> reducing the size of per rate-limiting transaction (because it would enable >>>> specifying the rate-limiting parameters more space-efficiently). To test >>>> the waters and to keep things relatively simple, I chose not to go into >>>> this enhanced form of rate-limiting. >>>> >>>> I haven't gone into how to process a transaction having multiple >>>> rate-limited inputs. The easiest way to handle this case is to not allow >>>> any transaction having more than one rate-limited input. One could imagine >>>> complex logic to handle transactions having multiple rate-limited inputs by >>>> creating multiple rate-limited change addresses. However at first glance I >>>> don't believe that the marginal added functionality would justify the >>>> increased implementation complexity. >>>> >>>> I'd be interested in seeing you write a BIP for this. >>>> >>>> >>>> Thank you, but sadly my understanding of Bitcoin is way too low to be >>>> able to write a BIP and do the implementation. However I see tremendous >>>> value in this functionality. Favorable feedback of the list regarding the >>>> usefulness and the technical feasibility of rate-limiting functionality >>>> would of course be an encouragement for me to descend further down the >>>> rabbit hole. >>>> >>>> Zac >>>> >>>> >>>> On Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw@gmail•com> >>>> wrote: >>>> >>>>> [Resubmitting to list with minor edits. My previous submission ended >>>>> up inside an existing thread, apologies.] >>>>> >>>>> Hi list, >>>>> >>>>> I'd like to explore whether it is feasible to implement new scripting >>>>> capabilities in Bitcoin that enable limiting the output amount of a >>>>> transaction based on the total value of its inputs. In other words, to >>>>> implement the ability to limit the maximum amount that can be sent from an >>>>> address. >>>>> >>>>> Two use cases come to mind: >>>>> >>>>> UC1: enable a user to add additional protection their funds by >>>>> rate-limiting the amount that they are allowed to send during a certain >>>>> period (measured in blocks). A typical use case might be a user that >>>>> intends to hodl their bitcoin, but still wishes to occasionally send small >>>>> amounts. Rate-limiting avoids an attacker from sweeping all the users' >>>>> funds in a single transaction, allowing the user to become aware of the >>>>> theft and intervene to prevent further thefts. >>>>> >>>>> UC2: exchanges may wish to rate-limit addresses containing large >>>>> amounts of bitcoin, adding warm- or hot-wallet functionality to a >>>>> cold-storage address. This would enable an exchange to drastically reduce >>>>> the number of times a cold wallet must be accessed with private keys that >>>>> give access to the full amount. >>>>> >>>>> In a typical setup, I'd envision using multisig such that the user has >>>>> two sets of private keys to their encumbered address (with a "set" of keys >>>>> meaning "one or more" keys). One set of private keys allows only for >>>>> sending with rate-limiting restrictions in place, and a second set of >>>>> private keys allowing for sending any amount without rate-limiting, >>>>> effectively overriding such restriction. >>>>> >>>>> The parameters that define in what way an output is rate-limited might >>>>> be defined as follows: >>>>> >>>>> Param 1: a block height "h0" indicating the first block height of an >>>>> epoch; >>>>> Param 2: a block height "h1" indicating the last block height of an >>>>> epoch; >>>>> Param 3: an amount "a" in satoshi indicating the maximum amount that >>>>> is allowed to be sent in any epoch; >>>>> Param 4: an amount "a_remaining" (in satoshi) indicating the maximum >>>>> amount that is allowed to be sent within the current epoch. >>>>> >>>>> For example, consider an input containing 100m sats (1 BTC) which has >>>>> been rate-limited with parameters (h0, h1, a, a_remaining) of (800000, >>>>> 800143, 500k, 500k). These parameters define that the address is >>>>> rate-limited to sending a maximum of 500k sats in the current epoch that >>>>> starts at block height 800000 and ends at height 800143 (or about one day >>>>> ignoring block time variance) and that the full amount of 500k is still >>>>> sendable. These rate-limiting parameters ensure that it takes at minimum >>>>> 100m / 500k = 200 transactions and 200 x 144 blocks or about 200 days to >>>>> spend the full 100m sats. As noted earlier, in a typical setup a user >>>>> should retain the option to transact the entire amount using a second (set >>>>> of) private key(s). >>>>> >>>>> For rate-limiting to work, any change output created by a transaction >>>>> from a rate-limited address must itself be rate-limited as well. For >>>>> instance, expanding on the above example, assume that the user spends 200k >>>>> sats from a rate-limited address a1 containing 100m sats: >>>>> >>>>> Start situation: >>>>> At block height 800000: rate-limited address a1 is created; >>>>> Value of a1: 100.0m sats; >>>>> Rate limiting params of a1: h0=800000, h1=800143, a=500k, >>>>> a_remaining=500k; >>>>> >>>>> Transaction t1: >>>>> Included at block height 800100; >>>>> Spend: 200k + fee; >>>>> Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k. >>>>> >>>>> Result: >>>>> Value at destination address: 200k sats; >>>>> Rate limiting params at destination address: none; >>>>> Value at change address a2: 99.8m sats; >>>>> Rate limiting params at change address a2: h0=800000, h1=800143, >>>>> a=500k, a_remaining=300k. >>>>> >>>>> In order to properly enforce rate limiting, the change address must be >>>>> rate-limited such that the original rate limit of 500k sats per 144 blocks >>>>> cannot be exceeded. In this example, the change address a2 were given the >>>>> same rate limiting parameters as the transaction that served as its input. >>>>> As a result, from block 800100 up until and including block 800143, a >>>>> maximum amount of 300k sats is allowed to be spent from the change address. >>>>> >>>>> Example continued: >>>>> a2: 99.8 sats at height 800100; >>>>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; >>>>> >>>>> Transaction t2: >>>>> Included at block height 800200 >>>>> Spend: 400k + fees. >>>>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. >>>>> >>>>> Result: >>>>> Value at destination address: 400k sats; >>>>> Rate limiting params at destination address: none; >>>>> Value at change address a3: 99.4m sats; >>>>> Rate limiting params at change address a3: h0=800144, h1=800287, >>>>> a=500k, a_remaining=100k. >>>>> >>>>> Transaction t2 is allowed because it falls within the next epoch >>>>> (running from 800144 to 800287) so a spend of 400k does not violate the >>>>> constraint of 500k per epoch. >>>>> >>>>> As could be seen, the rate limiting parameters are part of the >>>>> transaction and chosen by the user (or their wallet). This means that the >>>>> parameters must be validated to ensure that they do not violate the >>>>> intended constraints. >>>>> >>>>> For instance, this transaction should not be allowed: >>>>> a2: 99.8 sats at height 800100; >>>>> Rate-limit params of a2: h0=800000, h1=800143, a=500k, >>>>> a_remaining=300k; >>>>> >>>>> Transaction t2a: >>>>> Included at block height 800200; >>>>> Spend: 400k + fees; >>>>> Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k. >>>>> >>>>> This transaction t2a attempts to shift the epoch forward by 20 blocks >>>>> such that it starts at 800124 instead of 800144. Shifting the epoch forward >>>>> like this must not be allowed because it enables spending more that the >>>>> rate limit allows, which is 500k in any epoch of 144 blocks. It would >>>>> enable overspending: >>>>> >>>>> t1: spend 200k at 800100 (epoch 1: total: 200k); >>>>> t2a: spend 400k at 800200 (epoch 2: total: 400k); >>>>> t3a: spend 100k at 800201 (epoch 2: total: 500k); >>>>> t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for >>>>> epoch 2). >>>>> >>>>> Specifying the rate-limiting parameters explicitly at every >>>>> transaction allows the user to tighten the spending limit by setting >>>>> tighter limits or for instance by setting a_remainder to 0 if they wish to >>>>> enforce not spending more during an epoch. A second advantage of explicitly >>>>> specifying the four rate-limiting parameters with each transaction is that >>>>> it allows the system to fully validate the transaction without having to >>>>> consider any previous transactions within an epoch. >>>>> >>>>> I will stop here because I would like to gauge interest in this idea >>>>> first before continuing work on other aspects. Two main pieces of work jump >>>>> to mind: >>>>> >>>>> Define all validations; >>>>> Describe aggregate behaviour of multiple (rate-limited) inputs, proof >>>>> that two rate-limited addresses cannot spend more than the sum of their >>>>> individual limits. >>>>> >>>>> Zac >>>>> >>>> [-- Attachment #2: Type: text/html, Size: 30746 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value 2021-08-05 14:22 ` Zac Greenwood @ 2021-08-10 0:41 ` Billy Tetrud 0 siblings, 0 replies; 33+ messages in thread From: Billy Tetrud @ 2021-08-10 0:41 UTC (permalink / raw) To: Zac Greenwood; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 28374 bytes --] > By explicitly specifying the start and end block of an epoch, the user has more flexibility in shifting the epoch Ok I see. I think I understand your proposal better now. If the output is spent within the range epochStart - epochEnd, the limit holds, if it is spent outside that range the change output must also have a range of the same length (or shorter?). So you want there to be the ability for the user to precisely define the length and starting block of the rate-limiting-period (epoch). I'd say it'd be clearer to specify the window length and the starting block in that case. The same semantics can be kept. > This would require the system to bookkeep how much was spent since the first rate-limited output Yes, for the length of the epoch, after which the bookkeeping can be discarded/reset until a new transaction is sent. Your proposal also requires bookkeeping tho - it needs to store the 'remain' value with the UTXO as well because its not efficient to go back and re-execute the script just to grab that value. > using an address as input for a transaction will always spends the full amount at that address Using a UTXO will spend the full UTXO. The address may contain many UTXOs. I'm not suggesting that a change address isn't needed - I'm suggesting that the *same* address be used as the change address for the change output. Eg consider the following UTXO info: Address X: rateLimit(windowSize = 144 blocks, limit = 100k sats) * UTXO 1: 100k sats, 50k spent by ancestor inputs since epochStart 800100 * UTXO 2: 200k sats, 10k spent since epochStart When sending a transaction using UTXO 2, a node would look up the list of UTXOs in Address X, add up the amount spent since epochStart (60k) and ensure that at most 40k is going to an address that isn't address X. So a valid transaction might look like: Input: UTXO 2 Output 1: 30k -> Address A Output 2: 170k -> Address X On Thu, Aug 5, 2021 at 7:22 AM Zac Greenwood <zachgrw@gmail•com> wrote: > Hi Billy, > > > It sounds like you're proposing an opcode > > No. I don’t have enough knowledge of Bitcoin to be able to tell how (and > if) rate-limiting can be implemented as I suggested. I am not able to > reason about opcodes, so I kept my description at a more functional level. > > > I still don't understand why its useful to specify those as absolute > block heights > > I feel that this a rather uninteresting data representation aspect that’s > not worth going back and forth about. Sure, specifying the length of the > epoch may also be an option, although at the price of giving up some > functionality, and without much if any gains. > > By explicitly specifying the start and end block of an epoch, the user has > more flexibility in shifting the epoch (using alternate values for > epochStart and epochEnd) and simultaneously increasing the length of an > epoch. These seem rather exotic features, but there’s no harm in retaining > them. > > > if you have a UTXO encumbered by rateLimit(epochStart = 800100, > epochEnd = 800200, limit = 100k, remain = 100k), what happens if you don't > spend that UTXO before block 800200? > > The rate limit remains in place. So if this UTXO is spent in block 900000, > then at most 100k may be spent. Also, the new epoch must be at least 100 > blocks and remain must correctly account for the actual amount spent. > > > This is how I'd imagine creating an opcode like this: > > > rateLimit(windowSize = 144 blocks, limit = 100k sats) > > This would require the system to bookkeep how much was spent since the > first rate-limited output. It is a more intuitive way of rate-limiting but > it may be much more difficult to implement, which is why I went with the > epoch-based rate limiting solution. In terms of functionality, I believe > the two solutions are nearly identical for all practical purposes. > > Your next section confuses me. As I understand it, using an address as > input for a transaction will always spends the full amount at that address. > That’s why change addresses are required, no? If Bitcoin were able to pay > exact amounts then there wouldn’t be any need for change outputs. > > Zac > > > On Thu, 5 Aug 2021 at 08:39, Billy Tetrud <billy.tetrud@gmail•com> wrote: > >> > A maximum amount is allowed to be spent within EVERY epoch. >> >> It sounds like you're proposing an opcode that takes in epochStart and >> epochEnd as parameters. I still don't understand why its useful to specify >> those as absolute block heights. You mentioned that this enables more >> straightforward validation logic, but I don't see how. Eg, if you have a >> UTXO encumbered by rateLimit(epochStart = 800100, epochEnd = 800200, limit >> = 100k, remain = 100k), what happens if you don't spend that UTXO before >> block 800200? Is the output no longer rate limited then? Or is the opcode >> calculating 800200-800100 = 100 and applying a rate limit for the next >> epoch? If the first, then the UTXO must be spent within one epoch to remain >> rate limited. If the second, then it seems nearly identical to simply >> specifying window=100 as a parameter instead of epochStart and epochEnd. >> >> > then there must be only a single (rate-limited) output >> >> This rule would make transactions tricky if you're sending money into >> someone else's wallet that may be rate limited. If the requirement is that >> only you yourself can send money into a rate limited wallet, then this >> point is moot but it would be ideal to not have such a requirement. >> >> This is how I'd imagine creating an opcode like this: >> >> rateLimit(windowSize = 144 blocks, limit = 100k sats) >> >> This would define that the epoch is 1 day's worth of blocks. This would >> evenly divide bitcoin's retarget period and so each window would start and >> end at those dividing lines (eg the first 144 blocks of the retargetting >> period, then the second, then the third, etc). >> >> When this output is spent, it ensures that there's a maximum of 100k sats >> is sent to addresses other than the originating address. It also records >> the amount spent in the current 144 block window for that address (eg by >> simply recording the already-spent amount on the resulting UTXO and having >> an index that allows looking up UTXOs by address and adding them up). That >> way, when any output from that address is spent again, if a new 144 block >> window has started, the limit is reset, but if its still within the same >> window, the already-spent amounts for UTXOs from that address are added up >> and subtracted from the limit, and that number is the remaining limit a >> subsequent transaction needs to adhere to. >> >> This way, 3rd party could send transactions into an address like this, >> and multiple outputs can be combined and used to spend to arbitrary outputs >> (up to the rate limit of course). >> >> On Wed, Aug 4, 2021 at 3:48 AM Zac Greenwood <zachgrw@gmail•com> wrote: >> >>> > Ah I see, this is all limited to within a single epoch. >>> >>> No, that wouldn't be useful. A maximum amount is allowed to be spent >>> within EVERY epoch. >>> >>> Consider an epoch length of 100 blocks with a spend limit of 200k per >>> epoch. The following is allowed: >>> >>> epoch1 (800101 - 800200): spend 120k in block 800140. Remaining for >>> epoch1: 80k; >>> epoch1 (800101 - 800200): spend another 60k in block 800195. Remaining >>> for epoch1: 20k; >>> epoch2 (800201 - 800300): spend 160k in block 800201. Remaining for >>> epoch2: 40k. >>> >>> Since the limit pertains to each individual epoch, it is allowed to >>> spend up to the full limit at the start of any new epoch. In this example, >>> the spending was as follows: >>> >>> 800140: 120k >>> 800195: 60k >>> 800201: 160k. >>> >>> Note that in a span of 62 blocks a total of 340k sats was spent. This >>> may seem to violate the 200k limit per 100 blocks, but this is the result >>> of using a per-epoch limit. This allows a maximum of 400k to be spent in 2 >>> blocks llke so: 200k in the last block of an epoch and another 200k in the >>> first block of the next epoch. However this is inconsequential for the >>> intended goal of rate-limiting which is to enable small spends over time >>> from a large amount and to prevent theft of a large amount with a single >>> transaction. >>> >>> To explain the proposed design more clearly, I have renamed the params >>> as follows: >>> >>> epochStart: block height of first block of the current epoch (was: h0); >>> epochEnd: block height of last block of the current epoch (was: h1); >>> limit: the maximum total amount allowed to be spent within the current >>> epoch (was: a); >>> remain: the remaining amount allowed to be spent within the current >>> epoch (was: a_remaining); >>> >>> Also, to illustrate that the params are specific to a transaction, I >>> will hence precede the param with the transaction name like so: >>> tx8_limit, tx31c_remain, tx42z_epochStart, ... etc. >>> >>> For simplicity, only transactions with no more than one rate-limited >>> input are considered, and with no more than two outputs: one rate-limited >>> change output, and a normal (not rate-limited) output. >>> >>> Normally, a simple transaction generates two outputs: one for a payment >>> to a third party and one for the change address. Again for simplicity, we >>> demand that a transaction which introduces rate-limiting must have only a >>> single, rate-limited output. The validation rule might be: if a transaction >>> has rate-limiting params and none of its inputs are rate-limited, then >>> there must be only a single (rate-limited) output (and no second or change >>> output). >>> >>> Consider rate limiting transactions tx1 having one or more normal (non >>> rate-limited) inputs: >>> >>> tx1 gets included at block height 800004; >>> The inputs of tx1 are not rate-limited => tx1 must have only a single >>> output which will become rate-limited; >>> params: tx1_epochStart=800001, tx1_epochEnd=800100, tx1_limit=200k, >>> tx1_remain=200k; >>> => This defines that an epoch has 100 blocks and no more than 200k sats >>> may be spent in any one epoch. Within the current epoch, 200k sats may >>> still be spent. >>> >>> This transaction begins to rate-limit a set of inputs, so it has a >>> single rate-limited output. >>> Let's explore transactions that have the output of tx1 as their input. I >>> will denote the output of tx1 as "out1". >>> >>> tx2a has out1 as its only input; >>> tx2a spends 50k sats and gets included at block height 803050; >>> tx2a specifies the following params for its change output "chg2a": >>> chg2a_epochStart=803001, chg2a_epochEnd=803100; >>> chg2a_limit=200k, chg2a_remain=150k. >>> >>> To enforce rate-limiting, the system must validate the params of the >>> change output chg2a to ensure that overspending is not allowed. >>> >>> The above params are allowed because: >>> => 1. the epoch does not become smaller than 100 blocks [(chg2a_epochEnd >>> - chg2a_epochStart) >= (tx1_epochEnd - tx1_epochStart)] >>> => 2. tx1_limit has not been increased (ch2a_limit <= tx1_limit) >>> => 3. the amount spent (50k sats) does not exceed tx1_remain AND does >>> not exceed chg2a_limit; >>> => 4. chg2a_remain" is 50k sats less than chg2a_limit. >>> >>> A transaction may also further constrain further spending like so: >>> >>> tx2b has out1as its only input; >>> tx2b spends 8k sats and gets included at block height 808105; >>> tx2b specifies the following params for its change output "chg2b": >>> chg2b_epochStart=808101, chg2b_epochEnd=808250; >>> chg2b_limit=10k, chg2b_remain=0. >>> >>> These params are allowed because: >>> => 1. the epoch does not become smaller than100 blocks. It is fine to >>> increase the epoch to 150 blocks because it does not enable exceeding the >>> original rate-limit; >>> => 2. the limit (chg2b_limit) has been decreased to 10k sats, further >>> restricting the maximum amount allowed to be spent within the current and >>> any subsequent epochs; >>> => 3. the amount spent (10k sats) does not exceed tx1_remain AND does >>> not exceed chg2b_limit; >>> => 4. chg2b_remain has been set to zero, meaning that within the current >>> epoch (block height 808101 to and including 808250), tx2b cannot be used as >>> a spending input to any transaction. >>> >>> Starting from block height 808251, a new epoch will start and the >>> rate-limited output of tx2b may again be used as an input for a subsequent >>> rate-limited transaction tx3b. This transaction tx3b must again be >>> accompanied by params that do not violate the rate-limit as defined by the >>> params of tx2b and which are stored with output out2b. So, the epoch of >>> tx3b must be at minimum 150 blocks, the maximum that is allowed to be spent >>> per epoch is at most 10k sats, and chg3b_remain must be decreased by at >>> least the amount spent by tx3b. >>> >>> From the above, the rate-limiting mechanics should hopefully be clear >>> and full set of validation rules could be defined in a more generalized way >>> with little additional effort. >>> >>> Note that I conveniently avoided talking about how to represent the >>> parameters within transactions or outputs, simply because I currently lack >>> enough understanding to reason about this. I am hoping that others may >>> offer help. >>> >>> Zac >>> >>> >>> On Tue, Aug 3, 2021 at 8:12 PM Billy Tetrud <billy.tetrud@gmail•com> >>> wrote: >>> >>>> > To enable more straightforward validation logic. >>>> > within the current epoch >>>> >>>> Ah I see, this is all limited to within a single epoch. I think that >>>> sufficiently limits the window of time in which nodes have to store >>>> information for rate limited outputs. However, I don't see how specifying >>>> block ranges simplifies the logic - wouldn't this complicate the logic with >>>> additional user-specified constraints? It also prevents the output from >>>> being able to be rate limited over the span of multiple epochs, which would >>>> seem to make it a lot more difficult to use for certain types of wallets >>>> (eg cold wallets). >>>> >>>> I think I see the logic of your 'remaining' parameter there. If you >>>> start with a single rate-limited input, you can split that into many >>>> outputs, only one of which have a 'remaining' balance. The rest can simply >>>> remain unspendable for the rest of the epoch. That way these things don't >>>> need to be tied together. However, that doesn't solve the problem of 3rd >>>> parties being able to send money into the wallet. >>>> >>>> > I don't believe that the marginal added functionality would justify >>>> the increased implementation complexity >>>> >>>> Perhaps, but I think there is a lot of benefit in allowing these kinds >>>> of things to operate as similarly as possible to normal transactions, for >>>> one because of usability reasons. If each opcode has its own quirks that >>>> are not intuitively related to their purpose (eg if a rate-limited wallet >>>> had no way to get a receiving address), it would confuse end-users (eg who >>>> wonder how to get a receiving address and how they can ask people to send >>>> money into their wallet) or require a lot of technical complexity in >>>> applications (eg to support something like cooperatively connecting with >>>> their wallet so that a transaction can be made that creates a new >>>> single-output for the wallet). A little complexity in this opcode can save >>>> a lot of external complexity here I think. >>>> >>>> > my understanding of Bitcoin is way too low to be able to write a BIP >>>> and do the implementation >>>> >>>> You might be able to find people willing to help. I would be willing to >>>> help write the BIP spec. I'm not the right person to help with the >>>> implementation, but perhaps you could find someone else who is. Even if the >>>> BIP isn't adopted, it could be a starting point or inspiration for someone >>>> else to write an improved version. >>>> >>>> On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <zachgrw@gmail•com> wrote: >>>> >>>>> [Note: I've moved your reply to the newly started thread] >>>>> >>>>> Hi Billy, >>>>> >>>>> Thank you for your kind and encouraging feedback. >>>>> >>>>> I don't quite understand why you'd want to define a specific span of >>>>>> blocks for the rate limit. Why not just specify the size of the window (in >>>>>> blocks) to rate limit within, and the limit? >>>>> >>>>> >>>>> To enable more straightforward validation logic. >>>>> >>>>> You mentioned change addresses, however, with the parameters you >>>>>> defined, there would be no way to connect together the change address with >>>>>> the original address, meaning they would have completely separate rate >>>>>> limits, which wouldn't work since the change output would ignore the >>>>>> previous rate limit. >>>>> >>>>> >>>>> The rate-limiting parameters must be re-specified for each >>>>> rate-limited input. So, a transaction that has a rate-limited input is only >>>>> valid if its output is itself rate-limited such that it does not violate >>>>> the rate-limiting constraints of its input. >>>>> >>>>> In my thread-starter, I gave the below example of a rate-limited >>>>> address a2 that serves as input for transaction t2: >>>>> >>>>> a2: 99.8 sats at height 800100; >>>>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; >>>>> >>>>> Transaction t2: >>>>> Included at block height 800200 >>>>> Spend: 400k + fees. >>>>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. >>>>> >>>>> Note how transaction t2 re-specifies the rate-limiting parameters. >>>>> Validation must ensure that the re-specified parameters are within bounds, >>>>> i.e., do not allow more spending per epoch than the rate-limiting >>>>> parameters of its input address a2. Re-specifying the rate-limiting >>>>> parameters offers the flexibility to further restrict spending, or to >>>>> disable any additional spending within the current epoch by setting >>>>> a_remaining to zero. >>>>> >>>>> Result: >>>>> Value at destination address: 400k sats; >>>>> Rate limiting params at destination address: none; >>>>> Value at change address a3: 99.4m sats; >>>>> Rate limiting params at change address a3: h0=800144, h1=800287, >>>>> a=500k, a_remaining=100k. >>>>> >>>>> As a design principle I believe it makes sense if the system is able >>>>> to verify the validity of a transaction without having to consider any >>>>> transactions that precede its inputs. As a side-note, doing away with this >>>>> design principle would however enable more sophisticated rate-limiting >>>>> (such as rate-limiting per sliding window instead of rate-limiting per >>>>> epoch having a fixed start and end block), but while at the same time >>>>> reducing the size of per rate-limiting transaction (because it would enable >>>>> specifying the rate-limiting parameters more space-efficiently). To test >>>>> the waters and to keep things relatively simple, I chose not to go into >>>>> this enhanced form of rate-limiting. >>>>> >>>>> I haven't gone into how to process a transaction having multiple >>>>> rate-limited inputs. The easiest way to handle this case is to not allow >>>>> any transaction having more than one rate-limited input. One could imagine >>>>> complex logic to handle transactions having multiple rate-limited inputs by >>>>> creating multiple rate-limited change addresses. However at first glance I >>>>> don't believe that the marginal added functionality would justify the >>>>> increased implementation complexity. >>>>> >>>>> I'd be interested in seeing you write a BIP for this. >>>>> >>>>> >>>>> Thank you, but sadly my understanding of Bitcoin is way too low to be >>>>> able to write a BIP and do the implementation. However I see tremendous >>>>> value in this functionality. Favorable feedback of the list regarding the >>>>> usefulness and the technical feasibility of rate-limiting functionality >>>>> would of course be an encouragement for me to descend further down the >>>>> rabbit hole. >>>>> >>>>> Zac >>>>> >>>>> >>>>> On Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw@gmail•com> >>>>> wrote: >>>>> >>>>>> [Resubmitting to list with minor edits. My previous submission ended >>>>>> up inside an existing thread, apologies.] >>>>>> >>>>>> Hi list, >>>>>> >>>>>> I'd like to explore whether it is feasible to implement new scripting >>>>>> capabilities in Bitcoin that enable limiting the output amount of a >>>>>> transaction based on the total value of its inputs. In other words, to >>>>>> implement the ability to limit the maximum amount that can be sent from an >>>>>> address. >>>>>> >>>>>> Two use cases come to mind: >>>>>> >>>>>> UC1: enable a user to add additional protection their funds by >>>>>> rate-limiting the amount that they are allowed to send during a certain >>>>>> period (measured in blocks). A typical use case might be a user that >>>>>> intends to hodl their bitcoin, but still wishes to occasionally send small >>>>>> amounts. Rate-limiting avoids an attacker from sweeping all the users' >>>>>> funds in a single transaction, allowing the user to become aware of the >>>>>> theft and intervene to prevent further thefts. >>>>>> >>>>>> UC2: exchanges may wish to rate-limit addresses containing large >>>>>> amounts of bitcoin, adding warm- or hot-wallet functionality to a >>>>>> cold-storage address. This would enable an exchange to drastically reduce >>>>>> the number of times a cold wallet must be accessed with private keys that >>>>>> give access to the full amount. >>>>>> >>>>>> In a typical setup, I'd envision using multisig such that the user >>>>>> has two sets of private keys to their encumbered address (with a "set" of >>>>>> keys meaning "one or more" keys). One set of private keys allows only for >>>>>> sending with rate-limiting restrictions in place, and a second set of >>>>>> private keys allowing for sending any amount without rate-limiting, >>>>>> effectively overriding such restriction. >>>>>> >>>>>> The parameters that define in what way an output is rate-limited >>>>>> might be defined as follows: >>>>>> >>>>>> Param 1: a block height "h0" indicating the first block height of an >>>>>> epoch; >>>>>> Param 2: a block height "h1" indicating the last block height of an >>>>>> epoch; >>>>>> Param 3: an amount "a" in satoshi indicating the maximum amount that >>>>>> is allowed to be sent in any epoch; >>>>>> Param 4: an amount "a_remaining" (in satoshi) indicating the maximum >>>>>> amount that is allowed to be sent within the current epoch. >>>>>> >>>>>> For example, consider an input containing 100m sats (1 BTC) which has >>>>>> been rate-limited with parameters (h0, h1, a, a_remaining) of (800000, >>>>>> 800143, 500k, 500k). These parameters define that the address is >>>>>> rate-limited to sending a maximum of 500k sats in the current epoch that >>>>>> starts at block height 800000 and ends at height 800143 (or about one day >>>>>> ignoring block time variance) and that the full amount of 500k is still >>>>>> sendable. These rate-limiting parameters ensure that it takes at minimum >>>>>> 100m / 500k = 200 transactions and 200 x 144 blocks or about 200 days to >>>>>> spend the full 100m sats. As noted earlier, in a typical setup a user >>>>>> should retain the option to transact the entire amount using a second (set >>>>>> of) private key(s). >>>>>> >>>>>> For rate-limiting to work, any change output created by a transaction >>>>>> from a rate-limited address must itself be rate-limited as well. For >>>>>> instance, expanding on the above example, assume that the user spends 200k >>>>>> sats from a rate-limited address a1 containing 100m sats: >>>>>> >>>>>> Start situation: >>>>>> At block height 800000: rate-limited address a1 is created; >>>>>> Value of a1: 100.0m sats; >>>>>> Rate limiting params of a1: h0=800000, h1=800143, a=500k, >>>>>> a_remaining=500k; >>>>>> >>>>>> Transaction t1: >>>>>> Included at block height 800100; >>>>>> Spend: 200k + fee; >>>>>> Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k. >>>>>> >>>>>> Result: >>>>>> Value at destination address: 200k sats; >>>>>> Rate limiting params at destination address: none; >>>>>> Value at change address a2: 99.8m sats; >>>>>> Rate limiting params at change address a2: h0=800000, h1=800143, >>>>>> a=500k, a_remaining=300k. >>>>>> >>>>>> In order to properly enforce rate limiting, the change address must >>>>>> be rate-limited such that the original rate limit of 500k sats per 144 >>>>>> blocks cannot be exceeded. In this example, the change address a2 were >>>>>> given the same rate limiting parameters as the transaction that served as >>>>>> its input. As a result, from block 800100 up until and including block >>>>>> 800143, a maximum amount of 300k sats is allowed to be spent from the >>>>>> change address. >>>>>> >>>>>> Example continued: >>>>>> a2: 99.8 sats at height 800100; >>>>>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k; >>>>>> >>>>>> Transaction t2: >>>>>> Included at block height 800200 >>>>>> Spend: 400k + fees. >>>>>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k. >>>>>> >>>>>> Result: >>>>>> Value at destination address: 400k sats; >>>>>> Rate limiting params at destination address: none; >>>>>> Value at change address a3: 99.4m sats; >>>>>> Rate limiting params at change address a3: h0=800144, h1=800287, >>>>>> a=500k, a_remaining=100k. >>>>>> >>>>>> Transaction t2 is allowed because it falls within the next epoch >>>>>> (running from 800144 to 800287) so a spend of 400k does not violate the >>>>>> constraint of 500k per epoch. >>>>>> >>>>>> As could be seen, the rate limiting parameters are part of the >>>>>> transaction and chosen by the user (or their wallet). This means that the >>>>>> parameters must be validated to ensure that they do not violate the >>>>>> intended constraints. >>>>>> >>>>>> For instance, this transaction should not be allowed: >>>>>> a2: 99.8 sats at height 800100; >>>>>> Rate-limit params of a2: h0=800000, h1=800143, a=500k, >>>>>> a_remaining=300k; >>>>>> >>>>>> Transaction t2a: >>>>>> Included at block height 800200; >>>>>> Spend: 400k + fees; >>>>>> Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k. >>>>>> >>>>>> This transaction t2a attempts to shift the epoch forward by 20 blocks >>>>>> such that it starts at 800124 instead of 800144. Shifting the epoch forward >>>>>> like this must not be allowed because it enables spending more that the >>>>>> rate limit allows, which is 500k in any epoch of 144 blocks. It would >>>>>> enable overspending: >>>>>> >>>>>> t1: spend 200k at 800100 (epoch 1: total: 200k); >>>>>> t2a: spend 400k at 800200 (epoch 2: total: 400k); >>>>>> t3a: spend 100k at 800201 (epoch 2: total: 500k); >>>>>> t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for >>>>>> epoch 2). >>>>>> >>>>>> Specifying the rate-limiting parameters explicitly at every >>>>>> transaction allows the user to tighten the spending limit by setting >>>>>> tighter limits or for instance by setting a_remainder to 0 if they wish to >>>>>> enforce not spending more during an epoch. A second advantage of explicitly >>>>>> specifying the four rate-limiting parameters with each transaction is that >>>>>> it allows the system to fully validate the transaction without having to >>>>>> consider any previous transactions within an epoch. >>>>>> >>>>>> I will stop here because I would like to gauge interest in this idea >>>>>> first before continuing work on other aspects. Two main pieces of work jump >>>>>> to mind: >>>>>> >>>>>> Define all validations; >>>>>> Describe aggregate behaviour of multiple (rate-limited) inputs, proof >>>>>> that two rate-limited addresses cannot spend more than the sum of their >>>>>> individual limits. >>>>>> >>>>>> Zac >>>>>> >>>>> [-- Attachment #2: Type: text/html, Size: 33740 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2021-11-01 1:20 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-21 5:56 [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) Billy Tetrud
2021-07-25 5:38 ` David A. Harding
2021-07-25 19:49 ` Billy Tetrud
2021-07-26 0:05 ` David A. Harding
[not found] ` <SN7PR18MB3981DC1CD23B90367045995FD2E89@SN7PR18MB3981.namprd18.prod.outlook.com>
2021-07-26 20:18 ` Billy Tetrud
2021-07-26 21:08 ` James MacWhyte
2021-07-27 0:41 ` Billy Tetrud
2021-07-27 11:18 ` Zac Greenwood
2021-07-27 17:21 ` Billy Tetrud
2021-07-28 4:57 ` Zac Greenwood
2021-07-28 17:57 ` Billy Tetrud
2021-07-28 22:30 ` Jeremy
2021-07-30 18:42 ` Billy Tetrud
2021-11-01 1:19 ` Billy Tetrud
2021-07-31 20:01 ` [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood
2021-08-02 4:40 ` Billy Tetrud
2021-08-10 2:17 ` ZmnSCPxj
2021-08-13 11:02 ` Zac Greenwood
2021-08-14 1:50 ` ZmnSCPxj
2021-08-16 11:17 ` Zac Greenwood
2021-08-16 11:48 ` ZmnSCPxj
2021-08-30 14:43 ` Zac Greenwood
2021-08-31 9:00 ` ZmnSCPxj
2021-08-31 14:09 ` Zac Greenwood
2021-08-31 14:22 ` ZmnSCPxj
2021-09-01 15:15 ` Zac Greenwood
2021-08-01 8:09 Zac Greenwood
2021-08-02 9:32 ` Zac Greenwood
2021-08-03 18:12 ` Billy Tetrud
2021-08-04 10:48 ` Zac Greenwood
2021-08-05 6:39 ` Billy Tetrud
2021-08-05 14:22 ` Zac Greenwood
2021-08-10 0:41 ` Billy Tetrud
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox