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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <patrick@meadia.com.au>) id 1VnUNs-0001PQ-Ad
for bitcoin-development@lists.sourceforge.net;
Mon, 02 Dec 2013 14:22:00 +0000
X-ACL-Warn:
Received: from mail-wi0-f181.google.com ([209.85.212.181])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VnUNr-00058A-Ba
for bitcoin-development@lists.sourceforge.net;
Mon, 02 Dec 2013 14:22:00 +0000
Received: by mail-wi0-f181.google.com with SMTP id hq4so4861692wib.14
for <bitcoin-development@lists.sourceforge.net>;
Mon, 02 Dec 2013 06:21:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:content-type:content-transfer-encoding;
bh=rpQ/fRKLPkCSo1nCNOH3AlPGRXuAt9mMgSiW8HjyrII=;
b=i4JTofWUCP0RL9NOl//uE0QC+RksUcLyDTG0QPE6WinuheteURl18jCo/VLe3csGqc
bVXPzdMeiYhNdXdA6o8JjxWa6kHXsaCphIBBs5jLAh4x4XSMPcnoiQelNG7SOXeA50mq
VnbUCH76KGXzrlaOEQ6sBVgW5oWl600soKaGoPc8A5hYF639blF07yMZg2oAlqTOzdZx
nfzzZ6uopBOou6yHM/rUZs36RNdAbeq97E46Yu0Iqq0difATpfDyxONZMevIFv3nT9XQ
c47G+vSxxV4vtAvSyWGdQdjjqXCrAV8I5DD1ExkXf+2sRM9vMI01xR0CXO0cp7SAwq3r
J+UA==
X-Gm-Message-State: ALoCoQkm2Of3ARgTV3TuVVJxvaTWiSYDXMFWuvZ9b2Sgv/4+a4vCaTo060mF0bBo1Cf7hN5c/zvj
X-Received: by 10.195.13.234 with SMTP id fb10mr2110980wjd.50.1385992500838;
Mon, 02 Dec 2013 05:55:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.195.18.40 with HTTP; Mon, 2 Dec 2013 05:54:30 -0800 (PST)
X-Originating-IP: [124.171.135.157]
In-Reply-To: <39921E12-B411-4430-9D56-04F53906B109@plan99.net>
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>
From: Patrick Mead <patrick@meadia.com.au>
Date: Tue, 3 Dec 2013 00:24:30 +1030
Message-ID: <CAGLkj4C9fyAX1CnB0oZH3BwLRQp6WOo9kLUqDhRUSA6y3LxYvg@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: plan99.net]
X-Headers-End: 1VnUNr-00058A-Ba
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: Mon, 02 Dec 2013 14:22:00 -0000
First time posting to this mailing list so feel free to ignore me if
this is a stupid idea.
On Mon, Dec 2, 2013 at 3:49 AM, Mike Hearn <mike@plan99.net> wrote:
>
> We need to get away from the notion of senders attaching fees anyway. Thi=
s is the wrong
> way around because it=E2=80=99s the recipient who cares about double spen=
ding risk, not the sender.
>
It seems to me that a common problem currently revolves around
accepting transactions in
retail scenarios, such as paying for a sandwich from Subway. A
solution could be to give the
vendor responsibility for setting the fee, which means they can choose
the trade-off that works
best for them in terms of fee size vs. speed of processing.
Idea:
Add a "fee" parameter to the payment URI specification.
When processing the transaction, the customer's UI should show only
the total price, including
both the transfer amount and the fee. The vendor only accepts the
transaction if the customer
uses the right amount and fee. If the fee is too small (for example,
the user might be using an
older wallet and has selected a fee of zero), the vendor can issue a
refund transaction
immediately and tell the user to try again.
Pros:
- could easily be implemented immediately
- old wallets would still be supported by just manually entering the
fee as users do now
- no greater risk of double spending on either side
- maintains the distributed nature of the system
- relies on humans to judge the fee (who are much less likely to
spiral infinitely upwards)
- flexible enough to support varying sizes of transaction and varying
degrees of security
Cons
- requires the vendor to have sufficient understanding of Bitcoin to
make the trade-off
- doesn't solve the problem of selecting a fee for transactions
between individuals/laymen
- doesn't solve fee selection for automated transactions such as
mixing/de/refragmentation
Thoughts?
|
