This comes up every few months. I think the problem you are trying to solve
is already solved by SSL client certificates, and if you want to help make
them more widespread the programs you need to upgrade are web browsers and
not Bitcoin wallets. There are certainly bits of infrastructure you
On Fri, Apr 4, 2014 at 3:22 PM, Eric Larchevêque ela...@gmail.com wrote:
I see only benefits for the entire ecosystem, and if I'm working on such a
proposition it is because I really need this feature.
Why do you need it? Because you don't want to implement a login system?
Very, very few
On Fri, Apr 4, 2014 at 9:43 AM, Mike Hearn m...@plan99.net wrote:
These are the kinds of problems that crop up when you mix together two
different things: the act of paying, and the act of identifying yourself.
This is precisely why SINs use a different version byte from bitcoin
addresses.
Using a bitcoin address repeatedly is something we're trying to move away
from.
This is indeed a flaw of the proposed protocol. However it really depends
in the end of the usage : you could use an auth just once, to redeem a good
you paid, or multiple times if this makes a sense (mining pool app
What if I do a shared spend/CoinJoin type tx? Now anyone who took part in
the shared tx with me can get into my hotel room too?
Oh, if these seem too abstract, also consider bitbanks. In an ideal world
nobody would outsource running of their Bitcoin wallet, but sadly people
do, so then they
On Fri, Apr 4, 2014 at 6:51 AM, Nikita Schmidt
nik...@megiontechnologies.com wrote:
Fair enough. Although I would have chosen the field order (p) simply
because that's how all arithmetic already works in bitcoin. One field
for everybody. It's also very close to 2^256, although still smaller
The goal of writing a BIP seems to be to get lots of different wallet
authors to write lots of code for you - but I *am* a wallet author, and I
don't think that's the right way to get traction with a new scheme.
I started without a BIP and the feedback I got is that I should to a BIP.
We
Why do you need it? Because you don't want to implement a login system?
Very, very few websites are the sort of place where they'd want to
authenticate with only a Bitcoin address. If for no other reason than
they'd have no way to email you, and if you lost your wallet, you'd lose
all your
I'm cracking my head for many months with the idea of using TREZOR for web
auth purposes. Unfortunately I'm far from any usable solution yet.
My main comments to your BIP: Don't use bitcoin addresses directly and
don't encourage services to use this login for financial purposes. Mike
is right,
On Fri, Apr 4, 2014 at 4:56 PM, slush sl...@centrum.cz wrote:
I'm cracking my head for many months with the idea of using TREZOR for web
auth purposes. Unfortunately I'm far from any usable solution yet.
My main comments to your BIP: Don't use bitcoin addresses directly and
don't encourage
Hmmm, well TREZOR requires a web plugin. So if nobody installs plugins then
we have a problem :) But regardless, actually like I said, you don't need a
plugin. Browsers do it all already. With the keygen tag they even create
a private key and upload the public part to be signed for you, it's
On Fri, Apr 4, 2014 at 5:37 PM, Mike Hearn m...@plan99.net wrote:
Hmmm, well TREZOR requires a web plugin. So if nobody installs plugins
then we have a problem :) But regardless, actually like I said, you don't
need a plugin.
I see the plugin as a temporary solution and we'll eliminate the
Hmmm, well TREZOR requires a web plugin. So if nobody installs plugins
then we have a problem :) But regardless, actually like I said, you don't
need a plugin. Browsers do it all already. With the keygen tag they even
create a private key and upload the public part to be signed for you, it's
On Friday, 4 April 2014, at 5:51 pm, Nikita Schmidt wrote:
On 4 April 2014 01:42, Matt Whitlock b...@mattwhitlock.name wrote:
The fingerprint field, Hash16(K), is presently specified as a 16-bit field.
Rationale: There is no need to consume 4 bytes just to allow shares to be
grouped
On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote:
I still repeat my concern that any private key secret sharing scheme
really ought to be compatible with threshold ECDSA, otherwise we're
just going to have another redundant specification.
I have that concern too, but then how can we
On Friday, 4 April 2014, at 9:25 am, Gregory Maxwell wrote:
On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock b...@mattwhitlock.name wrote:
On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote:
I still repeat my concern that any private key secret sharing scheme
really ought to be
On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock b...@mattwhitlock.name wrote:
Are you proposing to switch from prime fields to a binary field? Because if
you're going to break up a secret into little pieces, you can't assume that
every piece of the secret will be strictly less than some 8-bit
On Friday, 4 April 2014, at 10:08 am, Gregory Maxwell wrote:
On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock b...@mattwhitlock.name wrote:
Are you proposing to switch from prime fields to a binary field? Because if
you're going to break up a secret into little pieces, you can't assume
that
On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock b...@mattwhitlock.name wrote:
Honestly, that sounds a lot more complicated than what I have now. I made my
current implementation because I just wanted something simple that would let
me divide a private key into shares for purposes of
On Friday, 4 April 2014, at 10:51 am, Gregory Maxwell wrote:
On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock b...@mattwhitlock.name wrote:
Honestly, that sounds a lot more complicated than what I have now. I made
my current implementation because I just wanted something simple that would
20 matches
Mail list logo
