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 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
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
Allow me to introduce this simple idea that could be useful ...
-The Intuition was some discussion on Utreexo project about storage saving
and some traversing issues in handling the UTXOS Merkle Tree/ forest; that
is N internal nodes need to be stored along with 2N pointers (left&right),
+ maybe
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
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
Dear Sir,
Regarding your message
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019636.html
Specifically the part
*"Right now, lightning anchor outputs use a 330 sats amount. Each
commitment*
*transaction has two such outputs, and only one of them is spent"*
I was wondering *
Dear Bitcoin Developers,
-I think you may remember me sending to you about my proposal to partition
( and other stuff all about) the UTXO set Merkle in bridge servers
providing proofs Stateless nodes.
-While those previous suggestions might not have been on the most interest
of core Developers, I
On Mon, Feb 7, 2022, 16:44 Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > every lightning network transaction adds one dust UTXO
>
> Could you clarify what you mean here? What dust do lightning transactions
> create?
>
I mean this msg
https://lists.linuxfoundation
I just want to add an alarming info to this thread...
*There are at least 5.7m UTXOs≤1000 Sat (~7%), *
*8.04 m ≤1$ (10%), *
*13.5m ≤ 0.0001BTC (17%)*
It seems that bitInfoCharts took my enquiry seriously and added a main link
for dust analysis:
https://bitinfocharts.com/top-100-dustiest-bitcoin-a
Are you big Developers aware of what is said in this thread
https://bitcointalk.org/index.php?topic=5385559.new#new
That "Omni" ALT coin, and all Alt coins and new protocols do create such
extensive amount of dust that they are thinking of dividing 1 Satoshi to
fractions or how to accept a UTXO wi
If you allow me to comment (just with a bird eye, have not read the paper
only the abstract)
I think the Bitcoin community may consider the intuition of somewhat
"Future Saving" through TX fees:
ie, the idea of saving a ratio of the fees (say half to be decreased to
half with each reward halving)i
12 matches
Mail list logo
