Re: [Bitcoin-development] Pubkey addresses

[Gregory Maxwell <gmaxwell@gmail.com>]

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).