{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-09-11\n📝 Original message:On Tue, Sep 11, 2012 at 3:07 PM, Matthew Mitchell\n\u003cmatthewmitchell at godofgod.co.uk\u003e wrote:\n\u003e For some reason sourceforge is not sending me updates anymore but I can see the replies online…\n\u003e\n\u003e There could be a slightly more simple protocol which gives all the transactions hashes and nodes can then download the transactions separately. However there are two problems:\n\u003e\n\u003e 1. Downloading all the transactions individually might be inefficient. My proposal will allow nodes to request multiple transactions at once.\n\nSomeone can do that just by pipelining the one at a time requests.\nHow much bandwidth do you think you could save over that?\n\n\u003e 2. Why not add a few additional components to the protocol to allow requests for any level of the merkle tree? It's not very complicated at all and protects against the future.\n\nI don't see what value this provides.  For protecting against the\nfuture you might as well suggest uploading x86 code which gets\nexecuted to select transactions. \"Protects against the future\".  Can\nyou clarify some more about exactly how you think it would help?\n\nIt's sometimes desirable to be more general rather than more special\ncase when it's costless... but having couple extra p2p protocol\nmessages to implement, test for interop, guard against vulnerability,\netc. isn't costless... and should be justified with concrete benefits.\n\nit's not clear to me how your proposal is really all that useful for\nvery large blocks: I looks like it would lot of bytes sending\nredundant tree data.\n\n\u003eThe block sizes at the moment are about 0.1MB but what if the bitcoin demand starts pushing that into megabytes?\n\nAnd what if? _Bitcoin_ blocksizes can't be any larger.  Some future\nincompatible system? well perhaps. But we're working on the protocol\nfor bitcoin now.\n\n\u003e And yes the ~0.95MB limit needs to be changed in order for bitcoin to grow that far. Why would the limit not be lifted? How will bitcoin demand be satisfied other than having large fees to deter transactions, hoping the fees are large enough to balance the demand with the block size limits to prevent many transactions being unconfirmed and annoying users? That limit has got to go eventually. And then it could be that block sizes do become large enough to worry about the performance in relaying.\n\nThe finite size— and ultimately the contention for space it causes— is\nthe only thing will creates non-trivial fees. Without the fees there\nis no honest economic motivation to mine with adequate computing power\nto provide security (lots of dishonest motivations— e.g. applying\ncontrol over the currency exist), you'd just have a race to the\nbottom, given unbounded block sizes it is always rational for\ndecentralized to include any transaction with a fee even if it is very\nsmall— otherwise the next rational solver is just going to include it.\n\nBitcoin gets its value through scarcity. There are two kinds of\nscarcity that are economically important, scarcity of the coins— there\nwill never be more than 21 million— and scarcity of the block space\nwhich, as the protocol is defined and enforced by every node can not\nbe more than 1MB. The latter scarcity is what makes the security model\neconomically sane.\n\nFortunately, its perfectly possible to make transactions denominated\nin bitcoin outside of the blockchain, and in a secure and distributed\nmanner that respects the principles that make bitcoin attractive, but\nwith information hiding that improves privacy, transaction speed, and\nscalability. See, e.g. the good work being done by Open transactions\nto create distributed cryptographic banks.  So blockchain scarcity\nitself doesn't prevent Bitcoin from being a one world currency\n(something which isn't at all sane no matter how big you make the\nblocks if you don't allow for other modes of transaction processing—\nwho the heck wants to possibly wait an hour to get a 1 confirm\nsodapop??).\n\n\u003eFrom the beginning it was obvious that confirmations would eventually\nbe slower (or expensive to make merely slow; Bitcoin is incapable of\nreliable fast confirmations)— thats the nature the stochastic\nconsensus and the fee based security support.  You could instead\nimagine a future where bitcoin's security came by collusion by major\nfinancial cartels and governments, and where fees aren't important....\n But I reject that future, it's a perfectly viable one, but why bother\nwith Bitcoins in the first place? To make some early adopters a little\nbit of money starting off the next big centrally controlled fiat?\nBoring.\n\nI can't say for sure if the 1MB limit will stay exactly as is forever,\nas I expect the economics work with any limit out of a fairly broad\nrange that is low enough to both make the space seriously scarce and\nlow enough that 'inexpensive' (e.g. privately owned) hardware can\ncontinue to audit it to preserve the decentralized security,  and the\neconomic importance of the size limit is more subtle than the\ninflation resistance... but I know that changing it is precisely as\ntechnically difficult as changing the 21 million limit: all Bitcoin\nnode software must be replaced with incompatible software, and I\nbelieve it would be just as economically risky— if not more so— if\ndone wrong, as at least inflation would have a easily understood\ndirect dillution effect while inadequate security would potentially\nmake all Bitcoin worthless.  As such I don't think it's even worth\ndiscussing until there is an urgent demand to clarify the tradeoffs...\n\nShould the block size ever be increased the message format used for\nrelaying the larger blocks will be the smallest of the issues being\ndiscussed."}