diff options
| author | Natanael <natanael.l@gmail.com> | 2015-02-10 11:21:03 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-02-10 10:21:11 +0000 |
| commit | b564c562882c0862565f539809e0824ec78d74a8 (patch) | |
| tree | 9fa2da9ae498dc1bdfee1294ad4ab86c363219b5 | |
| parent | de819210c103a66d0d3f6277fc15a4109a6fd28a (diff) | |
| download | pi-bitcoindev-b564c562882c0862565f539809e0824ec78d74a8.tar.gz pi-bitcoindev-b564c562882c0862565f539809e0824ec78d74a8.zip | |
[Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)
| -rw-r--r-- | b8/18e974049cb8915b6ada185860ad05d2108de4 | 178 |
1 files changed, 178 insertions, 0 deletions
diff --git a/b8/18e974049cb8915b6ada185860ad05d2108de4 b/b8/18e974049cb8915b6ada185860ad05d2108de4 new file mode 100644 index 000000000..47307007c --- /dev/null +++ b/b8/18e974049cb8915b6ada185860ad05d2108de4 @@ -0,0 +1,178 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <natanael.l@gmail.com>) id 1YL7wN-0005mN-IQ + for bitcoin-development@lists.sourceforge.net; + Tue, 10 Feb 2015 10:21:11 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 74.125.82.179 as permitted sender) + client-ip=74.125.82.179; envelope-from=natanael.l@gmail.com; + helo=mail-we0-f179.google.com; +Received: from mail-we0-f179.google.com ([74.125.82.179]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YL7wL-0006mY-Tq + for bitcoin-development@lists.sourceforge.net; + Tue, 10 Feb 2015 10:21:11 +0000 +Received: by mail-we0-f179.google.com with SMTP id u56so27060847wes.10 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 10 Feb 2015 02:21:03 -0800 (PST) +MIME-Version: 1.0 +X-Received: by 10.194.172.35 with SMTP id az3mr51270504wjc.43.1423563663777; + Tue, 10 Feb 2015 02:21:03 -0800 (PST) +Received: by 10.194.92.208 with HTTP; Tue, 10 Feb 2015 02:21:03 -0800 (PST) +Received: by 10.194.92.208 with HTTP; Tue, 10 Feb 2015 02:21:03 -0800 (PST) +In-Reply-To: <CAAt2M18H0K99bmD4H_FRSeE+O9nGFDruCmo63GOQt1kxAdVBmQ@mail.gmail.com> +References: <CAAt2M18H0K99bmD4H_FRSeE+O9nGFDruCmo63GOQt1kxAdVBmQ@mail.gmail.com> +Date: Tue, 10 Feb 2015 11:21:03 +0100 +Message-ID: <CAAt2M188whrv9VgV8UYBq+kcmgN9b6QQH7+wd7wQYNj8bd4Pcg@mail.gmail.com> +From: Natanael <natanael.l@gmail.com> +To: bitcoin-development@lists.sourceforge.net +Content-Type: multipart/alternative; boundary=089e0122e8b67ea84e050eb93ea0 +X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (natanael.l[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -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: 1YL7wL-0006mY-Tq +Subject: [Bitcoin-development] Standardizing automatic pre-negotiation of + transaction terms with BIP70? (Emulating Amazon one-click purchase at all + merchants) +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Tue, 10 Feb 2015 10:21:11 -0000 + +--089e0122e8b67ea84e050eb93ea0 +Content-Type: text/plain; charset=UTF-8 + +BIP70 is a protocol for getting a user's wallet client communicate with a +merchant's server in order to agree on details like where to send the +payment, how much to send, what the shipping address is, sending a receipt +back, and much more using various extensions that adds more functionality. + +There could even be advanced functionality for automatically negotiating +terms. One example could be selecting a multisignature arbitrator both +sides trust. Another could be to agree on the speed and type of delivery. +Many more types of decisions could be automatically agreed upon. + +But as it is now, it is designed to be initiated at the time of payment. If +you always want next-day delivery from online stores then you won't always +know if that's an option until you've filled the digital basket and gone +through checkout. If you only want to shop with an arbitrator involved same +thing applies. + +Everything that BIP70 enables happens at the last step only, as it is right +now. + +If there could be a BIP70 HTML tag on web shops that automatically +triggered your wallet as soon as you visit the page, it would be possible +for a browser extension that talks to your wallet to tell you right away if +the web shop you're currently looking at has terms you consider acceptable +or not (note: if your wallet client isn't installed on or linked to that +same machine, a visible Qr code would be an acceptable alternative which +you can scan in advance before you start shopping). This notification can +even be automatically updated as you add and remove things from your cart +and details like shipping options change. + +This would massively simplify the shipping experience and make every web +shop feel like Amazon. + +Of course this has privacy implications and increases exposure to potential +wallet exploits, but the wallet can ask you if you intend to shop or not at +each site before it even connects and send any information at all in order +to mitigate both of those problems. This way it should be reasonably safe. + +Another option would be to automatically connect but limit what data is +sent in order to remain privacy preserving, until the user agrees to send +private information. + +This second method would also open up for the merchant to other send +relevant information such as details about various certifications from +third parties, which can include a certification that shows they have been +been audited and approved by by entity X for purpose Y. If your wallet has +that entity whitelisted it will show you that certificate (for example +"Acme Audits have audited and approves of Merchant M's privacy policy and +data protection"). With a list of predefined types of certifications that +the wallet understand and accepts, it could (by choice of the user) require +a certificate to be present to even allow you to make a purchase (lack of +required certifications would result in automatic denial). No certificate = +your wallet never proceed to send private information. + +Thoughts? + +- Sent from my tablet + +--089e0122e8b67ea84e050eb93ea0 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<p dir=3D"ltr">BIP70 is a protocol for getting a user's wallet client c= +ommunicate with a merchant's server in order to agree on details like w= +here to send the payment, how much to send, what the shipping address is, s= +ending a receipt back, and much more using various extensions that adds mor= +e functionality.</p> +<p dir=3D"ltr">There could even be advanced functionality for automatically= + negotiating terms. One example could be selecting a multisignature arbitra= +tor both sides trust. Another could be to agree on the speed and type of de= +livery. Many more types of decisions could be automatically agreed upon. </= +p> +<p dir=3D"ltr">But as it is now, it is designed to be initiated at the time= + of payment. If you always want next-day delivery from online stores then y= +ou won't always know if that's an option until you've filled th= +e digital basket and gone through checkout. If you only want to shop with a= +n arbitrator involved same thing applies.</p> +<p dir=3D"ltr">Everything that BIP70 enables happens at the last step only,= + as it is right now. </p> +<p dir=3D"ltr">If there could be a BIP70 HTML tag on web shops that automat= +ically triggered your wallet as soon as you visit the page, it would be pos= +sible for a browser extension that talks to your wallet to tell you right a= +way if the web shop you're currently looking at has terms you consider = +acceptable or not (note: if your wallet client isn't installed on or li= +nked to that same machine, a visible Qr code would be an acceptable alterna= +tive which you can scan in advance before you start shopping). This notific= +ation can even be automatically updated as you add and remove things from y= +our cart and details like shipping options change. </p> +<p dir=3D"ltr">This would massively simplify the shipping experience and ma= +ke every web shop feel like Amazon.</p> +<p dir=3D"ltr">Of course this has privacy implications and increases exposu= +re to potential wallet exploits, but the wallet can ask you if you intend t= +o shop or not at each site before it even connects and send any information= + at all in order to mitigate both of those problems. This way it should be = +reasonably safe.</p> +<p dir=3D"ltr">Another option would be to automatically connect but limit w= +hat data is sent in order to remain privacy preserving, until the user agre= +es to send private information.</p> +<p dir=3D"ltr">This second method would also open up for the merchant to ot= +her send relevant information such as details about various certifications = +from third parties, which can include a certification that shows they have = +been been audited and approved by by entity X for purpose Y. If your wallet= + has that entity whitelisted it will show you that certificate (for example= + "Acme Audits have audited and approves of Merchant M's privacy po= +licy and data protection"). With a list of predefined types of certifi= +cations that the wallet understand and accepts, it could (by choice of the = +user) require a certificate to be present to even allow you to make a purch= +ase (lack of required certifications would result in automatic denial). No = +certificate =3D your wallet never proceed to send private information. </p> +<p dir=3D"ltr">Thoughts? </p> +<p dir=3D"ltr">- Sent from my tablet</p> + +--089e0122e8b67ea84e050eb93ea0-- + + |