Re: [Bitcoin-development] Proposed BIP 70 extension
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. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
+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 m...@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
Re: [Bitcoin-development] Proposed BIP 70 extension
On Wed, Jun 25, 2014 at 10:25 AM, Mike Hearn m...@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 -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Jun 25, 2014, at 10:15, slush sl...@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. smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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 jti...@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 m...@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/ -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn m...@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/ -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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
Re: [Bitcoin-development] Proposed BIP 70 extension
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 m...@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 -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Jun 24, 2014, at 10:32, slush sl...@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. smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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.ya...@gmail.com wrote: On Jun 24, 2014, at 10:32, slush sl...@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/ -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
Seems like a nice idea.
On 24 June 2014 14:27, Mike Hearn m...@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
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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 jgar...@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. smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Tue, Jun 24, 2014 at 10:21:46AM -0400, Jeff Garzik wrote: On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn m...@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 -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
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.ya...@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 jgar...@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 -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Tue, Jun 24, 2014 at 3:00 PM, Gmail will.ya...@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 -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Jun 24, 2014, at 16:12, Gavin Andresen gavinandre...@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). smime.p7s Description: S/MIME cryptographic signature -- 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
