* [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
@ 2015-06-12 16:51 Pieter Wuille
2015-06-12 17:21 ` Gavin Andresen
` (3 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: Pieter Wuille @ 2015-06-12 16:51 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2755 bytes --]
Hello all,
I've created a simulator for Bitcoin mining which goes a bit further than
the one Gavin used for his blog post a while ago. The main difference is
support for links with different latency and bandwidth, because of the
clustered configuration described below. In addition, it supports different
block sizes, takes fees into account, does difficulty adjustments, and
takes processing and mining delays into account. It also simulates longer
periods of time, and averages the result of many simulations running in
parallel until the variance on the result is low enough.
The code is here: https://github.com/sipa/bitcoin-net-simul
The configuration used in the code right now simulates two groups of miners
(one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected
internally, but are only connected to each other through a slow 2 Mbit/s
link.
Here are some results.
This shows how the group of smaller miners loses around 8% of their
relative income (if they create larger blocks, their loss percentage goes
up slightly further):
Configuration:
* Miner group 0: 80.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 20.000000% hashrate, blocksize 1000000.000000
* Expected average block size: 16200000.000000
* Average fee per block: 0.250000
* Fee per byte: 0.0000000154
Result:
* Miner group 0: 81.648985% income (factor 1.020612 with hashrate)
* Miner group 1: 18.351015% income (factor 0.917551 with hashrate)
When fees become more important however, and half of a block's income is
due to fees, the effect becomes even stronger (a 15% loss), and the optimal
way to compete for small miners is to create larger blocks as well (smaller
blocks for them result in even less income):
Configuration:
* Miner group 0: 80.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 20.000000% hashrate, blocksize 20000000.000000
* Expected average block size: 20000000.000000
* Average fee per block: 25.000000
* Fee per byte: 0.0000012500
Result:
* Miner group 0: 83.063545% income (factor 1.038294 with hashrate)
* Miner group 1: 16.936455% income (factor 0.846823 with hashrate)
The simulator is not perfect. It doesn't take into account that multiple
blocks/relays can compete for the same bandwidth, or that nodes cannot
process multiple blocks at once.
The numbers used may be unrealistic, and I don't mean this as a prediction
for real-world events. However, it does very clearly show the effects of
larger blocks on centralization pressure of the system. Note that this also
does not make any assumption of destructive behavior on the network - just
simple profit maximalization.
Lastly, the code may be buggy; I only did some small sanity tests with
simple networks.
--
Pieter
[-- Attachment #2: Type: text/html, Size: 3119 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
2015-06-12 16:51 [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed Pieter Wuille
@ 2015-06-12 17:21 ` Gavin Andresen
2015-06-12 18:30 ` Peter Todd
2015-06-12 18:01 ` Peter Todd
` (2 subsequent siblings)
3 siblings, 1 reply; 11+ messages in thread
From: Gavin Andresen @ 2015-06-12 17:21 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]
Nice work, Pieter. You're right that my simulation assumed bandwidth for
'block' messages isn't the bottleneck.
But doesn't Matt's fast relay network (and the work I believe we're both
planning on doing in the near future to further optimize block propagation)
make both of our simulations irrelevant in the long-run?
Or, even simpler, why couldn't the little miners just run their
block-assembling-and-announcing code on the other high-bandwidth-side of
the bandwidth bottleneck?
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 761 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
2015-06-12 17:21 ` Gavin Andresen
@ 2015-06-12 18:30 ` Peter Todd
2015-06-12 18:39 ` Pieter Wuille
0 siblings, 1 reply; 11+ messages in thread
From: Peter Todd @ 2015-06-12 18:30 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote:
> Nice work, Pieter. You're right that my simulation assumed bandwidth for
> 'block' messages isn't the bottleneck.
>
> But doesn't Matt's fast relay network (and the work I believe we're both
> planning on doing in the near future to further optimize block propagation)
> make both of our simulations irrelevant in the long-run?
Then simulate first the relay network assuming 100% of txs use it, and
secondly, assuming 100%-x use it.
For instance, is it in miners' advantage in some cases to sabotage the
relay network? The analyse say yes, so lets simulate that. Equally even
the relay network isn't instant.
--
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
2015-06-12 18:30 ` Peter Todd
@ 2015-06-12 18:39 ` Pieter Wuille
0 siblings, 0 replies; 11+ messages in thread
From: Pieter Wuille @ 2015-06-12 18:39 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]
If there is a benefit in producing larger more-fee blocks if they propagate
slowly, then there is also a benefit in including high-fee transactions
that are unlikely to propagate quickly through optimized relay protocols
(for example: very recent transactions, or out-of-band receoved ones). This
effect is likely an order of magnitude less important still, but the effect
is likely the same.
On Jun 12, 2015 8:31 PM, "Peter Todd" <pete@petertodd•org> wrote:
> On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote:
> > Nice work, Pieter. You're right that my simulation assumed bandwidth for
> > 'block' messages isn't the bottleneck.
> >
> > But doesn't Matt's fast relay network (and the work I believe we're both
> > planning on doing in the near future to further optimize block
> propagation)
> > make both of our simulations irrelevant in the long-run?
>
> Then simulate first the relay network assuming 100% of txs use it, and
> secondly, assuming 100%-x use it.
>
> For instance, is it in miners' advantage in some cases to sabotage the
> relay network? The analyse say yes, so lets simulate that. Equally even
> the relay network isn't instant.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
[-- Attachment #2: Type: text/html, Size: 1696 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
2015-06-12 16:51 [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed Pieter Wuille
2015-06-12 17:21 ` Gavin Andresen
@ 2015-06-12 18:01 ` Peter Todd
2015-06-12 18:24 ` Mike Hearn
2015-06-14 17:45 ` Jonas Nick
3 siblings, 0 replies; 11+ messages in thread
From: Peter Todd @ 2015-06-12 18:01 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
On Fri, Jun 12, 2015 at 06:51:02PM +0200, Pieter Wuille wrote:
> The configuration used in the code right now simulates two groups of miners
> (one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected
> internally, but are only connected to each other through a slow 2 Mbit/s
> link.
>
> Here are some results.
>
> This shows how the group of smaller miners loses around 8% of their
> relative income (if they create larger blocks, their loss percentage goes
> up slightly further):
To be clear, when you say 8% of their income, you mean revenue, not
profit?
Actual profit margins of something like 5%-10% are likely, so that's an
enormous hit that could make their mining operation completely
non-viable.
--
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
2015-06-12 16:51 [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed Pieter Wuille
2015-06-12 17:21 ` Gavin Andresen
2015-06-12 18:01 ` Peter Todd
@ 2015-06-12 18:24 ` Mike Hearn
2015-06-12 18:26 ` Pieter Wuille
2015-06-14 17:45 ` Jonas Nick
3 siblings, 1 reply; 11+ messages in thread
From: Mike Hearn @ 2015-06-12 18:24 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 262 bytes --]
>
> are only connected to each other through a slow 2 Mbit/s link.
>
That's very slow indeed. For comparison, plain old 3G connections routinely
cruise around 7-8 Mbit/sec.
So this simulation is assuming a speed dramatically worse than a mobile
phone can get!
[-- Attachment #2: Type: text/html, Size: 565 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
2015-06-12 16:51 [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed Pieter Wuille
` (2 preceding siblings ...)
2015-06-12 18:24 ` Mike Hearn
@ 2015-06-14 17:45 ` Jonas Nick
2015-06-18 22:00 ` Tom Harding
3 siblings, 1 reply; 11+ messages in thread
From: Jonas Nick @ 2015-06-14 17:45 UTC (permalink / raw)
To: bitcoin-development
Hi all,
it's a very useful approach to also model fees and you came up with an interesting scenario.
Assuming that you meant that the groups are only connected with a single link,
I've recreated the scenario with Gavin's simulation and got similar results.
The group with the large hashrate does profit overall, but the miners which are not directly
connected to the small group loose:
https://github.com/jonasnick/bitcoin_miningsim/blob/master/analysis/README.md#two-groups-well-connected-internally-but-connected-to-each-other-with-a-single-poor-connection
Moreover, it's important to note that this is not an equilibrium because these miners are better off when they create their own
connections to the small group (see the plot below the other one).
This means that your scenario is not the result of a cartel but the result of a long-term network partition.
When assuming partitions, there are quite a few scenarios where big miners can profit from creating big
blocks. For example, one 40% miner and two groups of three 10% miners, where both groups are connected to the big
miner but they are not connected to each other.
https://github.com/jonasnick/bitcoin_miningsim/blob/master/analysis/README.md#one-big-miner-and-two-partitioned-groups
Best,
Jonas
On 06/12/2015 06:51 PM, Pieter Wuille wrote:
> Hello all,
>
> I've created a simulator for Bitcoin mining which goes a bit further than
> the one Gavin used for his blog post a while ago. The main difference is
> support for links with different latency and bandwidth, because of the
> clustered configuration described below. In addition, it supports different
> block sizes, takes fees into account, does difficulty adjustments, and
> takes processing and mining delays into account. It also simulates longer
> periods of time, and averages the result of many simulations running in
> parallel until the variance on the result is low enough.
>
> The code is here: https://github.com/sipa/bitcoin-net-simul
>
> The configuration used in the code right now simulates two groups of miners
> (one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected
> internally, but are only connected to each other through a slow 2 Mbit/s
> link.
>
> Here are some results.
>
> This shows how the group of smaller miners loses around 8% of their
> relative income (if they create larger blocks, their loss percentage goes
> up slightly further):
>
> Configuration:
> * Miner group 0: 80.000000% hashrate, blocksize 20000000.000000
> * Miner group 1: 20.000000% hashrate, blocksize 1000000.000000
> * Expected average block size: 16200000.000000
> * Average fee per block: 0.250000
> * Fee per byte: 0.0000000154
> Result:
> * Miner group 0: 81.648985% income (factor 1.020612 with hashrate)
> * Miner group 1: 18.351015% income (factor 0.917551 with hashrate)
>
> When fees become more important however, and half of a block's income is
> due to fees, the effect becomes even stronger (a 15% loss), and the optimal
> way to compete for small miners is to create larger blocks as well (smaller
> blocks for them result in even less income):
>
> Configuration:
> * Miner group 0: 80.000000% hashrate, blocksize 20000000.000000
> * Miner group 1: 20.000000% hashrate, blocksize 20000000.000000
> * Expected average block size: 20000000.000000
> * Average fee per block: 25.000000
> * Fee per byte: 0.0000012500
> Result:
> * Miner group 0: 83.063545% income (factor 1.038294 with hashrate)
> * Miner group 1: 16.936455% income (factor 0.846823 with hashrate)
>
> The simulator is not perfect. It doesn't take into account that multiple
> blocks/relays can compete for the same bandwidth, or that nodes cannot
> process multiple blocks at once.
>
> The numbers used may be unrealistic, and I don't mean this as a prediction
> for real-world events. However, it does very clearly show the effects of
> larger blocks on centralization pressure of the system. Note that this also
> does not make any assumption of destructive behavior on the network - just
> simple profit maximalization.
>
> Lastly, the code may be buggy; I only did some small sanity tests with
> simple networks.
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
2015-06-14 17:45 ` Jonas Nick
@ 2015-06-18 22:00 ` Tom Harding
2015-06-19 1:31 ` Yifu Guo
0 siblings, 1 reply; 11+ messages in thread
From: Tom Harding @ 2015-06-18 22:00 UTC (permalink / raw)
To: Pieter Wuille; +Cc: bitcoin-development
On 06/12/2015 06:51 PM, Pieter Wuille wrote:
>> However, it does very clearly show the effects of
>> larger blocks on centralization pressure of the system.
On 6/14/2015 10:45 AM, Jonas Nick wrote:
> This means that your scenario is not the result of a cartel but the result of a long-term network partition.
>
Pieter, to Jonas' point, in your scenario the big miners are all part of
the majority partition, so "centralization pressure" (pressure to merge
with a big miner) cannot be separated from "pressure to be connected to
the majority partition".
I ran your simulation with a large (20%) miner in a 20% minority
partition, and 16 small (5%) miners in a majority 80% partition, well
connected. The starting point was your recent update, which had a more
realistic "slow link" speed of 100 Mbit/s (making all of the effects
smaller).
To summarize the results across both your run and mine:
** Making small blocks when others are making big ones -> BAD
** As above, and fees are enormous -> VERY BAD
** Being separated by a slow link from majority hash power -> BAD
** Being a small miner with blocksize=20MB -> *NOT BAD*
Configuration:
* Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 80.000000% hashrate, blocksize 1000000.000000
* Expected average block size: 4800000.000000
* Average fee per block: 0.250000
* Fee per byte: 0.0000000521
Result:
* Miner group 0: 20.404704% income (factor 1.020235 with hashrate)
* Miner group 1: 79.595296% income (factor 0.994941 with hashrate)
Configuration:
* Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 80.000000% hashrate, blocksize 20000000.000000
* Expected average block size: 20000000.000000
* Average fee per block: 0.250000
* Fee per byte: 0.0000000125
Result:
* Miner group 0: 19.864232% income (factor 0.993212 with hashrate)
* Miner group 1: 80.135768% income (factor 1.001697 with hashrate)
Configuration:
* Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 80.000000% hashrate, blocksize 1000000.000000
* Expected average block size: 4800000.000000
* Average fee per block: 25.000000
* Fee per byte: 0.0000052083
Result:
* Miner group 0: 51.316895% income (factor 2.565845 with hashrate)
* Miner group 1: 48.683105% income (factor 0.608539 with hashrate)
Configuration:
* Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 80.000000% hashrate, blocksize 20000000.000000
* Expected average block size: 20000000.000000
* Average fee per block: 25.000000
* Fee per byte: 0.0000012500
Result:
* Miner group 0: 19.865943% income (factor 0.993297 with hashrate)
* Miner group 1: 80.134057% income (factor 1.001676 with hashrate)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
2015-06-18 22:00 ` Tom Harding
@ 2015-06-19 1:31 ` Yifu Guo
0 siblings, 0 replies; 11+ messages in thread
From: Yifu Guo @ 2015-06-19 1:31 UTC (permalink / raw)
To: Tom Harding; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3572 bytes --]
Nice insight Peter,
This further confirms the real problem, which doesn't have much to do with
blocksize but rather the connectivity of nodes in countries with
not-so-friendly internet policies and deceptive connectivity.
On Thu, Jun 18, 2015 at 6:00 PM, Tom Harding <tomh@thinlink•com> wrote:
> On 06/12/2015 06:51 PM, Pieter Wuille wrote:
> >> However, it does very clearly show the effects of
> >> larger blocks on centralization pressure of the system.
>
> On 6/14/2015 10:45 AM, Jonas Nick wrote:
> > This means that your scenario is not the result of a cartel but the
> result of a long-term network partition.
> >
>
> Pieter, to Jonas' point, in your scenario the big miners are all part of
> the majority partition, so "centralization pressure" (pressure to merge
> with a big miner) cannot be separated from "pressure to be connected to
> the majority partition".
>
> I ran your simulation with a large (20%) miner in a 20% minority
> partition, and 16 small (5%) miners in a majority 80% partition, well
> connected. The starting point was your recent update, which had a more
> realistic "slow link" speed of 100 Mbit/s (making all of the effects
> smaller).
>
> To summarize the results across both your run and mine:
>
> ** Making small blocks when others are making big ones -> BAD
> ** As above, and fees are enormous -> VERY BAD
>
> ** Being separated by a slow link from majority hash power -> BAD
>
> ** Being a small miner with blocksize=20MB -> *NOT BAD*
>
>
> Configuration:
> * Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
> * Miner group 1: 80.000000% hashrate, blocksize 1000000.000000
> * Expected average block size: 4800000.000000
> * Average fee per block: 0.250000
> * Fee per byte: 0.0000000521
> Result:
> * Miner group 0: 20.404704% income (factor 1.020235 with hashrate)
> * Miner group 1: 79.595296% income (factor 0.994941 with hashrate)
>
> Configuration:
> * Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
> * Miner group 1: 80.000000% hashrate, blocksize 20000000.000000
> * Expected average block size: 20000000.000000
> * Average fee per block: 0.250000
> * Fee per byte: 0.0000000125
> Result:
> * Miner group 0: 19.864232% income (factor 0.993212 with hashrate)
> * Miner group 1: 80.135768% income (factor 1.001697 with hashrate)
>
> Configuration:
> * Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
> * Miner group 1: 80.000000% hashrate, blocksize 1000000.000000
> * Expected average block size: 4800000.000000
> * Average fee per block: 25.000000
> * Fee per byte: 0.0000052083
> Result:
> * Miner group 0: 51.316895% income (factor 2.565845 with hashrate)
> * Miner group 1: 48.683105% income (factor 0.608539 with hashrate)
>
> Configuration:
> * Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
> * Miner group 1: 80.000000% hashrate, blocksize 20000000.000000
> * Expected average block size: 20000000.000000
> * Average fee per block: 25.000000
> * Fee per byte: 0.0000012500
> Result:
> * Miner group 0: 19.865943% income (factor 0.993297 with hashrate)
> * Miner group 1: 80.134057% income (factor 1.001676 with hashrate)
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
*Yifu Guo*
*"Life is an everlasting self-improvement."*
[-- Attachment #2: Type: text/html, Size: 5194 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-06-19 1:31 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-12 16:51 [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed Pieter Wuille
2015-06-12 17:21 ` Gavin Andresen
2015-06-12 18:30 ` Peter Todd
2015-06-12 18:39 ` Pieter Wuille
2015-06-12 18:01 ` Peter Todd
2015-06-12 18:24 ` Mike Hearn
2015-06-12 18:26 ` Pieter Wuille
2015-06-12 18:27 ` Mike Hearn
2015-06-14 17:45 ` Jonas Nick
2015-06-18 22:00 ` Tom Harding
2015-06-19 1:31 ` Yifu Guo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox