Re: [bitcoin-dev] Removing the Dust Limit

2022-03-12 Thread vjudeu via bitcoin-dev 
> We should remove the dust limit from Bitcoin.

Any node operator can do that. Just put "dustrelayfee=0." in your 
bitcoin.conf.

And there is more: you can also conditionally allow free transactions:

mintxfee=0.0001
minrelaytxfee=0.
blockmintxfee=0.

Then, when using getblocktemplate you will get transactions with the highest 
fees first anyway, and you include cheap or free transactions in the end, if 
there will be enough room for them.

So, all of those settings are in the hands of node operators, there is no need 
to change the source code, all you need is to convince nodes to change their 
settings.


On 2021-08-08 20:53:28 user Jeremy via bitcoin-dev 
 wrote:
We should remove the dust limit from Bitcoin. Five reasons:


1) it's not our business what outputs people want to create
2) dust outputs can be used in various authentication/delegation smart contracts
3) dust sized htlcs in lightning 
(https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light)
 force channels to operate in a semi-trusted mode which has implications 
(AFAIU) for the regulatory classification of channels in various jurisdictions; 
agnostic treatment of fund transfers would simplify this (like getting a 0.01 
cent dividend check in the mail)
4) thinly divisible colored coin protocols might make use of sats as value 
markers for transactions.
5) should we ever do confidential transactions we can't prevent it without 
compromising privacy / allowed transfers


The main reasons I'm aware of not allow dust creation is that:


1) dust is spam
2) dust fingerprinting attacks


1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by well 
behaved wallets to not redeem outputs that cost more in fees than they are 
worth.


cheers,


jeremy


___
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Removing the Dust Limit

2021-08-09 Thread Karl via bitcoin-dev 
Why would removing the dust limit impact decentralisation of mining if
miners can reconfigure the dust limit for their mined blocks?
___
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Removing the Dust Limit

2021-08-09 Thread Prayank via bitcoin-dev 
> As feerates have gone up over time, and as we expect them to go up further, 
>we should be considering drastically increasing the 3 sat/vByte basis to 
>something more like 20 sat/vB.

I have no opinion on changing or removing dust limit. However, fee rates are 
not going up. Yes, we expect them to go up and miners revenue from fees as 
well. Although, fees/day (in terms of BTC) has been decreasing in each cycle. 
Fee rates have been ranging between 1 sat/vByte to 200-300 sat/vByte, regularly 
reset to 1-5 sat/vByte and very low since long time now except when hash rate 
went down.

Fees per MB since 2016: https://i.imgur.com/XEkkf99.png 

Highest in this cycle on April 19 2021: 2.5 BTC
Highest in previous cycle on December 18 2017: 10 BTC

It stays low all the time except few days in each cycle.

-- 
Prayank
 
A3B1 E430 2298 178F

___
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Removing the Dust Limit

2021-08-08 Thread Oleg Andreev via bitcoin-dev 
I agree with Jeremy. Dust limit works due to design accident: that outputs are 
not encrypted. But outputs are private business and the real issue is only the 
cost of utxo set storage born by every user. There are two ways to address this:

1) either make ppl pay for renting that storage (which creates a ton of 
problems of its own)
2) or make storage extremely cheap so it remains cheap at any scale. This is 
perfectly solved by Utreexo.

But looking at the private data because you can is a hack that creates issues 
of its own.

