From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: From: Gregory Maxwell To: Luke-Jr 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 23:46:41 -0000 On Sat, Dec 17, 2011 at 4:52 PM, Luke-Jr 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).