|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: Pettycoin Revisited Part V: Fast Blocks |
| 4 | +commentIssueId: 42 |
| 5 | +--- |
| 6 | +> This is the fifth in a series analyzing the pettycoin implementation |
| 7 | +> against Gregory Maxwell's |
| 8 | +> [writeup on scaling](https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs). |
| 9 | +> The first talked about |
| 10 | +> [UTXO commitments vs backrefs](http://rustyrussell.github.io/pettycoin/2014/11/29/Pettycoin-Revisted-Part-I:-UTXO-Commitments.html), |
| 11 | +> the second talked about [Propogation servers vs prev_txhashes](http://rustyrussell.github.io/pettycoin/2014/12/04/Pettycoin-Revisited-Part-II:-Proof-of-Propogation.html), |
| 12 | +> the third talked about [Hashed Fees vs Random Extrapolation](http://rustyrussell.github.io/pettycoin/2014/12/04/Pettycoin-Revisited-Part-III:-Miner-Rewards.html), and |
| 13 | +> the fourth talked about [Simplified Transactions vs Normal Bitcoin Transactions](http://rustyrussell.github.io/pettycoin/2014/12/05/Pettycoin-Revisited-Part-IV:-Simplified-Transactions.html) |
| 14 | +
|
| 15 | +Bitcoin uses an average of 10 minutes between blocks, whereas |
| 16 | +pettycoin uses 10 seconds. I chose 10 seconds by standing in front of |
| 17 | +an automated checkout at the supermarket and counting how long until I |
| 18 | +got annoyed: it was about 5 seconds, which is the average wait time if |
| 19 | +blocks were exactly 10 seconds apart. |
| 20 | + |
| 21 | +## Pettycoin Solution ## |
| 22 | + |
| 23 | +Pettycoin's network protocol always handed block headers, then had |
| 24 | +separate queries to fill in the contents (a natural consequence of |
| 25 | +designing a system where nodes only needed partial knowledge). It had |
| 26 | +a canonical transaction ordering to help with transaction guessing, |
| 27 | +but didn't have anything as sophisticated as |
| 28 | +[Invertible Bloom Lookup Tables](https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2). |
| 29 | + |
| 30 | +Since 10 seconds is getting close to the network latency, pettycoin |
| 31 | +was designed to use [GHOST](https://eprint.iacr.org/2013/881.pdf) to |
| 32 | +limit divergence. Since it never left the test net, the practicality |
| 33 | +of this approach was never tested (and indeed, never implemented |
| 34 | +fully). |
| 35 | + |
| 36 | +By itself, 10 second block times don't provide a good experience, however: |
| 37 | +15% of the time you'll be waiting over 20 seconds for the next block, due |
| 38 | +to the long tail of block times. |
| 39 | + |
| 40 | +Hence my |
| 41 | +[proposal to limit variance](http://rustyrussell.github.io/pettycoin/2014/10/30/More-Regular-Block-Times.html), |
| 42 | +which was never deployed, and which made Gregory Maxwell nervous. The |
| 43 | +proposal feels a little dirty, leaning more on the real-time network |
| 44 | +behaviour (in particular, the delay since the previous received block) |
| 45 | +to accept a block. Bitcoin only relies on this for refusing blocks |
| 46 | +more than 2 hours in the future, which is an uncommon case. |
| 47 | + |
| 48 | +The costs of having 10x faster block times are 10x larger headers. |
| 49 | +For bitcoin, the header is 80 bytes, and 80 bytes every 10 seconds is |
| 50 | +still very cheap. But merge mining raises the header to the `bitcoin |
| 51 | +header` + `coinbase` + log2(`number-of-mergemined-chains`) * |
| 52 | +`hashsize` + `pettycoin header`. Which is more like 80 + 100 + 8 * |
| 53 | +32 + 80 = 516 bytes, though if previous block hashes are merkled in, |
| 54 | +you require some additional hashes, making the minimal block size |
| 55 | +around 600 bytes. |
| 56 | + |
| 57 | +For pettycoin, this is somewhat mitigated by the 1 month horizon, |
| 58 | +but that's still 155 MB of data for just the headers; a bit more |
| 59 | +since we need to keep recent alternate forks for GHOST. |
| 60 | + |
| 61 | +## Summary ## |
| 62 | + |
| 63 | +I think there's merit in a sidechain which offers faster confirmation, |
| 64 | +reducing the requirement for zeroconf tricks. While such a chain is |
| 65 | +more divergent, that doesn't matter if they all agree on the |
| 66 | +transaction(s) we care about. |
| 67 | + |
| 68 | +This would be an interesting experiment in itself, and if I were doing |
| 69 | +pettycoin again, I'd separate this from the microtransaction |
| 70 | +sidechain. |
0 commit comments