shymaa arafat [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-08-18 to 2023-02-28
💬 Posted a total of 19 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1l7ldumxqplqv4h9lfkwpwp3lapj3xnla2hnf8h8mm9da3qlv6shqfhgr56

Profile Code

nprofile1qqs0l0k7dnqqlsx2mjl5m8qhqcl7segnfl74te5nmnaajk7cs0kdgtsuydakj

Author Public Key

npub1l7ldumxqplqv4h9lfkwpwp3lapj3xnla2hnf8h8mm9da3qlv6shqfhgr56

Show more details

Last Notes

2023-06-09 13:05:13

- reply

📅 Original date posted:2022-02-13
📝 Original message:
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 at 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 at 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 at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220213/eb38bf91/attachment.html>

2023-06-09 13:03:55

- reply

📅 Original date posted:2021-10-08
📝 Original message:
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 the performance even if slightly.
-In full nodes, and since they will usually appear in clusters, they will
be fetched rarely (either by a dust sweeping action, or a malicious
attacker)
In both cases as a batch
-To not exhaust the node with DoS(as the reply mentioned)one may think of
uploading the whole dust partition if they were called more than certain
threshold (say more than 1 Tx in a block)
-and then keep them there for "a while", but as a separate partition too to
exclude them from any caching mechanism after that block.
-The "while" could be a tuned parameter.
-Take care that the more dust is sweeped, the less dust to remain in the
UTXO set; as users are already much dis-incentivised to create more.
.
Thanks for allowing the reply
On Thu, Oct 7, 2021, 16:43 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>
> > I don't know what brings up sorting here, unless as an example.
>
> Yes, it is an example: quicksort is bad for network-facing applications
> because its ***worst-case behavior*** is bad.
> Bitcoin is a network-facing application, and similarly, ***worst-case
> behavior*** being bad is something that would strongly discourage
> particular approaches.
> Your proposal risks bad ***worst-case behavior***.
>
> > Anyways, I was comparing to rejecting them completely, not to keeping
> them in one set. In addition, those dust sweep Transactions will probably
> be a dust sweep and thus contain so many inputs which "maybe" makes 1-one
> disk visit to fetch all their hashes at once, 2-from a smaller subset with
> max size 5-10% the UTXO set, justifiable.
>
> Do not consider the ***average case*** where a block is composed of only a
> few dust sweep transactions and most transactions are normal,
> non-dust-sweep transactions.
>
> Instead, consider the ***worst case*** where ***all*** transactions in a
> block are dust sweep transactions, because that is what attackers will use.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211008/91bd7b81/attachment.html>

2023-06-09 13:03:42

- reply

📅 Original date posted:2021-09-16
📝 Original message:
It could be viewed as the simple complete tree to 1D array with no
pointers described in lecture 8 here
https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-006-introduction-to-algorithms-spring-2020/lecture-notes/index.htm
starting from min 15 in this video
https://youtu.be/Xnpo1atN-Iw
Since all trees in Utreexo forest are full binary trees, this is perfect to
use, and we can save *76*10⁶*2*size of pointer(probably4bytes)*
*~600MB *with almost no effort.
However, I suggest to put it in a 2D array to make it more easy to handle
(the indexing math) as we, different than the lecture, traverse in many
ways ( normally to delete or insert, and the parent siblings for the proofs)
I wrote more details here
https://bitcointalk.org/index.php?topic=5360009.0
On Thu, Sep 16, 2021, 14:37 Vincent <vincent.palazzo at protonmail.com> wrote:
> Hi.
>
> Thanks for the reference, but I missed where you want save space with this
> compression on the Merkle Tree.
>
> Regards.
>
> Vincent.
> vincenzo.palazzo at protonmail.com
> https://github.com/vincenzopalazzo
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, September 16th, 2021 at 5:15 AM, shymaa arafat <
> shymaa.arafat at gmail.com> wrote:
>
> 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 1 more pointer in the leaves special nodes to handle different
> traversing options (insert, delete, & differently proof fetch that traverse
> aunt or niece node according to your implementation
> https://github.com/mit-dci/utreexo/discussions/316)
> .
> Then, I thought of a simple idea that gets rid of all the pointers;
> specially appealing when we have all trees are full (complete) in the
> forest, but can work for any Merkle Tree:
>
> - 2D array with variable row size; R[j] is of length (N/2^j)
> -For example when N=8 nodes
> R[0]=0,1,2,...,7
> R[1]=8,9,10,11
> R[2]=12,13
> R[3]=14
> .
> -We can see that total storage is just 2N-1 nodes,
> no need for pointers, and traversing could be neat in any direction with
> the right formula:
>
> -Pseudo code to fetch proof[i] ...
>
> //direction to know + or -
> If ((i mod 2)==0) drct=1;
> else drct=-1;
> // first, the sibling node
> proof[i]=R[0,i+drct]
>
> //add the rest thru loop
> For(j=1; j≤logN; j++)
> { index= i/(2^j)+drct;
> proof[i]=Add(R[j,index]);
> }
>
> -In fact it's just the simple primitive approach of transforming a
> recursion to an iteration, and even if Utreexo team solved their problem
> differently I thought it is worth telling as it can work for any Merkle Tree
> .
> Thanks for your time,
> Shymaa M Arafat
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210916/c0fa90ad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_20210913_194256.jpg
Type: image/jpeg
Size: 279763 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210916/c0fa90ad/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_20210913_193322.jpg
Type: image/jpeg
Size: 164592 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210916/c0fa90ad/attachment-0003.jpg>

2023-06-09 13:03:42

- reply

📅 Original date posted:2021-09-11
📝 Original message:
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 1 more pointer in the leaves special nodes to handle different
traversing options (insert, delete, & differently proof fetch that traverse
aunt or niece node according to your implementation
https://github.com/mit-dci/utreexo/discussions/316)
.
Then, I thought of a simple idea that gets rid of all the pointers;
specially appealing when we have all trees are full (complete) in the
forest, but can work for any Merkle Tree:
- 2D array with variable row size; R[j] is of length (N/2^j)
-For example when N=8 nodes
R[0]=0,1,2,...,7
R[1]=8,9,10,11
R[2]=12,13
R[3]=14
.
-We can see that total storage is just 2N-1 nodes,
no need for pointers, and traversing could be neat in any direction with
the right formula:
-Pseudo code to fetch proof[i] ...
//direction to know + or -
If ((i mod 2)==0) drct=1;
else drct=-1;
// first, the sibling node
proof[i]=R[0,i+drct]
//add the rest thru loop
For(j=1; j≤logN; j++)
{ index= i/(2^j)+drct;
proof[i]=Add(R[j,index]);
}
-In fact it's just the simple primitive approach of transforming a
recursion to an iteration, and even if Utreexo team solved their problem
differently I thought it is worth telling as it can work for any Merkle Tree
.
Thanks for your time,
Shymaa M Arafat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210911/1ca4abf1/attachment.html>

2023-06-09 13:03:20

- reply

📅 Original date posted:2021-08-27
📝 Original message:
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 design Utreexo
or what so ever(putting them in one or two subtree/forest with hardly
changing roots according to the categorization will reduce the proof size,
even if slightly)
-This will also help things like Bloom filters, assume UTXOs,...etc when
about 10% with almost zero probability are trimmed from the pool you are
withdrawing from.
.
-The paper I mentioned earlier says in Feb 2018, there was about 2.4m UTXOS
less than 1000 Satoshi, of which ~824,892 holds exactly 1 Satoshi
-I don't think any of those were spent since that time, in fact there could
be a possibility that the numbers may have increased
-As the last previous reply mentioned you have to consider the long run
effect on the UTXO set forever, this is a straight forward improvement that
comes with almost no effort
.
Ps.
-If there is something wrong, something I missed in this idea please
explain it to me
-Or do you find the improvement itself a "dust" that doesn't worth the
effort???
.
Regards & thank you all for your time in reading & replying
Shymaa M. Arafat
On Fri, Aug 27, 2021, 00:06 Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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 likely be vanishingly small. It would be interesting to add
> something to the consensus rules to decrease the vbytes for a transaction
> that consumes dust outputs such that the value of removing them from the
> system (saving the future cost of maintenance) is approximately equal to
> the amount that the fee could be made lower for such transactions. Even
> measuring this as a value over the whole (future) bitcoin network, I'm not
> sure how to evaluate the magnitude of this future cost.
>
>
>
>
>
> On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> 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 outputs given their cost of
>> maintenance (storing the output potentially forever) is lower than their
>> immediate reward in fees.
>> > - if txn relaying nodes censor something that a miner would mine, users
>> will seek a private/direct relay to the miner and vice versa.
>> > - if direct relay to miner becomes popular, it is both bad for privacy
>> and decentralization.
>> > - therefore the dust limit, should there be demand to create dust at
>> prevailing mempool feerates, causes an incentive to increase network
>> centralization (immediately)
>> >
>> > the tradeoff is if a short term immediate incentive to promote network
>> centralization is better or worse than a long term node operator overhead.
>>
>> Against the above, we should note that in the Lightning spec, when an
>> output *would have been* created that is less than the dust limit, the
>> output is instead put into fees.
>>
>> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs
>>
>> Thus, the existence of a dust limit encourages L2 protocols to have
>> similar rules, where outputs below the dust limit are just given over as
>> fees to miners, so the existence of a dust limit might very well be
>> incentivize-compatible for miners, regardless of centralization effects or
>> not.
>>
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210827/f42a4a62/attachment.html>

2023-06-09 12:40:51

- reply

2023-06-07 23:19:54

- reply

📅 Original date posted:2023-02-28
🗒️ Summary of this message: A proposal suggests saving a ratio of Bitcoin transaction fees to address the block reward problem, but a game theoretic model is needed for exact numbers.
📝 Original message: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)is worth thinking of:
Keep in mind that the block reward problem will not start only in 2140, but
when the mining cost becomes comparable to the reward value (could this be
as near as 2040?I don't know, you know the answer better than me)
.
-So, why not start a fee splitting mechanism in analogy to reward
splitting mechanism
*(the saved ratio is half the total now, and to be halved with every
Bitcoin reward halving until a threshold is reached where the saved amounts
gets added to the low block reward)*
Ofcourse this is very rough, a game theoritic model has to be built with
the appropriate incentives and costs to get the exact numbers
.
Thank you for letting me comment in your list
.
Regards
.
Shymaa M Arafat
On Tue, Feb 28, 2023, 02:18 HcaFc_jbe via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Greetings, Brno is a beautiful city.
>
>
>
>
> Long term miner incentives remain an open question, and this is an
> interesting proposal, but it has flaws.
>
>
>
>
> -----To intervene or not intervene
>
> --No intervention: When block subsidies do run out, years from now, it's
> possible that we live in a world where ordinals, LN-settlements, and
> on-chain transactions will be filling block space to the extent that miners
> are incentivized to continue mining.
>
> --Intervention: Tail-emissions? Demurrage?
> Fee-redistribution schemes like this one?
>
> Really, it is too early to say whether mining incentives _will even_ be a
> problem, let alone _what_ the solution(s) should be.
>
> This fee-redistribution scheme aims to solve
>
> 1. Undercutting attacks [which have been precluded AFAIK with anti
> fee-sniping
>
> nLocktime since Core 0.11]
>
> 2. Fee-variance between blocks, whether due to the mining gap or
> variance in block
>
> demand.
>
>
>
> --Flaws
>
> 0. A miner in this world could be more aggressive in excluding certain
> blocks to the detriment of their counter parties. I.e. If a miner can
> ignore high-fee transactions, knowing they won't receive the _benefits_ of
> mining them [or less benefit], they can exclude these transactions without
> losing fees. E.g. if a miner is or represents a counterparty in a LN
> commitment transaction, and this counter party prefers that a time
> threshold is reached [so that they can mine a different version of the
> commitment transaction] then under this scheme they can avoid mining the
> first commitment transaction without really losing its fee, since it's fee
> is socialized anyway. This attack then becomes free or very cheap.
>
> 1. How would this smart-contract actually be constructed? The paper
> contains no references to op_codes or implementations. You do mention that
> you are not a bitcoin dev, so that's fair. AFAIK this isn't even _possible_
> with the current Script, and could remain impossible. Maybe DLCs could be
> applied somehow. IDK.
>
> 2.0. I think it will be difficult to convince the ecosystem that the
> mining incentive structure should be changed from competitive to
> cooperative. This effectively changes the mining ecosystem into one giant
> mining pool. How would this affect mining centralization?
>
> 2.1. How do we achieve miner consensus in implementing the
> fee-redistribution scheme? And what is the consensus for updating?
>
> ---Paper-nits:
>
> I believe the distribution in block creation is not exponential, but
> poisson -> on page two it's described as exponential.
>
> Cheers,
>
> -Paul
>
> ------- Original Message -------
> On Monday, February 27th, 2023 at 8:32 AM, Rastislav Budinsky via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hello,
>
> I am working on my Bachelor's thesis, in which a new way of collecting
> transaction fees is introduced or rather how they are distributed.
>
> When a miner mines a block he takes all the fees currently. However with
> the proposed solution he takes only fraction M and remaining fraction C is
> sent to one of more contracts. One contract at its simplest collects fees
> from the miner and at the same time redistributes it back to the miner.
>
> This means no new Bitcoins are introduced, only the one collected from
> fees are collected, averaged and rewarded back to the miner in a "smarter"
> way.
>
> We can have multiple such contracts, where each averages the collected
> fees over different time frames. I would like to refer you to our paper for
> more details [1], which is not yet in the final form.
>
> Benefits are discussed in the paper [1] as well, mainly it should make
> mining more secure and predictable against drastic fluctuations in fees. I
> personally do not think miners should oppose this solution as for most
> miners it should make a better mining environment. Similarly in a sense to
> what mining pools bring.
>
> I would like to know your opinions about this proposal and we can also
> discuss the needed parameters introduced with such a solution if you are in
> favor of it or think it might be interesting.
>
> Introducing this solution soon enough will not make a great difference to
> miners with current block rewards and at the same time the contracts will
> be adapted before transaction fees become the main source of income for
> miners.
>
> As I have very little to none developer experience from blockchain's point
> (especially on Bitcoin), I am not sure if this would be possible as
> soft-fork as scripts in Bitcoin are stateless I suppose.
> However maybe a generally spendable script by anyone holding the funds is
> created, which a miner of the block would be the one spending it, and the
> correct logic of following the contracts is embedded into consensus nodes
> themselves. Thus perhaps a less disruptive solution to hard-fork.
>
> Once again, I would love to know your opinions about this & I apologize
> for making this a bit less conventional BIP proposal.
>
> [1] https://arxiv.org/abs/2302.04910
>
> Best regards.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230228/ce1d3450/attachment.html>

2023-06-07 23:03:55

- reply

📅 Original date posted:2022-02-13
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220213/eb38bf91/attachment-0001.html>

2023-06-07 23:03:54

- reply

📅 Original date posted:2022-02-13
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220213/ce129380/attachment-0001.html>

2023-06-07 23:03:53

- reply

📅 Original date posted:2022-02-07
📝 Original message:On Mon, Feb 7, 2022, 16:44 Billy Tetrud via bitcoin-dev <
bitcoin-dev at 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 at lists.linuxfoundation.org> wrote:
>
>>
>>
>> > On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev <
>> bitcoin-dev at 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 at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220207/cc4fbf85/attachment-0001.html>

2023-06-07 23:03:51

- reply

📅 Original date posted:2022-02-06
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220206/78172c6e/attachment.html>

2023-06-07 23:02:38

- reply

📅 Original date posted:2022-01-21
📝 Original message: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 *is there a way to distinguish those 2 dust UTXOs?*
I mean does(or could) the protocol force the user to always spend the first
not any of them at random?
-My point is to distinguish between them when inserted in the UTXO set to
know in advance which will be spent so fast in the next transaction, and
which is gonna stay there for a while?
-If you look at the number of addresses holding ≤1$ here (by subtracting
total from >1$), you would find it doesn't change very much with days
https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
-Meaning not that just official dust value, but values ≤1$ are rarely spent
unless one forced to. I always had the idea of storing them separately
(along with non-standard & burned ones at least from public addresses,
these should be separated too as they're not expected be spent ever)
.
So the answer may make a difference,
Thank you
Shymaa M Arafat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220121/31a9ee74/attachment.html>

2023-06-07 23:00:32

- reply

📅 Original date posted:2021-11-11
📝 Original message:Dear Bitcoin Developers,
Hi everybody,
Please allow me to suggest this idea, hope you find it worth reading &
commenting....
While append to the right UTXO Merkles have the much needed advantage of
locality of reference that leads to shorter batch proofs, they're
criticized by some for not providing non-inclusion proofs. This is a
suggestion to slightly change the needed anyway map/dictionary to map the
UTXOS to their positions as leaves given their hash value, so that it can
provide non-inclusion proofs....
1-A 2⁶⁴ (could be tuned*) pointer vector is allocated to put the UTXO in a
bucket according to its hash.
2-Due to the Cryptographic hash robustness & bit randomness UTXO hashes
should fall uniformly as all buckets are equiprobable and each bucket is
expected to contain 1-2 UTXOS (less than Go lang map load factor which is
6.5-8, 2³² entry may lead to the same)
3-Insertion is adding a node (in order)to the bucket linked list, deletion
is deleting a node from the bucket list; the vector bucket pointer maybe
adjusted in the process from or to NULL value.
.
The strucutre should be as in attached figure:
Vector of pointers to buckets that could be linked lists with the following
fields in each node:
-A pointer to the UTXO leaf in the main Merkle
-The value of the remaining hash bits, or could be omitted with its value
with the leaf node.
-two bit flag that will be explained shortly.
.
4-To save computation time, we may calculate and send the accumulated root
value of this secondary tree only once per block; either at the end if
valid or when encountering an invalid UTXO to send the non-inclusion proof
and abort the whole block. Like the Tx Merkle, maybe no need to store the
tree or maybe it will save time for the non changed parts (experimental).
5-The non-inclusion proof will be send according to the previous block
accumulated root, so during batch preparation a newly inserted UTXO will
be flagged 1, a deleted UTXO is flagged -1, and 0 means value the same as
previous block.
6-If the block is valid, update and reset flags to 0 while computing the
new root. A hash of a bucket is the concatenation of all its nodes(expected
to be2), and empty buckets are substituted by a default NULL hash value.
7-If we had an invalid UTXO, we have two cases:
a)-The hash doesn't exist in any case ( not even with a deleted flag), in
this case we send the usual non-inclusion proof considering old status
before any UTXO from this block.
b)-The UTXO hash is there, but has a deleted flag (it was spent before
during this block); ie, a double spend within the same block.
Now, in this case I do have some doubts and suggestions or comments are
welcomed:
I think we should resend the previous inclusion proof along saying
something like "TX ID ....spent it with proof...."
I guess this an implementation detail of how to point out to a previous
proof in the same block
( I assume such a block is going to be aborted anyways after the invalid
UTXO and old status will be resumed, if this is wrong please say so)
.
That's all, thank you for your time,
Shymaa M. Arafat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211112/d58c7732/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_20211109_003226.jpg
Type: image/jpeg
Size: 182701 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211112/d58c7732/attachment-0001.jpg>

2023-06-07 22:59:48

- reply

📅 Original date posted:2021-10-08
📝 Original message: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 the performance even if slightly.
-In full nodes, and since they will usually appear in clusters, they will
be fetched rarely (either by a dust sweeping action, or a malicious
attacker)
In both cases as a batch
-To not exhaust the node with DoS(as the reply mentioned)one may think of
uploading the whole dust partition if they were called more than certain
threshold (say more than 1 Tx in a block)
-and then keep them there for "a while", but as a separate partition too to
exclude them from any caching mechanism after that block.
-The "while" could be a tuned parameter.
-Take care that the more dust is sweeped, the less dust to remain in the
UTXO set; as users are already much dis-incentivised to create more.
.
Thanks for allowing the reply
On Thu, Oct 7, 2021, 16:43 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>
> > I don't know what brings up sorting here, unless as an example.
>
> Yes, it is an example: quicksort is bad for network-facing applications
> because its ***worst-case behavior*** is bad.
> Bitcoin is a network-facing application, and similarly, ***worst-case
> behavior*** being bad is something that would strongly discourage
> particular approaches.
> Your proposal risks bad ***worst-case behavior***.
>
> > Anyways, I was comparing to rejecting them completely, not to keeping
> them in one set. In addition, those dust sweep Transactions will probably
> be a dust sweep and thus contain so many inputs which "maybe" makes 1-one
> disk visit to fetch all their hashes at once, 2-from a smaller subset with
> max size 5-10% the UTXO set, justifiable.
>
> Do not consider the ***average case*** where a block is composed of only a
> few dust sweep transactions and most transactions are normal,
> non-dust-sweep transactions.
>
> Instead, consider the ***worst case*** where ***all*** transactions in a
> block are dust sweep transactions, because that is what attackers will use.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211008/91bd7b81/attachment.html>

2023-06-07 22:59:48

- reply

📅 Original date posted:2021-10-07
📝 Original message: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 making a burden keep them in secondary storage, where in
such cases u can verify then delete them.
On Thu, Oct 7, 2021, 06:52 ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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 where there is an invalid but ignored dust tx, however
> > this attack seems every bit as expensive as a 51% attack
>
> How would such a node treat a transaction that spends multiple dust UTXOs
> and creates a single non-dust UTXO out of them (after fees)?
> Is it valid (to such a node) or not?
>
> I presume from #1 it never stores dust UTXOs, so the node cannot know if
> the UTXO being spent by such a tx is spending dust, or trying to spend an
> already-spent TXO, or even inventing a TXO out of `/dev/random`.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211007/3889c77d/attachment.html>

2023-06-07 22:59:09

- reply

📅 Original date posted:2021-09-16
📝 Original message:It could be viewed as the simple complete tree to 1D array with no
pointers described in lecture 8 here
https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-006-introduction-to-algorithms-spring-2020/lecture-notes/index.htm
starting from min 15 in this video
https://youtu.be/Xnpo1atN-Iw
Since all trees in Utreexo forest are full binary trees, this is perfect to
use, and we can save *76*10⁶*2*size of pointer(probably4bytes)*
*~600MB *with almost no effort.
However, I suggest to put it in a 2D array to make it more easy to handle
(the indexing math) as we, different than the lecture, traverse in many
ways ( normally to delete or insert, and the parent siblings for the proofs)
I wrote more details here
https://bitcointalk.org/index.php?topic=5360009.0
On Thu, Sep 16, 2021, 14:37 Vincent <vincent.palazzo at protonmail.com> wrote:
> Hi.
>
> Thanks for the reference, but I missed where you want save space with this
> compression on the Merkle Tree.
>
> Regards.
>
> Vincent.
> vincenzo.palazzo at protonmail.com
> https://github.com/vincenzopalazzo
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, September 16th, 2021 at 5:15 AM, shymaa arafat <
> shymaa.arafat at gmail.com> wrote:
>
> 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 1 more pointer in the leaves special nodes to handle different
> traversing options (insert, delete, & differently proof fetch that traverse
> aunt or niece node according to your implementation
> https://github.com/mit-dci/utreexo/discussions/316)
> .
> Then, I thought of a simple idea that gets rid of all the pointers;
> specially appealing when we have all trees are full (complete) in the
> forest, but can work for any Merkle Tree:
>
> - 2D array with variable row size; R[j] is of length (N/2^j)
> -For example when N=8 nodes
> R[0]=0,1,2,...,7
> R[1]=8,9,10,11
> R[2]=12,13
> R[3]=14
> .
> -We can see that total storage is just 2N-1 nodes,
> no need for pointers, and traversing could be neat in any direction with
> the right formula:
>
> -Pseudo code to fetch proof[i] ...
>
> //direction to know + or -
> If ((i mod 2)==0) drct=1;
> else drct=-1;
> // first, the sibling node
> proof[i]=R[0,i+drct]
>
> //add the rest thru loop
> For(j=1; j≤logN; j++)
> { index= i/(2^j)+drct;
> proof[i]=Add(R[j,index]);
> }
>
> -In fact it's just the simple primitive approach of transforming a
> recursion to an iteration, and even if Utreexo team solved their problem
> differently I thought it is worth telling as it can work for any Merkle Tree
> .
> Thanks for your time,
> Shymaa M Arafat
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210916/c0fa90ad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_20210913_194256.jpg
Type: image/jpeg
Size: 279763 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210916/c0fa90ad/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_20210913_193322.jpg
Type: image/jpeg
Size: 164592 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210916/c0fa90ad/attachment-0003.jpg>

2023-06-07 22:59:08

- reply

📅 Original date posted:2021-09-11
📝 Original message: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 1 more pointer in the leaves special nodes to handle different
traversing options (insert, delete, & differently proof fetch that traverse
aunt or niece node according to your implementation
https://github.com/mit-dci/utreexo/discussions/316)
.
Then, I thought of a simple idea that gets rid of all the pointers;
specially appealing when we have all trees are full (complete) in the
forest, but can work for any Merkle Tree:
- 2D array with variable row size; R[j] is of length (N/2^j)
-For example when N=8 nodes
R[0]=0,1,2,...,7
R[1]=8,9,10,11
R[2]=12,13
R[3]=14
.
-We can see that total storage is just 2N-1 nodes,
no need for pointers, and traversing could be neat in any direction with
the right formula:
-Pseudo code to fetch proof[i] ...
//direction to know + or -
If ((i mod 2)==0) drct=1;
else drct=-1;
// first, the sibling node
proof[i]=R[0,i+drct]
//add the rest thru loop
For(j=1; j≤logN; j++)
{ index= i/(2^j)+drct;
proof[i]=Add(R[j,index]);
}
-In fact it's just the simple primitive approach of transforming a
recursion to an iteration, and even if Utreexo team solved their problem
differently I thought it is worth telling as it can work for any Merkle Tree
.
Thanks for your time,
Shymaa M Arafat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210911/1ca4abf1/attachment-0001.html>

2023-06-07 22:58:00

- reply

📅 Original date posted:2021-08-27
📝 Original message: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 design Utreexo
or what so ever(putting them in one or two subtree/forest with hardly
changing roots according to the categorization will reduce the proof size,
even if slightly)
-This will also help things like Bloom filters, assume UTXOs,...etc when
about 10% with almost zero probability are trimmed from the pool you are
withdrawing from.
.
-The paper I mentioned earlier says in Feb 2018, there was about 2.4m UTXOS
less than 1000 Satoshi, of which ~824,892 holds exactly 1 Satoshi
-I don't think any of those were spent since that time, in fact there could
be a possibility that the numbers may have increased
-As the last previous reply mentioned you have to consider the long run
effect on the UTXO set forever, this is a straight forward improvement that
comes with almost no effort
.
Ps.
-If there is something wrong, something I missed in this idea please
explain it to me
-Or do you find the improvement itself a "dust" that doesn't worth the
effort???
.
Regards & thank you all for your time in reading & replying
Shymaa M. Arafat
On Fri, Aug 27, 2021, 00:06 Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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 likely be vanishingly small. It would be interesting to add
> something to the consensus rules to decrease the vbytes for a transaction
> that consumes dust outputs such that the value of removing them from the
> system (saving the future cost of maintenance) is approximately equal to
> the amount that the fee could be made lower for such transactions. Even
> measuring this as a value over the whole (future) bitcoin network, I'm not
> sure how to evaluate the magnitude of this future cost.
>
>
>
>
>
> On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> 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 outputs given their cost of
>> maintenance (storing the output potentially forever) is lower than their
>> immediate reward in fees.
>> > - if txn relaying nodes censor something that a miner would mine, users
>> will seek a private/direct relay to the miner and vice versa.
>> > - if direct relay to miner becomes popular, it is both bad for privacy
>> and decentralization.
>> > - therefore the dust limit, should there be demand to create dust at
>> prevailing mempool feerates, causes an incentive to increase network
>> centralization (immediately)
>> >
>> > the tradeoff is if a short term immediate incentive to promote network
>> centralization is better or worse than a long term node operator overhead.
>>
>> Against the above, we should note that in the Lightning spec, when an
>> output *would have been* created that is less than the dust limit, the
>> output is instead put into fees.
>>
>> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs
>>
>> Thus, the existence of a dust limit encourages L2 protocols to have
>> similar rules, where outputs below the dust limit are just given over as
>> fees to miners, so the existence of a dust limit might very well be
>> incentivize-compatible for miners, regardless of centralization effects or
>> not.
>>
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210827/f42a4a62/attachment.html>

2023-06-07 22:57:59

- reply

📅 Original date posted:2021-08-20
📝 Original message:On Fri, Aug 20, 2021, 06:52 Jeremy via bitcoin-dev <
bitcoin-dev at 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 limit is a per-node relay policy.
> - it is rational for miners to mine dust outputs given their cost of
> maintenance (storing the output potentially forever) is lower than their
> immediate reward in fees.
>
-Here, u r assuming miners not running full nodes, or even stateless nodes
as in Utreexo
-otherwise they suffer from storing dust UTXOS/their effect on proof
length, right?
- if txn relaying nodes censor something that a miner would mine, users
> will seek a private/direct relay to the miner and vice versa.
> - if direct relay to miner becomes popular, it is both bad for privacy and
> decentralization.
> - therefore the dust limit, should there be demand to create dust at
> prevailing mempool feerates, causes an incentive to increase network
> centralization (immediately)
>
> the tradeoff is if a short term immediate incentive to promote network
> centralization is better or worse than a long term node operator overhead.
>
>
> ///////////////////
>
> my take is that:
>
> 1) having a dust limit is worse since we'd rather not have an incentive to
> produce or roll out centralizing software, whereas not having a dust limit
> creates an mild incentive for node operators to improve utreexo
> decentralizing software.
>
Why not having dust limit improves Utreexo, I think (and tried to suggest
many times) separate storing of dust&other non spendable UTXOS (and their
hashes) so that they do not affect other UTXOS proofs ( and not brought
into main memory unless called as a TXO)
2) it's hard to quantify the magnitude of the incentives, which does matter.
>
I honestly don't get the long term perspective of miners Incentivised to
storing small dust UTXOS instead of having their values added to the fee.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210820/607a4fa6/attachment-0001.html>

2023-06-07 22:57:54

- reply

📅 Original date posted:2021-08-18
📝 Original message: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:
1-Dust UTXOS, along with burned & non-standard UTXOS, to be stored
separately in secondary storage; their Hashes in a separate Merkle too in
any accumulator design
(an earlier draft of the idea
https://bitcointalk.org/index.php?topic=5343748.new#new)
.
-In fact, the idea of separating the real UTXO values was first suggested in
https://royalsocietypublishing.org/doi/10.1098/rsos.180817
In their words
"Similarly, one can think of a two-tier data structure where a UTXO subset
containing UTXOs with a low probability of being selected such as dust is
kept on disk, while the other UTXOs are kept in memory."
.
2-I suggest also that existing dust UTXOS (from the same paper, in some
cases a UTXO could be added as an extra input with the cost of 68*fee/byte)
, to be selected with large UTXO whenever they fit in a spending ( use one
large & one small to get rid of the small)
.
3-In general when user is not willing to leave the dust to the fee, and if
there's no dust UTXOS, do not let the coin selection algorithm select the
closest match; let it choose the smallest that doesn't create dust.
For example if there's UTXOS 0.00013 & 0.00012 and user want to spend
0.0001198 choose 0.00013 so that the change is not dust (with same cost).
.
Thank you for your time,
This is the first time I send a suggestion to your emailing list, so sorry
if I missed any regulations
.
Shymaa M. Arafat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210818/05bf3a96/attachment.html>