Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

2022-02-17 Thread ZmnSCPxj via bitcoin-dev
Good morning shymaa, > 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: >

Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

2022-02-13 Thread shymaa arafat via bitcoin-dev
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

Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

2022-02-13 Thread yanmaani--- via bitcoin-dev
On 2022-02-07 14:34, Billy Tetrud via bitcoin-dev wrote: I do think that UTXO set size is something that will need to be addressed at some point. I liked the idea of utreexo or some other accumulator as the ultimate solution to this problem. What about using economic incentives to

Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

2022-02-13 Thread shymaa arafat via bitcoin-dev
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:

Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

2022-02-07 Thread shymaa arafat via bitcoin-dev
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

Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

2022-02-07 Thread Billy Tetrud via bitcoin-dev
> every lightning network transaction adds one dust UTXO Could you clarify what you mean here? What dust do lightning transactions create? I do think that UTXO set size is something that will need to be addressed at some point. I liked the idea of utreexo or some other accumulator as the

Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

2022-02-06 Thread Eric Voskuil via bitcoin-dev
> On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev > wrote: > >  >> Dear Bitcoin Developers, > >> -When I contacted bitInfoCharts to divide the first interval of addresses, >> they kindly did divided to 3 intervals. From here: >>

Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

2022-02-06 Thread Pieter Wuille via bitcoin-dev
> Dear Bitcoin Developers, > -When I contacted bitInfoCharts to divide the first interval of addresses, > they kindly did divided to 3 intervals. From here: > https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html > -You can see that there are more than 3.1m addresses holding ≤

[bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

2022-02-06 Thread shymaa arafat via bitcoin-dev
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