This rant by cascadianhacker was excellent. I was just about to post this when I saw this thread.
My favorites below. I laughed at the "failure of C++ comment". I think the bitcoin devs should switch to C#, which is easy to program in (for me at least) and has automatic garbage collection with very little overhead, and supports the Generics library and has an IO library too. What's not to like?
TonyT
http://cascadianhacker.com/blog/2014/10/20_a-summary-of-changes-to-bitcoin-since-0321.html
The takeaway: next to nothing has been done to bring the Bitcoin project forwards since 0.5.3 (the duplicate TXID rules). This (and the comments to code ratio) speaks as strongly to the failure of C++ as an expressive language that fosters the construction of (developer) performance-enhancing abstractions as it does to the failures of the group of humans who've sprung up around the thing seeking to make a buck; make a name for themselves as "Bitcoiners" or what have you; or even just a few miserable credits in the eyes of those who would print fiat currencies endlessly by derping relentlessly at its fringes.
Bitcoin Core is stalled out. It's gone precisely nowhere since 0.5.3 (unless you count the SSL patches that should never have been necessary in the first place). {NOTE: 2012-03-14 - Bitcoin-Qt version 0.5.3 released}
//
Doubling down on the "address reuse is evil and dangerous, bad for privacy and so on!" poor decisions. Sending your change to new addresses is, in the vast majority of scenarios, entirely pointless. The "hierarchical deterministic wallet" stuff is cool: being able to back up a single master key and have an arbitrary number of addresses keyed off it trumps the current behavior by miles.
The current behavior is for every transaction to spin up new addresses for change destination. This leads to wallet backups actually expiring - a phenomenally stupid thing that fell out of the poorly-thought-through "address reuse is evil, let's send change to arbitrary addresses" implementation shitshow. I look forward to finding when this actually happened at some point in my bitcoin archaeology. If, that is, I follow through in any detail.
//
From Gavin's own notes: "…accomodate higher transaction volume, and to measure what percentage of hashing power simply goes along with defaults." Read as: "we're probing the network to estimate our ability to push stuff through, and if by chance we get people to run this code the blockchain will increase in size even faster lending credence to our other efforts to put strange into the reference client in a vain attempt to reduce blockchain size". Note the plausible deniability that comes from running one campaign to "keep the blockchain small" while all the while bloating it.
http://cascadianhacker.com/blog/2014/10/20_a-summary-of-changes-to-bitcoin-since-0321.html
Topic: A summary of changes to Bitcoin since 0.3.21 (Read 1264 times)
What, no one noticed a beautiful longpoll support for getblocktemplate?
The straight dope from Cascadian Hacker:
"Please enjoy this list of and commentary on a subset1 of changes to the Bitcoin protocol.
0.9.3
OpenSSL upgrade2
0.9.2.0 - 0.9.2.1
commands getwalletinfo, getblockchaininfo, getnetworkinfo added to support detangling of getinfo
oodles of GUI work
OpenSSL -> 1.0.1h
0.9.1
OpenSSL -> 1.0.1g
0.9.0
rebranded: Bitcoin -> Bitcoin Core (BIG STUFF, YO)
autotools build process (./autogen.sh; ./configure; make)
introduction of bitcoin-cli executeable ('cause don't make a correct thing, just keep derping at its edges, crufting layer after layer of duct tape on to the poor thing…)
"malleability"3-related fixes
"IsStandard() transaction rules tightened to prevent relaying and mining of mutated transactions"4
minimum fee required for nodes to consider relaying transaction fees dropped5
"Add getrawchangeaddress call for raw transaction change destinations"6
"Reject insanely high fees by default in sendrawtransaction"7
"New RPC ping command to request ping, new pingtime and pingwait fields in getpeerinfo output"8
0.8.6
"Default block size increase for miners."9
0.8.5
"Blocks containing transactions with version numbers larger than 0x7fffffff caused the code that checks for LevelDB database inconsistencies at startup to erroneously report database corruption and suggest that you reindex your database."
0.8.1 - 0.8.3
much UI
"MacOSX: * OSX support for click-to-pay (bitcoin:)"10
"The default fee for low-priority transactions is lowered from 0.0005 BTC (for each 1,000 bytes in the transaction; an average transaction is about 500 bytes) to 0.0001 BTC."11
0.8.0
"This release no longer maintains a full index of historical transaction ids by default, so looking up an arbitrary transaction using the getrawtransaction RPC call will not work. If you need that functionality, you must run once with -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more details)."12
"LevelDB, a fast, open-source, non-relational database from Google, is now used to store transaction and block indices."13
Introduction of Bloom Filters14
0.7.2
"Prevent RPC move from deadlocking. This was caused by trying to lock the database twice."15
0.7.1
"-salvagewallet command-line option, which moves any existing wallet.dat to wallet.{timestamp}.dat and then attempts to salvage public/private keys and master encryption keys (if the wallet is encrypted) into a new wallet.dat."16
0.7.0
"Transactions with zero-value outputs are considered non-standard"17
0.6.1 - 0.6.3
"added nonce value to ping"18
0.6.0
QR codes for sending and receiving19
new RPC call: importprivkey 20
irc peer scanning disabled
DOS protections21
multisig stuff
0.5.1 - 0.5.3.1
patch integrated that disallows new transactions with the same TXID as old transactions, unless all outputs from said have been spent22
"Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries)."23
0.5.0
"The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys."
new RPC commands signmessage and verifymessage 24
0.4.0
Wallet encryption25
multithreading deadlocks26
0.3.21 - 0.3.24
UPNP enabled by default for GUI client27
"Support for full-precision bitcoin amounts."
"New rpc command sendmany to send bitcoins to more than one address in a single transaction."
The takeaway: next to nothing has been done to bring the Bitcoin project forwards since 0.5.3 (the duplicate TXID rules). This (and the comments to code ratio) speaks as strongly to the failure of C++ as an expressive language that fosters the construction of (developer) performance-enhancing abstractions as it does to the failures of the group of humans who've sprung up around the thing seeking to make a buck; make a name for themselves as "Bitcoiners" or what have you; or even just a few miserable credits in the eyes of those who would print fiat currencies endlessly by derping relentlessly at its fringes.
Bitcoin Core is stalled out. It's gone precisely nowhere since 0.5.3 (unless you count the SSL patches that should never have been necessary in the first place).
Footnotes:
1
Subset criteria: things I found interesting.
2
Not necessary in any sense of the word, as you shouldn't be securing the connection to your remote bitcoin node via SSL.
3
Malleability is not and never was a thing. Referencing transactions by the hash you supplied at the time of submission to the memory pool and not the hash the miner who found the block in which they were so courteous as to embed your transaction blessed your transaction with demonstrates a poor understanding of transaction formation and block inclusion rules. Mt. Gox claims to have lost coins to this particular subtlety of the protocol, as they tracked transactions by the TXID they themselves generated, and not those the network blessed their transactions with. TXID's are changeable, as relaying peers maintaining the memory pool can change the scripts in a transaction without affecting signature validity.
4
So instead of accepting the protocol as it exists and as it works (just dandily, thank you for asking), the solution was to enforce more uniformity and homogeneity in what transactions are relayed through the memory pool. Mind you, this only affects the memory pool of upgraded nodes. Older nodes will continue to relay these transactions to miners very happily; those miners will happily accept transactions of adequate fee regardless of their IsStandard()-ness. Exercise for bitcoin pranksters: diddle as many transactions' scripts as possible in order to make 0.9 nodes hardfork. Much lulz will be had.
5
Another fairly smart change, if you're working for the USG and want to increase block sizes. Previously, you'd have not even bothered to send small-value transactions, as the fee required for the tx to propagate to the miners would make it uneconomical. If, however, you accept the mainstream derping about "banking the unbanked" (which itself is just a PR ruse of the USG's to get their fingers into the blockchain), you'll find yourself wanting to do something stupid about minimum transaction values in the bitcoin network. Once you reduce the minimum fee for broadcasting, a whole slew of smaller transactions will want into each block. That demand will put upward pressure on the price each transaction must pay for inclusion into each 1MB block, pressure that can only be alleviated by increasing the maximum block size. So there you have it: the USG is exploiting your kindhearted desire to make the world a better place for someone to whom you're entirely unrelated to fuck up the blockchain.
6
Doubling down on the "address reuse is evil and dangerous, bad for privacy and so on!" poor decisions. Sending your change to new addresses is, in the vast majority of scenarios, entirely pointless. The "hierarchical deterministic wallet" stuff is cool: being able to back up a single master key and have an arbitrary number of addresses keyed off it trumps the current behavior by miles.
The current behavior is for every transaction to spin up new addresses for change destination. This leads to wallet backups actually expiring - a phenomenally stupid thing that fell out of the poorly-thought-through "address reuse is evil, let's send change to arbitrary addresses" implementation shitshow. I look forward to finding when this actually happened at some point in my bitcoin archaeology. If, that is, I follow through in any detail.
7
More protecting idiot BTC holders from their own idiocy.
8
Prime example of the "feature development" that goes on instead of reimplementations. Derpy diddling at the fringes of things instead of actual contributions to ecosystem.
9
From Gavin's own notes: "…accomodate higher transaction volume, and to measure what percentage of hashing power simply goes along with defaults." Read as: "we're probing the network to estimate our ability to push stuff through, and if by chance we get people to run this code the blockchain will increase in size even faster lending credence to our other efforts to put strange into the reference client in a vain attempt to reduce blockchain size". Note the plausible deniability that comes from running one campaign to "keep the blockchain small" while all the while bloating it.
10
One of my least favorite integrations with host OS's and Bitcoin: "click this link to start your Bitcoin installation!".
11
Further efforts to increase demand for transaction inclusion in blocks, this time by reducing the default fee.
12
It's not a regression if you make it happen intentionally, guys!
13
Continues with "LevelDB works much better on machines…", which is pretty funny considering the LevelDB fixes required for very large version numbers.
14
An exercise I'd like to perform myself some day: estimate how many of the Bitcoin nodes out there support bloom filters. This would be a neat proxy for upgrade-rate.
15
The braindamaged "accounts" approach to BTC management lead to deadlocks. Well done, power rangers.
16
Bitcoin is written so well that it comes with its own utility to salvage wallet files (wallet files it probably fucked up in the first place)!
17
Attempting to ban zero-valued outs was no doubt a preliminary probing of the Bitcoin source control organization to see how well it handled stupid inputs. Clearly, it is a very forgiving machine, and gave the USG the notion it could start diddling with IsStandard() in hope of forking the blockchain in their favor.
18
I have always wondered why this was done. The official line is "to identify self connections" but…what?
19
Extremely! Very! Important!
20
This one's actually moderately useful. Note for future patchers of a stripped reference client: grab this one.
21
Denial of Service patches should also be brought into any future stripped-down reference client: doubtless the Empire's planning to hit any nodes that don't comply with their pending hardfork with DOS attacks.
22
The patch itself is an interesting read. Of code-culture note, there's ~2:1 code to comment ratio. A thing heard occasionally in my shop: "Whenever you feel compelled to write a comment, don't. Then, when you've refrained from crufting up the project with comments, write a test."
Of implementation note, I'm interested to know how this is acting now that nodes don't maintain a full index of TXID's. Future research project…
23
The lulz - they flow endlessly.
24
Part of the Imperial approach to crypto FUD. This introduced the notion of signing with one's bitcoin keys. While attractive to the nerdy, this is in no way a good idea as people are bound to get the wrong idea and associate Bitcoin addresses or keys with identity in some way. We've addressed this before but I'll summarize again: addresses are transient and should be treated as such. GPG keys are identity and should be protected as such.
Don't let anyone tell you that Bitcoin signatures are in any way a thing to use when you can use the full power of GPG instead.
25
Didn't work.
26
In c++? Surely not.
27
In the name of making things easy for the technically un-savvy to use Bitcoin, this is when it began advertising its presence to your home router."
"Please enjoy this list of and commentary on a subset1 of changes to the Bitcoin protocol.
0.9.3
OpenSSL upgrade2
0.9.2.0 - 0.9.2.1
commands getwalletinfo, getblockchaininfo, getnetworkinfo added to support detangling of getinfo
oodles of GUI work
OpenSSL -> 1.0.1h
0.9.1
OpenSSL -> 1.0.1g
0.9.0
rebranded: Bitcoin -> Bitcoin Core (BIG STUFF, YO)
autotools build process (./autogen.sh; ./configure; make)
introduction of bitcoin-cli executeable ('cause don't make a correct thing, just keep derping at its edges, crufting layer after layer of duct tape on to the poor thing…)
"malleability"3-related fixes
"IsStandard() transaction rules tightened to prevent relaying and mining of mutated transactions"4
minimum fee required for nodes to consider relaying transaction fees dropped5
"Add getrawchangeaddress call for raw transaction change destinations"6
"Reject insanely high fees by default in sendrawtransaction"7
"New RPC ping command to request ping, new pingtime and pingwait fields in getpeerinfo output"8
0.8.6
"Default block size increase for miners."9
0.8.5
"Blocks containing transactions with version numbers larger than 0x7fffffff caused the code that checks for LevelDB database inconsistencies at startup to erroneously report database corruption and suggest that you reindex your database."
0.8.1 - 0.8.3
much UI
"MacOSX: * OSX support for click-to-pay (bitcoin:)"10
"The default fee for low-priority transactions is lowered from 0.0005 BTC (for each 1,000 bytes in the transaction; an average transaction is about 500 bytes) to 0.0001 BTC."11
0.8.0
"This release no longer maintains a full index of historical transaction ids by default, so looking up an arbitrary transaction using the getrawtransaction RPC call will not work. If you need that functionality, you must run once with -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more details)."12
"LevelDB, a fast, open-source, non-relational database from Google, is now used to store transaction and block indices."13
Introduction of Bloom Filters14
0.7.2
"Prevent RPC move from deadlocking. This was caused by trying to lock the database twice."15
0.7.1
"-salvagewallet command-line option, which moves any existing wallet.dat to wallet.{timestamp}.dat and then attempts to salvage public/private keys and master encryption keys (if the wallet is encrypted) into a new wallet.dat."16
0.7.0
"Transactions with zero-value outputs are considered non-standard"17
0.6.1 - 0.6.3
"added nonce value to ping"18
0.6.0
QR codes for sending and receiving19
new RPC call: importprivkey 20
irc peer scanning disabled
DOS protections21
multisig stuff
0.5.1 - 0.5.3.1
patch integrated that disallows new transactions with the same TXID as old transactions, unless all outputs from said have been spent22
"Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries)."23
0.5.0
"The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys."
new RPC commands signmessage and verifymessage 24
0.4.0
Wallet encryption25
multithreading deadlocks26
0.3.21 - 0.3.24
UPNP enabled by default for GUI client27
"Support for full-precision bitcoin amounts."
"New rpc command sendmany to send bitcoins to more than one address in a single transaction."
The takeaway: next to nothing has been done to bring the Bitcoin project forwards since 0.5.3 (the duplicate TXID rules). This (and the comments to code ratio) speaks as strongly to the failure of C++ as an expressive language that fosters the construction of (developer) performance-enhancing abstractions as it does to the failures of the group of humans who've sprung up around the thing seeking to make a buck; make a name for themselves as "Bitcoiners" or what have you; or even just a few miserable credits in the eyes of those who would print fiat currencies endlessly by derping relentlessly at its fringes.
Bitcoin Core is stalled out. It's gone precisely nowhere since 0.5.3 (unless you count the SSL patches that should never have been necessary in the first place).
Footnotes:
1
Subset criteria: things I found interesting.
2
Not necessary in any sense of the word, as you shouldn't be securing the connection to your remote bitcoin node via SSL.
3
Malleability is not and never was a thing. Referencing transactions by the hash you supplied at the time of submission to the memory pool and not the hash the miner who found the block in which they were so courteous as to embed your transaction blessed your transaction with demonstrates a poor understanding of transaction formation and block inclusion rules. Mt. Gox claims to have lost coins to this particular subtlety of the protocol, as they tracked transactions by the TXID they themselves generated, and not those the network blessed their transactions with. TXID's are changeable, as relaying peers maintaining the memory pool can change the scripts in a transaction without affecting signature validity.
4
So instead of accepting the protocol as it exists and as it works (just dandily, thank you for asking), the solution was to enforce more uniformity and homogeneity in what transactions are relayed through the memory pool. Mind you, this only affects the memory pool of upgraded nodes. Older nodes will continue to relay these transactions to miners very happily; those miners will happily accept transactions of adequate fee regardless of their IsStandard()-ness. Exercise for bitcoin pranksters: diddle as many transactions' scripts as possible in order to make 0.9 nodes hardfork. Much lulz will be had.
5
Another fairly smart change, if you're working for the USG and want to increase block sizes. Previously, you'd have not even bothered to send small-value transactions, as the fee required for the tx to propagate to the miners would make it uneconomical. If, however, you accept the mainstream derping about "banking the unbanked" (which itself is just a PR ruse of the USG's to get their fingers into the blockchain), you'll find yourself wanting to do something stupid about minimum transaction values in the bitcoin network. Once you reduce the minimum fee for broadcasting, a whole slew of smaller transactions will want into each block. That demand will put upward pressure on the price each transaction must pay for inclusion into each 1MB block, pressure that can only be alleviated by increasing the maximum block size. So there you have it: the USG is exploiting your kindhearted desire to make the world a better place for someone to whom you're entirely unrelated to fuck up the blockchain.
6
Doubling down on the "address reuse is evil and dangerous, bad for privacy and so on!" poor decisions. Sending your change to new addresses is, in the vast majority of scenarios, entirely pointless. The "hierarchical deterministic wallet" stuff is cool: being able to back up a single master key and have an arbitrary number of addresses keyed off it trumps the current behavior by miles.
The current behavior is for every transaction to spin up new addresses for change destination. This leads to wallet backups actually expiring - a phenomenally stupid thing that fell out of the poorly-thought-through "address reuse is evil, let's send change to arbitrary addresses" implementation shitshow. I look forward to finding when this actually happened at some point in my bitcoin archaeology. If, that is, I follow through in any detail.
7
More protecting idiot BTC holders from their own idiocy.
8
Prime example of the "feature development" that goes on instead of reimplementations. Derpy diddling at the fringes of things instead of actual contributions to ecosystem.
9
From Gavin's own notes: "…accomodate higher transaction volume, and to measure what percentage of hashing power simply goes along with defaults." Read as: "we're probing the network to estimate our ability to push stuff through, and if by chance we get people to run this code the blockchain will increase in size even faster lending credence to our other efforts to put strange into the reference client in a vain attempt to reduce blockchain size". Note the plausible deniability that comes from running one campaign to "keep the blockchain small" while all the while bloating it.
10
One of my least favorite integrations with host OS's and Bitcoin: "click this link to start your Bitcoin installation!".
11
Further efforts to increase demand for transaction inclusion in blocks, this time by reducing the default fee.
12
It's not a regression if you make it happen intentionally, guys!
13
Continues with "LevelDB works much better on machines…", which is pretty funny considering the LevelDB fixes required for very large version numbers.
14
An exercise I'd like to perform myself some day: estimate how many of the Bitcoin nodes out there support bloom filters. This would be a neat proxy for upgrade-rate.
15
The braindamaged "accounts" approach to BTC management lead to deadlocks. Well done, power rangers.
16
Bitcoin is written so well that it comes with its own utility to salvage wallet files (wallet files it probably fucked up in the first place)!
17
Attempting to ban zero-valued outs was no doubt a preliminary probing of the Bitcoin source control organization to see how well it handled stupid inputs. Clearly, it is a very forgiving machine, and gave the USG the notion it could start diddling with IsStandard() in hope of forking the blockchain in their favor.
18
I have always wondered why this was done. The official line is "to identify self connections" but…what?
19
Extremely! Very! Important!
20
This one's actually moderately useful. Note for future patchers of a stripped reference client: grab this one.
21
Denial of Service patches should also be brought into any future stripped-down reference client: doubtless the Empire's planning to hit any nodes that don't comply with their pending hardfork with DOS attacks.
22
The patch itself is an interesting read. Of code-culture note, there's ~2:1 code to comment ratio. A thing heard occasionally in my shop: "Whenever you feel compelled to write a comment, don't. Then, when you've refrained from crufting up the project with comments, write a test."
Of implementation note, I'm interested to know how this is acting now that nodes don't maintain a full index of TXID's. Future research project…
23
The lulz - they flow endlessly.
24
Part of the Imperial approach to crypto FUD. This introduced the notion of signing with one's bitcoin keys. While attractive to the nerdy, this is in no way a good idea as people are bound to get the wrong idea and associate Bitcoin addresses or keys with identity in some way. We've addressed this before but I'll summarize again: addresses are transient and should be treated as such. GPG keys are identity and should be protected as such.
Don't let anyone tell you that Bitcoin signatures are in any way a thing to use when you can use the full power of GPG instead.
25
Didn't work.
26
In c++? Surely not.
27
In the name of making things easy for the technically un-savvy to use Bitcoin, this is when it began advertising its presence to your home router."
Jump to: