Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
Good morning shymaa, > I just want to add an alarming info to this thread... > > There are at least 5.7m UTXOs≤1000 Sat (~7%), > 8.04 m ≤1$ (10%), > 13.5m ≤ 0.0001BTC (17%) > > It seems that bitInfoCharts took my enquiry seriously and added a main link > for dust analysis: > https://bitinfocharts.com/top-100-dustiest-bitcoin-addresses.html > Here, you can see just the first address contains more than 1.7m dust UTXOs > (ins-outs =1,712,706 with a few real UTXOs holding the bulk of 415 BTC) > https://bitinfocharts.com/bitcoin/address/1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ > > » > That's alarming isn't it?, is it due to the lightning networks protocol or > could be some other weird activity going on? > . I believe some blockchain tracking analysts will "dust" addresses that were spent from (give them 546 sats), in the hope that lousy wallets will use the new 546-sat UTXO from the same address but spending to a different address and combining with *other* inputs with new addresses, thus allowing them to grow their datasets about fund ownership. Indeed JoinMarket has a policy to ignore-by-default UTXOs that pay to an address it already spent from, precisely due to this (apparently common, since my JoinMarket maker got dusted a number of times already) practice. I am personally unsure of how common this is but it seems likely that you can eliminate this effect by removing outputs of exactly 546 sats to reused addresses. Regards, ZmnSCPxj ___ 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
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
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
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 >
Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn
> every lightning network transaction adds one dust UTXO Could you clarify what you mean here? What dust do lightning transactions create? I do think that UTXO set size is something that will need to be addressed at some point. I liked the idea of utreexo or some other accumulator as the ultimate solution to this problem. In the mean time, I kind of agree with Eric that outputs unlikely to be spent can easily be stored off ram and so I wouldn't expect them to really be much of an issue to keep around. 3 million utxos is only like 100MB. If software could be improved to move dust off ram, that sounds like a good win tho. On Sun, Feb 6, 2022, 13:14 Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > >> Dear Bitcoin Developers, > > > >> -When I contacted bitInfoCharts to divide the first interval of > addresses, they kindly did divided to 3 intervals. From here: > >> https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html > >> -You can see that there are more than 3.1m addresses holding ≤ 0.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.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
> On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev > wrote: > > >> Dear Bitcoin Developers, > >> -When I contacted bitInfoCharts to divide the first interval of addresses, >> they kindly did divided to 3 intervals. From here: >> 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
Re: [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, > -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 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] 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
