|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: Pettycoin Revisited Part VI: Fees and Horizons |
| 4 | +commentIssueId: 42 |
| 5 | +--- |
| 6 | +> This is the sixth 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 | +> and the fifth discussed [Fast blocks vs Bitcoin blocks](http://rustyrussell.github.io/pettycoin/2014/12/10/Pettycoin-Revisited-Part-V:-Fast-Blocks.html). |
| 15 | +
|
| 16 | +Mining fees must be sufficient to support the network, otherwise it |
| 17 | +will eventually fail. There's a tension between users who want the |
| 18 | +lowest fees possible, and miners who want the highest fees possible. |
| 19 | +And while the miner of a particular block collects the fees, the |
| 20 | +incremental cost of remembering the transaction is carried by the |
| 21 | +entire network. |
| 22 | + |
| 23 | +## Bitcoin Solution ## |
| 24 | + |
| 25 | +Bitcoin is supposed to use an open market fee structure; miners choose |
| 26 | +what to accept based on fees, and so transactions offer a fee |
| 27 | +sufficient to have miners include the transaction in their block. |
| 28 | + |
| 29 | +In practice, the default formula used is very simple: there are a |
| 30 | +number of "first-in-first-served" free transaction slots in each |
| 31 | +block, then a fixed fee is required per kb of transaction. This fixed |
| 32 | +fee has dropped several times as the bitcoin price increases. |
| 33 | + |
| 34 | +It's not particularly important, as miners view transactions fees as a |
| 35 | +tiny cherry on top: the block rewards are driving mining at the |
| 36 | +moment. This will eventually change, so efforts are underway to have |
| 37 | +the reference bitcoin client guestimate appropriate fees which are |
| 38 | +likely to have a transaction included. How well this will work in |
| 39 | +practice is uncertain: miners have short-term incentive to include |
| 40 | +transactions no matter how small the fee, but a longer-term incentive |
| 41 | +to reject tiny fees. This is especially true if clients autodetect |
| 42 | +appropriate fee levels. |
| 43 | + |
| 44 | +### What Level of Fee Should Happen? ### |
| 45 | + |
| 46 | +As a first approximation, the cost of running the bitcoin network |
| 47 | +should be equal to the value of bitcoins currently produced. Let's |
| 48 | +assume that we want the network to continue at the current spending |
| 49 | +level when the block reward next halves; transaction fees will have |
| 50 | +to make up the difference, at around $4000 per block. |
| 51 | + |
| 52 | +The bitcoin price is a huge unknown, so we'll try to make our other |
| 53 | +guesses extremely conservative. Let the bitcoin transaction rate will |
| 54 | +increase to a massive 100 transactions per second, that's 60,000 |
| 55 | +transactions each paying around 6c each. |
| 56 | + |
| 57 | +## Pettycoin Solution ## |
| 58 | + |
| 59 | +If bitcoin won't let you reasonably send 1c, what would? A sidechain |
| 60 | +specifically designed for this, with properties that ensured it |
| 61 | +wouldn't compete with bitcoin. That way, miners could pick up the |
| 62 | +(too-small) fees, without entering a race to the bottom on the bitcoin |
| 63 | +network. |
| 64 | + |
| 65 | +Of course, the sidechain would have to be cheap to run, too, so the |
| 66 | +additional cost of merge mining it was worth the small fees involved. |
| 67 | + |
| 68 | +This was the core design of pettycoin: |
| 69 | + |
| 70 | +1. A 1-month horizon, after which coins are returned to the bitcoin |
| 71 | + network. |
| 72 | +2. Simplified, less-powerful transaction types. |
| 73 | +3. Fees based on percentage, rather than absolute values. |
| 74 | + |
| 75 | +The horizon ensures that pettycoin is not a store of value, but only a |
| 76 | +transfer network, and puts an approximate upper limit on how much data |
| 77 | +needs to be stored. |
| 78 | + |
| 79 | +Simplified transactions |
| 80 | +[were a bad idea](http://rustyrussell.github.io/pettycoin/2014/12/05/Pettycoin-Revisited-Part-IV:-Simplified-Transactions.html) |
| 81 | +as they don't save much, and it's hard to tell which parts of the |
| 82 | +bitcoin scripts will be useful in future. |
| 83 | + |
| 84 | +The percentage-based fee (0.3% currently) makes for a simple penalty |
| 85 | +if transactions get large enough that it would be cheaper to do them |
| 86 | +on the bitcoin network. (You could also flag a transaction as zero-fee, |
| 87 | +with the idea that miners may or may not accept them). |
| 88 | + |
| 89 | +This scheme required simplified transactions, which can distinguish a |
| 90 | +payment from change. Using percentage of the total transferred would |
| 91 | +encourage users to split their outputs so future transactions would |
| 92 | +not need to transfer as much, leading to a larger UTXO size. |
| 93 | + |
| 94 | +The simplest solution I can think of would be to ignore the |
| 95 | +largest output, and sum the rest as the fee basis. |
| 96 | + |
| 97 | +This could still be gamed for some cases, of course, but is fairly |
| 98 | +simple in the common case. There's no reason to restrict number of |
| 99 | +inputs, as consuming many inputs would reduce the UTXO size and help |
| 100 | +the network overall. |
| 101 | + |
| 102 | +## Summary ## |
| 103 | + |
| 104 | +This core idea of a complementary network for sub-cent transactions |
| 105 | +has promise, but has a significant bootstrap problem. If there are |
| 106 | +still free bitcoin transactions, it provides no value. If there are |
| 107 | +no more free bitcoin transactions, then you need to pay the |
| 108 | +transaction fee to get money on and off the sidechain, in order to |
| 109 | +save money later (and you only have a limited time to do it). |
| 110 | + |
| 111 | +It would take a compelling use case to drive adoption, which could |
| 112 | +be artificial: eg. a subsidised SatoshiDice-style service on the |
| 113 | +microtransaction network. |
0 commit comments