Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-11-01 Thread Billy Tetrud via bitcoin-dev
FYI I broke out the fee limiting functionality from OP_CD into an opcode called OP_LIMITFEECONTRIBUTION as Jeremy suggested. On Fri, Jul 30, 2021 at 1:42 PM Billy Tetrud wrote: > Thanks for

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-30 Thread Billy Tetrud via bitcoin-dev
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

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-28 Thread Jeremy via bitcoin-dev
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

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-28 Thread Billy Tetrud via bitcoin-dev
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

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-28 Thread Zac Greenwood via bitcoin-dev
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

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-27 Thread Billy Tetrud via bitcoin-dev
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

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-27 Thread Zac Greenwood via bitcoin-dev
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

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-26 Thread Billy Tetrud via bitcoin-dev
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

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-26 Thread James MacWhyte via bitcoin-dev
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. > >

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-26 Thread Billy Tetrud via bitcoin-dev
> 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

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-25 Thread David A. Harding via bitcoin-dev
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

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-25 Thread Billy Tetrud via bitcoin-dev
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

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-24 Thread David A. Harding via bitcoin-dev
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