path: root/a8/7d8e5acbbd76c68941eb0892f2805a8df1c040

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1XgCPv-0001j5-VA
	for bitcoin-development@lists.sourceforge.net;
	Mon, 20 Oct 2014 12:50:32 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.178 as permitted sender)
	client-ip=209.85.214.178; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f178.google.com; 
Received: from mail-ob0-f178.google.com ([209.85.214.178])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XgCPu-0004Ak-3m
	for bitcoin-development@lists.sourceforge.net;
	Mon, 20 Oct 2014 12:50:31 +0000
Received: by mail-ob0-f178.google.com with SMTP id wn1so3684202obc.23
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 20 Oct 2014 05:50:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.183.70 with SMTP id h67mr21806475oif.19.1413809424587;
	Mon, 20 Oct 2014 05:50:24 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.108.196 with HTTP; Mon, 20 Oct 2014 05:50:24 -0700 (PDT)
In-Reply-To: <544174F8.1050208@AndySchroder.com>
References: <544174F8.1050208@AndySchroder.com>
Date: Mon, 20 Oct 2014 14:50:24 +0200
X-Google-Sender-Auth: 5NTWFdVW7W30UMozRs9OVAMPFqw
Message-ID: <CANEZrP33KH1F8GrTDnTP95G1MyxZ+DXWrC6QKBrj61HXv-eg2w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andy Schroder <info@andyschroder.com>
Content-Type: multipart/alternative; boundary=001a113ce0688863510505da280e
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: 1XgCPu-0004Ak-3m
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth
 Communication and bitcoin: URI Scheme Improvements
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: Mon, 20 Oct 2014 12:50:32 -0000

--001a113ce0688863510505da280e
Content-Type: text/plain; charset=UTF-8

Hey Andy,

Thanks for starting this discussion!

One thing this brings up is the never-resolved issue of whether BIPs should
document how we'd *like* things to work, or how things *actually do* work.
BIP32 is an example of the former - it was new technology and the spec was
finalised before any wallets actually implemented it. BIP 44 is an example
of the latter, it basically documents how myTREZOR works and as such there
was minimal or no scope for changes to it. Of course both kinds of document
are valuable.

Currently these specs document how Andreas' app already works. Whilst
preserving compatibility with existing Android apps is surely useful,
having a well designed protocol is also good. The current protocol has
several problems. I don't know which is more important right now and don't
have a strong opinion on that. My gut feeling is that these documents
should possibly be just wiki pages on Andreas' github. Then if the protocol
is brought to a point where it seems pretty good, maybe it can be BIPped at
that point. Alternatively, if developers of other wallet apps feel they'd
like a BIP right now even in the current state, that would be a very
important data point.

Re: the actual specs:

>
>    - There may seem to be some inconsistency in the connection header
>    messages
>
> IMHO we could live with that. Although Android apps are updatable, perfect
header format is probably not worth the inevitable hassle and transition
period that would result.

>
>    - The current method uses an unauthenticated bluetooth connection for
>    bluetooth 2.1
>
> This on the other hand is not excellent. This is actually my fault - the
first Bluetooth support in Bitcoin Wallet for Android was written by me in
a frantic Berlin hackathon over a weekend. We barely got it working at all
by the end, so doing encryption/auth was out of the question. Then I went
back to more important tasks and what got shipped was a cleaned
up/robustified version of that.

Re: hash. I'm not a fan of this approach. For one, in future there might
not even BE a uri involved, e.g. consider the Square style UX where the
merchant is broadcasting an endpoint via BLE and the phone just
automagically connects, sees a trusted merchant and pays. Super slick, we
definitely want it - but no URI. Then of course there's the usual QR code
size limitations.

Encrypting/authing the connection at the app layer does not have to be
difficult. What we really need/want, is a simple lightweight library that
does an ECDH key agreement using secp256k1, and then does AES+HMAC on
framed messages. Such a protocol would be useful not only for this use
case, but perhaps for encrypting/authing the p2p protocol in future as well.

Once the encrypted connection is set up above the Bluetooth layer, the
payment protocol request can then be signed either with a regular Bitcoin
key that was in the Bitcoin URI as the payment address (when a URI is
available), thus linking the request to the URI without adding any
additional data by doubling up the backwards compatibility support. Or if
there's no URI, then of course, the payment request must be PKI signed and
the signed PaymentDetails structure can contain a copy of the public key
that was used to set up the connection, thus binding the connection to a
PKI identity and ensuring you're not talking to a MITM.

I suspect that this is not anywhere near as hard to implement as one might
think. ECDH is not a complex protocol. You certainly don't need full blown
HTTPS involved.

>
>    - There is no acknowledgement failure message possible in the payment
>    protocol, only an acknowledgement message or lack of acknowledgement
>    message. This issue seems to be a concern and as a result, the memo field
>    is used to send an "ack" or "nack" in Schildbach's wallet. Can we add a
>    boolean status field to the payment acknowledgement message?
>
> Ugh. I did want a way to indicate failure when we designed BIP70, but I
can't remember why one wasn't included in the final spec. I think we
decided the containing protocol could do this instead (normally HTTP).

Abusing the memo field is definitely the wrong thing to do! Rather the
Bluetooth specific encapsulation protocol should have a notion of failure.

>
>    - I'd personally like a new optional boolean field added to the
>    "PaymentDetails" portion of the "PaymentRequest" to allow for the payer's
>    wallet to match the "Output" optional "amount" fields as a total amount of
>    all Outputs, rather than requiring the amount for each output to be matched
>    exactly.
>
> Extending BIP70 with more negotiable privacy features is a different
effort, let's not discuss that as part of Bluetooth support.

Besides, no wallet uses even the existing support for merge avoidance in
BIP70. In fact Andreas' wallet is one of the blocking factors here because
it violates the specs by requiring the BIP70 request to have only a single
output that matches the address specified in the URI. All because he
doesn't trust HTTPS :(

I don't think adding even more privacy stuff to BIP70 makes any sense until
we have implementations that actually exploit the existing support. And to
get there, we must fix Andreas' wallet so it doesn't violate the specs
anymore. Sorry Andreas. I know we argue about this all the time, but it's
really a big problem that your app doesn't obey the specs. It makes
everyone reluctant to use new BIP70 features, because they feel a need to
test with every possible wallet app in case one of them has simply decided
to do their own thing and become deliberately incompatible. And then why
bother, there are more important things to do.

>
>    - Amount of data stored in QR codes may be getting large when a
>    backwards compatible URL is used (for wallets that don't support the
>    payment protocol) and can be difficult to scan with outdoor screens that
>    have an extra weather resistant pane when in direct sunlight.
>
> MAC addresses could be encoded more efficiently, of course, but it seems
unlikely that address-less URIs can be relied upon any time soon - and
besides if the URI needs to bind to an authenticated channel because PKI
signing is not in use, then it makes sense to use that part of the URI to
do so.

>
>    - The number of offline transactions of a wallet is limited to the
>    known unspent outputs when they go offline. Long term, I'd like to see
>    wallet devices that can use systems such as Kryptoradio's DVB-T based
>    broadcast (but this will need yet another radio!).
>
> Given that all interesting mobile devices have sophisticated internet
access radios of various forms, I doubt it's worth putting much effort in
here. Bluetooth for submitting payments makes sense some of the time,
partly for performance and partly because it's more decentralised than
looping in an intermediary HTTPS server to temporarily host a BIP70 request
file. I don't think we should try and invent an entirely new "block chain
internet" though. At any rate, it's a separate effort.

>
>    - The additional payment_url approach is a bit sloppy of a solution in
>    the PaymentDetails portion of the PaymentRequest.
>
> This is only an issue because of the way you define the hashing mechanism.
If you reuse the backwards compatibility address, then the payment_url can
of course be customised based on whatever transport mechanism the request
was fetched over. There is no longer any need to have the payment request
be created (and presumably stored) the moment the QR code is generated.
Besides, that approach has all kinds of messy implementation problems. You
don't know the QR code will *ever* be scanned, but you must have the exact
payment request at the time the QR code is generated. Payment requests
expire, so you have to define some kind of timeout at which point the QR
code itself becomes invalid. Urgh.

Much better to have the PaymentRequest formatted and signed on demand, once
the URI is being resolved. But that means you have to abandon the h=
mechanism.

