Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4Qfz-0000tN-S3 for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 09:27:31 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.169 as permitted sender) client-ip=209.85.212.169; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f169.google.com; Received: from mail-wi0-f169.google.com ([209.85.212.169]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z4Qfy-0004GE-En for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 09:27:31 +0000 Received: by wicnd19 with SMTP id nd19so18431602wic.1 for ; Mon, 15 Jun 2015 02:27:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.59.98 with SMTP id y2mr7148982wjq.42.1434360444389; Mon, 15 Jun 2015 02:27:24 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.28.14.196 with HTTP; Mon, 15 Jun 2015 02:27:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 11:27:24 +0200 X-Google-Sender-Auth: lGU3UAhrv2UjL9X_DE4uBTf9r7M Message-ID: From: Mike Hearn To: Adam Back Content-Type: multipart/alternative; boundary=047d7ba978a0c48e3305188b1004 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z4Qfy-0004GE-En Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] comments on BIP 100 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 09:27:31 -0000 --047d7ba978a0c48e3305188b1004 Content-Type: text/plain; charset=UTF-8 > > 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). --047d7ba978a0c48e3305188b1004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That was probably insufficiently specific, let m= e 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 traditio= nal client side development, at a cost they can afford.

Unfortunately, as you know, one of the reasons that developers turn t= o outsourced services is that those services actually like developers and g= ive them the features they need. Whereas any attempt to add protocol featur= es for app/wallet developers to Bitcoin Core becomes controversial due to s= ome perceived or real lack of perfection.

I persev= ered 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 a= ctionable items left for the getutxo patch, regardless, I had to fork Bitco= in to get it out there. It would have been much=C2=A0easier to just = say, fuck it, I'll use blockchain.in= fo 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 &q= uot;how high?"

So It's unreasonable for t= he 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 prefer= red way! Just accept that decentralised app dev is already hard, and the wa= y Core is run makes it much harder still.


As I said I dont think we can expect Bitco= in to scale with no further
algorithmic improvements.=C2=A0

A big part = of the debate around this change is showing that this statement is wrong. &= quot;Scaling" is not some kind of binary yes/no thing. It's a cont= inuous 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 =C2=A0invo= lves rewriting the existing code or maybe it just means improving what you&= #39;ve got.

Or maybe (painful truth coming up) you= r 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 origina= lly envisioned.

A big part of the reason modern we= b dev is so messed up is that lots of developers starting thinking every ap= p 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 st= ore 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, t= hey 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.


=C2=A0
I am referring to global bandwidth O(n^2) w= ith n=3Dusers

OK. O() notation normally ref= ers to computational complexity, but ... I still don't get it - the vas= t majority of users don't run relaying nodes that take part in gossipin= g. They run web or SPV wallets. And the nodes that do take part don't c= onnect to every other node.


=C2=A0<= /div>
There can be a case for some increase t= o 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 ar= eas, 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 &= quot;you" I really mean blockstream because it's taking forever to= try and negotiate with every single person individually).

--047d7ba978a0c48e3305188b1004--