Ok, agreed. I will submit a pull request to BIP72 then.
Not sure about escaping though. It is indeed not critical for bitcoin URIs,
but still it is a part of RFC, don't think we should go against it.
Andreas, we will implement this on our side, with bluetooth on r= and web
address on r1=.
However it's not ideal at the moment. Basically the main problem is that
in the BIP72 there is no way to provide a fallback alternative URI for
payment request fetch if client wallet supports BIP70 but doesn't not
support fetching over bluetooth or bluetooth connection fails for any
reason.
On 07/01/2014 10:18 AM, Mike Hearn wrote:
However it's not ideal at the moment. Basically the main problem is
that in the BIP72 there is no way to provide a fallback alternative
URI for payment request fetch if client wallet supports BIP70 but
doesn't not support fetching over
I think it makes more sense to not add a duplicate parameter. Current
implementations will break if multiple r parameters are used (either reject the
URI completely, or do something undefined). If a new parameter is used, then
the current implementations will just ignore it if they don’t
In my mind it's not like the client's phone is going all directions at the
same time. There should be a priority method and fallback method(s). And I
see p2p radio as priority, and web as fallback, and BIP21 in the end as
always-working-default.
So I'm keeping support for it all while want to
Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
advocate for a simple array parameter name, like rs= (plural of r).
Length really does matter for QR codes.
I'm fine with either multiple r= params or exactly one r= plus zero to
many r[]= params. Although I think it is a
Multiple parameters is currently undefined as far as I can tell. Should the
client take the first, last, or ignore it completely if there are multiple of
any parameter? I think that’s the point of the parameter pollution discussion,
which will define it one way or the other.
I’m only
Ok, one more idea:
r= is used for the first URL, and we *think* of it as r0=
additional URLs are appended as
r1=
r2=
and so on. This would also define an ordering in case we need it.
On 07/01/2014 05:07 PM, Michael Wozniak wrote:
Multiple parameters is currently undefined as far as I can tell.
Hmm, r1, r2 etc is actually interesting. It takes less chars then array
(yes, array brackets have to be escaped) and provides unlimited number of
options, uniformed approach and priority definition. I'd say that is the
way to go. Any objections?
On 1 Jul 2014 16:39, Andreas Schildbach
Nope, r1/r2 sounds good to me. BTW we should update the spec to reflect
that escaping is largely unnecessary in many cases.
--
Open source business process management suite built on Java and Eclipse
Turn processes into
It took some time but we have finally implemented bluetooth integration
offered by Andreas in our bitcoin payment terminals.
However it's not ideal at the moment. Basically the main problem is that
in the BIP72 there is no way to provide a fallback alternative URI for
payment request fetch if
But these cases are the norm, rather than the exception.
Well, you're lucky, you live in Berlin. Most of the payments I make with
Bitcoin are online, to websites. So this will differ between people.
I wonder how critical it is. Let's say you are paying for a meal. In your
head the place
Companies can have a Cert with their name via CAcert. It requires some work
though to get assured as an organisation.
Did you already think about what CA is to be trusted or do users need to do
that. The least good decision in my POV would be to accept OS/browser built in
CAs only.
Am
On Fri, Mar 21, 2014 at 12:02:44AM +0100, Mike Hearn wrote:
It's not unusual, in a face-to-face transaction at a bricks-and-mortar
establishment, that you know neither the legal name of the entity
running the establishment
I'd hope that people can get certs for their actual business
Yeah, for those cases we'd need to think of something else. That gets into
the realm of creating our own infrastructure though ...
--
___
Bitcoin-development mailing list
But these cases are the norm, rather than the exception. Of all these
places I spend my money at during the day I hardly ever know their
official name. I'm thinking in terms of bakery, indian restaurant or
snack vending machine.
In Germany usually businesses are named like the people that run it.
Let's not pull out silly examples. Of course you can find locations
that lack Internet.
Those locations are completely unsuitable to bitcoin transactions,
since the receiver cannot verify double-spending or anything else
about the transaction.
On Fri, Mar 21, 2014 at 9:59 AM, Alex Kotenko
Those locations are completely unsuitable to bitcoin transactions,
since the receiver cannot verify double-spending or anything else
about the transaction.
The usual issue is that they lack internet *for some customers*. The place
may well have private wifi or hardwired connections that
Jeff, there are *plenty* of places that lack local Internet access for
one or both participants.
Obviously making the case where both participants lack access to the
bitcoin network is difficult to secure, but not impossible (e.g. use a
telephany-based system to connect to a centralized
One participant, yes. Two participants lacking net would require a
serious revisit of BIP 70's security assumptions and some design, at a
minimum.
On Sat, Mar 22, 2014 at 12:55 PM, Mark Friedenbach m...@monetize.io wrote:
Jeff, there are *plenty* of places that lack local Internet access for
I think it's mostly a UI issue. The recipient needs to understand that what
he received is nothing more than an IOU that can be revoked at any time. If
the UI makes it clear and the user trusts the sender, no problem. BIP70
would work as before.
On Sat, Mar 22, 2014 at 6:24 PM, Jeff Garzik
I know that general approach to interaction design in Bitcoin assumes
minimal to no difference between payer and payee, and generally I agree
with this approach.
However, for the sake of my PoS development this assumption is wrong by
default, as PoS is a specialized hardware, and one who cared to
On 03/20/2014 05:14 PM, Alex Kotenko wrote:
Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing
URI's patterns. BT is strictly point-to-point connection, so BT MAC
should be considered as server address, and payment request ID can be
considered as request path. Probably
On 03/20/2014 01:12 PM, Adam Back wrote:
Whats a sensible limit on practical/convenient QR code size?
Technically 3 KB. In my experience codes above 1.5 KB become impossible
to scan (ZXing scanner, 3 years ago). You will want to stay below 500
bytes for convenient scanning. That said, I'm
On 03/20/2014 06:31 PM, Jeff Garzik wrote:
Afaik, BIP73 needs an external server (the web server).
Yes. Internet connectivity is not a rarity these days. Near-field
web servers also work fine.
Unfortunately it still is. At least here in Germany.
+1
I couldn't do a better job at describing my motivation behind trying to
stuff payment requests into QR codes.
On 03/20/2014 10:52 PM, Roy Badami wrote:
On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote:
Yes, this overlaps somewhat with the PKI signing in BIP70, but not
entirely
Maybe its time to explore raw ECDSA signed message based certs.
btw I dont think its quite 4kB. eg bitpay's looks to be about 1.5kB in der
format. And they contain a 2048-bit RSA server key, and 2048-bit RSA
signatures (256byte each right there = 512bytes). And even 2048 is weaker
than 256-bit
On Fri, Mar 21, 2014 at 11:59 AM, Adam Back a...@cypherspace.org wrote:
Maybe its time to explore raw ECDSA signed message based certs.
If you want to create and run a new CA, by all means. But I bet you don't.
So we're stuck with the current system for now.
btw I dont think its quite 4kB.
Oh, one other reason I found - apparently RIM, at least in the past, has
been telling CA's that they need to pay mad bux for the Certicom ECC
patents. So that's another reason why most certs are still using RSA.
On Fri, Mar 21, 2014 at 12:08 PM, Mike Hearn m...@plan99.net wrote:
On Fri, Mar
According to Bernstein it's patent FUD (expired, ancient and solid prior
art).
http://lists.randombit.net/pipermail/cryptography/2013-August/005126.html
Adam
On Fri, Mar 21, 2014 at 12:33:57PM +0100, Mike Hearn wrote:
Oh, one other reason I found - apparently RIM, at least in the past,
Maybe so, but given the relatively minor advantages of ECC certs I can see
why a CA might not want to take any risks. They are sitting ducks for
patent trolls.
I think ECC will still happen, though we end up back into NSA fear
territory thanks to the stupid way secp256r1 was defined. *Hopefully*
2014-03-21 9:47 GMT+00:00 Andreas Schildbach andr...@schildbach.de:
On 03/20/2014 05:14 PM, Alex Kotenko wrote:
Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing
URI's patterns. BT is strictly point-to-point connection, so BT MAC
should be considered as server
SPDY requires SSL and is even more complex than HTTP.
Really, the current protocol we've got (length prefixed protobufs) is just
fine except for the lack of encryption/authentication. For that you need to
do ECDH to establish a shared AES session key, and MAC each packet. Like I
said, it's not
2014-03-21 14:51 GMT+00:00 Andreas Schildbach andr...@schildbach.de:
Quoting from RFC 3986, Section 3.4. Query: The characters slash (/)
and question mark (?) may represent data within the query component.
Ok.
So BIP72 with a BT URI in the 'r' parameter?
Yes.
On 03/20/2014 03:22 AM, Alex Kotenko wrote:
Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
need to still be able to use it for backwards compatibility. But at the
same time I want to be able to support BIP70. And also I want to avoid
using external servers, the
Very, very limited. The more data you stuff in them, the less reliable and
slower scanning becomes. A URL is about the limit of what's practically
achievable. Even with that, BitPay have been complaining about the
increased character length from adding the https url to download the
payment request
2014-03-20 8:08 GMT+00:00 Andreas Schildbach andr...@schildbach.de:
On 03/20/2014 03:22 AM, Alex Kotenko wrote:
Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
need to still be able to use it for backwards compatibility. But at the
same time I want to be able to
On Thu, Mar 20, 2014 at 8:12 AM, Adam Back a...@cypherspace.org wrote:
Whats a sensible limit on practical/convenient QR code size?
Extremely limited. Preferably under 100 bytes. You will see
increasingly poor operating in varying light conditions, such as
paying via QR code on a printed
2014-03-20 17:31 GMT+00:00 Jeff Garzik jgar...@bitpay.com:
On Thu, Mar 20, 2014 at 8:12 AM, Adam Back a...@cypherspace.org wrote:
Whats a sensible limit on practical/convenient QR code size?
Extremely limited. Preferably under 100 bytes. You will see
increasingly poor operating in varying
It really depends on the physical, real world size of the QR code.
If you have a big screen, and security permits displaying a larger QR
code, you can afford more bytes. If you are displaying a tiny postage
stamp 1-2cm in size, the practical byte limit is very low.
Ideally, you test your QR
Hmm, is there any other way to do it? Can we provide a signed payment
request and verify the sign on receiving side and this way protect from
bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't
a very well developed area, and my own skills are not enough to quickly
implement
With Java, in theory, you can use SSLSocketFactory.createSocket(btsocket,
address, 1234, true) to wrap a bluetooth socket in SSL. However I have not
tried it.
For now, just prototype and build your product without the security. We can
find someone to experiment with this, if you don't want to .
We'll see how it will go, maybe I will get to implement this somewhere soon.
Yes, I'm thinking exactly about radio MitM attacks possible with bluetooth.
I'll also look into using PKI inside the PoS for the merchant. It would be
great user experience if we would be able to provide a signed payment
On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote:
Yes, this overlaps somewhat with the PKI signing in BIP70, but not
entirely - you might want to serve unsigned payment requests, but
still have confidentiality and authenticity for a local face to face
transaction. The signing and
Hi Andreas
I'm implementing support for BIP70 in my POS at the moment, and I've just
realized that with options you're proposing usecase I'm looking for is not
covered.
Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
need to still be able to use it for backwards
Take a look at BIP 73:
https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki
On Wed, Mar 19, 2014 at 10:22 PM, Alex Kotenko alexy...@gmail.com wrote:
Hi Andreas
I'm implementing support for BIP70 in my POS at the moment, and I've just
realized that with options you're proposing
I've written up a document about all the different methods on how the
payment protocol (both the old one and BIP70) is used in Bitcoin Wallet.
It only provides an overview -- I plan to go into details with separate
(BIP?) documents where needed.
I have refreshed the Bitcoin Wallet preview version with beta version
3.32. It now implements BIP72 aka URI extension for payment protocol.
There is one important deviation from the standard though: Bitcoin URI
address and amount fields need to correspond to the data from the
payment request. The
Just a small update. I merged the code to my bitcoinj-0.11 branch and
put up binary .apk files for experimentation. Just make sure to tick
BIP70 for tap-to-pay/scan-to-pay in the labs settings.
Source:
https://github.com/schildbach/bitcoin-wallet/commits/bitcoinj-0.11
Binaries:
Although it should be noted that these binaries don't yet do URI support so
you can't scan a bitcoin URI with r= in it and see the verified merchant
name, etc. I think Andreas plans to do the UI for that in the next update.
On Thu, Jan 30, 2014 at 11:46 AM, Andreas Schildbach
But the face-to-face case isn't intrinsically dependent on SSL security, and
it's nice not to introduce that attack vector...
If the only concern is to make scan-to-pay work without reliance on
SSL's PKI, it might be better to specify the payment protocol url
*and* the public key used for
Thanks Andreas, that's really interesting work. Comments below.
On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach
andr...@schildbach.dewrote:
Because I could not find any standard for Bluetooth URLs, I made
up my own: bt:112233445566 means MAC address 11:22:33:44:55:66.
I would like to
On Jan 27, 2014, at 9:39 AM, Andreas Schildbach andr...@schildbach.de wrote:
On 01/27/2014 06:11 PM, Jeremy Spilman wrote:
SCAN TO PAY
For scan-to-pay, the current landscape looks different. I assume at
least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
into a QR-code.
On Mon, Jan 27, 2014 at 7:18 PM, Andreas Schildbach
andr...@schildbach.dewrote:
I'm not saying I'm against signed payment requests, but unfortunately
they are just too big for QR-codes. Then again, QR-codes *can* take up
to 2 KB. How big would a very basic trust chain plus signature be?
As I
On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
andr...@schildbach.de wrote:
SCAN TO PAY
For scan-to-pay, the current landscape looks different. I assume at
least 50% of Bitcoin transactions are initiated by a BIP21
55 matches
Mail list logo
