> > That was probably insufficiently specific, let me rephrase: I am > referring to the trend that much of the industry is built on web2.0 > technology using bitcoin via a library in a web scripting language
OK, good to hear that. I'm not happy about the use of web technologies in wallets/services either, but the causes of that trend are nothing to do with block chain sizes. It's more because there's a generation of developers who see no alternatives. With projects like Lighthouse, I'm trying to show people that they can blend the good bits of the web with the good bits of more traditional client side development, at a cost they can afford. Unfortunately, as you know, one of the reasons that developers turn to outsourced services is that those services actually like developers and give them the features they need. Whereas any attempt to add protocol features for app/wallet developers to Bitcoin Core becomes controversial due to some perceived or real lack of perfection. I persevered for several months to add a very small "API" I needed for my app to Bitcoin Core, and it was in the end a waste of time. There are no actionable items left for the getutxo patch, regardless, I had to fork Bitcoin to get it out there. It would have been *much* easier to just say, fuck it, I'll use blockchain.info and in fact some in this community told me to do exactly that. But, the approach I chose has been working fine for months now. Compare this experience to companies like chain.com, blockcypher etc - when developers say jump, they say "how high?" So It's unreasonable for the Bitcoin Core developer group to constantly call developers building apps idiots or "non technical" (as I see so often in this block size debate), and then complain that people don't write apps in their preferred way! Just accept that decentralised app dev is already hard, and the way Core is run makes it much harder still. As I said I dont think we can expect Bitcoin to scale with no further > algorithmic improvements. A big part of the debate around this change is showing that this statement is wrong. "Scaling" is not some kind of binary yes/no thing. It's a continuous effort. You write a system that scales a certain amount, and then if you find you need more capacity, you scale it again. Maybe that involves rewriting the existing code or maybe it just means improving what you've got. Or maybe (painful truth coming up) your product is not that compelling, or times change and your users leave, and you discover you never actually need to scale to the giddy heights originally envisioned. A big part of the reason modern web dev is so messed up is that lots of developers starting thinking every app they built needed to be "web scale" from day one. SQL databases? Pah. Doesn't scale. Think big. We gotta no NoSQL sharded key/value store from the start! Otherwise we're just showing lack of confidence in our own product. Then when they used up all their budget solving consistency bugs a relational database would have avoided, they notice their competitors sailing past them on a not-fully-scalable but certainly-scalable-enough architecture that let them focus on features and making users happy. > I am referring to global bandwidth O(n^2) with n=users OK. O() notation normally refers to computational complexity, but ... I still don't get it - the vast majority of users don't run relaying nodes that take part in gossiping. They run web or SPV wallets. And the nodes that do take part don't connect to every other node. > There can be a case for some increase to create some breathing room to > work on scaling and decentralising tech, I just mean to say that if we > do it in isolation, we're not focussing on the big picture. Alright - let's agree that we disagree on a few areas, like the relative desirability of alternative non-blockchain designs - but we do seem to agree that there is a case for an increase in the block size limit. That seems like progress. As you agree with that, what sort of schedule and time are you thinking of? (well, by "you" I really mean blockstream because it's taking forever to try and negotiate with every single person individually).
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
