path: root/8d/f5e062e0e9fedf4588403d6e2aa946e51f42f6

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 2055140A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 04:05:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com
	[209.85.212.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43C2AFD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 04:05:43 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so189840275wib.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 21:05:42 -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=pDcmQ3VsnzP5pw7FmgWuT3Hvy3F7Oly+dl4YEK9XVe8=;
	b=agva8iSLyu0ZYdpLDwL5RxfoDN3NNSoHgC4iSKAB1pjGDqnkj9rC2T7Au1bz17bTiK
	EIqKSWQ09yp3bCTKD8EwZV9yMeX8qtSS03MrSsn25eIngjSwYGVFpivpMV8xP7Mo8/wh
	SlBoNG+r27ulRDGM+NehQ2J7NZg/ss3aheCPhb8LikUJRzuYURAGXIVl7nuHf7OnsJek
	2Qfp7vCfV1a50nmcwEjsKEEo0gqriSmmGPOz2aHwSp0iq2qDQVkZhAwzuU/tJrzkSblR
	5I1C9o26uU9GJevCOpyGteCgxC2RWfejiITBSNytKF/f/kZKru2+xlc8t9S7X1DsXk72
	/YCQ==
X-Received: by 10.194.82.167 with SMTP id j7mr11238126wjy.123.1437624341854;
	Wed, 22 Jul 2015 21:05:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.229.195 with HTTP; Wed, 22 Jul 2015 21:05:22 -0700 (PDT)
In-Reply-To: <CABsx9T21i_onZcj=zcY=rvbxQtVUh=cW-TYxYNqwxcFxA5hKvQ@mail.gmail.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>
From: Jeremy Rubin <jeremy.l.rubin.travel@gmail.com>
Date: Thu, 23 Jul 2015 12:05:22 +0800
Message-ID: <CAJ+8mEP5dCmRbm7-FY5v+mO+jwB-=LnTVDo=5+AML4oAUgTwuw@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bb04d2c377ff0051b8300e7
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 04:05:44 -0000

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

I think the catch here is that under STUA (short term use address) there is
a strict incentive, you can reduce the transaction fee for these txns. This
also fits with the general model that you pay the miners for security. My
belief is that when there is a savings benefit to be had large players will
prefer it at a minimum, and users will desire it.


Your analysis of saving is inaccurate, it comes to be at or greater than 20
bytes because there is typically 2 UTXOs or more. I get that this is still
marginal, but when the margins are tight this is a pretty decent gain.


The security decrease is actually less extreme than it seems. This is for
multiple reasons:
1) you can select LEN_PARAM when you make the tx to be secure at that time
Adding a byte or two gets much more security while still keeping it lean.
2) For a small transaction, the hash power is less rewarding than just
working on the blockchain or doing something else
3) These addresses are only for use for short term, not perm storage. As
such, if you model the threat it isn't great (I'm using this address for
one day, someone grinds it in that time).
4) Because it is a UTXO saving, it reduces memory bloat.t

It would be interesting to get a more exact analysis on the time needed to
run a brute force as it involves computing a valid keypair and hashing for
each attempt.



On Thu, Jul 23, 2015 at 5:06 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">I think the catch here is that under STUA (short term use =
address) there is a strict incentive, you can reduce the transaction fee fo=
r these txns. This also fits with the general model that you pay the miners=
 for security. My belief is that when there is a savings benefit to be had =
large players will prefer it at a minimum, and users will desire it.<div><b=
r></div><div><br></div><div>Your analysis of saving is inaccurate, it comes=
 to be at or greater than 20 bytes because there is typically 2 UTXOs or mo=
re. I get that this is still marginal, but when the margins are tight this =
is a pretty decent gain.</div><div><br></div><div><br></div><div>The securi=
ty decrease is actually less extreme than it seems. This is for multiple re=
asons:</div><div>1) you can select LEN_PARAM when you make the tx to be sec=
ure at that time Adding a byte or two gets much more security while still k=
eeping it lean.</div><div>2) For a small transaction, the hash power is les=
s rewarding than just working on the blockchain or doing something else</di=
v><div>3) These addresses are only for use for short term, not perm storage=
. As such, if you model the threat it isn&#39;t great (I&#39;m using this a=
ddress for one day, someone grinds it in that time).</div><div>4) Because i=
t is a UTXO saving, it reduces memory bloat.t</div><div><br></div><div>It w=
ould be interesting to get a more exact analysis on the time needed to run =
a brute force as it involves computing a valid keypair and hashing for each=
 attempt.</div><div><br></div><div><br></div></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Thu, Jul 23, 2015 at 5:06 AM, Gavin An=
dresen via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div class=3D"gmail_extra"><span class=3D""><div class=3D"gmail_quote=
">On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <span dir=3D"=
ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">It also requires most clients to be updated to =
support the new address system.</blockquote></div><br></span>That&#39;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.</div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">I think it&#39;s just not w=
orth it for a very modest space savings (10 bytes, when scriptSig+scriptPub=
Key is about 120 bytes), especially with the extreme decrease in security (=
going from 2^160 to 2^80 to brute-force).<span class=3D"HOEnZb"><font color=
=3D"#888888"><br clear=3D"all"><div><br></div>-- <br><div>--<br>Gavin Andre=
sen<br></div><div><br></div>
</font></span></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>
<br></blockquote></div><br></div>

--047d7bb04d2c377ff0051b8300e7--