{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-07-17\n📝 Original message:On Tue, Jul 16, 2013 at 04:16:23PM +0200, Wendell wrote:\n\u003e Hello everyone,\n\u003e \n\u003e In the previous thread, I expressed interest in seeing an SPV bitcoind, further stating that I would fund such work. Mike Hearn followed up with some of Satoshi's old code for this, which is now quite broken. The offer and interest on my side still stand, as more diversity in SPV options seems like the right way to go.\n\u003e \n\u003e Time-permitting, I would really appreciate feedback from knowledgable parties about the possible approaches to an SPV bitcoind. We at Hive ideally want to see something that could one be merge into master, rather than a fork.\n\nKeep in mind that SPV mode is newer than many realize: bloom filters are\na 0.8 feature, itself released only last Febuary. As John Dillon posted\nearlier this week in \"Protecting Bitcoin against network-wide DoS\nattack\" the Bitcoin codebase will have to implement much better anti-DoS\nattack defences soon, and in a decentralized system there aren't any\noptions other than requiring peers to either do work (useful or not) or\nsacrifice something of value. SPV peers can't do useful work, leaving\nonly sacrifice - to what extent and how much is unknown. In addition SPV\nnodes have serious privacy issues because their peers know that any\ntransaction sent to them by the SPV node is guaranteed to be from the\nnode rather than relayed; bloom filters are only really helpful with\npayment protocols that don't exist yet and don't apply to merchants.\nThen you have MITM problems, vulnerability to fake blocks etc.\n\nIt'll be awhile before we know how serious these issues are in practice,\nand we're likely to find new issues we didn't think of too. In any case\nBitcoin is far better off if we make it easy to run a full node,\ndonating whatever resources you can. Fortunately there's a whole\ncontinuum between SPV and full nodes.\n\nThe way you do this is by maintaining partial UTXO sets. The trick is\nthat if you have verified every block in some range i to j, every time\nyou see a txout created by a transaction, and not subsequently spent,\nyou can be sure that at height j the txout existed. If height j is the\ncurrent block, you can be sure the txout exists provided that the chain\nitself is valid. Any transaction that only spends txouts in this partial\nset is a transaction you can fully verify and safely relay; for other\ntransactions you just don't know and have to wait until you see them in\na block.\n\nSo what's useful about that? Basically it means your node starts with\nthe same security level, and usefulness to the network, as a SPV node.\nBut over time you keep downloading blocks as they are created, and with\nwhatever bandwidth you have left (out of some user-configurable\nallocation) you download additional blocks going further and further\nback in time. Gradually your UTXO set becomes more complete, and over\ntime you can verify a higher and higher % of all valid transactions.\nEventually your node becomes a full node, but in the meantime it was\nstill useful for the user, and still contributed to the network by\nrelaying blocks and an increasingly large subset of all transactions.\n(optionally you can store a subset of the chain history too for other\nnodes to bootstrap from) You've also got better security because you\n*are* validating blocks, starting off incompletely, and increasingly\ncompletely until your finally validating fully. Privacy is improved, for\nboth you and others, by mixing your transactions with others and adding\nto the overall anonymity set.\n\nIn the future we'll have miners commit a hash of the UTXO set, and that\ngives us even more options to, for instance, have relayed transactions\ninclude proof that their inputs were valid, allowing all nodes to relay\nthem safely.\n\n\nAs for specifics, you need to maintain a UTXO set, and in addition a set\nof spent txouts (the STXO set) for which you haven't seen the\ntransaction that created the txout. As download newer blocks you update\nthe UTXO set; as you download older blocks you update the UTXO set and\nSTXO set.\n\nNodes now advertise this new variable to their peers:\n\nnOldestBlock - The oldest block that we've validated. (and all\nsubsequent blocks)\n\nWe'll also want the ability to advertise what sub-ranges of the\nblockchain data we have on hand:\n\nlistArchivedBlockRanges - lists of (begin, end pairs)\n\nNodes should drop all but the largest n pairs, say 5 or something. The\nindex -1 is reserved to indicate the last block to make it easy to\nadvertise that you have every block starting at some height to the most\nrecent. (reserving -n with n as the last block might be a better choice\nto show intent, but still allow for specific proofs when we get node\nidentities)\n\nWe probably want to define a NODE_PARTIAL service bit or something; I'll\nhave to re-read Pieter Wuille's proposal and think about it. Nodes\nshould NOT advertize NODE_NETWORK unless they have the full chain and\nhave verified it.\n\nNodes with partial peers should only relay transactions to those peers\nif the transactions spend inputs the peers know about - remember how\neven an SPV node has that information if it's not spending unconfirmed\ninputs it didn't create. Nodes will have to update their peers\nperiodically as nOldestBlock changes. That said it may also be\nworthwhile to simply relay all transactions in some cases too - a\nreasonable way to approach this might be to set a bloom filter for tx's\nthat you *definitely* want, and if you are interested in everything,\njust set the filter to all 1's. If someone comes up with a reasonable\nmicropayment or proof-of-work system even relaying txs that you haven't\nvalidated is fine - the proof-of-work and prioritization will prevent\nDoS attacks just fine.\n\nRemember that if you're running a partial node, it can get new blocks\nfrom any partial node, and it can retrieve historic blockchain data from\nany partial node that has archived the sequence of blocks you need next.\nOn a large scale this is similar to how in BitTorrent you can serve data\nto your peers the moment you get it - a significant scalability\nimprovement for the network as a whole. Even if a large % of the network\nwas partial nodes running for just a few hours a day the whole system\nwould work fine due to how partial nodes can serve each other the data\nthey need.\n\nOn startup you can act as a SPV node temporarily, grabbing asking for\nfiltered blocks matching your wallet, and then go back and get the full\nblocks, or just download the full blocks right away. That's a tradeoff\non how long the node has been off.\n\nAnyway, it's a bit more code compared to pure-SPV, but it results in a\nmuch more scalable Bitcoin, and if you can spare the modest bandwidth\nrequirements to keep up with the blockchain it'll result in much better\nrobustness against DoS attacks for you and Bitcoin in general.\n\n-- \n'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130717/a73ba03e/attachment.sig\u003e"}