On 02/26/2015 04:30 AM, Andreas Schildbach wrote:
On 02/24/2015 11:41 AM, Mike Hearn wrote:
On 02/23/2015 04:10 PM, Eric Voskuil wrote:
Does this not also require the BT publication of the script for a P2SH
address?
You mean if the URI you're serving is like this?
Manually quoting a reply from Andreas that was sent privately while the
e-mail list was 2 days delayed delivering messages
On 02/25/2015 02:45 AM, Andreas Schildbach wrote:
Bear in mind that the bt: scheme is already in use by ~700.000
installations. If we change the protocol
On 02/23/2015 04:09 PM, Jan Vornberger wrote:
I'm still concerned that the fact, that Bluetooth is often disabled, is a
problem for the UX. And it's not just a one-time thing as with NFC,
which is - in my experience - also often disabled, but then people turn
it on and leave it on.
It's the
On 02/24/2015 11:41 AM, Mike Hearn wrote:
Does this not also require the BT publication of the script for a P2SH
address?
You mean if the URI you're serving is like this?
bitcoin:3aBcD?bt=
Yes it would. I guess then, the server would indicate both the script,
On 02/23/2015 09:53 PM, Andy Schroder wrote:
I was saying provide a public key via NFC (or a public key fingerprint
and then send the full public key over bluetooth). Instead of providing
a new public key on each tap, why can't the payee just stop accepting
connections from new parties on that
Does this not also require the BT publication of the script for a P2SH
address?
You mean if the URI you're serving is like this?
bitcoin:3aBcD?bt=
Yes it would. I guess then, the server would indicate both the script, and
the key within that script that it wanted to use. A
On 02/24/2015 11:49 AM, Andy Schroder wrote:
Hello,
I think were talking about a lot of the same things. There is one key
piece of information that I was not thinking about until you made it
clear. Why the payee needs to identify the payer. In my fuel pump
application, they really don't, so
Hello,
I think were talking about a lot of the same things. There is one key
piece of information that I was not thinking about until you made it
clear. Why the payee needs to identify the payer. In my fuel pump
application, they really don't, so I wasn't thinking closely about these
other
Andy Schroder
On 02/23/2015 10:09 AM, Jan Vornberger wrote:
Hey!
On Sun, Feb 22, 2015 at 05:37:16PM -0500, Andy Schroder wrote:
It's maybe not a bad idea for the wallet to try all payment_url
mechanisms in parallel. Should we add this as a recommendation to
wallets in TBIP75?
It doesn't
On Tue, Feb 24, 2015 at 01:14:43AM -0500, Andy Schroder wrote:
I've had similar issues where the NFC device has to be disconnected
and reconnected. I've got lots of error checking in my code on the
NFC device, which helps, but still has problems sometimes. I've
found if I limit how quickly a
We can change resource to Session ID if you want.
I think the URL scheme should be:
bitcoin:[address]?r=bt:macs=PublicKey
But when connecting to the mac, the client indicates the SessionID in
the header, and as you say, SessionID is derived in some way from PublicKey.
This is a slightly
The list appears dead, this is a test.
e
signature.asc
Description: OpenPGP digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with
On 02/24/2015 02:50 PM, Andy Schroder wrote:
We can change resource to Session ID if you want.
I think the URL scheme should be:
bitcoin:[address]?r=bt:macs=PublicKey
This is a question of proper URL semantics, as applied to the bt scheme.
From rfc3986 [Uniform Resource Identifier (URI):
DHKE will not improve the situation. Either we use a simple method to
transfer a session key or a complex method.
You're right that just sending the session key is simpler. I originally
suggested doing ECDHE to set up an encrypted channel for the following
reasons:
1. URIs are put in QR
I read from your answer that even if we use ECDHE, we can't use it for
every situation.
Which situations do you mean? I think it can be used in every situation.
It's the opposite way around - a fixed session key in the URI cannot be
used in every situation.
On 02/23/2015 01:18 PM, Mike Hearn wrote:
I read from your answer that even if we use ECDHE, we can't use it for
every situation.
Which situations do you mean? I think it can be used in every situation.
It's the opposite way around - a fixed session key in the URI cannot be
used in
On 02/23/2015 11:58 AM, Mike Hearn wrote:
You're right that just sending the session key is simpler. I
originally suggested doing ECDHE to set up an encrypted channel
for the following reasons: [...]
I read from your answer that even if we use ECDHE, we can't use it for
every situation. So in
Hey!
On Sun, Feb 22, 2015 at 05:37:16PM -0500, Andy Schroder wrote:
It's maybe not a bad idea for the wallet to try all payment_url
mechanisms in parallel. Should we add this as a recommendation to
wallets in TBIP75?
It doesn't need to be a recommendation I think, but maybe it would be
good
At the moment I'm also modifying BitPay's memo field to contain 'ack', as
Andreas' wallet otherwise reports a failure if I transmit the original via
Bluetooth. :-)
Huh?
--
Download BIRT iHub F-Type - The Free
But via Bluetooth it checks for 'ack' directly:
We need a BIP70 conformance suite really. There are so many deviations from
the spec out there already and it's brand new :(
--
Download BIRT iHub F-Type - The Free
On Mon, Feb 23, 2015 at 05:59:34PM +0100, Mike Hearn wrote:
At the moment I'm also modifying BitPay's memo field to contain 'ack', as
Andreas' wallet otherwise reports a failure if I transmit the original via
Bluetooth. :-)
Huh?
For HTTP it checks whether 'nack' is _not_ presented:
Mike,
Before addressing other issues I could use some clarification on your
intent.
In one statement you refer to derivation of a session key from a bitcoin
address (passed via NFC):
doing ECDH over secp256k1 to derive a session key means we can reuse
the address that was put in the URI
Den 23 feb 2015 08:38 skrev Andy Schroder i...@andyschroder.com:
I agree that NFC is the best we have as far as a trust anchor that you
are paying the right person. The thing I am worried about is the privacy
loss that could happen if there is someone passively monitoring the
connection. So, in
On 02/23/2015 01:49 AM, Andreas Schildbach wrote:
I think at this point I'd like to bring back my original suggestion of
using DHKE (Diffie-Hellman) or simlar. I know we'd still need to
transmit some secret that could be eavesdropped,
Hi Andreas,
DHKE will not improve the situation. Either
I think at this point I'd like to bring back my original suggestion of
using DHKE (Diffie-Hellman) or simlar. I know we'd still need to
transmit some secret that could be eavesdropped, but at least the
session could not be decrypted from recordings.
Anyway, establishing a mostly secure session is
On 02/23/2015 03:11 PM, Mike Hearn wrote:
I don't see how you propose to treat the bitcoin address as a
secp256k1 public key, or do you mean something else?
Sorry, I skipped a step. I shouldn't make assumptions about what's
obvious.
No problem, we don't all have the same context. I may have
Andy, adding to my previous post below:
On 02/23/2015 01:40 AM, Eric Voskuil wrote:
On 02/22/2015 11:36 PM, Andy Schroder wrote:
...
It's possible a really sophisticated modification could be done where
the attacker encrypts and decrypts the communication and then relays to
each party
I don't see how you propose to treat the bitcoin address as a secp256k1
public key, or do you mean something else?
Sorry, I skipped a step. I shouldn't make assumptions about what's obvious.
The server would provide the public key and the client would convert it to
address form then match
Hi everyone,
I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which
displays QR codes, but also provides payment requests via NFC. It can optionally
receive the sender's transaction via Bluetooth, so if the sender wallet
supports it, the sender can be completely offline.
On 02/22/2015 02:37 PM, Andy Schroder wrote:
I'd like to see some discussion too about securing the bluetooth
connection. Right now it is possible for an eavesdropper to monitor the
data transferred.
Yes, this should be a prerequisite issue to all others.
I'd personally like to see if
Hello Jan,
Regarding a few of your questions:
Andreas and I had a number of private discussions regarding the
payment_url parameter. I had suggested a additional_payment_urls
repeated parameter, but he didn't seem to like that idea and I
personally am indifferent, so that is why we decided
Hi Jan,
This is really nice work.
WRT the Schroder and Schildbach proposal, the generalization of the r
and payment_url parameters makes sense, with only the potential
backward compat issue on payment_url.
TBIP75 furthermore proposes to include an additional 'h' parameter
which would be a
One correction inline below.
e
On 02/22/2015 02:39 PM, Eric Voskuil wrote:
Hi Jan,
This is really nice work.
WRT the Schroder and Schildbach proposal, the generalization of the r
and payment_url parameters makes sense, with only the potential
backward compat issue on payment_url.
Andy Schroder
On 02/22/2015 06:06 PM, Eric Voskuil wrote:
On 02/22/2015 02:37 PM, Andy Schroder wrote:
I'd like to see some discussion too about securing the bluetooth
connection. Right now it is possible for an eavesdropper to monitor the
data transferred.
Yes, this should be a prerequisite
Andy Schroder
On 02/22/2015 05:48 PM, Eric Voskuil wrote:
One correction inline below.
e
On 02/22/2015 02:39 PM, Eric Voskuil wrote:
Hi Jan,
This is really nice work.
WRT the Schroder and Schildbach proposal, the generalization of the r
and payment_url parameters makes sense, with only
On 02/22/2015 11:37 PM, Andy Schroder wrote:
Andreas and I had a number of private discussions regarding the
payment_url parameter. I had suggested a additional_payment_urls
repeated parameter, but he didn't seem to like that idea and I
personally am indifferent, so that is why we decided to
On 02/23/2015 12:32 AM, Andy Schroder wrote:
I guess we need to decide whether we want to consider NFC communication
private or not. I don't know that I think it can be. An eavesdropper can
place a tiny snooping device near and read the communication. If it is
just passive, then the
On 02/22/2015 03:32 PM, Andy Schroder wrote:
On 02/22/2015 06:06 PM, Eric Voskuil wrote:
On 02/22/2015 02:37 PM, Andy Schroder wrote:
I'd like to see some discussion too about securing the bluetooth
connection. Right now it is possible for an eavesdropper to monitor the
data transferred.
Jan, this is great stuff! Thanks for sharing your experiences.
I think the 4k payments requests issue must be solvable somehow. I had
no trouble transmitting that amount via NFC, although yes a bit of delay
was noticable.
About payment_url: Protobuf allows changing optional to repeated and yes
On 02/22/2015 11:39 PM, Eric Voskuil wrote:
The MAC address (and resource name) should be encoded using base58. This
is shorter than base16, is often shorter than base64, better
standardized and does not require URI encoding, and is generally
available to implementers.
Of course this is just
On 02/22/2015 03:35 PM, Andy Schroder wrote:
On 02/22/2015 02:39 PM, Eric Voskuil wrote:
Hi Jan,
This is really nice work.
WRT the Schroder and Schildbach proposal, the generalization of the r
and payment_url parameters makes sense, with only the potential
backward compat issue on
However, I don't think we should base
bitcoin around what Apple wants us to do. They've already had their war
on bitcoin. They are going to do whatever they can to protect their NFC
based payment system. We need to make their platform the the less
desirable one if they are going to play the
42 matches
Mail list logo
