"Quasi-consensus": help me understand this conversation with Chris Guida \ stacker news ~bitcoin

pull down to refresh

"Quasi-consensus": help me understand this conversation with Chris Guida

1197 sats \ 63 comments \ @Scoresby 23 Oct bitcoin

Earlier today, Stephan Livera responded to a post by Nick Szabo and said

To which Chris Guida (I thought he was on SN, but I couldn't find his profile) responded

Now, this is something that kinda gets to me. I don't like the claim that the "network never consented to this" and frankly, I think such statements fundamentally misunderstand Bitcoin. If you hadn't consented to the consensus rules of the network, you wouldn't have considered the coins as a payment.

I seldom argue with people on X, but

Chris replied with something that is even more silly than claiming you didn't consent to rules the coins had on the package

I therefore took issue with the term

But apparently I was unclear because

And I attempted to clarify

Yay, we agree! ...oh.

So we go back to the drawing board

But Chris continues to abide in the land of "quasi-consensus"

Further clarification is required

Chris tries a defensive maneuver

I still dislike "quasi-consensus"

At which point Chris seemed to grow tired of our conversation

This is something that has irked me about the spam debate from the very beginning: Bitcoin is a system designed to make sure any consensus valid transaction can get mined even if other people (or powerful actors such as states) try to prevent it.

If relay policy is effective at preventing consensus valid transactions from being mined then we are all very wrong about what Bitcoin does and how well it delivers on its value proposition.

If consensus valid transactions that do things we don't like can be prevented from reaching blocks as long as "enough true Bitcoiners" run "good relay policies," then the whole proof of work, consensus system is kinda pointless.

Relay policies, at best, encourage people to shape their transactions in certain ways, but if people want to shape them some other way (as long as it is still consensus valid) Bitcoin is designed to help them get their transactions into blocks.

view all related items

102 sats \ 39 replies \ @Undisciplined 23 Oct

"Zero imagination"? Has he seen your posters?

As an academic, confusing jargon is par for the course. Oftentimes technical terms, like "consensus", also have more colloquial uses. I get what he's trying to do by saying there's been a sort of social agreement around this mempool policy.

I hadn't thought about this in the way you lay it out: i.e. the tension between censorship resistance as a feature and spam resistance as a capacity. I don't think there's a contradiction, though. It is still possible to make a consensus valid transaction, even if filters aren't transmitting most transactions of that type.

I don't see why the network has to make all consensus valid transactions easy or cheap. They just need to be possible. It's fine for the users of the network, acting in aggregate, to make certain types of transactions difficult or expensive.

144 sats \ 27 replies \ @ek 23 Oct

It's fine for the users of the network, acting in aggregate, to make certain types of transactions difficult or expensive.

Is it also fine if a nation state does that as a “user of the network”? They can spin up as many “users of the network” as they want.

166 sats \ 1 reply \ @Scoresby OP 23 Oct

as far as my node is concerned, it is very difficult to tell the difference between a node and bot.

I once brought this up to Mechanic and he said it would be trivial to notice a government spinning up a large quantity of nodes.

and when I asked how he knew that this hadn't already happened, he stopped talking to me, like Chris.

0 sats \ 0 replies \ @gregtonoski 22h

So, have you found out yourself or just posted your story to mock a person?

0 sats \ 24 replies \ @Undisciplined 23 Oct

No, but that's not because of how they're using the network. It's because they shouldn't exist in the first place.

Does spinning up tons of nodes reduce the ability of existing nodes to broadcast to miners? I'm not sure why it would, at least not to a significant extent.

Let's say that literally every person who runs a node voluntarily opted for a mempool policy that doesn't transmit certain consensus valid transactions. Why am I supposed to care that this is possible?

42 sats \ 11 replies \ @ek 23 Oct

Does spinning up tons of nodes reduce the ability of existing nodes to broadcast to miners?

Yes, if they are maliciously used to eclipse nodes.

0 sats \ 10 replies \ @Undisciplined 23 Oct

isolated from all honest peers but remains connected to at least one malicious peer

That seems like a pretty extreme condition, and doesn't seem like something that would come about simply by spinning up a bunch of nodes. They'd also have to prevent connections to any honest peer.

42 sats \ 9 replies \ @ek 23 Oct

doesn't seem like something that would come about simply by spinning up a bunch of nodes

Your node connects to random peers. If most peers are malicious, the chance is higher that all of your 8 outbound connections (default) will be consumed by only malicious peers.

They'd also have to prevent connections to any honest peer.

You don’t know who is a honest peer or not.

0 sats \ 8 replies \ @Undisciplined 23 Oct

Sure, but why am I only connecting to these newly spun up malicious peers?

Are you talking about long-term dynamics or immediate impact of spinning up a ton of nodes? I was thinking about the latter.

42 sats \ 7 replies \ @ek 23 Oct

Do you know if your peers are malicious or not before you connect to them?

view all 7 replies

42 sats \ 11 replies \ @Scoresby OP 23 Oct

Let's say that literally every person who runs a node voluntarily opted for a mempool policy that doesn't transmit certain consensus valid transactions.

I suspect new ways of reaching miners would emerge.

If not, why wouldn't this aligned group of node runners just use their mempool polices to determine the block validation rules (I think this is a better term for consensus rules, courtesy of #1263085) of Bitcoin?

Does spinning up tons of nodes reduce the ability of existing nodes to broadcast to miners? I'm not sure why it would, at least not to a significant extent.

Isn't this your contention from earlier? (#1262882)

It's fine for the users of the network, acting in aggregate, to make certain types of transactions difficult or expensive.

How could users of the network make certain types of valid transactions difficult or expensive except by impinging on the ability to nodes that disagree with them via having many many more nodes?

Personally, I don't believe the relay network is an effective way to increase the costs of getting a valid transaction confirmed. Possibly it achieves this effect in the very short term, but the incentives are such that it will quickly get routed around.

102 sats \ 10 replies \ @Undisciplined 23 Oct

Isn't this your contention from earlier?

No. Or, it wasn't my intention to make that contention.

I suspect new ways of reaching miners would emerge.

As do I, but I chose an intentionally extreme example to help articulate my thoughts.

How could users of the network make certain types of valid transactions difficult or expensive except by impinging on the ability to nodes that disagree with them via having many many more nodes?

Maybe it's been answered in the other comments, but number of nodes doesn't seem like the driving factor. It's about paths to successful miners, which will typically be related to number of nodes, but might not be in some extreme cases.

42 sats \ 9 replies \ @Scoresby OP 23 Oct

we are mostly in agreement.

I know that there has been a lot of work done on the p2p network part of bitcoin software. In general, I believe this has been aimed at making it difficult to eclipse a particular node or prevent a node form learning about new blocks.

I brought up the number of nodes ("many many more nodes") because it's the only thing I've heard put forward as a reason that filtering is useful at all. I, too, disagree that numerical eclipse is ineffective, but I've never heard anyone provide another reason why running filters is important.

102 sats \ 8 replies \ @Undisciplined 23 Oct

If filters don't work (and I'm not arguing that they do), why is there such a stark cutoff at the old OP_RETURN limit?

