Profile picture
Deadal Nix @deadalnix
, 15 tweets, 2 min read Read on Twitter
Some people seems to adulate Satoshi, think he can do nothing wrong and his word are to be interpreted as gospel. While I share Satoshi's plan to create peer to peer digital cash, I do think it is important that we think for ourselves. Here are some errors Satoshi made:
Early version of bitcoind allows you to spend any coin by using "op_true op_return" as signature.
It was initially possible to fork each version of the client on its own chain using "op_version"
Input value were not direcatly covered by signature, making it impossible for offline devices to check how much is spent and paid in fees.
It is possible to put op_checksig in an input script. Coputing the signature hash fails and return 1 as an error code, but error code was checked so it is possible to produce a valid signature signing 1.
Version fields are completely useless because they don't degrade gracefully. In case of hard fork, you can't |ake sense of the new data regardless of version, and in case of soft forks, they aren't useful.
Places where addresses could be useful, for instance outputs, do not have one.
Numerous opcodes were seriously flawed in early version, some of them exibiting buffer overflow.
It was possible to create several coinbases with the same txid, and in fact, satoshi lost coins doing so. This breaks numerous assumption about the txns graph being a dag by design.
Block size and/or tx count are not covered by pow. This creates DoS vector that lead to the introduction of the block size. Bitcoin Ulimited suffered from attacks after neglecting these DoS vectors.
The script number format is little endian, one complement. No more comments on that one.
The original code had numerous problems checking signature encoding, at least one could lead to a chain split between 32 and 64 bits archituctures.
The merkle tree doesn't handle empty branches properly. This lead to a vulnerability where you could repeat transactions is a block and get a node to reject it.
It is also possible to generate a valid 64 bytes transaction that looks like an intermediate node in the merkle tree, making it possible to lie to spv by brute forcing 70bits or so, which isn't considered secure.
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.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Deadal Nix
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!