rich1.0npub1c56tk56u5846gc9tj6kcd886y9sztx6yrj24zhegrsv87qfs7nes834kvphttps://nostr.ae/npub1c56tk56u5846gc9tj6kcd886y9sztx6yrj24zhegrsv87qfs7nes834kvpnjumphttps://nostr.ae📅 Original date posted:2013-07-17 📝 Original message:Peter, 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. Will you implement this? -wendell grabhive.com | twitter.com/grabhive On Jul 17, 2013, at 12:58 PM, Peter Todd wrote: > So what's useful about that? Basically it means your node starts with > the same security level, and usefulness to the network, as a SPV node. > But over time you keep downloading blocks as they are created, and with > whatever bandwidth you have left (out of some user-configurable > allocation) you download additional blocks going further and further > back in time. Gradually your UTXO set becomes more complete, and over > time you can verify a higher and higher % of all valid transactions. > Eventually your node becomes a full node, but in the meantime it was > still useful for the user, and still contributed to the network by > relaying blocks and an increasingly large subset of all transactions. > (optionally you can store a subset of the chain history too for other > nodes to bootstrap from) You've also got better security because you > *are* validating blocks, starting off incompletely, and increasingly > completely until your finally validating fully. Privacy is improved, for > both you and others, by mixing your transactions with others and adding > to the overall anonymity set. > > In the future we'll have miners commit a hash of the UTXO set, and that > gives us even more options to, for instance, have relayed transactions > include proof that their inputs were valid, allowing all nodes to relay > them safely. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130717/e78aceae/attachment.sig>