Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WzQlX-00017p-GI for bitcoin-development@lists.sourceforge.net; Tue, 24 Jun 2014 13:28:03 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.52 as permitted sender) client-ip=209.85.219.52; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f52.google.com; Received: from mail-oa0-f52.google.com ([209.85.219.52]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WzQlW-0000W9-IP for bitcoin-development@lists.sourceforge.net; Tue, 24 Jun 2014 13:28:03 +0000 Received: by mail-oa0-f52.google.com with SMTP id j17so308940oag.11 for ; Tue, 24 Jun 2014 06:27:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.79.102 with SMTP id i6mr838286obx.85.1403616477108; Tue, 24 Jun 2014 06:27:57 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.35.234 with HTTP; Tue, 24 Jun 2014 06:27:57 -0700 (PDT) Date: Tue, 24 Jun 2014 15:27:57 +0200 X-Google-Sender-Auth: ow69spSxjVXHe-aQxnBecTWw3vQ Message-ID: From: Mike Hearn To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7b2e46d284e14104fc94ed7e X-Spam-Score: -0.5 (/) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1WzQlW-0000W9-IP Subject: [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: Tue, 24 Jun 2014 13:28:03 -0000 --047d7b2e46d284e14104fc94ed7e Content-Type: text/plain; charset=UTF-8 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? --047d7b2e46d284e14104fc94ed7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Coinbase have started allowing merchants to set discounts = for purchasing with Bitcoin. Seeing an individual discount is not very moti= vating 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 Coinb= ase) and Stephen Pair the following minor BIP 70 extension:

<= /div>

message PaymentDetails {
=C2=A0 =C2=A0 //= Size in satoshis of any discount provided by the merchant ONLY
=C2=A0 =C2=A0 // because the user cho= se to pay using Bitcoin or other similar=C2=A0
=C2=A0 =C2=A0 // digital currency. Other kinds of discounts,=C2=A0loyalty bon= uses and=C2=A0
=C2=A0 =C2=A0 // so on should n= ot be recorded here, rather they could be mentioned
=C2=A0 =C2=A0 /= / in the memo field. This field exists so wallets can show the user<= /div>
=C2=A0 =C2=A0 // a running= total of how much money they have saved by avoiding
=C2=A0 =C2=A0 // credit cards a= nd bank payments; the goal is to encourage people to
=C2=A0 =C2=A0 /= / use Bitcoin. Putting other kinds of discounts here would make the<= /div>
=C2=A0 =C2=A0 // running t= otal calculated meaningless; so don't do it!
=C2=A0 =C2=A0 optional uint64 currency_usage_discount= _size =3D 8;
}

=
Wallets would th= en be able to persist this data to disk and compete on cool visualisations = for how much money you saved over time.

We haven't formali= sed how to extend BIP 70 yet, that's my fault. We should do that. In th= e meantime, what do people think of this proposal?
--047d7b2e46d284e14104fc94ed7e--