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

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

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

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

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

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