It's too bad that merchants socialize the costs induced by credit card users. When I walk into a store, I get the same price whether I pay with cash or credit card. Why would I use cash when I can get cash back rewards for using credit cards? Plus, credit cards give me insurance against dishonorable merchants. I can reverse the payment if needed.

If merchants offered me lower prices to use cash, I'd consider it.

No, I'm just using the conventionally accepted definitions. Discussing these things is futile if you can't agree on definitions. Also, if you go back to the mailing lists, these definitions go back far beyond 2014. That's just when the pages were created.

You're never going to get anywhere if you keep referring to apples as oranges.

Anyway, like I've said before, the name you give it doesn't matter, so foaming at the mouth about hard forks isn't necessary. The issue is whether a fork is consensus-breaking or not. In the case of BIP148 or a hard fork, consensus would be broken.

I guess you don't understand how wikis work. You're only looking at the most recent revisions.

The hardfork wiki was created on 22 March 2014‎, and the definition in question was published on 23 March 2014‎. See here for the entire history.

The softfork wiki was also created on 22 March 2014‎, and the definition in question was published on 23 March 2014. See here for the entire history.

This is how the definitions appeared at that time:

Not according to the definitions we've been using for many years. From the Bitcoin wiki:


BIP148 rejected previously valid blocks (blocks that didn't signal for Segwit). That's how it pressured miners into activating Segwit. Miners risked losing block rewards if they didn't.


Sort of like you calling a "soft fork" a "hard fork."

None of this matters anyway. Soft vs. hard is not important. What matter is whether a fork is compatibility-breaking. That is what causes network splits. That's why BIP148 was just as reckless as many hard fork proposals.

BIP148 was controversial, but it was coded as a soft fork. Not all soft forks are backward compatible. That's one of things that upset me so much about the BIP148 camp -- they marketed it as a backward compatible soft fork, which was completely false and deceptive. Of course, no UASF can be a priori backward compatible because soft forks require majority hashrate to remain compatible. Indeed, one might call it a "soft-hard" fork because it was a soft fork that was extremely likely to cause a network split.

As you may be able to tell, I was vehemently opposed to BIP148. It was incredibly reckless to do on such a short timeline and I honestly lost a lot of respect for the people who pushed it. I also think Luke is an asshole who puts his own misguided principles above all else, including the health of the Bitcoin network.

But credit where credit is due: Segwit never would have activated if not for BIP148.

He's made hundreds of contributions to Bitcoin Core and maintains the BIP process. He's the one who realized Segwit could be implemented as a soft fork -- prior to that, it wasn't a serious option. He was probably integral in getting Segwit activated on the network by championing BIP148.

He has some good ideas and also some really bad ones. It can help to have conservative engineers like him involved, even if their ideas won't agree with the consensus most of the time. They see things that other people can't and can provide important counterpoints in technical discussions.

Somehow "LN.PIZZA" doesn't produce the same sort of hype that a publicly traded Fortune 1000 company does.

Personally, I'd rather see Dominos go out of business than see anyone paying for that crap. Awful, awful stuff. Get some real pizza!

It looks like he's going even further off the deep end. I guess he's made his bed with Craig Wright and now he's got to sleep in it. The pair of them are looking more delusional by the day.


This is just fascinating and hilarious and sickening all at once.

The losses might be small enough that private investors might compensate victims in exchange for company equity. That's definitely the hail mary everyone should be hoping for -- a replay of the Coincheck aftermath where everyone was repaid the fiat value of their coins. If they're in the middle of negotiations, that would explain the delay. They might also be busy figuring out how to best apply a haircut to user accounts to account for the losses.

In theory, that's true. In practice, we pay the same price no matter what. I'm stuck paying $10 because other people are using credit cards, Paypal, etc. and the seller is charging me for it.

In this way, it's completely rational for everyone to keep using PayPal. Unless sellers offer us lower prices for using cheaper payment methods, we have no incentive to change anything.

Could you give a couple examples?

Many people think of the block weight limit as an obstacle, but it serves an important economic purpose. Many people think POW is wasteful -- all the more because it's not capable of scaling node resource usage with sharding or similar models -- but undoubtedly it's still the most secure model for consensus. That seems like a fine trade-off to me.


With millions of users and so many different stakeholders with different interests, we should expect drastic changes to the protocol to be controversial. The people who have so far opted into Bitcoin agreed to the current rules, right? Changing them isn't so easy with such a diverse ecosystem.

I'm not sure how that was supposed to work. Was Ernst and Young really supposed to take custody of the cryptocurrency wallets? A law firm holding bank accounts in trust/escrow is one thing. Holding bitcoin wallets is another.

Those were the hot wallet coins, so given that the site is indefinitely shut down and no customers will be withdrawing anytime soon, it made sense to move them to cold storage. Cold storage that could actually be accessed, that is.

You're conflating different definitions of "authority."

Greg was referring to those with the power to influence others because of their recognized knowledge and expertise. That doesn't imply that such authorities have power or control over the Bitcoin protocol. It just implies that there are knowledgeable experts within the Bitcoin community, just like all other technical fields. Craig Wright regularly lambasts such people in a populist attempt to persuade people towards his arguments.

I'm curious to see how things turn out. One would think it's impossible to trademark common words like "blockchain" but that's not necessarily true if the word is not descriptive of the company itself. This is the case with arbitrary trademarks. I'm not sure whether "blockchain" is legally considered descriptive of their wallet and exchange services, though. It might be.

I read an earlier legal analysis that suggests Blockchain's argument was on dubious footing. It seems like they are trying to leverage their design trademark (logo) to prevent others from using the word. That sounds pretty weak.

As I understand, the biggest hurdle for most people with bootstrapping a node isn't download bandwidth but hardware/computing limitations for verifying blocks and updating the UTXO set.

That's why things like Libsecp256k1 seem so important, and why this soft limit idea just seems like a kludge by comparison. Optimizing bootstrapping inefficiency seems like a better route than arbitrarily adding new throughput limits that will just slow down the damage slightly and linearly.

There's really no such thing as a "decentralized" exchange yet. The best we have are centralized exchanges that don't hold custody of your coins. This keeps you safe from a hack of an exchange's wallets, but there are still other considerations to make.

"Decentralized" exchanges still all use a centralized server infrastructure and the DNS. That's why they're being targeted by the US government and we're seeing them start to implement mandatory KYC on their customers. Using the DNS can also allow attackers to hijack the site registry and phish customer private keys.

I think fees should rise over time given Bitcoin's incentive design, but I don't see any good reasons to lower the block weight limit. The fee market is working fine and fees will rise when usage starts spiking again.

We wouldn't gain much by lowering the limit. Block propagation delays aren't a major problem right now. Things like FIBRE have resulted in minimal orphan rates. As for initial sync time, it's too late for a size reduction to do much at this point. It would be many years too late to have much effect.

His fork won't be backed by hashpower. It would be backward incompatible, just like a hard fork. One might call it a "soft-hard" fork.


After it's obvious that ~0 other Bitcoin developers agree with him, this will be forgotten about pretty quickly.

Luke has been pushing the idea of lowering the block size limit for years and years. He's never been able to garner much support from anyone -- other Core developers, the community, or anyone else. Nothing has changed this time. The articles cite two supporters of the idea: BitcoinErrorLog, a social media personality, and Vinny Lingham, who doesn't really support the idea at all and was just joking.

I would expect this discussion to quickly fade away just like it did last time.

That probability is not concrete. Hash power distribution is dynamic, constantly changing, and we also don't know whether a single entity controls multiple pools. Plus, by making all transactions older than 1 month irreversible, you create new incentives for miners to game the system. The fact that you say the probabilities can be easily calculated yet you have no idea what they are shows the weakness of your claims.


Anyone who has upload or storage limitations doesn't need to run an archival node. They can still run a full node, contribute to network security and secure their own transactions. There's just no basis for what you're saying.

Upload bandwidth becomes an issue with much bigger blocks. If we're drastically increasing the block size, we can talk about appropriate trade-offs to make, but right now it's completely unnecessary.

This is a solution looking for a problem.


Then what did you mean? You haven't clarified at all. You've said multiple times that once the blockchain is pruned, all older transactions, e.g. older than one month, will be irreversible. How is that any different than a checkpoint at all?