* [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 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: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: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
* 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 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 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-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
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