From: Pieter Wuille <pieter.wuille@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Pubkey addresses
Date: Sun, 18 Dec 2011 16:42:06 +0100 [thread overview]
Message-ID: <20111218154205.GA5304@ulyssis.org> (raw)
In-Reply-To: <CAGQP0AE-OkJroyAN5jga_a-s8i_SSub9uSgTQBZDrQQfzC=bSg@mail.gmail.com>
On Sun, Dec 18, 2011 at 01:15:26PM +0100, Jorge Timón wrote:
> But anyway, reading some comments I feel I'm missing something about
> this proposal. How can you save space by putting the whole public key
> instead of just the address (a hash of the public key) with each
> output?
> Is this what it's being proposed?
Yes. The reason is that currently a send-to-address puts the address in the
output script, while redeeming requires the full pubkey plus the signature
to be placed in the input script. Overall, this requires more space than a
send-to-pubkey, where the output contains the pubkey, and the input the
signature.
There are several possible improvements however, and they may not all have
been explained in this thread. To summarize:
* compressed public keys (33 byte pubkeys instead of 65 bytes)
* compact signatures (66 bytes instead of 72, including hash type byte)
* pubkey recovery (allows the public key to be derived from a compact signature)
The first is very easy to implement (see pull #649). Compact signatures
and pubkey recovery require a change to the scripting language (though are
already implemented, as they are used for message signing).
These result in several combinations that could be proposed:
1) send-to-pubkeys-hash
- currently the default addres type
2) send-to-recovered-pubkeys-hash-with-compact-signature-inside-op_eval
- extend the scripting language inside OP_EVAL, as described in
https://gist.github.com/1262449
- use compact signatures
- use key recovery, and never put a pubkey in the blockchain data
3) send-to-pubkey
- traditional transaction type
4) send-to-compressed-pubkey
- what Luke proposes as new address type
5) send-to-compressed-pubkeys-hash
- what pull #649 would bring
Gregory Maxwell made a small table to compare these options:
http://people.xiph.org/~greg/addr.compare.html
If you don't consider pruning, everything is better than send-to-pubkeys-hash
as we have now. Both using pubkeys instead of hashes, using compressed pubkeys
instead of full ones improve the situation independently, and using key
recovery is even better.
If you do consider pruning, the advantages are smaller, but it is far from
clear to me how pruning will be implemented in the future (as a pruning
node cannot function as a NODE_NETWORK service anymore).
--
Pieter
next prev parent reply other threads:[~2011-12-18 15:42 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 [this message]
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
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=20111218154205.GA5304@ulyssis.org \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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