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 (
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
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
>
> 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
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
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
>
> 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
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
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
>
> 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
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
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
>
> 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 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
>
> 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
>
> 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
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 i
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
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
20 matches
Mail list logo