* [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 12:41 shymaa arafat
2022-02-06 17:39 ` Pieter Wuille
0 siblings, 1 reply; 9+ messages in thread
From: shymaa arafat @ 2022-02-06 12:41 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]
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 think this one I happened to notice is:
-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 ≤ 0.000001
BTC (1000 Sat) with total value of *14.9BTC*; an average of *473 Sat* per
address.
-Keeping in mind that an address can hold more than 1 UTXO; ie, this is
even a lowerbound on the number of UTXOs holding such small values.
-Noticing also that every lightning network transaction adds one dust UTXO
(actually two one of which is instantly spent, and their dust limit is 333
Sat not even 546), ie, *this number of dust UTXOs will probably increase
with time.*
.
-Therefore, a simple solution would be to follow the difficulty adjustment
idea and just *delete all those*, or at least remove them to secondary
storage for Archiving with extra cost to get them back, *along with
non-standard UTXOs and Burned ones* (at least for publicly known,
published, burn addresses). *Benefits are:*
1- you will *relieve* the system state from the burden *of about 3.8m
UTXOs *
(*3.148952m*
+ *0.45m* non-standard
+ *0.178m* burned
https://blockchair.com/bitcoin/address/1111111111111111111114oLvT2
https://blockchair.com/bitcoin/address/1CounterpartyXXXXXXXXXXXXXXXUWLpVr
as of today 6Feb2022)
, a number that will probably increase with time.
2-You will add to the *scarcity* of Bitcoin even with a very small amount
like 14.9 BTC.
3-You will *remove* away *the risk of using* any of these kinds for
*attacks* as happened before.
.
-Finally, the parameters could be studied for optimal values; I mean the
1st delete, the periodical interval, and also the delete threshold (maybe
all holding less than 1$ not just 546 Sat need to be deleted)
.
That's all
Thank you very much
.
Shymaa M Arafat
[-- Attachment #2: Type: text/html, Size: 3239 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* 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 12:41 [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn shymaa arafat
@ 2022-02-06 17:39 ` Pieter Wuille
2022-02-06 19:14 ` Eric Voskuil
[not found] ` <382073c28af1ec54827093003cbec2cc@willtech.com.au>
0 siblings, 2 replies; 9+ messages in thread
From: Pieter Wuille @ 2022-02-06 17:39 UTC (permalink / raw)
To: shymaa arafat, Bitcoin Protocol Discussion
> 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 ≤ 0.000001 BTC (1000 Sat) with total value of 14.9BTC; an average of 473 Sat per address.
> -Therefore, a simple solution would be to follow the difficulty adjustment idea and just delete all those
That would be a soft-fork, and arguably could be considered theft. While commonly (but non universally) implemented standardness rules may prevent spending them currently, there is no requirement that such a rule remain in place. Depending on how feerate economics work out in the future, such outputs may not even remain uneconomical to spend. Therefore, dropping them entirely from the UTXO set is potentially destroying potentially useful funds people own.
> or at least remove them to secondary storage
Commonly adopted Bitcoin full nodes already have two levels of storage effectively (disk and in-RAM cache). It may be useful to investigate using amount as a heuristic about what to keep and how long. IIRC, not even every full node implementation even uses a UTXO model.
> for Archiving with extra cost to get them back, along with non-standard UTXOs and Burned ones (at least for publicly known, published, burn addresses).
Do you mean this as a standardness rule, or a consensus rule?
* As a standardness rule it's feasible, but it makes policy (further) deviate from economically rational behavior. There is no reason for miners to require a higher price for spending such outputs.
* As a consensus rule, I expect something like this to be very controversial. There are currently no rules that demand any minimal fee for anything, and given uncertainly over how fee levels could evolve in the future, it's unclear what those rules, if any, should be.
Cheers,
--
Pieter
^ permalink raw reply [flat|nested] 9+ messages in thread
* 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 17:39 ` Pieter Wuille
@ 2022-02-06 19:14 ` Eric Voskuil
2022-02-07 14:34 ` Billy Tetrud
[not found] ` <382073c28af1ec54827093003cbec2cc@willtech.com.au>
1 sibling, 1 reply; 9+ messages in thread
From: Eric Voskuil @ 2022-02-06 19:14 UTC (permalink / raw)
To: Pieter Wuille, Bitcoin Protocol Discussion
> On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
>> 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 ≤ 0.000001 BTC (1000 Sat) with total value of 14.9BTC; an average of 473 Sat per address.
>
>> -Therefore, a simple solution would be to follow the difficulty adjustment idea and just delete all those
>
> That would be a soft-fork, and arguably could be considered theft. While commonly (but non universally) implemented standardness rules may prevent spending them currently, there is no requirement that such a rule remain in place. Depending on how feerate economics work out in the future, such outputs may not even remain uneconomical to spend. Therefore, dropping them entirely from the UTXO set is potentially destroying potentially useful funds people own.
>
>> or at least remove them to secondary storage
>
> Commonly adopted Bitcoin full nodes already have two levels of storage effectively (disk and in-RAM cache). It may be useful to investigate using amount as a heuristic about what to keep and how long. IIRC, not even every full node implementation even uses a UTXO model.
You recall correctly. Libbitcoin has never used a UTXO store. A full node has no logical need for an additional store of outputs, as transactions already contain them, and a full node requires all of them, spent or otherwise.
The hand-wringing over UTXO set size does not apply to full nodes, it is relevant only to pruning. Given linear worst case growth, even that is ultimately a non-issue.
>> for Archiving with extra cost to get them back, along with non-standard UTXOs and Burned ones (at least for publicly known, published, burn addresses).
>
> Do you mean this as a standardness rule, or a consensus rule?
>
> * As a standardness rule it's feasible, but it makes policy (further) deviate from economically rational behavior. There is no reason for miners to require a higher price for spending such outputs.
> * As a consensus rule, I expect something like this to be very controversial. There are currently no rules that demand any minimal fee for anything, and given uncertainly over how fee levels could evolve in the future, it's unclear what those rules, if any, should be.
>
> Cheers,
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 9+ messages in thread
* 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 19:14 ` Eric Voskuil
@ 2022-02-07 14:34 ` Billy Tetrud
2022-02-07 16:51 ` shymaa arafat
2022-02-13 9:56 ` yanmaani
0 siblings, 2 replies; 9+ messages in thread
From: Billy Tetrud @ 2022-02-07 14:34 UTC (permalink / raw)
To: Eric Voskuil, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3833 bytes --]
> 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
ultimate solution to this problem. In the mean time, I kind of agree with
Eric that outputs unlikely to be spent can easily be stored off ram and so
I wouldn't expect them to really be much of an issue to keep around. 3
million utxos is only like 100MB. If software could be improved to move
dust off ram, that sounds like a good win tho.
On Sun, Feb 6, 2022, 13:14 Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
> > On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> >
> >> 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 ≤ 0.000001
> BTC (1000 Sat) with total value of 14.9BTC; an average of 473 Sat per
> address.
> >
> >> -Therefore, a simple solution would be to follow the difficulty
> adjustment idea and just delete all those
> >
> > That would be a soft-fork, and arguably could be considered theft. While
> commonly (but non universally) implemented standardness rules may prevent
> spending them currently, there is no requirement that such a rule remain in
> place. Depending on how feerate economics work out in the future, such
> outputs may not even remain uneconomical to spend. Therefore, dropping them
> entirely from the UTXO set is potentially destroying potentially useful
> funds people own.
> >
> >> or at least remove them to secondary storage
> >
> > Commonly adopted Bitcoin full nodes already have two levels of storage
> effectively (disk and in-RAM cache). It may be useful to investigate using
> amount as a heuristic about what to keep and how long. IIRC, not even every
> full node implementation even uses a UTXO model.
>
> You recall correctly. Libbitcoin has never used a UTXO store. A full node
> has no logical need for an additional store of outputs, as transactions
> already contain them, and a full node requires all of them, spent or
> otherwise.
>
> The hand-wringing over UTXO set size does not apply to full nodes, it is
> relevant only to pruning. Given linear worst case growth, even that is
> ultimately a non-issue.
>
> >> for Archiving with extra cost to get them back, along with non-standard
> UTXOs and Burned ones (at least for publicly known, published, burn
> addresses).
> >
> > Do you mean this as a standardness rule, or a consensus rule?
> >
> > * As a standardness rule it's feasible, but it makes policy (further)
> deviate from economically rational behavior. There is no reason for miners
> to require a higher price for spending such outputs.
> > * As a consensus rule, I expect something like this to be very
> controversial. There are currently no rules that demand any minimal fee for
> anything, and given uncertainly over how fee levels could evolve in the
> future, it's unclear what those rules, if any, should be.
> >
> > Cheers,
> >
> > --
> > Pieter
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 5177 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* 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 14:34 ` Billy Tetrud
@ 2022-02-07 16:51 ` shymaa arafat
2022-02-13 9:56 ` yanmaani
1 sibling, 0 replies; 9+ messages in thread
From: shymaa arafat @ 2022-02-07 16:51 UTC (permalink / raw)
To: Billy Tetrud, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5190 bytes --]
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.org/pipermail/bitcoin-dev/2021-December/019636.html
Even though, the writer clarified after my enquiry I still think it is the
same meaning most of the time only one will be spent. His words:
..............
*My statement was technically incorrect, it should have been "most of the
time only one of them is spent".*
*But nothing prevents them to be both spent, or none of them to be spent.*
*They are strictly equivalent, the only difference is the public key that
can sign for them: one of these outputs belongs to you, the other belongs
to your peer.*
*You really cannot distinguish anything when inserting them into the utxo
set, they are perfectly symmetrical and you cannot know beforehand for sure
which one will be spent.*
*You can guess which one will be spent most of the time, but your heuristic
will never be 100% correct, so I don't think it's worth pursuing.*
*.........*........
>
> 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. In the mean time, I kind of agree with
> Eric that outputs unlikely to be spent can easily be stored off ram and so
> I wouldn't expect them to really be much of an issue to keep around. 3
> million utxos is only like 100MB. If software could be improved to move
> dust off ram, that sounds like a good win tho.
>
> On Sun, Feb 6, 2022, 13:14 Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>>
>>
>> > On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>> >
>> >
>> >> 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 ≤
>> 0.000001 BTC (1000 Sat) with total value of 14.9BTC; an average of 473 Sat
>> per address.
>> >
>> >> -Therefore, a simple solution would be to follow the difficulty
>> adjustment idea and just delete all those
>> >
>> > That would be a soft-fork, and arguably could be considered theft.
>> While commonly (but non universally) implemented standardness rules may
>> prevent spending them currently, there is no requirement that such a rule
>> remain in place. Depending on how feerate economics work out in the future,
>> such outputs may not even remain uneconomical to spend. Therefore, dropping
>> them entirely from the UTXO set is potentially destroying potentially
>> useful funds people own.
>> >
>> >> or at least remove them to secondary storage
>> >
>> > Commonly adopted Bitcoin full nodes already have two levels of storage
>> effectively (disk and in-RAM cache). It may be useful to investigate using
>> amount as a heuristic about what to keep and how long. IIRC, not even every
>> full node implementation even uses a UTXO model.
>>
>> You recall correctly. Libbitcoin has never used a UTXO store. A full node
>> has no logical need for an additional store of outputs, as transactions
>> already contain them, and a full node requires all of them, spent or
>> otherwise.
>>
>> The hand-wringing over UTXO set size does not apply to full nodes, it is
>> relevant only to pruning. Given linear worst case growth, even that is
>> ultimately a non-issue.
>>
>> >> for Archiving with extra cost to get them back, along with
>> non-standard UTXOs and Burned ones (at least for publicly known, published,
>> burn addresses).
>> >
>> > Do you mean this as a standardness rule, or a consensus rule?
>> >
>> > * As a standardness rule it's feasible, but it makes policy (further)
>> deviate from economically rational behavior. There is no reason for miners
>> to require a higher price for spending such outputs.
>> > * As a consensus rule, I expect something like this to be very
>> controversial. There are currently no rules that demand any minimal fee for
>> anything, and given uncertainly over how fee levels could evolve in the
>> future, it's unclear what those rules, if any, should be.
>> >
>> > Cheers,
>> >
>> > --
>> > Pieter
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists•linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 7598 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
[not found] ` <CAM98U8mJvYcBur01Z32TS4RYW+jMDCVQAUtrg5KXF+50d0zirA@mail.gmail.com>
@ 2022-02-13 5:19 ` shymaa arafat
2022-02-18 3:36 ` ZmnSCPxj
0 siblings, 1 reply; 9+ messages in thread
From: shymaa arafat @ 2022-02-13 5:19 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, lightning-dev
[-- Attachment #1: Type: text/plain, Size: 6194 bytes --]
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-addresses.html
Here, you can see just *the first address contains more than 1.7m dust
UTXOs*
(ins-outs =1,712,706 with a few real UTXOs holding the bulk of 415 BTC)
https://bitinfocharts.com/bitcoin/address/1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ
»»»»»
That's alarming isn't it?, is it due to the lightning networks protocol or
could be some other weird activity going on?
.
The following address are similar but less severe
~394k UTXOs, 170k, 92k, 10*20k, 4or5 *14k,...etc
add at least 2.7m UTXOs coming from addresses with a higher balance to the
interval numbers here (calculated & mentioned in my previous email)
https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
I think it seems bitInfoCharts will probably make their own report about it
soon
Regards
Shymaa M. Arafat
On Wed, Feb 9, 2022, 07:19 shymaa arafat <shymaa.arafat@gmail•com> wrote:
> If 1 Sat reached 100$, you may adjust the delete( or call it omitting or
> trimming) threshold, since you will need to acquire decimal places inside
> the Sat variable too ( people may have TXs less than 100$)
>
> -Talking with today's numbers,
> https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
>
> it is hard to imagine that someone's all holdings in Bitcoin is just ≤1000
> Sat (3.15 m address) or even ≤10,000 Sat (4.1$, with currently 7.6m
> addresses in addition to the 3.15m)
> So we'll just incentivise those people to find a low fee time in say a 6
> month interval and collect those UTXOs into one of at least 5$
> (10.86m≤4.1$) or 1$ (5.248m≤1$) your decision.
>
> -During 4 days after showing the smaller intervals, those ≤1000Sat
> increase by ~2K everyday with total holding increased by 0.01BTC. Addresses
> in millions:
> 3.148, 3.1509, 3.152895, 3.154398
> Total BTC:
> 14.91,14.92,14.93,14.94
>
> -The number of ≤10,000 Sat increases by 4-8 k per day.
> Addresses in millions:
> 7.627477, 7.631436, 7.639287, 7.644925
> Total BTC
> 333.5, 333.63, 333.89, 334.1
>
> -remember that no. of addresses is a lowerbound on no. of UTXOs; ie., the
> real numbers could be even more.
> .
> + There's also non-standard & burned , yes they're about 0.6m UTXOs, but
> they're misleading on the status of the value they hold.
> .
> At the end, I'm just suggesting...
> .
> Regards,
> Shymaa
>
> On Wed, Feb 9, 2022, 00:16 <damian@willtech•com.au> wrote:
>
>> Good Morning,
>>
>> I wish to point out that because fees are variable there is no reason
>> fees could not be less than 1 sat in future if fees climb. You may
>> consider this optimistic but I recall in the first days of Bitcoin when
>> fees were voluntary. It is not unreasonable provided the fungibility
>> (money-like-quality) of Bitcoin is maintained for 1 sat to be worth over
>> $100.00 in the future.
>>
>> KING JAMES HRMH
>> Great British Empire
>>
>> Regards,
>> The Australian
>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>> of Hougun Manor & Glencoe & British Empire
>> MR. Damian A. James Williamson
>> Wills
>>
>> et al.
>>
>>
>> Willtech
>> www.willtech.com.au
>> www.go-overt.com
>> duigco.org DUIGCO API
>> and other projects
>>
>>
>> m. 0487135719
>> f. +61261470192
>>
>>
>> This email does not constitute a general advice. Please disregard this
>> email if misdelivered.
>> --------------
>> On 2022-02-06 09:39, 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:
>> >> https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
>> >> -You can see that there are more than 3.1m addresses holding ≤
>> >> 0.000001 BTC (1000 Sat) with total value of 14.9BTC; an average of 473
>> >> Sat per address.
>> >
>> >> -Therefore, a simple solution would be to follow the difficulty
>> >> adjustment idea and just delete all those
>> >
>> > That would be a soft-fork, and arguably could be considered theft.
>> > While commonly (but non universally) implemented standardness rules
>> > may prevent spending them currently, there is no requirement that such
>> > a rule remain in place. Depending on how feerate economics work out in
>> > the future, such outputs may not even remain uneconomical to spend.
>> > Therefore, dropping them entirely from the UTXO set is potentially
>> > destroying potentially useful funds people own.
>> >
>> >> or at least remove them to secondary storage
>> >
>> > Commonly adopted Bitcoin full nodes already have two levels of storage
>> > effectively (disk and in-RAM cache). It may be useful to investigate
>> > using amount as a heuristic about what to keep and how long. IIRC, not
>> > even every full node implementation even uses a UTXO model.
>> >
>> >> for Archiving with extra cost to get them back, along with
>> >> non-standard UTXOs and Burned ones (at least for publicly known,
>> >> published, burn addresses).
>> >
>> > Do you mean this as a standardness rule, or a consensus rule?
>> >
>> > * As a standardness rule it's feasible, but it makes policy (further)
>> > deviate from economically rational behavior. There is no reason for
>> > miners to require a higher price for spending such outputs.
>> > * As a consensus rule, I expect something like this to be very
>> > controversial. There are currently no rules that demand any minimal
>> > fee for anything, and given uncertainly over how fee levels could
>> > evolve in the future, it's unclear what those rules, if any, should
>> > be.
>> >
>> > Cheers,
>> >
>> > --
>> > Pieter
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists•linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
[-- Attachment #2: Type: text/html, Size: 9517 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* 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 14:34 ` Billy Tetrud
2022-02-07 16:51 ` shymaa arafat
@ 2022-02-13 9:56 ` yanmaani
2022-02-13 13:11 ` shymaa arafat
1 sibling, 1 reply; 9+ messages in thread
From: yanmaani @ 2022-02-13 9:56 UTC (permalink / raw)
To: Billy Tetrud, Bitcoin Protocol Discussion
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 disincentivize the creation of
new UTXOs? Currently, the fee is only charged per byte of space. What if
you instead charged a fee of (bytes*byte_weight +
net_utxos*utxo_weight)? For example, if utxo_weight=500, then a
transaction that creates 2 new UTXOs would cost as if it were 1 KB in
size. And a transaction that consolidated 2 UTXOs into one might even
get a negative transaction fee (rebate).
Technologically, you'd implement this by lowering the block size cap by
max(0, net_utxos_created*utxo_weight). That would be a soft fork, if
maybe a contentious one. It's probably also a good idea to limit it at
0, separate from consensus issues, because it means you're not
guaranteed to get back whatever you put into it.
^ permalink raw reply [flat|nested] 9+ messages in thread
* 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 9:56 ` yanmaani
@ 2022-02-13 13:11 ` shymaa arafat
0 siblings, 0 replies; 9+ messages in thread
From: shymaa arafat @ 2022-02-13 13:11 UTC (permalink / raw)
To: yanmaani, Bitcoin Protocol Discussion; +Cc: Billy Tetrud
[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]
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 with 0 value????
Isn't that almost the definition of non-standard transactions; the famous
2016 email?
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html
On Sun, Feb 13, 2022, 13:02 yanmaani--- via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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 disincentivize the creation of
> new UTXOs? Currently, the fee is only charged per byte of space. What if
> you instead charged a fee of (bytes*byte_weight +
> net_utxos*utxo_weight)? For example, if utxo_weight=500, then a
> transaction that creates 2 new UTXOs would cost as if it were 1 KB in
> size. And a transaction that consolidated 2 UTXOs into one might even
> get a negative transaction fee (rebate).
>
> Technologically, you'd implement this by lowering the block size cap by
> max(0, net_utxos_created*utxo_weight). That would be a soft fork, if
> maybe a contentious one. It's probably also a good idea to limit it at
> 0, separate from consensus issues, because it means you're not
> guaranteed to get back whatever you put into it.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2714 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* 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 5:19 ` shymaa arafat
@ 2022-02-18 3:36 ` ZmnSCPxj
0 siblings, 0 replies; 9+ messages in thread
From: ZmnSCPxj @ 2022-02-18 3:36 UTC (permalink / raw)
To: shymaa arafat, Bitcoin Protocol Discussion; +Cc: lightning-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:
> https://bitinfocharts.com/top-100-dustiest-bitcoin-addresses.html
> Here, you can see just the first address contains more than 1.7m dust UTXOs
> (ins-outs =1,712,706 with a few real UTXOs holding the bulk of 415 BTC)
> https://bitinfocharts.com/bitcoin/address/1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ
>
> »»»»»
> That's alarming isn't it?, is it due to the lightning networks protocol or could be some other weird activity going on?
> .
I believe some blockchain tracking analysts will "dust" addresses that were spent from (give them 546 sats), in the hope that lousy wallets will use the new 546-sat UTXO from the same address but spending to a different address and combining with *other* inputs with new addresses, thus allowing them to grow their datasets about fund ownership.
Indeed JoinMarket has a policy to ignore-by-default UTXOs that pay to an address it already spent from, precisely due to this (apparently common, since my JoinMarket maker got dusted a number of times already) practice.
I am personally unsure of how common this is but it seems likely that you can eliminate this effect by removing outputs of exactly 546 sats to reused addresses.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-02-18 3:36 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-06 12:41 [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn shymaa arafat
2022-02-06 17:39 ` Pieter Wuille
2022-02-06 19:14 ` Eric Voskuil
2022-02-07 14:34 ` Billy Tetrud
2022-02-07 16:51 ` shymaa arafat
2022-02-13 9:56 ` yanmaani
2022-02-13 13:11 ` shymaa arafat
[not found] ` <382073c28af1ec54827093003cbec2cc@willtech.com.au>
[not found] ` <CAM98U8mJvYcBur01Z32TS4RYW+jMDCVQAUtrg5KXF+50d0zirA@mail.gmail.com>
2022-02-13 5:19 ` shymaa arafat
2022-02-18 3:36 ` ZmnSCPxj
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox