[Bitcoin-development] Proposed BIP 70 extension

[Bitcoin-development] Proposed BIP 70 extension

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

Coinbase have started allowing merchants to set discounts for purchasing
with Bitcoin. Seeing an individual discount is not very motivating as they
tend to be small. Seeing them stack up over time can be more motivating
because it feels like free money. Many businesses exploit this effect with
loyalty points, etc. Bitcoin should do this too - show the user how much
they're saving by using Bitcoin instead of credit cards.

I suggested to Charlie Lee (who pushed this through at Coinbase) and
Stephen Pair the following minor BIP 70 extension:


message PaymentDetails {
    // Size in satoshis of any discount provided by the merchant ONLY
    // because the user chose to pay using Bitcoin or other similar
    // digital currency. Other kinds of discounts, loyalty bonuses and
    // so on should not be recorded here, rather they could be mentioned
    // in the memo field. This field exists so wallets can show the user
    // a running total of how much money they have saved by avoiding
    // credit cards and bank payments; the goal is to encourage people to
    // use Bitcoin. Putting other kinds of discounts here would make the
    // running total calculated meaningless; so don't do it!
    optional uint64 currency_usage_discount_size = 8;
}

Wallets would then be able to persist this data to disk and compete on cool
visualisations for how much money you saved over time.

We haven't formalised how to extend BIP 70 yet, that's my fault. We should
do that. In the meantime, what do people think of this proposal?

[-- Attachment #2: Type: text/html, Size: 3393 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Jeff Garzik]

On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn <mike@plan99.net> wrote:
> Wallets would then be able to persist this data to disk and compete on cool visualisations for how much money you saved over time.

heh, this is a cool idea.

It also seems like it would be subject to instant inflation, as it's
unprovable, and a rational economic actor may choose to exaggerate
such numbers.  It also seems collectively rational by some points of
view for all bitcoin actors to inflate this number.

At a minimum, I would either add "marketing_" to the field name
itself, or include additional comment caveats noting in BOLD language
that this field is informational, and should not be relied upon for
accounting/auditing purposes.

It just seems like a statistic that everyone has an incentive to exaggerate.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Proposed BIP 70 extension

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

>
> It also seems like it would be subject to instant inflation, as it's
> unprovable


The user knows the price that is on the website or menu, they know the
price they actually paid ... if the numbers don't add up that would seem to
be pretty easily detectable. But sure it's only for marketing.  I think the
comment makes it clear it's just for fun.

[-- Attachment #2: Type: text/html, Size: 595 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[slush]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

Sounds like marketing bullshit to me. It does not have even statistical
meaning; well, you can "save" a lot of satoshis, but nobody tell you that
the merchant cut you on BTC/USD exchange rate in tens of %.

Payment protocol should not contain these fictional data, which has no real
meaning for the payment itself. Put these marketing claims to memo field
instead...

slush


On Tue, Jun 24, 2014 at 4:24 PM, Mike Hearn <mike@plan99.net> wrote:

> It also seems like it would be subject to instant inflation, as it's
>> unprovable
>
>
> The user knows the price that is on the website or menu, they know the
> price they actually paid ... if the numbers don't add up that would seem to
> be pretty easily detectable. But sure it's only for marketing.  I think the
> comment makes it clear it's just for fun.
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 2267 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

>
> Sounds like marketing bullshit to me. It does not have even statistical
> meaning; well, you can "save" a lot of satoshis, but nobody tell you that
> the merchant cut you on BTC/USD exchange rate in tens of %.
>

Your own wallet can look up the exchange rate and compare it to what you're
getting (and in fact, wallets do!).

Besides, assuming the customer is *always* being scammed seems extreme.
There are plenty of merchants that genuinely care about their reputation
and genuinely want people to pay with Bitcoin so they can avoid card fees.


> Payment protocol should not contain these fictional data
>

Well, I think the protocol should contain whatever is useful.

I'll probably draft a BIP for this next week or so.

[-- Attachment #2: Type: text/html, Size: 1218 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Gmail]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]



> On Jun 24, 2014, at 10:32, slush <slush@centrum.cz> wrote:
> 
> Sounds like marketing bullshit to me. It does not have even statistical meaning; well, you can "save" a lot of satoshis, but nobody tell you that the merchant cut you on BTC/USD exchange rate in tens of %.

People would also abuse this feature in the same way amazon (and other sales sites) abuse the definition of "save". For example, Amazon will indicate that you're getting x% off by shopping at amazon, but all that number really means is x% off MSRP. In reality, every website has the same price. I have no doubt that merchants would put similarly meaningless and/or misleading data in this field. 

I agree, the memo field is appropriate for this data. 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1593 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Andreas Schildbach]

I think it should be made more clear what's the reference price for the
discount. In Germany, we generally don't use credit cards but rather
"EC-Cards", which is already much cheaper. Or maybe for some merchants
the only alternative is cash, and they would still offer a Bitcoin discount.

Also, currently PR are created by the payment processors afaik. How can
they know what other payment option the merchant provides and what's the
conditions? Maybe we should first solve the signature delegation problem
so that the merchant can create the request.

Although I'm sure this feature will get abused, I (as a wallet author)
would be willing to give it a try. I agree with Jeff that the name of
the field should start with something like "marketing".


On 06/24/2014 03:27 PM, Mike Hearn wrote:
> Coinbase have started allowing merchants to set discounts for purchasing
> with Bitcoin. Seeing an individual discount is not very motivating as
> they tend to be small. Seeing them stack up over time can be more
> motivating because it feels like free money. Many businesses exploit
> this effect with loyalty points, etc. Bitcoin should do this too - show
> the user how much they're saving by using Bitcoin instead of credit cards.
> 
> I suggested to Charlie Lee (who pushed this through at Coinbase) and
> Stephen Pair the following minor BIP 70 extension:
> 
> 
> message PaymentDetails {
>     // Size in satoshis of any discount provided by the merchant ONLY
>     // because the user chose to pay using Bitcoin or other similar 
>     // digital currency. Other kinds of discounts, loyalty bonuses and 
>     // so on should not be recorded here, rather they could be mentioned
>     // in the memo field. This field exists so wallets can show the user
>     // a running total of how much money they have saved by avoiding
>     // credit cards and bank payments; the goal is to encourage people to
>     // use Bitcoin. Putting other kinds of discounts here would make the
>     // running total calculated meaningless; so don't do it!
>     optional uint64 currency_usage_discount_size = 8;
> }
> 
> Wallets would then be able to persist this data to disk and compete on
> cool visualisations for how much money you saved over time.
> 
> We haven't formalised how to extend BIP 70 yet, that's my fault. We
> should do that. In the meantime, what do people think of this proposal?
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> 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
> 

Re: [Bitcoin-development] Proposed BIP 70 extension

[Jeff Garzik]

I think there is nothing wrong with having a numeric memo field, which
is effectively what this is.  Structured rather than unstructured
data.

On Tue, Jun 24, 2014 at 11:15 AM, Gmail <will.yager@gmail.com> wrote:
>
>
>> On Jun 24, 2014, at 10:32, slush <slush@centrum.cz> wrote:
>>
>> Sounds like marketing bullshit to me. It does not have even statistical meaning; well, you can "save" a lot of satoshis, but nobody tell you that the merchant cut you on BTC/USD exchange rate in tens of %.
>
> People would also abuse this feature in the same way amazon (and other sales sites) abuse the definition of "save". For example, Amazon will indicate that you're getting x% off by shopping at amazon, but all that number really means is x% off MSRP. In reality, every website has the same price. I have no doubt that merchants would put similarly meaningless and/or misleading data in this field.
>
> I agree, the memo field is appropriate for this data.
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> 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
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Proposed BIP 70 extension

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

>
> I think it should be made more clear what's the reference price for the
> discount.
>

That might be useful for merchants that already provide a series of
price-differentiated payment methods, yes. Will think about it.


> Also, currently PR are created by the payment processors afaik. How can
> they know what other payment option the merchant provides and what's the
> conditions?
>

Currently Coinbase let merchants specify the size of their discount (I
guess in percentage terms, I should ask). So the merchants tell the payment
processor. I don't think this is a worry at the moment.

[-- Attachment #2: Type: text/html, Size: 991 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Drak]

[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]

Seems like a nice idea.


On 24 June 2014 14:27, Mike Hearn <mike@plan99.net> wrote:

> Coinbase have started allowing merchants to set discounts for purchasing
> with Bitcoin. Seeing an individual discount is not very motivating as they
> tend to be small. Seeing them stack up over time can be more motivating
> because it feels like free money. Many businesses exploit this effect with
> loyalty points, etc. Bitcoin should do this too - show the user how much
> they're saving by using Bitcoin instead of credit cards.
>
> I suggested to Charlie Lee (who pushed this through at Coinbase) and
> Stephen Pair the following minor BIP 70 extension:
>
>
> message PaymentDetails {
>     // Size in satoshis of any discount provided by the merchant ONLY
>     // because the user chose to pay using Bitcoin or other similar
>     // digital currency. Other kinds of discounts, loyalty bonuses and
>     // so on should not be recorded here, rather they could be mentioned
>     // in the memo field. This field exists so wallets can show the user
>     // a running total of how much money they have saved by avoiding
>     // credit cards and bank payments; the goal is to encourage people to
>     // use Bitcoin. Putting other kinds of discounts here would make the
>     // running total calculated meaningless; so don't do it!
>     optional uint64 currency_usage_discount_size = 8;
> }
>
> Wallets would then be able to persist this data to disk and compete on
> cool visualisations for how much money you saved over time.
>
> We haven't formalised how to extend BIP 70 yet, that's my fault. We should
> do that. In the meantime, what do people think of this proposal?
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 4647 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Roy Badami]

On Tue, Jun 24, 2014 at 10:21:46AM -0400, Jeff Garzik wrote:
> On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn <mike@plan99.net> wrote:
> > Wallets would then be able to persist this data to disk and compete on cool visualisations for how much money you saved over time.
> 
> heh, this is a cool idea.
> 
> It also seems like it would be subject to instant inflation, as it's
> unprovable, and a rational economic actor may choose to exaggerate
> such numbers.  It also seems collectively rational by some points of
> view for all bitcoin actors to inflate this number.

Rather than offering discounts, how about offering automatic cashback?
I know they're kinda stupid, but I gather cashback deals are very
commonplace in the US and (probably as a result) not unheard of elsewhere.

So you add an optional cashback_to field to the Payment message,
distinct from but conceptually similar to the refund_to field.  The
wallet can tally up how much cashback is received, without having to
trust the merchants.

Much harder to game, AFAICS.

roy

Re: [Bitcoin-development] Proposed BIP 70 extension

[Gmail]

[-- Attachment #1.1: Type: text/plain, Size: 740 bytes --]

Ok, wanting structured data is a decent argument, but why this random arbitrary case in particular? There are hundreds of fields like this that people might want to use. 

If we're going to support one random cosmetic field, we might as well support them all with a generic structured data format. 

I'd rather we just didn't have this essentially pointless "feature" at all. Let's try and keep as much cruft as possible out of the payment protocol. The textual memo field is already more than sufficient. 

> On Jun 24, 2014, at 11:48, Jeff Garzik <jgarzik@bitpay.com> wrote:
> 
> I think there is nothing wrong with having a numeric memo field, which
> is effectively what this is.  Structured rather than unstructured
> data.

[-- Attachment #1.2: Type: text/html, Size: 1068 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1593 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Andy Alness]

I somewhat agree with Will (but also with Mike, Jeff, and Charlie.) I
think the idea of letting consumers know advanced details about the
transaction is good and defining these with strong types is also good.
Maybe an arbitrary set of accounting line items would be more
palatable. You could have a line item for state sales tax for example,
or a cash back reward, or a merchant discount like the proposed,
whatever is applicable. It would be a list of amount / label tuples
maybe.

On Tue, Jun 24, 2014 at 12:00 PM, Gmail <will.yager@gmail.com> wrote:
> Ok, wanting structured data is a decent argument, but why this random
> arbitrary case in particular? There are hundreds of fields like this that
> people might want to use.
>
> If we're going to support one random cosmetic field, we might as well
> support them all with a generic structured data format.
>
> I'd rather we just didn't have this essentially pointless "feature" at all.
> Let's try and keep as much cruft as possible out of the payment protocol.
> The textual memo field is already more than sufficient.
>
> On Jun 24, 2014, at 11:48, Jeff Garzik <jgarzik@bitpay.com> wrote:
>
> I think there is nothing wrong with having a numeric memo field, which
> is effectively what this is.  Structured rather than unstructured
> data.
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> 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
>



-- 
Andy Alness
Software Engineer
Coinbase
San Francisco, CA

Re: [Bitcoin-development] Proposed BIP 70 extension

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On Tue, Jun 24, 2014 at 3:00 PM, Gmail <will.yager@gmail.com> wrote:

> Ok, wanting structured data is a decent argument, but why this random
> arbitrary case in particular? There are hundreds of fields like this that
> people might want to use.
>

Protocol buffers are designed to be extensible, and there are hundreds of
field numbers available.

It would be silly to add a "generic stuff" field inside a container format
that ALREADY has all the mechanisms necessary for forwards and backwards
extensibility.


-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 969 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Gmail]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

> On Jun 24, 2014, at 16:12, Gavin Andresen <gavinandresen@gmail.com> wrote:
> 
> It would be silly to add a "generic stuff" field inside a container format that ALREADY has all the mechanisms necessary for forwards and backwards extensibility.

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. 

How about exchange rate? Sharing links? Referral information? Any of these things are just as deserving of specification (and just as arbitrary). 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1593 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

>
> 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=270055.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 should
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 ago.
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.

[-- Attachment #2: Type: text/html, Size: 1490 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Jorge Timón]

+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=270055.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 should
> 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 ago.
> 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.
>


-- 
Jorge Timón

Re: [Bitcoin-development] Proposed BIP 70 extension

[slush]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Wed, Jun 25, 2014 at 10:25 AM, Mike Hearn <mike@plan99.net> wrote:
>
> The protocol is there to contain features! There is zero benefit to
> slavishly following some religious notion of purity or minimalism here.
>

Good standard must be explicit as much as possible. Having million optional
fields with ambiguous meaning is even worse than not having these fields.

HTTP status codes are good example. There are hundreds of them, still
applications understands just few of them, because other have ambiguous
meaning and software don't know how to handle them.

Good example of such over-engineering is also XMPP. XMPP has milions
extensions and features, but look at Jabber clients; call yourself lucky
when you can send messages and files, although there're various extensions
like searching for contacts (something which has be working in ICQ decade
ago), voice support, end to end encryption or alerting users. These
features are defined, but not widely implemented, because its definition is
vague or the feature is abused because of poor design.

Please don't over-engineer payment protocol.

Thank you for your attention.

slush

[-- Attachment #2: Type: text/html, Size: 1707 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Gmail]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]


> On Jun 25, 2014, at 10:15, slush <slush@centrum.cz> wrote:
> Good standard must be explicit as much as possible. Having million optional fields with ambiguous meaning is even worse than not having these fields.

+1. BIP70 is important. We want to keep it very simple and generalized, or there is a very real risk that implementers will either not bother with it or implement it in buggy, poorly standardized ways. 

Any information not required by the machine should only exist in human-oriented fields (namely, the memo field). 

Let's try to avoid ending up with another horrendously complicated, edge-case-oriented protocol like we programmers frequently complain about. 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1593 bytes --]

Re: [Bitcoin-development] Proposed BIP 70 extension

[Jeff Garzik]

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ón <jtimon@monetize.io> wrote:
> +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=270055.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 should
>> 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 ago.
>> 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.
>>
>
>
> --
> Jorge Timón
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> 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



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/