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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VnoCX-0000do-LW
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 11:31:37 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.82 as permitted sender)
client-ip=62.13.149.82; envelope-from=pete@petertodd.org;
helo=outmail149082.authsmtp.co.uk;
Received: from outmail149082.authsmtp.co.uk ([62.13.149.82])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VnoCW-00056Z-Eo for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 11:31:37 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id rB3BVUwk080586;
Tue, 3 Dec 2013 11:31:30 GMT
Received: from tilt (ge-19-102-21.service.infuturo.it [151.19.102.21])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rB3BVMJt056725
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 3 Dec 2013 11:31:28 GMT
Date: Tue, 3 Dec 2013 06:31:17 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20131203113117.GA12623@tilt>
References: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW"
Content-Disposition: inline
In-Reply-To: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 735a79a5-5c0e-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgEUHFAXAgsB AmUbWlVeU1x7W2s7 ag9QcwRUfEtOXRto
UVdMSlVNFUsqcx9z YGNkFhl3cQJEfTBx Zk5gWT5cX0Erck8s
R1NRRm1TeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4lGjk1 WxEEEn0hEEAeDyw1
I1QdEmBUF0IQP0Mu KjMA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 151.19.102.21/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: petertodd.org]
X-Headers-End: 1VnoCW-00056Z-Eo
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
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, 03 Dec 2013 11:31:37 -0000
--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Dec 01, 2013 at 12:51:46PM +0100, Mike Hearn wrote:
> 4) Finally, when we next hard fork, we make v2 transactions include the
> output value in the signature, same as the output script (this proposal h=
as
> been on the forums for a while now). That allows the fee data added in st=
ep
> 2 to be cross-checked against the signatures on the inputs, thus
> authenticating it.
FTFY s/hard-fork/soft-fork/
The proposals on the forums with regard to a soft-fork are for a new
transaction format - to be done in parallel with the old one - that
commits to transaction inputs and outputs via a merkle tree extending
into the transaction. This data is then committed to via the merge-mine
standard.
In addition, all this discussion about trying to figure out transaction
fees based on transaction is a bit irrelevant if you suppose a
soft-fork. We already know that we need a merkle-sum-tree of fees and
transaction size to be able to audit miners and create compact fraud
proofs, and using that merkle-sum-tree you can easily calculate sum
fees/sum size for the whole block to determine fees.
We know that we can make a good assumption that transactions in
blocks will have been broadcast prior by the assumption you and Gavin
are making that miners would by far prefer to mine transactions that
have already been broadcast so that block propagation via txid lists
works. That advantage is on the order of 10x to 100x (or even higher)
lower cost per KB to the miner. (if this is not true, let us all know,
because then your scalability arguments are bunk with regard to
blocksize)
In addition faking fees via non-disclosed high-fee transactions has a
cost of about 1% due to the risk your block gets orphaned and the tx fee
gets mined by another miner.
Between those two the merkle-sum-trees for fees and size can be used for
various levels of average fee for a whole block, plus statistical
distributions.
Next it is also desirable for another, related, soft-fork to include a
sorted list of txids and/or H(scriptPubKey)'s in a block. (the latter is
explicitly part of my TXO commitments proposal) With the txids version
especially it's easy and low-bandwidth for SPV nodes to get proof that a
given transaction has been mined recently, by asking for proof of
inclusion or exclusion to accompany a bloom filter match.
Finally with various anti-sybil techniques that create long-term
identities it's easy to show that a peer lied about the data required
for fee estimates anyway.
> One obvious concern is what to do if nodes don't converge on very similar
> estimates. Wallets will always want to pay the lowest fee possible, so th=
at
> means they'll always be riding the very edge of what's acceptable, opening
> up tx propagation to random flaky failures if fee estimates change whilst=
a
> transaction is in progress, or if some nodes don't calculate the same
> estimates as others.
Propagation failures are not a major problem if transactions can be
rebroadcast with new, higher, fees; propagation failures can be detected
easily and quickly with my proof-of-tx-mining proposal.
--=20
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3
--ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJSncEEAAoJECSBQD2l8JH7yMIH/3txXGyQ47+EuPsUy2567wRM
Q3L2baGremy+3K+fRn969Y78h9dpckbCiWirWhDIoLQbWaJqB/RlaHjxtMu35Nd+
nmy3iKwJa8RyVNLFASt7XEmpSAKmZElCcdHOABoyfq9bxGqnIlgcV6tJPt1GHytp
dIpmEbUgD8/8Ia2EhOK8f+VpjRaCt9ev1UUp+9/iEa9pFafE5WZIxHGzXY0wF+7I
kkSwTMFUZG943Lg1U1CeEptBz+Yiu0/hnX4Sz0sHDaog8/NvCy/DjhjAaLxTUqOm
VfbNHQw7961GZEeNoTPiNb3EAefibcuF2eeRqkrj/FceTWQeyLlhoff/T00YaT0=
=08ST
-----END PGP SIGNATURE-----
--ew6BAiZeqk4r7MaW--
|
