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
|
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 <jeremy@taplink.co>) id 1VZnAb-0002fa-Es
for bitcoin-development@lists.sourceforge.net;
Fri, 25 Oct 2013 19:35:41 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1VZnAa-0006iM-DV for bitcoin-development@lists.sourceforge.net;
Fri, 25 Oct 2013 19:35:41 +0000
Received: from laptop-air ([192.168.168.135]) by mail.taplink.co ;
Fri, 25 Oct 2013 12:43:48 -0700
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Andreas Petersson" <andreas@petersson.at>, "Peter Todd"
<pete@petertodd.org>
References: <20131024143043.GA12658@savin>
<CANEZrP100Lg_1LcFMKx1yWrGTSFb5GZmLmXNbZjPGaiEgOeuwA@mail.gmail.com>
<20131024144358.GA17142@savin>
<CANEZrP1TfM+wYbGjUk3+8JJZs6cKZXdb57xGMc=hDr9dQjMMZA@mail.gmail.com>
<20131024145447.GA19949@savin>
<CABsx9T0T0v=HnRRr6BLKNQOFMBJWrhF4G4SOCJ9DidGJBB8Eow@mail.gmail.com>
<20131025070708.GA5760@savin>
<91968c56640bf7647325728f490b9257@localhost>
<20131025161323.GA15774@petertodd.org>
Date: Fri, 25 Oct 2013 12:35:34 -0700
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w5izdkiyyldrnw@laptop-air>
In-Reply-To: <20131025161323.GA15774@petertodd.org>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
X-Spam-Score: -2.0 (--)
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.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
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: taplink.co]
-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: 1VZnAa-0006iM-DV
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Making fee estimation better
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, 25 Oct 2013 19:35:41 -0000
Do you think we're at the point where wallets have to be able to "actively
bid" the fee using replacement due to block contention?
I think a fee estimation API is just a data point. Depending on the
properties of the estimator, and how that's presented in the UI, it could
serve to either increase or decrease the need for recovery.
Like you said, we already have "fee estimation" in the form of "user,
please estimate the fee!" Now we want to make fee estimation "better", and
one key aspect of better fee estimation is decreasing the need for
recovery. Techniques like signing multiple transactions with different fee
levels should become less useful the better you are at estimating the fee.
What I find interesting is that fee estimation can look at the size and
type of the transaction, the age of the inputs, the number of inputs
versus outputs, amount of the outputs, factor in [assumptions about] what
fee policies miners are actually using, and after all that, look at the
actual competing transactions on the blockchain and try to figure out how
many of those are even real.
For example, if you just look at fee-per-KB of mempool versus fee-per-KB
of recently mined transactions, without taking into account input age,
number of inputs vs outputs, output amounts... all the other things miner
might have used to discriminate between transactions, then I don't think
you'll end up with a better fee estimator.
Contention might bump you out of a few blocks, but if the basis for
calculating the fee is fundamentally compatible with the relay policies
and the transaction-inclusion policies being run by large mining pools,
the transaction isn't dead, it's just pending.
On Fri, 25 Oct 2013 09:13:23 -0700, Peter Todd <pete@petertodd.org> wrote:
> On Fri, Oct 25, 2013 at 02:02:35PM +0200, Andreas Petersson wrote:
>>
>>
>> > Worth thinking about the whole ecosystem of wallets involved; they all
>> > have to handle double-spends gracefully to make tx replacement of any
>> > kind user friendly. We should try to give people a heads up that this
>> is
>> > coming soon if that's your thinking.
>>
>> If there is a situation where wallets are supposed to constantly monitor
>> the tx propagation and recreate their transactions with different fees,
>> this would make a lot of usecases inconvenient.
>> half-offline bluetooth transactions, users with unstable connections,
>> battery power lost, etc, etc. - and last but not least power concerns on
>> hardware wallets on the bitcoincard (tx signing drains a significant
>> amount
>> of power and should therefore only be done once)
>
> Anyway, as I've said repeatedly my problem with fee estimation is that
> it needs to be combined with some form of transaction replacement to
> give users a way to recover from bad estimates, not that I think the
> idea shouldn't be implemented at all. After all, we alrady have fee
> estimation: wallet authors and users manully estimate fees!
>
> This particular case is a nasty one re: recovering from a bad estimate,
> and it's exactly why the payment protocol is designed for the sender to
> give the receiver a copy of every transaction they make so the receiver
> can be held responsible for getting them mined, eg. with
> child-pays-for-parent, out-of-band fee payment, or maybe even by adding
> inputs to the transaction. (SIGHASH_ANYONECANPAY)
|
