Hi list, I’m reposting the reply below that I wrote on Dec 11. I later discovered I had accidentally emailed it directly to Greg instead of sending it to the list, and I wrongly inferred that it was being blocked. I then made public comments implying censorship, an embarrassing mistake that was entirely my own. My apologies to the moderators, Greg, and anyone misled by that. I’m participating in good faith and want to keep the focus on the technical merits. Here is the message as originally sent: Hi Greg, When you say I misunderstood your quote, are you referring to the notion that you thought we should try to shape behavior? You also said your reason for caring about motivation in the first place was because you didn't want to give the wrong impression about what was "kosher". Both you and Sipa (who also stated in that thread "The problem is that people may see this as a legitimation of the storage in the first place, and encourage doing so even more.") seemed to be primarily motivated by the social signals that would be sent by allowing even a small amount of data to be used arbitrarily in the protocol, but felt (from my reading) that it may be worth the trade-off for, as you said, shaping users to more conservative needs. I certainly appreciate your larger point here, where you state that current use has nullified previously effective means of curbing this behavior, and as you say, sometimes even further increasing it. This is precisely why my proposal exists as it does. It acknowledges that these attempts to "stop" the behavior are not effective against strong financial incentives to overcome them. They would also eventually lead to more harmful abuse; typically this filter discussion lands at the threat of fake pubkey use, which has generally been seen as the most harmful way to include data in the system. My proposal attempts to destroy trust in those markets, to reduce the desire to spam in the first place. *"Were such a proposal seriously advanced it would likely cause a new flood of transactions both to move to evade it directly and as a result of NFT indexer changes to just "wormhole" the tokens to new outputs after the fact (and a new marketing opportunity for the NFT gifters). NFTs are just an imaginary parallel world that don't depend on the network to validate their activity, so they don't really care about the network's rules, and as such the network's rules have pretty limited effect. "* I understand why you feel that way, but this is not the only way to look at it, and I'm glad we're able to have this discussion. I am not so naive about the behavior of these communities and have some experience with them in the past. You're right: every crypto asset is essentially a narrative. Where I feel you don't give me enough credit is when you dismiss that the buyers of those narratives are apathetic towards them. One of the largest debates in the ordinal world was the value that the actual numbering system should have at all. The entire point of ordinal theory is that they number and value specific satoshi as non-fungible assets themselves. To suggest that they would be content to assign a new satoshi with their key, I think, underestimates how sentimental they are about their rules. It may seem like a silly delusion, but they obviously value them or they wouldn't spend so much on them. I think this would be a very effective measure against the types of trends we are seeing today, and materially reduce the UTXO set either way. *"The proposed gain is some negligible one time reduction in utxo disk space. You motivated it by claiming this is a 'memory usage' reduction, but it's not-- it's just full node storage in particular as the txouts in question are normally sized and largely quiescent already-- so the savings is pretty insignificant. "* I have a lot to learn, because reading this is a significant challenge to my worldview. I have been under the impression that bloat to the live state (chainstate) is one of the most harmful aspects of things like the fakepubkey threat. This becomes more nuanced when we think of future implementations that don't have a separate chainstate at all, but ignoring those, one of the central reasons stated for removing the recent OP_RETURN limits was to reduce potential UTXO bloat from applications like Citrea. There are several proposals now to address this bloat, and this is the first time I'm hearing someone consider 40% of the current state to be a *negligible *amount. *"And moreover the proposal would intentionally and knowingly confiscate millions of dollars in funds. This is outright theft, and I believe it makes the idea a total non-starter."* Millions of dollars certainly seems like a lot of money, but these UTXOs are less than $1 on average. It is only due to the massive size of the stated problem that they collectively represent such a significant amount of funds. It's my contention that the users of these satoshi are not intending to use them for their satoshi value whatsoever. They are simply using these as data points tracked in a database to facilitate a gambling trend. I don't say that to judge the behavior for moral reasons, but to highlight an abuse of the incentives in the Bitcoin network. The defense against dust spam in Bitcoin is the use of a fee market. This is a very effective incentive that makes it expensive and usually pointless to create a lot of smaller UTXOs rather than a few large ones. The problem with the abuse we see from schemes like ord is that they ignore this dynamic by adding an external incentive that pays much more than the satoshi themselves are worth, sidestepping the filter and creating a dynamic that was never imagined by the design. As an open system, this kind of abuse is hard to stop once it starts. My proposal stands as a way to address it and add new dynamics that aim to reduce the demand for such behavior by understanding it and addressing it in a way specific to its creation, which is to destroy trust in the markets that cause them. I presume you would not even be okay with the potential burning of a single satoshi even if it meant clearing up something people felt was a material problem to the network, so of course you'll certainly take issue with this. It is thanks in part to your uncompromising culture that protects what Bitcoin is in the first place. *"As an aside, since the idea fails so easily on basic principled grounds it's a disrespectful waste of participants time to advance a proposal at such length and *technobabbly* depth which could have been floated with a single sentence "How would people feel about a proposal to discourage NFTs by identifying a snapshot of existing dust-value NFT outputs and making spending them consensus invalid?" or similar. Much of the opposition to LLM use in the field of BIP discussion has been due to widespread misuse of LLMs to create thickets of dense language and obscure non-starter, trivial, or ill considered proposals making them much more costly to deal with and discouraging serious and thoughtful review of *all* ongoing discussion."* This is a very fair point; in hindsight I feel my proposal was much too detailed for this stage of discussion. To be honest, I felt intimidated proposing to this list and wanted to be sure that I had put in enough work to demonstrate the seriousness of my idea. I think I could have done it with a summary that linked to additional details instead. I did not use an LLM to create my proposal, though I do use LLMs as a tool for research and occasional formatting. I do not think LLMs should be used in place of human ideas. My proposal was written by me (and the friends who helped me) in every part, and only edited for style or grammar by a machine. On Tuesday, December 30, 2025 at 9:51:56 AM UTC-5 Antoine Riard wrote: > Hi list, > > > Which brings me to my disagreement, which I know is not shared by a > number of contributors here: just as it is hard to define spam on Bitcoin, > it's also very hard to define it in a discussion forum like this one. > Making suggestions which *I* think are terrible, or detrimental, on a list > like this, should never be disallowed here. Notions of motivation of > contributors (such as they are paid by such and such a company) should not > be relevant. Everything should be open to discussion which is > implementation-technical (so obviously not e.g. threats of violence or > things that bring legal liability to participants or have zero relevance to > Bitcoin's technical development) even if it's philosophy-motivated. And > blocking should be reserved either as an anti-DOS measure if volume gets > out of control, or if it brings dangers as per the previous parenthetical. > > I'm fully sharing waxwing reasonable opinion. While I can understand > gmax's sentiment being fed > up with poor coin confiscation proposals again and again on the mailing > list, the cure would be > worst than the disease. Maybe, I'm very voltairean here, but you don't > fight ill-founded opinions. > by persecuting their authors (--otherwise, down the road you take the risk > of seeing the bastille > popped up). Rather than you fight them back by doing the work to persuade > and to convince those > ideas you find stupid are indeed *objectively* stupid. > > To me, it's a sign of strength and confidence that Bitcoin and its > development process can > withstand and endure the most "outrageous" controversies. For sure, I have > been enough times > in the shoes of someone who has to champion controversial changes (cf. > `mempoolfullrbf`) to not > negate that the strength of the process is kinda traded on the back of the > devs, but this is not > altering my mind on what I think should be *ideally* the development > process in terms of openess > and publicity. > > My humble opinion only, as we said. > > Best, > Antoine > OTS hash: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d189c5f4d776bda558e1ce > Le mercredi 24 décembre 2025 à 17:23:48 UTC, waxwing/ AdamISZ a écrit : > >> Hi Greg, list: >> >> > I think the list should adopt a 1 year ban on parties *and their* >> employer(s) (if known) for any coin confiscation proposal on the list going >> forward (after, of course, making the rule clear on the signup page). It's >> tiresome and beyond being a waste of time risks undermining public >> confidence in Bitcoin to see the constant trickle of these >> outrageous proposals in venues where they previously understood that >> serious discussions were to be had. People are, of course, free to discuss >> whatever ill-founded concepts they want but they're not entitled to the >> time and the reputation of the participants here for offensively misguided >> proposals. >> >> I'm a huge agree-er with the motivation of this comment and a huge >> disagree-er with the suggestion itself. >> >> Actual confiscation, whatever the reason, hugely undermines Bitcoin's >> value to humanity - note I am not saying its financial value, but value as >> a project (and if we didn't see such value what the hell are we doing >> here). Of course those two types of value are very closely linked, but they >> are still distinct. I hold that same belief even when we are talking about >> other suggestions of confiscation, such as to address a quantum threat - >> something that has recently been discussed here, extensively. >> >> Which brings me to my disagreement, which I know is not shared by a >> number of contributors here: just as it is hard to define spam on Bitcoin, >> it's also very hard to define it in a discussion forum like this one. >> Making suggestions which *I* think are terrible, or detrimental, on a list >> like this, should never be disallowed here. Notions of motivation of >> contributors (such as they are paid by such and such a company) should not >> be relevant. Everything should be open to discussion which is >> implementation-technical (so obviously not e.g. threats of violence or >> things that bring legal liability to participants or have zero relevance to >> Bitcoin's technical development) even if it's philosophy-motivated. And >> blocking should be reserved either as an anti-DOS measure if volume gets >> out of control, or if it brings dangers as per the previous parenthetical. >> >> Just my opinion of course, I know that moderation of lists is not a >> simple matter. >> >> Cheers, >> AdamISZ/waxwing >> On Tuesday, December 23, 2025 at 10:26:16 PM UTC-3 Greg Maxwell wrote: >> >>> The 'dust threshold' isn't a consensus parameter, it's just a number >>> pulled out of the air that didn't seem unreasonable based on average fee >>> behavior. But in any particular block transactions may need no particular >>> fee level at all, including zero fees. And in some cases it may be very >>> economically advantageous to spend an output even if its face value doesn't >>> support it, NFT's being a one such example (although one I consider pretty >>> dumb). >>> >>> This proposal also appears to have ignored the prior discussion >>> particularly where it was pointed out that 'deleting' outputs will not >>> achieve the goal of deleting the tokens connected to them (so won't >>> eliminate the incentive), or that txouts which are predictably not going to >>> be accessed (as this proposal claims applies to the txouts it targets) >>> don't have as significant performance implications (because they don't need >>> to be cached in ram). It also appears to be uninformed by advances like >>> utxotree which makes the absolute size of the txout set much less >>> important, but would make mass removals such as that described >>> here expensive. Nor has it considered that given the level of fee spending >>> on NFT traffic a requirement to keep it over some (reasonable) threshold >>> would not likely discourage it, or the fact that existent NFT outputs are >>> generally over the dust limit in any case (so the proposals failure to meet >>> the opcat proponents' delusional goals is already clear). >>> >>> I think the list should adopt a 1 year ban on parties *and their* >>> employer(s) (if known) for any coin confiscation proposal on the list going >>> forward (after, of course, making the rule clear on the signup page). It's >>> tiresome and beyond being a waste of time risks undermining public >>> confidence in Bitcoin to see the constant trickle of these >>> outrageous proposals in venues where they previously understood that >>> serious discussions were to be had. People are, of course, free to discuss >>> whatever ill-founded concepts they want but they're not entitled to the >>> time and the reputation of the participants here for offensively misguided >>> proposals. >>> >>> >>> On Tue, Dec 23, 2025 at 6:27 PM John wrote: >>> >>>> Good evening all, >>>> >>>> Here is a related proposal by Matteo Pellegrini >>>> @matteopelleg >>>> >>>> >>>> >>>> Lynx. >>>> >>>> Abstract >>>> This proposal introduces a periodic, consensus-enforced mechanism for >>>> rendering UTXOs below the network's dust threshold permanently unspendable. >>>> At each halving block, UTXOs that have remained below the dust threshold >>>> since the previous halving become unspendable. These UTXOs become >>>> unspendable and may be pruned from the UTXO set entirely, reducing node >>>> storage requirements and eliminating the economic model that incentivizes >>>> their creation. >>>> >>>> Motivation >>>> The Bitcoin UTXO set has grown substantially due to various factors, >>>> including inscription protocols, spam attacks, and general dust >>>> accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO >>>> Cleanup) by @ostrom72158 >>>> have attempted to address this by creating lists of specific UTXOs to >>>> render unspendable, identified by external protocol indexers. >>>> >>>> The Cat's approach has a fatal flaw: it relies on a list. >>>> >>>> Using a curated list of "non-monetary UTXOs" introduces several >>>> problems: >>>> >>>> 1) External dependency: The Cat requires reference indexers (Ord, >>>> Stamps, etc.) to define which UTXOs qualify. This introduces >>>> consensus-level dependency on external, non-Bitcoin software that can >>>> change, have bugs, or interpret protocols differently. >>>> >>>> 2) Protocol targeting: By specifically identifying inscription and >>>> stamp outputs, the proposal makes subjective judgments about which Bitcoin >>>> uses are legitimate. This sets a precedent for protocol-level >>>> discrimination. >>>> >>>> 3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes >>>> workarounds. If Ordinals dust is targeted, protocols will adapt to create >>>> dust that doesn't match the list criteria. >>>> >>>> 4) Static snapshot: A one-time list cleanup provides temporary relief >>>> but does nothing for future UTXO accumulation. >>>> >>>> 5) Political vulnerability: Any list-based approach requires ongoing >>>> governance decisions about what belongs on the list, creating a permanent >>>> political attack surface. >>>> >>>> A better approach targets the economic reality, not the use case. >>>> >>>> UTXOs below the dust threshold are, by definition, economically >>>> irrational to spend under normal fee conditions. The dust limit exists >>>> precisely because spending these outputs costs more in fees than the output >>>> is worth. These UTXOs are already "dead" in practice; this proposal simply >>>> makes that reality explicit at the consensus layer. >>>> >>>> By using a threshold rather than a list, Lynx: >>>> >>>> - Requires no external indexers >>>> - Makes no judgment about why a UTXO is small >>>> - Applies equally to all participants >>>> - Provides ongoing, predictable maintenance >>>> - Removes political discretion from the process >>>> >>>> Impact on Inscription Protocols >>>> >>>> The typical Ordinals inscription is stored in a UTXO containing exactly >>>> 546 sats; the minimum required to meet the dust limit for P2PKH addresses >>>> and ensure transferability across all address types. This "postage" amount >>>> is standard across inscription tooling and marketplaces. >>>> >>>> A threshold of 999 sats captures the vast majority of inscription UTXOs >>>> without requiring any protocol-specific targeting. The economic model of >>>> inscriptions depends on these dust-level UTXOs being spendable; Lynx breaks >>>> that model through neutral, threshold-based rules rather than list-based >>>> discrimination. >>>> >>>> Specification >>>> >>>> Definitions >>>> >>>> - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats >>>> is subject to Lynx enforcement. >>>> >>>> - Halving block: A block at height N * 210,000 where N ≥ 1. >>>> >>>> - Snapshot block: A halving block at which the current dust threshold >>>> and qualifying UTXOs are recorded. >>>> >>>> - Enforcement block: The halving block following a snapshot block >>>> (i.e., snapshot block + 210,000 blocks). >>>> >>>> Lynx UTXOs: >>>> - Existed at the snapshot block >>>> - Had a value less than 999 sats >>>> - Remained unspent through the enforcement period (~4 years) >>>> >>>> Consensus Rules >>>> After activation, the following rules apply: >>>> >>>> 1) Snapshot: At each halving block H, record the set of all UTXOs with >>>> value < 999 sats. >>>> >>>> 2) Enforcement: At halving block H + 210,000: >>>> - Any UTXO that was in the snapshot set and remains unspent becomes >>>> permanently unspendable >>>> - Transactions attempting to spend these UTXOs are invalid >>>> >>>> 3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their >>>> local UTXO set. Transactions referencing unknown outpoints are already >>>> rejected as invalid; pruned Lynx UTXOs are simply treated as if they were >>>> already spent. >>>> >>>> 4) Grace period: The ~4 year window between snapshot and enforcement >>>> provides ample time for holders to consolidate sub-dust UTXOs if they wish >>>> to preserve the value. >>>> >>>> Activation >>>> >>>> Activation method: TBD (Speedy Trial, BIP8, or other mechanism as >>>> determined by community consensus) >>>> >>>> Recommended first snapshot: The halving following activation lock-in >>>> >>>> Rationale >>>> >>>> Why a fixed threshold? >>>> >>>> Using a fixed threshold of 999 sats rather than referencing the dynamic >>>> relay dust limit provides: >>>> >>>> - Simplicity: One number, no script-type variations, no need to query >>>> policy settings >>>> >>>> - Predictability: Everyone knows exactly what qualifies, forever >>>> >>>> - Consensus clarity: No ambiguity about which outputs are affected. >>>> >>>> Why tie to the halving? >>>> >>>> The halving is Bitcoin's most recognized Schelling point, using it >>>> provides: >>>> >>>> - Predictability: Everyone knows exactly when halvings occur >>>> - Sufficient notice: ~4 years is generous warning for any cleanup action >>>> - Aligned incentives: As block rewards decrease, fee revenue and UTXO >>>> efficiency become more critical to network sustainability >>>> - Natural cadence: The halving already represents a moment of >>>> network-wide coordination >>>> >>>> Why not a one-time cleanup? >>>> >>>> A one-time cleanup (as proposed by The Cat) provides temporary relief >>>> but creates no ongoing pressure against dust accumulation. Periodic >>>> enforcement: >>>> >>>> - Establishes a permanent, predictable norm >>>> - Removes any expectation that dust UTXOs have indefinite longevity >>>> - Discourages business models built on dust creation >>>> - Provides continuous UTXO set maintenance >>>> >>>> Why pruning works without a list >>>> >>>> A key insight enables pruning without maintaining a separate list: >>>> Bitcoin nodes already reject transactions that reference unknown outpoints. >>>> When a node receives a transaction spending an outpoint not in its UTXO >>>> set, it rejects it as invalid — the node doesn't need to know why the >>>> outpoint is missing (spent? never existed? pruned?). >>>> >>>> After enforcement, a Lynx UTXO is functionally equivalent to a spent >>>> output. Nodes can simply delete it from the UTXO set. Any future >>>> transaction attempting to spend it will reference an outpoint the node >>>> doesn't recognize, and will be rejected through existing validation logic. >>>> >>>> This means: >>>> >>>> - No separate "Lynx list" is required >>>> - No new validation logic is needed >>>> - Pruning is optional; nodes MAY keep Lynx UTXOs if they wish >>>> - The UTXO set shrinks naturally as nodes prune >>>> >>>> Why 999 sats? >>>> >>>> The threshold of 999 sats is chosen because: >>>> >>>> - Above all dust limits: Captures UTXOs at or below the dust limit for >>>> all script types (P2PKH: 546, P2TR: 330, etc.) >>>> - Captures all standard inscriptions: Typical inscription UTXOs contain >>>> exactly 546 sats as "postage"; well under 999 >>>> - Simple and memorable: A clean number that's easy to communicate and >>>> reason about >>>> >>>> Backward Compatibility >>>> >>>> This is a soft fork. Nodes that do not upgrade will: >>>> >>>> - Continue to consider all historical transactions valid >>>> - Accept blocks that exclude spends of Lynx UTXOs >>>> - Eventually converge with upgraded nodes (as upgraded miners will not >>>> include invalid spends) >>>> >>>> Wallets & Services should: >>>> >>>> - Warn users holding sub-threshold UTXOs after a snapshot block >>>> - Provide consolidation tools during the grace period >>>> - Update UTXO selection algorithms to deprioritize or exclude >>>> sub-threshold outputs approaching a snapshot >>>> >>>> Security Considerations >>>> >>>> No confiscation >>>> >>>> This proposal does not transfer value to any party. Sub-threshold UTXOs >>>> become unspendable, similar to: >>>> >>>> - Lost private keys >>>> - Provably unspendable OP_RETURN outputs >>>> - Satoshi's untouched coinbase rewards >>>> >>>> The bitcoin supply cap remains unchanged; the affected outputs simply >>>> become irrecoverable. Holders receive ~4 years notice to consolidate if >>>> they value the sats. >>>> >>>> Lightning Network >>>> >>>> Some Lightning implementations create small HTLCs and dust outputs >>>> during channel operations. Analysis is needed to determine: >>>> >>>> - Whether current dust thresholds affect normal LN operations >>>> - If LN implementations need adjustment before activation >>>> - Whether channel close scenarios create sub-threshold outputs >>>> >>>> Preliminary assessment: LN dust limits are already set conservatively >>>> above relay dust limits, so impact should be minimal. However, this >>>> requires verification from LN implementers. >>>> >>>> Fixed threshold vs. future fee markets >>>> >>>> The 999 satoshi threshold is fixed in consensus rules and does not >>>> adjust based on fee market conditions. >>>> This is intentional: >>>> >>>> - A fixed threshold provides certainty for users and developers >>>> - If fee markets change dramatically, a future soft fork could adjust >>>> the threshold >>>> - The ~4 year grace period allows the community to observe and adapt >>>> >>>> If Bitcoin's fee market evolves such that 999 sats becomes economically >>>> significant to spend, this would indicate broader success of the network; >>>> and the community could choose to lower or eliminate the threshold through >>>> a subsequent proposal. >>>> >>>> Acknowledgments >>>> This proposal builds on the problem identification in "The Cat" >>>> (Non-monetary UTXO Cleanup) while proposing a list-free alternative >>>> mechanism. The Cat correctly identifies UTXO bloat as a problem worth >>>> solving; Lynx offers a more neutral solution. >>>> >>>> >>>> https://x.com/matteopelleg/status/2000602318346334449 >>>> On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote: >>>> >>>>> I received no prior response from you, so I suspect the issue is on >>>>> your end-- since if you sent one I would normally have been directly >>>>> copied. >>>>> >>>>> In any case, your message makes no sense. If an output is provably >>>>> unspendable then it is unspendable. No amount of "clever steganography" >>>>> can change that. If you're imagining that perhaps they are *presumed* to >>>>> be unspendable but actually *are* spendable, then sure that would be an >>>>> issue but with any change to consensus relevant code great care must be >>>>> taken to not introduce errors. Actually *making* a consensus change would >>>>> only increase the potential for mistakes. >>>>> >>>>> These costs are just another reason why this hysteria over a non-issue >>>>> is misplaced. >>>>> >>>>> But in any case it is better that (any) implementations that care >>>>> about stamps put in the effort to define their exclusions in ways that are >>>>> safe than to burden everyone with a consensus change that doesn't care >>>>> about it. >>>>> >>>>> >>>>> On Fri, Dec 19, 2025 at 1:49 AM Jonathan Voss >>>>> wrote: >>>>> >>>>>> This is my third attempt to respond to this. Idk what is going wrong >>>>>> here. >>>>>> >>>>>> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set >>>>>> without a consensus change is that a clever use of steganography could >>>>>> cause one of those otherwise unspendable outputs to be spendable, thus >>>>>> causing a fork between those nodes that adopted the Stamp pruning method >>>>>> and those that did not once one of those steganographic Stamps is spent. >>>>>> Though this is unlikely, it is still technically possible, and I would not >>>>>> put it past the denizens of the Internet to stir up trouble just for its >>>>>> own sake. >>>>>> >>>>>> On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote: >>>>>> >>>>>>> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss >>>>>>> wrote: >>>>>>> >>>>>>>> Since the Bitcoin Stamps outputs are already unspendable, it makes >>>>>>>> perfect sense to mark and drop them from the UTXO set. >>>>>>> >>>>>>> >>>>>>> There is no consensus change involved in not storing a provably >>>>>>> unspendable output, it's just an implementation detail with no >>>>>>> interoperability implications and doesn't need a BIP. Bitcoin core has >>>>>>> long done so for several types of unspendable outputs, e.g. outputs over >>>>>>> 10kb and ones starting with OP_RETURN. >>>>>>> >>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Bitcoin Development Mailing List" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>> >>>>> To view this discussion visit >>>>>> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com >>>>>> >>>>>> . >>>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to bitcoindev+...@googlegroups.com. >>>> >>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com >>>> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/521249b0-a9a8-4fc1-b975-c6c80b8ddb01n%40googlegroups.com.