
Design errors Satoshi made - myth_drannon
https://twitter.com/deadalnix/status/1007548856375095296?s=09
======
Sreyanth
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...](https://github.com/bitcoin/bitcoin/blob/v0.8.2rc3/src/base58.h#L7-L14)

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)?

~~~
oconnor663
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.

~~~
jacquesm
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.

------
avhwl
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...](https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420)

~~~
glitchc
Great find.

------
flafla2
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.

~~~
avhwl
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.

~~~
flafla2
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.

~~~
repolfx
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.

------
m-i-l
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.

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

------
gammateam
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.

~~~
uncletammy
> 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? ;)

~~~
nfin
I would change

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

to

„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)

------
ailideex
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.

~~~
tomtomtom777
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.

~~~
ailideex
How is this not a bug?

------
robjan
[https://threadreaderapp.com/thread/1007548856375095296.html](https://threadreaderapp.com/thread/1007548856375095296.html)

------
fouc
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.

------
nayuki
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.

~~~
nayuki
Additionally, some mistakes in Bitcoin are reflected in
[https://en.bitcoin.it/wiki/Hardfork_Wishlist](https://en.bitcoin.it/wiki/Hardfork_Wishlist)

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

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

------
Boulth
> 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](https://curiosity-driven.org/low-level-bitcoin#signatures)

~~~
tomtomtom777
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.

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

------
jacquesm
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.

------
arisAlexis
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.

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

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

~~~
felix_nagaand
North Korea comes to mind first

~~~
twblalock
Why?

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

------
Cypher
old news...

