Author Archives: rusty

I used bitcoin-iterate and gnumeric to render the current bitcoin blocksizes, and here are the results. My First Graph: A Moment of Panic This is block sizes up to yesterday; I’ve asked gnumeric to derive an exponential trend line from the data (in black; the red one is linear) That trend line hits 1000000 at …

Continue reading “Current Blocksize, by graphs.”

I’ve been trying not to follow the Great Blocksize Debate raging on reddit.  However, the lack of any concrete numbers has kind of irked me, so let me add one for now. If we assume bandwidth is the main problem with running nodes, let’s look at average connection growth rates since 2008.  Google lead me …

Continue reading “Block size: rate of internet speed growth since 2008?”

Previously I discussed the use of IBLTs (on the pettycoin blog).  Kalle and I got some interesting, but slightly different results; before I revisited them I wanted some real data to play with. Finally, a few weeks ago I ran 4 nodes for a week, logging incoming transactions and the contents of the mempools when …

Continue reading “Some bitcoin mempool data: first look”

This is the fourth part of my series of posts explaining the bitcoin Lightning Networks 0.5 draft paper.  See Part I, Part II and Part III. The key revelation of the paper is that we can have a network of arbitrarily complicated transactions, such that they aren’t on the blockchain (and thus are fast, cheap …

Continue reading “Lightning Networks Part IV: Summary”

This is the third part of my series of posts explaining the bitcoin Lightning Networks 0.5 draft paper. In Part I I described how a Poon-Dryja channel uses a single in-blockchain transaction to create off-blockchain transactions which can be safely updated by either party (as long as both agree), with fallback to publishing the latest …

Continue reading “Lightning Networks Part III: Channeling Contracts”

In Part I, we demonstrated Poon-Dryja channels; a generalized channel structure which used revocable transactions to ensure that old transactions wouldn’t be reused. A channel from me<->you would allow me to efficiently send you 1c, but that doesn’t scale since it takes at least one on-blockchain transaction to set up each channel. The solution to …

Continue reading “Lightning Networks Part II: Hashed Timelock Contracts (HTLCs)”

[ Note for new readers: the mechanisms described here are from the original LN draft.   These days instead of throwaway keys we use hash preimages for revocation, and output scripts are used for HTLCs, as per https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf ] I finally took a second swing at understanding the Lightning Network paper.  The promise of this …

Continue reading “Lightning Networks Part I: Revocable Transactions”

With the 1.0 virtio standard finalized by the committee (though minor non-material corrections and clarifications are still trickling in), Michael Tsirkin did the heavy lifting of writing the Linux drivers (based partly on an early prototype of mine). But I wanted an independent implementation to test: both because OASIS insists on multiple implementations before standard …

Continue reading “lguest Learns PCI”

My previous discovery that poll() indicating an fd was writable didn’t mean write() wouldn’t block lead to some interesting discussion on Google+. It became clear that there is much confusion over read and write; eg. Linus thought read() was like write() whereas I thought (prior to my last post) that write() was like read(). Both …

Continue reading “POLLOUT doesn’t mean write(2) won’t block: Part II”

There are numerous C async I/O libraries; tevent being the one I’m most familiar with.  Yet, tevent has a very wide API, and programs using it inevitably descend into “callback hell”.  So I wrote ccan/io. The idea is that each I/O callback returns a “struct io_plan” which says what I/O to do next, and what …

Continue reading “ccan/io: revisited”