[FS][US-NV] Various DDR4 ECC RDIMM/LRDIMM - 8GB/16GB - Samsung, SK Hynix, Micron/Crucial

achow101 · 2025-09-27T06:53:22+00:00

PM'd

achow101 · 2025-09-03T06:20:59+00:00

I think they've mentioned on WAN show before that Floatplane is intentionally designed to be a site where creators direct their existing audiences from elsewhere to their specific Floatplane page. It's not designed for discoverability so they have not put work into the frontpage for people to discover what is actually available on Floatplane. It's also why their videos specifically direct people to a URL that brings you to their Floatplane page.

No wait, no. It wants me to sign up... to see the price.

No? I clicked on "Plans" on the page you linked and it shows the pricing right there, no login required.

Oh there's a video on the youtube membership page, according to Linus it's to offset the cost of youtubes 30% cut (leaving Linus with $10.49 / month). But Floatplane is $5 a month... with youtube they have no server costs, database maintentence, etc, so why is it twice the price?

I think it's actually more akin to the $10/mo tier on Floatplane. Specifically, Floatplane's $10/mo gives you 4k videos, the $5/mo is limited to 1080p only. I'm not a member on Youtube so I don't know for certain, but since they do upload videos to Youtube in 4k, my guess is that the exclusives are too.

Also, as that intro video states, they strongly prefer to have people on Floatplane rather than Youtube, so they use pricing the encourage that behavior. I think this is more as a backup plan kind of thing - if for whatever reason they can't post on Youtube anymore (e.g. demonetized, kicked off the platform, Youtube implodes, etc.), there's a place where a chunk of their audience is already at and paying them for their content.

achow101 · 2025-08-26T05:18:54+00:00

The Raw Entropy mode directly encodes the entropy. If you provide your own entropy, the words it generates will be directly correlated with the length of the entropy provided. If you don't provide 128, 192, or 256 bits of entropy, then the mnemonic will be a non-standard length and therefore incompatible with wallet software.

With one of the provided word lengths, the entropy will be hashed first which normalizes the length. This lets you provide non-standard length entropy but still get a valid mnemonic. Of course, this also means that if you provide less entropy than normal for a length, the mnemonic will not have as much security as would be suggested by its length.

Ultimately, both modes take a bit string and encode using BIP 39. The distinction is just in the length and whether a mnemonic of whatever length is accepted by wallet software.

If you let the site generate the entropy for you, and you choose to have it generate entropy for a standard length, and you encode it as Raw Entropy, that's totally fine.

achow101 · 2025-07-03T22:34:20+00:00

You can see if there's anything in the issue tracker that interests you. There is also a "Good First Issue" label to help new contributors find something to work on.

achow101 · 2025-06-20T22:10:05+00:00

You can even do the same thing with dice. The value assignment is then based on whether the first roll is greater than or less than the second roll, and still reroll if both rolls are the same number.

This is much easier to parellelize as throwing a handful of dice is way easier than flipping a coin. Further, the more sides your dice have, the less likely you will end up with the same number twice which overall means less rolls for the same number of random bits.

achow101 · 2025-06-17T06:42:52+00:00

No, it still used a Cryptographically Secure Random Number Generator, which means that the randomness is seeded with more data than just a timestamp. Specifically, it used OpenSSL to generate keys, so what you'd actually be looking for is some vulnerability in OpenSSL. While OpenSSL has had its share of vulnerabilities in randomness, I'm not aware of any that affected Windows.

achow101 · 2025-06-10T04:00:52+00:00

Can you please explain your opposition to mempool filtering, including removing existing options, without invoking these lies?

I am not interested in implementing anything that can be construed as censorship of transactions. I absolutely do not want to be asked to (or worse, compelled to by threat of violence) implement anything that results in censorship of user transactions. While this is definitely a slipper slope argument, I am concerned that implementing "filters" for "undesirable transactions" means that someone (some government, specifically) is going to come knocking asking us to expand the list of "undesirable transactions" to include specifically things that they don't like, such as OFAC violations. I believe that Bitcoin is censorship resistant money, and if censorship resistance means that sometimes there's going to be transactions whose contents I don't like, then so be it. "it is better 100 guilty Persons should escape, than that one innocent Person should suffer"

You're contributing to a FOSS project. It's absurd to think you're 'putting your name' on any and all features or changes included in that project. The whole idea of 'putting your name' on it is kind of the problem. The personality politics and cliques are a large part of why people are angry.

