From: Mike Hearn <hearn@vinumeris•com>
To: Thomas Voegtlin <thomasv@electrum•org>, Jeff Garzik <jgarzik@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
Date: Mon, 20 Jul 2015 15:46:39 +0200 [thread overview]
Message-ID: <CA+w+GKTtkYUst0UJa6364LqBRqWYrA+fOKed973mQCQS4ze=4Q@mail.gmail.com> (raw)
In-Reply-To: <55AB8785.4080201@electrum.org>
[-- Attachment #1: Type: text/plain, Size: 3714 bytes --]
Hey Thomas,
Was great to hang out with you in Berlin last week!
> Bitcoin addresses do not require a webserver. If we want to build
> something that competes with that, we should have at least that level of
> convenience.
>
Absolutely agree! Convenience for the user is an absolute must. I just
don't know how to let users exchange large data packets without some kind
of server acting as a dropbox in the middle. That leaves two solutions:
1) Set up a way for users to exchange large data packets by using other
people's web servers, e.g. with no user visible signup flow (pure p2p/done
automatically in the background by user wallets)
2) Make the data packets small instead.
We can debate better signing methods that work towards (2). The reason I am
unsure about this is that the point of BIP70 is to be extended with useful
features. Even if we find a way to squeeze a human-meaningful
signature/cert into a URI, that's only one of BIP70s features. The next set
we want to add might end up running out of space again.
A lot of the problems come from how limited QR codes are. So perhaps there
is also a third approach: either find a better replacement for QR codes
(maybe something that uses colour like Microsoft Tag
<http://tag.microsoft.com/what-is-tag/home.aspx>), or drop them as a design
constraint.
Calling Jeff Garzik, Jeff, are you there? I recall BitPay did some
experiments to find out how much data you can stuff into a QR code before
it hurts scannability too much, do you have a writeup anywhere?
This is the main reason I feel uneasy about anything that isn't "build a
store+forward network". QR codes are so fundamental to our ecosystem, but
sooooooo limited, that I'm not sure how else to move forward. We were told
when designing BIP70 that even putting a URL in the QR code is pushing it!
There was talk of compressing the URL in some way. So adding even an ECC
signature which is much longer seems risky.
We can imagine a parallel universe where our societies technology was more
NFC oriented: laptops had NFC tags in them, phones had better NFC support
etc. Then we would have more bytes to play with and we wouldn't face this
pointer-indirection problem :( But laptops don't have the hardware and
Apple sits on their NFC API because they can't imagine any use case that
isn't credit cards :( :(
To get more specific, DNSSEC uses RSA 1024 bit. This causes two problems:
1. A DNSSEC proof is large, bytes wise. Even a single RSA signature
won't fit nicely in a QR code, I think.
2. 1024 bit is the absolute minimum strength you can get away with,
really. DNSSEC assumes frequent key rotations to try and help, which
complicates things.
So I'm not sure using DNSSEC fixes the usability problem we want to fix.
I will do a separate reply to break out some thoughts on replacing QR codes.
Would it be possible to create the same kind of "lightweight payment
> requests" using SSL certificates? Probably, if the final signing key is
> a EC key, and if the payment request does not include the whole chain of
> certificates.
Given that the pre-existing value of the PKI is much lower for individuals
than for companies/websites, where they all have certs already, building a
Bitcoin-specific or entirely new/independent PKI for people is not so
unthinkable, I agree.
In theory such a cert could be as minimal as:
<ECC signature>thomasv@electrum•org
so literally just a signature + a UTF-8 string, and that's it! You don't
need anything more if you're willing to sacrifice extensibility,
revocability, etc.
The pubkey of the CA would be obtained by running the pubkey recovery
algorithm on the signature, and then checked against a table of trusted
pubkeys.
[-- Attachment #2: Type: text/html, Size: 4618 bytes --]
next prev parent reply other threads:[~2015-07-20 13:46 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 22:31 Mike Hearn
2015-07-14 6:42 ` Thomas Voegtlin
2015-07-14 11:19 ` Milly Bitcoin
2015-07-14 13:13 ` Thomas Voegtlin
2015-07-14 11:45 ` Mike Hearn
2015-07-19 11:18 ` Thomas Voegtlin
2015-07-20 13:46 ` Mike Hearn [this message]
2015-07-20 14:32 ` Thomas Voegtlin
2015-07-20 14:42 ` Mike Hearn
2015-07-20 14:52 ` Thomas Voegtlin
2015-07-20 15:14 ` Mike Hearn
2015-07-20 15:34 ` Thomas Voegtlin
2015-07-20 16:09 ` Mike Hearn
-- strict thread matches above, loose matches on Subject: below --
2015-07-27 22:46 Riccardo Spagni
2015-07-18 11:40 Riccardo Spagni
2015-07-18 11:46 ` Mike Hearn
2015-07-17 8:00 Riccardo Spagni
2015-07-18 11:21 ` Mike Hearn
2015-07-16 16:18 Riccardo Spagni
2015-07-14 19:07 Riccardo Spagni
2015-07-17 0:55 ` Justin Newton
2015-07-17 0:58 ` Justin Newton
2015-07-17 1:01 ` Justin Newton
2015-07-17 1:02 ` Justin Newton
2015-07-23 9:48 ` Thomas Voegtlin
2015-07-23 13:07 ` Thomas Voegtlin
2015-07-27 21:51 ` Justin Newton
2015-07-31 20:34 ` Thomas Voegtlin
2015-07-14 17:29 Justin Newton
2015-07-18 13:29 ` Thomas Voegtlin
2015-07-18 23:01 ` Justin Newton
2015-07-20 8:56 ` Thomas Voegtlin
2015-07-14 8:29 Riccardo Spagni
[not found] <55A3B52C.9020003@electrum.org>
2015-07-13 13:06 ` Thomas Voegtlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+w+GKTtkYUst0UJa6364LqBRqWYrA+fOKed973mQCQS4ze=4Q@mail.gmail.com' \
--to=hearn@vinumeris$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jgarzik@gmail$(echo .)com \
--cc=thomasv@electrum$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox