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 B7D05FB3 for ; Sun, 20 Dec 2015 11:43:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.22]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id C5FD5A0 for ; Sun, 20 Dec 2015 11:43:22 +0000 (UTC) Received: from [0.0.0.0] (unknown [93.174.93.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: s7r@sky-ip.org) by outbound.mailhostbox.com (Postfix) with ESMTPSA id 86CCD78183B; Sun, 20 Dec 2015 11:43:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org; s=20110108; t=1450611818; bh=yfhmjBlPoXjYHkg2GZ7KSRU+WTn42EHqzPBWGyxuhc8=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=bQ3GPIpzvhnHFKfxoKM72cNnf9h5STHqEAR0EWymHiTvZ9kaX4veQhj4j987E0W9B CcFUeMMw/IAV5mobjtRC52ZhOlX2WoS2/VT+rjwyVRErP8TMl7WmmnVuL3q/cq2wnj BXKi0ioo2NhZ5tVxYRXwY5B/PcFNisioN7It6gEQ= Reply-To: s7r@sky-ip.org References: <50e629572d8de852eb789d50b34da308@xbt.hk> <1449961269.2210.5.camel@yahoo.com> <20151220112454.GB16187@muck> To: Jeff Garzik , Peter Todd From: s7r X-Enigmail-Draft-Status: N1110 Message-ID: <56769453.4060903@sky-ip.org> Date: Sun, 20 Dec 2015 13:43:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=W7WYLUik c=1 sm=1 tr=0 a=DLnS8E+9DKeiaAAUnOny6w==:117 a=DLnS8E+9DKeiaAAUnOny6w==:17 a=N659UExz7-8A:10 a=hkgX1uSMAkJQHbajC78A:9 a=pILNOxqGKmIA:10 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,URIBL_BLACK autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 20 Dec 2015 15:14:48 +0000 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:43:29 -0000 What will be the actual effect over wallets? Say I have the private key for a dormant UTXO older than the consensus-critical maximum UTXO age. The UTXO is not part of the cache. So I setup a full node and import my old private key (wallet.dat). Will I even see the correct balance (where will it get if from, since it's dropped from the cache), or it will show me a 0 balance? If I can see the correct balance, where can I get the proof I need and what ensures I'll always be able to get that proof? On 12/20/2015 1:34 PM, Jeff Garzik via bitcoin-dev wrote: > On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev > > 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" > >