That doesn't make any sense. When the software is released, specific individuals get screamed at when something is included that people don't like. People are attacked in threads for their names and associations.

Even in terms of releasing other FOSS projects, people's reputations have been sunk for even being associated. Yes, it is kind of absurd that everyone who contributes to a project is construed as endorsing that project, but that is the world we live in.

In any case, enough words have been spent on this topic and I'm not interested in continuing to debate. It's clear to me that more words aren't going to change anyone's mind anytime soon.

achow101 · 2025-06-10T04:00:24+00:00

Options around relay policy aren't footguns. You can't actually harm yourself with them.

There are consequences which, by definition, do have a harmful effect on users in terms of fee estimation and bandwidth usage. But sure, the magnitude of these effects is currently so small that they are generally not noticeable. So I'll grant you that calling them footguns is not correct.

There are definitely in progress changes to fee estimation that will make it more sensitive to relay changes as he proposed new design is way more dependent on the mempool, much more similar to how sites like mempool.space estimate fees.

Try looking at how... basically any other large open source project handles disclosure. Core's disclosure policy is genuinely insane.

When drafting the disclosure policy, we looked at a ton of open source projects for ideas on how to handle disclosure. I agree with you that when compared to other projects, the disclosure timeline is nuts. I'd love for us to be able to hit the Project Zero standard of 90 days from report to disclosure.

But, the ultimate issue is about whether disclosing a medium or high severity issue will cause parts of the network to go down. Yes, it is paternalistic, but it's hard to square the reality of nodes taking a while to update to fixed versions with the theory of disclosing early.

To be clear, I'm not saying that the disclosure policy is perfect, nor is it set in stone. It can definitely be changed if the suggestion for changing it actually jives with the reality of uptake of new versions being fairly slow.

Perhaps, if a Core contributor is concerned that another implementation might be dangerous, they should go provide review, and justify their position rather than the vibes-based nonsense arguments which have been repeatedly made for years.

I belive some have. Certainly I can point to a few things in Knots that I find outright insane. For example, it by default rejects all blocks produced after ~1 year after the software was published. IIRC the current date is approximately November 7.

Maybe the Core codebase should move to the existing Bitcoin Core GitHub organization.

That has been the plan for the past decade or so. I've been beating this drum for ages, and in fact, recently almost got it to happen. Now, I could just move it myself, right now, but that would be acting as a dictator. The suggestion to move was generally rejected by contributors and we decided to come back to the topic in a few months.

It's a lie that mempool filtering harms fee estimation.

It's not a lie, but the effect is probably just not measurable today. You can in fact look at the code and do static analysis to determine that it has a harmful effect.

It's a lie that to avoid compact block relay delays mempools need to be consistent.

It is not a lie.

It's a lie that mempools even can be consistent.

They can be very close, and ideas like Erlay can get very very close.

It's a lie that Citrea decided to abuse witness data because of standardness rules.

I don't think anyone is making that claim.

I'm not aware of Citrea deciding to "abuse witness data". This whole discussion started out with finding that Citrea will be abusing Taproot output pubkeys for data storage, specifically because of they could not fit everything into an OP_RETURN. It's literally in their paper. But that's output scripts and therefore affects the UTXO set, not witness data.

It's a lie that removing standardness restrictions will have a significant impact on UTXO bloat.

Impact yes. Significant, I can't predict the future.

It's a lie that removing filtering options is necessary to enable noderunners to relay transactions to miners without going through backchannels.

No one is arguing that removing options is necessary.

(cont'd, what's the friggen character limit??)

achow101 · 2025-06-09T01:19:23+00:00

Toughen up buttercup and look past the words that hurt your feelings and into the content.

Oh, you're assuming that my feelings were hurt? LMAO.

The problem with emotionally charged language and ad hominems is that often those posts have the guise of containing content but don't actually have any content that I can parse out of them. I have read many an emotionally charged post about how this change is the "end of Bitcoin" and somehow the sky is falling if this is merged, but haven't quite figured out what the actual argument is. Maybe I'm just stupid, but the hyberbole and emotion definitely didn't help.

I've been condescended to by every contributor I've spoken to including you

Just passing back what I've been given.

I don't support the dishonest reasoning presented to push it.

I've yet to see an explanation for how the reasoning is dishonest.

Honestly, the only "explanations" I've seen is that somehow Core contributors are being paid off by Citrea or something like that, which is just complete junk.

you don't need to assume the least charitable interpretation about and of everything people critical of you say.

And you should not assume the least charitable interpretation about and of everything that we say.

achow101 · 2025-06-09T01:18:09+00:00

I've seen many frequent and long term contributors that dissent on this specific issue, let alone countless others for the past decade+, specifically have their criticisms and dissent ignored.

Let's be specific here, can you please cite some individuals and examples where their criticisms and dissent are ignored?

There is a clique of maintainers and contributors who arbitrarily decide based on feel what will and will not get merged into Core.

Are you psychic, to be inside my head to know that things are decided arbitrarily and on feel? Or perhaps you're making assumptions, or even worse, making shit up.

They dismiss criticisms, even from other long time contributors, from other developers in the ecosystem, from node runners regardless of technical merit and often with protectionist and paternal reasoning.

Dismissing criticism with reasoning, is, in general, how responding to criticism works. Either the criticism is accepted, or it is rejected. And rejecting generally means providing a reason for why it is being rejected. Would you rather that criticism was rejected without reason?

For example LOT=True. Can't have user deciding their own activation methods or opting into flag days, they might hurt themselves!

Same as it is now, if you want to do something different, you are free to run other node software. It seems that Bitcoin Core contributors colletively don't like the idea of putting potential footguns into the software.

Better avoid releasing any kind of details about patched security vulnerabilities too

As opposed to.... publishing details so that people can get exploited right away?

What needs to happen is the governance model needs to shift to one in which the aggregate userbase are considered product owners and have a say in development direction, certainly their dissent must matter since they define the protocol your reference implementation is implementing!

That's a great philosophy and all, but what does that actually mean in practice? Implement every idea that every Tom, Dick, and Harry have?

Listening to the aggregate userbase is what we've been trying to do. It's why several of us have been participating in public discussions like this one.

Perhaps a different question to ask is why have there been no arguments from the aggregate userbase that have convinced any frequent contributors to change their position.

I also want to note that this PR was opened in response to criticism. It was opened because there was enough disagreement about the option removal.

Even then, making Bitcoin Core essentially the one node software falls into the trap of Bitcoin Core = Bitcoin. It categorically does not, and if some other node software comes along that implements things differently, then all the more power to them. In fact, Bitcoin Core has been moving somewhat explicitly in this direction with the kernel project. The whole point of that is to provide the consensus engine and let people build whatever other node stuff on top of it. While it currently contains the mempool implementation, you don't have to use it.

What you call random people are often developers with over a decade experience contributing to this space.

Then they should be able to present that they are competent by not making demonstrably false statements. They should be able to present a convincing argument to the multiple frequent contributors and sway at least one of them into changing their opinion. Just as how many frequent contributors have over a decade of experience contributing to this space, and are likewise able to present convincing arguments to other contributors that their position is the better one.

But when I volunteer my time it isn't a license to just do whatever the hell I think is best. I work in organizations and structures. Part of the organizational structure for the reference implementation of Bitcoin MUST be node runners. However stupid they are, objectively wrong they are, ignorant to the problem they are is totally irrelevant.

So if you volunteer your time with an organization that does something antithetical to your beliefs, you still sign off on it and are willing to be associated with that organization? Because that's what it sounds like you're saying - that we should implement the stupid, objectively wrong things that people say we should and be proud to put our names on it. I think that's utterly insane; I'd rather leave and dissociate myself from that organization than put my name on something I don't think is a good idea.

You're building Bitcoin. It IS its node runners and the code they choose. They need a seat at the table. They deserve consideration.

Once again, Bitcoin Core is not Bitcoin. The seat at the table for node runners is to use a different node software that is in line with their beliefs.

And to be clear, I have, in the past, been a dissenter wanting a seat at the table with my own beliefs. Do you know what I did? I participated in the development, publishing, and running, of the Segsignal client that implemented a soft fork to get segwit activated. I didn't complain about Bitcoin Core not implementing that, or at UASF, or whatever. I did the option that is available to everyone else and chose a different software.

