{"type":"rich","version":"1.0","author_name":"npub18df3zgqr9zt5ah42zpd34rmq6fp7v57vvwmtk20krhrfdczp38ks5xccej","author_url":"https://nostr.ae/npub18df3zgqr9zt5ah42zpd34rmq6fp7v57vvwmtk20krhrfdczp38ks5xccej","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-13\n📝 Original message:I don't like this scheme at all. It doesn't seem to make bitcoin\nbetter, it makes it worse.\n\nLets say it's 2050 and I want to sweep a paper wallet I created in\n2013. I can't just make the TX and send it to the network, I have to\nfirst contact an \"archive node\" to get the UTXO data in order to make\nthe TX. How is this better than how the system works today?\n\nSince many people are going to be holding BTC long term (store of\nvalue of a first-class feature of bitcoin), this scheme is going to\neffect pretty much all users.\n\nThese archive nodes will be essential to network's operation. If there\nare no running archive nodes, the effect on the network is the same as\nthe network today without any full nodes.\n\nAnyways, UTXO size is a function of number of users, rather than a\nfunction of time. If tons of people join the network, UTXO still will\nincrease no matter what. All this change is going to do is make it\nharder for people to use bitcoin. A person can still generate 1GB of\nUTXO data, but as long as they spend those UTXOs within the amount\nthey are still using those resources.\n\nIMO, wildcard inputs is still the best way to limit the UTXO set.\n\n\nOn 12/12/15, Gregory Maxwell via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e have run a node/kept their utxo before they were aware of this change and\n\u003e\u003e then realise miners have discarded their utxo. Oops?\n\u003e\n\u003e I believe you have misunderstood jl2012's post.  His post does not\n\u003e cause the outputs to become discarded. They are still spendable,\n\u003e but the transactions must carry a membership proof to spend them.\n\u003e They don't have to have stored the data themselves, but they must\n\u003e get it from somewhere-- including archive nodes that serve this\n\u003e purpose rather than having every full node carry all that data forever.\n\u003e\n\u003e Please be conservative with the send button. The list loses its\n\u003e utility if every moderately complex idea is hit with reflexive\n\u003e opposition by people who don't understand it.\n\u003e\n\u003e Peter Todd has proposed something fairly similar with \"STXO\n\u003e commitments\". The primary argument against this kind of approach that\n\u003e I'm aware of is that the membership proofs get pretty big, and if too\n\u003e aggressive this trades bandwidth for storage, and storage is usually\n\u003e the cheaper resource. Though at least the membership proofs could be\n\u003e omitted when transmitting to a node which has signaled that it has\n\u003e kept the historical data anyways.\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"}