> On 9 Aug 2021, at 00:16, Matt Corallo via bitcoin-dev 
>  wrote:
> 
> If it weren't for the implications in changing standardness here, I think we 
> should consider increasing the dust limit instead.
> 
> The size of the UTXO set is a fundamental scalability constraint of the 
> system. In fact, with proposals like assume-utxo/background history sync it 
> is arguably *the* fundamental scalability constraint of the system. Today's 
> dust limit is incredibly low - its based on a feerate of only 3 sat/vByte in 
> order for claiming the UTXO to have *any* value, not just having enough value 
> to be worth bothering. As feerates have gone up over time, and as we expect 
> them to go up further, we should be considering drastically increasing the 3 
> sat/vByte basis to something more like 20 sat/vB.
> 
> Matt
> 
>> On 8/8/21 14:52, Jeremy via bitcoin-dev wrote:
>> We should remove the dust limit from Bitcoin. Five reasons:
>> 1) it's not our business what outputs people want to create
> 
> It is precisely our business - the costs are born by us, not the creator. If 
> someone wants to create outputs which don't make sense to spend, they can do 
> so using OP_RETURN, since they won't spend it anyway.
> 
>> 2) dust outputs can be used in various authentication/delegation smart 
>> contracts
> 
> So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-them 
> outputs.
> 
>> 3) dust sized htlcs in lightning 
>> (https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light
>>  
>> )
>>  force channels to operate in a semi-trusted mode which has implications 
>> (AFAIU) for the regulatory classification of channels in various 
>> jurisdictions; agnostic treatment of fund transfers would simplify this 
>> (like getting a 0.01 cent dividend check in the mail)
> 
> This is unrelated to the consensus dust limit. This is related to the 
> practical question about the value of claiming an output. Again, the 
> appropriate way to solve this instead of including spendable dust outputs 
> would be an OP_RETURN output (though I believe this particular problem is 
> actually better solved elsewhere in the lightning protocol).
> 
>> 4) thinly divisible colored coin protocols might make use of sats as value 
>> markers for transactions.
> 
> These schemes can and should use values which make them economical to spend. 
> The whole *point* of the dust limit is to encourage people to use values 
> which make sense economically to "clean up" after they're done with them. If 
> people want to use outputs which they will not spend/"clean up" later, they 
> should be using OP_RETURN.
> 
>> 5) should we ever do confidential transactions we can't prevent it without 
>> compromising privacy / allowed transfers
> 
> This is the reason the dust limit is not a *consensus* limit. If and when CT 
> were to happen we can and would relax the standardness rules around the dust 
> limit to allow for CT.
> 
>> The main reasons I'm aware of not allow dust creation is that:
>> 1) dust is spam
>> 2) dust fingerprinting attacks
> 
> 3) The significant costs to every miner and full node operator.
> ___
> bitcoin-dev mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Removing the Dust Limit

2021-08-08 Thread Matt Corallo via bitcoin-dev 
If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit 
instead.


The size of the UTXO set is a fundamental scalability constraint of the system. In fact, with proposals like 
assume-utxo/background history sync it is arguably *the* fundamental scalability constraint of the system. Today's dust 
limit is incredibly low - its based on a feerate of only 3 sat/vByte in order for claiming the UTXO to have *any* value, 
not just having enough value to be worth bothering. As feerates have gone up over time, and as we expect them to go up 
further, we should be considering drastically increasing the 3 sat/vByte basis to something more like 20 sat/vB.


Matt

On 8/8/21 14:52, Jeremy via bitcoin-dev wrote:

We should remove the dust limit from Bitcoin. Five reasons:

1) it's not our business what outputs people want to create


It is precisely our business - the costs are born by us, not the creator. If someone wants to create outputs which don't 
make sense to spend, they can do so using OP_RETURN, since they won't spend it anyway.



2) dust outputs can be used in various authentication/delegation smart contracts


So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-them 
outputs.

3) dust sized htlcs in lightning 
(https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light 
) 
force channels to operate in a semi-trusted mode which has implications (AFAIU) for the regulatory classification of 
channels in various jurisdictions; agnostic treatment of fund transfers would simplify this (like getting a 0.01 cent 
dividend check in the mail)


This is unrelated to the consensus dust limit. This is related to the practical question about the value of claiming an 
output. Again, the appropriate way to solve this instead of including spendable dust outputs would be an OP_RETURN 
output (though I believe this particular problem is actually better solved elsewhere in the lightning protocol).



4) thinly divisible colored coin protocols might make use of sats as value 
markers for transactions.


These schemes can and should use values which make them economical to spend. The whole *point* of the dust limit is to 
encourage people to use values which make sense economically to "clean up" after they're done with them. If people want 
to use outputs which they will not spend/"clean up" later, they should be using OP_RETURN.



5) should we ever do confidential transactions we can't prevent it without 
compromising privacy / allowed transfers


This is the reason the dust limit is not a *consensus* limit. If and when CT were to happen we can and would relax the 
standardness rules around the dust limit to allow for CT.




The main reasons I'm aware of not allow dust creation is that:

1) dust is spam
2) dust fingerprinting attacks


3) The significant costs to every miner and full node operator.
___
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev