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 113DFC8D for ; Sun, 13 Dec 2015 16:14:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4F21F162 for ; Sun, 13 Dec 2015 16:14:23 +0000 (UTC) Received: by qkdp187 with SMTP id p187so104789635qkd.1 for ; Sun, 13 Dec 2015 08:14:22 -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=CsE8PW1UGkQ09Qievesf60TknuO0G2WrMCMruwy80Zs=; b=VdYrTiRrZdMBdrZxrOFh7HxpFOlnVkle8mv4lIOLiAnaD2mJQIk00k40KDfG0Ug5cL ZOb/CPINm5rMIptHC2fjat9EPcNs0Iljz/yxSZvKO0leklNiJmxFcpYk9zlTAwtTeksY A2BZqp2l+BStsPs+cItN6vymx0cTBWWv4rTjfVwP79vQIK5h6x1swp2f5mjxB2z2FC3R 9YBHLyW33Tir8O8Ebf6aFIw/TXE3EfdbdmloqYJ0dTkxf2MiXMCLi8ZJePQ0R01EUJeB m8xUA6Y3eWUgbjSnoc9/RAc8wUb++zn9H89KATEsh7dJdj9LRvUcfodsbtiD7vf0Pt0Z MEgw== MIME-Version: 1.0 X-Received: by 10.55.76.14 with SMTP id z14mr29521603qka.14.1450023262497; Sun, 13 Dec 2015 08:14:22 -0800 (PST) Received: by 10.140.20.228 with HTTP; Sun, 13 Dec 2015 08:14:21 -0800 (PST) Received: by 10.140.20.228 with HTTP; Sun, 13 Dec 2015 08:14:21 -0800 (PST) In-Reply-To: <50e629572d8de852eb789d50b34da308@xbt.hk> References: <50e629572d8de852eb789d50b34da308@xbt.hk> Date: Sun, 13 Dec 2015 08:14:21 -0800 Message-ID: From: Danny Thorpe To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=001a11487d6c7a32460526c9d991 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 X-Mailman-Approved-At: Sun, 13 Dec 2015 17:12:52 +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, 13 Dec 2015 16:14:26 -0000 --001a11487d6c7a32460526c9d991 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What is the current behavior / cost that this proposal is trying to avoid? Are ancient utxos required to be kept in memory always in a fully validating node, or can ancient utxos get pushed out of memory like a normal LRU caching db? Thanks, -Danny On Dec 12, 2015 1:55 PM, "jl2012--- via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > It is a common practice in commercial banks that a dormant account might > 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 my 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 blo= ck > 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 ha= sh > 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 branch > will become 1. If all dormant UTXOs in a block are spent, the record for > 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 fundamenta= l > 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 > --001a11487d6c7a32460526c9d991 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

What is the current behavior / cost that this proposal is tr= ying to avoid? Are ancient utxos required to be kept in memory always in a = fully validating node, or can ancient utxos get pushed out of memory like a= normal LRU caching db?

Thanks,
-Danny

On Dec 12, 2015 1:55 PM, "jl2012--- via bit= coin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
It is a common practice in commercial ban= ks that a dormant account might be confiscated. Confiscating or deleting do= rmant UTXOs might be too controversial, but allowing the UTXOs set growing = without any limit might not be a sustainable option. People lose their priv= ate keys. People do stupid things like sending bitcoin to 1BitcoinEater. We= shouldn=E2=80=99t be obliged to store everything permanently. This is my p= roposal:

Dormant UTXOs are those UTXOs with 420000 confirmations. In every block X a= fter 420000, it will commit to a hash for all UTXOs generated in block X-42= 0000. The UTXOs are first serialized into the form: txid|index|value|script= PubKey, 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, th= ey 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 bloc= k 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&quo= t;)

If all dormant UTXOs under a Merkle branch are spent, hash of the branch wi= ll become 1. If all dormant UTXOs in a block are spent, the record for this= block could be forgotten. Full nodes do not need to remember which particu= lar 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 blockchai= n for the current status of the UTXO commitment for their coin. They may al= so 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 wi= tness, just by replacing "witness" with "scriptSig"

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--001a11487d6c7a32460526c9d991--