if
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
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 int
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 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
Good morning shymaa,
> The suggested idea I was replying to is to make all dust TXs invalid by some
> nodes.
Is this supposed to be consensus change or not?
Why "some" nodes and not all?
I think the important bit is for full nodes.
Non-full-nodes already work at reduced security; what is import
The suggested idea I was replying to is to make all dust TXs invalid by
some nodes. I suggested a compromise by keeping them in secondary storage
for full nodes, and in a separate Merkle Tree for bridge servers.
-In bridge servers they won't increase any worstcase, on the contrary this
will enhance
If u allow me to discuss,,,
I previously suggested storing dust UTXOS in a separate Merkle tree or
strucutre in general if we are talking about the original set.
I'm a kind of person who doesn't like to throw any thing; if it's not
needed now keep it in the basement for example.
So, if dust UTXOS m
Good morning shymaa
> If u allow me to discuss,,,
> I previously suggested storing dust UTXOS in a separate Merkle tree or
> strucutre in general if we are talking about the original set.
> I'm a kind of person who doesn't like to throw any thing; if it's not needed
> now keep it in the basement
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 blocks
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 t
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 crea
___
From: 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 con
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 like
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 ou
On Fri, Aug 20, 2021, 06:52 Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 li
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
maintenan
Dear Sir,
I'm not discussing the dust limit here, but I'm suggesting some mitigations
to the dust problem which tackles almost the same points mentioned here
especially the scalability of the UTXOS set and the corresponding Merkle
proofs/witnesses in Utreexo or any similar design
.
I suggest:
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 t
> Alternately, one possible softforkable design would be for Bitcoin to
> maintain a non-CT block (the current scheme) and a separately-committed CT
> block (i.e. similar to how SegWit has a "separate" "block"/Merkle tree that
> includes witnesses).
> When transferring funds from the legacy non-
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
https://github.com/litecoin-project/lips/blob/master/lip-000
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 ha
> As developers, we have no
control over prevailing feerates, so this is a problem LN needs to deal
with regardless of Bitcoin Core's dust limit.
Right, as of today, we're going to trim-to-dust any commitment output of
which the value is inferior to the transaction owner's
`dust_limit_satoshis` p
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
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
> 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 thi
On Mon, Aug 09, 2021 at 09:22:28AM -0400, Antoine Riard wrote:
> I'm pretty conservative about increasing the standard dust limit in any
> way. This would convert a higher percentage of LN channels capacity into
> dust, which is coming with a lowering of funds safety [0].
I think that reasoning i
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
I'm pretty conservative about increasing the standard dust limit in any
way. This would convert a higher percentage of LN channels capacity into
dust, which is coming with a lowering of funds safety [0]. Of course, we
can adjust the LN security model around dust handling to mitigate the
safety risk
some additional answers/clarifications
> Question for Jeremy: would you also allow zero-value outputs? Or would
> you just move the dust limit down to a fixed 1-sat?
>
I would remove it entirely -- i don't think there's a difference between
the two realistically.
>
> Allowing 0-value or 1-s
Under no circumstances do I think we should *increase* the dust limit. That
would have a mildly confiscatory effect on current Lightning Channel
operators, among others.
Generally, the UTXO set will grow. We should work to accommodate the worst
case scenario under current consensus rules. I think
On Sun, Aug 08, 2021 at 11:52:55AM -0700, Jeremy wrote:
> We should remove the dust limit from Bitcoin. Five reasons:
Jeremy knows this, but to be clear for other readers, the dust limit is
a policy in Bitcoin Core (and other software) where it refuses by
default to relay or mine transactions with
32 matches
Mail list logo
