October 25, 2014

Notes on Increasing the Maximum Bitcoin Block Size (or, "Why it ain't happenin'")

Filed under: Uncategorized — @ 12:00 a.m.
Notes on Increasing the Maximum Bitcoin Block Size (or, "Why it ain't happenin'")

Please allow me to share some research that I've done into the topic of increasing the block size maximum, and the opinions that I've formed along the way1.


Specific notes on Gavin Andresen's "Blocksize Economics":

  • Andresen claims:

    …economic theory says that in a competitive market, supply, demand, and price will find an equilibrium where the price is equal to the marginal cost to suppliers plus some net income (because suppliers can always choose to do something more profitable with their time or money).

    In the case of Bitcoin, this is categorically false: Bitcoin miners must purchase ASICs4. To use the claim that miners can pack their bags and do other things to justify this other claim that "the market will prevail/provide" is a complete farce.

  • In the linked piece, Andresen never mentions the actual reason that Satoshi imposed a block limit. Oleg Andreev, however, does:

    Huge blocks could lead to excessive use of bandwidth which could lead to higher percentage of orphaned blocks due to higher synchronization delays.

    If I'm reading history correctly, Satoshi imposed a maximum block size of 1MB to address the Denial of Service attacks performed against the Bitcoin network using arbitrarily large blocks (~2010) when blocks could still be minted by dilletantes with CPUs.

  • Andresen claims:

    Transaction confirmation speed is important for most small-value transactions, so it is likely they will be secured using semi-trusted third parties who co-sign transactions and guarantee to never allow double-spending.

    That third party is the blockchain. To propose off-chain solutions for a non-problem suggests the proposer is dangerously out of touch with actual blockchain economics. The blockchain is secured by the means provided in Bitcoin - nothing less, and nothing more. This claim could be reworded thusly, without losing any content and gaining some clarity:

    Some holders of Bitcoin trust Coinbase to both hold their coins and transfer them to other Coinbae holders. All such "holders" of "Bitcoins" leverage Coinbase's advanced database technologies to broadcast transactions within the Coinbase network and further trust Coinbase to never allow double spends.

    Trusting any party but the Bitcoin network itself to secure transactions is the height of folly.

Specific notes on Gavin Andresen's "A Scalability Roadmap":

  • the "'pruned' block database":
    The actual blockchain cannot be pruned and still remain a blockchain5. What is proposed is that clients maintain a "database" of unspent transactions in (lossy, easily corruptible) memory; a database against which new blocks and new transactions can be compared to see that in fact all outputs in the new blocks are formed from inputs in the unspent transactions pool (referred to in the literature as the UTXO, or close as I can tell, "unspent transaction output").
    Missing from this Pull Request is an answer to the question of "what should a client do should they see a transaction whose inputs are not in the UTXO?". Charitably, I could not possibly say. Uncharitably, I must assume that the USG is exerting some influence on those who "maintain" "Bitcoin Core" in order to degrade the performance of as many full nodes in the wild as possible. Only with the network (fragile and full of indeterminate behavior as it is) weakened even further does that organization stand the slightest chance of imposing their will upon it.
  • Andresen claims:

    You might be surprised that old blocks aren't needed to validate new transactions. Pieter Wuille re-architected Bitcoin Core a few releases ago so that all of the data needed to validate transactions is kept in a 'UTXO' (unspent transaction output) database.

    For a node to be considered a full node, it must validate transactions against a blockchain that the node itself has validated in its entirety. Anything shy of that is not a full node, and it does not actually validate transactions. Should the pruning be implemented on the basis of a UTXO argument, nodes will be forced to download the blockchain in its entirety to validate transactions about which they're unsure. Why then bother?

  • Andresen notes the validity of these claims, almost pooh-pooing them:

    a proposal from Mark Friedenbach for how to embed such a commitment [ed: a UTXO hashing scheme to enable peers to ask for the UTXO set instead of the full blockchain6] in blocks hasn't reached consensus, and neither have discussions about exactly how the UTXO set should be represented and hashed.

  • Andresen assumes the sale7 on the extremely contentious notion of increasing the block size:

    The next scaling problem that needs to be tackled is the hardcoded 1-megabyte block size limit that means the network can suppor [sic] only approximately 7-transactions-per-second.

    First off, I don't agree that the Bitcoin protocol must support any more transactions per second than it currently does. Consider that average block sizes are currently a third of their theoretical maximum, and that few people are doing much to minimize their transaction sizes. Before we discuss diddling our scarcity numbers, let's actually watch the network's behavior at steady state when it does bump up against those numbers.

  • A myth that Andresen promulgates:
    1. Connect to peers, just as is done today.
    2. Download headers for the best chain from its peers (tens of megabytes; will take at most a few minutes)
    3. Download enough full blocks to handle and reasonable blockchain re-organization (a few hundred should be plenty, which will take perhaps an hour).
    4. Ask a peer for the UTXO set, and check it against the commitment made in the blockchain.

    This myth misses a core point about Bitcoin: it's not something that one just discovers, dabbles in, and voila can run with the big dogs of. It's something you approach carefully, quietly, and humbly for it is so much larger and scarier than yourself.

    The analogy that I use when talking about it with civilians is that it's radioactive money. Hard dollars in a bank account are great, sure; but when I can point to my (negligible) bitcoin stash and say that "this is thus and such fraction of all the BTC that will ever exist", that's downright radioactive money technology compared to the dollar. Dollars waste away every year unless one sticks them in inflation-resistant assets, and the Bitcoin simply does no such thing. Radioactive, I tell you.

    In this story, taking a week or even a month to sync the blockchain should be no big deal. If you need to use Bitcoins quickly and you've never set your tooling up you'll simply be shit out of luck. Doing well in this life requires planning, foresight, and execution. Diddling Bitcoin to hold the hands of people who lack foresight and the ability to plan and subsequently execute is a recipe for no soup I'll dine on.

