From: Andrew <onelineproof@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
Date: Thu, 7 May 2015 11:15:57 +0000 [thread overview]
Message-ID: <CAL8tG==YbM8Lv4+iW3PVO34Dcs_kJ7CMbw9koOSr7GpOYmbE=Q@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7560 bytes --]
I'm mainly just an observer on this. I mostly agree with Pieter. Also, I
think the main reason why people like Gavin and Mike Hearn are trying to
rush this through is because they have some kind of "apps" that depend on
zero conf instant transactions, so this would of course require more
traffic on the blockchain. I think people like Gavin or Mike should state
clearly what kind of (rigorous) system for instant transactions is
satisfactory for use in their applications. Be it lightning or something
similar, what is good enough? And no zero conf is not a real secure system.
Then once we know what is good enough for them (and everyone else), we can
implement it as a soft fork into the protocol, and it's a win win situation
for both sides (we can also benefit from all the new users people like Mike
are trying bring in).
On Thu, May 7, 2015 at 10:52 AM, Jorge Timón <jtimon@jtimon•cc> wrote:
> On Thu, May 7, 2015 at 11:25 AM, Mike Hearn <mike@plan99•net> wrote:
> > I observed to Wladimir and Gavin in private that this timeline meant a
> change to the block size was unlikely to get into 0.11, leaving only 0.12,
> which would give everyone only a few months to upgrade in order to fork the
> chain by the end of the winter growth season. That seemed tight.
>
> Can you please elaborate on what terrible things will happen if we
> don't increase the block size by winter this year?
> I assume that you are expecting full blocks by then, have you used any
> statistical technique to come up with that date or is it just your
> guess?
> Because I love wild guesses and mine is that full 1 MB blocks will not
> happen until June 2017.
>
> > What we need to see right now is leadership and a plan, that fits in the
> > available time window.
> >
> >>
> >> Certainly a consensus in this kind of technical community should be a
> >> basic requirement for any serious commitment to blocksize increase.
> >
> >
> > I'm afraid I have come to disagree. I no longer believe this community
> can
> > reach consensus on anything protocol related. Some of these arguments
> have
> > dragged on for years. Consensus isn't even well defined - consensus of
> who?
> > Anyone who shows up? And what happens when, inevitably, no consensus is
> > reached? Stasis forever?
>
> We've successfully reached consensus for several softfork proposals
> already.
> I agree with others that hardfork need to be uncontroversial and there
> should be consensus about them.
> If you have other ideas for the criteria for hardfork deployment all I'm
> ears.
> I just hope that by "What we need to see right now is leadership" you
> don't mean something like "when Gaving and Mike agree it's enough to
> deploy a hardfork" when you go from vague to concrete.
>
>
> >> Long-term incentive compatibility requires that there be some fee
> >> pressure, and that blocks be relatively consistently full or very nearly
> >> full.
> >
> >
> > I disagree. When the money supply eventually dwindles I doubt it will be
> fee
> > pressure that funds mining, but as that's a long time in the future, it's
> > very hard to predict what might happen.
>
> Oh, so your answer to "bitcoin will eventually need to live on fees
> and we would like to know more about how it will look like then" it's
> "no bitcoin long term it's broken long term but that's far away in the
> future so let's just worry about the present".
> I agree that it's hard to predict that future, but having some
> competition for block space would actually help us get more data on a
> similar situation to be able to predict that future better.
> What you want to avoid at all cost (the block size actually being
> used), I see as the best opportunity we have to look into the future.
>
> >> What we see today are
> >> transactions enjoying next-block confirmations with nearly zero pressure
> >> to include any fee at all (though many do because it makes wallet code
> >> simpler).
> >
> >
> > Many do because free transactions are broken - the relay limiter means
> > whether a free transaction actually makes it across the network or not is
> > basically pot luck and there's no way for a wallet to know, short of
> either
> > trying it or actually receiving every single transaction and repeating
> the
> > calculations. If free transactions weren't broken for all non-full nodes
> > they'd probably be used a lot more.
>
> Free transactions are a gift from miners that run an altruistic policy.
> That's great but we shouldn't rely on them for the future. They will
> likely disappear at some point and that's ok.
> In any case, he's not complaining about the lack of free transactions,
> more like the opposite.
> He is saying that's very easy to get free transactions in the next
> block and blocks aren't full so there's no incentive to include fees
> to compete for the space.
> We can talk a lot about "a fee market" and build a theoretically
> perfect fee estimator but we won't actually have a fee market until
> there's some competition for space.
> Nobody will pay for space that's abundant just like people don't pay
> for the air they breath.
>
> > What I don't see from you yet is a specific and credible plan that fits
> > within the next 12 months and which allows Bitcoin to keep growing. Not
> some
> > vague handwave like "let's all use the Lightning network" (which does not
> > exist), or "let's do more research" (Gavin has done plenty of research),
> or
> > "but what about the risks" (Bitcoin is full of risks). A plan, with dates
> > attached, and a strong chance of actually being deployed in time.
>
> Ok, this is my plan: we wait 12 months, hope that your estimations are
> correct (in case that my guess was better than yours, we keep waiting
> until June 2017) and start having full blocks and people having to
> wait 2 blocks for their transactions to be confirmed some times.
> That would be the beginning of a true "fee market", something that
> Gavin used to say was his #1 priority not so long ago (which seems
> contradictory with his current efforts to avoid that from happening).
> Having a true fee market seems clearly an advantage.
> What are supposedly disastrous negative parts of this plan that make
> an alternative plan (ie: increasing the block size) so necessary and
> obvious.
> I think the advocates of the size increase are failing to explain the
> disadvantages of maintaining the current size. It feels like the
> explanation are missing because it should be somehow obvious how the
> sky will burn if we don't increase the block size soon.
> But, well, it is not obvious to me, so please elaborate on why having
> a fee market (instead of just an price estimator for a market that
> doesn't even really exist) would be a disaster.
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
[-- Attachment #2: Type: text/html, Size: 8926 bytes --]
next prev parent reply other threads:[~2015-05-07 11:16 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-06 22:12 Matt Corallo
2015-05-06 22:30 ` slush
2015-05-06 23:06 ` Eric Lombrozo
2015-05-06 22:44 ` Tier Nolan
2015-05-06 23:12 ` Matt Corallo
2015-05-06 23:33 ` Tier Nolan
2015-05-06 23:41 ` Matt Corallo
2015-05-07 2:16 ` Peter Todd
2015-05-06 23:11 ` Matt Whitlock
2015-05-06 23:13 ` Matt Corallo
2015-05-07 0:00 ` Tom Harding
2015-05-07 0:07 ` Bryan Bishop
2015-05-07 0:37 ` Gregory Maxwell
2015-05-07 1:49 ` Peter Todd
2015-05-07 3:03 ` Justus Ranvier
2015-05-08 11:02 ` Thomas Zander
2015-05-08 20:17 ` Aaron Voisine
2015-05-07 3:47 ` Pieter Wuille
2015-05-07 9:25 ` Mike Hearn
2015-05-07 10:12 ` Peter Todd
2015-05-07 10:42 ` Btc Drak
2015-05-07 10:52 ` Jorge Timón
2015-05-07 11:15 ` Andrew [this message]
2015-05-07 11:29 ` Mike Hearn
2015-05-07 12:26 ` Jorge Timón
2015-05-07 14:05 ` Mike Hearn
2015-05-07 14:18 ` Bryan Bishop
2015-05-07 14:22 ` Peter Todd
2015-05-07 14:40 ` Peter Todd
2015-05-07 14:52 ` Gavin Andresen
2015-05-07 14:56 ` Peter Todd
2015-05-07 15:04 ` Alex Morcos
2015-05-07 15:09 ` Jeff Garzik
2015-05-07 15:12 ` Mike Hearn
2015-05-07 15:17 ` Jeff Garzik
2015-05-07 15:29 ` Mike Hearn
2015-05-07 15:35 ` Jeff Garzik
2015-05-07 16:18 ` Justus Ranvier
2015-05-07 16:21 ` Jorge Timón
2015-05-07 17:29 ` Peter Todd
2015-05-07 19:37 ` Mike Hearn
2015-05-07 19:44 ` Jérémie Dubois-Lacoste
2015-05-07 20:20 ` Jérémie Dubois-Lacoste
2015-05-07 15:58 ` Matthew Mitchell
2015-05-07 16:47 ` Matthew Mitchell
2015-05-07 17:26 ` Matt Corallo
[not found] ` <CABsx9T2vAQyZODRE9apu0R1n=LybssQcuTYD7P3mAQH_Fv6QCQ@mail.gmail.com>
2015-05-07 17:40 ` [Bitcoin-development] Fwd: " Gavin Andresen
2015-05-07 17:43 ` [Bitcoin-development] " Mike Hearn
2015-05-07 18:03 ` Btc Drak
2015-05-07 18:06 ` Mike Hearn
2015-05-07 18:21 ` Ross Nicoll
2015-05-07 18:40 ` Gavin Costin
2015-05-07 18:46 ` Btc Drak
2015-05-07 19:31 ` Bernard Rihn
2015-05-07 19:31 ` Alan Reiner
2015-05-07 19:54 ` Jeff Garzik
2015-05-07 19:59 ` Justus Ranvier
2015-05-08 1:40 ` Tom Harding
2015-05-08 2:09 ` Jeff Garzik
2015-05-08 5:13 ` Tom Harding
2015-05-08 9:43 ` Mike Hearn
2015-05-08 15:23 ` Alan Reiner
2015-05-08 14:59 ` Alan Reiner
2015-05-08 15:49 ` Jeff Garzik
2015-05-13 10:37 ` Oliver Egginger
2015-05-13 11:25 ` Angel Leon
2015-05-08 17:17 ` Andrew
2015-05-08 17:51 ` Alan Reiner
[not found] ` <CADZB0_bK+YsK8sN-di2pynvjsq5VjSvnEu0-cCGhPqFunyVm7Q@mail.gmail.com>
2015-05-09 12:02 ` Andrew
2015-05-09 12:53 ` Justus Ranvier
2015-05-09 18:33 ` Andrew
2015-05-08 1:51 ` Joel Joonatan Kaartinen
2015-05-08 3:41 ` Peter Todd
2015-05-07 18:38 ` Chris Wardell
2015-05-07 18:55 ` Alex Mizrahi
2015-05-07 18:59 ` Ross Nicoll
2015-05-07 19:03 ` Matt Corallo
2015-05-07 19:13 ` Jeff Garzik
2015-05-07 19:34 ` Mike Hearn
2015-05-07 21:29 ` Matt Corallo
2015-05-07 23:05 ` 21E14
2015-05-07 15:33 ` Jorge Timón
2015-05-07 16:11 ` Mike Hearn
2015-05-07 16:47 ` Jorge Timón
2015-05-07 16:59 ` Gavin Andresen
2015-05-07 17:42 ` Peter Todd
2015-05-07 18:05 ` Jorge Timón
2015-05-07 19:57 ` Btc Drak
2015-05-07 15:39 ` Btc Drak
2015-05-07 13:02 ` Peter Todd
2015-05-07 19:14 ` Matt Corallo
2015-05-07 11:55 ` Dave Hudson
2015-05-07 13:40 ` Jorge Timón
2015-05-08 4:46 ` Tom Harding
2015-05-07 14:04 ` Jeff Garzik
2015-05-07 14:32 ` Peter Todd
2015-05-07 14:38 ` Justus Ranvier
2015-05-07 14:49 ` Peter Todd
2015-05-07 15:13 ` Justus Ranvier
2015-05-07 15:25 ` Peter Todd
2015-05-07 15:04 ` Jeff Garzik
2015-05-07 15:16 ` Justus Ranvier
2015-05-07 15:27 ` Jeff Garzik
2015-05-07 15:33 ` Justus Ranvier
2015-05-07 15:47 ` Jeff Garzik
2015-05-07 15:50 ` Justus Ranvier
2015-05-07 11:20 ` Wladimir J. van der Laan
2015-05-07 11:30 ` Eric Lombrozo
2015-05-07 15:56 ` Jeff Garzik
2015-05-07 16:13 ` Mike Hearn
2015-05-07 16:54 John Bodeen
2015-05-08 20:38 Raystonn .
2015-05-08 20:40 ` Mark Friedenbach
2015-05-08 20:51 Raystonn
2015-05-08 20:55 ` Mark Friedenbach
2015-05-08 21:01 Raystonn
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='CAL8tG==YbM8Lv4+iW3PVO34Dcs_kJ7CMbw9koOSr7GpOYmbE=Q@mail.gmail.com' \
--to=onelineproof@gmail$(echo .)com \
--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