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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
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 <jgarzik@bitpay.com>) id 1WzrfN-0007ar-Ky
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 18:11:29 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com
designates 74.125.82.50 as permitted sender)
client-ip=74.125.82.50; envelope-from=jgarzik@bitpay.com;
helo=mail-wg0-f50.google.com;
Received: from mail-wg0-f50.google.com ([74.125.82.50])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WzrfL-0006kx-Tf
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 18:11:29 +0000
Received: by mail-wg0-f50.google.com with SMTP id m15so2362945wgh.21
for <bitcoin-development@lists.sourceforge.net>;
Wed, 25 Jun 2014 11:11:19 -0700 (PDT)
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:cc:content-type:content-transfer-encoding;
bh=ExFgYo4Y1lI4/XTeMF8JPJO1mNkmCIFUaL+m00R4WZQ=;
b=WBqIkT9DvXwKU1Ry1SW2I5Nf/sp15pRtSzC82DRKZWrxsB0u1eUiz8/58qYHyzmrEX
MfLLNfEG/uPMpK/yYkSNSviHeL2cdrZaSmMRfmLdURHiI3T3l88k/UHhLPyKvYHyIWvV
8BpbEJhmbNad9ajjA5rwz/XYsnJKexr8D8QGiAu3hw1ULdT9yswCNTQPzT8o2obgy84L
iUwrOk4+DfGeNQHoOC4gHJ9AfMLJvrjiDWsAcxbcK37PEmFOr1gG/g+E4tMYlcc4WAWP
vMNtuDFeaEgzbcZY44WxbI7d9hSGf03d2voULiQv8iZJH+lJJj0Z9QnN1QiHF/6XXY9m
TEyA==
X-Gm-Message-State: ALoCoQnKlxxymT/BVMZoZXOFW4SctFxuQf5OBlgVAOad/1GYeisltAJ97OZJTkPBalBrPNUGozoH
X-Received: by 10.194.77.103 with SMTP id r7mr11606137wjw.67.1403719878772;
Wed, 25 Jun 2014 11:11:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.195.12.3 with HTTP; Wed, 25 Jun 2014 11:10:58 -0700 (PDT)
In-Reply-To: <CAC1+kJN0ajyfFbLbuxqSph=LhaaHM71=4KAj7W1ggivxuxAvRA@mail.gmail.com>
References: <CANEZrP3iyQ9zQ+hDnooxrjdBO+_Fj+nAkK1Skgk+Gb4gkidPhQ@mail.gmail.com>
<CAJHLa0Omiz+UhGjSKgYU7+b2YY7aN23w7o8CQntqMePFs7LkjA@mail.gmail.com>
<CANEZrP06gk-JhKaNpvYUTfjFq9AGnCay9=pjUGpVMjMSuX3_ew@mail.gmail.com>
<CAJna-HhX8HOci0KMe4ZScr4QW792S3n5twvU0QhbQe1N_3q7_w@mail.gmail.com>
<6E6F88E9-5698-419B-927C-F65A5FCABBE9@gmail.com>
<CAJHLa0PYfuJg3daPvzPFZpFz7ezH2RHpJ8zyz2g1NDKppM7rWA@mail.gmail.com>
<BBF86C9B-6B3D-4A03-AC7B-35619C47091F@gmail.com>
<CABsx9T13yksenx5aYd4HVqTyVjARx9aTHy=Neu64p6k9FnRRVw@mail.gmail.com>
<C95DB811-9E6A-4EA2-AE8F-83595C3AC817@gmail.com>
<CANEZrP0ce4MMX2hOhcGVWt23L_CMn6Cmj9_Okqd0BR9seQXJew@mail.gmail.com>
<CAC1+kJN0ajyfFbLbuxqSph=LhaaHM71=4KAj7W1ggivxuxAvRA@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Wed, 25 Jun 2014 14:10:58 -0400
Message-ID: <CAJHLa0MaoG2gDkgEkTuV0d3U1=p2Zmr4E-kO=qowpZeRY0q7Ew@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@monetize.io>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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.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: 1WzrfL-0006kx-Tf
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed BIP 70 extension
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, 25 Jun 2014 18:11:29 -0000
Remember the IETF RFC process.
1) RFCs are never updated. Extensions go into new RFCs.
2) Build an implementation, write a draft, circulate both. Then get a
BIP number.
3) As MH indicated, it would be useful to have a living payment
protocol document that _is_ updated.
4) Let's stop calling it BIP70. That just reinforces the desire to
update the BIP70 document.
On Wed, Jun 25, 2014 at 9:33 AM, Jorge Tim=C3=B3n <jtimon@monetize.io> wrot=
e:
> +1 on setting up the payment protocol extensions process more formally.
> On the feature itself, it is interesting to note that some
> complementary currencies backed by national currencies offer a
> discount when converting from fiat to complementary, which has an
> equivalent effect to this "discount for paying with btc". The main
> difference is that in local currencies the merchants are a relatively
> small group and the discount is uniform whereas here each merchant can
> set his own discount. There's scientific studies on how different
> currency features like these discounts affect adoption, velocity and
> other variables. I can ask for them if anyone is interested.
>
> On the implementation, I think a percentage/proportion would be
> preferable over an amount in satoshis.
> Let's imagine for a second that the bitcoin payment protocol ends up
> being a generalized and universal payment protocol. The field would be
> really something like "discount/additional_charge for paying with the
> chosen currency/payment_method".
> You could have 0.95 for a 5% discount or 1.05 for a 5% additional
> charge. Mhmm, maybe a flat discount/charge in addition to the
> proportional one...
>
> On security, being an optional field, I don't see how can it harm anythin=
g.
> It is true that the merchants can lie about the discount, but wallets
> can be smart or stupid about it, or just completely ignore the field
> as they wish.
>
> Anyway, it feels like a random simple extension as an excuse to
> develop the extension process. If it gets too complicated we can start
> with a simpler and less critical one but it's hard for me to imagine
> it.
>
>
> On 6/25/14, Mike Hearn <mike@plan99.net> wrote:
>>>
>>> I agree. It would be even sillier to start specifying container formats
>>> for random one-off "that would be kind of nice, I guess" features.
>>>
>>
>> No, it'd be sensible.
>>
>> Here's a list I drew up a long time ago of features I imagined adding to
>> the payment protocol:
>>
>> https://bitcointalk.org/index.php?topic=3D270055.msg2890147#msg2890147
>>
>> The protocol is there to contain features! There is zero benefit to
>> slavishly following some religious notion of purity or minimalism here. =
The
>> shared resource in question is just varint encoded integers. So, we shou=
ld
>> be guided by what will help our users and what will help adoption.
>>
>> Anyway, Gavin asked me to start handling more BIP 70 stuff a few weeks a=
go.
>> I want to use something simple to set up the extensions process more
>> formally. IMO we need a "living document" version of the payment protoco=
l
>> with all the different extensions out there folded into it, to simplify
>> programming tasks and ensure field numbers don't collide.
>>
>
>
> --
> Jorge Tim=C3=B3n
>
> -------------------------------------------------------------------------=
-----
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Editi=
on
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--=20
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
|
