From: Mike Hearn <mike@plan99•net>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
Date: Mon, 15 Jun 2015 11:27:24 +0200 [thread overview]
Message-ID: <CANEZrP0Z_EOmVgbvVmYDvegm6jfd1cKB52acXHocjRuM-qGEog@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTENbj+E7ypJASrM1r04eW3kYe+afwy+Rt3i9ubeT-=2mA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4206 bytes --]
>
> 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).
[-- Attachment #2: Type: text/html, Size: 5392 bytes --]
next prev parent reply other threads:[~2015-06-15 9:27 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-14 21:23 Adam Back
2015-06-14 22:23 ` Mike Hearn
2015-06-14 23:58 ` Adam Back
2015-06-15 0:53 ` Eric Lombrozo
2015-06-15 0:55 ` Eric Lombrozo
2015-06-15 4:11 ` Peter Todd
2015-06-15 4:43 ` Eric Lombrozo
2015-06-15 9:27 ` Mike Hearn [this message]
2015-06-15 9:39 ` Eric Lombrozo
2015-06-15 10:24 ` Pieter Wuille
2015-06-15 10:36 ` Mike Hearn
2015-06-15 10:40 ` Pieter Wuille
2015-06-15 10:50 ` Mike Hearn
2015-06-15 11:16 ` Rebroad (sourceforge)
2015-06-15 17:53 ` Raystonn .
2015-06-15 18:14 ` Adam Back
2015-06-15 18:57 ` [Bitcoin-development] The Bitcoin Node Market Raystonn .
2015-06-15 19:18 ` sickpig
2015-06-15 19:36 ` Raystonn .
2015-06-15 20:12 ` sickpig
2015-06-16 3:30 ` Kevin Greene
2015-06-16 3:41 ` Luke Dashjr
2015-06-16 3:49 ` Kevin Greene
2015-06-16 4:05 ` Kevin Greene
2015-06-16 4:12 ` Aaron Voisine
2015-06-16 5:28 ` justusranvier
2015-06-16 5:30 ` Potter QQ
2015-06-16 7:55 ` Aaron Voisine
2015-06-16 13:32 ` justusranvier
2015-06-16 17:04 ` Aaron Voisine
2015-06-16 17:22 ` Aaron Voisine
2015-06-16 15:52 ` devrandom
2015-06-15 4:43 ` [Bitcoin-development] comments on BIP 100 Peter Todd
2015-06-15 9:06 ` Mike Hearn
2015-06-15 2:28 ` Jeff Garzik
2015-06-15 2:44 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP0Z_EOmVgbvVmYDvegm6jfd1cKB52acXHocjRuM-qGEog@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox