From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WzrfN-0007ar-Ky for bitcoin-development@lists.sourceforge.net; Wed, 25 Jun 2014 18:11:29 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com designates 74.125.82.50 as permitted sender) client-ip=74.125.82.50; envelope-from=jgarzik@bitpay.com; helo=mail-wg0-f50.google.com; Received: from mail-wg0-f50.google.com ([74.125.82.50]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WzrfL-0006kx-Tf for bitcoin-development@lists.sourceforge.net; Wed, 25 Jun 2014 18:11:29 +0000 Received: by mail-wg0-f50.google.com with SMTP id m15so2362945wgh.21 for ; Wed, 25 Jun 2014 11:11:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ExFgYo4Y1lI4/XTeMF8JPJO1mNkmCIFUaL+m00R4WZQ=; b=WBqIkT9DvXwKU1Ry1SW2I5Nf/sp15pRtSzC82DRKZWrxsB0u1eUiz8/58qYHyzmrEX MfLLNfEG/uPMpK/yYkSNSviHeL2cdrZaSmMRfmLdURHiI3T3l88k/UHhLPyKvYHyIWvV 8BpbEJhmbNad9ajjA5rwz/XYsnJKexr8D8QGiAu3hw1ULdT9yswCNTQPzT8o2obgy84L iUwrOk4+DfGeNQHoOC4gHJ9AfMLJvrjiDWsAcxbcK37PEmFOr1gG/g+E4tMYlcc4WAWP vMNtuDFeaEgzbcZY44WxbI7d9hSGf03d2voULiQv8iZJH+lJJj0Z9QnN1QiHF/6XXY9m TEyA== X-Gm-Message-State: ALoCoQnKlxxymT/BVMZoZXOFW4SctFxuQf5OBlgVAOad/1GYeisltAJ97OZJTkPBalBrPNUGozoH X-Received: by 10.194.77.103 with SMTP id r7mr11606137wjw.67.1403719878772; Wed, 25 Jun 2014 11:11:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.195.12.3 with HTTP; Wed, 25 Jun 2014 11:10:58 -0700 (PDT) In-Reply-To: References: <6E6F88E9-5698-419B-927C-F65A5FCABBE9@gmail.com> From: Jeff Garzik Date: Wed, 25 Jun 2014 14:10:58 -0400 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WzrfL-0006kx-Tf Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed BIP 70 extension X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 18:11:29 -0000 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=C3=B3n wrot= e: > +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 anythin= g. > 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 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=3D270055.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 shou= ld >> 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 a= go. >> I want to use something simple to set up the extensions process more >> formally. IMO we need a "living document" version of the payment protoco= l >> with all the different extensions out there folded into it, to simplify >> programming tasks and ensure field numbers don't collide. >> > > > -- > Jorge Tim=C3=B3n > > -------------------------------------------------------------------------= ----- > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Editi= on > 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 --=20 Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/