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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1Vo2rv-00069c-8y
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Dec 2013 03:11:19 +0000
Received-SPF: pass (sog-mx-2.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-2.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1Vo2ru-0005Yu-H4 for bitcoin-development@lists.sourceforge.net;
Wed, 04 Dec 2013 03:11:19 +0000
Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by
mail.taplink.co ; Tue, 3 Dec 2013 17:46:52 -0800
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Mike Hearn" <mike@plan99.net>, "Gavin Andresen" <gavinandresen@gmail.com>
References: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
<l7f97u$jdg$1@ger.gmane.org>
<5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net>
<l7fpbn$hf6$1@ger.gmane.org>
<39921E12-B411-4430-9D56-04F53906B109@plan99.net>
<CAGLkj4C9fyAX1CnB0oZH3BwLRQp6WOo9kLUqDhRUSA6y3LxYvg@mail.gmail.com>
<CANEZrP1C=Hc-3f-rqQ+wYrPn-eUj52HjN+qRQdJMWvnP+dkK=Q@mail.gmail.com>
<CAJHLa0P_uzEQ2OG2FTXyD2Zw4RzujNBxKbKD04CSS1sLNpLUUQ@mail.gmail.com>
<CANEZrP2hf2853w9f4__Ji9v3eRRU0u6pEzPxAmFN+iH067gtnA@mail.gmail.com>
<CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@mail.gmail.com>
<CANEZrP1PLKemiUEgMJRGdiZXt7o=0_5fhLKYY0x3Ngb_iEm+2w@mail.gmail.com>
<CABsx9T322nCvynRCL6Mb9C0f5EuJSfMDTSGiU+_JsYoSCb=_kQ@mail.gmail.com>
Date: Tue, 03 Dec 2013 17:45:44 -0800
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w7jnreqwyldrnw@laptop-air.hsd1.ca.comcast.net>
In-Reply-To: <CABsx9T322nCvynRCL6Mb9C0f5EuJSfMDTSGiU+_JsYoSCb=_kQ@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
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 SPF_PASS SPF: sender matches SPF record
-0.0 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: 1Vo2ru-0005Yu-H4
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: Wed, 04 Dec 2013 03:11:19 -0000
allowfee:
> Allow up to allowfee satoshis to be deducted from the amount paid to be
> used to pay Bitcoin network transaction fees. A wallet >implementation
> must not reduce the amount paid for fees more than allowfee, and
> transaction fees must be equal to or greater than the >amount reduced.
minfee:
> Pay at least minfee satoshis in transaction fees. Wallet software should
> add minfee to the amount the user authorizes and pays, and >include at
> least minfee in the transaction created to pay miner's transaction fees.
> Wallet software may request that the user pays more, if >it must create
> a complex transaction or judges that minfee is not sufficient for the
> transaction to be accepted by the network..
>
Thanks for the draft specs Gavin. Very clear and precise.
Personally I think 'allowfee' is more useful than 'minfee'. The 'allowfee'
tells me something very useful and definitive about what the merchant will
let me do when making payment, and if the merchant chooses 'allowfee'
intelligently, they can provide real value to their customers without
exposing them to undue risk.
A 'minfee' field on the other hand, is just a data point for the wallet
software to consider, and likely to be noisy enough that wallets will tend
to ignore it. (e.g. like Drak's example of Gox's 0.001 fee)
The sender's wallet software will always be free to choose the fee, and
paying less than the 'allowfee' or 'minfee' can still get a TX included in
the next block.
I think of the PaymentRequest is a part of the purchase contract. If a
payer transmits a transaction before 'expires' but with less than
'minfee', which gets included in the next block, have they failed to meet
the terms of payment?
If there is some time criticality, for example to reduce exchange rate
risk, then a wallet might need to choose a higher fee to ensure the
transaction clears in time. Instead of 'minfee' I'm thinking it would be
more appropriate to communicate this using the existing 'expires' field --
in other words, let the merchant express what their requirement is, not
tell the wallet how to achieve it.
In the case of a transaction with too-low fee, either the payer can
double-spend with a higher fee, or wait longer for the transaction to make
it into a block. If it hits the blockchain before the 'expires' time, then
the merchant should have no standing to refute it, regardless of the
amount of fees paid.
A refund comes into play if a payer reduced the total amount in excess of
an agreed upon 'allowfee', or if the transaction doesn't hit the
blockchain until after 'expires'. It should be clear in these cases that
payer would end up eating the fees in both directions. But then, what if a
wallet pays the 'minfee' and broadcasts 1 block before 'expires' but the
payment DOESN'T make the block? Is the merchant liable for too-slow
transactions due to their own insufficient 'minfee' value?
So I see 'allowfee' as extremely useful, but 'minfee' as somewhat
problematic.
Thanks,
Jeremy
|
