From: Rodney Morris <rodney.morris@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Date: Mon, 17 Aug 2015 21:57:47 +1000 [thread overview]
Message-ID: <CABerxhEwA7Pz0hdSuOf+RwWZiZpY1fSArB+UiyVUwr6S2fr3vQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5065 bytes --]
Words cannot capture how much I wish Satoshi had put logic like this (or
even just a simple block size doubling every reward halving) in place when
he put in the "temporary" 1MB anti-spam block size limit...
I see problems to this approach. The biggest one I see is that a miner
with 11% of hash power could sabotage block size increases by only ever
mining empty blocks.
I haven't run any statistics or simulations, but I'm concerned that the
interplay between the random distribution of transaction arrival and the
random distribution of block times may lead to false signals.
A 90% full block 1 minute after the previous block is a more "serious"
problem than a 90% full block 30 minutes after the previous block. A 90%
full block after a 90% full block is a more "serious" problem than a 90%
full block after an empty block.
I would expect a robust approach in this manner to look at block sizes
weighted by block times, but this is an interesting proposal regardless.
But I think you'll run up against one of the great schisms in this debate -
those that believe blocks should always be full (or close to it), to
encourage a "fee market" and to encourage off-chain transactions, and those
that think that the blockchain should be useable by almost anyone for
almost anything, implying there should always be spare space in blocks,
with off-chain transactions reserved for microtransactions and zero-conf
(and possibly low-fee transactions). At least, that's my take on it.
Rodney
>
>
> Date: Mon, 17 Aug 2015 11:51:26 +0100
> From: Btc Drak <btcdrak@gmail•com>
> To: Patrick Strateman <patrick.strateman@gmail•com>
> Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size
> Max Cap
> Message-ID:
> <CADJgMzvV7cSW9aBnAf5zX7FDxN5E=AW=rET2i9EnysLao=
> vVyw@mail•gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
> > Nobody is going to click that...
>
> I guess I am nobody. Here's a copy of the text:-
>
> *Dynamically Controlled Bitcoin Block Size Max Cap
> <http://upalc.com/maxblocksize.php>*
>
> *Assumption*: This article is for those, who already understand the bitcoin
> protocol and aware of the block size controversy. Details of the problem
> statement can be found in BIP 100
> <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf>.
> Satoshi's opinion regarding block size can be found here
> <https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366>. I will
> be
> directly going into the solution without explaining the problem in details.
>
>
> *Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
> block each full node does a calculation to find the next target. We will do
> just another calculation here. Nodes will also calculate what % of blocks
> in the last difficulty period is higher than 90% of the maximum block size,
> which is 1 MB for now. If it is found that more than 90% blocks in the last
> difficulty period is higher than 90% of the maximum block size, then double
> the maximum block size. If not, then calculate what % of blocks in the last
> difficulty period is less than 50% of the maximum block size. If it is
> higher than 90%, then half the maximum block size. If none of the above
> condition satisfies, keep the maximum block size as it is.
>
> Please note that, while calculating the % of blocks, it is better to take
> into account the first 2000 of the 2016, than the whole of 2016. This helps
> to avoid the calculation mistake if some of the last few blocks get
> orphaned.
>
>
> *Reasoning*: This solution is derived directly from the indication of the
> problem. If transaction volume increases, then we will naturally see bigger
> blocks. On the contrary, if there are not enough transaction volume, but
> maximum block size is high, then only few blocks may sweep the mempool.
> Hence, if block size is itself taken into consideration, then maximum block
> size can most rationally be derived. Moreover, this solution not only
> increases, but also decreases the maximum block size, just like difficulty.
>
>
> *Other Solutions of this Problem*:-
>
> Making Decentralized Economic Policy
> <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf> - by
> Jeff Garzik
>
> Elastic block cap with rollover penalties
> <https://bitcointalk.org/index.php?topic=1078521> ? by Meni Rosenfeld
>
> Increase maximum block size
> <https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki> - by
> Gavin
> Andresen
>
> Block size following technological growth
> <https://gist.github.com/sipa/c65665fc360ca7a176a6> - by Pieter Wuille
>
> The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
> <https://lightning.network/lightning-network-paper.pdf> - by Joseph Poon &
> Thaddeus Dryja
>
>
> Please share your opinion regarding this solution below. For mail
> communication, feel free to write me at bitcoin [at] upalc.com.
>
>
[-- Attachment #2: Type: text/html, Size: 6993 bytes --]
next reply other threads:[~2015-08-17 11:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-17 11:57 Rodney Morris [this message]
2015-08-17 12:38 ` Angel Leon
2015-08-17 12:43 ` Tier Nolan
-- strict thread matches above, loose matches on Subject: below --
2015-08-21 21:45 Upal Chakraborty
2015-08-20 15:02 Upal Chakraborty
2015-08-18 12:13 Upal Chakraborty
2015-08-18 17:26 ` Chris Wardell
2015-08-20 7:31 ` Jorge Timón
2015-08-20 10:23 ` Milly Bitcoin
2015-08-21 0:25 ` Tom Harding
2015-08-21 0:37 ` Peter Todd
2015-08-21 16:52 ` Tom Harding
2015-08-21 22:21 ` Peter Todd
2015-08-21 23:16 ` Tom Harding
2015-08-22 0:01 ` Peter Todd
2015-08-22 3:21 ` Jorge Timón
2015-08-22 6:26 ` Peter Todd
2015-08-23 23:41 ` Tom Harding
2015-08-24 2:27 ` Jorge Timón
2015-08-21 0:45 ` Milly Bitcoin
2015-08-21 0:58 ` Peter Todd
2015-08-21 1:30 ` Milly Bitcoin
2015-08-21 20:28 ` Jorge Timón
2015-08-21 12:13 ` Sriram Karra
2015-08-21 20:09 ` Jorge Timón
2015-08-18 19:44 ` cedric perronnet
2015-08-18 20:58 ` Danny Thorpe
2015-08-18 21:17 ` Chris Wardell
2015-08-19 17:21 ` Upal Chakraborty
2015-08-17 9:44 Upal Chakraborty
2015-08-17 9:54 ` Levin Keller
2015-08-17 9:59 ` Patrick Strateman
2015-08-17 10:51 ` Btc Drak
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=CABerxhEwA7Pz0hdSuOf+RwWZiZpY1fSArB+UiyVUwr6S2fr3vQ@mail.gmail.com \
--to=rodney.morris@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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