This happened to one of the merchants at the Bitcoin 2013 conference in
San Jose. They sold some T-shirts and accepted zero-confirmation
transactions. The transactions depended on other unconfirmed transactions,
which never confirmed, so this merchant never got their money.
Beyond the fact
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
I'm soliciting feedback on an idea to will improve security, increase the
number of full nodes, and provide more avenues for bitcoin distribution.
The idea is still in its infancy, but I need constructive feedback before I
take this further, or decide to abandon the idea.
In particular, my ego is
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:
Working on a proposal for extensions based on bip44 conventions.
Most interesting is: Fully Deterministic GPG keys.
https://github.com/taelfrinn/bip44extention
Would welcome any comments or interest
--
Download BIRT
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
On Sun, Feb 22, 2015 at 6:29 PM, Eric Lombrozo elombr...@gmail.com wrote:
As for 0-conf security, there are instances where 0-conf transactions make a
lot of sense - i.e. paying for utilities, ISP, web hosting, or other such
services which could be immediately shut off upon detection of a
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
19 matches
Mail list logo