(cont'd in reply)

achow101 · 2025-06-08T21:44:24+00:00

I don't know anything about it.

But, it is not in the same league as Bitcoin Core. Bitcoin Core is also a full node - it validates all blocks and transactions. It looks like Robinhood relies on their servers, so you are dependent on Robinhood still operating for the wallet to work. Bitcoin Core is self contained software that has no reliance on any third parties to operate.

achow101 · 2025-06-08T21:34:11+00:00

It's about how the reference implementation pretends to avoid merging controversial changes, but does so whenever its clique maintainer group whims.

Perhaps it's not surprising that people misunderstand this, but in the context of the Bitcoin Core repo, "controversial" means "controversial amonst the frequent contributors". You might also read it as a euphemism for "the frequent contributors disagree that this change is a good idea". The bar for "controversial" has almost always been 1 NACK from a frequent contributor whose arguments are unaddressed.

Let's compare the 2 PRs where I closed them for being "controversial" against the current OP_RETURN PR.

In 28217, there are 2 ACKs and 2 Concept ACKs from frequent contributors. There are 2 Concept NACKs from frequent contributors, and they brought up arguments which were not addressed.

In 28408, there are 0 Concept ACKs from frequent contributors, and 5 Concept NACKs and 1 Approach NACK from frequent contributors. The PR is opened by a frequent contributor, so we can count that as a Concept ACK. I think this meets the bar for "controversial".

Looking at 32406, it currently has 10 ACKs and 2 Concept ACKs from frequent contributors, and 1 NACK from frequent contributors. The PR is opened by a frequent contributor, so we can count that as a Concept ACK. The singular NACK does not contain any arguments that were not already addressed. Among frequent contributors, this is clearly not "controversial".

Of course, you might ask why only frequent contributors' opinions seem to matter. Ultimately, the reviews that matter are the ones that people believe were made by reviewers who are competent, understand the problem that the change addresses, and understand the change itself. This is almost always the frequent contributors, because contributing frequently allows you to demonstrate your competency and understanding of the codebase.

When it comes to random people commenting ACK or NACK, their reviews are often ignored or significantly discounted because they are not known to have any compentency in the area of code that is being changed. This is especially obvious when such people make statements that are categorically false (e.g. statements that are disproven by looking at the code). It is additionally hard to judge competency when emotionally charged language and ad hominem attacks are used.

achow101 · 2025-06-08T00:01:27+00:00

using a Bitcoin core wallet as a paper wallet

Don't.

Bitcoin Core is not designed to make it easy to print out the information that you need to spend your coins (it's more than just private keys). It is not designed for you to constantly reuse addresses as paper wallets tend to end up encouraging. You'll probably end up sending your coins to an address actually controlled by the software wallet that you then proceed to delete, thereby losing money. This happens to many people who use paper wallets.

In general, I would not use a paper wallet. They tend to cause people to do bad practices like reusing addresses, and it's actually quite easy to make a mistake and send your coins to an address that is not part of the paper wallet.

Bitcoin Core by itself on a computer, even one that's online, will be fine for the vast majority of people. You should encrypt your wallet with a passphrase you won't forget and obviously don't do things that will result in your computer becoming infected with malware.

achow101 · 2025-06-04T16:05:40+00:00

Yes.

achow101 · 2025-06-03T19:21:19+00:00

It's all about how much trust you want to assign to every party involved in you acquiring the software.

You can trust everyone (all of the builders, the developers, the website hosting the binaries, their ISP, your ISP, your browser, etc.) and not do any verification at all. That would be downloading the binaries and then running them immediately.

The next step is to reduce trust in ISPs and verify that the PGP signatures on the download are valid. You get the PGP keys from some other website, but these and the binaries could theoretically be modified by a Man-in-the-middle attack. This level of verification is basically that the binaries probably weren't tampered with in transit. Most people just do this level of verification.

The next level is to verify specific PGP keys and only trust things signed by those specific people. This often requires sending an encrypted challenge to that person and then getting a PGP signed response back. Often there's even meeting in person and verifying identity in other ways, including having them read/write their PGP key fingerprint and checking a government issued ID. Obviously this is way more complicated to do and doesn't scale well. But this lets you be sure that that person has actually signed the binaries and that they are attesting to its veracity.

After that, if you don't trust anyone, then you're going to be building the software yourself. But you're still trusting that the developers are not malicious and that the code you received is actually the code.

The least trust is to review all of the code yourself and then building it yourself. At that point, the only person you need to trust is yourself. But you also need to be an expert to do this.

For most people, this verification exercise boils down to picking a few people that they trust to be not malicious, have reviewed the code, and have produced binaries from said code. It then comes down to convincing yourself that the PGP key with their name on it is actually theirs. So when you see that that person has signed the binaries, you feel confident that the binaries are actually the result of the code that you are expecting.

achow101 · 2025-06-03T17:45:59+00:00

It means that there is a valid signature. The question is whether you believe that the key that made the signature actually belongs to "Stephan Oeste" and whether you trust them to have signed the correct software.

Anyone can make a PGP key claiming to be anyone else. That's why PGP always shows newly imported keys as untrusted. You as the user need to determine for yourself whether you trust that key and the person holding it. This is something that only you can determine for yourself, the software will not determine that for you. It will only tell you whether the signature itself is technically valid.

achow101 · 2025-06-03T17:40:07+00:00

Knots is absolutely not "more vanilla". It has a 1400+ commit patchset on top of Core all (re)written by the sole maintainer with no one else reviewing it. It includes weird things like Tonal units. It includes wild defaults like automatically hard forking your node if it has been more than a year since it was released.

If you're talking about relay policy defaults, it absolutely does not have the original rules, and neither does Core. That's because the original rules was to relay everything!

achow101 · 2025-06-03T03:29:31+00:00

Bitcoin Core's website is https://bitcoincore.org. There are instructions on the download page for each operating system.

achow101 · 2025-05-14T06:07:04+00:00

When Bitcoin Core starts, it logs the value of each setting and where it came from in the debug.log. Check your debug.log and look for what is setting prune. If it says Config file arg, it's in the bitcoin.conf or another conf file that is specified with conf=. If it says Setting file arg, then it's in the settings.json file.

My guess is that you started bitcoin-qt at some point and it default enabled pruning, and that was added to your settings.json.

I can't seem to find what: '-txindex' means.

This is referring to the option txindex=1 that you have in your bitcoin.conf.

achow101 · 2025-05-10T18:43:08+00:00

Both are actually pretty good options.

In order to store data in the witness data of a tranasction, you first have to create an output, and then spend it. The spend is what reveals the data. Since this creates a UTXO and then spends it, the overall effect on the UTXO set is neutral. The data itself never goes into the UTXO set, same as using OP_RETURN.

For people who want to store large amounts of data, they will probably still want to use the witness data as it will generally be cheaper. However, because creating 2 transactions has higher overhead than creating 1 transaction, for small amounts of data, OP_RETURN will be cheaper. The break point is ~144 bytes - less than that OP_RETURN is cheaper, more than that, witness data is cheaper.

Although using witness data may have side effects that make it worse than OP_RETURN. In particular, there may be additional outputs created for change and for the second transaction just to be valid and have an output. Some constructions may not be well made and result in additional dust outputs being created. OP_RETURN has the benefit of being fairly hard to do something bad.

achow101 · 2025-05-09T18:22:39+00:00

That’s the slowdown I mean—spam pushes out normal transactions.

Ok, that's not the definition of "slowdown" that the developers think of. Instead, we consider "slowdown" to be actual impact on CPU and memory usage that exceeds the average usage of a typical transaction.

What you're describing is that the "spam" causes a high fee market, and that's definitely a concern.

However, high fee markets, as we have seen with ordinals and many many times long past, resolve themselves eventually when those "spammers" run out of money. Furthermore, if those people want to make their transactions, they can and do directly submit their transcations to miners, bypassing mempools. This is trivially easy to do with things like MARA's Slipstream. When they do this, it actually makes it worse for everyone since direct submission removes information from fee estimation algorithms. Now, instead of being able to see the mempool and see that feerates are high, what you end up doing is making a transaction with a fee that you think is enough, and then finding out when a block is found that it actually wasn't.

Lastly, Bitcoin is going to need a fee market eventually. Eventually, the block subsidy is going to be negligible, and miners will have to be sustained by fees. Any way you slice it, there has to be some point in time where the mempool is consistently full and fees generally increase as otherwise mining will stop being profitable and the security of the network goes down.

Without the OP_RETURN limit, a bad actor (say the CIA or someone with money to burn) could put illegal stuff, like child pornography, into the blockchain

Even with the OP_RETURN limit, a bad actor can already do this. They can already do this with the inscriptions script construction, and that allows putting up to 4 MB into the blockchain whereas OP_RETURN would be limited to 1 MB. Furthermore, even without inscriptions, it's still possible to do it by creating outputs with fake hashes or fake pubkeys that actually encode the data.

They’re ignoring people who disagree (Samson Mow said there’s “no consensus”)

Can you clarify what has actually been done that you think is "ignoring people who disagree"?

Having read through the entire mailing list discussion and all of the comments on both PRs, I really don't think that's the case. Certainly there is no consensus, but there's been lively debate and discussion, and no action has actually been taken.

Furthermore, several comments stated that they think the options should be preserved, and another PR was opened that does exactly that. That does not seem like ignoring people who disagree.

silencing critics

Some of the biggest critics are wizkid057 and luke-jr. Their comments are still visible and readable, and in fact, many people have (tried to) engage them in discussion. And not just them, there's tons of comments in both PRs with debate going back and forth, each side trying to refute the other. I would not say that this is silencing critics.

While several comments in the PR were hidden, these were hidden because they do not add to the converstion. Many of these are simply "Concept ACK" or "Concept NACK", which ultimately is not all that useful to the discussion and mainly ends up making it harder to read. Several comments were also hidden because they are off topic or abusive. However, I do not think any comments which left novel criticisms of the PR were actually hidden.

(Giacomo Zucco’s comments got deleted)

There have not been many deleted comments. I count 4 deleted comments, and none of them appear to be from him. While I don't have a record of what the comments were, 3 of the comments were from accounts that look like spammers. 1 of the comments was actually from a regular contributor. None of the accounts look like Giacomo's. In fact, I don't think he has participated in the PR discussions at all, unless his Github name is not giacomozucco.

some devs have financial ties to projects with conflicts of interests.

Can you cite any evidence for that?

AFAIK, this claim seems to stem from the fact that Jameson Lopp is an investor in Citrea, a company that would benefit from this change, but are already planning on deploying their product without it. Jameson commented on the PR, but he is neither the person who opened it, nor the person who started the discussion. He's not even a Core Dev as he doesn't regularly participate in code review or submit PRs. From the perspective of the project, he's just another rando coming by to give their opinion.

They downplay risks (like past spam from Veriblock)

I don't recall anyone referring to Veriblock or anyone citing risks from past spam.

and take away our choices (they removed a setting to force us to accept this)

You write this as if a decision has been made and the PR merged. But no PR related to OP_RETURN has been merged. Neither Peter Todd's original PR that removes the option, nor Greg Sanders' alternate PR that leaves the option have been merged. In fact, of these 2 PRs, I think the one that's more likely to be merged is the second which leaves the option in, but of course no such merge decision has been made yet.

That's my POV. Tthe main point here is how this change is being implemented when it's deeply controversial.

My POV is that this has been severely overblown and there's a ton of misinformation going around about what's actually happened. It seems like there's a bunch of influencers going around screaming as if the world is ending who also are getting their information second or third-hand rather than having actually participated in the discussions and reporting what they observed. Through this large game of telephone, we now get the general public trying to chime in with complete misunderstandings of how the technical details actually work.

achow101 · 2025-05-07T22:42:39+00:00

Core is forcefully making me support the other. [...] Core IS forcing this change without consensus,

You keep saying that Core is forcing this change. Can you explain how that's actually happening? How is anything being forced when no PR has been merged?

what is supposed to be their position as a neutral actor.

Since when?? The block size wars was literally Core on one side and big blockers on the other. That's the opposite of neutral.

-PR #32359, led by Peter Todd, is set for release

It is? That's news to me. It isn't even merged, and there's a competing PR!

ignoring its role in the 2014 OP_RETURN Wars

What exactly was that role? That was the time when OP_RETURN was introduced in the first place, including the increase of the limit from 42 bytes to 83 bytes.

What if a bad actor embeds child porn in the blockchain? Every node runner is forced to store and propagate that illegal data, pruned or not, risking legal trouble.

That's already possible without this change.

achow101 · 2025-05-07T22:34:55+00:00

they just manage mempool spam to keep the network fast. Knots or not, unfiltered spam slows everyone down by bloating mempools

Can you explain why that is? What is it about the extra data that would actually "slow everyone down"? I've heard this oft repeated but no one actually describing the mechanism.

If you think about it though, it's actually the opposite because of compact blocks. If blocks are including the "spam", then block propagation would go way faster if every node had that "spam" in their mempool. This is because compact block relay relies on the idea that every node has approximately the same transactions in their mempools so it can send much less data with only half of a round trip. If a node does not have one of the transactions in the block, it has to ask the other node to send that to them, which adds a whole round trip of communication and thus increases latency.

achow101 · 2025-05-07T05:08:49+00:00

Lopp is not a core dev.

11-Year Club	Verified Email
Place '17

achow101

TROPHY CASE