This is why I was bringing up the case of everyone on the network opting for a particular policy. As I understand it, basically all nodes had the same policy in that regard and we hardly ever saw transactions that didn't conform to it.

42 sats \ 7 replies \ @Scoresby OP 23 Oct

This was a point Chris brought up and that I did not respond to.

I'd sat that chart he presented showing a clear absence of OP_RETURNs is evidence that there really hasn't been much economic demand for op returns that are bigger.

As I understand it, basically all nodes had the same policy in that regard and we hardly ever saw transactions that didn't conform to it.

Mempool policy can nudge one way or the other, but I believe it is very gentle and as soon as there is any kind of sustained demand for transactions that go against policy, it will quickly crumble.

view all 7 replies

143 sats \ 10 replies \ @Scoresby OP 23 Oct

It's fine for the users of the network, acting in aggregate, to make certain types of transactions difficult or expensive.

If this is possible, then Bitcoin really is ineffective at the only thing it does: censorship resistance.

Nodes can be spun up without any real proof of work. I can run several nodes on my computer. If the relay policies enacted by these nodes can effect the difficulty of getting transactions confirmed, what's the point of proof of work?

The reason we don't assign every node a number and then randomly pick a number and have that node sign a new block is that nodes can be easily created. If Bitcoin relied on such a system, whoever had the most AWS servers would control the network. We use proof of work because it prevents such a dynamic.

Relay policies aren't part of consensus and therefore no different than a jurisdiction passing a law saying "don't do these kind of transactions" -- neither should be effective at preventing consensus valid transactions from getting confirmed.

