Proposed BIP 70 extension
20 messages, 24 to 25 Jun 2014. Started by Mike Hearn.
Mike Hearn (5), William Yager (4), Jeff Garzik (3), slush (2), Andreas Schildbach, Drak, Roy Badami, Andy Alness, +2 more
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?
On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (1 line)
> 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.
Quoted text (3 lines)
> > 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.
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:
Quoted text (22 lines)
> 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 > >
Quoted text (5 lines)
> > 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.
Quoted text (2 lines)
> 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.
Quoted text (3 lines)
> 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.
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:
Quoted text (45 lines)
> 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
>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:
Quoted text (20 lines)
> > >> 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 >
Quoted text (4 lines)
> > 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.
Quoted text (4 lines)
> 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.
Seems like a nice idea.
On 24 June 2014 14:27, Mike Hearn <mike@plan99•net> wrote:
Quoted text (43 lines)
> 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
>
>On Tue, Jun 24, 2014 at 10:21:46AM -0400, Jeff Garzik wrote:
Quoted text (9 lines)
> 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
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.
Quoted text (5 lines)
> 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.
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:
Quoted text (29 lines)
> 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 >
On Tue, Jun 24, 2014 at 3:00 PM, Gmail <will.yager@gmail•com> wrote:
Quoted text (4 lines)
> 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.
Quoted text (3 lines)
> 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).
Quoted text (4 lines)
> > 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.
+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:
Quoted text (23 lines)
>> >> 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. >
On Wed, Jun 25, 2014 at 10:25 AM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (4 lines)
> > 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
Quoted text (2 lines)
> 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.
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:
Quoted text (71 lines)
> +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