Re: [bitcoin-dev] BIP proposal: Fee-redistribution contracts
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@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 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 environme
Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
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 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 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.01 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
Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
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.01 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.linuxfoundatio
[bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
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.01 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/14oLvT2 https://blockchair.com/bitcoin/address/1CounterpartyXXXUWLpVr 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Take 2: Removing the Dust Limit
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
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 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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
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@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@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] Storing the Merkle Tree in a compact way
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
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@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@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@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
Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
On Fri, Aug 20, 2021, 06:52 Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > one interesting point that came up at the bitdevs in austin today that > favors remove that i believe is new to this discussion (it was new to me): > > the argument can be reduced to: > > - dust 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@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
Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
