1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sipa@ulyssis.org>) id 1RcIsZ-0006Mz-6L
for bitcoin-development@lists.sourceforge.net;
Sun, 18 Dec 2011 15:42:23 +0000
X-ACL-Warn:
Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129]
helo=cavuit01.kulnet.kuleuven.be)
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RcIsU-00088W-QK for bitcoin-development@lists.sourceforge.net;
Sun, 18 Dec 2011 15:42:23 +0000
X-KULeuven-Envelope-From: sipa@ulyssis.org
X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5,
autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00,
FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20)
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: F41F5138044.A5779
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be
[134.58.240.75])
by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id F41F5138044
for <bitcoin-development@lists.sourceforge.net>;
Sun, 18 Dec 2011 16:42:06 +0100 (CET)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps02.kuleuven.be (Postfix) with ESMTP id D7C19F3862
for <bitcoin-development@lists.sourceforge.net>;
Sun, 18 Dec 2011 16:42:06 +0100 (CET)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id DB29A10052
for <bitcoin-development@lists.sourceforge.net>;
Sun, 18 Dec 2011 16:42:06 +0100 (CET)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id 96BB287C1AA; Sun, 18 Dec 2011 16:42:06 +0100 (CET)
Date: Sun, 18 Dec 2011 16:42:06 +0100
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20111218154205.GA5304@ulyssis.org>
References: <201112170132.26201.luke@dashjr.org>
<CAGQP0AFg7dMK4Rzm9M1Ur-jeQmAp85nKbE_Ry5sXr+Pw=e3EQg@mail.gmail.com>
<1324138546.29801.3.camel@BMThinkPad.lan.bluematt.me>
<4EECDD5F.8030402@parhelic.com>
<CAGQP0AE-OkJroyAN5jga_a-s8i_SSub9uSgTQBZDrQQfzC=bSg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <CAGQP0AE-OkJroyAN5jga_a-s8i_SSub9uSgTQBZDrQQfzC=bSg@mail.gmail.com>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.20 (2009-06-14)
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
X-Headers-End: 1RcIsU-00088W-QK
Subject: Re: [Bitcoin-development] Pubkey addresses
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 18 Dec 2011 15:42:23 -0000
On Sun, Dec 18, 2011 at 01:15:26PM +0100, Jorge Tim=F3n 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 t=
he
output script, while redeeming requires the full pubkey plus the signatur=
e
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 hav=
e
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 sig=
nature)
The first is very easy to implement (see pull #649). Compact signatures=20
and pubkey recovery require a change to the scripting language (though ar=
e
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 pu=
bkeys
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 fro=
m
clear to me how pruning will be implemented in the future (as a pruning
node cannot function as a NODE_NETWORK service anymore).
--=20
Pieter
|
