I did not know Hal well, but he was at Caltech in the dorm room next door to mine. He was indeed a wonderful man. Everybody liked him, and he was respectful and kind to everyone.

Oh, and he was off-the-charts smart, too, though you had to get to know him for a while before discovering this.

Hal is the person I believe was Satoshi. All of the evidence points to him more than anyone else I have read about. But wanting to keep his identity secret makes perfect sense given what happened.

  Nick Szabo
  Satoshi Nakamoto

Hal's post was so inspiring – thank you for sharing.

The bit about having to finish the documentation was particularly noteworthy. Even when writing code laboriously through eye moment, Hal didn't lose focus of the importance of documentation.

Also why some other folks suspected of being Satoshi have denied it so arduously.

If the above poster is Satoshi (which I suspect, it being a new account), I'd like to thank you for your contribution. Your writings are underrated but will be appreciated by future economists, developers, and historians.

Apologies for the use of 'x' to denote multiplication. I just figured out that I could have written as asterisk * as 3 asterisks in markdown, but it's too late to edit my post now.

Bitcoin is set up such that there is no auto-updating feature. Any change to Bitcoin must be accepted manually by all participants.

But there's still a question of "how many people actually review the changelog before updating?" It's a very small number, but that might be okay. If a bad actor pushes malicious code through, all you need is one person to raise the alarm.

In general, Bitcoin is very well reviewed. I don't think it would be easy for a bad actor (even a good actor who is being compelled in secret by a state actor) to push through malicious code. But it's hard to be certain exactly how robust Bitcoin is to this type of thing.

The culture of Bitcoin is highly resistant to changes in the core code. Even optimizations are increasingly scrutinized. Attempts to influence the core devs ("psyops") are also likely to fall flat, simply because the core devs have gone to great lengths to ensure that there is a lot of red tape to making changes, and that larger changes take years to get through with hundreds of eyes of review.

Systems are as decentralized as the people running it; if you convince by force the majority of the people running it to accept your change then I guess you win, right? FWIW; there is still the question of what the people who reject the change choose to do--give up or resist--and if they go with resist then they effectively become a fork of the network and now there are two networks: the one that was forced to accept your corruption and the one that didn't... since all the effort of the larger network you corrupted is busy the latter network could possibly still be secure. Really if you want to do that you don't want to push a band update you want to force people to counter the protocol: get a majority of then hash rate to promise to cause chain reorganizations constantly to screw with the smaller forks.

Pushing code to a repo doesn't mean it's used in prod. It's vulnerable to takeover by a massive single group (though v unlikely and this would ruin the value), or small co-op of the largest miners, but it's vulnerable to that in every sense.

So it doesn't really matter who can push code to what repo. It only matters who can organise the majority of computational power.

I'm not saying it's not vulnerable, but I am saying that investing in taking over btc in order to enrich yourself will by its nature backfire, and that it's not really vulnerable to code change in any way like a centralised system.

You’re right, the only thing preventing what you’re saying is the community keeping the leaders in check. But the leaders have way more influence individually than each community member does, so if one with git access to the Core repo is compromised by the CIA let’s say, they can nefariously push for changes that seem innocuous but actually benefit some entity with deep pockets. And most of the community doesn’t review each line of code that gets changed.

I would think, given how popular bitcoin is, every single change that goes into the code is reviewed by hundreds or thousands of developers. Malicious code will most likely be caught, and then someone can just fork it at that point and everyone who cares about their BTC investment will switch over to the new chain.

You're not missing a thing. Bitcoin is sound in theory. In practice, though, humans are very flawed and they tend to submit to authority more than is healthy. In the case of Bitcoin in particular, the Core implementation has been declared the de facto reference client. Meaning, whatever they say goes. This has proven to be detrimental to Bitcoin as Blockstream, a private corporation is the employer of (or was cofounded by) the most influential Core contributors. Those who disagreed with the direction Blockstream wanted to steer the project to, were removed from their authority position. Now as a result, Bitcoin is unable to scale. Blockstream keeps delaying a simple upgrade that would do just that and at the same time, keeps pushing competing solutions like LN and Liquid. I think Bitcoin as an experiment in human behavior was very interesting. But as a revolutionary technology, not that successful...

There have been numerous forks. If someone attempt to force in code via intimidation or whatever, the chain can be forked from any block and started up again without that code by anyone.

you can discuss the changes to be pushed, you can submit pull requests yourself and if you are dissatisfied about what gets accepted, you can also run your own version of the codebase with different implementations (lacking updates) as long as they aren't incompatible with the other nodes. (ie a subset of features instead of different features)

if you need me to elaborate on the ramifications/benefits of that let me know.

There are multiple competing full clients.

