Den 23 feb 2015 08:38 skrev "Andy Schroder" :
>
> 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 response to some o
On 02/22/2015 11:36 PM, Andy Schroder wrote:
> 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.
We have the same obj
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 i
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
>
> 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 Q
>
> 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
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
>
> 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
> use
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 Ent
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
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_ p
>
> 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 Ente
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 iHub
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 alre
>
> 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
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
On Sun, Feb 22, 2015 at 6:29 PM, Eric Lombrozo 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
> double-spend.
Indee
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 (
20 matches
Mail list logo