From: s7r <s7r@sky-ip•org>
To: Jeff Garzik <jgarzik@gmail•com>, Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
Date: Sun, 20 Dec 2015 13:43:15 +0200 [thread overview]
Message-ID: <56769453.4060903@sky-ip.org> (raw)
In-Reply-To: <CADm_Wca0cWRvcVaJ+p47A49yffQ1vP=u4807j7axn=mdBdsUGQ@mail.gmail.com>
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
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto: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"
>
>
next prev parent reply other threads:[~2015-12-20 11:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-12 20:09 jl2012
2015-12-12 23:01 ` gb
2015-12-13 1:00 ` Vincent Truong
2015-12-13 2:07 ` Gregory Maxwell
2015-12-13 8:13 ` Chris Priest
2015-12-13 8:18 ` Gregory Maxwell
2015-12-13 9:17 ` Chris Priest
2015-12-13 9:24 ` Gregory Maxwell
2015-12-13 18:11 ` jl2012
2015-12-13 21:20 ` Ricardo Filipe
2015-12-13 21:36 ` Tier Nolan
2015-12-20 11:24 ` Peter Todd
2015-12-20 11:34 ` Jeff Garzik
2015-12-20 11:43 ` s7r [this message]
2015-12-20 16:30 ` Chris Pacia
2015-12-20 16:35 ` Peter Todd
2015-12-21 3:34 ` Jeff Garzik
2015-12-21 3:23 ` Tom Harding
2015-12-13 16:14 ` Danny Thorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56769453.4060903@sky-ip.org \
--to=s7r@sky-ip$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jgarzik@gmail$(echo .)com \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox