From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6AFBDB3F for ; 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 ; Sun, 20 Dec 2015 11:34:29 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id to4so20376078igc.0 for ; 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> <20151220112454.GB16187@muck> Date: Sun, 20 Dec 2015 06:34:29 -0500 Message-ID: From: Jeff Garzik To: Peter Todd 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-de= v <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 coupl= e years down the line.

However,
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

2) This rever= ses the useful minimization attribute of HD wallets - "just backup the= seed"


--089e011763436bb233052752c15c--