From: Gregory Maxwell <gmaxwell@gmail•com>
To: Luke-Jr <luke@dashjr•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Pubkey addresses
Date: Sat, 17 Dec 2011 18:46:34 -0500 [thread overview]
Message-ID: <CAAS2fgSjbkS03x+e21pRvA9jswy7OdKP4Qe3uBLe_kTbBdv77g@mail.gmail.com> (raw)
In-Reply-To: <201112171652.22148.luke@dashjr.org>
On Sat, Dec 17, 2011 at 4:52 PM, Luke-Jr <luke@dashjr•org> wrote:
> I propose that full public key addresses be required to be "compact" (length
> 33), and use version 21 (begins with '4', and is redundant with ver 20 for 20-
> byte data). Any reason this wouldn't be workable?
Would introduce yet another address type that services will have to cope with.
No currently deployed sofware knows how to spend it.
No currently deployed software knows how to receive it.
All pay-to-pubkey schemes (point compressed or otherwise) shift
storage to TXN _output_ scripts which are the least prunable place, so
for nodes which are pruning any pay to pubkey scheme will result in
more storage than pay to address.
Ignoring pruning, pay-to-address + key recovery is quite a bit smaller
than pay-to-compressed pubkey.
The downsides to op-eval2+recovery were the lack of software, but
we're in an equal boat with this.
Excitement over key recovery fell was diminished when it was pointed
out that it only saves space in input scripts which wasn't so
important because they're quickly prunable. If you accept that
pruning will someday be common on many nodes then you should prefer
pay to address (since its smallest in that case). If you assume they
won't be, you should prefer pay to address plus key recovery (since
its the smallest without pruning).
Pay to non-compressed pubkey is smaller than
pay-to-address-without-recovery assuming you don't prune, and its more
deployable because nodes can already recieve it. It's larger if you
do prune, and it's larger than recovery either way. Pay-to-compressed
has all the disadvantages, it still larger than recovery and doesn't
have the advantage of already deployed software.
Sorry to be curt— I'm a little irritated that discussion on recovery
in OP_EVAL was dropped because "input script size doesn't matter
because of pruning" and now people are talking about adding another
address type which creates seriously bloated transactions where there
is pruning, because its slightly smaller in the no-pruning case (and
again, still not as small for key recovery).
next prev parent reply other threads:[~2011-12-17 23:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-17 6:32 Luke-Jr
2011-12-17 11:14 ` Jorge Timón
2011-12-17 16:15 ` Matt Corallo
2011-12-17 18:20 ` Jordan Mack
2011-12-18 12:15 ` Jorge Timón
2011-12-18 14:03 ` Luke-Jr
2011-12-18 14:28 ` Jorge Timón
2011-12-18 14:34 ` Luke-Jr
2011-12-18 15:42 ` Pieter Wuille
2011-12-18 19:50 ` Jorge Timón
2011-12-17 13:54 ` Wladimir
2011-12-17 21:52 ` Luke-Jr
2011-12-17 23:46 ` Gregory Maxwell [this message]
2011-12-18 0:28 ` Luke-Jr
2011-12-18 0:39 ` Luke-Jr
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=CAAS2fgSjbkS03x+e21pRvA9jswy7OdKP4Qe3uBLe_kTbBdv77g@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(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