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 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
> '.
> 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
> 
> .
>
> 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 <
> [email protected]> 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
>> [email protected]
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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 potential DOS
vector. I wrote about this in the section '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

.

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 <
[email protected]> 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
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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 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
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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 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  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 express

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
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  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 lim

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 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  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 <
> [email protected]> 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
>> 
>>  and
>> most overlap with the use

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 (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 <
[email protected]> 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
> 
>  and
> most overlap with the use cases of op_ctv  (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
> 
> that uses OP_CD or even my full vision
>  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  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
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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 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

and
most overlap with the use cases of op_ctv  (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

that uses OP_CD or even my full vision
 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  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
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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.
>
> 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
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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 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  wrote:

> Agree.
>
>
> Sent from Yahoo Mail for iPhone
> 
>
> On Sunday, July 25, 2021, 7:07 PM, David A. Harding via bitcoin-dev <
> [email protected]> 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

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 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


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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 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

that
could use this opcode or the larger vision

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 <
[email protected]> 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 *

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 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


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev