{"type":"rich","version":"1.0","author_name":"npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grz","author_url":"https://nostr.ae/npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grz","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-03-29\n📝 Original message:Well it's not going off-topic since the btc folks need now to find a way\nto counter the attack\n\nThe disk space story is know to be a non issue, because encouraging\npeople to run nodes while they don't know how to dedicate the right\nstorage space that is trivial and not expensive to get today is just\nstupid, they should not try to run full nodes, and no I tested with non\nSSD drives, I was more wondering about cpu and bandwidth use, but did\nnot notice any impact, just stopped because a repeated sw bug or drive\nissue desynched the chain and bitcoin-qt was trying to reload it from\nthe begining each time, which in my case was taking 10 days despite of\ngood bandwidth (which would allow me to torrent the entire chain + state\nin less than 20 hours), so I stopped after the 3rd crash, setting up a\nfull node on my servers is still in the todo list (very low priority for\nthe reasons already explained)\n\nRunning a prune node implies first to setup a full node, so the same\nproblematic applies and then the advantage of pruning is not really\nobvious, I don't know what's the strange story about \"archival nodes\", I\nproposed something else\n\nBack to the topic, the conclusion is that this is not difficult at all\nfor many people to run efficient full nodes, ideally the community\nshould promote this, seed a torrent with a recent state, implement a\npatch to defeat BU plans and have everybody upgrade\n\nBut of course this will not happen\n\n\nLe 29/03/2017 à 18:41, Andrew Johnson a écrit :\n\u003e I believe that as we continue to add users to the system by scaling\n\u003e capacity that we will see more new nodes appear, but I'm at a bit of a\n\u003e loss as to how to empirically prove it. \n\u003e\n\u003e I do see your point on increasing load on archival nodes, but the\n\u003e majority of that load is going to come from new nodes coming online,\n\u003e they're the only ones going after very old blocks.   I could see that\n\u003e as a potential attack vector, overwhelm the archival nodes by spinning\n\u003e up new nodes constantly, therefore making it difficult for a \"real\"\n\u003e new node to get up to speed in a reasonable amount of time. \n\u003e\n\u003e Perhaps the answer there would be a way to pay an archival node a\n\u003e small amount of bitcoin in order to retrieve blocks older than a\n\u003e certain cutoff?  Include an IP address for the node asking for the\n\u003e data as metadata in the transaction...  Archival nodes could set and\n\u003e publish their own policy, let the market decide what those older\n\u003e blocks are worth.  Would also help to incentivize running archival\n\u003e node, which we do need.  Of course, this isn't very user friendly. \n\u003e\n\u003e We can take this to bitcoin-discuss, if we're getting too far off topic.\n\u003e\n\u003e\n\u003e On Wed, Mar 29, 2017 at 11:25 AM David Vorick \u003cdavid.vorick at gmail.com\n\u003e \u003cmailto:david.vorick at gmail.com\u003e\u003e wrote:\n\u003e\n\u003e\n\u003e     On Mar 29, 2017 12:20 PM, \"Andrew Johnson\"\n\u003e     \u003candrew.johnson83 at gmail.com \u003cmailto:andrew.johnson83 at gmail.com\u003e\u003e\n\u003e     wrote:\n\u003e\n\u003e         What's stopping these users from running a pruned node?  Not\n\u003e         every node needs to store a complete copy of the blockchain. \n\u003e\n\u003e\n\u003e     Pruned nodes are not the default configuration, if it was the\n\u003e     default configuration then I think you would see far more users\n\u003e     running a pruned node.\n\u003e\n\u003e     But that would also substantially increase the burden on archive\n\u003e     nodes.\n\u003e\n\u003e\n\u003e     Further discussion about disk space requirements should be taken\n\u003e     to another thread.\n\u003e\n\u003e\n\u003e -- \n\u003e Andrew Johnson\n\u003e\n\n-- \nZcash wallets made simple: https://github.com/Ayms/zcash-wallets\nBitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets\nGet the torrent dynamic blocklist: http://peersm.com/getblocklist\nCheck the 10 M passwords list: http://peersm.com/findmyass\nAnti-spies and private torrents, dynamic blocklist: http://torrent-live.org\nPeersm : http://www.peersm.com\ntorrent-live: https://github.com/Ayms/torrent-live\nnode-Tor : https://www.github.com/Ayms/node-Tor\nGitHub : https://www.github.com/Ayms\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/0b5f83cc/attachment.html\u003e"}