Design errors Satoshi made | Hacker News Reader

Design errors Satoshi made

twitter.com

128 pointsmyth_drannon53 comments

No expertise to comment about the tech/crypto design, but Satoshi definitely seemed to care about the users.

I once skimmed through Satoshi's code while I was in college and found this: https://github.com/bitcoin/bitcoin/blob/v0.8.2rc3/src/base58...

I've neither seen any such decision in any other project, nor have I come across any strong advocacy for such things online. FAIW, Satoshi might be a kick-ass UX designer too.

In a different tangent, do any of you remember or still see/make such decisions (mostly to build a better UX)?

These are very similar to the considerations that were discussed in RFC 3548, which documented Base32 and Base64. I assume they were pretty well known at the time the code you linked to was written.

https://tools.ietf.org/html/rfc3548

Seems e.g. Flickr did roughly the same thing for its short URLs at around the same time.

https://www.flickr.com/groups/api/discuss/72157616713786392/

A downside of base58 as implemented by Bitcoin: leading zeros are optional, so there are multiple possible valid encodings of a single address, and addresses don't have a fixed length.

That's a lot better than the typical 'pay this invoice with the exact description' you get from municipalities here where the 'exact description' is a string without spaces and a ridiculous number of leading zeros.

I used to host counter strike games and voice servers, every one else just gives you a random port number like 39281, ugly, difficult to remember, awkward to tell people. I wrote a script that would generate ports that where easy to remember stuff with doubles and triples like 4040 or 44455. I found it super helpful, no customers ever mentioned it, but if you are doing UX right I guess they should never notice it.

Similar features are often found in encryption products, for example openssh which gives you a visually distinct ASCII randomart to easily spot the difference between the keys.

Douglas Crockford documented his BASE32 encoding in 2002. It's a very friendly format with many nice characteristics, including those in Satoshi's base58 and more (listed in his "requirements" section here: https://www.crockford.com/wrmg/base32.html)

I like it, but I think the exclusion of U is unnecessary -- excluding Z2 or 5S similarities seems like it would be preferable.

The original Bitcoin release (and whitepaper) made the mistake of reaching consensus by selecting the longest chain instead of the chain with the most accumulated work. The distinction is subtle but important, since the amount of PoW per block varies. This was quietly fixed early on in Bitcoin's history: https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7...

Great find.

It’s important to remember that Satoshi is not a god, but I also agree with this reply to the OP tweet:

> Great summary. However all issues you mention are technical ones (mostly coding). I think the people that praise Satoshi or follow his "gospel" are more attached to his concept and design which is, in most cases, the White Paper.

Any software engineer will write buffer overflows, miss a few corner cases that break your model, or write hard-to-maintain code that needs to be refactored. However these issues are ephemeral, do not block the broader vision, and have since been fixed. I would even argue that it’s totally understandable that the initial PoC of Bitcoin was buggy and flawed. It should be expected of any first-try implementation of groundbreaking tech.

Yes, the author seems to have confused implementation errors for design errors in a majority of these. I detest worshipping the crypto calf as much as anyone, but there is a big difference between the two.

Agreed, the thread highlights some decent implementation issues but largely misses the design problems, both ones that were present in the whitepaper but fixed and ones that are still with us today.

Would you be willing to expand on some of the errors in the white paper? I’m admittedly not too familiar with the whitepaper (only skimmed it), but some of the other errors mentioned in this thread (for example, not including accumulated work of a chain in consensus calculations and only considering chain length) are pretty interesting.

The "freeing up disk space using Merkle trees" section doesn't make much sense. The Merkle tree structure turned out to be useful for other purposes but reducing disk usage wasn't one of them.

Agree with other comments that these are more coding issues, that aren't uncommon in pre-beta versions of software.

But if we're talking about design issues, there is one big one that everyone seems to be missing - and that is the Proof of Work incentive mechanism. The first issue with this is that it disproportionately rewards early adopters (both via difficulty increasing every 2 weeks and rewards halving every 4 years) and requires a constant addition of new adopters just to sustain the price (to counteract the deflationary nature of new coin generation), which makes it appear more like a traditional pyramid scheme than a new financial paradigm and may in the long term behave like one. The second issue is that this has led to the concentration of almost all of the wealth in a handful of anonymous and in many cases very shady characters in a completely unregulated market which has completely inverted the original goals of the project. The third issue is of course that Proof of Work is an environmental disaster.

You misconstrue the algorithm, difficulty only increases when hash power increases to maintain a 10 min blocktime. Difficulty can decrease too.

Well, what you call here "design issues" I would call "flaws of an imperfect solution". They are design issues similar to how CAP theorem is a "design issue" with dbms-s or how concentration of wealth is a "design issue" of capitalism.

His system solves a previously unsolved problem, but it has flaws. Do we know a better solution? Well, it's being worked on. However, Bitcoin has been here for ~10 years.

well thats why its open source software

but yes the Satoshi as Gospel stuff is quite uncanny! Even the Bitcoin Core and Bitcoin Cash crowd debate each other over the meanings of Satoshi writings and then debate about the context! Cryptocurrency's regulatory problems will be solved by the IRS designating all of it as a religion.

Goodbye atheism, hello tax free status.

If there is one thing more certain than religious beliefs, it's taxes.

Tell that to the church.

Well, not too long ago, the church would actually collect taxes from the farmers...

I’ve never thought about it before, but there are quite a few striking similarities between crypto and the history of early monotheism. With an established central religion, a few popular alternatives centered around dogmas that promise to better than the original and carried by a cult of personality, and a million prophets and “false” idols all of it carried solely by faith.

Of course it was centralized power structures and societal authority that chose which religion we have today, and crypto is much less likely to obtain that.

Well on crypto you do have centralizing incentives considering that your income as a miner is directly proportional to the amount of money you have (buying hardware).

Not only that but the power on the Bitcoin blockchain is directly determined by how much hardware you can buy and how specialized you can make this hardware. Consider that atm you can fit about 80% of bitcoin hash power on a single stage (about 11 people IIRC).

> Even the Bitcoin Core and Bitcoin Cash crowd debate each other over the meanings of Satoshi writings and then debate ...

Of of the few actual debates between the two party's interpretation of the whitepaper is about running full nodes. Core believes that Satoshi expected anyone transacting on the network to run their own full node to validate each blocks even if the person isn't trying to mine (generate coins). The Cash party believes that Satoshi never intended end users to run a full node unless they were also trying to generate coins.

Other than that though, there doesn't seem to be much debate coming from the "Bitcoin Core" side. They seem to be of the opinion that the whitepaper describes a system that simply cannot work in it's original form. It's hard to know what people really think though because of the censorship (or strict moderation if you prefer) in r/bitcoin.

> Cryptocurrency's regulatory problems will be solved by the IRS designating all of it as a religion.

Does that mean they can apply for tax exempt status? ;)

