YA crazy bitcoin project
This project is maintained by Rusty Russell
I spoke on pettycoin at linux.conf.au last week. In practice, it’s 80% an explanation of the bitcoin protocol and the sidechains proposal, which I haven’t seen covered in significant technical detail before. (continues…)
This is the seventh in a series analyzing the pettycoin implementation against Gregory Maxwell’s writeup on scaling. The first talked about UTXO commitments vs backrefs, the second talked about Propogation servers vs prev_txhashes, the third talked about Hashed Fees vs Random Extrapolation, the fourth talked about Simplified Transactions vs Normal Bitcoin Transactions, the fifth discussed Fast blocks vs Bitcoin blocks. and the sixth Fees and Horizons for A Microtransaction Sidechain.(continues…)
This is the sixth in a series analyzing the pettycoin implementation against Gregory Maxwell’s writeup on scaling. The first talked about UTXO commitments vs backrefs, the second talked about Propogation servers vs prev_txhashes, the third talked about Hashed Fees vs Random Extrapolation, the fourth talked about Simplified Transactions vs Normal Bitcoin Transactions, and the fifth discussed Fast blocks vs Bitcoin blocks.(continues…)
This is the fifth in a series analyzing the pettycoin implementation against Gregory Maxwell’s writeup on scaling. The first talked about UTXO commitments vs backrefs, the second talked about Propogation servers vs prev_txhashes, the third talked about Hashed Fees vs Random Extrapolation, and the fourth talked about Simplified Transactions vs Normal Bitcoin Transactions(continues…)
This is the fourth in a series analyzing the pettycoin implementation against Gregory Maxwell’s writeup on scaling. The first talked about UTXO commitments vs backrefs, the second talked about Propogation servers vs prev_txhashes, and the third talked about Hashed Fees vs Random Extrapolation.(continues…)
This is the third in a series analyzing the pettycoin implementation against Gregory Maxwell’s writeup on scaling. The first talked about UTXO commitments vs backrefs and the second talked about Propogation servers vs prev_txhashes.(continues…)
One key problem with any system where you only need to know part of the blocks to contribute, is that you need to be sure that the information is available: that someone can tell you anything you need. (continues…)
Since blockstream released their fascinating sidechains paper I’ve been discussing related ideas with Gregory Maxwell. Sidechains are a method of automating the 1:1 bitcoin pegging (which pettycoin uses); it will require a soft-fork of the bitcoin protocol, which is why I never persued such a direction. The interest in side-chains suggests it’s a medium-term possibility, however. (continues…)
Gavin Andresen of bitcoin fame posted a github gist a while ago, about using IBLTs to send block transaction summaries across the bitcoin network. (continues…)
One problem with bitcoin blocks is the irregular timing between them. If you’re waiting for inclusion in a block to make double-spending more difficult, the formula you need to know is is 1-e^(-(T/600)): this says the probability that a block has been found at time T seconds. At T=600 (ie. 10 minutes) it’s 63%: in fact most blocks are found in under 7 minutes, but there’s a long tail. 14% of the time you’re still waiting after 20 minutes, and 5% of the time you’re waiting over 30 minutes with no confirmation, and 1% are over 46 minutes. (continues…)
There’s an interesting post on scaling by Vitalik Buterin over at the Ethereum blog. I always read these posts with excitement and a little trepidation, as I wonder if they’ll come up with some scaling trick I missed for pettycoin… (continues…)
After a three week holiday, I’m now caught up with my mail and backlog of kernel work, and am finally back to pettycoin. (continues…)
Bitcoin has a very simple structure: the header is merely 80 bytes: (continues…)
When I looked at the goals for Alpha02, I realized I’d be breaking the protocol, so I decided I wanted to do all the breakage at once. The first change is to include more than one “prev” reference in each block. (continues…)
It will be a quiet week for pettycoin this week: I’m away at Kernel Summit. But I did submit a talk to linux.conf.au about pettycoin! (continues…)
I realized I was out by a factor of 10 on horizons: instead of 30 days, it was 300 days (120 hours instead of 12 hours for the test network). (continues…)
A user (wow, I have a user!) reported several bugs, but the coolest
was that dumbwallet would freeze talking to pettycoin. Indeed,
strace revealed that after a successful poll() write() on a socket
was taking 90 seconds! You can see the gory details in the
ccan commit.
Without O_NONBLOCK it doesn’t do the complete write, but it doesn’t
return without blocking either. I didn’t expect O_NONBLOCK to make
a difference on a ready socket.
(continues…)
Lots of bugfixing on alpha01: nothing like having two servers running for a week to shake things loose! (continues…)
Joel ran up pettycoin, and indeed, there were bugs. Most importantly,
it got very upset with not being able to find 16 peers (--seeding
fixes that).
(continues…)
The gateway (bitcoin -> pettycoin only!) is finished, and dumbwallet is too. So I pushed and tagged the release v-alpha01. (continues…)
Although last week was school holidays, I slowly scratched off items on the TODO list. This week was more polishing: a web page with FAQ and code of conduct, and a mailing list. (continues…)
One big item on my todo list was JSON-RPC. This is what bitcoind uses, so it makes sense for pettycoin to do the same. You can see the bitcoin JSON API here. (continues…)
It seems that I’m closing out the early, furious development phase this week. The project now has 285 commits, and 152 of those have been since I’ve been on sabbatical: 78 in the last two weeks. (continues…)
Preventing double spending is the raison d’etre for the blockchain, so it’s a little weird that I implemented it so late. Yet it’s fairly trivial, and the initial implementation (sans testing!) only took a day. Obviously it’s illegal for two transactions which spend the same output to appear in the same chain of blocks (disallowing the same transaction appearing twice is a corollary of this rule). So I maintain a hash of inputs requested by each transaction, and implemented the complaint packet to show when this happens, as well as a polite notification when someone sends you a transaction which clashes with a known one. (continues…)
Pettycoin relies on partial knowledge, but until today the code assumed we needed to know transaction in every shard in every block. (continues…)
In pettycoin, blocks contain shards, and shards contain
transactions. These are represented by struct block, struct block_shard
and then the transactions (or hashes, or NULL).
(continues…)
One key idea of pettycoin is that of complaint packets, which allow one node to prove that there is a problem with a block in a compact form, and not requiring any other knowledge by the recipient. For example, consider if you put a transaction in a block which tries to use one my transactions as an input. To show that the block is invalid, I only need send my transaction, your transaction, and proof that your transaction is in that block. (continues…)
Pettycoin has a simple “mining” program called generate. The main
program feeds it transaction positions and hashes on stdin, and it
outputs a block (if it finds one) on stdout.
(continues…)
Late yesterday I realized that one of my grand plans was not going to work. This morning I fixed it. (continues…)
It started with some minor cleanups: the error PROTOCOL_INVALID_LEN
should be called PROTOCOL_ERROR_INVALID_LEN to match the other errors.
That became changing PROTOCOL_ERROR to PROTOCOL_ECODE everywhere.
(continues…)
I entered today intending to shrink this structure: (continues…)
Since I spent the end of last week changing the structure of blocks, it was time to blow the cobwebs off the unit tests. I stopped maintaining those when I realized just how much the project was in flux: I didn’t want to spend a good portion of my time refactoring test code. (continues…)
I recently moved the depth into the header, so I decided to use spatch to help with the grunt work. I’ve used it once before, and a little googling lead me to this: (continues…)
The point of pettycoin is that you don’t need to know all transactions in a block to be useful: you can publish a compact standalone proof of anything which could possibly be malformed about a block, which the code calls a “complaint”. (continues…)
When I started thinking about pettycoin my head was full of proof-of-work, and similar protocol issues. When I started implementing pettycoin I quickly got bogged down in the minutia of networking between pettycoin nodes. So I decided to implement the most familiar thing: a command-response protocol. (continues…)
Since my wonderful wife convinced me to take a six month sabbatical I’ll be posting the gory details of my work on pettycoin here. Four days of pettycoin hacking, and one day of baby-wrangling and keeping up with my other miscellaneous projects (linux kernel maintenance and virtio standards). (continues…)