From: "Jorge Timón" <jtimon@jtimon•cc>
To: Dave Hudson <dave@hashingit•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
Date: Thu, 7 May 2015 15:40:23 +0200 [thread overview]
Message-ID: <CABm2gDpceBQ=SqH-axgbMgOGOf8cOe1wLyJgJY5TEFu4taiNwA@mail.gmail.com> (raw)
In-Reply-To: <5049F137-E123-47F6-9D24-FE51B92629FF@hashingit.com>
On Thu, May 7, 2015 at 1:55 PM, Dave Hudson <dave@hashingit•com> wrote:
> Known: There has been a steady trend towards the mean block size getting
> larger. See
> https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=0&address=
Looking at this graph and in retrospective, we shouldn't have removed
the standard policy limit without observing the supposedly disastrous
effects of hitting the limit first.
Removing the standard limit would have been trivial (bdb issues aside)
at any point after seeing the effects.
> Known: If we reach the point where all blocks are 1M bytes then there's a
> major problem in terms of transaction confirmation. I published an analysis
> of the impact of different mean block sizes against confirmation times:
> http://hashingit.com/analysis/34-bitcoin-traffic-bulletin. The current 35%
> to 45% mean block size doesn't have a huge impact on transaction
> confirmations (assuming equal fees for all) but once we're up at 80% then
> things start to get unpleasant. Instead of 50% of first confirmations taking
> about 7 minutes they instead take nearer to 19 minutes.
Well, this is only for first confirmations of free transaction.
A higher fee should increase your probabilities, but if you're sending
free transactions you may not care about them taking longer to be
included.
> Known: There are currently a reasonably large number of zero-fee
> transactions getting relayed and mined. If things start to slow down then
> there will be a huge incentive to delay them (or drop them altogether).
Well, maybe "instant and free" it's not a honest form of bitcoin
marketing and it just has to disappear.
Maybe we just need to start being more honest about pow being good for
processing micro-transactions: it is not.
Hopefully lightning will be good for that.
Free and fast in-chain transactions is something temporary that we
know will eventually disappear.
If people think it would be a adoption disaster that it happens soon,
then they could also detail an alternative plan to roll that out
instead of letting it happen.
But if the plan is to delay it forever...then I'm absolutely against.
> Known: There's a major problem looming for miners at the next block reward
> halving. Many are already in a bad place and without meaningful fees then
> sans a 2x increase in the USD:BTC ratio then many will simply have to leave
> the network, increasing centralisation risks. There seems to be a fairly
> pervasive assumption that the 300-ish MW of power that they currently use is
> going to pay for itself (ignoring capital and other operating costs).
I take this as an argument for increasing fee competition and thus,
against increasing the block size.
> Known: the orphan rate is still pretty-high even with everyone's fast
> connections. If we assume that 20M byte blocks become possible then that's
> likely to increase.
>
> Unknown: What are the security implications for larger blocks (this one (at
> least) can be simulated though)? For example, could large blocks with huge
> numbers of trivial transactions be used to put other validators at a
> disadvantage in a variant of a selfish mining attack? I've seen objections
> that such bad actors could be blacklisted in the future but it's not clear
> to me how. A private mining pool can trivially be made to appear like 100
> pools of 1% of the size without significantly affecting the economics of
> running that private mine.
No blacklisting, please, that's centralized.
In any case, a related known: bigger blocks give competitive advantage
to bigger miners.
next prev parent reply other threads:[~2015-05-07 13:40 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
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 [this message]
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='CABm2gDpceBQ=SqH-axgbMgOGOf8cOe1wLyJgJY5TEFu4taiNwA@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=dave@hashingit$(echo .)com \
/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