📅 Original date posted:2014-06-25
📝 Original message: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 at 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 at 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 at 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/
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 15:23:18
in reply to nevent1q…uv3w
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 15:23:18Event JSON
{
"id": "a05b0a5be6cf9657fe7c4006036e0cb215723a731ddcff4e4fe7bcf02c22adbf",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686151398,
"kind": 1,
"tags": [
[
"e",
"9815d098bc7f4989718551eb052a860bc92caef6ef36f2244b5fda76fe0b928a",
"",
"root"
],
[
"e",
"9c0a2516df0f3ce1dba0941ec8edee57163504bf6c68dbc3bf2e8332b257758c",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2014-06-25\n📝 Original message:Remember the IETF RFC process.\n\n1) RFCs are never updated. Extensions go into new RFCs.\n2) Build an implementation, write a draft, circulate both. Then get a\nBIP number.\n3) As MH indicated, it would be useful to have a living payment\nprotocol document that _is_ updated.\n4) Let's stop calling it BIP70. That just reinforces the desire to\nupdate the BIP70 document.\n\n\n\nOn Wed, Jun 25, 2014 at 9:33 AM, Jorge Timón \u003cjtimon at monetize.io\u003e wrote:\n\u003e +1 on setting up the payment protocol extensions process more formally.\n\u003e On the feature itself, it is interesting to note that some\n\u003e complementary currencies backed by national currencies offer a\n\u003e discount when converting from fiat to complementary, which has an\n\u003e equivalent effect to this \"discount for paying with btc\". The main\n\u003e difference is that in local currencies the merchants are a relatively\n\u003e small group and the discount is uniform whereas here each merchant can\n\u003e set his own discount. There's scientific studies on how different\n\u003e currency features like these discounts affect adoption, velocity and\n\u003e other variables. I can ask for them if anyone is interested.\n\u003e\n\u003e On the implementation, I think a percentage/proportion would be\n\u003e preferable over an amount in satoshis.\n\u003e Let's imagine for a second that the bitcoin payment protocol ends up\n\u003e being a generalized and universal payment protocol. The field would be\n\u003e really something like \"discount/additional_charge for paying with the\n\u003e chosen currency/payment_method\".\n\u003e You could have 0.95 for a 5% discount or 1.05 for a 5% additional\n\u003e charge. Mhmm, maybe a flat discount/charge in addition to the\n\u003e proportional one...\n\u003e\n\u003e On security, being an optional field, I don't see how can it harm anything.\n\u003e It is true that the merchants can lie about the discount, but wallets\n\u003e can be smart or stupid about it, or just completely ignore the field\n\u003e as they wish.\n\u003e\n\u003e Anyway, it feels like a random simple extension as an excuse to\n\u003e develop the extension process. If it gets too complicated we can start\n\u003e with a simpler and less critical one but it's hard for me to imagine\n\u003e it.\n\u003e\n\u003e\n\u003e On 6/25/14, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e I agree. It would be even sillier to start specifying container formats\n\u003e\u003e\u003e for random one-off \"that would be kind of nice, I guess\" features.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e No, it'd be sensible.\n\u003e\u003e\n\u003e\u003e Here's a list I drew up a long time ago of features I imagined adding to\n\u003e\u003e the payment protocol:\n\u003e\u003e\n\u003e\u003e https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147\n\u003e\u003e\n\u003e\u003e The protocol is there to contain features! There is zero benefit to\n\u003e\u003e slavishly following some religious notion of purity or minimalism here. The\n\u003e\u003e shared resource in question is just varint encoded integers. So, we should\n\u003e\u003e be guided by what will help our users and what will help adoption.\n\u003e\u003e\n\u003e\u003e Anyway, Gavin asked me to start handling more BIP 70 stuff a few weeks ago.\n\u003e\u003e I want to use something simple to set up the extensions process more\n\u003e\u003e formally. IMO we need a \"living document\" version of the payment protocol\n\u003e\u003e with all the different extensions out there folded into it, to simplify\n\u003e\u003e programming tasks and ensure field numbers don't collide.\n\u003e\u003e\n\u003e\n\u003e\n\u003e --\n\u003e Jorge Timón\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Open source business process management suite built on Java and Eclipse\n\u003e Turn processes into business applications with Bonita BPM Community Edition\n\u003e Quickly connect people, data, and systems into organized workflows\n\u003e Winner of BOSSIE, CODIE, OW2 and Gartner awards\n\u003e http://p.sf.net/sfu/Bonitasoft\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n\n\n-- \nJeff Garzik\nBitcoin core developer and open source evangelist\nBitPay, Inc. https://bitpay.com/",
"sig": "7945935314db3288d16e5babe9c9197c091ad7b95ad3d993b3d7ddf216f6984156fc850a7b017e320ccf4bb71a619e5b93dad112dbfa0692f71c01ba7a104595"
}