On Sat, Nov 02, 2013 at 10:44:58AM +0100, Thomas Voegtlin wrote:
>
> >To be specific, we (in cooperation with / inspired by Timo Hanke)
> >developed method how to prove that the seed generated by Trezor
> >has been created using combination of computer-provided entropy
> >and device-provided entro
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
Le 31/10/2013 12:18, slush a écrit :
> Oh, I forgot to one practical aspect; the way how the mnemonic is
> "mined" in Thomas proposal prevents usage in embedded devices, because
> difficulty of generating proper mnemonic is simply too high for
> embedded microcontrollers. Maybe this can be solv
> To be specific, we (in cooperation with / inspired by Timo Hanke)
> developed method how to prove that the seed generated by Trezor has
> been created using combination of computer-provided entropy and
> device-provided entropy, without leaking full private information to
> other computer, j
20 matches
Mail list logo
