summaryrefslogtreecommitdiff
path: root/d3/a6dd720f0b7b3fa8ff87d340d9e88204c74fe7
blob: b02ce7ae3c4ada2080db494c081ccbede67d9b8c (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1Vneyg-0003vd-Fk
	for bitcoin-development@lists.sourceforge.net;
	Tue, 03 Dec 2013 01:40:42 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.174 as permitted sender)
	client-ip=74.125.82.174; envelope-from=gavinandresen@gmail.com;
	helo=mail-we0-f174.google.com; 
Received: from mail-we0-f174.google.com ([74.125.82.174])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Vneyf-0004ZE-He
	for bitcoin-development@lists.sourceforge.net;
	Tue, 03 Dec 2013 01:40:42 +0000
Received: by mail-we0-f174.google.com with SMTP id q58so12714068wes.5
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 02 Dec 2013 17:40:35 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.13.142 with SMTP id h14mr169672wic.3.1386034835247; Mon,
	02 Dec 2013 17:40:35 -0800 (PST)
Received: by 10.195.13.68 with HTTP; Mon, 2 Dec 2013 17:40:35 -0800 (PST)
In-Reply-To: <CANEZrP2hf2853w9f4__Ji9v3eRRU0u6pEzPxAmFN+iH067gtnA@mail.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>
Date: Tue, 3 Dec 2013 11:40:35 +1000
Message-ID: <CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a11c23dc2005a9404ec9762c8
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gavinandresen[at]gmail.com)
	-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: plan99.net]
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-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: 1Vneyf-0004ZE-He
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 01:40:42 -0000

--001a11c23dc2005a9404ec9762c8
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn <mike@plan99.net> wrote:

> PPv1 doesn't have any notion of fee unfortunately. I suppose it could be
> added easily, but we also need to launch the existing feature set.
>

Lets bang out a merchant-pays-fee extension.

How about:

SPEC:

    optional uint64 allowfee    tag number=1000

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.

:ENDSPEC

Rationale: we don't want wallet software giving users discounts-- sending
transactions that are amount-allowfee without paying any fee.  We also want
to allow users to pay MORE in fees, if they need to (fragmented wallet,
maybe, or big CoinJoin transaction) or decide to.


PS: I think there was also consensus that the BIP72  request=...   should
be shortened to just r=... (save 6 chars in QR codes).  Unless somebody
objects, I'll change the BIP and the reference implementation code to make
it so...

-- 
--
Gavin Andresen

--001a11c23dc2005a9404ec9762c8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 3, 2013 at 12:44 AM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">PPv1 doesn&#39;t have any notion of fee unfortunately. I s=
uppose it could be added easily, but we also need to launch the existing fe=
ature set.</div></blockquote><div><br></div><div>Lets bang out a merchant-p=
ays-fee extension.</div>
<div><br></div><div>How about:</div><div><br></div><div>SPEC:</div><div><br=
></div><div>=A0 =A0 optional uint64 allowfee =A0 =A0tag number=3D1000</div>=
<div><br></div><div>Allow up to allowfee satoshis to be deducted from the a=
mount paid to be used to pay Bitcoin network transaction fees. A wallet imp=
lementation must not reduce the amount paid for fees more than allowfee, an=
d transaction fees must be equal to or greater than the amount reduced.</di=
v>
<div><br></div><div>:ENDSPEC</div><div><br></div><div>Rationale: we don&#39=
;t want wallet software giving users discounts-- sending transactions that =
are amount-allowfee without paying any fee. =A0We also want to allow users =
to pay MORE in fees, if they need to (fragmented wallet, maybe, or big Coin=
Join transaction) or decide to.</div>
<div><br></div><div><br></div><div>PS: I think there was also consensus tha=
t the BIP72 =A0request=3D... =A0 should be shortened to just r=3D... (save =
6 chars in QR codes). =A0Unless somebody objects, I&#39;ll change the BIP a=
nd the reference implementation code to make it so...</div>
<div><br></div></div>-- <br>--<br>Gavin Andresen<br>
</div><div class=3D"gmail_extra"><br></div></div>

--001a11c23dc2005a9404ec9762c8--