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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@monetize.io>) id 1WznKV-0004pg-Ou
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 13:33:39 +0000
Received: from mail-la0-f46.google.com ([209.85.215.46])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WznKS-0004g8-9j
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 13:33:39 +0000
Received: by mail-la0-f46.google.com with SMTP id el20so742154lab.5
for <bitcoin-development@lists.sourceforge.net>;
Wed, 25 Jun 2014 06:33:28 -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:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=07Xlkdl5I6gfnK4MswoLXtQxNt8p80jpDrXH3cPkkxI=;
b=VdlMKo1AT47h+onk7gnt4iznB4aeTZMIii/BFKRydQh0rnGjvSiidavt3/hPzhIcn1
TLQQxaBfKSXZ42t2mhDOFJ8cEPurRNoAPiyV8OvWpa+fnZCADMcWFnIeszj/OqOe+4hH
GrHz+9FcHwtOh6D0vTpwjUv/rBceziD9MXi4LBv3zUUg27fCHrrqeePpRVO9OeW955qQ
YPrD6cgXCKnD+NltUEta0YpimKilnda3PgmTdI3wd8chllm0ut3iTHI1ouD7bd/2eQkE
K0WhjqpDTPrq5/ro+BLPum75gd4MKHGd0aWc9IPusivIsBahrXnraR+Y/DDfJPaKgBrm
eweQ==
X-Gm-Message-State: ALoCoQndVrdKrdTQOKa7mO4NVB9y0Vfnd8zm25oOqwVvg007xSwi8Z4yb87/42BnXHj/4rREbzoT
MIME-Version: 1.0
X-Received: by 10.152.28.70 with SMTP id z6mr836453lag.96.1403703208503; Wed,
25 Jun 2014 06:33:28 -0700 (PDT)
Received: by 10.112.185.4 with HTTP; Wed, 25 Jun 2014 06:33:28 -0700 (PDT)
X-Originating-IP: [85.53.220.188]
In-Reply-To: <CANEZrP0ce4MMX2hOhcGVWt23L_CMn6Cmj9_Okqd0BR9seQXJew@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>
Date: Wed, 25 Jun 2014 15:33:28 +0200
Message-ID: <CAC1+kJN0ajyfFbLbuxqSph=LhaaHM71=4KAj7W1ggivxuxAvRA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@monetize.io>
To: Mike Hearn <mike@plan99.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.
X-Headers-End: 1WznKS-0004g8-9j
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 13:33:39 -0000
+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 anything.
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. T=
he
> shared resource in question is just varint encoded integers. So, we shoul=
d
> 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 ag=
o.
> I want to use something simple to set up the extensions process more
> formally. IMO we need a "living document" version of the payment protocol
> with all the different extensions out there folded into it, to simplify
> programming tasks and ensure field numbers don't collide.
>
--=20
Jorge Tim=C3=B3n
|
