Return-Path: <jgarzik@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6AFBDB3F for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 20 Dec 2015 11:34:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E1606A0 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 20 Dec 2015 11:34:29 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id to4so20376078igc.0 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 20 Dec 2015 03:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r8Jcusi9eaoV9XsUbFipSnAO0iqSiHuVSVVM/jQKG4o=; b=D9bxgRAO5eXvy7pgJKEt41SnouuwQBEEJubUjlEKQztoyd0pVFShQcYCTkVe2/7xIf crcjLAnLN82eq9MatyKN2YiGUPxI5yZXRTV3HVSIUtatg5jkBQjV5eBjrF9ulqk7n7oM Nxmxz/kgCByoDcXXA4DxGDZBFUmv1UakzYfdnwelPx5Hh6YuSUbNlzhTp7Y1X5foqShu EVMOCjizFDIMBA1gWYpAGhuUZPi5KWeIzcF+5+HW/JvMvVzdz+VSkmjwiy8yyV+8vfoq LqSnmugOIDtqtqCobl0l8IQKB2tmmW/hbh5ty0/1Jep51E4mEeCXOsJMEl02pihtS1iO Bf0w== MIME-Version: 1.0 X-Received: by 10.50.36.105 with SMTP id p9mr13700146igj.54.1450611269412; Sun, 20 Dec 2015 03:34:29 -0800 (PST) Received: by 10.79.8.198 with HTTP; Sun, 20 Dec 2015 03:34:29 -0800 (PST) In-Reply-To: <20151220112454.GB16187@muck> References: <50e629572d8de852eb789d50b34da308@xbt.hk> <1449961269.2210.5.camel@yahoo.com> <CACrzPenXGQZBrx8QC+1QE2oCE3N=qmfgc_OWrowtjtLjGkZrRA@mail.gmail.com> <CAAS2fgQi7aiwyOaVBiMbp6t9D58aFAmDdKPzFiscB6ouGzBK6A@mail.gmail.com> <20151220112454.GB16187@muck> Date: Sun, 20 Dec 2015 06:34:29 -0500 Message-ID: <CADm_Wca0cWRvcVaJ+p47A49yffQ1vP=u4807j7axn=mdBdsUGQ@mail.gmail.com> From: Jeff Garzik <jgarzik@gmail.com> To: Peter Todd <pete@petertodd.org> Content-Type: multipart/alternative; boundary=089e011763436bb233052752c15c 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 <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 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: Sun, 20 Dec 2015 11:34:30 -0000 --089e011763436bb233052752c15c Content-Type: text/plain; charset=UTF-8 On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > What I proprosed is that a consensus-critical maximum UTXO age be part > of the protocol; UTXO's younger than that age are expected to be cached. > For UTXO's older than that age, they can be dropped from the cache, > however to spend them you are required to provide the proof, and that > proof counts as blockchain space to account for the fact that they do > need to be broadcast on the network. Yes, this is almost what -has- to happen in the long term. Ideally we should start having wallets generate those proofs now, and then introduce the max-age as a second step as a planned hard fork a couple years down the line. However, 1) There is also the open question of "grandfathered" UTXOs - for those wallets generated in 2009, buried in a landfill and then dug out 10 years ago 2) This reverses the useful minimization attribute of HD wallets - "just backup the seed" --089e011763436bb233052752c15c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-de= v <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation= .org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span= > wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex">What I proprosed is that a consensus-critical maximum= UTXO age be part<br> of the protocol; UTXO's younger than that age are expected to be cached= .<br> For UTXO's older than that age, they can be dropped from the cache,<br> however to spend them you are required to provide the proof, and that<br> proof counts as blockchain space to account for the fact that they do<br> need to be broadcast on the network.</blockquote><div></div></div><br></div= ><div class=3D"gmail_extra">Yes, this is almost what -has- to happen in the= long term.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e= xtra">Ideally we should start having wallets generate those proofs now, and= then introduce the max-age as a second step as a planned hard fork a coupl= e years down the line.</div><div class=3D"gmail_extra"><br></div><div class= =3D"gmail_extra">However,</div><div class=3D"gmail_extra">1) There is also = the open question of "grandfathered" UTXOs - for those wallets ge= nerated in 2009, buried in a landfill and then dug out 10 years ago</div><d= iv class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">2) This rever= ses the useful minimization attribute of HD wallets - "just backup the= seed"</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e= xtra"><br></div></div> --089e011763436bb233052752c15c--