* [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin @ 2015-12-12 20:09 jl2012 2015-12-12 23:01 ` gb 2015-12-13 16:14 ` Danny Thorpe 0 siblings, 2 replies; 19+ messages in thread From: jl2012 @ 2015-12-12 20:09 UTC (permalink / raw) To: bitcoin-dev 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" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-12 20:09 [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin jl2012 @ 2015-12-12 23:01 ` gb 2015-12-13 1:00 ` Vincent Truong 2015-12-13 16:14 ` Danny Thorpe 1 sibling, 1 reply; 19+ messages in thread From: gb @ 2015-12-12 23:01 UTC (permalink / raw) To: jl2012; +Cc: bitcoin-dev 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 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@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-12 23:01 ` gb @ 2015-12-13 1:00 ` Vincent Truong 2015-12-13 2:07 ` Gregory Maxwell 0 siblings, 1 reply; 19+ messages in thread From: Vincent Truong @ 2015-12-13 1:00 UTC (permalink / raw) To: gb; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4653 bytes --] 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 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@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 > [-- Attachment #2: Type: text/html, Size: 5602 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-13 1:00 ` Vincent Truong @ 2015-12-13 2:07 ` Gregory Maxwell 2015-12-13 8:13 ` Chris Priest 2015-12-20 11:24 ` Peter Todd 0 siblings, 2 replies; 19+ messages in thread From: Gregory Maxwell @ 2015-12-13 2:07 UTC (permalink / raw) To: Vincent Truong; +Cc: Bitcoin Dev On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > have run a node/kept their utxo before they were aware of this change and > then realise miners have discarded their utxo. Oops? I believe you have misunderstood jl2012's post. His post does not cause the outputs to become discarded. They are still spendable, but the transactions must carry a membership proof to spend them. They don't have to have stored the data themselves, but they must get it from somewhere-- including archive nodes that serve this purpose rather than having every full node carry all that data forever. Please be conservative with the send button. The list loses its utility if every moderately complex idea is hit with reflexive opposition by people who don't understand it. Peter Todd has proposed something fairly similar with "STXO commitments". The primary argument against this kind of approach that I'm aware of is that the membership proofs get pretty big, and if too aggressive this trades bandwidth for storage, and storage is usually the cheaper resource. Though at least the membership proofs could be omitted when transmitting to a node which has signaled that it has kept the historical data anyways. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-13 2:07 ` Gregory Maxwell @ 2015-12-13 8:13 ` Chris Priest 2015-12-13 8:18 ` Gregory Maxwell 2015-12-20 11:24 ` Peter Todd 1 sibling, 1 reply; 19+ messages in thread From: Chris Priest @ 2015-12-13 8:13 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev I don't like this scheme at all. It doesn't seem to make bitcoin better, it makes it worse. Lets say it's 2050 and I want to sweep a paper wallet I created in 2013. I can't just make the TX and send it to the network, I have to first contact an "archive node" to get the UTXO data in order to make the TX. How is this better than how the system works today? Since many people are going to be holding BTC long term (store of value of a first-class feature of bitcoin), this scheme is going to effect pretty much all users. These archive nodes will be essential to network's operation. If there are no running archive nodes, the effect on the network is the same as the network today without any full nodes. Anyways, UTXO size is a function of number of users, rather than a function of time. If tons of people join the network, UTXO still will increase no matter what. All this change is going to do is make it harder for people to use bitcoin. A person can still generate 1GB of UTXO data, but as long as they spend those UTXOs within the amount they are still using those resources. IMO, wildcard inputs is still the best way to limit the UTXO set. On 12/12/15, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> have run a node/kept their utxo before they were aware of this change and >> then realise miners have discarded their utxo. Oops? > > I believe you have misunderstood jl2012's post. His post does not > cause the outputs to become discarded. They are still spendable, > but the transactions must carry a membership proof to spend them. > They don't have to have stored the data themselves, but they must > get it from somewhere-- including archive nodes that serve this > purpose rather than having every full node carry all that data forever. > > Please be conservative with the send button. The list loses its > utility if every moderately complex idea is hit with reflexive > opposition by people who don't understand it. > > Peter Todd has proposed something fairly similar with "STXO > commitments". The primary argument against this kind of approach that > I'm aware of is that the membership proofs get pretty big, and if too > aggressive this trades bandwidth for storage, and storage is usually > the cheaper resource. Though at least the membership proofs could be > omitted when transmitting to a node which has signaled that it has > kept the historical data anyways. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-13 8:13 ` Chris Priest @ 2015-12-13 8:18 ` Gregory Maxwell 2015-12-13 9:17 ` Chris Priest 0 siblings, 1 reply; 19+ messages in thread From: Gregory Maxwell @ 2015-12-13 8:18 UTC (permalink / raw) To: Chris Priest; +Cc: Bitcoin Dev On Sun, Dec 13, 2015 at 8:13 AM, Chris Priest <cp368202@ohiou•edu> wrote: > Lets say it's 2050 and I want to sweep a paper wallet I created in > 2013. I can't just make the TX and send it to the network, I have to > first contact an "archive node" to get the UTXO data in order to make > the TX. How is this better than how the system works today? You already are in that boat. If your paper wallet has only the private key (as 100% of them do today). You'll have no idea what coins have been assigned to it, or what their TXids are. You'll need to contact a public index (which isn't a service existing nodes provide) or synchronize the full blockchain history to find it. Both are also sufficient for jl2012's (/Petertodd's STXO), they'd only be providing you with somewhat more data. If instead, you insist that you'd already be running a full node and not have to wait for the sync, then again you'd also be your own archive. In none of these cases do you lose anything. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 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 0 siblings, 2 replies; 19+ messages in thread From: Chris Priest @ 2015-12-13 9:17 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev > In none of these cases do you lose anything. Nor do you gain anything. Archive nodes will still need to exist precisely because paper wallets don't include UTXO data. This is like adding the ability to partially seed a movie with bittorrent. You still need someone who has the whole thing has to be participating in order for anyone to play the movie. This isn't going to kill bitcoin, but it won't make it any better. Every paper wallet would have to be re-printed with UTXO data included. It doesn't even solve the core problem because someone can still flood the network with lots of UTXOs, as long as they spend them quickly. On 12/13/15, Gregory Maxwell <greg@xiph•org> wrote: > On Sun, Dec 13, 2015 at 8:13 AM, Chris Priest <cp368202@ohiou•edu> wrote: >> Lets say it's 2050 and I want to sweep a paper wallet I created in >> 2013. I can't just make the TX and send it to the network, I have to >> first contact an "archive node" to get the UTXO data in order to make >> the TX. How is this better than how the system works today? > > You already are in that boat. If your paper wallet has only the > private key (as 100% of them do today). You'll have no idea what coins > have been assigned to it, or what their TXids are. You'll need to > contact a public index (which isn't a service existing nodes provide) > or synchronize the full blockchain history to find it. Both are also > sufficient for jl2012's (/Petertodd's STXO), they'd only be providing > you with somewhat more data. If instead, you insist that you'd > already be running a full node and not have to wait for the sync, then > again you'd also be your own archive. In none of these cases do you > lose anything. > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-13 9:17 ` Chris Priest @ 2015-12-13 9:24 ` Gregory Maxwell 2015-12-13 18:11 ` jl2012 1 sibling, 0 replies; 19+ messages in thread From: Gregory Maxwell @ 2015-12-13 9:24 UTC (permalink / raw) To: Chris Priest; +Cc: Bitcoin Dev On Sun, Dec 13, 2015 at 9:17 AM, Chris Priest <cp368202@ohiou•edu> wrote: >> In none of these cases do you lose anything. > > Nor do you gain anything. Archive nodes will still need to exist Not every node is an archive node; that's even the case today. Lowering the resource requirements to independently enforce the rules of the system is highly virtuous. > precisely because paper wallets don't include UTXO data. This is like > adding the ability to partially seed a movie with bittorrent. [...] > Every paper wallet would have to be re-printed with UTXO data They are not printed now with UTXO data (txid:vout:scriptpubkey:amount), and unless you start and fully synchronize (or are running a full node) you already cannot author a transaction without that data. The private key is already not enough, and no Bitcoin node will just give you what you need to know. The only additional information JL2012's scheme would add would be the hash tree fragments to show membership; and the same places that currently give you what is required to author a transaction could provide it for you. > included. It doesn't even solve the core problem because someone can > still flood the network with lots of UTXOs, as long as they spend them > quickly. The system already inhibits the rate new UTXO can be added; but we're still left with the perpetually growing history that contains many lost and otherwise unspendable outputs. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 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 1 sibling, 2 replies; 19+ messages in thread From: jl2012 @ 2015-12-13 18:11 UTC (permalink / raw) To: Chris Priest; +Cc: Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe <danny.thorpe@gmail•com> wrote: > 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? I don't see why it must be kept in memory. But storage is still a problem. With the 8 year limit and a fixed max block size, it indirectly sets an upper limit for UTXO set. Chris Priest via bitcoin-dev : > This isn't going to kill bitcoin, but it won't make it any better. Do you believe that thousands of volunteer full nodes are obliged to store an UTXO record, just because one paid US$0.01 to an anonymous miner 100 years ago? It sounds insanely cheap, isn't it? My proposal (or similar proposal by Peter Todd) is to solve this problem. Many commercial banks have a dormant threshold less than 8 years so I believe it is a balanced choice. Back to the topic, I would like to further elaborate my proposal. We have 3 types of full nodes: Archive nodes: full nodes that store the whole blockchain Full UTXO nodes: full nodes that fully store the latest UTXO state, but not the raw blockchain Lite UTXO nodes: full nodes that store only UTXO created in that past 420000 blocks Currently, if one holds nothing but a private key, he must consult either an archive node or a full UTXO node for the latest UTXO state to spend his coin. We currently do not have any lite UTXO node, and such node would not work properly beyond block 420000. With the softfork I described in my original post, if the UTXO is created within the last 420000 blocks, the key holder may consult any type of full node, including a lite UTXO node, to create the transaction. If the UTXO has been confirmed by more than 420000 blocks, a lite UTXO node obviously can't provide the necessary information to spend the coin. However, not even a full UTXO node may do so. A full UTXO node could tell the position of the UTXO in the blockchain, but can't provide all the information required by my specification. Only an archive node may do so. What extra information is needed? (1) If your UTXO was generated in block Y, you first need to know the TXO state (spent / unspent) of all outputs in block Y at block (Y + 420000). Only UTXOs at that time are relevant. (2) You also need to know if there was any spending of any block Y UTXOs after block (Y + 420000). It is not possible to construct the membership prove I require without these information. It is designed this way, so that lite UTXO nodes won't need to store any dormant UTXO records: not even the hash of individual dormant UTXO records. If the blockchain grows to insanely big, it may take days or weeks to retrieve to records. However, I don't think this is relevant as one has already left his coins dormant for >8 years. Actually, you don't even need the full blockchain. For (1), all you need is the 420000 blocks from Y to Y+420000 minus any witness data, as you don't need to do any validation. For (2), you just need the coinbase of Y+420001 to present, where any spending would have been committed, and retrieve the full block only if a spending is found. So the Bitcoin Bank (miners) is not going to shred your record and confiscate your money. Instead, the Bank throws your record to the garage (raw blockchain). You can search for your record by yourself, or employ someone (archive node) to search it for you. In any case it incurs costs. But as thousands of bankers have kept your record on their limited desk space for 8 years for free (though one of them might receive a fraction of a penny from you), you shouldn't complain with any moral, technical, or legal reason. And no matter what users say, I believe something like this will happen when miners and full nodes can't handle the UTXO set. I'd like to see more efficient proposals that archive the same goals. p.s. there were some typos in my original. The second sentence of the second paragraph should be read as "For every block X+420000, it will commit to a hash for all UTXOs generated in block X." -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJWbbR2AAoJEO6eVSA0viTScEoL/RPlsxr0A5wTtgdi+9i4AFlV Sw/He89+YPGe5VCG74YNAPLEUF1/rICzUJ4DulvNTOo/5xtmkv5ok4bD7v1JZnH3 DE2PExMQYs2X4Qm6mkcwi8IWlMR2U5j5ebUq21Kj4AqVFj9UcQmYGhPehB2f+cM9 Wki/TDwNj5fV8AZ4uR9pPgaf+bvVQQ9BOOLiIMiTbphNCx1hfGfYcsqmXlCbGk9A PatGR88aQTxpa7PhbCZwwf76cKuOaYYZeHr9jRR9RL5rZVXgE1SI/niBytJhXaP8 lwYtk4Bpz0IGd23v1dArNQQoOp5Xycbeq1l1qyv/qtxju65No+dhqiEcFBZVI1AS VcndMQ+yvNuxVgib2Ifh9YjXelWAqqLzzoVcz2RxXh6HJ0tVKxBokwdAcsclZb93 zQ1JhDR4vBpLquytZA8lDIxJraNCdB/KEAOAey6ljP3zL7fBLBp1oZw4DDDtFy8V EMjrOSVnjyuyfey2YXsGnnHuQS0mpwmSroV2400uGQ== =2xRy -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-13 18:11 ` jl2012 @ 2015-12-13 21:20 ` Ricardo Filipe 2015-12-13 21:36 ` Tier Nolan 1 sibling, 0 replies; 19+ messages in thread From: Ricardo Filipe @ 2015-12-13 21:20 UTC (permalink / raw) To: jl2012; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5766 bytes --] I really like ideas that tackle this issue. The question imho is what is the incentive to run a "Full UTXO node" instead of a pruned or archive node. For starters, it would be nice to know what would be the savings for Full UTXO nodes over archive nodes right now. Also, what advantages would this have over "archive pruned nodes: nodes that store X blocks of the whole blockchain before 420000". Seems like an interesting intermediate use case to me too. 2015-12-13 18:11 GMT+00:00 jl2012--- via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe <danny.thorpe@gmail•com> > wrote: > >> 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? >> > > I don't see why it must be kept in memory. But storage is still a problem. > With the 8 year limit and a fixed max block size, it indirectly sets an > upper limit for UTXO set. > > > Chris Priest via bitcoin-dev : > >> This isn't going to kill bitcoin, but it won't make it any better. >> > > Do you believe that thousands of volunteer full nodes are obliged to store > an UTXO record, just because one paid US$0.01 to an anonymous miner 100 > years ago? It sounds insanely cheap, isn't it? My proposal (or similar > proposal by Peter Todd) is to solve this problem. Many commercial banks > have a dormant threshold less than 8 years so I believe it is a balanced > choice. > > Back to the topic, I would like to further elaborate my proposal. > > We have 3 types of full nodes: > > Archive nodes: full nodes that store the whole blockchain > Full UTXO nodes: full nodes that fully store the latest UTXO state, but > not the raw blockchain > Lite UTXO nodes: full nodes that store only UTXO created in that past > 420000 blocks > > Currently, if one holds nothing but a private key, he must consult either > an archive node or a full UTXO node for the latest UTXO state to spend his > coin. We currently do not have any lite UTXO node, and such node would not > work properly beyond block 420000. > > With the softfork I described in my original post, if the UTXO is created > within the last 420000 blocks, the key holder may consult any type of full > node, including a lite UTXO node, to create the transaction. > > If the UTXO has been confirmed by more than 420000 blocks, a lite UTXO > node obviously can't provide the necessary information to spend the coin. > However, not even a full UTXO node may do so. A full UTXO node could tell > the position of the UTXO in the blockchain, but can't provide all the > information required by my specification. Only an archive node may do so. > > What extra information is needed? > > (1) If your UTXO was generated in block Y, you first need to know the TXO > state (spent / unspent) of all outputs in block Y at block (Y + 420000). > Only UTXOs at that time are relevant. > > (2) You also need to know if there was any spending of any block Y UTXOs > after block (Y + 420000). > > It is not possible to construct the membership prove I require without > these information. It is designed this way, so that lite UTXO nodes won't > need to store any dormant UTXO records: not even the hash of individual > dormant UTXO records. If the blockchain grows to insanely big, it may take > days or weeks to retrieve to records. However, I don't think this is > relevant as one has already left his coins dormant for >8 years. Actually, > you don't even need the full blockchain. For (1), all you need is the > 420000 blocks from Y to Y+420000 minus any witness data, as you don't need > to do any validation. For (2), you just need the coinbase of Y+420001 to > present, where any spending would have been committed, and retrieve the > full block only if a spending is found. > > So the Bitcoin Bank (miners) is not going to shred your record and > confiscate your money. Instead, the Bank throws your record to the garage > (raw blockchain). You can search for your record by yourself, or employ > someone (archive node) to search it for you. In any case it incurs costs. > But as thousands of bankers have kept your record on their limited desk > space for 8 years for free (though one of them might receive a fraction of > a penny from you), you shouldn't complain with any moral, technical, or > legal reason. And no matter what users say, I believe something like this > will happen when miners and full nodes can't handle the UTXO set. > > I'd like to see more efficient proposals that archive the same goals. > > p.s. there were some typos in my original. The second sentence of the > second paragraph should be read as "For every block X+420000, it will > commit to a hash for all UTXOs generated in block X." > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQGcBAEBCAAGBQJWbbR2AAoJEO6eVSA0viTScEoL/RPlsxr0A5wTtgdi+9i4AFlV > Sw/He89+YPGe5VCG74YNAPLEUF1/rICzUJ4DulvNTOo/5xtmkv5ok4bD7v1JZnH3 > DE2PExMQYs2X4Qm6mkcwi8IWlMR2U5j5ebUq21Kj4AqVFj9UcQmYGhPehB2f+cM9 > Wki/TDwNj5fV8AZ4uR9pPgaf+bvVQQ9BOOLiIMiTbphNCx1hfGfYcsqmXlCbGk9A > PatGR88aQTxpa7PhbCZwwf76cKuOaYYZeHr9jRR9RL5rZVXgE1SI/niBytJhXaP8 > lwYtk4Bpz0IGd23v1dArNQQoOp5Xycbeq1l1qyv/qtxju65No+dhqiEcFBZVI1AS > VcndMQ+yvNuxVgib2Ifh9YjXelWAqqLzzoVcz2RxXh6HJ0tVKxBokwdAcsclZb93 > zQ1JhDR4vBpLquytZA8lDIxJraNCdB/KEAOAey6ljP3zL7fBLBp1oZw4DDDtFy8V > EMjrOSVnjyuyfey2YXsGnnHuQS0mpwmSroV2400uGQ== > =2xRy > -----END PGP SIGNATURE----- > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 7069 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-13 18:11 ` jl2012 2015-12-13 21:20 ` Ricardo Filipe @ 2015-12-13 21:36 ` Tier Nolan 1 sibling, 0 replies; 19+ messages in thread From: Tier Nolan @ 2015-12-13 21:36 UTC (permalink / raw) Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2043 bytes --] On Sun, Dec 13, 2015 at 6:11 PM, jl2012--- via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Back to the topic, I would like to further elaborate my proposal. > > We have 3 types of full nodes: > > Archive nodes: full nodes that store the whole blockchain > Full UTXO nodes: full nodes that fully store the latest UTXO state, but > not the raw blockchain > Lite UTXO nodes: full nodes that store only UTXO created in that past > 420000 blocks > There is a risk that miners would eventually react by just refusing to accept blocks that spend dormant outputs. This is a risk even without the protocol, but I think if there are already lots of UTXO-lite nodes deployed, it would be much easier to just define them as the new (soft-forked) consensus rule. There is a precedent for things to be disabled rather than fixed when security problems arise. Imagine a crisis caused by a security related bug with the revival proofs. Disabling them is much lower risk than trying to find/fix the bug and then deploy the fix. The longer it takes, the longer the security problem remains. > > What extra information is needed? > > (1) If your UTXO was generated in block Y, you first need to know the TXO > state (spent / unspent) of all outputs in block Y at block (Y + 420000). > Only UTXOs at that time are relevant. > > (2) You also need to know if there was any spending of any block Y UTXOs > after block (Y + 420000). > Is this how it works? Source transaction is included in block Y. If the output is spent before Y + 420,000, then no further action is taken. The miner for block Y + 420,000 will include a commitment to merkle_hash(Block Y's unspent outputs). It is possible for someone to prove that they didn't spend their transaction before Y + 420,000. I think the miners have to remember the "live" UTXO merkle root for every block? With the path to the UTXO and the miner can recalculate the root for that block. If there were 20 dormant outputs being spent, then the miner would have to commit to 20 updates. [-- Attachment #2: Type: text/html, Size: 2760 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-13 2:07 ` Gregory Maxwell 2015-12-13 8:13 ` Chris Priest @ 2015-12-20 11:24 ` Peter Todd 2015-12-20 11:34 ` Jeff Garzik 1 sibling, 1 reply; 19+ messages in thread From: Peter Todd @ 2015-12-20 11:24 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2364 bytes --] On Sun, Dec 13, 2015 at 02:07:36AM +0000, Gregory Maxwell via bitcoin-dev wrote: > On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > have run a node/kept their utxo before they were aware of this change and > > then realise miners have discarded their utxo. Oops? > > I believe you have misunderstood jl2012's post. His post does not > cause the outputs to become discarded. They are still spendable, > but the transactions must carry a membership proof to spend them. > They don't have to have stored the data themselves, but they must > get it from somewhere-- including archive nodes that serve this > purpose rather than having every full node carry all that data forever. > > Please be conservative with the send button. The list loses its > utility if every moderately complex idea is hit with reflexive > opposition by people who don't understand it. > > Peter Todd has proposed something fairly similar with "STXO > commitments". The primary argument against this kind of approach that That's incorrect terminology - what I proposed are "TXO commitments". I proposed that a MMR of all prior transaction outputs's, spent and unspent, be committed too in blocks along with a spentness flag, not just spent transaction outputs. That's why I often use the term (U)TXO commitments to refer to both classes of proposals. > I'm aware of is that the membership proofs get pretty big, and if too > aggressive this trades bandwidth for storage, and storage is usually > the cheaper resource. Though at least the membership proofs could be > omitted when transmitting to a node which has signaled that it has > kept the historical data anyways. 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. The proofs are relatively large, but not so much larger than a CTxIn as to make paying for that data infeasible. -- 'peter'[:-1]@petertodd.org 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-20 11:24 ` Peter Todd @ 2015-12-20 11:34 ` Jeff Garzik 2015-12-20 11:43 ` s7r ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Jeff Garzik @ 2015-12-20 11:34 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 990 bytes --] On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev < 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" [-- Attachment #2: Type: text/html, Size: 1670 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-20 11:34 ` Jeff Garzik @ 2015-12-20 11:43 ` s7r 2015-12-20 16:30 ` Chris Pacia 2015-12-21 3:23 ` Tom Harding 2 siblings, 0 replies; 19+ messages in thread From: s7r @ 2015-12-20 11:43 UTC (permalink / raw) To: Jeff Garzik, Peter Todd; +Cc: Bitcoin Dev 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" > > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-20 11:34 ` Jeff Garzik 2015-12-20 11:43 ` s7r @ 2015-12-20 16:30 ` Chris Pacia 2015-12-20 16:35 ` Peter Todd 2015-12-21 3:23 ` Tom Harding 2 siblings, 1 reply; 19+ messages in thread From: Chris Pacia @ 2015-12-20 16:30 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 391 bytes --] On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > 2) This reverses the useful minimization attribute of HD wallets - "just backup the seed" It would be nice if the bip37 filter matching algorithm was extended to serve up the proof. And if server-based wallets did the same it would preserve the "just backup the seed" functionality. [-- Attachment #2: Type: text/html, Size: 565 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-20 16:30 ` Chris Pacia @ 2015-12-20 16:35 ` Peter Todd 2015-12-21 3:34 ` Jeff Garzik 0 siblings, 1 reply; 19+ messages in thread From: Peter Todd @ 2015-12-20 16:35 UTC (permalink / raw) To: Chris Pacia, Jeff Garzik; +Cc: bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia <ctpacia@gmail•com> wrote: >On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" < >bitcoin-dev@lists•linuxfoundation.org> wrote: > >> 2) This reverses the useful minimization attribute of HD wallets - >"just >backup the seed" > >It would be nice if the bip37 filter matching algorithm was extended to >serve up the proof. > >And if server-based wallets did the same it would preserve the "just >backup >the seed" functionality. Exactly! The information will be out there - "just backup the seed" requires someone to have the exact same data needed to generate the TXO-unspent proof that my proposal requires to spend an old txout. tl;dr: jgarzik is incorrect; theres no difference at all from the status quo. -----BEGIN PGP SIGNATURE----- iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWdtjA AAoJEMCF8hzn9Lncz4MH/iwwa7xlbrJJiYqe7Hccr3Vm5D/qbv60eYi2btPDHFo9 mRnijzqFtt60e1AoFr9NwnCrAhhGmYkWsxLcA2oF+38H12DS9qsb9oT+pckJX34V v06+Uap89v9VTHcxVrOEQUCx+9xQO7WkpFw/OTZJA4nmFZ8lvbgDGWE9q7mjQKof QU1FiOM7mI6QCU8xTjRvVX5pTwvYNB7PAie/UoCfWU7/QdvsgTHRe4pq0XwJqHKy xCr0DbfMZ2TvLFXitS5ZgTbDHURljjHlE7Qdmk9AcFNpI0PCR9YrZ5Mgb10sMygr kX3V3uzjx2YBjKEpX9fqk6Kf/aufUqQ1PRBHF3m6bSE= =mtj/ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-20 16:35 ` Peter Todd @ 2015-12-21 3:34 ` Jeff Garzik 0 siblings, 0 replies; 19+ messages in thread From: Jeff Garzik @ 2015-12-21 3:34 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 1266 bytes --] On Sun, Dec 20, 2015 at 11:35 AM, Peter Todd <pete@petertodd•org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia <ctpacia@gmail•com> > wrote: > >On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" < > >bitcoin-dev@lists•linuxfoundation.org> wrote: > > > >> 2) This reverses the useful minimization attribute of HD wallets - > >"just > >backup the seed" > > > >It would be nice if the bip37 filter matching algorithm was extended to > >serve up the proof. > > > >And if server-based wallets did the same it would preserve the "just > >backup > >the seed" functionality. > > Exactly! The information will be out there - "just backup the seed" > requires someone to have the exact same data needed to generate the > TXO-unspent proof that my proposal requires to spend an old txout. > > tl;dr: jgarzik is incorrect; theres no difference at all from the status > quo. > The data stored in the legacy case makes it possible to sign and send a transaction without any connection to a network. The data stored in the upgraded case, absent grandfathering, requires significant network sync at a minimum. The user experience and security parameters are different. Thus, issue/recommendation #1. [-- Attachment #2: Type: text/html, Size: 1951 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-20 11:34 ` Jeff Garzik 2015-12-20 11:43 ` s7r 2015-12-20 16:30 ` Chris Pacia @ 2015-12-21 3:23 ` Tom Harding 2 siblings, 0 replies; 19+ messages in thread From: Tom Harding @ 2015-12-21 3:23 UTC (permalink / raw) To: bitcoin-dev On 12/20/2015 3:34 AM, Jeff Garzik via bitcoin-dev wrote: > 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" Also, a change (#6550) has been merged to bitcoin core that removes merkle branches from the wallet, and if pruning gets turned on (possible in 0.12 with #6057), it would become quite a bit more difficult to spend older coins under a change like this. As a solution I would favor not removing wallet merkle branches. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 2015-12-12 20:09 [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin jl2012 2015-12-12 23:01 ` gb @ 2015-12-13 16:14 ` Danny Thorpe 1 sibling, 0 replies; 19+ messages in thread From: Danny Thorpe @ 2015-12-13 16:14 UTC (permalink / raw) To: jl2012; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2717 bytes --] 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’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@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3174 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2015-12-21 3:34 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-12-12 20:09 [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox