* [bitcoin-dev] Block size implementation using Game Theory
@ 2015-08-06 23:52 Wes Green
2015-08-07 2:16 ` Anthony Towns
2015-08-07 5:20 ` jl2012
0 siblings, 2 replies; 3+ messages in thread
From: Wes Green @ 2015-08-06 23:52 UTC (permalink / raw)
To: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Block size implementation using Game Theory
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
1 sibling, 0 replies; 3+ messages in thread
From: Anthony Towns @ 2015-08-07 2:16 UTC (permalink / raw)
To: Wes Green; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5283 bytes --]
On 7 August 2015 at 09:52, Wes Green via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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, whatev
> H
> er 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.
>
>
> 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.
>
The equilibrium for that game is just keeping the same block size, isn't
it? Assume there's a huge backlog of fee-paying transactions, such that you
can trivially fill 1MB, and easily fill 1.25MB for the forseeable future;
fee per MB is roughly stable at "f". Then at any point in time, a miner has
the choice between receiving 25 + f btc, or increasing the blocksize to 1+p
MB and earning (25+f+pf) * (1-p) = f-ppf = 25(1-p) + f(1-pp) < 25+f. Even
if you think bigger blocks are good long term, wouldn't you reason that
other people will think so too, so why pay the price for it yourself,
instead of waiting for someone else to pay it and just reaping the benefit?
An idea I've been pondering is having the block size adjustable in
proportion to fees being paid. Something like "a block is invalid if
a(B-c)*B > F" where B is the block's size, F is the total fees for the
block, and a and c are scaling parameters -- either hardcoded in bitcoin,
or dynamically adjusted by miner votes. ATM, bitcoin's behavour is
effectively the same as setting c=1MB, a>=21M BTC/byte.
Having a more reasonable value for a would make it much easier to produce a
fee market for bitcoin transactions -- if the blocksize is currently around
some specific "B", then the average cost per byte of a transaction is just
"a(B-c)". If you pay more than that, then a miner will include your txn
sooner, increasing the blocksize beyond average if necessary; if you pay
less, you may have to wait for a lull in transactions so that the blocksize
ends up being smaller than average and miners can afford to include your
transaction (or someone might send an unnecessarily high fee paying txn
through, and yours might get swept along with it).
To provide some real numbers, you need to make some assumptions on fee
levels. If you're happy with:
- 1 MB blocks are fine, even if no one's paying any fees
- if people are paying 0.1 mBTC / kB (=0.1 BTC/MB) in fees on average then
8MB is okay
then a(1-c)=0, so c=1MB, and a(8-1)=0.1, so a=0.0143 and the scaling works
out like:
- 1MB blocks: free transactions, no fees
- 2MB blocks: 0.0143 mBTC/kB, 0.02 btc in fees/block
- 4MB blocks: 0.043 mBTC/kB, 0.17 btc in fees/block
- 8MB blocks: 0.1 mBTC/kB, 0.8 btc in fees/block
- 20MB blocks: 0.27 mBTC/kB, 5.4 btc in fees/block
- 40MB blocks: 0.56 mBTC/kB, 22 btc in fees/block
In the short term, miners can just maximise fees for a block -- ie, add the
highest fee/byte txns in order until adding the next one would invalidate
the block.
Over the long term, you'd still want to be able to adjust a and c -- as the
price of bitcoin in USD/real terms goes up, a should decrease
proportionally; as hardware/software improve, a should decrease and/or c
should increase. Essentially miners would want to choose a,c such that the
market for block space clears at a price of some $x/byte, where $x is
determined by their costs -- ie, hardware/software constraints. If they set
a too high, or c too low, then they'll be unable to accept some
transactions offering $x/byte, and thus lose out. If they set a too low or
c too high, they'll be mining bigger blocks for less reward, and lose out
that way too. At the moment, I think it's a bit of both problems -- c is
too low (meaning some transactions get dropped), but a is too high (meaning
fees are too low to pay for the effort of bigger blocks).
Note that, as described, miners could try cheating this plan by making a
high fee transaction to themselves but not publishing it -- they'll collect
the fee anyway, and now they can mine arbitrarily large blocks. You could
mitigate this by having a(B-c) set the /minimum/ fee/byte of every
transaction in a block, or alternatively by enforcing each miner pay a
significant %ge of collected fees to the miner of the next block(s).
Cheers,
aj
--
Anthony Towns <aj@erisian•com.au>
[-- Attachment #2: Type: text/html, Size: 8548 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Block size implementation using Game Theory
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
1 sibling, 0 replies; 3+ messages in thread
From: jl2012 @ 2015-08-07 5:20 UTC (permalink / raw)
To: Wes Green; +Cc: bitcoin-dev
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-08-07 5:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox