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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1SfdZI-0005UF-Bp
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 20:56:32 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.83.47 as permitted sender)
client-ip=74.125.83.47; envelope-from=gavinandresen@gmail.com;
helo=mail-ee0-f47.google.com;
Received: from mail-ee0-f47.google.com ([74.125.83.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SfdZH-0001Tk-JZ
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 20:56:32 +0000
Received: by eekd49 with SMTP id d49so1099019eek.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 15 Jun 2012 13:56:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.14.22.69 with SMTP id s45mr1679525ees.186.1339793785331; Fri,
15 Jun 2012 13:56:25 -0700 (PDT)
Received: by 10.14.3.66 with HTTP; Fri, 15 Jun 2012 13:56:25 -0700 (PDT)
In-Reply-To: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com>
References: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com>
Date: Fri, 15 Jun 2012 16:56:25 -0400
Message-ID: <CABsx9T0Z3xKGOO=4Tr94cKTBpfUwHQ_qHJPidB_MPYAGCJV=VQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1SfdZH-0001Tk-JZ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Near-term scalability
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: Fri, 15 Jun 2012 20:56:32 -0000
> (1) Change the mining code to group transactions together with their
> mempool dependencies and then calculate all fees as a group.
I think there is general consensus this is a good idea.
> (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to
> avoid paying excessive fees and queue-jumping. Guess that's on my
> plate.
I don't think the problem is with SatoshiDice, but is with the current
fixed/inflexible fee rules:
----------------------------
I've been thinking about fees a lot the last couple of days, and I'm
close to making a formal proposal. Here are my thoughts so far:
It seems to me there are two typical use cases:
Case 1: I want my transaction to be confirmed quickly, and am willing
to pay a fee to make that happen.
Case 2: I want my transaction to be confirmed eventually. I'd rather
not pay, unless I have to.
I don't think the current code handles those two cases as well as it
could; here's a proposal to fix that:
o Let miners decide on how many free transactions they'll support, by
letting them specify how much of each block to set aside for 'free'
transactions (bytes) and what the threshold for 'free' is
(bitcoins/kilobyte). I think a new RPC call to get/set the parameters
dynamically is the right way to go.
o Change the block creation code to calculate a
bitcoin-fee-per-kilobyte for each transaction, where the fee and size
are both calculated based on the transaction and it's dependent
descendants (so we get the receiver-can-opt-to-pay-the-fee behavior we
want). Order transactions so highest-paying get into the non-free
space first.
o Fill up the "free" space (if any) with the highest-priority
transactions, where priority is a function of transaction size, age of
inputs, number of bitcoins... and ratio of inputs to outputs (to
encourage combining inputs so more pruning is possible).
The fee-paying space in a block lets Use Case #1 users compete to make
their fees high enough to get into the block.
The free space should let non-spamming Use Case #2 users (who don't
send a lot of transactions, and so have well-aged, high-priority
inputs) send transactions for free, at least as long as there are
miners willing to accept free transactions.
The question is: how do clients suggest fees to users if miners might
have very different fee policies?
I think full, transaction-verifying clients can watch how long
transactions stay in the memory pool to figure it out. I'm gathering
statistics right now to test a couple of simple heuristic algorithms
for reasonable fee/priority policies.
But that won't work for newly started clients that haven't seen a lot
of transactions enter/exit the memory pool, or SPV clients that can't
lookup transaction inputs (so can't calculate what fees are being paid
-- and once we have bloom filters may not be paying attention anything
but their own transactions, anyway).
I'm still thinking about that.
Maybe a new p2p network command: you give me a list of block hashes, I
tell you average fees paid per kilobyte for fee-paying transactions in
those blocks, and minimum and average priority of free transactions in
those blocks.
Maybe the big mining pools all publish their fee policies and that
information somehow gets to clients (encoded in the coinbase? ... but
they have a strong incentive to lie to try put upward pressure on
fees... ).
Maybe each client developer runs a "fee policy server" and clients
periodically ask it for reasonable fee rules (HTTP fetch info from a
web page that is updated as often or infrequently as is convenient,
maybe). I think I like this solution the best, it should let clients
compete to have the smartest/bestest algorithms for saving their
user's money on transaction fees.
--
--
Gavin Andresen
|
