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
------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