--001a113ce0688863510505da280e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey Andy,<div><br></div><div>Thanks for starting this disc=
ussion!</div><div><br></div><div>One thing this brings up is the never-reso=
lved issue of whether BIPs should document how we&#39;d <i>like</i>=C2=A0th=
ings to work, or how things <i>actually do</i>=C2=A0work. BIP32 is an examp=
le of the former - it was new technology and the spec was finalised before =
any wallets actually implemented it. BIP 44 is an example of the latter, it=
 basically documents how myTREZOR works and as such there was minimal or no=
 scope for changes to it. Of course both kinds of document are valuable.</d=
iv><div><br></div><div>Currently these specs document how Andreas&#39; app =
already works. Whilst preserving compatibility with existing Android apps i=
s surely useful, having a well designed protocol is also good. The current =
protocol has several problems. I don&#39;t know which is more important rig=
ht now and don&#39;t have a strong opinion on that. My gut feeling is that =
these documents should possibly be just wiki pages on Andreas&#39; github. =
Then if the protocol is brought to a point where it seems pretty good, mayb=
e it can be BIPped at that point. Alternatively, if developers of other wal=
let apps feel they&#39;d like a BIP right now even in the current state, th=
at would be a very important data point.</div><div><br></div><div>Re: the a=
ctual specs:</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><ul><=
li>There may seem to be some inconsistency in the connection
        header messages=C2=A0</li></ul></div></blockquote><div>IMHO we coul=
d live with that. Although Android apps are updatable, perfect header forma=
t is probably not worth the inevitable hassle and transition period that wo=
uld result.</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" te=
xt=3D"#000000"><ul>
      <li>The current method uses an unauthenticated bluetooth
        connection for bluetooth 2.1</li></ul></div></blockquote><div>This =
on the other hand is not excellent. This is actually my fault - the first B=
luetooth support in Bitcoin Wallet for Android was written by me in a frant=
ic Berlin hackathon over a weekend. We barely got it working at all by the =
end, so doing encryption/auth was out of the question. Then I went back to =
more important tasks and what got shipped was a cleaned up/robustified vers=
ion of that.</div><div><br></div><div>Re: hash. I&#39;m not a fan of this a=
pproach. For one, in future there might not even BE a uri involved, e.g. co=
nsider the Square style UX where the merchant is broadcasting an endpoint v=
ia BLE and the phone just automagically connects, sees a trusted merchant a=
nd pays. Super slick, we definitely want it - but no URI. Then of course th=
ere&#39;s the usual QR code size limitations.</div><div><br></div><div>Encr=
ypting/authing the connection at the app layer does not have to be difficul=
t. What we really need/want, is a simple lightweight library that does an E=
CDH key agreement using secp256k1, and then does AES+HMAC on framed message=
s. Such a protocol would be useful not only for this use case, but perhaps =
for encrypting/authing the p2p protocol in future as well.</div><div><br></=
div><div>Once the encrypted connection is set up above the Bluetooth layer,=
 the payment protocol request can then be signed either with a regular Bitc=
oin key that was in the Bitcoin URI as the payment address (when a URI is a=
vailable), thus linking the request to the URI without adding any additiona=
l data by doubling up the backwards compatibility support. Or if there&#39;=
s no URI, then of course, the payment request must be PKI signed and the si=
gned PaymentDetails structure can contain a copy of the public key that was=
 used to set up the connection, thus binding the connection to a PKI identi=
ty and ensuring you&#39;re not talking to a MITM.</div><div><br></div><div>=
I suspect that this is not anywhere near as hard to implement as one might =
think. ECDH is not a complex protocol. You certainly don&#39;t need full bl=
own HTTPS involved.</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FF=
FFFF" text=3D"#000000"><ul>
      <li>There is no acknowledgement failure message possible in the
        payment protocol, only an acknowledgement message or lack of
        acknowledgement message. This issue seems to be a concern and as
        a result, the memo field is used to send an &quot;ack&quot; or &quo=
t;nack&quot; in
        Schildbach&#39;s wallet. Can we add a boolean status field to the
        payment acknowledgement message?<br></li></ul></div></blockquote><d=
iv>Ugh. I did want a way to indicate failure when we designed BIP70, but I =
can&#39;t remember why one wasn&#39;t included in the final spec. I think w=
e decided the containing protocol could do this instead (normally HTTP).</d=
iv><div><br></div><div>Abusing the memo field is definitely the wrong thing=
 to do! Rather the Bluetooth specific encapsulation protocol should have a =
notion of failure.</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFF=
FFF" text=3D"#000000"><ul><li>I&#39;d personally like a new optional boolea=
n field added to the
        &quot;PaymentDetails&quot; portion of the &quot;PaymentRequest&quot=
;





          to allow for the payer&#39;s wallet to match the &quot;Output&quo=
t; optional
          &quot;amount&quot; fields as a total amount of all Outputs, rathe=
r than
          requiring the amount for each output to be matched exactly.</li><=
/ul></div></blockquote><div>Extending BIP70 with more negotiable privacy fe=
atures is a different effort, let&#39;s not discuss that as part of Bluetoo=
th support.</div><div><br></div><div>Besides, no wallet uses even the exist=
ing support for merge avoidance in BIP70. In fact Andreas&#39; wallet is on=
e of the blocking factors here because it violates the specs by requiring t=
he BIP70 request to have only a single output that matches the address spec=
ified in the URI. All because he doesn&#39;t trust HTTPS :(=C2=A0</div><div=
><br></div><div>I don&#39;t think adding even more privacy stuff to BIP70 m=
akes any sense until we have implementations that actually exploit the exis=
ting support. And to get there, we must fix Andreas&#39; wallet so it doesn=
&#39;t violate the specs anymore. Sorry Andreas. I know we argue about this=
 all the time, but it&#39;s really a big problem that your app doesn&#39;t =
obey the specs. It makes everyone reluctant to use new BIP70 features, beca=
use they feel a need to test with every possible wallet app in case one of =
them has simply decided to do their own thing and become deliberately incom=
patible. And then why bother, there are more important things to do.=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#00000=
0"><ul><li>Amount of data stored in QR codes may be
          getting large when a backwards compatible URL is used (for
          wallets that don&#39;t support the payment protocol) and can be
          difficult to scan with outdoor screens that have an extra
          weather resistant pane when in direct sunlight.<br></li></ul></di=
v></blockquote><div>MAC addresses could be encoded more efficiently, of cou=
rse, but it seems unlikely that address-less URIs can be relied upon any ti=
me soon - and besides if the URI needs to bind to an authenticated channel =
because PKI signing is not in use, then it makes sense to use that part of =
the URI to do so.</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFF=
FF" text=3D"#000000"><ul>
      <li><span>The number of offline transactions of a
          wallet is limited to the known unspent outputs when they go
          offline. </span>Long term, I&#39;d like to see wallet devices
        that can use systems such as Kryptoradio&#39;s DVB-T based broadcas=
t
        (but this will need yet another radio!).</li></ul></div></blockquot=
e><div>Given that all interesting mobile devices have sophisticated interne=
t access radios of various forms, I doubt it&#39;s worth putting much effor=
t in here. Bluetooth for submitting payments makes sense some of the time, =
partly for performance and partly because it&#39;s more decentralised than =
looping in an intermediary HTTPS server to temporarily host a BIP70 request=
 file. I don&#39;t think we should try and invent an entirely new &quot;blo=
ck chain internet&quot; though. At any rate, it&#39;s a separate effort.</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"=
><ul><li>The additional payment_url approach is a bit sloppy of a
        solution in the PaymentDetails portion of the PaymentRequest. </li>=
</ul></div></blockquote><div>This is only an issue because of the way you d=
efine the hashing mechanism. If you reuse the backwards compatibility addre=
ss, then the payment_url can of course be customised based on whatever tran=
sport mechanism the request was fetched over. There is no longer any need t=
o have the payment request be created (and presumably stored) the moment th=
e QR code is generated. Besides, that approach has all kinds of messy imple=
mentation problems. You don&#39;t know the QR code will <i>ever</i>=C2=A0be=
 scanned, but you must have the exact payment request at the time the QR co=
de is generated. Payment requests expire, so you have to define some kind o=
f timeout at which point the QR code itself becomes invalid. Urgh.</div><di=
v><br></div><div>Much better to have the PaymentRequest formatted and signe=
d on demand, once the URI is being resolved. But that means you have to aba=
ndon the h=3D mechanism.</div></div></div></div>

--001a113ce0688863510505da280e--