102 sats \ 9 replies \ @Undisciplined 23 Oct

You’ve written about how being an economic node is what matters.

How can that be true without implying any shared policies amongst those nodes are impactful?

We still have censorship resistance because there’s no stopping someone from mining their own blocks, right?

142 sats \ 5 replies \ @Scoresby OP 23 Oct

As far as relay policies go, a node's economic weight doesn't matter.

Think about it this way: a node can relay transactions even if it's never been used to verify coins in any particular wallet. A node can refuse to relay transactions even if all it has ever done is download and verify the chain. In fact the "amount" of relaying a node does is the same no matter how it is used. It either relays a transaction or it doesn't.

When people (also including me) talk about economic nodes, they mean that you are using your node to say: "Yes, these coins I accept follow the consensus rules of bitcoin. I will accept them." An economic node with a lot of weight is able to say this about a lot of coins.

The reason relay policy is different is that you and I can have completely different relay policies and still agree on the state of the chain. This is not the case of consensus rules.

A big economic node will still have to accept as valid a block that includes transactions it refused to relay (transactions that it filtered or that it never allowed in it's mempool in the first place).

I suppose the economic node could refuse to accept any block that had transactions it didn't like, but if that was the case, the node would effectively be creating new consensus rules...and it would need to be sure that at least 51% of the hashrate followed the same rules.

102 sats \ 4 replies \ @Undisciplined 23 Oct

Thanks for straightening me out there. Economic node isn't the right term for this.

Still, if your transaction has some feature that goes against the mempool policy of every single miner, there's no way that transaction is going through. Spinning up nodes on AWS that will store and relay your transaction obviously wouldn't help with that.

On the flip side, if your transaction conforms to the policies of miners then it will go through, regardless of how many AWS nodes are spun up that would reject it.

It's about connectedness to successful miners. The censorship resistance comes from how difficult it is to block the path to miners and from having free entry into mining.

42 sats \ 3 replies \ @Scoresby OP 23 Oct

if your transaction conforms to the policies of miners

yes! but this is the same as saying "if your transaction is a transaction a miner wants to mine", the mempool policy part is unimportant.

And this was the point I was trying to get to: in the case where many or almost half of all miners don't like your transaction, Bitcoin is designed to incentivize new miners to enter the game or current miners to change their mind. That's what's so great about it!

The censorship resistance comes from how difficult it is to block the path to miners and from having free entry into mining.

I believe my position is that only the latter matters. Free entry into mining is the important part.

Mempool policies really have very little to do with it. Due to the nature of electronic communication, it's pretty easy to get to a miner who is interested in mining your transaction (although how might look very different from a relay network run y nodes).

102 sats \ 2 replies \ @Undisciplined 23 Oct

If it were easy to block someone's path to a miner, you wouldn't consider that a censorship issue?

42 sats \ 1 reply \ @Scoresby OP 23 Oct

I don't think it is possible to make it difficult.

If it was, then this would be a major vulnerability to bitcoin, and many of our previous assumptions about its usefulness would be in serious trouble.

see your point: #1263232

view all 1 replies

144 sats \ 2 replies \ @ek 23 Oct

We still have censorship resistance because there’s no stopping someone from mining their own blocks, right?

No, see #1222210:

Sure, it only takes one block, but if everybody else can get into each block while I can only get into one block a year, I would consider myself censored, not very unlike a bank closing my account.

In reality, if you’re really mining your own tx, it’s more like never though.

Bitcoin’s censorship resistance relies on miners acting in their own interest, not that everyone is mining their own tx, that would be ridiculous.

Chris Guida & Co. are suggesting miners to not be selfish, see debate in the linked post.

This is absolutely crazy to me.

You should really watch the debate.

42 sats \ 1 reply \ @ek 23 Oct

edit timer ran out

that would be ridiculous

Because getting a single confirmation on your tx would be like winning the lottery

0 sats \ 0 replies \ @Undisciplined 23 Oct

I get that. I articulated my thoughts better here #1263201

Free entry into mining, means profit seekers will come in and accept those censored transactions, but just that threat of entry will keep miners from engaging in widespread censorship.

144 sats \ 8 replies \ @SimpleStacker 23 Oct

If relay policy is effective at preventing consensus valid transactions from being mined then we are all very wrong about what Bitcoin does and how well it delivers on its value proposition.

It doesn't matter how we feel about it, what matters is what the truth is. Is relay policy effective at preventing consensus valid transactions or is it not?

Take the spam debate out of it and just focus on that question itself.

It seems to me that the answer is it is effective if enough nodes do it, and you don't have a side channel with a miner.

That suggests to me that the social layer is an important determinant of censorship resistance, over and above what the consensus rules are. Broad censorship resistance can only be maintained if enough nodes agree not to censor.

93 sats \ 7 replies \ @Scoresby OP 23 Oct

Broad censorship resistance can only be maintained if enough nodes agree not to censor.

I disagree with this. I've seen a lot of data (especially good from LaurentMT here (#1244876) that shows that at somewhere around 90% censoring/filtering, transaction relay begins to be unreliable.

However, this assumes a static system. Such simulations rarely model rising fee rates for censored transactions, nor any out of band or new transaction relay networks that might emerge.

Because nodes require no (or little to no) work to spin up (just like bots on X or any other bane of the internet) any system that can be censored by pure node count alone will fail. Say there are currently 20k nodes. What stops some government from spinning up 200k nodes and censoring the network this way? This isn't a novel idea and if it was possible to so trivially defeat the censorship resistance provided by mining, I don't see how Bitcoin would have even lasted this long.

144 sats \ 6 replies \ @SimpleStacker 23 Oct

However, this assumes a static system. Such simulations rarely model rising fee rates for censored transactions, nor any out of band or new transaction relay networks that might emerge.

That's exactly my point. These are responses on the social layer of bitcoin, not consensus.

Say there are currently 20k nodes. What stops some government from spinning up 200k nodes and censoring the network this way

I think it would depend on network topology. But again, that's exactly my point. Practical censorship resistance depends on more than just consensus rules.

132 sats \ 0 replies \ @Undisciplined 23 Oct

I feel very validated that you're making the same kinds of points I am.

30 sats \ 4 replies \ @Scoresby OP 23 Oct

I should have been more clear: when I said "this assumes a static system" I should have said "this assumes a static mempool system." The rules that validate blocks can be treated as static.

Mempool policies are effectively infinite in variety and pretty much can be ignored.

These are responses on the social layer of bitcoin, not consensus.

What I'm trying to argue is that any layer other than consensus ends up being irrelevant.

This is because the block validation (consensus) rules are designed to incentivize the mining of transactions that the "social layer" doesn't like. How the transactions reach miners is irrelevant, only important is the fact that there are effectively infinite ways of transmitting transactions to miners.

102 sats \ 3 replies \ @SimpleStacker 23 Oct

Ok, I think I understand what you're saying. It's actually a very PhD economist way of modeling the world ("the incentives must imply this outcome---how it gets to that outcome is irrelevant")

Now that I understand, I'd say I agree with you locally, but not globally. Locally in the sense that, right now, it seems like consensus rules are enough to ensure non-censorability.¹

But I'd argue that this is only a function of current circumstances. Because miners' incentives exist both on and off chain, governments could, theoretically, make it so difficult or dangerous to mine disfavored transactions that miners refuse any side channels. In the current state of the world, that would be difficult to pull off, because we don't have a one-world government, and because internet privacy tools may be enough for individuals to circumvent national-level rules.

Still, the point I'm trying to make is that I don't think we should be lulled into thinking that a properly designed consensus layer is all that's required to keep bitcoin decentralized and non-censorable. I think that's perhaps too rosy of an outlook, and would tend to make bitcoiners complacent about social level threats.

You'd still have to respond to the question of "If filters don't work, why is there a cutoff at the OP_RETURN limit?" You answered earlier, "That indicates there's no demand above the limit." But even if there's little demand above the limit, you shouldn't see such a steep cutoff right at the limit. It should be a smoother dropoff of demand. Personally, though, I don't think this cutoff is relevant to the efficacy of filters, I think it speaks more to the impact of software defaults. ↩

30 sats \ 2 replies \ @Scoresby OP 23 Oct

"If filters don't work"

I'd like to put the statement "filters don't work" even more strongly: "filters can't work."

If filters can be effective in the face of sustained demand for a certain kind of valid transaction, Bitcoin fails to deliver on its value proposition. There is absolutely nothing that stops a state actor from attacking Bitcoin via a giant network of state-controlled nodes. And if our defense relies on some social layer, the project fails.

It's not like this threat was never considered. The block validation rules of bitcoin are designed to resist exactly this kind of attack. I'd even go so far as to say that solving the problem of a social layer is what Satoshi was trying to solve with Bitcoin in the first place.

The only social layer I believe is necessary for Bitcoin is agreement on block validation rules (what I've been calling 'consensus rules'). This was Satoshi's big innovation: he created a way that if users agreed on a minimal set of rules, no other differences were relevant.

The problem Satoshi was trying to solve was how to create a peer to peer money, a money with a third party, that was stable -- not in the sense of price or anything like that, but in the sense of useful to anyone who wanted to use it, stable in the sense of not being subject to the turmoil of disagreement in a social layer.

If a social layer beyond agreeing to block validation rules is necessary to make Bitcoin work, we are immediately confronted with the problem of how to decide things in this social layer. Is it by vote? by CPU power? by who has the most coins? In answering this question, I believe you will find that the only known solution is the same one Satoshi came up with for block validation rules. But this is just to say the social layer can only be coming to consensus on what the block validation rules are. Nothing else matters.

And so, yes, I believe

a properly designed consensus layer is all that's required to keep bitcoin decentralized and non-censorable.

As to your distinction that block validation rules are enough locally but not globally

Because miners' incentives exist both on and off chain, governments could, theoretically, make it so difficult or dangerous to mine disfavored transactions that miners refuse any side channels.

Check out Rob Warren's recent X thread on how difficult it is to control hash power: #1263431. A state may do everything it can to put pressure on miners in its jurisdiction, but the permissionless nature of mining is such that we may hope it is in the self-interest of miners outside such a state's jurisdiction to put disfavored transactions in blocks.

Therefore, I maintain that consensus rules are enough to maintain censorship resistance and that it is not a "function of current circumstances."

102 sats \ 0 replies \ @SimpleStacker 23h

I think your point is that, as long as there's an on-chain incentive to mine the most profitable transactions, then the most profitable valid transactions will find their way into blocks.

I don't disagree with that, but my question is at what cost and at what degree of usability? I think censorability is a spectrum, not a 1 or a 0. So my argument would be that bitcoin's built-in incentive structure can keep censorship<1, but it's uncertain if it can maintain a high degree of usability and mainstream adoption.

So, I still maintain that social norms, ethos, and other soft crap like that still matters for the tradeoff matrix between censorability and usability on bitcoin

0 sats \ 0 replies \ @Scoresby OP 23 Oct

The problem Satoshi was trying to solve was how to create a peer to peer money, a money without a third party, that was stable -- not in the sense of price or anything like that, but in the sense of useful to anyone who wanted to use it, stable in the sense of not being subject to the turmoil of disagreement in a social layer.

I never see the typos until after 10 minutes is up...

202 sats \ 1 reply \ @DannyM 23 Oct

I had a similar discussion with supertestnet at tabconf, except he argued significantly better than Chris Guida did.

essentially the idea is that they want those transactions off of their system until they HAVE to pull them in (as blocks), because they want to avoid propagating those transactions, regardless of whether they'll end up in blocks or not. the idea is that if enough people run the filters, MAYBE some non-monetary transactions can be prevented.

he obviously acknowledged that you can always go to a miner anyway and include whatever you want, so long as it doesn't break consensus if you really care about it

122 sats \ 0 replies \ @justin_shocknet 23 Oct

Coincidence that none of the people concerned with pulling things they don't want are talking about Utreexo?

For the uninitiated, Utreexo uses proofs for your outputs instead of whole blocks.

224 sats \ 2 replies \ @optimism 23 Oct

If relay policy is effective at preventing consensus valid transactions from being mined then we are all very wrong about what Bitcoin does and how well it delivers on its value proposition.

It's been effective at discouraging, not preventing. However, if we think of Bitcoin's realized importance for humanity, we can - even independently of NgU and hype - establish that it is much bigger now than a decade ago. With that, there is a lot more interest in (a) changing Bitcoin and/or (b) integrating with Bitcoin, and this will be for the whole spectrum of ideas: good and bad.

So you'll see some stuff that a significant group of Bitcoiners see as undesirable, be it inscriptions/shitcoinery, sidechains or centralizing protocols, get stronger (economic) backing than before and these will increasingly challenge the status quo.

The current polarization and arguing, fully caused by shitcoiners (let's not forget this), does not offer much hope though. It shows how fragile Bitcoiners are right now, but I also cannot help but feel that this is a reflection of society for the past 15 years. Humanity is weak as we adopt to information abundance.

If consensus valid transactions that do things we don't like can be prevented from reaching blocks as long as "enough true Bitcoiners" run "good relay policies," then the whole proof of work, consensus system is kinda pointless.

I'm going to refer to what you call consensus as block validation rules and not use the word consensus, to prevent confusion. block validation rules are non-discriminatory by design; it is a minimal set of validity requirements that guard integrity of the value chain / script evaluation, sets some limits, and enforce longest work chains. The flexibility that this gives is not just some libertarian idea, it is technically the best way to ensure future crises to be handled without hard fork.

100 sats \ 1 reply \ @Scoresby OP 23 Oct

I'm going to refer to what you call consensus as block validation rules and not use the word consensus, to prevent confusion.

You make a really important point here that I should have been able to articulate in this post. I was using consensus in a weird way, but it's a way that is often used in bitcoin, and maybe that is causing some of this trouble.

But block validation rules doesn't surface the idea that if you have rules that are even a tiny bit different, you (might, or are likely to) fork. I'll happily use block validation rules instead of consensus rules if I can figure out how to carry that extra little bit of meaning.

The flexibility that this gives is not just some libertarian idea, it is technically the best way to ensure future crises to be handled without hard fork.

Honestly, I wish I had just said exactly what you put in this last paragraph of your comment.

102 sats \ 0 replies \ @optimism 23 Oct

I'd say block validation rules are an extendable set of rules, and what moves them is consensus, because they only work if everyone on the same chaintip enforces them in exactly the same way.

"Consensus rules" is perhaps a misnomer because the rules do not describe consensus. Instead consensus is formed over these rules, or else it won't work for anyone. The rules come first: someone codes them, then you review, compile and run them, and finally, you running them makes you part of the consensus that these are the rules; not the other way around. It's still semantics though, but because consensus is a popular word nowadays it can be confusing af in some contexts at times.

Honestly, I wish I had just said exactly what you put in this last paragraph of your comment.

It's easier to discuss this in a non-adversarial setting, and I took maybe an hour over first coffee to write and rewrite that comment, free it of aggression for the most part and take a step back and read it through / tune it a couple of times before hitting reply. That's much harder on X than it is on SN.

102 sats \ 7 replies \ @gregtonoski 22h

I think you oversimplify, @Scoresby. Bitcoin is very complex.

"Bitcoin works because consensus rules are all that matter" is false. There are many more critical success factors at play. It's not that one day Satoshi implemented "consensus rules" and Bitcoin came to be and succeeded. (As a side note, Satoshi himself changed the rules many times).

Both consensus rules and mempool filters are needed and also both of them need updating (fixes, improvements etc.).

Regarding the malware Core v30 - there isn't any (formal) reason for meddling with the mempool policy default settings. The author Gregory Sanders hadn't informed about one. Instead, he and his co-workers dictated it and later gaslit about the change. Two years earlier, the same change had been requested by Peter Todd as he had taken $1000 bribe from a simp for Ethereum guru Vitalik Buterin, to do it (source: GitHub repository). Peter Todd deployed malware on Bitcoin nodes a few weeks ago. He exploited the well-known vulnerability (P2SPAM or so-called OP_RETURN) in Bitcoin protocol. The impact of the vulnerability had been moderate throughout the years so there hadn't been pressure to fix it immediately. Virtually all node runners relied on the mempool policy to somewhat mitigate the issue. Core v30 unilaterally breached the status quo, doing so against Bitcoiners who run honest nodes.

The time to fix the P2SPAM vulnerability has come, apparently. The security patch will affect code of consensus rules. Bitcoin has always been P2P monetary network and releases of Core malware don't invalidate the statement.

0 sats \ 6 replies \ @Scoresby OP 21h

I agree that consensus rules need to change, but I disagree that mempool policies are useful to any great extent (and I certainly don't think they are worth getting worked up over).

While I don't think "Bitcoin came to be and succeeded," I do think Satoshi managed to get a few key elements in place and that started this whole thing off. I'll settle for filter proponents suggesting a change to block validation rules and standing by it.

0 sats \ 5 replies \ @gregtonoski 21h

Let's do it. Would you like to contribute and spread the word about the idea, perhaps? I am going to contribute on the technical side and I already openes the discussion on the Bitcoin-dev mailing list.