1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YL8rM-0005NF-RL
for bitcoin-development@lists.sourceforge.net;
Tue, 10 Feb 2015 11:20:04 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.181 as permitted sender)
client-ip=209.85.212.181; envelope-from=natanael.l@gmail.com;
helo=mail-wi0-f181.google.com;
Received: from mail-wi0-f181.google.com ([209.85.212.181])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YL8rL-00006b-3t
for bitcoin-development@lists.sourceforge.net;
Tue, 10 Feb 2015 11:20:04 +0000
Received: by mail-wi0-f181.google.com with SMTP id r20so7949818wiv.2
for <bitcoin-development@lists.sourceforge.net>;
Tue, 10 Feb 2015 03:19:57 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.90.37 with SMTP id bt5mr45063809wib.29.1423567196947;
Tue, 10 Feb 2015 03:19:56 -0800 (PST)
Received: by 10.194.92.208 with HTTP; Tue, 10 Feb 2015 03:19:56 -0800 (PST)
Received: by 10.194.92.208 with HTTP; Tue, 10 Feb 2015 03:19:56 -0800 (PST)
In-Reply-To: <CANEZrP2LhgFWWJYQGO+XbDX1o5=hwPtFbE+etEHoQo+3AfUSrA@mail.gmail.com>
References: <CAAt2M18H0K99bmD4H_FRSeE+O9nGFDruCmo63GOQt1kxAdVBmQ@mail.gmail.com>
<CAAt2M188whrv9VgV8UYBq+kcmgN9b6QQH7+wd7wQYNj8bd4Pcg@mail.gmail.com>
<CANEZrP2LhgFWWJYQGO+XbDX1o5=hwPtFbE+etEHoQo+3AfUSrA@mail.gmail.com>
Date: Tue, 10 Feb 2015 12:19:56 +0100
Message-ID: <CAAt2M19F2fWj7Ovw_aWvJ5+7osQG6WA=RuT3G+QYiYm-mnNnyg@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d043d6779168a42050eba1104
X-Spam-Score: -0.1 (/)
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
0.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YL8rL-00006b-3t
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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 11:20:04 -0000
--f46d043d6779168a42050eba1104
Content-Type: text/plain; charset=UTF-8
Den 10 feb 2015 12:08 skrev "Mike Hearn" <mike@plan99.net>:
>
> We can certainly imagine many BIP70 extensions, but for things like
auto-filling shipping addresses, is the wallet the best place to do it? My
browser already knows how to fill out this data in credit card forms, it
would make sense to reuse that for Bitcoin.
>
> It sounds like you want a kind of Star-Trek negotiation agent thing,
where your computer knows how to seek out the best deal because all the
metadata is standardised. Such a thing would be an interesting project, but
it's probably not best done in BIP70 given how it's deployed and used
today. Rather, I'd suggest looking at the various HTML5 data standards
which would allow merchants to advertise things like where they ship to in
a machine readable and crawlable form.
BIP70 doesn't have to be the place, but not needing to make sure the device
in question have that information stored already would be an improvement.
What protocol is used doesn't matter much, I just thought reusing BIP70
would simplify implementation.
HTML5 elements could definitely be supported, through adding a tag in the
HTML form that says "prompt the Bitcoin wallet about the following payment
details".
As one example, your browser could ask your hardware wallet over BLE for
this data. This way you barely have to trust the computer you're using at
all, as everything it does is confirmed on the hardware wallet before
payment (assuming it has a screen, which it should). Linking your hardware
wallet over BLE to new devices which you then use for browsing and shopping
could be trivial and yet allow secure auto-fill of this kind.
--f46d043d6779168a42050eba1104
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 10 feb 2015 12:08 skrev "Mike Hearn" <<a href=3D"mailto:mi=
ke@plan99.net">mike@plan99.net</a>>:<br>
><br>
> We can certainly imagine many BIP70 extensions, but for things like au=
to-filling shipping addresses, is the wallet the best place to do it? My br=
owser already knows how to fill out this data in credit card forms, it woul=
d make sense to reuse that for Bitcoin.<br>
><br>
> It sounds like you want a kind of Star-Trek negotiation agent thing, w=
here your computer knows how to seek out the best deal because all the meta=
data is standardised. Such a thing would be an interesting project, but it&=
#39;s probably not best done in BIP70 given how it's deployed and used =
today. Rather, I'd suggest looking at the various HTML5 data standards =
which would allow merchants to advertise things like where they ship to in =
a machine readable and crawlable form.</p>
<p dir=3D"ltr">BIP70 doesn't have to be the place, but not needing to m=
ake sure the device in question have that information stored already would =
be an improvement. What protocol is used doesn't matter much, I just th=
ought reusing BIP70 would simplify implementation. </p>
<p dir=3D"ltr">HTML5 elements could definitely be supported, through adding=
a tag in the HTML form that says "prompt the Bitcoin wallet about the=
following payment details". </p>
<p dir=3D"ltr">As one example, your browser could ask your hardware wallet =
over BLE for this data. This way you barely have to trust the computer you&=
#39;re using at all, as everything it does is confirmed on the hardware wal=
let before payment (assuming it has a screen, which it should). Linking you=
r hardware wallet over BLE to new devices which you then use for browsing a=
nd shopping could=C2=A0 be trivial and yet allow secure auto-fill of this k=
ind. </p>
--f46d043d6779168a42050eba1104--
|
