> 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
Good morning Pieter,
> Indeed - UTXO set size is an externality that unfortunately Bitcoin's
> consensus rules fail to account
> for. Having a relay policy that avoids at the very least economically
> irrational behavior makes
> perfect sense to me.
>
> It's also not obvious how consensus rules
misdelivered.
From: LORD HIS EXCELLENCY JAMES HRMH
Sent: Thursday, 7 October 2021 7:34 PM
To: Erik Aronesty ; ZmnSCPxj ; Bitcoin
Protocol Discussion
Cc: lightning-dev
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Good Afternoon,
The underlying c
l Discussion
Cc: lightning-dev
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Good Afternoon,
Returning to this subject, there should be no restriction to the value of
utxo's that keep in one's own wallet as change can be created in any value.
With obvious intent, the w
Good Afternoon,
Returning to this subject, there should be no restriction to the value of
utxo's that keep in one's own wallet as change can be created in any value.
With obvious intent, the wallet should avoid creating utxo's below the current
dust limit at the time the transaction is created
Good morning e,
> mostly thinking out loud
>
> suppose there is a "lightweight" node:
>
> 1. ignores utxo's below the dust limit
> 2. doesn't validate dust tx
> 3. still validates POW, other tx, etc.
>
> these nodes could possibly get forked - accepting a series of valid,
> mined
Jumping in late to this thread.
I very much agree with how David Harding presents things, with a few comments
inline.
‐‐‐ Original Message ‐‐‐
On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev
wrote:
> > 1. it's not our business what outputs people want to
mostly thinking out loud
suppose there is a "lightweight" node:
1. ignores utxo's below the dust limit
2. doesn't validate dust tx
3. still validates POW, other tx, etc.
these nodes could possibly get forked - accepting a series of valid,
mined blocks where there is an invalid but ignored dust
rom: bitcoin-dev on behalf of
shymaa arafat via bitcoin-dev
Sent: Friday, 27 August 2021 7:07 PM
To: Billy Tetrud ; Bitcoin Protocol Discussion
Cc: lightning-dev
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Allow me to ask:
-Untill you find a mitigation that consolid
Allow me to ask:
-Untill you find a mitigation that consolidate all dust UTXOS, why don't
you separate them and all probably Unspendable UTXOS in a different
partition?
-I'm talking at the real UTXO storage level (to be kept in secondary
storage), and at the Merkleization level in any accumulator
One interesting thing I thought of: the cost of maintenance of the dust
creates a (very) small incentive to mine transactions that *use* dust
outputs with a slightly lower fee that contain dust, in order to reduce the
future maintenance cost for themselves. However, the rational discount
would
Good morning Jeremy,
> one interesting point that came up at the bitdevs in austin today that favors
> remove that i believe is new to this discussion (it was new to me):
>
> the argument can be reduced to:
>
> - dust limit is a per-node relay policy.
> - it is rational for miners to mine dust
one interesting point that came up at the bitdevs in austin today that
favors remove that i believe is new to this discussion (it was new to me):
the argument can be reduced to:
- dust limit is a per-node relay policy.
- it is rational for miners to mine dust outputs given their cost of
On Tue, Aug 10, 2021 at 06:37:48PM -0400, Antoine Riard via bitcoin-dev wrote:
> Secondly, the trim-to-dust evaluation doesn't correctly match the lifetime of
> the HTLC.
Right: but that just means it's not something you should determine once
for the HTLC, but something you should determine each
For sure, CT can be done with computational soundness. The advantage of
unhidden amounts (as with current bitcoin) is that you get unconditional
soundness. My understanding is that there is a fundamental tradeoff between
unconditional soundness and unconditional privacy. I believe Monero has
taken
ZmnSCPxj, what you are describing is pretty much what Litecoin is doing
with MWEB. Basically MimbleWimble (which has CT) with extension blocks. If
you are interested:
https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki
> 5) should we ever do confidential transactions we can't prevent it without
> compromising
privacy / allowed transfers
I wanted to mention the dubiousness of adding confidential transactions to
bitcoin. Because adding CT would eliminate the ability for users to audit
the supply of Bitcoin, I
Why would removing the dust limit impact decentralisation of mining if
miners can reconfigure the dust limit for their mined blocks?
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
> 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
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
Good morning all,
Thinking a little more, if the dust limit is intended to help keep UTXO sets
down, then on the LN side, this could be achieved as well by using channel
factories (including "one-shot" factories which do not allow changing the
topology of the subgraph inside the factory, but
Good morning Billy, et al.,
> For sure, CT can be done with computational soundness. The advantage of
> unhidden amounts (as with current bitcoin) is that you get unconditional
> soundness.
My understanding is that it should be possible to have unconditional soundness
with the use of El-Gamal
You might be interested in https://eprint.iacr.org/2017/1066.pdf which
claims that you can make CT computationally hiding and binding, see section
4.6.
with respect to utreexo, you might review
https://github.com/mit-dci/utreexo/discussions/249?sort=new which discusses
tradeoffs between different
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*
24 matches
Mail list logo
