On 6 November 2013 07:41, slush wrote:
> > But where are the private keys stored? Crypto in the browser with help,
> but although they will expose ECC via the NSS, I dont think bitcoin's
> particular curve will be supported, because it's not NIST approved. If the
> use case was presented though,
> But where are the private keys stored? Crypto in the browser with help,
but although they will expose ECC via the NSS, I dont think bitcoin's
particular curve will be supported, because it's not NIST approved. If the
use case was presented though, they may add it.
Trezor, my friend.
Slush
Sent
On 2 November 2013 22:14, Johnathan Corgan wrote:
> On 11/01/2013 10:01 PM, bitcoingr...@gmx.com wrote:
>
> > Server provides a token for the client to sign.
>
> Anyone else concerned about signing an arbitrary string? Could be a
> hash of $EVIL_DOCUMENT, no? I'd want to XOR the string with my
On 2 November 2013 22:57, slush wrote:
> Glad to see that there are more and more people wanting to replace
> passwords with digital signatures.
>
> Although such method has been already used on other websites like Eligius
> or bitcoin-otc, I dont think theres any standard way to doing so yet.
>
On Sat, Nov 02, 2013 at 02:14:22PM -0700, Johnathan Corgan wrote:
> On 11/01/2013 10:01 PM, bitcoingr...@gmx.com wrote:
>
> > Server provides a token for the client to sign.
>
> Anyone else concerned about signing an arbitrary string? Could be a
> hash of $EVIL_DOCUMENT, no? I'd want to XOR the
Required vs. strongly recommended is an important distinction. Satoshi
Dice reuses EC Keys for every single transaction. Exchanges will have the
same address you deposit in over and over, which gets reused. This is a
best practice argument rather than a protocol requirement.
On Sat, Nov 2, 201
On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote:
> I actually had a use case in my case where it was possible, and that was
> the check I used to get around it, just configured it so that I always
> generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
> It was ei
I actually had a use case in my case where it was possible, and that was
the check I used to get around it, just configured it so that I always
generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
It was either that or making sure I had no unspent outputs. The use case
of doin
On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello wrote:
> This was one of my concerns when implementing a scheme where you sign a
> refund transaction before the original transaction is broadcast. I
> originally tried to pass a hash and have the server sign it. However, I
> had no way to
This was one of my concerns when implementing a scheme where you sign a
refund transaction before the original transaction is broadcast. I
originally tried to pass a hash and have the server sign it. However, I
had no way to know that what I was signing wasn't a transaction that was
spending my c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Or SIGHASH of a transaction spending those coins or updating the SIN...
On 11/2/13 2:14 PM, Johnathan Corgan wrote:> On 11/01/2013 10:01 PM,
bitcoingr...@gmx.com wrote:
>
>> Server provides a token for the client to sign.
>
> Anyone else concerned a
Glad to see that there are more and more people wanting to replace
passwords with digital signatures.
Although such method has been already used on other websites like Eligius
or bitcoin-otc, I dont think theres any standard way to doing so yet.
Two comments to your proposal:
A) message-to-be-si
On 11/01/2013 10:01 PM, bitcoingr...@gmx.com wrote:
> Server provides a token for the client to sign.
Anyone else concerned about signing an arbitrary string? Could be a
hash of $EVIL_DOCUMENT, no? I'd want to XOR the string with my own
randomly generated nonce, sign that, then pass the nonce a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02.11.2013 19:08, Jeff Garzik wrote:
> On Sat, Nov 2, 2013 at 12:52 PM, Melvin Carvalho
> wrote:
>> Identity need not be a hard problem. In my view it is a solved
>> problem.
>
>
> Yes: https://en.bitcoin.it/wiki/Identity_protocol_v1
>
Well
On Sat, Nov 2, 2013 at 12:52 PM, Melvin Carvalho
wrote:
> Identity need not be a hard problem. In my view it is a solved problem.
Yes: https://en.bitcoin.it/wiki/Identity_protocol_v1
--
Android is increasing in popula
On 2 November 2013 17:26, Mike Hearn wrote:
> Guys, identity systems for the web are off-topic for this list. Other than
> the anonymous passports/SINs/fidelity bond ideas, Bitcoin doesn't have any
> relevance to it.
>
> On Sat, Nov 2, 2013 at 2:19 PM, Hannu Kotipalo wrote:
>
>> Maybe this is a b
Guys, identity systems for the web are off-topic for this list. Other than
the anonymous passports/SINs/fidelity bond ideas, Bitcoin doesn't have any
relevance to it.
On Sat, Nov 2, 2013 at 2:19 PM, Hannu Kotipalo wrote:
> Maybe this is a bit off-topic, but the *real* answer to the question
> "wh
> No, it wouldn't. You can log a user in using SSL and then redirect the
user back to an encrypted page
sorry, I meant unencrypted page of course
--
Android is increasing in popularity, but the open development platform th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02.11.2013 15:02, Mike Hearn wrote:
>
> http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/
>
>
Maybe this is a bit off-topic, but the *real* answer to the question
"why-is-nobody-using-ssl-client-certificates" is that it w
On 2 November 2013 14:02, Mike Hearn wrote:
> On Sat, Nov 2, 2013 at 6:01 AM, wrote:
>
>> In brief, the authentication work as follows:
>>
>>
>>
>> Server provides a token for the client to sign.
>>
>> client passes the signed message and the bitcoin address back to the
>> server.
>>
>> server v
On Sat, Nov 2, 2013 at 6:01 AM, wrote:
> In brief, the authentication work as follows:
>
>
>
> Server provides a token for the client to sign.
>
> client passes the signed message and the bitcoin address back to the
> server.
>
> server validates the message and honors the alias (optional) and bi
On Saturday, November 02, 2013 5:01:43 AM bitcoingr...@gmx.com wrote:
> In celebration of the 5 year anniversary of the Bitcoin whitepaper, we are
> delighted to introduce the Message Signing based authentication method. In
> brief, the authentication work as follows:
> Server provides a token for
22 matches
Mail list logo
