|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: Pettycoin Revisited Part VII: Payback |
| 4 | +commentIssueId: 42 |
| 5 | +--- |
| 6 | +> This is the seventh 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), |
| 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 | +> the fifth discussed [Fast blocks vs Bitcoin blocks](http://rustyrussell.github.io/pettycoin/2014/12/10/Pettycoin-Revisited-Part-V:-Fast-Blocks.html). |
| 15 | +> and the sixth [Fees and Horizons for A Microtransaction Sidechain](http://rustyrussell.github.io/pettycoin/2014/12/11/Pettycoin-Revisited-Part-VI:-Fees-and-Horizons.html). |
| 16 | +
|
| 17 | +Lacking the ability to mint coins, rewarding miners for a sidechain is |
| 18 | +difficult. Relying on fees in the initial stages is not possible, and |
| 19 | +using fees provides a disincentive for actually *using* the network. |
| 20 | + |
| 21 | +## Pettycoin Solution ## |
| 22 | + |
| 23 | +To solve this problem, pettycoin allows transactions to flag themselves |
| 24 | +as feeless, with the understanding that miners may not include such |
| 25 | +transactions. It also mines the future to pay for the present: 25% |
| 26 | +of the fees from block N+(X-years) would get paid to block N. The |
| 27 | +actual number of years was to be selected by an on-blockchain election |
| 28 | +conducted at the 1 year mark. |
| 29 | + |
| 30 | +The problem with this is that it requires the retention of all old |
| 31 | +block headers, even before the horizon (otherwise we could use compact |
| 32 | +SPV proofs for those headers). A further lottery process could select |
| 33 | +an agreed subset, however. |
| 34 | + |
| 35 | +## Alternate Solution ## |
| 36 | + |
| 37 | +A similar idea was suggested in the |
| 38 | +[sidechains whitepaper](http://www.blockstream.com/sidechains.pdf), |
| 39 | +via a different mechanism: that old miners would have the right to |
| 40 | +mine a block with lower difficulty in the future. In some ways this |
| 41 | +is nicer, since the easy miner could provide proof of their old block |
| 42 | +using a compact SPV proof. Also, if the ability to mine an easy block |
| 43 | +is part of the UTXO set, UTXO commitments can provide protection |
| 44 | +against double-spends. |
| 45 | + |
| 46 | +This introduces the issue that some party could flood the chain with |
| 47 | +easy blocks; perhaps instead each block would only be (say) 25% easier |
| 48 | +than normal, rather than ridiculously easy. The miner could then |
| 49 | +sell the use of their private key. |
| 50 | + |
| 51 | +## Summary ## |
| 52 | + |
| 53 | +Weak blocks make checking significantly more complex, but I'd have to |
| 54 | +implement it to really know how bad it was. It fits fairly nicely |
| 55 | +into the bitcoin model of inputs and outputs, however. |
0 commit comments