I would change

„Core believes that Satoshi expected anyone transacting on the network to run their own full node to validate each blocks“

„Core believes that Satoshi expected anyone transacting on the network to BE ABLE TO run their own full node to validate each blocks (without needing a supercomputer or anything near that)“

But actually even this is not right. Bitcoin Core devs are taking distance to the words satoshi said... at least when necessary... they correctly say that time has passed and they try to do what‘s best for the project from todays point of view (mostly it is the same anyway, but they don‘t try to argue with „satoshi said this“... of course it happens now and then because many people work on bitcoin core, but these are not arguments with which you win the fight/consens)

It worked out pretty well for the witnesses.

Well we've already had the Satoshi Nakamoto Institute [0] (a copy/paste collection of every Satoshi Nakamoto forum post) become so fanatically strict in their interpretation of the "gospel" that a founder split off to set up the Nakamoto Studies Institute [1], just like the People's Front of Judea vs Judean Popular People's Front split in The Life of Brian [2].

[0] https://nakamotoinstitute.org/

[1] https://nakamotostudies.org/

[2] https://en.wikipedia.org/wiki/Monty_Python%27s_Life_of_Brian

If the first "design error" you list is a bug it seems like you don't understand the concept:

> Early version of bitcoind allows you to spend any coin by using "op_true op_return" as signature.

He does. Early versions allowed you to spend anybody else's money by using this script as "signature".

Spending money involves prepending the input script to the output script, then executing and checking the result.

Normally the output script is something like "[pubkey] OP_CHECKSIG" (for the old P2PK), and the only input script to cause the combination to succeed would be the valid signature, such that "[sig] [pubkey] OP_CHECKSIG" succeeds.

With "OP_TRUE OP_RETURN" instead of [sig] it would also succeed as OP_RETURN would stop execution.

This was fixed by ensuring OP_RETURN stops execution AND fails the script.

How is this not a bug?

https://threadreaderapp.com/thread/1007548856375095296.html

I've been waiting for something like this. I take it as a sign of maturity of the bitcoin/blockchain ecosystem when people can actively discuss all the issues that the founder missed instead of letting hero worship getting in the way.

Good list of technical flaws in Bitcoin. I have a comment on one of them:

> Input value were not [directly] covered by signature, making it impossible for offline devices to check how much is spent and paid in fees.

It is true that the input value (amount) being spent is not covered by the signature. This got fixed in Bitcoin SegWit signatures (BIP 143) and in Bitcoin Cash (mandatory).

Even in traditional Bitcoin, it is possible for offline devices to avoid being tricked by incorrect input values. The idea is to feed every input transaction into the device, let the device extract the input values, and let the device compute the transaction hash - instead of the unsafe shortcut of feeding the hash and value.

Additionally, some mistakes in Bitcoin are reflected in https://en.bitcoin.it/wiki/Hardfork_Wishlist

Tying energy consumption with profit? Or externalities don't count?

Not a mistake of the protocoll, but a bad consequence. The difference being that there is no easy fix.

Name one thing that doesn't link profit and energy consumption.

> Verifying signatures was O(n*m) where n is the number of checksig ops and m the transaction size. This makes it possible to generate transaction that are absurdly expensive to validate.

That's what sigops limits are for: https://curiosity-driven.org/low-level-bitcoin#signatures

Not really.

The problem is that with twice as many sigops, you would also have to hash ~twice as much for each sigop. Hence O(n*m). A problem known "quadratic hashing".

This is solved by using a different way to hash the signatures that doesn't require full recalculation on each input.

In Bitcoin Cash it is fixed for all transactions; in Bitcoin it is only fixed for SegWit transactions so an attacker could still do this, by not using segwits.

This seems like a historical list of major bugs... are those really "design errors"? Or are we expecting perfect code on v0.1?

Those are not design flaws. Besides that, who here has written software that scaled through many orders of magnitude as seamlessly as bitcoin has. I certainly haven't, and the amount of forethought that has gone into bitcoin consistently surprised me.

these are common bugs and not design errors. Bufer overflows are never design errors. Deadalnix for those who don't know is the coder of bitcoin cash, an altcoin.

edit: never mind/fuck this thread/not wading into a holy war

Aside from the fact that there is no evidence for that, what state actor would benefit from the existence of Bitcoin?

North Korea comes to mind first

Why?

If it's about money laundering, they had no problem doing that with the many currencies that already existed before Bitcoin.

NSA.

How would the NSA benefit?

Anybody holding Satoshi's wallet address is sitting on roughly $2-3 Billion USD at current prices. That alone gives the holder a great deal of power over the network.

old news...

Reply on news.ycombinator.com