Another use case for paying more fees than outputs is to incentivize honest mining when Bitcoin is under a state-level censorship attack. If it's really important to me that my transaction goes through, I might be willing to set a fee at 99x the output value. It's the only way bitcoin could work in an adversarial environment.
/Kalle On Thu, 11 May 2023 at 13:55, vjudeu via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > > > confused. the rule was "cannot pay a fee > sum of outputs with > > consideration of cpfp in the mempool" > > your example is of someone paying a fee "< sum" which wouldn't be blocked > > Every transaction paying "fee > sum" can be replaced by N transactions paying > "fee <= sum", where the sum of all fees will be the same. That means, someone > will still do the same thing, but it will be just expanded into N > transactions, so you will reach the same outcome, but splitted into more > transactions. That means, mempool will be even more congested, because for > example instead of 1kB transaction with huge fee, you will see 100 such > transactions with smaller fees, that will add to the same amount, but will > just consume more space. > > > show me how someone could move 1 btc and pay 2 btc as fees... > > In the previous example, I explained how someone could move 1k sats and pay > almost 1 BTC as fees. But again, assuming that you have 3 BTC, and you move 1 > BTC with 2 BTC fee, that will be rejected by your rules if and only if that > will be done in a single transaction. But hey, the same owner can prepare N > transactions upfront, and release them all at the same time, Segwit makes it > possible without worrying about malleability. > > So, instead of: > > 3 BTC -> 1 BTC > > You can see this: > > 3 BTC -> 2 BTC -> 1 BTC > > If that second transaction will not pass CPFP, more outputs could be used: > > +--------------------+--------------------+--------------------+ > | 3.0 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BTC | > | 0.5 BTC | 0.5 BTC 0.5 BTC | 0.5 BTC | > | 0.5 BTC | 0.5 BTC +--------------------+ > | +--------------------+ > | 0.5 BTC | 0.5 BTC -> 0.5 BTC | > | 0.5 BTC | 0.5 BTC | > +--------------------+--------------------+ > > As you can see, there are four transactions, each paying 0.5 BTC fee, so the > total fee is 2 BTC. However, even if you count it as CPFP, you will get 1.5 > BTC in fees for the third transaction in the chain. Note that more outputs > could be used, or they could be wired a bit differently, and then if you will > look at the last transaction, the sum of all fees from 10 or 15 transactions > in that chain, could still pass your limits, but the whole tree will exceed > that. If you have 1.5 BTC limit for that 3 BTC, then you could have 20 > separate chains of transactions, each paying 0.1 BTC in fees, and it will > still sum up to 2 BTC. > > > the only way around it is to maintain balances and use change addresses. > > which would force nft and timestamp users to maintain these balances and > > would be a deterrent > > Not really, because you can prepare all of those transactions upfront, as the > part of your protocol, and release all of them at once. You don't have to > maintain all UTXOs in between, you can create the whole transaction tree > first, sign it, and broadcast everything at once. More than that: if you have > HD wallet, you only need to store a single key, and generate all addresses > in-between on-the-fly, as needed. Or even use some algorithm to > deterministically recreate the whole transaction tree. > > > > On 2023-05-10 19:42:49 user Erik Aronesty <e...@q32.com> wrote: > confused. the rule was "cannot pay a fee > sum of outputs with > consideration of cpfp in the mempool" > > > your example is of someone paying a fee "< sum" which wouldn't be blocked > > > note: again, i'm not a fan of this, i like the discussion of "bitcoin as > money only" and using fee as a lever to do that > > > show me how someone could move 1 btc and pay 2 btc as fees... i think we can > block it at the network or even the consensus layer, and leave anything but > "non-monetary use cases" intact. the only way around it is to maintain > balances and use change addresses. which would force nft and timestamp > users to maintain these balances and would be a deterrent > > > im am much more in favor of doing something like op_ctv which allows many > users to pool fees and essentially "share" a single utxo. > . > > > > On Wed, May 10, 2023 at 12:19 PM <vju...@gazeta.pl> wrote: > > > possible to change tx "max fee" to output amounts? > > Is it possible? Yes. Should we do that? My first thought was "maybe", but > after thinking more about it, I would say "no", here is why: > > Starting point: 1 BTC on some output. > Current situation: A single transaction moving 0.99999000 BTC as fees, and > creating 1000 satoshis as some output (I know, allowed dust values are lower > and depend on address type, but let's say it is 1k sats to make things > simpler). > > And then, there is a room for other solutions, for example your rule, > mentioned in other posts, like this one: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021626.html > > > probably easier just to reject any transaction where the fee is higher than > > the sum of the outputs > > Possible situation after introducing your proposal, step-by-step: > > 1) Someone wants to move 1 BTC, and someone wants to pay 0.99999000 BTC as > fees. Assuming your rules are on consensus level, the first transaction > creates 0.5 BTC output and 0.5 BTC fee. > 2) That person still wants to move 0.5 remaining BTC, and still is willing to > pay 0.49999000 BTC as fees. Guess what will happen: you will see another > transaction, creating 0.25 BTC output, and paying 0.25 BTC fee. > ... > N) Your proposal replaced one transaction, consuming maybe one kilobyte, with > a lot of transactions, doing exactly the same, but where fees are distributed > between many transactions. > > Before thinking about improving that system, consider one simple thing: is it > possible to avoid "max fee rule", no matter in what way it will be defined? > Because as shown above, the answer seems to be "yes", because you can always > replace a single transaction moving 1 BTC as fees with multiple transactions, > each paying one satoshi per virtual byte, and then instead of consuming > around one kilobyte, it would consume around 1 MvB per 0.01 BTC, so 100 MvB > per 1 BTC mentioned in the example above. > > > > On 2023-05-08 13:55:18 user Erik Aronesty via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > possible to change tx "max fee" to output amounts? > > > seems like the only use case that would support such a tx is spam/dos type > stuff that satoshi warned about > > > its not a fix for everything, but it seems could help a bit with certain > attacks > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
