From: Wes Green <maveric100@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Block size implementation using Game Theory
Date: Thu, 06 Aug 2015 23:52:32 +0000 [thread overview]
Message-ID: <CAOvA3_hhzWqX0k7xbua=qFptb90fkbCU-WDMih4=mX+kRrWG1g@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]
Bitcoin is built on game theory. Somehow we seem to have forgotten that and
are trying to fix our "block size issue" with magic numbers, projected
percentage growth of bandwidth speeds, time limits, etc... There are
instances where these types of solutions make sense, but this doesn't
appear to be one of them. Lets return to game theory.
Proposal: Allow any miner to, up to, double the block size at any given
time - but penalize them. Using the normal block reward, whatever
percentage increase the miner makes over the previous limit is taken from
both the normal reward and fees. The left over is rewarded to the next
miner that finds a block.
If blocks stay smaller for an extended period of time, it goes back down to
the previous limit/ x amount decrease/% decrease (up for debate)
Why would this work?: Miners only have incentive to do raise the limit when
they feel there is organic growth in the network. Spam attacks, block bloat
etc would have to be dealt with as it is currently. There is no incentive
to raise the size for spam because it will subside and the penalty will
have been for nothing when the attack ends and block size goes back down.
I believe it would have the nice side effect of forcing miners to hold the
whole block chain. I believe SPV does not allow you to see all the
transactions in a block and be able to calculate if you should be adding
more to your reward transaction if the last miner made the blocks bigger.
Because of this, the miners would also have an eye on blockchain size and
wont want it getting huge too fast (outsize of Moore's law of Nielsen's
Law). Adding to the gamification.
This system would encourage block size growth due to organic growth and the
penalty would encourage it to be slow as to still keep reward high and
preserve ROE.
What this would look like: The miners start seeing what looks like natural
network growth, and make the decision (or program an algorithm, the beauty
is it leaves the "how" up to the miners) to increase the blocksize. They
think that, in the long run, having larger blocks will increase their
revenue and its worth taking the hit now for more fees later. They increase
the size to 1.25 MB. As a result, they reward would be 18.75 (75%). The
miner fees were .5BTC. The miner fees are also reduced to .375BTC. Everyone
who receives that block can easily calculate 1) if the previous miner gave
themselves the proper reward 2) what the next reward should be if they win
it. Miners now start building blocks with a 31.25 reward transaction and
miner fee + .125.
[-- Attachment #2: Type: text/html, Size: 3826 bytes --]
next reply other threads:[~2015-08-06 23:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-06 23:52 Wes Green [this message]
2015-08-07 2:16 ` [bitcoin-dev] Block size implementation using Game Theory Anthony Towns
2015-08-07 5:20 ` jl2012
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='CAOvA3_hhzWqX0k7xbua=qFptb90fkbCU-WDMih4=mX+kRrWG1g@mail.gmail.com' \
--to=maveric100@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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