It’s not resilient to outside forces. I would argue strongly that it’s a huge risk to the majority of the population under the consideration of computation complexity.

The computation stack end to end has alarming risks. If the average user can’t read code, then anything they use is a form of delegated trust.

The users trust the wallet software that it’s doing the right thing. The average user does not even know what validation means.

Additionally what is known about computation is public knowledge. What secrets exist within state actors or even possible ET tech that could be used to influence truth with advanced computation?

There’s certainly no guarantee of security within Bitcoin or the network. It shifts the trust model at the most.

In another perspective, the amount of individuals who understand cryptography are quite low for the entire human population. Combine cryptography with hardware and software and that’s the small percentage of people who truly “get it” and are also specifically the ones entrusted as the leaders of all. The attack vectors are large.

In order to fix this we need to reduce complexity across the stack end to end. Every individual should know how to build their own computer without having to trust any hardware or software manufacturing.

I’d argue the stack is needlessly complicated end to end. Individuals add complexity by allowing the conceptual model of computation to remain complex within their tooling and then adding their own esoteric layer on top. It’s a house of cards.

Here’s a good post by Bruce Schneier https://www.schneier.com/blog/archives/2019/02/blockchain_an...

Would I keep a significant portion of net worth in bitcoin? No.

Would I use it to make a payment like PayPal? Yes.

I do not trust anything with computation today. It is compromised end to end.

As long as the Internet depends on BGP and ISP’s there’s no true decentralization. We need ad-hoc mesh networking with deterministic address spacing. Doing so behind some type of one-time cryptographic address that maps to an IP would be interesting. A few projects are experimenting in this path. Yggdrasil looks promising as an algorithm. Ouroborus has an interesting novel stack based on recursion.

I mention all these things because it’s exactly the reason why bitcoin is not safe or to be trusted. The cult behind it doesn’t help the fact of the fragility of the situation. Much of the cult are increasing the risk of other individuals by preaching trustless models.

I frequent several datacenters in the Pacific Northwest; a couple of them are near the cheap power available in the central part of Washington State. We're on friendly terms with the staff and we talk about their other customers in general terms because it's nice to have a feel for who your neighbors are.

Two years ago the datacenter owners were contemplating whole new buildings. "We're going to run out of room next year, so we're planning another quarter million square feet down the road a bit." That expansion didn't happen. The space they opened up internally remains largely unused. One of the cages next to ours had a bunch of bitcoin mining racks, clearly at the DC's capacity for cooling . . . and they were unplugged because the customer hadn't paid their power bills. The DC wound up tossing the machines away after a few months. That parcel of land "down the road a bit" remains vacant.

I think the bitcoin "resource losses" go much, much deeper than an algorithmic tweak that would have been taken for granted a few months after introduction. [Okay, 25% is a good optimization, but it wouldn't have changed the basic game, nor the character of the companies involved]

Schnorr signatures were also kept in reserve for many years due to a patent that recently expired. Should be merged in the next major feature release.

>...that could enhance bitcoin

It does not its irrelevant it chances nothing about bitcoin or its limits. Its a client side it does not speed up usage or something the CPU just useless less cycles and idles more.

Uhh, ECC powers most cryptographic stacks out there. Most TLS connections use DH over some elliptic curve, for example.

Many of the core developers live in the US jurisdiction under a public identity. Many of the major corporations in the space such as BitGo and Coinbase also are in the US jurisdiction.

If everyone is anonymous, you can probably ignore the patent. But if you want legitimate businesses to be able to use the software, you need to respect the laws in which those businesses operate.

Because violating it would nevertheless cause very real problems for the developers, businesses, and perhaps even users with public identities living in jurisdictions that might come after them for it?

Because businesses use the software as well? If you want to promote the usage of bitcoin, the last thing you want to do is scare away businesses from using your software.

There will be energy savings for the nodes that have a copy of the blockchain and need to verify transactions but not for the miners.

Market forces fundamentally tie the energy consumption of the miners to the price of bitcoin.

You can't save energy in bitcoin, because proof-of-waste is intrinsic to it's functioning and the difficulty adjusts to keep it that way.

Bitcoin miners are the ones that use the energy calculating the SHA256 functional. The cost of the function is not relevant to energy use as competition between miners means the energy used will match the value of the block reward.

This optimizing is for the users of the bitcoin network that must validate that the rules are being followed so they can reject any miners that do not follow the consensus rules

This only helps nodes verify blocks, the mining is what uses huge amounts of power and that won't change.

ecdsa speed is related to client performance, it has nothing to do with the power consumption of proof of work.

This is not relevant to bitcoin mining. Just synchronization.

The mining is no longer (for 7 years or so) done by traditional CPUs. People use ASICs

Note that this is not mining, just running a full node. When running one, signature verification is most of what your CPU is doing.