I've known for years that 21 million was a magical number - that is the sum of all Bitcoins that could ever exist, and on this research trip I've learned that there is a second magic number: 1 megabyte. The fixed and predictable supply of Bitcoins means that we can all evaluate our holdings in terms of both todays circulation and tomorrows circulation. Were the USG or any other fiat institution to mess with that 21M, they'd be able to enslave the whole world all over again by creating more money out of thin air. As difficult as it is to predict the ROI of mining, let's not give the miners yet another headache in their simulations, that of estimating the maximum block size and the demand for transactions at some point in the future.

Andresen has this vision to convey about the future of the block size:

Roll out a hard fork that increases the maximum block size, and implements a rule to increase that size over time, very similar to the rule that decreases the block reward over time.

Choose the initial maximum size so that a 'Bitcoin hobbyist' can easily participate as a full node on the network. By 'Bitcoin hobbyist' I mean somebody with a current, reasonably fast computer and Internet connection, running an up-to-date version of Bitcoin Core and willing to dedicate half their CPU power and bandwidth to Bitcoin.

And choose the increase to match the rate of growth of bandwidth over time: 50% per year for the last twenty years. Note that this is less than the approximately 60% per year growth in CPU power; bandwidth will be the limiting factor for transaction volume for the foreseeable future.

Andresen explicitly seeks to slip fiat dynamics into Bitcoin via block sizes, disregarding hard limits in the P2P protocol and the importance of holding the line on the ideology of scarce resources.

Enshrine a second number of scarcity: 1 megabyte. The alternative is an ever-increasing block size; a world with no scarcity in transaction space; and negligible mining fees after the block reward goes to zero. In a world where the block size increases regularly, the reward for mining will decline far more precipitiously than it would otherwise, giving the fiat governments another chance to prevent Bitcoin wresting the control of capital from their hands.



I am, however, just some dog with a computer. I advise you to do your own research and form your own opinions. If you've not the time to do that – you could do worse than reading this summary and the links so included.


Rumor has it that Bitcoin P2P messages of 32 MB in size don't even transmit reliably between peers. If a message of 32 MB can't transmit between peers reliably, bringing the maximum block size anywhere near that line is a terrible idea.


This suggests an average transaction size of 251.969 bytes per transaction. Not unfair - my random sample of 3 transactions clocked in at ~253B bytes.


