* [bitcoin-dev] tx max fee
@ 2023-05-07 23:59 Erik Aronesty
2023-05-08 23:57 ` Peter Todd
0 siblings, 1 reply; 9+ messages in thread
From: Erik Aronesty @ 2023-05-07 23:59 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 242 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 396 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] tx max fee
2023-05-07 23:59 [bitcoin-dev] tx max fee Erik Aronesty
@ 2023-05-08 23:57 ` Peter Todd
2023-05-09 0:04 ` Erik Aronesty
0 siblings, 1 reply; 9+ messages in thread
From: Peter Todd @ 2023-05-08 23:57 UTC (permalink / raw)
To: Erik Aronesty, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
On Sun, May 07, 2023 at 07:59:40PM -0400, Erik Aronesty via bitcoin-dev 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
With CPFP it often makes sense for a transaction to have a fee larger than the
output amounts.
This proposal would also screw over applications like my OpenTimestamps
service.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] tx max fee
2023-05-08 23:57 ` Peter Todd
@ 2023-05-09 0:04 ` Erik Aronesty
0 siblings, 0 replies; 9+ messages in thread
From: Erik Aronesty @ 2023-05-09 0:04 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
fair. i suppose you could support cpfp in any dust filtering. im not a
fan, but I think its the only legit way to defend the chain from non money
use cases
On Mon, May 8, 2023, 7:58 PM Peter Todd <pete@petertodd•org> wrote:
> On Sun, May 07, 2023 at 07:59:40PM -0400, Erik Aronesty via bitcoin-dev
> 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
>
> With CPFP it often makes sense for a transaction to have a fee larger than
> the
> output amounts.
>
> This proposal would also screw over applications like my OpenTimestamps
> service.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
[-- Attachment #2: Type: text/html, Size: 1345 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] tx max fee
2023-05-11 11:02 ` vjudeu
2023-05-11 12:32 ` Kalle Rosenbaum
@ 2023-05-12 0:06 ` Tom Harding
1 sibling, 0 replies; 9+ messages in thread
From: Tom Harding @ 2023-05-12 0:06 UTC (permalink / raw)
To: vjudeu; +Cc: bitcoin-dev
On 5/11/23 04:02, vjudeu via bitcoin-dev wrote:
> Every transaction paying "fee > sum" can be replaced by N transactions
> paying "fee <= sum", where the sum of all fees will be the same.
These N transactions will generally have a lower feerate than the
original, and the lowest feerate of the N could be drastically lower
than the original.
As a group, in the current environment (for example), they could take
days or weeks longer to be mined than the original.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] tx max fee
2023-05-11 12:32 ` Kalle Rosenbaum
@ 2023-05-11 15:20 ` Andrew Baine
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Baine @ 2023-05-11 15:20 UTC (permalink / raw)
To: Kalle Rosenbaum, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 8144 bytes --]
Regardless of the submitter's rationale, it is easy to work around any rule
that denies mempool inclusion based on fee proportion: if you have plenty,
add inputs from your own wallet and return to yourself; if not, borrow them
and return to the lender, maybe with interest.
On Thu, May 11, 2023 at 9:27 AM Kalle Rosenbaum via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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 <erik@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 <vjudeu@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
>
[-- Attachment #2: Type: text/html, Size: 9869 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] tx max fee
2023-05-11 11:02 ` vjudeu
@ 2023-05-11 12:32 ` Kalle Rosenbaum
2023-05-11 15:20 ` Andrew Baine
2023-05-12 0:06 ` Tom Harding
1 sibling, 1 reply; 9+ messages in thread
From: Kalle Rosenbaum @ 2023-05-11 12:32 UTC (permalink / raw)
To: vjudeu, Bitcoin Protocol Discussion
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 <erik@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 <vjudeu@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] tx max fee
2023-05-10 17:42 ` Erik Aronesty
@ 2023-05-11 11:02 ` vjudeu
2023-05-11 12:32 ` Kalle Rosenbaum
2023-05-12 0:06 ` Tom Harding
0 siblings, 2 replies; 9+ messages in thread
From: vjudeu @ 2023-05-11 11:02 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
> 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 <erik@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 <vjudeu@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] tx max fee
2023-05-10 16:19 vjudeu
@ 2023-05-10 17:42 ` Erik Aronesty
2023-05-11 11:02 ` vjudeu
0 siblings, 1 reply; 9+ messages in thread
From: Erik Aronesty @ 2023-05-10 17:42 UTC (permalink / raw)
To: vjudeu; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3296 bytes --]
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 <vjudeu@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
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 4037 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] tx max fee
@ 2023-05-10 16:19 vjudeu
2023-05-10 17:42 ` Erik Aronesty
0 siblings, 1 reply; 9+ messages in thread
From: vjudeu @ 2023-05-10 16:19 UTC (permalink / raw)
To: Erik Aronesty, Bitcoin Protocol Discussion, Bitcoin Protocol Discussion
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-05-12 0:06 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-07 23:59 [bitcoin-dev] tx max fee Erik Aronesty
2023-05-08 23:57 ` Peter Todd
2023-05-09 0:04 ` Erik Aronesty
2023-05-10 16:19 vjudeu
2023-05-10 17:42 ` Erik Aronesty
2023-05-11 11:02 ` vjudeu
2023-05-11 12:32 ` Kalle Rosenbaum
2023-05-11 15:20 ` Andrew Baine
2023-05-12 0:06 ` Tom Harding
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox