* [Bitcoin-development] Proposed BIP 70 extension
@ 2014-06-24 13:27 Mike Hearn
2014-06-24 14:21 ` Jeff Garzik
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Mike Hearn @ 2014-06-24 13:27 UTC (permalink / raw)
To: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 13:27 [Bitcoin-development] Proposed BIP 70 extension Mike Hearn @ 2014-06-24 14:21 ` Jeff Garzik 2014-06-24 14:24 ` Mike Hearn 2014-06-24 18:34 ` Roy Badami 2014-06-24 15:43 ` Andreas Schildbach 2014-06-24 17:37 ` Drak 2 siblings, 2 replies; 20+ messages in thread From: Jeff Garzik @ 2014-06-24 14:21 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev 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/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 14:21 ` Jeff Garzik @ 2014-06-24 14:24 ` Mike Hearn 2014-06-24 14:32 ` slush 2014-06-24 18:34 ` Roy Badami 1 sibling, 1 reply; 20+ messages in thread From: Mike Hearn @ 2014-06-24 14:24 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 14:24 ` Mike Hearn @ 2014-06-24 14:32 ` slush 2014-06-24 15:06 ` Mike Hearn 2014-06-24 15:15 ` Gmail 0 siblings, 2 replies; 20+ messages in thread From: slush @ 2014-06-24 14:32 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 14:32 ` slush @ 2014-06-24 15:06 ` Mike Hearn 2014-06-24 15:15 ` Gmail 1 sibling, 0 replies; 20+ messages in thread From: Mike Hearn @ 2014-06-24 15:06 UTC (permalink / raw) To: slush; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 14:32 ` slush 2014-06-24 15:06 ` Mike Hearn @ 2014-06-24 15:15 ` Gmail 2014-06-24 15:48 ` Jeff Garzik 1 sibling, 1 reply; 20+ messages in thread From: Gmail @ 2014-06-24 15:15 UTC (permalink / raw) To: slush; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 15:15 ` Gmail @ 2014-06-24 15:48 ` Jeff Garzik 2014-06-24 19:00 ` Gmail 0 siblings, 1 reply; 20+ messages in thread From: Jeff Garzik @ 2014-06-24 15:48 UTC (permalink / raw) To: Gmail; +Cc: Bitcoin Dev 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/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 15:48 ` Jeff Garzik @ 2014-06-24 19:00 ` Gmail 2014-06-24 19:34 ` Andy Alness 2014-06-24 20:12 ` Gavin Andresen 0 siblings, 2 replies; 20+ messages in thread From: Gmail @ 2014-06-24 19:00 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 19:00 ` Gmail @ 2014-06-24 19:34 ` Andy Alness 2014-06-24 20:12 ` Gavin Andresen 1 sibling, 0 replies; 20+ messages in thread From: Andy Alness @ 2014-06-24 19:34 UTC (permalink / raw) To: Gmail; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 19:00 ` Gmail 2014-06-24 19:34 ` Andy Alness @ 2014-06-24 20:12 ` Gavin Andresen 2014-06-24 20:28 ` Gmail 1 sibling, 1 reply; 20+ messages in thread From: Gavin Andresen @ 2014-06-24 20:12 UTC (permalink / raw) To: Gmail; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 20:12 ` Gavin Andresen @ 2014-06-24 20:28 ` Gmail 2014-06-25 8:25 ` Mike Hearn 0 siblings, 1 reply; 20+ messages in thread From: Gmail @ 2014-06-24 20:28 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 20:28 ` Gmail @ 2014-06-25 8:25 ` Mike Hearn 2014-06-25 13:33 ` Jorge Timón 2014-06-25 14:15 ` slush 0 siblings, 2 replies; 20+ messages in thread From: Mike Hearn @ 2014-06-25 8:25 UTC (permalink / raw) To: Gmail; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-25 8:25 ` Mike Hearn @ 2014-06-25 13:33 ` Jorge Timón 2014-06-25 18:10 ` Jeff Garzik 2014-06-25 14:15 ` slush 1 sibling, 1 reply; 20+ messages in thread From: Jorge Timón @ 2014-06-25 13:33 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev +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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-25 13:33 ` Jorge Timón @ 2014-06-25 18:10 ` Jeff Garzik 0 siblings, 0 replies; 20+ messages in thread From: Jeff Garzik @ 2014-06-25 18:10 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev 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/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-25 8:25 ` Mike Hearn 2014-06-25 13:33 ` Jorge Timón @ 2014-06-25 14:15 ` slush 2014-06-25 16:03 ` Gmail 1 sibling, 1 reply; 20+ messages in thread From: slush @ 2014-06-25 14:15 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-25 14:15 ` slush @ 2014-06-25 16:03 ` Gmail 0 siblings, 0 replies; 20+ messages in thread From: Gmail @ 2014-06-25 16:03 UTC (permalink / raw) To: slush; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 14:21 ` Jeff Garzik 2014-06-24 14:24 ` Mike Hearn @ 2014-06-24 18:34 ` Roy Badami 1 sibling, 0 replies; 20+ messages in thread From: Roy Badami @ 2014-06-24 18:34 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 13:27 [Bitcoin-development] Proposed BIP 70 extension Mike Hearn 2014-06-24 14:21 ` Jeff Garzik @ 2014-06-24 15:43 ` Andreas Schildbach 2014-06-24 15:59 ` Mike Hearn 2014-06-24 17:37 ` Drak 2 siblings, 1 reply; 20+ messages in thread From: Andreas Schildbach @ 2014-06-24 15:43 UTC (permalink / raw) To: bitcoin-development 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 > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 15:43 ` Andreas Schildbach @ 2014-06-24 15:59 ` Mike Hearn 0 siblings, 0 replies; 20+ messages in thread From: Mike Hearn @ 2014-06-24 15:59 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] Proposed BIP 70 extension 2014-06-24 13:27 [Bitcoin-development] Proposed BIP 70 extension Mike Hearn 2014-06-24 14:21 ` Jeff Garzik 2014-06-24 15:43 ` Andreas Schildbach @ 2014-06-24 17:37 ` Drak 2 siblings, 0 replies; 20+ messages in thread From: Drak @ 2014-06-24 17:37 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2014-06-25 18:11 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-24 13:27 [Bitcoin-development] Proposed BIP 70 extension Mike Hearn 2014-06-24 14:21 ` Jeff Garzik 2014-06-24 14:24 ` Mike Hearn 2014-06-24 14:32 ` slush 2014-06-24 15:06 ` Mike Hearn 2014-06-24 15:15 ` Gmail 2014-06-24 15:48 ` Jeff Garzik 2014-06-24 19:00 ` Gmail 2014-06-24 19:34 ` Andy Alness 2014-06-24 20:12 ` Gavin Andresen 2014-06-24 20:28 ` Gmail 2014-06-25 8:25 ` Mike Hearn 2014-06-25 13:33 ` Jorge Timón 2014-06-25 18:10 ` Jeff Garzik 2014-06-25 14:15 ` slush 2014-06-25 16:03 ` Gmail 2014-06-24 18:34 ` Roy Badami 2014-06-24 15:43 ` Andreas Schildbach 2014-06-24 15:59 ` Mike Hearn 2014-06-24 17:37 ` Drak
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox