📅 Original date posted:2015-12-13
📝 Original message: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 at 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’t 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 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 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 fundamental
> assumption in Bitcoin anyway. The proposal also works without segregated
> witness, just by replacing "witness" with "scriptSig"
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151213/5df532a2/attachment.html>;
Danny Thorpe [ARCHIVE] /
npub1q5…3ps87
2023-06-07 17:46:17
in reply to nevent1q…yxw7
Author Public Key
npub1q5sgcakfxhw3ya93tvnpqeacvf32p6lw70hke53rkjnf9lhw9w8s43ps87Published at
2023-06-07 17:46:17Event JSON
{
"id": "a585579a861bd673291ad3aef07f25807a4fdd526ba565eaf2eae82b1684b162",
"pubkey": "05208c76c935dd1274b15b261067b86262a0ebeef3ef6cd223b4a692feee2b8f",
"created_at": 1686159977,
"kind": 1,
"tags": [
[
"e",
"3a132d93c9c4c5dfbfb11ddb31dd151bd41288218a2dab2ec24f273a7cf079bf",
"",
"root"
],
[
"e",
"31cac3fa3382bdfc6f868b403709c7050708eae3b87709ee3aae6ce956c2d4d3",
"",
"reply"
],
[
"p",
"dc329a02c970aabf03b87185ef51c86afe4586fe3a148508af898af3fabc56a3"
]
],
"content": "📅 Original date posted:2015-12-13\n📝 Original message:What is the current behavior / cost that this proposal is trying to avoid?\nAre ancient utxos required to be kept in memory always in a fully\nvalidating node, or can ancient utxos get pushed out of memory like a\nnormal LRU caching db?\n\nThanks,\n-Danny\nOn Dec 12, 2015 1:55 PM, \"jl2012--- via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e It is a common practice in commercial banks that a dormant account might\n\u003e be confiscated. Confiscating or deleting dormant UTXOs might be too\n\u003e controversial, but allowing the UTXOs set growing without any limit might\n\u003e not be a sustainable option. People lose their private keys. People do\n\u003e stupid things like sending bitcoin to 1BitcoinEater. We shouldn’t be\n\u003e obliged to store everything permanently. This is my proposal:\n\u003e\n\u003e Dormant UTXOs are those UTXOs with 420000 confirmations. In every block X\n\u003e after 420000, it will commit to a hash for all UTXOs generated in block\n\u003e X-420000. The UTXOs are first serialized into the form:\n\u003e txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.\n\u003e After some confirmations, nodes may safely delete the UTXO records of block\n\u003e X permanently.\n\u003e\n\u003e If a user is trying to redeem a dormant UTXO, in addition the signature,\n\u003e they have to provide the scriptPubKey, height (X), and UTXO value as part\n\u003e of the witness. They also need to provide the Merkle path to the dormant\n\u003e UTXO commitment.\n\u003e\n\u003e To confirm this tx, the miner will calculate a new Merkle hash for the\n\u003e block X, with the hash of the spent UTXO replaced by 1, and commit the hash\n\u003e to the current block. All full nodes will keep an index of latest dormant\n\u003e UTXO commitments so double spending is not possible. (a \"meta-UTXO set\")\n\u003e\n\u003e If all dormant UTXOs under a Merkle branch are spent, hash of the branch\n\u003e will become 1. If all dormant UTXOs in a block are spent, the record for\n\u003e this block could be forgotten. Full nodes do not need to remember which\n\u003e particular UTXO is spent or not, since any person trying to redeem a\n\u003e dormant UTXO has to provide such information.\n\u003e\n\u003e It becomes the responsibility of dormant coin holders to scan the\n\u003e blockchain for the current status of the UTXO commitment for their coin.\n\u003e They may also need to pay extra fee for the increased tx size.\n\u003e\n\u003e This is a softfork if there is no hash collision but this is a fundamental\n\u003e assumption in Bitcoin anyway. The proposal also works without segregated\n\u003e witness, just by replacing \"witness\" with \"scriptSig\"\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151213/5df532a2/attachment.html\u003e",
"sig": "d8beeab83b4310f8ffbf3fad64c3eac083a15b89aaf6a13577b54cddf5572e368f34b3abffeda727b0933070be3b7bc9ce374db294163fd2c95e0a1cb08dfd68"
}