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)?
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.
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.
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.
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)
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.
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...
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.
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.
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.
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].
> 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? ;)
„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)
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).
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.
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.
> 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.
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.
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.
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.
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)?