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

[Billy Tetrud <billy.tetrud@gmail.com>]

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