On Fri, Apr 4, 2014 at 5:41 AM, kjj wrote:
> Matt Whitlock wrote:
> > The creation date in your BIP header has the wrong format. It should be
> 01-04-2014, per BIP 1.
> >
> At first, I thought this was a second April Fool's joke, but then I
> looked and saw that all of the BIPs really do use this
Hello,
I've written a draft BIP description of an authentication protocol based on
Bitcoin public address.
By authentication we mean to prove to a service/application that we control
a specific Bitcoin address by signing a challenge, and that all related
data and settings may securely be linked t
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 could
On Fri, Apr 4, 2014 at 3:01 AM, Wladimir wrote:
> Personally I'd prefer to standardize on ISO 8601 (-MM-DD) dates as well.
+1 for all-numeric, easily computer parse-able without a lookup table,
and naturally sorts correctly in a lexicographic sort.
English (or any language) should never be i
What I'm trying to achieve, is to have a very simple way of authenticating
yourself with one Bitcoin address from your wallet.
For most of the people using Bitcoin, their wallet is on their phone.
The UX is clear and simple :
1. click on "connect with Bitcoin" (the audience is normal people)
2. fl
Using a bitcoin address repeatedly is something we're trying to move away
from.
And using a bitcoin address as a persistent identity key feels like the
wrong direction to me.
Better to use something like client certificates, the FIDO alliance's
(new!) specs:
http://fidoalliance.org/specificatio
On Fri, Apr 4, 2014 at 3:22 PM, Eric Larchevêque 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 websites are the s
On Fri, Apr 4, 2014 at 9:43 AM, Mike Hearn 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. There should neve
> 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
On 4 April 2014 01:42, Matt Whitlock 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 together. And if someone has more than 100 different secrets, they
> probably have a go
>
> 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 the
On Fri, Apr 4, 2014 at 6:51 AM, Nikita Schmidt
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
> than your maximum prime.
>
> 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
>
> My view on this is mainly about the UX and the fact everyone in
> Bitcoinland has a wallet.
>
Well, yes, but we also have browsers too :)
I don't want to suggest the problem is unimportant - I'd love it if the
world could move beyond passwords. But I have many scars from my time in
the Google
On Fri, Apr 4, 2014 at 4:51 PM, Mike Hearn wrote:
> My view on this is mainly about the UX and the fact everyone in
>> Bitcoinland has a wallet.
>>
>
> Well, yes, but we also have browsers too :)
>
>
Yes, but no one will ever install a plug in.
And all will update their wallets with the last ver
>
>
> 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
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, m
On Fri, Apr 4, 2014 at 4:51 PM, Mike Hearn wrote:
>
> I don't want to suggest the problem is unimportant - I'd love it if the
> world could move beyond passwords. But I have many scars from my time in
> the Google account swamps. We had a big team, lots of resources and even
> just getting people
On Fri, Apr 4, 2014 at 4:56 PM, slush 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 services to u
On Fri, Apr 4, 2014 at 5:09 PM, Eric Larchevêque wrote:
> On Fri, Apr 4, 2014 at 4:56 PM, slush 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 u
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 tag they even create
a private key and upload the public part to be signed for you, it's
seamless for
On Fri, Apr 4, 2014 at 5:37 PM, Mike Hearn 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 plugin
once t
>
> 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 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 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 together. And if some
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 w
On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock 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 compatible with threshold ECDSA, otherwise we're
>> just going to have another redundant
On Friday, 4 April 2014, at 9:25 am, Gregory Maxwell wrote:
> On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock 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 compatible with thres
On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock 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 prime
> modulus. A
On Friday, 4 April 2014, at 10:08 am, Gregory Maxwell wrote:
> On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock 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
On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock 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 dissemination to my next
> of
On Friday, 4 April 2014, at 10:51 am, Gregory Maxwell wrote:
> On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock 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 p
31 matches
Mail list logo
