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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sergiolerner@certimix.com>) id 1Yrguo-0005VY-H7
for bitcoin-development@lists.sourceforge.net;
Mon, 11 May 2015 06:10:10 +0000
X-ACL-Warn:
Received: from p3plsmtpa09-06.prod.phx3.secureserver.net ([173.201.193.235])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1Yrgum-0007LJ-Ms
for bitcoin-development@lists.sourceforge.net;
Mon, 11 May 2015 06:10:10 +0000
Received: from [192.168.1.105] ([190.247.34.93])
by p3plsmtpa09-06.prod.phx3.secureserver.net with
id SWA01q00720a7yu01WA1pr; Sun, 10 May 2015 23:10:02 -0700
Message-ID: <555047B6.8010402@certimix.com>
Date: Mon, 11 May 2015 03:09:58 -0300
From: Sergio Lerner <sergiolerner@certimix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
References: <554FC36C.80402@certimix.com>
<CAAS2fgQL6ExHqT+po-F2b9+3Ns4woFx-VqQSdDkXRZwy47+XwA@mail.gmail.com>
In-Reply-To: <CAAS2fgQL6ExHqT+po-F2b9+3Ns4woFx-VqQSdDkXRZwy47+XwA@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [173.201.193.235 listed in list.dnswl.org]
X-Headers-End: 1Yrgum-0007LJ-Ms
Subject: Re: [Bitcoin-development] A way to create a fee market even without
a block size limit (2013)
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: Mon, 11 May 2015 06:10:10 -0000
El 10/05/2015 06:07 p.m., Gregory Maxwell escribió:
> On Sun, May 10, 2015 at 8:45 PM, Sergio Lerner
> <sergiolerner@certimix.com> wrote:
>> Can the system by gamed?
> Users can pay fees or a portion of fees out of band to miner(s); this
> is undetectable to the network.
Then this is exactly what is needed. Let me explain.
I know of 5 methods for a user to pay fees to a miner. I will explain
each method and why these methods do not prevent the fee market from
being created:
1) By transaction fees
This is the standard, which would be limited by the CoVar algorithm, and
would create the fee market, if it were the only way to pay fees.
2) By creating multiple transactions, each adding an output that pays to
each miner (to a known miner address) the fees. User does not
pre-negotiate anything with miners.
This requires a transaction to have an additional output and requires
sending through the p2p network one different transaction to each miner,
each having an output with a "known" address of that miner. But the
network does not propagates double-spends, so those transaction would
need to be sent directly to the top miners, and to all at the same time.
The IP addresses of the top miners are not generally publicly available,
and then may not accept new incoming connections. Also having an
additional output means the transactions would be larger, so they will
score lower by any metric the miner uses to choose transactions. Last,
miners must be programmed to automatically interpret payments to their
addresses as fees. The resulting protocol is very difficult to do
reliably, expensive, as any delay would make one miner receive the
transaction from other miner and reject the double-spend that is being
send directly to it, increasing the average confirmation time.
3) By adding an anyone-can-spend output for fees, so the miner can spend
that output in the same block. User does not pre-negotiate anything
with miners.
We can hard-fork not to allow spending outputs created in the same
block. This is a drawback, unless we reduce the block rate, which is my
proposal. However, spending in the same block also requires an storing
in the block an additional input, which consumes at least 40 bytes more,
and the transaction containing the input cannot be relayed to the
network in advance. Then the block that uses this method to collect fees
from many transactions will propagate slower, and the miner may end
loosing money. The any-one-can-spend output would take approximately 10
bytes. So if transmitting 10+40=50 bytes, cost more than the fees
earned, then miners do not have an incentive to game the system. It's
has been studied that "each kilobyte costs an additional 80ms delay
until a majority knows about the block." (Information propagation in the
Bitcoin network). So 50 bytes costs 3.9 ms in propagation time, which
having a a 25 BTC subsidy is roughly equivalent to 0.2 mBTC. Currently
this is more than what transactions do pay in fees (about 0.1 mBTC), so
this should not be a problem for at least 5 years. And again, we could
just prevent spending outputs in the same block they are created.
4) Using a transaction having a single input having exactly the desired
output amount plus fees and signing the input with SIGHASH_SINGLE |
SIGHASH_ANYONECANPAY and adding to the transaction a single output with
the desired amount. The miner will be able to join many of these
transactions and finally add an output to collect all fees together,
without using standard transaction fees.
This is unreliable and cannot be systematically repeated without
creating a pre-transaction just to prepare the single input having the
amount plus fees exactly. The pre-transaction would need to pay fees, so
the problem is not avoided, just moved around.
5) By negotiating out of band with the miner previously. Anything could
be agreed by the user and the miner.
This actually creates a parallel out-of-band market for fees, which is
exactly what we want. If a user-to-miner pre-negotiation will take
place, then the miner can establish whatever price policy he wants to
compete and stay in business, as block data propagation costs money. So
there will be two fee markets, the "out-of-band" market, and the
"in-band" market, and both should converge.
My conclusion is that fee markets will be created, and any alternate
fee-paying methods (without a pre-negotiation) are not reliable nor
cost-saving options. The full proposal would be to use the CoVar method,
reduce the block rate to 1 minute, and do not allow spending outputs in
the same block they are created.
Best regards,
Sergio.
|
