{"type":"rich","version":"1.0","author_name":"npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452","author_url":"https://nostr.ae/npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-07-17\n📝 Original message:Hi Wendell,\n\nWhat Peter describes (a hash of the current set of UTXOs as part of the coinbase) is already implemented in libcoin, on which you can easily build both a bitcoind and any client. Libcoin is a library originally based on the satoshi client, and as such it is compatible/replacable with \"master\". \n\nHave a look at github.com/libcoin/libcoin and look in the BlockChain.h/cpp and the MerkleTrie classes then you can see how it works.\n\nWhat is missing from libcoin is a scheme to bootstrap the hash of UTXOs, there is some stub code for a p2pool like mining scheme ensuring several UTXO hashes every 10 minutes, but I will not have time to finalize it the first few months - anyone are of course welcome to help out ;)\n\nMichael\n\n\nOn 17/07/2013, at 09:37, Wendell \u003cw at grabhive.com\u003e wrote:\n\n\u003e Peter,\n\u003e \n\u003e This sounds like a _very_ good idea for a desktop client, and probably acceptable to users so long as we take available disk space into consideration, and only ever use a fraction of it.\n\u003e \n\u003e Will you implement this?\n\u003e \n\u003e -wendell\n\u003e \n\u003e grabhive.com | twitter.com/grabhive\n\u003e \n\u003e On Jul 17, 2013, at 12:58 PM, Peter Todd wrote:\n\u003e \n\u003e\u003e So what's useful about that? Basically it means your node starts with\n\u003e\u003e the same security level, and usefulness to the network, as a SPV node.\n\u003e\u003e But over time you keep downloading blocks as they are created, and with\n\u003e\u003e whatever bandwidth you have left (out of some user-configurable\n\u003e\u003e allocation) you download additional blocks going further and further\n\u003e\u003e back in time. Gradually your UTXO set becomes more complete, and over\n\u003e\u003e time you can verify a higher and higher % of all valid transactions.\n\u003e\u003e Eventually your node becomes a full node, but in the meantime it was\n\u003e\u003e still useful for the user, and still contributed to the network by\n\u003e\u003e relaying blocks and an increasingly large subset of all transactions.\n\u003e\u003e (optionally you can store a subset of the chain history too for other\n\u003e\u003e nodes to bootstrap from) You've also got better security because you\n\u003e\u003e *are* validating blocks, starting off incompletely, and increasingly\n\u003e\u003e completely until your finally validating fully. Privacy is improved, for\n\u003e\u003e both you and others, by mixing your transactions with others and adding\n\u003e\u003e to the overall anonymity set.\n\u003e\u003e \n\u003e\u003e In the future we'll have miners commit a hash of the UTXO set, and that\n\u003e\u003e gives us even more options to, for instance, have relayed transactions\n\u003e\u003e include proof that their inputs were valid, allowing all nodes to relay\n\u003e\u003e them safely.\n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e See everything from the browser to the database with AppDynamics\n\u003e Get end-to-end visibility with application monitoring from AppDynamics\n\u003e Isolate bottlenecks and diagnose root cause in seconds.\n\u003e Start your free trial of AppDynamics Pro today!\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=48808831\u0026iu=/4140/ostg.clktrk_______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130717/d6c0fe64/attachment.sig\u003e"}