path: root/60/4c97ce3d0e1faff417028dbb52ff19a1ffc136

Return-Path: <jeremy.l.rubin.travel@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 58DE947E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 06:05:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com
	[209.85.212.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 029B4DE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 06:05:32 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so192468148wib.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 23:05:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=aaJ8X80XLZHMBR3MK0HSFh03gB9uQqQyqZLtKcWVIG4=;
	b=IS3K2Dv5nsZn+G5VmUUA3TmEufNZjUB7OgKIizwWsB4LlGprsYV/cmd0xbjc3ErVB/
	Dr//UPpBQC0gdxhXl3IJjtEVnYzwQ/QiszcL39a6t6+o+PAhzUMzBWzK0vRk/Oxn9ehs
	ExgpEG0MIEykj/iFi4TThzeF5QygGzzzOTN+cR7vKO6wqM9H4Awf2hpdbAIscXmco8Pl
	g70w2savkFmh5rGSoZYOHGI7z62BfXgSFJu5clwGM2pTEWvpF1M3RT/mE1+UuQyB7mpb
	0HPZEKVa+4ksuTnY+64wlfcCxfFwA8TG717Y35JI1X3KY3zRRhfSOGEaRNvAEQoXtpIt
	2gLQ==
X-Received: by 10.180.36.129 with SMTP id q1mr13870228wij.10.1437631531503;
	Wed, 22 Jul 2015 23:05:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.229.195 with HTTP; Wed, 22 Jul 2015 23:05:12 -0700 (PDT)
In-Reply-To: <20150723045546.Horde.KiM4VIQqwnFJ3lwdFrO-2w3@server47.web-hosting.com>
References: <CAJ+8mEOPRQ-euqL62nB8_7xTaZbjCmFwKHXUrD9y=bNr56m-rg@mail.gmail.com>
	<CAE-z3OWgdDiFNgKd8D_pPyV6ZdPdUjdFwL7eMQzjAL_xfn+ZUg@mail.gmail.com>
	<CABsx9T21i_onZcj=zcY=rvbxQtVUh=cW-TYxYNqwxcFxA5hKvQ@mail.gmail.com>
	<20150723045546.Horde.KiM4VIQqwnFJ3lwdFrO-2w3@server47.web-hosting.com>
From: Jeremy Rubin <jeremy.l.rubin.travel@gmail.com>
Date: Thu, 23 Jul 2015 14:05:12 +0800
Message-ID: <CAJ+8mENg0WshSjuF_vWquScHJ1nqZKOTHyqwMTKiMC1JOEkLFA@mail.gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=e89a8f502ec2c0d63b051b84ac99
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2015 06:05:34 -0000

--e89a8f502ec2c0d63b051b84ac99
Content-Type: text/plain; charset=UTF-8

A standard transaction is 225 bytes, leading to a savings of 8.6%.

However, that is essentially the minimum saving. For other sizes (eg, 10
outputs) which seem to be pretty frequent savings can be greater.

Furthermore, it is important to note that this is a memory saving for the
UTXO pool so the reduction there is more (not super familiar with how the
UTXO pool is stored, but it should be a better savings than 8.6%).


Does anyone have the tools currently to be able to easily run through the
chain and analyze the impact of this change on historical data more
directly?

On Thu, Jul 23, 2015 at 12:55 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Quoting Gavin Andresen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>  On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>  It also requires most clients to be updated to support the new address
>>> system.
>>>
>>
>>
>> That's the killer: introducing Yet Another Type of Bitcoin Address takes a
>> very long time and requires a lot of people to change their code. At
>> least,
>> that was the lesson learned when we introduced P2SH addresses.
>>
>> I think it's just not worth it for a very modest space savings (10 bytes,
>> when scriptSig+scriptPubKey is about 120 bytes), especially with the
>> extreme decrease in security (going from 2^160 to 2^80 to brute-force).
>>
>> --
>> --
>> Gavin Andresen
>>
>
> I think it would only save ~5% with all overhead (value, sequence,
> locktime, version, etc.) counted
>
> A better way is to introduce shorter ECDSA keys, which will save a lot of
> space for public key and signature. It is safe as long as the output value
> is much lower than the cost of attack.
>
> If this happens, I think it will be part of the OP_MAST which will require
> a new address type anyway.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--e89a8f502ec2c0d63b051b84ac99
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A standard transaction is 225 bytes, leading to a savings =
of 8.6%.<div><br></div><div>However, that is essentially the minimum saving=
. For other sizes (eg, 10 outputs) which seem to be pretty frequent savings=
 can be greater.</div><div><br></div><div>Furthermore, it is important to n=
ote that this is a memory saving for the UTXO pool so the reduction there i=
s more (not super familiar with how the UTXO pool is stored, but it should =
be a better savings than 8.6%).=C2=A0<br><div><br></div><div><br></div></di=
v><div>Does anyone have the tools currently to be able to easily run throug=
h the chain and analyze the impact of this change on historical data more d=
irectly?</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Thu, Jul 23, 2015 at 12:55 PM, jl2012 via bitcoin-dev <span dir=3D"lt=
r">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"><br>
Quoting Gavin Andresen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt;:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev &lt;<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
It also requires most clients to be updated to support the new address<br>
system.<br>
</blockquote>
<br>
<br>
That&#39;s the killer: introducing Yet Another Type of Bitcoin Address take=
s a<br>
very long time and requires a lot of people to change their code. At least,=
<br>
that was the lesson learned when we introduced P2SH addresses.<br>
<br>
I think it&#39;s just not worth it for a very modest space savings (10 byte=
s,<br>
when scriptSig+scriptPubKey is about 120 bytes), especially with the<br>
extreme decrease in security (going from 2^160 to 2^80 to brute-force).<br>
<br>
--<br>
--<br>
Gavin Andresen<br>
</blockquote>
<br></div></div>
I think it would only save ~5% with all overhead (value, sequence, locktime=
, version, etc.) counted<br>
<br>
A better way is to introduce shorter ECDSA keys, which will save a lot of s=
pace for public key and signature. It is safe as long as the output value i=
s much lower than the cost of attack.<br>
<br>
If this happens, I think it will be part of the OP_MAST which will require =
a new address type anyway.<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>

--e89a8f502ec2c0d63b051b84ac99--