public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: jl2012@xbt.hk
To: Wes Green <maveric100@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Block size implementation using Game Theory
Date: Fri, 07 Aug 2015 01:20:21 -0400	[thread overview]
Message-ID: <ee3ac5ef1febb7d9a66d89c41543a64f@xbt.hk> (raw)
In-Reply-To: <CAOvA3_hhzWqX0k7xbua=qFptb90fkbCU-WDMih4=mX+kRrWG1g@mail.gmail.com>

It won't work as you thought. If a miner has 95% of hashing power, he 
would have 95% of chance to find the next block and collect the penalty. 
In long term, he only needs to pay 5% penalty. It's clearly biased 
against small miners.

Instead, you should require the miners to burn the penalty. Whether this 
is a good idea is another issue.

Wes Green via bitcoin-dev 於 2015-08-06 19:52 寫到:
> 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.
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



      parent reply	other threads:[~2015-08-07  5:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06 23:52 [bitcoin-dev] Block size implementation using Game Theory Wes Green
2015-08-07  2:16 ` Anthony Towns
2015-08-07  5:20 ` jl2012 [this message]

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=ee3ac5ef1febb7d9a66d89c41543a64f@xbt.hk \
    --to=jl2012@xbt.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=maveric100@gmail.com \
    /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