1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <peter@grigor.ws>) id 1Wk1Pj-00017o-SN
for bitcoin-development@lists.sourceforge.net;
Tue, 13 May 2014 01:21:51 +0000
X-ACL-Warn:
Received: from mail-ve0-f175.google.com ([209.85.128.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wk1Pi-0003xq-Fv
for bitcoin-development@lists.sourceforge.net;
Tue, 13 May 2014 01:21:51 +0000
Received: by mail-ve0-f175.google.com with SMTP id jw12so9819796veb.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 12 May 2014 18:21:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to
:content-type;
bh=LqVb6V8/pndGiO987E00AO2xdS2v9o1KVyNmSd8au+Q=;
b=kXt8gs8yhirKgb/ZdcTnxbZQqBWKMPUBXSE/9ZUIUMzdc+tLoqFXI/12KovUnPSY77
G53cQHUR8Z9I3oVEkgqCtH8mhK9ZMomzONIJUmVK9FHAGgYg4XZhGJUqOicEbe80nw3X
i11QVFB0RhG32dN4Lp7HJ9QH/dR6jeMLfW3N5sVAkQh3oYXs96JrrWgX5OQFhSQ401BG
TCE9dEVOUp2VqVaZOzm+nqUvFYR6Pyyz4min0NwAQwA3syArGB3yc4eVnGgLkrxmJJrm
9l4xdh1j/sUXjQMC9z+tdMVH4YHEgm3XRVlJPUqyWCPiUWQhAkigrvZqemC09Dpw1v4F
K4yw==
X-Gm-Message-State: ALoCoQnfCgPA/KAyXZQ9i1L5J+1XlVzzjrEiqxynYiYojX5pKzQRM1VqDV3k7iC42sVybx6vVvKO
MIME-Version: 1.0
X-Received: by 10.58.195.231 with SMTP id ih7mr4143662vec.32.1399944104714;
Mon, 12 May 2014 18:21:44 -0700 (PDT)
Received: by 10.220.3.66 with HTTP; Mon, 12 May 2014 18:21:44 -0700 (PDT)
X-Originating-IP: [68.5.210.114]
Date: Mon, 12 May 2014 18:21:44 -0700
Message-ID: <CAGpx8BVhQaO3+zeRgsMBgZa8-6L6+4k60tpQYOVBtFxVjoyBkw@mail.gmail.com>
From: Peter Grigor <peter@grigor.ws>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=047d7b67663011385e04f93de30c
X-Spam-Score: 3.5 (+++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
2.5 US_DOLLARS_3 BODY: Mentions millions of $ ($NN, NNN,
NNN.NN)
1.0 HTML_MESSAGE BODY: HTML included in message
0.0 LOTS_OF_MONEY Huge... sums of money
X-Headers-End: 1Wk1Pi-0003xq-Fv
Subject: [Bitcoin-development] Bitcoin Fee Formula Proposal
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 01:21:52 -0000
--047d7b67663011385e04f93de30c
Content-Type: text/plain; charset=UTF-8
This was originally submitted to the bitcoin github issue manager. I'm
re-posting here.
I propose the transaction fee should be calculated from a percentage of the
input amount divided by the confirmations of the input multiplied by the
number of inputs.
By using a percentage of the input amount the transaction fee will always
make sense no matter what the "price" of bitcoins may be in fiat; by
dividing the fee by the number of confirmations we discourage hasty spends
and reward savings (ie. old inputs); by multiplying the fee by the number
of inputs we discourage "payment fragmenting."
Let me further explain payment fragmenting by way of an example: Let's say
I get paid $2,500 in bitcoins per month from my job. If I then take that
$2,500 and pay for a coffee (right away, 1 confirmation) I'll be charged a
fee of $2.50 because I'm charged according to the *input amount*, not the
actual transaction size. Because of this it would behove my employer to pay
me the $2,500 as one transaction with, perhaps, 100 output addresses at $25
apiece so that when I pay for my coffee I use one of the $25 unspent
outputs. By multiplying the transaction fee be the number of inputs this
provides a disincentive for payment fragmenting as multiple inputs will be
required to pay for larger purchases.
Furthermore this provides an incentive for wallet software to use the
oldest input(s) which most closely match the transaction amount. For the
example above: In real life a user's wallet would have a number of inputs
to choose from and wouldn't use the newest "paycheck" input for the coffee
purchase. Furthermore, even if the $2,500 input was the only input
available, by waiting for 100 confirmations (less than a day) the
transaction fee would be 2.5 cents.
Transaction fees would then be calculated by the following formula:
((INPUT_AMOUNT * BASE_PERCENT) / CONFIRMATIONS) * NUMBER_OF_INPUTS
The INPUT_AMOUNT, CONFIRMATIONS and NUMBER_OF_INPUTS would be determined by
the creator of the transaction and should be optimized for the transaction
amount -- the BASE_PERCENT would be hard-coded in the bitcoind software.
The special case of zero CONFIRMATIONS will be treated as 1 confirmation in
order to avoid a divide by zero error.
For example: if I choose a BASE_PERCENT of 0.1% and one input it will cost:
- $1 to send $1,000,000 that has 100 confirmations;
- $0.10 (10 cents) to send $1,000,000 that has 1,000 confirmations
(approx. 1 week);
- $0.10 (10 cents) to send $100 which has 1 confirmation;
- $0.01 (1 cent) to send $100 which has 10 confirmations;
- $0.001 (1/10 cent) to send $100 which has 100 confirmations (less than
a day);
I've put together a spreadsheet which shows the various fees by amount and
confirmations -- the spreadsheet assumes one input for a transaction:
https://docs.google.com/spreadsheets/d/1ovAQfxksQmOq3zYf79qFEDPCrSx58SmyK3Uwpu8iTUs/edit?usp=sharing
--047d7b67663011385e04f93de30c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif;font-size:13px=
">This was originally submitted to the bitcoin github issue manager. I'=
m re-posting here.</span><div style=3D"font-family:arial,sans-serif;font-si=
ze:13px">
<br></div><div style=3D"font-family:arial,sans-serif;font-size:13px"><p sty=
le=3D"margin-right:0px;margin-bottom:15px;margin-left:0px;color:rgb(51,51,5=
1);font-family:Helvetica,arial,freesans,clean,sans-serif;font-size:14px;lin=
e-height:23.799999237060547px;margin-top:0px!important">
I propose the transaction fee should be calculated from a percentage of the=
input amount divided by the confirmations of the input multiplied by the n=
umber of inputs.</p><p style=3D"margin:15px 0px;color:rgb(51,51,51);font-fa=
mily:Helvetica,arial,freesans,clean,sans-serif;font-size:14px;line-height:2=
3.799999237060547px">
By using a percentage of the input amount the transaction fee will always m=
ake sense no matter what the "price" of bitcoins may be in fiat; =
by dividing the fee by the number of confirmations we discourage hasty spen=
ds and reward savings (ie. old inputs); by multiplying the fee by the numbe=
r of inputs we discourage "payment fragmenting."</p>
<p style=3D"margin:15px 0px;color:rgb(51,51,51);font-family:Helvetica,arial=
,freesans,clean,sans-serif;font-size:14px;line-height:23.799999237060547px"=
>Let me further explain payment fragmenting by way of an example: Let's=
say I get paid $2,500 in bitcoins per month from my job. If I then take th=
at $2,500 and pay for a coffee (right away, 1 confirmation) I'll be cha=
rged a fee of $2.50 because I'm charged according to the=C2=A0<em>input=
amount</em>, not the actual transaction size. Because of this it would beh=
ove my employer to pay me the $2,500 as one transaction with, perhaps, 100 =
output addresses at $25 apiece so that when I pay for my coffee I use one o=
f the $25 unspent outputs. By multiplying the transaction fee be the number=
of inputs this provides a disincentive for payment fragmenting as multiple=
inputs will be required to pay for larger purchases.</p>
<p style=3D"margin:15px 0px;color:rgb(51,51,51);font-family:Helvetica,arial=
,freesans,clean,sans-serif;font-size:14px;line-height:23.799999237060547px"=
>Furthermore this provides an incentive for wallet software to use the olde=
st input(s) which most closely match the transaction amount. For the exampl=
e above: In real life a user's wallet would have a number of inputs to =
choose from and wouldn't use the newest "paycheck" input for =
the coffee purchase. Furthermore, even if the $2,500 input was the only inp=
ut available, by waiting for 100 confirmations (less than a day) the transa=
ction fee would be 2.5 cents.</p>
<p style=3D"margin:15px 0px;color:rgb(51,51,51);font-family:Helvetica,arial=
,freesans,clean,sans-serif;font-size:14px;line-height:23.799999237060547px"=
>Transaction fees would then be calculated by the following formula:</p><p =
style=3D"margin:15px 0px;color:rgb(51,51,51);font-family:Helvetica,arial,fr=
eesans,clean,sans-serif;font-size:14px;line-height:23.799999237060547px">
((INPUT_AMOUNT * BASE_PERCENT) / CONFIRMATIONS) * NUMBER_OF_INPUTS</p><p st=
yle=3D"margin:15px 0px;color:rgb(51,51,51);font-family:Helvetica,arial,free=
sans,clean,sans-serif;font-size:14px;line-height:23.799999237060547px">The =
INPUT_AMOUNT, CONFIRMATIONS and NUMBER_OF_INPUTS would be determined by the=
creator of the transaction and should be optimized for the transaction amo=
unt -- the BASE_PERCENT would be hard-coded in the bitcoind software. The s=
pecial case of zero CONFIRMATIONS will be treated as 1 confirmation in orde=
r to avoid a divide by zero error.</p>
<p style=3D"margin:15px 0px;color:rgb(51,51,51);font-family:Helvetica,arial=
,freesans,clean,sans-serif;font-size:14px;line-height:23.799999237060547px"=
>For example: if I choose a BASE_PERCENT of 0.1% and one input it will cost=
:</p>
<ul style=3D"padding:0px 0px 0px 30px;margin:15px 0px;color:rgb(51,51,51);f=
ont-family:Helvetica,arial,freesans,clean,sans-serif;font-size:14px;line-he=
ight:23.799999237060547px"><li style=3D"margin-left:15px">$1 to send $1,000=
,000 that has 100 confirmations;</li>
<li style=3D"margin-left:15px">$0.10 (10 cents) to send $1,000,000 that has=
1,000 confirmations (approx. 1 week);</li><li style=3D"margin-left:15px">$=
0.10 (10 cents) to send $100 which has 1 confirmation;</li><li style=3D"mar=
gin-left:15px">
$0.01 (1 cent) to send $100 which has 10 confirmations;</li><li style=3D"ma=
rgin-left:15px">$0.001 (1/10 cent) to send $100 which has 100 confirmations=
(less than a day);</li></ul><p style=3D"margin:15px 0px;color:rgb(51,51,51=
);font-family:Helvetica,arial,freesans,clean,sans-serif;font-size:14px;line=
-height:23.799999237060547px">
I've put together a spreadsheet which shows the various fees by amount =
and confirmations -- the spreadsheet assumes one input for a transaction:</=
p><p style=3D"margin-top:15px;margin-right:0px;margin-left:0px;color:rgb(51=
,51,51);font-family:Helvetica,arial,freesans,clean,sans-serif;font-size:14p=
x;line-height:23.799999237060547px;margin-bottom:0px!important">
<a href=3D"https://docs.google.com/spreadsheets/d/1ovAQfxksQmOq3zYf79qFEDPC=
rSx58SmyK3Uwpu8iTUs/edit?usp=3Dsharing" target=3D"_blank" style=3D"color:rg=
b(65,131,196);text-decoration:none">https://docs.google.com/spreadsheets/d/=
1ovAQfxksQmOq3zYf79qFEDPCrSx58SmyK3Uwpu8iTUs/edit?usp=3Dsharing</a></p>
</div></div>
--047d7b67663011385e04f93de30c--
|
