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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Z2mZt-0002Xw-N7
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Jun 2015 20:26:25 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.170 as permitted sender)
client-ip=209.85.212.170; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f170.google.com;
Received: from mail-wi0-f170.google.com ([209.85.212.170])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z2mZs-0005gX-KP
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Jun 2015 20:26:25 +0000
Received: by wiwd19 with SMTP id d19so58826379wiw.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Jun 2015 13:26:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.80.229 with SMTP id u5mr21927081wix.92.1433967978599;
Wed, 10 Jun 2015 13:26:18 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.16.40 with HTTP; Wed, 10 Jun 2015 13:26:18 -0700 (PDT)
In-Reply-To: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com>
References: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com>
Date: Wed, 10 Jun 2015 22:26:18 +0200
X-Google-Sender-Auth: xyxv8XbFTFHvtnVeP3JoKESDJtU
Message-ID: <CANEZrP3+jW3BO=Zv41CGubJL7bSZ==o=Wp83K6Q0xL4PP+0ZUQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Nathan Wilcox <nathan@leastauthority.com>
Content-Type: multipart/alternative; boundary=f46d04428e40fbda3805182faffd
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1Z2mZs-0005gX-KP
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
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: Wed, 10 Jun 2015 20:26:25 -0000
--f46d04428e40fbda3805182faffd
Content-Type: text/plain; charset=UTF-8
I described an alternative way for SPV wallets to learn about fees some
time ago. It requires a new transaction version that embeds output values
into the signed data. Then an upgrade to the P2P protocol to send UTXO data
along with transactions when they are relayed.
The idea is that the wallet sets a Bloom filter with an FP rate that
ensures it will see some random subset of all transactions being broadcast
on the network, and with the extra data, it can calculate the fee paid.
Once a transaction broadcast is observed the wallet includes that tx hash
in its next Bloom filter, thus it can see which block the tx confirmed in.
By measuring the amount of time that passed between a broadcast and it
appearing in a block, it can calculate its own tables of fee paid:time
taken.
This has the advantage that you don't have to trust miners to publish data
accurately. However it requires some protocol upgrades and of course, a lot
of new code in SPV wallets.
The way Bitcoin Wallet for Android handles fees currently is to just update
a hard coded value every so often.
--f46d04428e40fbda3805182faffd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I described an alternative way for SPV wallets to learn ab=
out fees some time ago. It requires a new transaction version that embeds o=
utput values into the signed data. Then an upgrade to the P2P protocol to s=
end UTXO data along with transactions when they are relayed.<div><br></div>=
<div>The idea is that the wallet sets a Bloom filter with an FP rate that e=
nsures it will see some random subset of all transactions being broadcast o=
n the network, and with the extra data, it can calculate the fee paid. Once=
a transaction broadcast is observed the wallet includes that tx hash in it=
s next Bloom filter, thus it can see which block the tx confirmed in. By me=
asuring the amount of time that passed between a broadcast and it appearing=
in a block, it can calculate its own tables of fee paid:time taken.</div><=
div><br></div><div>This has the advantage that you don't have to trust =
miners to publish data accurately. However it requires some protocol upgrad=
es and of course, a lot of new code in SPV wallets.</div><div><br></div><di=
v>The way Bitcoin Wallet for Android handles fees currently is to just upda=
te a hard coded value every so often.</div></div>
--f46d04428e40fbda3805182faffd--
|
