rich1.0npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwhttps://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwnjumphttps://nostr.ae📅 Original date posted:2015-06-01 📝 Original message:RE: going to the public: I started pushing privately for SOMETHING, ANYTHING to be done, or at the very least for there to be some coherent plan besides "wait and see" back in February. As for it being unhealthy for me to write the code that I think should be written and asking people to run it: Ok. What would you suggest I do? I believe scaling up is the number one priority right now. I think core devs SHOULD be taking time to solve it, because I think the uncertainty of how it will be solved (or if it will be solved) is bad for Bitcoin. I think working on things like fixing transaction malleability is great... but the reason to work on that is to enable smart contracts and all sorts of other interesting new uses of the blockchain. But if we're stuck with 1MB blocks then there won't be room for all of those interesting new uses on the blockchain. Others disagree, and have the advantage of status-quo : if nothing is done, they get what they want. Based on some comments I've seen, I think there is also concern that "my own personal network/computer connection might not be able to handle more transaction volume." That is NOT a good reason to limit scalability, but I think it is clouding the judgement of many of the core contributors who started contributing as a spare-time hobby from their homes (where maybe they have crappy DSL connections). RE: decentralization: I think this is a red-herring. I'll quote something I said on reddit yesterday: "I don't believe a 20MB max size will increase centralization to any significant degree. See http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized and http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners And I think we will have a lot LESS centralization of payments via services like Coinbase (or hubs in some future StrawPay/Lightning network) if the bitcoin network can directly handle more payment volume. The centralization trade-offs seems very clear to me, and I think the "big blocks mean more centralized" arguments are either just wrong or are exaggerated or ignore the tradeoff with payment centralization (I think that is a lot more important for privacy and censorship resistance)." RE: incentives for off-chain solutions: I'll quote myself again from http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea : "The “layer 2” services that are being built on top of the blockchain are absolutely necessary to get nearly instant real-time payments, micropayments and high volume machine-to-machine payments, to pick just three examples. The ten-minute settlement time of blocks on the network is not fast enough for those problems, and it will be the ten minute block interval that drives development of those off-chain innovations more than the total number of transactions supported." On Mon, Jun 1, 2015 at 8:45 AM, Jérôme Legoupil <jjlegoupil at gmail.com> wrote: > If during the "1MB bumpy period" something goes wrong, consensus among the > community would be reached easily if necessary. > That is the problem: this will be a "frog in boiling water" problem. I believe there will be no sudden crisis-- instead, transactions will just get increasingly unreliable and expensive, driving more and more people away from Bitcoin towards... I don't know what. Some less expensive, more reliable, probably more-centralized solution. The Gavin 20MB proposal is compromising Bitcoin's long-term security in an > irreversible way, for gaining short-term better user experience. > If by long-term security you mean "will transaction fees be high enough to pay for enough hashing power to secure the network if there are bigger blocks" I've written about that: http://gavinandresen.ninja/block-size-and-miner-fees-again If you mean something else, then please be specific. -- -- Gavin Andresen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/4417e2e4/attachment.html>