Skip to content

Commit 27eff9e

Browse files
committedJan 4, 2015
New post (well, old one, finally revised for upload).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1 parent 6212b14 commit 27eff9e

File tree

1 file changed

+113
-0
lines changed

1 file changed

+113
-0
lines changed
 
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,113 @@
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

Comments
 (0)
Please sign in to comment.