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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Rc3xh-0003LC-66
for bitcoin-development@lists.sourceforge.net;
Sat, 17 Dec 2011 23:46:41 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com;
helo=mail-qy0-f175.google.com;
Received: from mail-qy0-f175.google.com ([209.85.216.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Rc3xg-0007tC-FH
for bitcoin-development@lists.sourceforge.net;
Sat, 17 Dec 2011 23:46:41 +0000
Received: by qcqw6 with SMTP id w6so2821678qcq.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 17 Dec 2011 15:46:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.137.131 with SMTP id w3mr3620997qct.27.1324165594985; Sat,
17 Dec 2011 15:46:34 -0800 (PST)
Received: by 10.229.1.197 with HTTP; Sat, 17 Dec 2011 15:46:34 -0800 (PST)
In-Reply-To: <201112171652.22148.luke@dashjr.org>
References: <201112170132.26201.luke@dashjr.org>
<201112171652.22148.luke@dashjr.org>
Date: Sat, 17 Dec 2011 18:46:34 -0500
Message-ID: <CAAS2fgSjbkS03x+e21pRvA9jswy7OdKP4Qe3uBLe_kTbBdv77g@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Rc3xg-0007tC-FH
Cc: bitcoin-development@lists.sourceforge.net
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: Sat, 17 Dec 2011 23:46:41 -0000
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" (len=
gth
> 33), and use version 21 (begins with '4', and is redundant with ver 20 fo=
r 20-
> byte data). Any reason this wouldn't be workable?
Would introduce yet another address type that services will have to cope wi=
th.
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=E2=80=94 I'm a little irritated that discussion on recover=
y
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).
|