An ASIC is an Application Specific Intgrated Circuit. That is to say that it cannot be repurposed for anything other than computing SHA-256 (the Bitcoin mining algorithm) at high speeds.


For one to have "a blockchain", one must: have a copy of every block; every block must be untruncated; every transaction must be confirmed to be valid. Anything short of that is a scamchain.




Meaning that he's written this assuming that the reader agrees with the claim he then makes: the network must be pushed to support far more than 7 transactions per second. This is poor writing in the first place, poor rhetoric in the second, and ultimately downright disingenous.

October 22, 2014

Technical Flaws in Early Ether Wallet Implementations

Filed under: Uncategorized — @ 12:00 a.m.
Technical Flaws in Early Ether Wallet Implementations

It's hard to tell if this is intentional or accidental:

The payment has already been registered by the website and we can proceed to download the wallet file. @abarkn1

Securing one's wallet requires that one generate keys offline and away from any meddling fingers. This is because nobody can be trusted to generate your keys for you, as you must also trust them to not run away with your money.2

Charitable interpretations:

  • the software that is Ether is too raw for end users
  • it might be brought to market before it's robust enough to survive

If the software is too raw for end-users, who are the target users? Nominal "cryptocurrency application developers"? There are none such who are inadequately technical to use alpha-grade software3. If the software is not robust enough to survive the harsh light of day, consider it stillborn and walk away. The Spartan (myth?) of leaving new children on the back porch to demonstrate fitness carries within it a grain of knowledge for those who can tease it out. Bitcoin is so strong that even crippled by Satoshi4 and the power rangers5 it's still strolling around the net, making a mockery of the best moles in the business of compromising open-source cryptography software.

The uncharitable interpretation:

  • No software beyond some rudimentary key generation algorithms have been written6

The Ether developers appear to be doubling down on the guaranteed premine scam. In addition to all of their own vaporware cryptocurrency they'll fabricate and dump directly into their pockets, they've now committed to fabricating another epic pile and dumping those into the pockets of those foolish enough to preorder a cryptocurrency7.



A handle which is intended to stand for Andreas Brekken but I can't help reading as "a barking", and appending amusing strings.


Interesting stories from early BTC days still float around of a gentleman who would generate "extra large" GPG keys - for other people. He's not around anymore, as sharing keys doesn't fly with people who understand how this shit works and care that it be handled correctly. "You're using one of those weird large keys? And you BOUGHT it?!" Trading wallets, while not unheard-of, is pro-grade cryptocurrency stuff.


There are plenty of chumps, however, who are inadequately technical to understand the braindamage of purchasing keys, and are dropping their lifetime savings into a lotto ticket in hopes of striking the "next Bitcoin".


Ne'er have I seen such a marriage of quality technical vision and flawed execution. Perhaps there's something to that Application Architect role I keep hearing about…


You assholes get no such praise.


Go read their blog. It's full of lulz about getting multiple applications running on the same machine and client interoperability issues BEFORE THEY'VE PUBLISHED A SINGLE LINE OF CODE.


All one can really do is shrug and chuckle. If the words "preorder a crptocurrency" don't bring a smile to your face and make you chuckle a little bit, what the fuck are you doing reading my blog? Shouldn't you be reading and wasting your money on dice sites with statistically verifiable -EV experiences for the trivial having?

October 21, 2014

Instructions on Building Bitcoin 0.5.3 from Source on Debian 6 (Squeeze)

Filed under: Uncategorized — @ 12:00 a.m.
Instructions on Building Bitcoin 0.5.3 from Source on Debian 6 (Squeeze)

You might have guessed from my last post regarding the utter irrelevance of all work done on "Bitcoin Core" since the 0.5.3 release (and arguably since the wallet encryption fix release, as TXID's aren't terribly important in the ways that most people derping on the topic would like them to be) that I was working on some Bitcoin archaeology1. My research confirms La Serenissima's whispered imperative to never run anything of a later vintage than 0.6.3 and go beyond that to make a strong case against anything past 0.5.3.

In this post, I present a small script (more a set of guidelines, really) that provisions a bitcoind daemon of March 2011 vintage onto a Debian 6 box2:


update_packages() {
    echo "updating system packages, installing bitcoind dependencies"
    sudo apt-get update && sudo apt-get -y upgrade
    sudo apt-get install -y build-essential libssl-dev libdb4.8-dev libdb4.8++-dev libboost-all-dev wget git

get_bitcoin() {
    echo "cloning the official bitcoin repository"
    cd ~
    git clone

build_bitcoind() {
    echo "building bitcoin"
    local tag="$1"
    cd ~/bitcoin/src
    git checkout "$tag"
    sed -i 's/USE_UPNP:=0/USE_UPNP=/1' ./makefile.unix
    make -f makefile.unix

install_bitcoind() {
    echo "installing bitcoin"
    sudo cp ~/bitcoin/src/bitcoind /usr/bin/bitcoind
    sudo chmod +x /usr/bin/bitcoind
    ls ~/.bitcoin || mkdir ~/.bitcoin
    cat > ~/.bitcoin/bitcoin.conf << "END"

start_bitcoind() {
    echo "starting and daemonizing bitcoind"
    bitcoind -daemon -nolisten

build_bitcoind "v0.5.3"

Script instructions for those who need it:

  • Get (access to) a Debian 6 (aka Squeeze) server
  • Copy the script and dump it onto your drive, naming it
  • Squirt the script onto the remote machine:
    cat | ssh you@YOUR_SQUEEZE_BOX
  • Then ssh you@YOUR_SQUEEZE_BOX, and du -h to watch your .bitcoin directory fill up
  • Also, run bitcoind getblocknumber and compare that to the "last block" value shown at any of the popular block explorers to get a notion of how far behind the tip of the blockchain your bitcoind installation is

    I hope you're renting a VPS with enough space…

Things to note:

  • RPC user and password are set to bad values. Hie thee to ~/.bitcoin/bitcoin.conf and change them to sensible ones.
  • The start_bitcoind function handles the -daemon and -nolisten flags, which run the thing in the background and tell it to not listen to the outside world. I'm not entirely certain about how this is implemented, so if you're considering taking a dependency on this approach…look into it yourself. Also, if you run the thing yourself from the command line on your Debian box, remember to pass those flags along - this install does not hold your hand through the SystemV integration: that you'll have to handle yourself.
  • The script is not signed. Conveniently, I'm not a fan of copyright either, so if it passes your personal code review feel free to do whatever with it (including the authorship notice would be nice, though). Just don't come crying to me when this derpy website gets MITM'd and your box gets hosed and the USG runs off with your coins.

So go forth and merrily ruin the day of those who would force their own shitty view of the world onto Bitcoin. Run an old node. Be a hero.



Three years! That's an eternity in Bitcoin!


It's really more of a proof of concept than a script. If you want it to run on Ubuntu, well, that's your problem.

October 20, 2014

A summary of changes to Bitcoin since 0.3.21

Filed under: Uncategorized — @ 12:00 a.m.
A summary of changes to Bitcoin since 0.3.21

Please enjoy this list of and commentary on a subset1 of changes to the Bitcoin protocol.

  • 0.9.3
    • OpenSSL upgrade2
  • -
    • 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 (./; ./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 -
    • 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).



Subset criteria: things I found interesting.


Not necessary in any sense of the word, as you shouldn't be securing the connection to your remote bitcoin node via SSL.


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.


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.


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.


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.


More protecting idiot BTC holders from their own idiocy.


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.


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.


One of my least favorite integrations with host OS's and Bitcoin: "click this link to start your Bitcoin installation!".


Further efforts to increase demand for transaction inclusion in blocks, this time by reducing the default fee.


It's not a regression if you make it happen intentionally, guys!


Continues with "LevelDB works much better on machines…", which is pretty funny considering the LevelDB fixes required for very large version numbers.


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.


The braindamaged "accounts" approach to BTC management lead to deadlocks. Well done, power rangers.


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


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.


I have always wondered why this was done. The official line is "to identify self connections" but…what?


Extremely! Very! Important!


This one's actually moderately useful. Note for future patchers of a stripped reference client: grab this one.


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.


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…


The lulz - they flow endlessly.


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.


Didn't work.


In c++? Surely not.


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.