path: root/14/9a16a8a40554519c9c360de0d327e19324d35b

Return-Path: <vincent.truong@procabiak.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C864CC4D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 13 Dec 2015 01:00:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com
	[209.85.213.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C298E5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 13 Dec 2015 01:00:27 +0000 (UTC)
Received: by mail-ig0-f175.google.com with SMTP id mv3so62420538igc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 12 Dec 2015 17:00:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=procabiak.com; s=procabiakindustries;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=tH6Q83yTInH+n9QMDxHsiZlvSE4XjMwAkUI4VqGzJSI=;
	b=Pxq+VT2t5paDUptlbQ59kguPXhFaWfo8Ap1LM8hdMX0KDQ0zXqKe89WrivnewoFnp2
	K1t89eTfSYDGNBZuskUhmUV88xWbjw1RYlbTtxqV3hKjpHymlD1xepHqtba0eEmD7Aj5
	F7X4qPFqhmhwXeQEbUxGf0VNjndAJqFvSZtT8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=tH6Q83yTInH+n9QMDxHsiZlvSE4XjMwAkUI4VqGzJSI=;
	b=KwHNEJiaG51rQrUPm4ulN+8/4xcMbzJ0/FskwC7OThs7mtRRfumyYmrV7NdnZjyHKR
	LIDRRRUudzDyUFuOSCN/pyKinZ+um+qMbxmX2BnYgXJZEsr1oQtyD/rRs9rSivJ85/Ly
	SI2C6XT1KqDLMWatUp3ILSBYYkAGa88nef5jCXZ/k0jE182FI68prHUUe/WQOVSvtcWo
	n5+GsK53aT4Y44o4+DeLkBbcM0ANq7t0rEJks9kw6mw545sA47Xd3t6zLeHY8mo2+Unu
	Rtirn22WnZleki0WzmZs5vm4ee8f6bKTZxpQKdst5DB06PpuCEjypx6OdKud7NKV3ZeC
	JLVQ==
X-Gm-Message-State: ALoCoQlBOMbW+YiVsNFLOTjZnTPK7ufi+X7dknO//iRfE+/6mpH3mLYsMZbNc5X1liLTaRXELWT1ok5jI/7i2qWw+uuGwtzjeQ==
MIME-Version: 1.0
X-Received: by 10.50.33.20 with SMTP id n20mr11391384igi.17.1449968426972;
	Sat, 12 Dec 2015 17:00:26 -0800 (PST)
Received: by 10.36.129.10 with HTTP; Sat, 12 Dec 2015 17:00:26 -0800 (PST)
X-Originating-IP: [14.202.127.219]
Received: by 10.36.129.10 with HTTP; Sat, 12 Dec 2015 17:00:26 -0800 (PST)
In-Reply-To: <1449961269.2210.5.camel@yahoo.com>
References: <50e629572d8de852eb789d50b34da308@xbt.hk>
	<1449961269.2210.5.camel@yahoo.com>
Date: Sun, 13 Dec 2015 12:00:26 +1100
Message-ID: <CACrzPenXGQZBrx8QC+1QE2oCE3N=qmfgc_OWrowtjtLjGkZrRA@mail.gmail.com>
From: Vincent Truong <vincent.truong@procabiak.com>
To: gb <kiwigb@yahoo.com>
Content-Type: multipart/alternative; boundary=089e01537a5406904d0526bd1581
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,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
X-Mailman-Approved-At: Sun, 13 Dec 2015 01:32:33 +0000
Cc: 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, 13 Dec 2015 01:00:28 -0000

--089e01537a5406904d0526bd1581
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Dormant threshold is way too low. There's many news articles about people
forgetting that they used to mine bitcoins and then suddenly remembered.
This will continue to happen for much longer than 8 years as people
rediscover bitcoin when it goes further mainstream. You can't expect them
to have run a node/kept their utxo before they were aware of this change
and then realise miners have discarded their utxo. Oops?

Since we can't predict when mainstream will happen, you instead need a
threshold where the key holder is likely dead. That should be like 80 years
or 120 years, so 4.2m to 6.3m confirmations.

Next paragraph is off topic:

IMO it would be even better for these dormant & dead key holder's utxos to
also re-enter the economy as miner fees; let 1 dormant utxo to be mined per
block. It would need a hard fork. But then maybe people would stop being so
stupid with burning bitcoins/sending it to 1BitcoinEater, or mining a
million bitcoins from day 1 and leaving it, if they know it'll eventually
go into another miner's pockets. This could be used to fund cheap
transactions forever, and miners would be incentivised to hold copies of
these dormant utxos since it could become theirs one day. But this would be
even more controversial than just expiring them as we are in no short
supply of people who believe in Bitcoin's deflationary, fossil fuel
(burnable) economy, rather than a cyclical economy that better resembles
how we treat lost gold today...
On Dec 13, 2015 10:29 AM, "gb via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The general concept has merit and the basic outline here seems sound
> enough. I have harboured a notion for having "archived UTXO" for some
> time, this is essentially it. The retrieval from archive cost is on the
> UTXO holder not the entire storage network, which is then only bearing
> full 'instant' retrieval costs for N blocks.
>
> On Sat, 2015-12-12 at 15:09 -0500, jl2012--- via bitcoin-dev wrote:
> > It is a common practice in commercial banks that a dormant account migh=
t
> > be confiscated. Confiscating or deleting dormant UTXOs might be too
> > controversial, but allowing the UTXOs set growing without any limit
> > might not be a sustainable option. People lose their private keys.
> > People do stupid things like sending bitcoin to 1BitcoinEater. We
> > shouldn=E2=80=99t be obliged to store everything permanently. This is m=
y
> > proposal:
> >
> > Dormant UTXOs are those UTXOs with 420000 confirmations. In every block
> > X after 420000, it will commit to a hash for all UTXOs generated in
> > block X-420000. The UTXOs are first serialized into the form:
> > txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.
> > After some confirmations, nodes may safely delete the UTXO records of
> > block X permanently.
> >
> > If a user is trying to redeem a dormant UTXO, in addition the signature=
,
> > they have to provide the scriptPubKey, height (X), and UTXO value as
> > part of the witness. They also need to provide the Merkle path to the
> > dormant UTXO commitment.
> >
> > To confirm this tx, the miner will calculate a new Merkle hash for the
> > block X, with the hash of the spent UTXO replaced by 1, and commit the
> > hash to the current block. All full nodes will keep an index of latest
> > dormant UTXO commitments so double spending is not possible. (a
> > "meta-UTXO set")
> >
> > If all dormant UTXOs under a Merkle branch are spent, hash of the branc=
h
> > will become 1. If all dormant UTXOs in a block are spent, the record fo=
r
> > this block could be forgotten. Full nodes do not need to remember which
> > particular UTXO is spent or not, since any person trying to redeem a
> > dormant UTXO has to provide such information.
> >
> > It becomes the responsibility of dormant coin holders to scan the
> > blockchain for the current status of the UTXO commitment for their coin=
.
> > They may also need to pay extra fee for the increased tx size.
> >
> > This is a softfork if there is no hash collision but this is a
> > fundamental assumption in Bitcoin anyway. The proposal also works
> > without segregated witness, just by replacing "witness" with "scriptSig=
"
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<p dir=3D"ltr">Dormant threshold is way too low. There&#39;s many news arti=
cles about people forgetting that they used to mine bitcoins and then sudde=
nly remembered. This will continue to happen for much longer than 8 years a=
s people rediscover bitcoin when it goes further mainstream. You can&#39;t =
expect them to have run a node/kept their utxo before they were aware of th=
is change and then realise miners have discarded their utxo. Oops?</p>
<p dir=3D"ltr">Since we can&#39;t predict when mainstream will happen, you =
instead need a threshold where the key holder is likely dead. That should b=
e like 80 years or 120 years, so 4.2m to 6.3m confirmations.</p>
<p dir=3D"ltr">Next paragraph is off topic: </p>
<p dir=3D"ltr">IMO it would be even better for these dormant &amp; dead key=
 holder&#39;s utxos to also re-enter the economy as miner fees; let 1 dorma=
nt utxo to be mined per block. It would need a hard fork. But then maybe pe=
ople would stop being so stupid with burning bitcoins/sending it to 1Bitcoi=
nEater, or mining a million bitcoins from day 1 and leaving it, if they kno=
w it&#39;ll eventually go into another miner&#39;s pockets. This could be u=
sed to fund cheap transactions forever, and miners would be incentivised to=
 hold copies of these dormant utxos since it could become theirs one day. B=
ut this would be even more controversial than just expiring them as we are =
in no short supply of people who believe in Bitcoin&#39;s deflationary, fos=
sil fuel (burnable) economy, rather than a cyclical economy that better res=
embles how we treat lost gold today...</p>
<div class=3D"gmail_quote">On Dec 13, 2015 10:29 AM, &quot;gb via bitcoin-d=
ev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">The general concept has merit and the basic out=
line here seems sound<br>
enough. I have harboured a notion for having &quot;archived UTXO&quot; for =
some<br>
time, this is essentially it. The retrieval from archive cost is on the<br>
UTXO holder not the entire storage network, which is then only bearing<br>
full &#39;instant&#39; retrieval costs for N blocks.<br>
<br>
On Sat, 2015-12-12 at 15:09 -0500, jl2012--- via bitcoin-dev wrote:<br>
&gt; It is a common practice in commercial banks that a dormant account mig=
ht<br>
&gt; be confiscated. Confiscating or deleting dormant UTXOs might be too<br=
>
&gt; controversial, but allowing the UTXOs set growing without any limit<br=
>
&gt; might not be a sustainable option. People lose their private keys.<br>
&gt; People do stupid things like sending bitcoin to 1BitcoinEater. We<br>
&gt; shouldn=E2=80=99t be obliged to store everything permanently. This is =
my<br>
&gt; proposal:<br>
&gt;<br>
&gt; Dormant UTXOs are those UTXOs with 420000 confirmations. In every bloc=
k<br>
&gt; X after 420000, it will commit to a hash for all UTXOs generated in<br=
>
&gt; block X-420000. The UTXOs are first serialized into the form:<br>
&gt; txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated=
.<br>
&gt; After some confirmations, nodes may safely delete the UTXO records of<=
br>
&gt; block X permanently.<br>
&gt;<br>
&gt; If a user is trying to redeem a dormant UTXO, in addition the signatur=
e,<br>
&gt; they have to provide the scriptPubKey, height (X), and UTXO value as<b=
r>
&gt; part of the witness. They also need to provide the Merkle path to the<=
br>
&gt; dormant UTXO commitment.<br>
&gt;<br>
&gt; To confirm this tx, the miner will calculate a new Merkle hash for the=
<br>
&gt; block X, with the hash of the spent UTXO replaced by 1, and commit the=
<br>
&gt; hash to the current block. All full nodes will keep an index of latest=
<br>
&gt; dormant UTXO commitments so double spending is not possible. (a<br>
&gt; &quot;meta-UTXO set&quot;)<br>
&gt;<br>
&gt; If all dormant UTXOs under a Merkle branch are spent, hash of the bran=
ch<br>
&gt; will become 1. If all dormant UTXOs in a block are spent, the record f=
or<br>
&gt; this block could be forgotten. Full nodes do not need to remember whic=
h<br>
&gt; particular UTXO is spent or not, since any person trying to redeem a<b=
r>
&gt; dormant UTXO has to provide such information.<br>
&gt;<br>
&gt; It becomes the responsibility of dormant coin holders to scan the<br>
&gt; blockchain for the current status of the UTXO commitment for their coi=
n.<br>
&gt; They may also need to pay extra fee for the increased tx size.<br>
&gt;<br>
&gt; This is a softfork if there is no hash collision but this is a<br>
&gt; fundamental assumption in Bitcoin anyway. The proposal also works<br>
&gt; without segregated witness, just by replacing &quot;witness&quot; with=
 &quot;scriptSig&quot;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
<br>
<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>
</blockquote></div>

--089e01537a5406904d0526bd1581--