[bitcoin-dev] Regarding setting a lower minrelaytxfee

[bitcoin-dev] Regarding setting a lower minrelaytxfee

[Aaradhya Chauhan]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

I know this might be a sort of repetition for a previous question, but I do
want to know from enthusiasts in this group that while Bitcoin was trading
at much lower price in its early days, 1 sat/vB was a good dust protection
measure. But now, I think it's a bit high for merely a dust protection
measure, and should be lowered slightly. Even if not, it should be lowered
to half when prices go double than today and keeps oscillating at that
point. As it's not a consensus rule, I think it can be done easily, just
needing support from full node operators. I support LN but I think
transaction affordability should remain constant in the future. If I'm okay
to wait in a queue, I should have the option for same affordability for
minimum fees in the future as it is today. (Like we still have posts today
while email still exists).

Awaiting your response.

Regards
Aaradhya Chauhan

[-- Attachment #2: Type: text/html, Size: 1010 bytes --]

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[alicexbt]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

Hi Aaradhya,

> As it's not a consensus rule, I think it can be done easily, just needing support from full node operators

A few miners will need to use a lower minrelaytxfee for this to work. I don't think miners would want to lower their profits.

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Tuesday, July 26th, 2022 at 1:56 PM, Aaradhya Chauhan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

I know this might be a sort of repetition for a previous question, but I do want to know from enthusiasts in this group that while Bitcoin was trading at much lower price in its early days, 1 sat/vB was a good dust protection measure. But now, I think it's a bit high for merely a dust protection measure, and should be lowered slightly. Even if not, it should be lowered to half when prices go double than today and keeps oscillating at that point. As it's not a consensus rule, I think it can be done easily, just needing support from full node operators. I support LN but I think transaction affordability should remain constant in the future. If I'm okay to wait in a queue, I should have the option for same affordability for minimum fees in the future as it is today. (Like we still have posts today while email still exists).

Awaiting your response.

Regards
Aaradhya Chauhan

[-- Attachment #2: Type: text/html, Size: 2443 bytes --]

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via bitcoin-dev wrote:
> I know this might be a sort of repetition for a previous question, but I do
> want to know from enthusiasts in this group that while Bitcoin was trading
> at much lower price in its early days, 1 sat/vB was a good dust protection
> measure. But now, I think it's a bit high for merely a dust protection
> measure, and should be lowered slightly. Even if not, it should be lowered
> to half when prices go double than today and keeps oscillating at that
> point. As it's not a consensus rule, I think it can be done easily, just
> needing support from full node operators. I support LN but I think
> transaction affordability should remain constant in the future. If I'm okay
> to wait in a queue, I should have the option for same affordability for
> minimum fees in the future as it is today. (Like we still have posts today
> while email still exists).

If we're expecting fee revenue to be significant in the future - with constant
backlogs of low-fee txs - lowering the dust limit now is a good way to ensure
the entire ecosystem is ready to deal with those conditions. We're fairly close
to blocks being full, so you can't argue that the dust limit provides value by
reducing block usage. All it achieves is artificially lowering mempool usage,
putting the Bitcoin system in a no-backlog state that's quite unlike how we're
expecting Bitcoin to operate in the future. And indeed, the state Bitcoin can
operate in at any moment if there is a demand spike.

So I'd suggest removing the fixed dust limit entirely and relying purely on the
mempool size limit to determine what is or is not dust.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[Peter Todd]

On July 26, 2022 2:19:32 PM GMT+02:00, alicexbt via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>Hi Aaradhya,
>
>> As it's not a consensus rule, I think it can be done easily, just needing support from full node operators
>
>A few miners will need to use a lower minrelaytxfee for this to work. I don't think miners would want to lower their profits.

Whether or not this lowers profits for a particular miner is complex:

https://petertodd.org/2016/block-publication-incentives-for-miners

But to a first approximation, at any fee above zero failing to mine a tx you know about is leaving money on the table.

Anyway even if miners don't actually mine these txs by themselves, with Child-Pays-For-Parent, allowing near-zero txs into your mempool potentially allows you to mine more fees.

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[alicexbt]

Hi Peter,

> But to a first approximation, at any fee above zero failing to mine a tx you know about is leaving money on the table

Let's assume 10000 people go from A to B every day in flight. They buy tickets for different prices and some of them are looking to pay the minimum even if it's a morning flight, not preferred seat etc. If the minimum price for ticket drops, will this increase the revenue for airlines?

Some people who avoided flight earlier might book with new minimum although most of them already figured out other ways to travel or paid the old minimum. Maximum people or weight for a flight would still remain the same.

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, July 26th, 2022 at 7:57 PM, Peter Todd <pete@petertodd.org> wrote:


>
> On July 26, 2022 2:19:32 PM GMT+02:00, alicexbt via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Hi Aaradhya,
> >
> > > As it's not a consensus rule, I think it can be done easily, just needing support from full node operators
> >
> > A few miners will need to use a lower minrelaytxfee for this to work. I don't think miners would want to lower their profits.
>
>
> Whether or not this lowers profits for a particular miner is complex:
>
> https://petertodd.org/2016/block-publication-incentives-for-miners
>
> But to a first approximation, at any fee above zero failing to mine a tx you know about is leaving money on the table.
>
> Anyway even if miners don't actually mine these txs by themselves, with Child-Pays-For-Parent, allowing near-zero txs into your mempool potentially allows you to mine more fees.

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[vjudeu]

> So I'd suggest removing the fixed dust limit entirely and relying purely on the mempool size limit to determine what is or is not dust.

Just use those settings in your node:

minrelaytxfee=0.00000000
blockmintxfee=0.00000000
dustrelayfee=0.00000000

No changes in source code are needed, nodes can change their limits without asking anyone. And if some node is a miner, then it can be enforced. But if not, then still, free transactions are useful for communication (if more of them will be accepted, then we will switch to negative fee transactions with proper sighashes, then it will be very unlikely that miners will voluntarily add coins, so it will remain useful for communication).

On 2022-07-26 14:45:35 user Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via bitcoin-dev wrote:
> I know this might be a sort of repetition for a previous question, but I do
> want to know from enthusiasts in this group that while Bitcoin was trading
> at much lower price in its early days, 1 sat/vB was a good dust protection
> measure. But now, I think it's a bit high for merely a dust protection
> measure, and should be lowered slightly. Even if not, it should be lowered
> to half when prices go double than today and keeps oscillating at that
> point. As it's not a consensus rule, I think it can be done easily, just
> needing support from full node operators. I support LN but I think
> transaction affordability should remain constant in the future. If I'm okay
> to wait in a queue, I should have the option for same affordability for
> minimum fees in the future as it is today. (Like we still have posts today
> while email still exists).

If we're expecting fee revenue to be significant in the future - with constant
backlogs of low-fee txs - lowering the dust limit now is a good way to ensure
the entire ecosystem is ready to deal with those conditions. We're fairly close
to blocks being full, so you can't argue that the dust limit provides value by
reducing block usage. All it achieves is artificially lowering mempool usage,
putting the Bitcoin system in a no-backlog state that's quite unlike how we're
expecting Bitcoin to operate in the future. And indeed, the state Bitcoin can
operate in at any moment if there is a demand spike.

So I'd suggest removing the fixed dust limit entirely and relying purely on the
mempool size limit to determine what is or is not dust.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[Peter Todd]

On July 27, 2022 6:10:00 AM GMT+02:00, vjudeu via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> So I'd suggest removing the fixed dust limit entirely and relying purely on the mempool size limit to determine what is or is not dust.
>
>Just use those settings in your node:
>
>minrelaytxfee=0.00000000
>blockmintxfee=0.00000000
>dustrelayfee=0.00000000
>
>No changes in source code are needed, nodes can change their limits without asking anyone. And if some node is a miner, then it can be enforced. But if not, then still, free transactions are useful for communication (if more of them will be accepted, then we will switch to negative fee transactions with proper sighashes, then it will be very unlikely that miners will voluntarily add coins, so it will remain useful for communication).

It's pointless for individual nodes to make changes like this on their own. Without like-minded peers this achieves nothing. What is relevant is network wide defaults.

The only time those settings are useful is special situations like miners who want to push txs to their own memlools. For the _vast_ majority of users changing defaults achieves absolutely nothing.

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[vjudeu]

> It's pointless for individual nodes to make changes like this on their own.

It's pointless only if you assume that mining is centralized. And it's pointless if you also assume that there is no batching. By using different sighashes, batching is definitely possible. In case of one-input-one-output transactions, they should use SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, then it is possible to grab a lot of such transactions, and combine them all into a single transaction, saving some bytes, so fees for each user can be lower than one satoshi per virtual byte, when it is counted in non-batched version. In general, it should be possible to use SIGHASH_ANYONECANPAY by default, and use SIGHASH_PREVOUT_SOMETHING to make signatures from next transactions resistant to changes like adding more inputs and outputs.

> The only time those settings are useful is special situations like miners who want to push txs to their own memlools.

So they could be more useful, if it would be possible to mine a block with lower than required difficulty (a share), and be rewarded for that in P2P way. So, if some miner collected 7 BTC as a reward (6.25 BTC plus 0.75 BTC in fees), then if that miner created 100 times easier block than needed, it should be rewarded with 0.07 BTC in a P2P way. And if block rewards are based on fees, then it makes perfect sense to collect for example 0.07 BTC in transaction fees, and mine it, leaving the rest for other miners, then they will have an incentive to build on top of that.


On 2022-07-27 14:18:21 user Peter Todd <pete@petertodd.org> wrote:
> 

On July 27, 2022 6:10:00 AM GMT+02:00, vjudeu via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> So I'd suggest removing the fixed dust limit entirely and relying purely on the mempool size limit to determine what is or is not dust.
>
>Just use those settings in your node:
>
>minrelaytxfee=0.00000000
>blockmintxfee=0.00000000
>dustrelayfee=0.00000000
>
>No changes in source code are needed, nodes can change their limits without asking anyone. And if some node is a miner, then it can be enforced. But if not, then still, free transactions are useful for communication (if more of them will be accepted, then we will switch to negative fee transactions with proper sighashes, then it will be very unlikely that miners will voluntarily add coins, so it will remain useful for communication).

It's pointless for individual nodes to make changes like this on their own. Without like-minded peers this achieves nothing. What is relevant is network wide defaults.

The only time those settings are useful is special situations like miners who want to push txs to their own memlools. For the _vast_ majority of users changing defaults achieves absolutely nothing.

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[David A. Harding]

On 2022-07-26 02:45, Peter Todd via bitcoin-dev wrote:
> On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via 
> bitcoin-dev wrote:
>> [...] in its early days, 1 sat/vB was a good dust protection
>> measure. But now, I think it's a bit high [...] I think it can be done 
>> easily [...]
> 
> [...] lowering the dust limit now is a good way to ensure
> the entire ecosystem is ready to deal with those conditions.

I don't have anything new to add to the conversation at this time, but I 
did want to suggest a clarification and summarize some previous 
discussion that might be useful.

I think the phrasing by Aaradhya Chauhan and Peter Todd above are 
conflating the minimum output amount policy ("dust limit") with the 
minimum transaction relay feerate policy ("min tx relay fee").  Any 
transaction with an output amount below a node's configured dust limit 
(a few hundred sat by default) will not be relayed by that node no 
matter how high of a feerate it pays.  Any transaction with feerate 
below a nodes's minimum relay feerate (1 sat/vbyte by default) will not 
be relayed by that node even if the node has unused space in its mempool 
and peers that use BIP133 feefilters to advertise that they would accept 
low feerates.

Removing the dust limit was discussed extensively a year ago[1] with 
additional follow-up discussion about eight months ago.[2]

Lowering the minimum relay feerate was seriously proposed in a patch to 
Bitcoin Core four years ago[3] with additional related PRs being opened 
to ease the change.  Not all of the related PRs have been merged yet, 
and the original PR was closed.  I can't easily find some of the 
discussions I remember related to that change, but IIRC part of the 
challenge was that lower minimum relay fees reduce the cost of a variety 
of DoS attacks which could impact BIP152 compact blocks and erlay 
efficiency, could worsen transaction pinning, may increase IBD time due 
to more block chain data, and have other adverse effects.  Additionally, 
we've found in the past that some people who build systems that take 
advantage of low feerates become upset when feerates rise, sometimes 
creating problems even for people who prepared for eventual feerate 
rises.

Compared to the complexity of lowering the minimum feerate, the 
challenges of preventing denial/degregation-of-service attacks, and 
dealing with a fragmented userbase, the economic benefit of reducing the 
feerates for the bottom of the mempool seems small---if we lower min 
feerates to 1/10th their current values and that results in the 
equivalent of an extra 10 blocks of transactions getting mined a day, 
then users save a total of 0.09 BTC (~$1,800 USD) per day and miners 
earn an extra 0.01 BTC ($200 USD) per day (assuming all other things 
remain equal).[4]

-Dave

[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019635.html
[3] https://github.com/bitcoin/bitcoin/pull/13922
[4] The current min relay fee is 1 sat/vbyte.  There are ~1 million 
vbytes in a block that can be allocated to regular transactions.  Ten 
blocks at the current min relay fee would pay (10 * 1e6 / 1e8 = 0.1 BTC) 
in fees.  Ten blocks at 1/10 sat/vbyte would thus pay 0.01 BTC in fees, 
which is $200 USD @ $20k/BTC.  Thus users would save (0.1 - 0.01 = 0.09 
BTC = $1,800 USD @ $20k/BTC).

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[Aaradhya Chauhan]

[-- Attachment #1: Type: text/plain, Size: 4294 bytes --]

I think you misunderstood what I said. I did not say that it should be done
now, for the obvious reasons that the miners won't be doing any good by
such measures. But I am talking about when the price of BTC escalates to a
point when 1sat/vB becomes expensive as a dust limit. If the price
oscillates at that point and above, it would actually create the same
incentives as it is today. All I imply is to maintain the affordability of
the minimum possible fee if one is ready to wait.

On Fri, 29 Jul 2022 at 9:08 AM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2022-07-26 02:45, Peter Todd via bitcoin-dev wrote:
> > On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via
> > bitcoin-dev wrote:
> >> [...] in its early days, 1 sat/vB was a good dust protection
> >> measure. But now, I think it's a bit high [...] I think it can be done
> >> easily [...]
> >
> > [...] lowering the dust limit now is a good way to ensure
> > the entire ecosystem is ready to deal with those conditions.
>
> I don't have anything new to add to the conversation at this time, but I
> did want to suggest a clarification and summarize some previous
> discussion that might be useful.
>
> I think the phrasing by Aaradhya Chauhan and Peter Todd above are
> conflating the minimum output amount policy ("dust limit") with the
> minimum transaction relay feerate policy ("min tx relay fee").  Any
> transaction with an output amount below a node's configured dust limit
> (a few hundred sat by default) will not be relayed by that node no
> matter how high of a feerate it pays.  Any transaction with feerate
> below a nodes's minimum relay feerate (1 sat/vbyte by default) will not
> be relayed by that node even if the node has unused space in its mempool
> and peers that use BIP133 feefilters to advertise that they would accept
> low feerates.
>
> Removing the dust limit was discussed extensively a year ago[1] with
> additional follow-up discussion about eight months ago.[2]
>
> Lowering the minimum relay feerate was seriously proposed in a patch to
> Bitcoin Core four years ago[3] with additional related PRs being opened
> to ease the change.  Not all of the related PRs have been merged yet,
> and the original PR was closed.  I can't easily find some of the
> discussions I remember related to that change, but IIRC part of the
> challenge was that lower minimum relay fees reduce the cost of a variety
> of DoS attacks which could impact BIP152 compact blocks and erlay
> efficiency, could worsen transaction pinning, may increase IBD time due
> to more block chain data, and have other adverse effects.  Additionally,
> we've found in the past that some people who build systems that take
> advantage of low feerates become upset when feerates rise, sometimes
> creating problems even for people who prepared for eventual feerate
> rises.
>
> Compared to the complexity of lowering the minimum feerate, the
> challenges of preventing denial/degregation-of-service attacks, and
> dealing with a fragmented userbase, the economic benefit of reducing the
> feerates for the bottom of the mempool seems small---if we lower min
> feerates to 1/10th their current values and that results in the
> equivalent of an extra 10 blocks of transactions getting mined a day,
> then users save a total of 0.09 BTC (~$1,800 USD) per day and miners
> earn an extra 0.01 BTC ($200 USD) per day (assuming all other things
> remain equal).[4]
>
> -Dave
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
> [2]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019635.html
> [3] https://github.com/bitcoin/bitcoin/pull/13922
> [4] The current min relay fee is 1 sat/vbyte.  There are ~1 million
> vbytes in a block that can be allocated to regular transactions.  Ten
> blocks at the current min relay fee would pay (10 * 1e6 / 1e8 = 0.1 BTC)
> in fees.  Ten blocks at 1/10 sat/vbyte would thus pay 0.01 BTC in fees,
> which is $200 USD @ $20k/BTC.  Thus users would save (0.1 - 0.01 = 0.09
> BTC = $1,800 USD @ $20k/BTC).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5705 bytes --]

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[Aaradhya Chauhan]

[-- Attachment #1: Type: text/plain, Size: 4410 bytes --]

I'm not suggesting to initiate it anytime soon. But suppose, let's take a
situation where Bitcoin reaches and oscillates above 200k to 500k USD, then
1 sat/vB could be equivalent to 10 sat/vB of today, hampering the "dust
requirement" (ignoring inflation). I discussed this on the Bitcoin
subreddit and some suggested that the developers, in the future, have to
just change the "default minimum relay tx fee" from 1000 today to 500 at
that time. Obviously it's gonna be a little above 500, if we count
inflation. That would simply equate to the current situation. Do you think
that would be a problem?

On Fri, 29 Jul 2022 at 09:08, David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2022-07-26 02:45, Peter Todd via bitcoin-dev wrote:
> > On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via
> > bitcoin-dev wrote:
> >> [...] in its early days, 1 sat/vB was a good dust protection
> >> measure. But now, I think it's a bit high [...] I think it can be done
> >> easily [...]
> >
> > [...] lowering the dust limit now is a good way to ensure
> > the entire ecosystem is ready to deal with those conditions.
>
> I don't have anything new to add to the conversation at this time, but I
> did want to suggest a clarification and summarize some previous
> discussion that might be useful.
>
> I think the phrasing by Aaradhya Chauhan and Peter Todd above are
> conflating the minimum output amount policy ("dust limit") with the
> minimum transaction relay feerate policy ("min tx relay fee").  Any
> transaction with an output amount below a node's configured dust limit
> (a few hundred sat by default) will not be relayed by that node no
> matter how high of a feerate it pays.  Any transaction with feerate
> below a nodes's minimum relay feerate (1 sat/vbyte by default) will not
> be relayed by that node even if the node has unused space in its mempool
> and peers that use BIP133 feefilters to advertise that they would accept
> low feerates.
>
> Removing the dust limit was discussed extensively a year ago[1] with
> additional follow-up discussion about eight months ago.[2]
>
> Lowering the minimum relay feerate was seriously proposed in a patch to
> Bitcoin Core four years ago[3] with additional related PRs being opened
> to ease the change.  Not all of the related PRs have been merged yet,
> and the original PR was closed.  I can't easily find some of the
> discussions I remember related to that change, but IIRC part of the
> challenge was that lower minimum relay fees reduce the cost of a variety
> of DoS attacks which could impact BIP152 compact blocks and erlay
> efficiency, could worsen transaction pinning, may increase IBD time due
> to more block chain data, and have other adverse effects.  Additionally,
> we've found in the past that some people who build systems that take
> advantage of low feerates become upset when feerates rise, sometimes
> creating problems even for people who prepared for eventual feerate
> rises.
>
> Compared to the complexity of lowering the minimum feerate, the
> challenges of preventing denial/degregation-of-service attacks, and
> dealing with a fragmented userbase, the economic benefit of reducing the
> feerates for the bottom of the mempool seems small---if we lower min
> feerates to 1/10th their current values and that results in the
> equivalent of an extra 10 blocks of transactions getting mined a day,
> then users save a total of 0.09 BTC (~$1,800 USD) per day and miners
> earn an extra 0.01 BTC ($200 USD) per day (assuming all other things
> remain equal).[4]
>
> -Dave
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
> [2]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019635.html
> [3] https://github.com/bitcoin/bitcoin/pull/13922
> [4] The current min relay fee is 1 sat/vbyte.  There are ~1 million
> vbytes in a block that can be allocated to regular transactions.  Ten
> blocks at the current min relay fee would pay (10 * 1e6 / 1e8 = 0.1 BTC)
> in fees.  Ten blocks at 1/10 sat/vbyte would thus pay 0.01 BTC in fees,
> which is $200 USD @ $20k/BTC.  Thus users would save (0.1 - 0.01 = 0.09
> BTC = $1,800 USD @ $20k/BTC).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5655 bytes --]

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

On Thu, Jul 28, 2022 at 05:38:19PM -1000, David A. Harding wrote:
> I think the phrasing by Aaradhya Chauhan and Peter Todd above are conflating
> the minimum output amount policy ("dust limit") with the minimum transaction
> relay feerate policy ("min tx relay fee").  Any transaction with an output

Thanks for the correction! Brainfart on my part there.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[alicexbt]

[-- Attachment #1: Type: text/plain, Size: 5644 bytes --]

Hi Aaradhya,

> I discussed this on the Bitcoin subreddit and some suggested that the developers, in the future, have to just change the "default minimum relay tx fee" from 1000 today to 500 at that time.

>

There are several issues and pull requests (open and closed) in which developers tried to decrease the default minimum relay tx fee rate. Even I had opened an issue after reading this thread:

https://github.com/bitcoin/bitcoin/issues/25716

However, I think developers should not make any changes in the default minimum fee rate required for relay. If there are incentives for users and miners to change it, they should use non-default value. In case, miners want to experiment with lower fee rate and see if this increases revenue they could try using it on odd dates (even dates remain default) for a month. We all could analyze how this worked for different mining pools and non-default value (lower or higher) could become normal in the future.

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Saturday, July 30th, 2022 at 1:25 PM, Aaradhya Chauhan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> I'm not suggesting to initiate it anytime soon. But suppose, let's take a situation where Bitcoin reaches and oscillates above 200k to 500k USD, then 1 sat/vB could be equivalent to 10 sat/vB of today, hampering the "dust requirement" (ignoring inflation). I discussed this on the Bitcoin subreddit and some suggested that the developers, in the future, have to just change the "default minimum relay tx fee" from 1000 today to 500 at that time. Obviously it's gonna be a little above 500, if we count inflation. That would simply equate to the current situation. Do you think that would be a problem?
>
> On Fri, 29 Jul 2022 at 09:08, David A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 2022-07-26 02:45, Peter Todd via bitcoin-dev wrote:
>>> On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via
>>> bitcoin-dev wrote:
>>>> [...] in its early days, 1 sat/vB was a good dust protection
>>>> measure. But now, I think it's a bit high [...] I think it can be done
>>>> easily [...]
>>>
>>> [...] lowering the dust limit now is a good way to ensure
>>> the entire ecosystem is ready to deal with those conditions.
>>
>> I don't have anything new to add to the conversation at this time, but I
>> did want to suggest a clarification and summarize some previous
>> discussion that might be useful.
>>
>> I think the phrasing by Aaradhya Chauhan and Peter Todd above are
>> conflating the minimum output amount policy ("dust limit") with the
>> minimum transaction relay feerate policy ("min tx relay fee"). Any
>> transaction with an output amount below a node's configured dust limit
>> (a few hundred sat by default) will not be relayed by that node no
>> matter how high of a feerate it pays. Any transaction with feerate
>> below a nodes's minimum relay feerate (1 sat/vbyte by default) will not
>> be relayed by that node even if the node has unused space in its mempool
>> and peers that use BIP133 feefilters to advertise that they would accept
>> low feerates.
>>
>> Removing the dust limit was discussed extensively a year ago[1] with
>> additional follow-up discussion about eight months ago.[2]
>>
>> Lowering the minimum relay feerate was seriously proposed in a patch to
>> Bitcoin Core four years ago[3] with additional related PRs being opened
>> to ease the change. Not all of the related PRs have been merged yet,
>> and the original PR was closed. I can't easily find some of the
>> discussions I remember related to that change, but IIRC part of the
>> challenge was that lower minimum relay fees reduce the cost of a variety
>> of DoS attacks which could impact BIP152 compact blocks and erlay
>> efficiency, could worsen transaction pinning, may increase IBD time due
>> to more block chain data, and have other adverse effects. Additionally,
>> we've found in the past that some people who build systems that take
>> advantage of low feerates become upset when feerates rise, sometimes
>> creating problems even for people who prepared for eventual feerate
>> rises.
>>
>> Compared to the complexity of lowering the minimum feerate, the
>> challenges of preventing denial/degregation-of-service attacks, and
>> dealing with a fragmented userbase, the economic benefit of reducing the
>> feerates for the bottom of the mempool seems small---if we lower min
>> feerates to 1/10th their current values and that results in the
>> equivalent of an extra 10 blocks of transactions getting mined a day,
>> then users save a total of 0.09 BTC (~$1,800 USD) per day and miners
>> earn an extra 0.01 BTC ($200 USD) per day (assuming all other things
>> remain equal).[4]
>>
>> -Dave
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019635.html
>> [3] https://github.com/bitcoin/bitcoin/pull/13922
>> [4] The current min relay fee is 1 sat/vbyte. There are ~1 million
>> vbytes in a block that can be allocated to regular transactions. Ten
>> blocks at the current min relay fee would pay (10 * 1e6 / 1e8 = 0.1 BTC)
>> in fees. Ten blocks at 1/10 sat/vbyte would thus pay 0.01 BTC in fees,
>> which is $200 USD @ $20k/BTC. Thus users would save (0.1 - 0.01 = 0.09
>> BTC = $1,800 USD @ $20k/BTC).
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 8740 bytes --]

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrote:
> However, I think developers should not make any changes in the default minimum fee rate required for relay. If there are incentives for users and miners to change it, they should use non-default value. In case, miners want to experiment with lower fee rate and see if this increases revenue they could try using it on odd dates (even dates remain default) for a month. We all could analyze how this worked for different mining pools and non-default value (lower or higher) could become normal in the future.

Without a way for lower-fee-rate transactions to get to those miners,
experiments like that are pointless.

If you want to propose things like this, propose a way to get non-standard txs
to miners, like a hashcash-based alternative broadcast scheme.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[aliashraf.btc At protonmail]

> On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrote:
> like a hashcash-based alternative broadcast scheme.
Hi Peter,
I've been mulling the idea of attaching work to low fee txns, both as a compensation (e.g., in a sidechain, or an alt), and/or as a spam proof. Unfortunately, both suffer from ASICs:
For spam proof case, the adversary can easily buy a used/obsolete device to produce lots of spam txns very cheaply, unless you put the bar very high, making it almost impossible for average users to even try.
The compensation scenario is pretty off-topic, still, interesting enough for 1 min read:
Wallets commit to the latest blockchain state in the transaction AND attach work.
It is considered contribution to the security (illegitimate chains can't include the txn), hence isrewarded by fee discount/exemption depending on the offset of the state they've committed to (the closer, the better) and the amount of work attached.
For this to work, block difficulty is calculated inclusive with the work embedded in the txns, it contains. Sophisticated and consequential, yet not infeasible per se.

Unfortunately, this scheme is hard to balance with ASICs in the scene too, for instance, you can't subsidize wallets for their work like with a leverge, because miners can easily do it locally, seizing the subsidies for themselves, long story, not relevant just ignore it.

Cheers, Ali

------- Original Message -------
On Monday, August 1st, 2022 at 3:00 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrote:
>
> > However, I think developers should not make any changes in the default minimum fee rate required for relay. If there are incentives for users and miners to change it, they should use non-default value. In case, miners want to experiment with lower fee rate and see if this increases revenue they could try using it on odd dates (even dates remain default) for a month. We all could analyze how this worked for different mining pools and non-default value (lower or higher) could become normal in the future.
>
>
> Without a way for lower-fee-rate transactions to get to those miners,
> experiments like that are pointless.
>
> If you want to propose things like this, propose a way to get non-standard txs
> to miners, like a hashcash-based alternative broadcast scheme.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail wrote:
> > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrote:
> > like a hashcash-based alternative broadcast scheme.
> Hi Peter,
> I've been mulling the idea of attaching work to low fee txns, both as a compensation (e.g., in a sidechain, or an alt), and/or as a spam proof. Unfortunately, both suffer from ASICs:
> For spam proof case, the adversary can easily buy a used/obsolete device to produce lots of spam txns very cheaply, unless you put the bar very high, making it almost impossible for average users to even try.
> The compensation scenario is pretty off-topic, still, interesting enough for 1 min read:
> Wallets commit to the latest blockchain state in the transaction AND attach work.
> It is considered contribution to the security (illegitimate chains can't include the txn), hence isrewarded by fee discount/exemption depending on the offset of the state they've committed to (the closer, the better) and the amount of work attached.
> For this to work, block difficulty is calculated inclusive with the work embedded in the txns, it contains. Sophisticated and consequential, yet not infeasible per se.
> 
> Unfortunately, this scheme is hard to balance with ASICs in the scene too, for instance, you can't subsidize wallets for their work like with a leverge, because miners can easily do it locally, seizing the subsidies for themselves, long story, not relevant just ignore it.

We're not talking about a consensus system here. Just a way to rate-limit
access to a broadcast network used by a small minority of nodes. It's
completely ok to simply change the PoW algorithm in the _highly_ unlikely event
someone bothers to build an ASIC for it. Since this isn't a consensu system,
it's totally ok if multiple versions of the scheme run in parallel.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[Aaradhya Chauhan]

[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]

So, can we conclude by something, whether or not it would be possible and
feasible in the future?

On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail
> wrote:
> > > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev
> wrote:
> > > like a hashcash-based alternative broadcast scheme.
> > Hi Peter,
> > I've been mulling the idea of attaching work to low fee txns, both as a
> compensation (e.g., in a sidechain, or an alt), and/or as a spam proof.
> Unfortunately, both suffer from ASICs:
> > For spam proof case, the adversary can easily buy a used/obsolete device
> to produce lots of spam txns very cheaply, unless you put the bar very
> high, making it almost impossible for average users to even try.
> > The compensation scenario is pretty off-topic, still, interesting enough
> for 1 min read:
> > Wallets commit to the latest blockchain state in the transaction AND
> attach work.
> > It is considered contribution to the security (illegitimate chains can't
> include the txn), hence isrewarded by fee discount/exemption depending on
> the offset of the state they've committed to (the closer, the better) and
> the amount of work attached.
> > For this to work, block difficulty is calculated inclusive with the work
> embedded in the txns, it contains. Sophisticated and consequential, yet not
> infeasible per se.
> >
> > Unfortunately, this scheme is hard to balance with ASICs in the scene
> too, for instance, you can't subsidize wallets for their work like with a
> leverge, because miners can easily do it locally, seizing the subsidies for
> themselves, long story, not relevant just ignore it.
>
> We're not talking about a consensus system here. Just a way to rate-limit
> access to a broadcast network used by a small minority of nodes. It's
> completely ok to simply change the PoW algorithm in the _highly_ unlikely
> event
> someone bothers to build an ASIC for it. Since this isn't a consensu
> system,
> it's totally ok if multiple versions of the scheme run in parallel.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3160 bytes --]

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[vjudeu]

It is possible, because you can find nodes that accept low-fee transactions. And on some statistics, for example https://jochen-hoenicke.de/queue/#BTC,24h,weight,0 you can see that zero to one satoshi per virtual byte transactions could take more space than other transactions. You can be convinced that those charts are not fake by running a full node and reaching some nodes with different fee settings. If miners don't want to accept them, well, it is their choice to leave that money on the table. As long as the basic block reward is sufficient, they don't have to accept such low fee transactions, because they can wait instead, to receive them in some batched form.

Also, some miners could accept only 10 sats/vB or higher, because why not. As long as your transaction will reach enough nodes to be confirmed, you can safely pick lower fees. For now, de-facto standard is one satoshi per virtual byte, but:

1) it is only declared, so you can rely only on declarations, not on hard consensus rules
2) there is no way to make sure if some transaction was truly rejected by some miner, or maybe it was saved somewhere
3) you can never be sure if some node is a miner and can enforce those different fee rules or not

So, you can really judge only by how nodes behave, you cannot make sure in any way if anyone is running some additional rules. And fees are not a part of the consensus, so they can be freely adjusted by each node, and there is no way to make sure, what rules are really executed, you can only assume that, based on what transactions are included in blocks.



On 2022-08-03 18:19:12 user Aaradhya Chauhan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
So, can we conclude by something, whether or not it would be possible and feasible in the future?


On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail wrote:
> > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrote:
> > like a hashcash-based alternative broadcast scheme.
> Hi Peter,
> I've been mulling the idea of attaching work to low fee txns, both as a compensation (e.g., in a sidechain, or an alt), and/or as a spam proof. Unfortunately, both suffer from ASICs:
> For spam proof case, the adversary can easily buy a used/obsolete device to produce lots of spam txns very cheaply, unless you put the bar very high, making it almost impossible for average users to even try.
> The compensation scenario is pretty off-topic, still, interesting enough for 1 min read:
> Wallets commit to the latest blockchain state in the transaction AND attach work.
> It is considered contribution to the security (illegitimate chains can't include the txn), hence isrewarded by fee discount/exemption depending on the offset of the state they've committed to (the closer, the better) and the amount of work attached.
> For this to work, block difficulty is calculated inclusive with the work embedded in the txns, it contains. Sophisticated and consequential, yet not infeasible per se.
>
> Unfortunately, this scheme is hard to balance with ASICs in the scene too, for instance, you can't subsidize wallets for their work like with a leverge, because miners can easily do it locally, seizing the subsidies for themselves, long story, not relevant just ignore it.

We're not talking about a consensus system here. Just a way to rate-limit
access to a broadcast network used by a small minority of nodes. It's
completely ok to simply change the PoW algorithm in the _highly_ unlikely event
someone bothers to build an ASIC for it. Since this isn't a consensu system,
it's totally ok if multiple versions of the scheme run in parallel.

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[Aaradhya Chauhan]

[-- Attachment #1: Type: text/plain, Size: 4340 bytes --]

Thank you for answering. I'll check out the link you provided, while also
playing around with the fee settings for my own full node, at my home
server.

On Wed, 3 Aug 2022 at 23:02, vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It is possible, because you can find nodes that accept low-fee
> transactions. And on some statistics, for example
> https://jochen-hoenicke.de/queue/#BTC,24h,weight,0 you can see that zero
> to one satoshi per virtual byte transactions could take more space than
> other transactions. You can be convinced that those charts are not fake by
> running a full node and reaching some nodes with different fee settings. If
> miners don't want to accept them, well, it is their choice to leave that
> money on the table. As long as the basic block reward is sufficient, they
> don't have to accept such low fee transactions, because they can wait
> instead, to receive them in some batched form.
>
> Also, some miners could accept only 10 sats/vB or higher, because why not.
> As long as your transaction will reach enough nodes to be confirmed, you
> can safely pick lower fees. For now, de-facto standard is one satoshi per
> virtual byte, but:
>
> 1) it is only declared, so you can rely only on declarations, not on hard
> consensus rules
> 2) there is no way to make sure if some transaction was truly rejected by
> some miner, or maybe it was saved somewhere
> 3) you can never be sure if some node is a miner and can enforce those
> different fee rules or not
>
> So, you can really judge only by how nodes behave, you cannot make sure in
> any way if anyone is running some additional rules. And fees are not a part
> of the consensus, so they can be freely adjusted by each node, and there is
> no way to make sure, what rules are really executed, you can only assume
> that, based on what transactions are included in blocks.
>
>
>
> On 2022-08-03 18:19:12 user Aaradhya Chauhan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> So, can we conclude by something, whether or not it would be possible and
> feasible in the future?
>
>
> On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail
> wrote:
> > > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev
> wrote:
> > > like a hashcash-based alternative broadcast scheme.
> > Hi Peter,
> > I've been mulling the idea of attaching work to low fee txns, both as a
> compensation (e.g., in a sidechain, or an alt), and/or as a spam proof.
> Unfortunately, both suffer from ASICs:
> > For spam proof case, the adversary can easily buy a used/obsolete device
> to produce lots of spam txns very cheaply, unless you put the bar very
> high, making it almost impossible for average users to even try.
> > The compensation scenario is pretty off-topic, still, interesting enough
> for 1 min read:
> > Wallets commit to the latest blockchain state in the transaction AND
> attach work.
> > It is considered contribution to the security (illegitimate chains can't
> include the txn), hence isrewarded by fee discount/exemption depending on
> the offset of the state they've committed to (the closer, the better) and
> the amount of work attached.
> > For this to work, block difficulty is calculated inclusive with the work
> embedded in the txns, it contains. Sophisticated and consequential, yet not
> infeasible per se.
> >
> > Unfortunately, this scheme is hard to balance with ASICs in the scene
> too, for instance, you can't subsidize wallets for their work like with a
> leverge, because miners can easily do it locally, seizing the subsidies for
> themselves, long story, not relevant just ignore it.
>
> We're not talking about a consensus system here. Just a way to rate-limit
> access to a broadcast network used by a small minority of nodes. It's
> completely ok to simply change the PoW algorithm in the _highly_ unlikely
> event
> someone bothers to build an ASIC for it. Since this isn't a consensu
> system,
> it's totally ok if multiple versions of the scheme run in parallel.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5254 bytes --]

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 5573 bytes --]

I agree with Peter, it seems like we don't need a dust limit with full
blocks. And we should expect blocks to remain full indefinitely.

However, if we were to still have a dust limit, it shouldn't be a simple
constant. It should be determined by the mempool environment. Eg one could
define the dust limit to be the 5th percentile lowest fee in the last 100
blocks. Or the 1st percentile. Etc. This way, as the value of bitcoin
fluctuates (inevitably affecting the fees people are willing to pay), the
dust limit would automatically adjust to compensate. One might worry that
in high fee environments, the dust limit calculated this way might make for
too-high dust limits. But I don't think you could really say it would be
"too high" because it would match the actual mempool. We could have a
maximum dust limit set if that's a worry tho.

On Wed, Aug 3, 2022 at 5:35 PM Aaradhya Chauhan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thank you for answering. I'll check out the link you provided, while also
> playing around with the fee settings for my own full node, at my home
> server.
>
> On Wed, 3 Aug 2022 at 23:02, vjudeu via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> It is possible, because you can find nodes that accept low-fee
>> transactions. And on some statistics, for example
>> https://jochen-hoenicke.de/queue/#BTC,24h,weight,0 you can see that zero
>> to one satoshi per virtual byte transactions could take more space than
>> other transactions. You can be convinced that those charts are not fake by
>> running a full node and reaching some nodes with different fee settings. If
>> miners don't want to accept them, well, it is their choice to leave that
>> money on the table. As long as the basic block reward is sufficient, they
>> don't have to accept such low fee transactions, because they can wait
>> instead, to receive them in some batched form.
>>
>> Also, some miners could accept only 10 sats/vB or higher, because why
>> not. As long as your transaction will reach enough nodes to be confirmed,
>> you can safely pick lower fees. For now, de-facto standard is one satoshi
>> per virtual byte, but:
>>
>> 1) it is only declared, so you can rely only on declarations, not on hard
>> consensus rules
>> 2) there is no way to make sure if some transaction was truly rejected by
>> some miner, or maybe it was saved somewhere
>> 3) you can never be sure if some node is a miner and can enforce those
>> different fee rules or not
>>
>> So, you can really judge only by how nodes behave, you cannot make sure
>> in any way if anyone is running some additional rules. And fees are not a
>> part of the consensus, so they can be freely adjusted by each node, and
>> there is no way to make sure, what rules are really executed, you can only
>> assume that, based on what transactions are included in blocks.
>>
>>
>>
>> On 2022-08-03 18:19:12 user Aaradhya Chauhan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> So, can we conclude by something, whether or not it would be possible and
>> feasible in the future?
>>
>>
>> On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail
>> wrote:
>> > > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev
>> wrote:
>> > > like a hashcash-based alternative broadcast scheme.
>> > Hi Peter,
>> > I've been mulling the idea of attaching work to low fee txns, both as a
>> compensation (e.g., in a sidechain, or an alt), and/or as a spam proof.
>> Unfortunately, both suffer from ASICs:
>> > For spam proof case, the adversary can easily buy a used/obsolete
>> device to produce lots of spam txns very cheaply, unless you put the bar
>> very high, making it almost impossible for average users to even try.
>> > The compensation scenario is pretty off-topic, still, interesting
>> enough for 1 min read:
>> > Wallets commit to the latest blockchain state in the transaction AND
>> attach work.
>> > It is considered contribution to the security (illegitimate chains
>> can't include the txn), hence isrewarded by fee discount/exemption
>> depending on the offset of the state they've committed to (the closer, the
>> better) and the amount of work attached.
>> > For this to work, block difficulty is calculated inclusive with the
>> work embedded in the txns, it contains. Sophisticated and consequential,
>> yet not infeasible per se.
>> >
>> > Unfortunately, this scheme is hard to balance with ASICs in the scene
>> too, for instance, you can't subsidize wallets for their work like with a
>> leverge, because miners can easily do it locally, seizing the subsidies for
>> themselves, long story, not relevant just ignore it.
>>
>> We're not talking about a consensus system here. Just a way to rate-limit
>> access to a broadcast network used by a small minority of nodes. It's
>> completely ok to simply change the PoW algorithm in the _highly_ unlikely
>> event
>> someone bothers to build an ASIC for it. Since this isn't a consensu
>> system,
>> it's totally ok if multiple versions of the scheme run in parallel.
>> _______________________________________________
>> 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: 7134 bytes --]