+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
