{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-29\n📝 Original message:\u003e\n\u003e If the plan is a fix once and for all, then that should be changed too.\n\u003e It could be set so that it is at least some multiple of the max block size\n\u003e allowed.\n\u003e\n\nWell, but RAM is not infinite :-) Effectively what these caps are doing is\nsetting the minimum hardware requirements for running a Bitcoin node.\n\nThat's OK by me - I don't think we are actually going to exhaust the\nhardware abilities of any reasonable computer any time soon, but still,\nhaving the software recognise the finite nature of a computing machine\ndoesn't seem unwise.\n\n\n\u003e That system can send a block of any size.  It would require a change to\n\u003e the processing of any merkleblocks received.\n\u003e\n\nNot \"any\" size because, again, the remote node must buffer things up and\nhave the transaction data actually in memory in order to digest it. But a\nmuch larger size, yes.\n\nHowever, that's a bigger change.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/6aebe66a/attachment.html\u003e"}