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