* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-07 22:02 [Bitcoin-development] Block Size Increase Requirements Matt Corallo
@ 2015-05-07 23:24 ` Joseph Poon
2015-05-08 0:05 ` Peter Todd
` (3 subsequent siblings)
4 siblings, 0 replies; 67+ messages in thread
From: Joseph Poon @ 2015-05-07 23:24 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Dev
Hi Matt,
I agree that starting discussion on how to approach this problem is
necessary and it's difficult taking positions without details on what is
being discussed.
A simple hard 20-megabyte increase will likely create perverse
incentives, perhaps a method can exist with some safe transition. I
think ultimately, the underlying tension with this discussion is about
the relative power of miners. Any transition of blocksize increase will
increase the influence of miners, and it is about understanding the
tradeoffs for each possible approach.
On Thu, May 07, 2015 at 10:02:09PM +0000, Matt Corallo wrote:
> * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system. If we're just building Bitcoin
> to work in five years, great, but if we want it all to keep working as
> subsidy drops significantly, I'd like a better answer than "we'll deal
> with it when we get there" or "it will happen, all the predictions based
> on people's behavior today say so" (which are hopefully invalid thanks
> to the previous point). Ideally, I'd love to see some real free pressure
> already on the network starting to develop when we commit to hardforking
> in a year. Not just full blocks with some fees because wallets are
> including far greater fees than they really need to, but software which
> properly handles fees across the ecosystem, smart fee increases when
> transactions arent confirming (eg replace-by-fee, which could be limited
> to increase-in-fees-only for those worried about double-spends).
I think the long-term fee incentive structure needs to be significantly
more granular. We've all seen miners and pools take the path of least
resistance; often they just do whatever the community tells them to
blindly. While this status quo can change in the future, I think
designing sane defaults is a good path for any possible transition.
It seems especially reasonable to maintain fee pressure for normal
transactions during a hard-fork transition. It's possible to do so using
some kind of soft-cap structure. Building in a default soft-cap of 1
megabyte for some far future scheduled fork would seem like a sane thing
to do for bitcoin-core.
It seems also viable to be far more aggressive. What's your (and the
community's) opinion on some kind of coinbase voting protocol for
soft-cap enforcement? It's possible to write in messages to the coinbase
for a enforcible soft-cap that orphans out any transaction which
violates these rules. It seems safest to have the transition has the
first hardforked block be above 1MB, however, the next block default to
an enforced 1MB block. If miners agree to go above this, they must vote
in their coinbase to do so.
There's a separate discussion about this starting on:
CAE-z3OXnjayLUeHBU0hdwU5pKrJ6fpj7YPtGBMQ7hKXG3Sj6hw@mail•gmail.com
I think defaulting some kind of mechanism on reading the coinbase seems
to be a good idea, I think left alone, miners may not do so. That way,
it's possible to have your cake and eat it too, fee pressure will still
exist, while block sizes can increase (provided it's in the miners'
greater interests to do so).
The Lightning Network's security model in the long-term may rely on a
multi-tier soft-cap, but I'm not sure. If 2nd order systemic miner
incentives were not a concern, a system which has an enforced soft-cap
and permits breaching that soft-cap with some agreed upon much higher
fee would work best. LN works without this, but it seems to be more
secure if some kind of miner consensus rule is reached regarding
prioritizing behavior of 2nd-layer consensus states.
No matter how it's done, certain aspects of the security model of
something like Lightning is reliant upon having block-space
availability for transactions to enter into the blockchain in a timely
manner (since "deprecated" channel states become valid again after some
agreed upon block-time).
I think pretty much everyone agrees that the 1MB block cap will
eventually be a problem. While people may disagree with when that will
be and how it'll play out, I think we're all in agreement that
discussion about it is a good idea, especially when it comes to
resolving blocking concerns.
Starting a discussion on how a hypothetical blocksize increase will
occur and the necessary blocking/want-to-have features/tradeoffs seems
to be a great way to approach this problem. The needs for Lightning
Network may be best optimized by being able to prioritizing a large mass
of timeout transactions at once (when a well-connected node stops
communicating).
--
Joseph Poon
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-07 22:02 [Bitcoin-development] Block Size Increase Requirements Matt Corallo
2015-05-07 23:24 ` Joseph Poon
@ 2015-05-08 0:05 ` Peter Todd
2015-05-08 6:33 ` Arkady
2015-05-08 10:03 ` Mike Hearn
` (2 subsequent siblings)
4 siblings, 1 reply; 67+ messages in thread
From: Peter Todd @ 2015-05-08 0:05 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5667 bytes --]
On Thu, May 07, 2015 at 10:02:09PM +0000, Matt Corallo wrote:
> OK, so lets do that. I've seen a lot of "I'm not entirely comfortable
> with committing to this right now, but think we should eventually", but
> not much "I'd be comfortable with committing to this when I see X". In
> the interest of ignoring debate and pushing people towards a consensus
> at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the
> second.
>
> Personally, there are several things that worry me significantly about
> committing to a blocksize increase, which I'd like to see resolved
> before I'd consider supporting a blocksize increase commitment.
>
> * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today. I'd expect to see these not only implemented but
> being used in production (though I dont particularly care about them
> being all that stable). I'd want to see measurements of how they perform
> both in production and in the face of high packet loss (eg across the
> GFW or in the case of small/moderate DoS). In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the system.
It's really important that we remember that we're building security
software: it *must* hold up well even in the face of attack. That means
we need to figure out how it can be attacked, what the cost/profits of
such attacks are, and if the holes can be patched. Just testing the
software with simulated loads is insufficient.
Also, re: breaking, don't forget that this may not be a malicious act.
For instance, someone can send contradictory transactions to different
parts of the network simultaneously to prevent mempool consistency -
there's no easy way to fix this. There are also cases where miners have
different policy than others, e.g. version disagreements, commercial
contracts for tx mining, etc.
Finally, remember that it's not in miners' incentives in many situations
for their blocks to propagate to more than ~30% of the hashing power.(1)
Personally, I'm really skeptical that we'll ever find a block
propagation latency reduction technique that sucesfully meets all the
above criteria without changing the consensus algorithm itself.
* How do we ensure miners don't cheat and stop validating blocks fully
before building on them? This is a significant moral hazard with larger
blocks if fees don't become significant, and can lead to dangerous
forks. Also, think of the incentives: Why would a miner ever switch from
the longest chain, even if they don't actually have the blocks to back
it up?
* We need a clear understanding of how we expect new full nodes, pruned
or not, to sync up to the blockchain. Obviously 20MB blocks
significantly increases the time and data required to sync. Are we
planning on simply giving up on full validation and trusting others for
copies of UTXO sets? Are we going to rely on UTXO commitments? What
happens if the UTXO set size itself increases greatly?
> * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace. I know StrawPay is working on development,
> though its not obvious to me how far they are from their website, but I
> dont know of any commitments by large players (either SPV wallets,
> centralized wallet services, payment processors, or any others) to
> support such a system (to be fair, its probably too early for such
> players to commit to anything, since anything doesnt exist in public).
A good start would be for those players to commit to the general
principles of these systems; if they can't commit explain why.
For instance I'd be very interested in knowing if services like Coinbase
see legal issues with adopting technologies such as payment channels
between hosted wallet providers, payment processors, etc. I certainly
wouldn't be surprised if they see doing anythign not on-blockchain as a
source of legal uncertainty - based on discussions I've had with
regulatory types in this space it sounds like there's a reasonable
chance protocol details such as requiring that transactions happen on a
public blockchain will be "baked into" regulatory requirements.
> * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system. If we're just building Bitcoin
> to work in five years, great, but if we want it all to keep working as
> subsidy drops significantly, I'd like a better answer than "we'll deal
> with it when we get there" or "it will happen, all the predictions based
> on people's behavior today say so" (which are hopefully invalid thanks
> to the previous point). Ideally, I'd love to see some real free pressure
> already on the network starting to develop when we commit to hardforking
> in a year.
Agreed.
> Not just full blocks with some fees because wallets are
> including far greater fees than they really need to, but software which
> properly handles fees across the ecosystem, smart fee increases when
> transactions arent confirming (eg replace-by-fee, which could be limited
> to increase-in-fees-only for those worried about double-spends).
FWIW I've got some funding to implement first-seen-safe replace-by-fee.
1) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html
--
'peter'[:-1]@petertodd.org
00000000000000000fe0a96ac84aeb2e4e5c246e947cd8e759bd5fb158a16caf
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-08 0:05 ` Peter Todd
@ 2015-05-08 6:33 ` Arkady
0 siblings, 0 replies; 67+ messages in thread
From: Arkady @ 2015-05-08 6:33 UTC (permalink / raw)
To: Bitcoin Dev
--[remove this line and above]--
On Thu, 7 May 2015, Gregory Maxwell wrote:
> Date: Thu, 7 May 2015 00:37:54 +0000
> From: Gregory Maxwell <gmaxwell@gmail•com>
> To: Matt Corallo <bitcoin-list@bluematt•me>
> Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
> Subject: Re: [Bitcoin-development] Block Size Increase
>
> Thanks Matt; I was actually really confused by this sudden push with
> not a word here or on Github--so much so that I responded on Reddit to
> people pointing to commits in Gavin's personal repository saying they
> were reading too much into it.
I saw this. I was also pointing this out to the people who were asking
me. A
commit to a personal repository does not at first seem more than
experimental. sipa commits weird/neat things to private branches all the
time, after all.
> to share behavior. In the case of mining, we're trying to optimize the
> social good of POW security. (But the analogy applies in other ways
> too:
About the only argument IMO in favour of block size increases is to
assume
that making more room in a block will make it attractive to use for more
people at some point in the future: increasing transaction velocity,
increasing economy size, increasing value overall.
> increases to the chain side are largely an externality; miners enjoy
> the
> benefits, everyone else takes the costs--either in reduced security or
> higher node operating else.)
Who else but miners and pool operators will run full nodes when full
nodes
are being shut down because they are too large and unwieldy to maintain?
It
is already so that casual users refuse to run full nodes. This fact is
indisputable. The only question remaining is, "Do we care?" Arguments
against users who feel that the dataset is too large to run a full node,
full-time, start from a premise that these users are a static and
irrelevant
fraction. Is this even true? "Do we care?" I do. I will shortly only be
able
to run half the nodes I currently do thanks to the growth of the
blockchain
at its current rate.
> One potential argument is that maybe miners would be _regulated_ to
> behave correctly. But this would require undermining the openness of
> the
> system--where anyone can mine anonymously--in order to enforce
> behavior,
> and that same enforcement mechanism would leave a political level to
> impose additional rules that violate the extra properties of the
> system.
I would refuse to mine under such a regulated regime; moreover, I would
enjoy forking away from this, and, I suspect, the only miners who remain
would be those whose ultimate motivations do not coincide with the
users.
That is, the set of miners who are users, and the set of users who are
miners, would be wholly non-intersecting.
> So far the mining ecosystem has become incredibly centralized over
> time.
This is unfortunate but true.
> of the regular contributors to Bitcoin Core do. Many participants
> have never mined or only did back in 2010/2011... we've basically
> ignored the mining ecosystem, and this has had devastating effects,
> causing a latent undermining of the security model: hacking a dozen or
> so computers--operated under totally unknown and probably not strong
> security policies--could compromise the network at least at the tip...
The explicit form of the block dictated by the reference client and
agreed-to by the people who were sold on bitcoin near the beginning
(myself
included) was explicitly the notion that the rules were static; that the
nature of transaction foundations and the subsidies would not be
altered.
Here we have a hardfork being contemplated which is not only
controversial,
but does not even address some of the highest-utility and most-requested
features in peoples' hardfork wishlists.
The fact that mining has effectively been centralized directly implies
that
destabilizing changes that some well-heeled (and thus theoretically
capable,
at least) people have explicitly begun plans to fork the blockchain
about
will have an unknown, and completely unforeseen combined effect.
We can pretend that, "If merchants and miners and exchanges go along,
then
who else matters," but the reality is that the value in bitcoin exists
because *people* use it for real transactions: Not miners, whose profits
are
parasitically fractionally based on the quality and strength of the
bitcoin
economy as a whole; not exchanges who lubricate transactions in service
to
the economy; not even today's merchants whose primary means of accepting
bitcoin seems to be to convert them instantly to fiat and not
participate
meaningfully in the economy at all; not enriched felons; but actual
users
themselves.
> Rightfully we should be regarding this an an emergency, and probably
> should have been have since 2011.
There are two ways to look at it, assuming that the blocksize change
increases bitcoin's value to people after all: mining centralization
will be
corrected; or, mining centralization will not be corrected.
I would argue that rapidly increasing profitability at this point will
exacerbate the mining centralization problem, and in much the same way
as
when people were throwing money and unknowingly funding the massive
frauds
of the current cabals when bitcoin's exchange-driven rise to $1200 was
first
realized.
Thus, even if the premise were true, what will a blocksize increase
achieve
given mining centralization itself is a bigger systemic risk?
> Hardfork changes should only be made if they're almost completely
> uncontroversial--where virtually everyone can look at the available
> data
> and say "yea, that isn't undermining my property rights or future use
> of Bitcoin; it's no big deal".
The recent "revelation" that there are masses of paid trolls on popular
forum sites like reddit who supposedly don't even know who is hiring
them,
and the anger of more vociferous commenters in general, does not
invalidate
the relevance of every non-"industry" voice. I think elevating the
discussion away from the users does the system and the development
process
as a whole quite an injustice.
> I'm curious as to what discussions people have seen; e.g., are people
> even here aware of these concerns? Are you aware of things like the
> hashcash mediated dynamic blocksize limiting?
I have seen most of these; or the ideas seem obvious based on their
names.
> About proposals like lightning network (instant transactions and
> massive
> scale, in exchange for some short term DOS risk if a counterparty opts
> out)? Do people (other than Mike Hearn; I guess) think a future where
> everyone depends on a small number of "Google scale" node operations
> for
> the system is actually okay? (I think not, and if so we're never going
> to
> agree--but it can be helpful to understand when a disagreement is
> ideological).
It is not okay. If the current mining cabals continue to exist, and
flourish, and the developers make major changes that ignore this glaring
elephant, then the decentralized promise of bitcoin will be put more at
risk.
signmessage 1DdcrjT9Yqb6U58wVMA2e7untFbz2rmZd4
"49786791f4d0a260689867ccdfb2cc5b8460984e335504444ade113d2768505c"
G6NPl7Wklo9lcdgeVI2H2pexzgqD0KPHhI/wAe32DBm8m59Qf31j5d4tsx5drcql/8wPeIb0QGarr/o4VIOLLGE=
--[remove this line and below]--
HHsTfiZ/S7+GNYRwws+QyAr+6/MgDz0Jyntl7CAvjhdfzbnwPorybQUXxRw3CE4DgYgAy1zLanE8H/5NK+l3UlE=
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-07 22:02 [Bitcoin-development] Block Size Increase Requirements Matt Corallo
2015-05-07 23:24 ` Joseph Poon
2015-05-08 0:05 ` Peter Todd
@ 2015-05-08 10:03 ` Mike Hearn
2015-05-08 16:37 ` Peter Todd
2015-05-29 22:36 ` Gavin Andresen
2015-05-29 23:42 ` Chun Wang
4 siblings, 1 reply; 67+ messages in thread
From: Mike Hearn @ 2015-05-08 10:03 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]
>
> * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.
With a 20mb cap, miners still have the option of the soft limit.
I would actually be quite surprised if there were no point along the road
from 1mb to 20mb where miners felt a need to throttle their block sizes
artificially, for the exact reason you point out: propagation delays.
But we don't *need* to have fancy protocol upgrades implemented right now.
All we need is to demolish one bottleneck (the hard cap) so we can then
move on and demolish the next one (whatever that is, probably faster
propagation). Scaling is a series of walls we punch through as we encounter
them. One down, onto the next. We don't have to tackle them all
simultaneously.
FWIW I don't think the GFW just triggers packet loss, these days. It's
blocked port 8333 entirely.
* I'd very much like to see someone working on better scaling
> technology ... I know StrawPay is working on development,
>
So this request is already satisfied, isn't it? As you point out, expecting
more at this stage in development is unreasonable, there's nothing for
anyone to experiment with or commit to.
They have code here, by the way:
https://github.com/strawpay
You can find their fork of MultiBit HD, their implementation library, etc.
They've contributed patches and improvements to the payment channels code
we wrote.
> * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system.
>
What are your thoughts on using assurance contracts to fund network
security?
I don't *know* if hashing assurance contracts (HACs) will work. But I don't
know they won't work either. And right now I'm pretty sure that plain old
fee pressure won't work. Demand doesn't outstrip supply forever - people
find substitutes.
[-- Attachment #2: Type: text/html, Size: 2904 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-08 10:03 ` Mike Hearn
@ 2015-05-08 16:37 ` Peter Todd
2015-05-08 19:47 ` Tier Nolan
0 siblings, 1 reply; 67+ messages in thread
From: Peter Todd @ 2015-05-08 16:37 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
On Fri, May 08, 2015 at 12:03:04PM +0200, Mike Hearn wrote:
> >
> > * Though there are many proposals floating around which could
> > significantly decrease block propagation latency, none of them are
> > implemented today.
>
>
> With a 20mb cap, miners still have the option of the soft limit.
The soft-limit is there miners themselves produce smaller blocks; the
soft-limit does not prevent other miners from producing larger blocks.
As we're talking about ways that other miners can use 20MB blocks to
harm the competition, talking about the soft-limit is irrelevant.
Similarly, as security engineers we must plan for the worst case; as
we've seen before by your campaigns to raise the soft-limit(1) even at a
time when the vast majority of transaction volume was from one user
(SatoshiDice) soft-limits are an extremely weak form of control.
For the proposes of discussing blocksize increase requirements we can
stop talking about the soft-limit.
1) https://bitcointalk.org/index.php?topic=149668.0
--
'peter'[:-1]@petertodd.org
000000000000000009344ba165781ee352f93d657c8b098c8e518e6011753e59
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-08 16:37 ` Peter Todd
@ 2015-05-08 19:47 ` Tier Nolan
2015-05-09 3:08 ` Peter Todd
0 siblings, 1 reply; 67+ messages in thread
From: Tier Nolan @ 2015-05-08 19:47 UTC (permalink / raw)
Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]
On Fri, May 8, 2015 at 5:37 PM, Peter Todd <pete@petertodd•org> wrote:
> The soft-limit is there miners themselves produce smaller blocks; the
> soft-limit does not prevent other miners from producing larger blocks.
>
I wonder if having a "miner" flag would be good for the network.
Clients for general users and merchants would have a less strict rule than
the rule for miners. Miners who don't set their miners flag might get
orphaned off the chain.
For example, the limits could be setup as follows.
Clients: 20MB
Miners: 4MB
When in "miner mode", the client would reject 4MB blocks and wouldn't build
on them. The reference client might even track the miner and the non-miner
chain tip.
Miners would refuse to build on 5MB blocks, but merchants and general users
would accept them.
This allows the miners to soft fork the limit at some point in the future.
If 75% of miners decided to up the limit to 8MB, then all merchants and the
general users would accept the new blocks. It could follow the standard
soft fork rules.
This is a more general version of the system where miners are allowed to
vote on the block size (subject to a higher limit).
A similar system is where clients track all header trees. Your wallet
could warn you that there is an invalid tree that has > 75% of the hashing
power and you might want to upgrade.
[-- Attachment #2: Type: text/html, Size: 1886 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-08 19:47 ` Tier Nolan
@ 2015-05-09 3:08 ` Peter Todd
2015-05-16 4:39 ` Stephen
2015-05-16 11:25 ` Tier Nolan
0 siblings, 2 replies; 67+ messages in thread
From: Peter Todd @ 2015-05-09 3:08 UTC (permalink / raw)
To: Tier Nolan; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]
On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote:
> On Fri, May 8, 2015 at 5:37 PM, Peter Todd <pete@petertodd•org> wrote:
>
> > The soft-limit is there miners themselves produce smaller blocks; the
> > soft-limit does not prevent other miners from producing larger blocks.
> >
>
> I wonder if having a "miner" flag would be good for the network.
Makes it trivial to find miners and DoS attack them - a huge risk to the
network as a whole, as well as the miners.
Right now pools already get DoSed all the time through their work
submission systems; getting DoS attacked via their nodes as well would
be a disaster.
> When in "miner mode", the client would reject 4MB blocks and wouldn't build
> on them. The reference client might even track the miner and the non-miner
> chain tip.
>
> Miners would refuse to build on 5MB blocks, but merchants and general users
> would accept them.
That'd be an excellent way to double-spend merchants, significantly
increasing the chance that the double-spend would succeed as you only
have to get sufficient hashing power to get the lucky blocks; you don't
need enough hashing power to *also* ensure those blocks don't become the
longest chain, removing the need to sybil attack your target.
--
'peter'[:-1]@petertodd.org
000000000000000004bd67400df7577a30e6f509b6bd82633efeabe6395eb65a
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-09 3:08 ` Peter Todd
@ 2015-05-16 4:39 ` Stephen
2015-05-16 11:29 ` Tier Nolan
2015-05-16 11:25 ` Tier Nolan
1 sibling, 1 reply; 67+ messages in thread
From: Stephen @ 2015-05-16 4:39 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
Comments in line:
> On May 8, 2015, at 11:08 PM, Peter Todd <pete@petertodd•org> wrote:
>
> Makes it trivial to find miners and DoS attack them - a huge risk to the
> network as a whole, as well as the miners.
>
> Right now pools already get DoSed all the time through their work
> submission systems; getting DoS attacked via their nodes as well would
> be a disaster.
It seems that using a -miner flag to follow rules about smaller blocks would only reveal miner nodes if one sent the node a solved block that that was valid in every way except the block size. While not impossible, I wouldn't call this trivial, as it still requires wasting an entire block's worth of energy.
>> When in "miner mode", the client would reject 4MB blocks and wouldn't build
>> on them. The reference client might even track the miner and the non-miner
>> chain tip.
>>
>> Miners would refuse to build on 5MB blocks, but merchants and general users
>> would accept them.
>
> That'd be an excellent way to double-spend merchants, significantly
> increasing the chance that the double-spend would succeed as you only
> have to get sufficient hashing power to get the lucky blocks; you don't
> need enough hashing power to *also* ensure those blocks don't become the
> longest chain, removing the need to sybil attack your target.
>
I think this could be mitigated by counting confirmations differently. We should think of confirmations as only coming from blocks following the miners' more strict rule set. So if a merchant were to see payment for the first time in a block that met their own size restrictions but not the miners', then they would simply count it as unconfirmed.
If they get deep enough in the chain, though, the client should probably count them as being confirmed anyway, even if they don't meet the client nodes' expectation of the miners' block size limit. This happening probably just means that the client has not updated their software (or -minermaxblocksize configuration, depending on how it is implemented) in a long time.
I actually like Tier's suggestion quite a bit. I think we could have the default client limit set to some higher number, and have miners agree out of band on the latest block size limit. Or maybe even build in a way to vote into the blockchain.
Best,
Stephen
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-16 4:39 ` Stephen
@ 2015-05-16 11:29 ` Tier Nolan
0 siblings, 0 replies; 67+ messages in thread
From: Tier Nolan @ 2015-05-16 11:29 UTC (permalink / raw)
Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]
On Sat, May 16, 2015 at 5:39 AM, Stephen <stephencalebmorse@gmail•com>
wrote:
> I think this could be mitigated by counting confirmations differently. We
> should think of confirmations as only coming from blocks following the
> miners' more strict rule set. So if a merchant were to see payment for the
> first time in a block that met their own size restrictions but not the
> miners', then they would simply count it as unconfirmed.
>
In effect, there is a confirm penalty for less strict blocks. Confirms =
max(miner_confirms, merchant_confirms - 3, 0)
Merchants who don't upgrade end up having to wait longer to hit
confirmations.
If they get deep enough in the chain, though, the client should probably
> count them as being confirmed anyway, even if they don't meet the client
> nodes' expectation of the miners' block size limit. This happening probably
> just means that the client has not updated their software (or
> -minermaxblocksize configuration, depending on how it is implemented) in a
> long time.
>
That is a good idea. Any parameters that have miner/merchant differences
should be modifiable (but only upwards) in the command line.
"Why are my transactions taking longer to confirm?"
"There was a soft fork to make the block size larger and your client is
being careful. You need to add "minermaxblocksize=4MB" to your
bitcoin.conf file."
Hah, it could be called a "semi-hard fork"?
[-- Attachment #2: Type: text/html, Size: 2089 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-09 3:08 ` Peter Todd
2015-05-16 4:39 ` Stephen
@ 2015-05-16 11:25 ` Tier Nolan
1 sibling, 0 replies; 67+ messages in thread
From: Tier Nolan @ 2015-05-16 11:25 UTC (permalink / raw)
Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]
On Sat, May 9, 2015 at 4:08 AM, Peter Todd <pete@petertodd•org> wrote:
> > I wonder if having a "miner" flag would be good for the network.
>
> Makes it trivial to find miners and DoS attack them - a huge risk to the
> network as a whole, as well as the miners.
>
To mitigate against this, two chaintips could be tracked. The miner tip
and the client tip.
Miners would build on the miner tip. When performing client services, like
wallets, they would use the client tip.
The client would act exactly the same as any node, the only change would be
that it gives miner work based on the mining tip.
If the two tips end up significantly forking, there would be a warning to
the miner and perhaps eventually refuse to give out new work.
That would happen when there was a miner level hard-fork.
> That'd be an excellent way to double-spend merchants, significantly
> increasing the chance that the double-spend would succeed as you only
> have to get sufficient hashing power to get the lucky blocks; you don't
> need enough hashing power to *also* ensure those blocks don't become the
> longest chain, removing the need to sybil attack your target.
>
To launch that attack, you need to produce fake blocks. That is
expensive.
Stephen Cale's suggestion to wait more than one block before counting a
transaction as confirmed would also help mitigate.
[-- Attachment #2: Type: text/html, Size: 2036 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-07 22:02 [Bitcoin-development] Block Size Increase Requirements Matt Corallo
` (2 preceding siblings ...)
2015-05-08 10:03 ` Mike Hearn
@ 2015-05-29 22:36 ` Gavin Andresen
2015-05-29 23:25 ` Matt Corallo
2015-05-29 23:42 ` Chun Wang
4 siblings, 1 reply; 67+ messages in thread
From: Gavin Andresen @ 2015-05-29 22:36 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
Matt brought this up on Twitter, I have no idea why I didn't respond weeks
ago (busy writing blog posts, probably):
On Thu, May 7, 2015 at 6:02 PM, Matt Corallo <bitcoin-list@bluematt•me>
wrote:
>
>
> * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.
If block propagation isn't fixed, then mines have a strong incentive to
create smaller blocks.
So the max block size is irrelevant, it won't get hit.
> In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the system.
>
See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
for analysis of "but that means bigger miners can get an advantage"
argument.
Executive summary: if little miners are stupid and produce huge blocks,
then yes, big miners have an advantage.
But they're not, so they won't.
Until the block reward goes away, and assuming transaction fees become an
important source of revenue for miners.
I think it is too early to worry about that; see:
http://gavinandresen.ninja/when-the-block-reward-goes-away
> * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace.
Ok. What does this have to do with the max block size?
Are you arguing that work won't happen if the max block size increases?
* I'd like to see some better conclusions to the discussion around
> long-term incentives within the system.
Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away for
what I think about that.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 3299 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-29 22:36 ` Gavin Andresen
@ 2015-05-29 23:25 ` Matt Corallo
[not found] ` <CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Matt Corallo @ 2015-05-29 23:25 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
On 05/29/15 22:36, Gavin Andresen wrote:
> Matt brought this up on Twitter, I have no idea why I didn't respond
> weeks ago (busy writing blog posts, probably):
>
> On Thu, May 7, 2015 at 6:02 PM, Matt Corallo <bitcoin-list@bluematt•me
> <mailto:bitcoin-list@bluematt•me>> wrote:
>
>
>
> * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.
>
>
> If block propagation isn't fixed, then mines have a strong incentive to
> create smaller blocks.
>
> So the max block size is irrelevant, it won't get hit.
Sadly, this is very far from the whole story. The issue of miners
optimizing for returns has been discussed several times during this
discussion, and, sadly, miners who are geographically colocated who are
optimizing for returns with a free-floating blocksize will optimize away
50% of the network!
>
> In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the
> system.
>
>
> See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for
> analysis of "but that means bigger miners can get an advantage" argument.
>
> Executive summary: if little miners are stupid and produce huge blocks,
> then yes, big miners have an advantage.
I'll talk about transaction fees in a second, but there are several
problems with this already. As pointed out in the original mail, gfw has
already been known to interfere with Bitcoin P2P traffic. So now by
"little" miners, you mean any miner who is not located in mainland
China? Whats worse, the disadvantage is symmetric - little miners are at
a disadvantage when *anyone* mines a bigger block, and miners dont even
have to be "evil" for this to happen - just optimize for profits.
> But they're not, so they won't.
I dont know what you're referring to with this. Are you claiming little
miners today optimize for relay times and have good visibility into the
Bitcoin network and calculate an optimal block size based on this (or
would with a 20MB block size)?
> Until the block reward goes away, and assuming transaction fees become
> an important source of revenue for miners.
> I think it is too early to worry about that; see:
>
> http://gavinandresen.ninja/when-the-block-reward-goes-away
You dont make any points here with which I can argue, but let me respond
with the reason /I/ think it is a problem worth thinking a little bit
about...If we increase the blocksize sufficiently such that transaction
fees are not the way in which miners make their money, then either
miners are not being funded (ie hashpower has to drop to very little),
or the only people mining/funding miners are large orgs who are
"running" Bitcoin (ie the web wallets, payment processors, big
merchants, and exchanges of the world). Sadly, this is no longer a
decentralized Bitcoin and is, in fact, pretty much how the banking world
works today.
I'm not sure who, if anyone, claims Bitcoin is novel or interesting for
any reason other than its decentralization properties, and, in a world
which you are apparently proposing, the "natural" course of things is to
very strongly centralize.
> * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace.
>
>
> Ok. What does this have to do with the max block size?
>
> Are you arguing that work won't happen if the max block size increases?
Yes, I am arguing that by increasing the blocksize the incentives to
actually make Bitcoin scale go away. Even if amazing technologies get
built, no one will have any reason to use them.
> * I'd like to see some better conclusions to the discussion around
>
> long-term incentives within the system.
>
>
> Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away
> for what I think about that.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-07 22:02 [Bitcoin-development] Block Size Increase Requirements Matt Corallo
` (3 preceding siblings ...)
2015-05-29 22:36 ` Gavin Andresen
@ 2015-05-29 23:42 ` Chun Wang
2015-05-30 13:57 ` Gavin Andresen
2015-05-31 7:05 ` [Bitcoin-development] " Peter Todd
4 siblings, 2 replies; 67+ messages in thread
From: Chun Wang @ 2015-05-29 23:42 UTC (permalink / raw)
To: Bitcoin Dev
Hello. I am from F2Pool. We are currently mining the biggest blocks on
the network. So far top 100 biggest bitcoin blocks are all from us. We
do support bigger blocks and sooner rather than later. But we cannot
handle 20 MB blocks right now. I know most blocks would not be 20 MB
over night. But only if a small fraction of blocks more than 10 MB, it
could dramatically increase of our orphan rate, result of higher fee
to miners. Bad miners could attack us and the network with artificial
big blocks. As yhou know, other Chinese pools, AntPool, BW, they
produces ASIC chips and mining mostly with their own machines. They do
not care about a few percent of orphan increase as much as we do. They
would continue their zero fee policy. We would be the biggest loser.
As the exchanges had taught us, zero fee is not health to the network.
Also we have to redevelop our block broadcast logic. Server bandwidth
is a lot more expensive in China. And the Internet is slow. Currently
China has more than 50% of mining power, if block size increases, I
bet European and American pools could suffer more than us. We think
the max block size should be increased, but must be increased
smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
and so on. Thanks.
On Fri, May 8, 2015 at 6:02 AM, Matt Corallo <bitcoin-list@bluematt•me> wrote:
> OK, so lets do that. I've seen a lot of "I'm not entirely comfortable
> with committing to this right now, but think we should eventually", but
> not much "I'd be comfortable with committing to this when I see X". In
> the interest of ignoring debate and pushing people towards a consensus
> at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the
> second.
>
> Personally, there are several things that worry me significantly about
> committing to a blocksize increase, which I'd like to see resolved
> before I'd consider supporting a blocksize increase commitment.
>
> * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today. I'd expect to see these not only implemented but
> being used in production (though I dont particularly care about them
> being all that stable). I'd want to see measurements of how they perform
> both in production and in the face of high packet loss (eg across the
> GFW or in the case of small/moderate DoS). In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the system.
>
> * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace. I know StrawPay is working on development,
> though its not obvious to me how far they are from their website, but I
> dont know of any commitments by large players (either SPV wallets,
> centralized wallet services, payment processors, or any others) to
> support such a system (to be fair, its probably too early for such
> players to commit to anything, since anything doesnt exist in public).
>
> * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system. If we're just building Bitcoin
> to work in five years, great, but if we want it all to keep working as
> subsidy drops significantly, I'd like a better answer than "we'll deal
> with it when we get there" or "it will happen, all the predictions based
> on people's behavior today say so" (which are hopefully invalid thanks
> to the previous point). Ideally, I'd love to see some real free pressure
> already on the network starting to develop when we commit to hardforking
> in a year. Not just full blocks with some fees because wallets are
> including far greater fees than they really need to, but software which
> properly handles fees across the ecosystem, smart fee increases when
> transactions arent confirming (eg replace-by-fee, which could be limited
> to increase-in-fees-only for those worried about double-spends).
>
> I probably forgot one or two and certainly dont want to back myself into
> a corner on committing to something here, but those are a few things I
> see today as big blockers on larger blocks.
>
> Luckily, people have been making progress on building the software
> needed in all of the above for a while now, but I think they're all
> very, very immature today.
>
> On 05/07/15 19:13, Jeff Garzik wrote:> On Thu, May 7, 2015 at 3:03 PM,
> Matt Corallo <bitcoin-list@bluematt•me
>> <mailto:bitcoin-list@bluematt•me>> wrote:
> -snip-
>>> If, instead, there had been an intro on the list as "I think we should
>>> do the blocksize increase soon, what do people think?", the response
>>> could likely have focused much more around creating a specific list of
>>> things we should do before we (the technical community) think we are
>>> prepared for a blocksize increase.
>>
>> Agreed, but that is water under the bridge at this point. You - rightly
>> - opened the topic here and now we're discussing it.
>>
>> Mike and Gavin are due the benefit of doubt because making a change to a
>> leaderless automaton powered by leaderless open source software is
>> breaking new ground. I don't focus so much on how we got to this point,
>> but rather, where we go from here.
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-29 23:42 ` Chun Wang
@ 2015-05-30 13:57 ` Gavin Andresen
2015-05-30 14:08 ` Pindar Wong
` (2 more replies)
2015-05-31 7:05 ` [Bitcoin-development] " Peter Todd
1 sibling, 3 replies; 67+ messages in thread
From: Gavin Andresen @ 2015-05-30 13:57 UTC (permalink / raw)
To: Chun Wang; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]
On Fri, May 29, 2015 at 7:42 PM, Chun Wang <1240902@gmail•com> wrote:
> Hello. I am from F2Pool. We are currently mining the biggest blocks on
> the network.
Thanks for giving your opinion!
> Bad miners could attack us and the network with artificial
> big blocks.
How?
I ran some simulations, and I could not find a network topology where a big
miner producing big blocks could cause a loss of profit to another miner
(big or small) producing smaller blocks:
http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
(the 0.3% advantage I DID find was for the situation where EVERYBODY was
producing big blocks).
> We think
> the max block size should be increased, but must be increased
> smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
> and so on. Thanks.
Why 2 MB ? You said that server bandwidth is much more expensive in
China; what would be the difference in your bandwidth costs between 2MB
blocks and 20MB blocks?
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 2044 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-30 13:57 ` Gavin Andresen
@ 2015-05-30 14:08 ` Pindar Wong
2015-05-30 22:05 ` Alex Mizrahi
[not found] ` <CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
2 siblings, 0 replies; 67+ messages in thread
From: Pindar Wong @ 2015-05-30 14:08 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]
On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen <gavinandresen@gmail•com>
wrote:
> On Fri, May 29, 2015 at 7:42 PM, Chun Wang <1240902@gmail•com> wrote:
>
>> Hello. I am from F2Pool. We are currently mining the biggest blocks on
>> the network.
>
>
> Thanks for giving your opinion!
>
>
>
>> Bad miners could attack us and the network with artificial
>> big blocks.
>
>
> How?
>
> I ran some simulations, and I could not find a network topology where a
> big miner producing big blocks could cause a loss of profit to another
> miner (big or small) producing smaller blocks:
>
> http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
>
> (the 0.3% advantage I DID find was for the situation where EVERYBODY was
> producing big blocks).
>
>
>> We think
>> the max block size should be increased, but must be increased
>> smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
>> and so on. Thanks.
>
>
> Why 2 MB ? You said that server bandwidth is much more expensive in
> China; what would be the difference in your bandwidth costs between 2MB
> blocks and 20MB blocks?
>
Perhaps we should arrange to run some more 'simulations' with miners from
China and elsewhere?
Let me know there's interest to do.
p.
>
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 3379 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-30 13:57 ` Gavin Andresen
2015-05-30 14:08 ` Pindar Wong
@ 2015-05-30 22:05 ` Alex Mizrahi
2015-05-30 23:16 ` Brian Hoffman
2015-05-31 5:05 ` gb
[not found] ` <CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
2 siblings, 2 replies; 67+ messages in thread
From: Alex Mizrahi @ 2015-05-30 22:05 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
> Why 2 MB ?
>
Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
Why not grow it by 1 MB per year?
This is a safer option, I don't think that anybody claims that 2 MB blocks
will be a problem.
And in 10 years when we get to 10 MB we'll get more evidence as to whether
network can handle 10 MB blocks.
So this might be a solution which would satisfy both sides:
* people who are concerned about block size growth will have an
opportunity to stop it before it grows too much (e.g. with a soft fork),
* while people who want bigger blocks will get an equivalent of 25% per
year growth within the first 10 years, which isn't bad, is it?
So far I haven't heard any valid arguments against linear growth.
[-- Attachment #2: Type: text/html, Size: 1217 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-30 22:05 ` Alex Mizrahi
@ 2015-05-30 23:16 ` Brian Hoffman
2015-05-31 0:13 ` Alex Mizrahi
2015-05-31 5:05 ` gb
1 sibling, 1 reply; 67+ messages in thread
From: Brian Hoffman @ 2015-05-30 23:16 UTC (permalink / raw)
To: Alex Mizrahi; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]
> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
Do you anticipate linear growth?
> On May 30, 2015, at 6:05 PM, Alex Mizrahi <alex.mizrahi@gmail•com> wrote:
>
>
>> Why 2 MB ?
>
> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
>
> Why not grow it by 1 MB per year?
> This is a safer option, I don't think that anybody claims that 2 MB blocks will be a problem.
> And in 10 years when we get to 10 MB we'll get more evidence as to whether network can handle 10 MB blocks.
>
> So this might be a solution which would satisfy both sides:
> * people who are concerned about block size growth will have an opportunity to stop it before it grows too much (e.g. with a soft fork),
> * while people who want bigger blocks will get an equivalent of 25% per year growth within the first 10 years, which isn't bad, is it?
>
> So far I haven't heard any valid arguments against linear growth.
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 2464 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-30 23:16 ` Brian Hoffman
@ 2015-05-31 0:13 ` Alex Mizrahi
0 siblings, 0 replies; 67+ messages in thread
From: Alex Mizrahi @ 2015-05-31 0:13 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2720 bytes --]
> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
>
> Do you anticipate linear growth?
>
It's safe to say that absolutely nobody can predict the actual growth with
any degree of an accuracy.
I believe that linear growth compares very favorably to other alternatives:
1. Exponential growth: Linear growth is better at modelling diminishing
returns, that is, risk that it grows too much is much smaller. At the same
time initially it will grow faster than reasonable exponential models.
E.g. linear year-over-year relative growth: 100% 50% 33% 25% ...10%
While exponential one which gives the same result in 10 years:
25% 25% ... 25%
This is on the same scale, but exponential starts slower than we want at
start (1.25 MB will be too little for 2016 as we already see fully filled 1
MB blocks), but goes a bit too fast in the long term. It's highly unlikely
we'll see bandwidth growing 10x each 10 years in the long term.
2. Single step increase: an obvious advantage is that linear growth gives
us time to adapt to near realities, time to change something if there is an
unwanted effects, etc. At the same a single step is not a long-term
solution.
While a slow-but-steady growth might be.
3. Adaptive solutions (e.g. limit depends on the last N blocks or something
of that nature):
The problem with them is that they are rather complex, and also:
3.1. prone to manipulation: somebody might try to push the limit if it
will favor him in future
3.2. possibility of a positive feedback loop.
3.3. possibility of an unhealthy game-theoretic dynamics
The main problem is that we do not understand game theoretic aspects of
bitcoin mining in presence of various real-world factors such as block
propagation delays. Thus we can't design a proper adaptive solution.
There is no perfect solution to this problem as we cannot predict the
future and our understanding is limited.
But among the 5 alternatives (linear, exponential, single step, adaptive,
no limit), linear seems to be the best option at this point as it's both
quite safe and doesn't stunt growth too much.
> bitcoin is really really small right now, any sign of real adoption could
make it grow 100x or even more in a matter of weeks.
This is certainly possible, but the thing is:
1) this can't be predicted;
2) this will be a serious problem for many bitcoind installations;
3) it's not necessarily a healthy thing, perhaps it will grow 100x in a
matter of weeks, and then will go to zero in matter of weeks as well.
So I don't think that sudden growth spurts is something we should take into
account on the planning stage. If anything we'd like to prevent them from
happening, slow growth is usually better.
[-- Attachment #2: Type: text/html, Size: 3791 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-30 22:05 ` Alex Mizrahi
2015-05-30 23:16 ` Brian Hoffman
@ 2015-05-31 5:05 ` gb
1 sibling, 0 replies; 67+ messages in thread
From: gb @ 2015-05-31 5:05 UTC (permalink / raw)
To: Alex Mizrahi; +Cc: Bitcoin Dev
Linear growth is indeed the 'simplest' model for growth so removes
concerns of complexity using such a growth model. Seems like it might be
a safe compromise between exponential growth, zero growth and buys some
time to observe the longer term scale network behaviour.
A simple linear growth 'hard' technical limit could also be used
conjunction with the simple periodic soft dynamic limit adjustment (e.g.
1.5x of moving average) as discussed recently. So that the combination
provides for growth, with fee pressure, up until if/when the technical
hard limit is hit. And if we keep hitting the hard limit that signals a
market demand for ancillary layers to be built out, that has been
missing until now.
On Sun, 2015-05-31 at 01:05 +0300, Alex Mizrahi wrote:
>
>
> Why 2 MB ?
>
>
> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
>
>
> Why not grow it by 1 MB per year?
> This is a safer option, I don't think that anybody claims that 2 MB
> blocks will be a problem.
> And in 10 years when we get to 10 MB we'll get more evidence as to
> whether network can handle 10 MB blocks.
>
>
> So this might be a solution which would satisfy both sides:
> * people who are concerned about block size growth will have an
> opportunity to stop it before it grows too much (e.g. with a soft
> fork),
> * while people who want bigger blocks will get an equivalent of 25%
> per year growth within the first 10 years, which isn't bad, is it?
>
>
> So far I haven't heard any valid arguments against linear growth.
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 67+ messages in thread
[parent not found: <CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>]
* [Bitcoin-development] Fwd: Block Size Increase Requirements
[not found] ` <CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
@ 2015-05-31 1:31 ` Chun Wang
2015-05-31 2:20 ` Pindar Wong
` (3 more replies)
0 siblings, 4 replies; 67+ messages in thread
From: Chun Wang @ 2015-05-31 1:31 UTC (permalink / raw)
To: bitcoin-development
On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
>> Bad miners could attack us and the network with artificial
>> big blocks.
>
>
> How?
>
> I ran some simulations, and I could not find a network topology where a big
> miner producing big blocks could cause a loss of profit to another miner
> (big or small) producing smaller blocks:
>
> http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
>
> (the 0.3% advantage I DID find was for the situation where EVERYBODY was
> producing big blocks).
If someone propagate a 20MB block, it will take at best 6 seconds for
us to receive to verify it at current configuration, result of one
percent orphan rate increase. Or, we can mine the next block only on
the previous block's header, in this case, the network would see many
more transaction-less blocks.
Our orphan rate is about 0.5% over the past few months. If the network
floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB
block could contain an average of 50000 transactions, hundred of
thousands of sigops, Do you have an estimate how long it takes on the
submitblock rpccall?
For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars
per month. We also use Aliyun and Linode cloud services for block
propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for
100Mbps connectivity at Aliyun. For a single cross-border TCP
connection, it would be certainly far slower than 12.5 MB/s.
I think we can accept 5MB block at most.
(sorry forgot to cc to the mailing list)
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 1:31 ` [Bitcoin-development] Fwd: " Chun Wang
@ 2015-05-31 2:20 ` Pindar Wong
2015-05-31 12:40 ` Gavin Andresen
` (2 subsequent siblings)
3 siblings, 0 replies; 67+ messages in thread
From: Pindar Wong @ 2015-05-31 2:20 UTC (permalink / raw)
To: Chun Wang; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]
Thank you very much Chun Wang for the details below.
While I'm based in HK, but I'd like to propose that the miners in China
work together with Gavin and others to run an experiment of sorts next
month to gather more details for the community.
p.
On Sun, May 31, 2015 at 9:31 AM, Chun Wang <1240902@gmail•com> wrote:
> On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen <gavinandresen@gmail•com>
> wrote:
> >> Bad miners could attack us and the network with artificial
> >> big blocks.
> >
> >
> > How?
> >
> > I ran some simulations, and I could not find a network topology where a
> big
> > miner producing big blocks could cause a loss of profit to another miner
> > (big or small) producing smaller blocks:
> >
> > http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
> >
> > (the 0.3% advantage I DID find was for the situation where EVERYBODY was
> > producing big blocks).
>
> If someone propagate a 20MB block, it will take at best 6 seconds for
> us to receive to verify it at current configuration, result of one
> percent orphan rate increase. Or, we can mine the next block only on
> the previous block's header, in this case, the network would see many
> more transaction-less blocks.
>
> Our orphan rate is about 0.5% over the past few months. If the network
> floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB
> block could contain an average of 50000 transactions, hundred of
> thousands of sigops, Do you have an estimate how long it takes on the
> submitblock rpccall?
>
> For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars
> per month. We also use Aliyun and Linode cloud services for block
> propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for
> 100Mbps connectivity at Aliyun. For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
>
> I think we can accept 5MB block at most.
>
> (sorry forgot to cc to the mailing list)
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 3204 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 1:31 ` [Bitcoin-development] Fwd: " Chun Wang
2015-05-31 2:20 ` Pindar Wong
@ 2015-05-31 12:40 ` Gavin Andresen
2015-05-31 13:45 ` Alex Mizrahi
2015-05-31 12:52 ` Gavin Andresen
2015-05-31 14:34 ` Yifu Guo
3 siblings, 1 reply; 67+ messages in thread
From: Gavin Andresen @ 2015-05-31 12:40 UTC (permalink / raw)
To: Chun Wang; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]
On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240902@gmail•com> wrote:
>
> If someone propagate a 20MB block, it will take at best 6 seconds for
> us to receive to verify it at current configuration, result of one
> percent orphan rate increase.
That orphan rate increase will go to whoever is producing the 20MB blocks,
NOT you.
Or, we can mine the next block only on
> the previous block's header, in this case, the network would see many
> more transaction-less blocks.
>
Are you sure that is the best strategy? If a big block is slow to
propagate, I suspect it will be better to punish the miner that created it
by refusing to build on it until it has been fully validated.
I'll try to find time to run a couple of simulations.
>
> Our orphan rate is about 0.5% over the past few months. If the network
> floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB
> block could contain an average of 50000 transactions, hundred of
> thousands of sigops, Do you have an estimate how long it takes on the
> submitblock rpccall?
>
I can benchmark it. It should be pretty fast, and sipa has a couple of
patches pending to make the UTXO cache much faster.
It can be fast because the vast majority of the work of validating all
those transactions can happen as they are received into the memory pool.
> For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars
> per month.
You should be able to handle 20MB blocks no problem; if I round up to 100MB
per block that works out to 1.3Mbps.
We also use Aliyun and Linode cloud services for block
> propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for
> 100Mbps connectivity at Aliyun.
That speed will handle 20MB blocks no problem.
If each 20MB block is 100MB of data up/down the wire (I'm vastly
over-estimating, after optimization it should be 40MB) then you'll be
paying...uhhh:
0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13 $ /
GB = $57
Less than $2 per day in bandwidth, surely you can afford that.
> For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
That's OK, you'll 1.3Mbps or less.
> I think we can accept 5MB block at most.
>
Are you worried about paying too much, or do 20MB blocks "feel like too
much" ?
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 4411 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 12:40 ` Gavin Andresen
@ 2015-05-31 13:45 ` Alex Mizrahi
2015-05-31 14:54 ` Gavin Andresen
0 siblings, 1 reply; 67+ messages in thread
From: Alex Mizrahi @ 2015-05-31 13:45 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
> That orphan rate increase will go to whoever is producing the 20MB blocks,
> NOT you.
>
This depends on how miners are connected.
E.g. suppose there are three miners, A and B have fast connectivity between
then, and C has a slow network.
Suppose that A miners a block and B receives it in 1 second. C receives it
in 6 seconds.
This means that blocks mined by C during these ~5 seconds will be orphaned
because B gets A's block first.
[-- Attachment #2: Type: text/html, Size: 843 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 13:45 ` Alex Mizrahi
@ 2015-05-31 14:54 ` Gavin Andresen
2015-05-31 22:55 ` Alex Mizrahi
0 siblings, 1 reply; 67+ messages in thread
From: Gavin Andresen @ 2015-05-31 14:54 UTC (permalink / raw)
To: Alex Mizrahi; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]
On Sun, May 31, 2015 at 9:45 AM, Alex Mizrahi <alex.mizrahi@gmail•com>
wrote:
>
>
>> That orphan rate increase will go to whoever is producing the 20MB
>> blocks, NOT you.
>>
>
> This depends on how miners are connected.
>
> E.g. suppose there are three miners, A and B have fast connectivity
> between then, and C has a slow network.
> Suppose that A miners a block and B receives it in 1 second. C receives it
> in 6 seconds.
> This means that blocks mined by C during these ~5 seconds will be orphaned
> because B gets A's block first.
>
Yes, if you are on a slow network then you are at a (slight) disadvantage.
So?
There are lots of equations that go into the "is mining profitable"
equation: cost of power, Internet cost and connectivity, cost of capital,
access to technology other miners don't have, inexpensive labor or rent,
inexpensive cooling, ability to use waste heat...
That's good. An equation with lots of variables has lots of different
maximum solutions, and that means better decentralization -- there is less
likely to be one perfect place or way to mine.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1936 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 14:54 ` Gavin Andresen
@ 2015-05-31 22:55 ` Alex Mizrahi
2015-05-31 23:23 ` Ricardo Filipe
2015-06-01 13:15 ` Gavin Andresen
0 siblings, 2 replies; 67+ messages in thread
From: Alex Mizrahi @ 2015-05-31 22:55 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 387 bytes --]
>
> Yes, if you are on a slow network then you are at a (slight) disadvantage.
> So?
>
Chun mentioned that his pool is on a slow network, and thus bigger blocks
give it an disadvantage. (Orphan rate is proportional to block size.)
You said that no, on contrary those who make big blocks have a disadvantage.
And now you say that yes, this disadvantage exist.
Did you just lie to Chun?
[-- Attachment #2: Type: text/html, Size: 829 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 22:55 ` Alex Mizrahi
@ 2015-05-31 23:23 ` Ricardo Filipe
2015-05-31 23:40 ` Pindar Wong
2015-06-01 7:57 ` Alex Mizrahi
2015-06-01 13:15 ` Gavin Andresen
1 sibling, 2 replies; 67+ messages in thread
From: Ricardo Filipe @ 2015-05-31 23:23 UTC (permalink / raw)
To: Alex Mizrahi; +Cc: Bitcoin Dev
He also said that the equation for miners has many variables, as it
should. There is no disadvantage if the network speed is the same
between the miners. If there is a difference in network speed, the
miner is incentivized to invest in their network infrastructure.
2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi@gmail•com>:
>> Yes, if you are on a slow network then you are at a (slight) disadvantage.
>> So?
>
>
> Chun mentioned that his pool is on a slow network, and thus bigger blocks
> give it an disadvantage. (Orphan rate is proportional to block size.)
> You said that no, on contrary those who make big blocks have a disadvantage.
> And now you say that yes, this disadvantage exist.
>
> Did you just lie to Chun?
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 23:23 ` Ricardo Filipe
@ 2015-05-31 23:40 ` Pindar Wong
2015-05-31 23:58 ` Ricardo Filipe
2015-06-01 7:57 ` Alex Mizrahi
1 sibling, 1 reply; 67+ messages in thread
From: Pindar Wong @ 2015-05-31 23:40 UTC (permalink / raw)
To: Ricardo Filipe; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]
On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe <ricardojdfilipe@gmail•com>
wrote:
> He also said that the equation for miners has many variables, as it
> should. There is no disadvantage if the network speed is the same
> between the miners.
Hi,
Is that an assumption?
If there is a difference in network speed, the
> miner is incentivized to invest in their network infrastructure.
>
Perhaps it's best not to assume that investing in Internet network
infrastructure's a free or open market everywhere.
p.
>
> 2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi@gmail•com>:
> >> Yes, if you are on a slow network then you are at a (slight)
> disadvantage.
> >> So?
> >
> >
> > Chun mentioned that his pool is on a slow network, and thus bigger blocks
> > give it an disadvantage. (Orphan rate is proportional to block size.)
> > You said that no, on contrary those who make big blocks have a
> disadvantage.
> > And now you say that yes, this disadvantage exist.
> >
> > Did you just lie to Chun?
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 2890 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 23:40 ` Pindar Wong
@ 2015-05-31 23:58 ` Ricardo Filipe
2015-06-01 0:03 ` Pindar Wong
0 siblings, 1 reply; 67+ messages in thread
From: Ricardo Filipe @ 2015-05-31 23:58 UTC (permalink / raw)
To: Pindar Wong; +Cc: Bitcoin Dev
2015-06-01 0:40 GMT+01:00 Pindar Wong <pindar.wong@gmail•com>:
>
>
> On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe <ricardojdfilipe@gmail•com>
> wrote:
>>
>> He also said that the equation for miners has many variables, as it
>> should. There is no disadvantage if the network speed is the same
>> between the miners.
>
>
> Hi,
>
> Is that an assumption?
no, let me rephrase: The disadvantage alex refers to only exists if
miners do not have the same network speed.
>
>> If there is a difference in network speed, the
>> miner is incentivized to invest in their network infrastructure.
>
>
> Perhaps it's best not to assume that investing in Internet network
> infrastructure's a free or open market everywhere.
Just like easy ASIC access, low price electricity, etc are not a free
and open market.
>
> p.
>
>>
>>
>> 2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi@gmail•com>:
>> >> Yes, if you are on a slow network then you are at a (slight)
>> >> disadvantage.
>> >> So?
>> >
>> >
>> > Chun mentioned that his pool is on a slow network, and thus bigger
>> > blocks
>> > give it an disadvantage. (Orphan rate is proportional to block size.)
>> > You said that no, on contrary those who make big blocks have a
>> > disadvantage.
>> > And now you say that yes, this disadvantage exist.
>> >
>> > Did you just lie to Chun?
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists•sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 23:58 ` Ricardo Filipe
@ 2015-06-01 0:03 ` Pindar Wong
0 siblings, 0 replies; 67+ messages in thread
From: Pindar Wong @ 2015-06-01 0:03 UTC (permalink / raw)
To: Ricardo Filipe; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]
On Mon, Jun 1, 2015 at 7:58 AM, Ricardo Filipe <ricardojdfilipe@gmail•com>
wrote:
> 2015-06-01 0:40 GMT+01:00 Pindar Wong <pindar.wong@gmail•com>:
> >
> >
> > On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe <
> ricardojdfilipe@gmail•com>
> > wrote:
> >>
> >> He also said that the equation for miners has many variables, as it
> >> should. There is no disadvantage if the network speed is the same
> >> between the miners.
> >
> >
> > Hi,
> >
> > Is that an assumption?
> no, let me rephrase: The disadvantage alex refers to only exists if
> miners do not have the same network speed.
>
> >
> >> If there is a difference in network speed, the
> >> miner is incentivized to invest in their network infrastructure.
> >
> >
> > Perhaps it's best not to assume that investing in Internet network
> > infrastructure's a free or open market everywhere.
> Just like easy ASIC access, low price electricity, etc are not a free
> and open market.
>
-- point well made and taken.
p.
>
> >
> > p.
> >
> >>
> >>
> >> 2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi@gmail•com>:
> >> >> Yes, if you are on a slow network then you are at a (slight)
> >> >> disadvantage.
> >> >> So?
> >> >
> >> >
> >> > Chun mentioned that his pool is on a slow network, and thus bigger
> >> > blocks
> >> > give it an disadvantage. (Orphan rate is proportional to block size.)
> >> > You said that no, on contrary those who make big blocks have a
> >> > disadvantage.
> >> > And now you say that yes, this disadvantage exist.
> >> >
> >> > Did you just lie to Chun?
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >
> >> > _______________________________________________
> >> > Bitcoin-development mailing list
> >> > Bitcoin-development@lists•sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development@lists•sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
>
[-- Attachment #2: Type: text/html, Size: 3808 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 23:23 ` Ricardo Filipe
2015-05-31 23:40 ` Pindar Wong
@ 2015-06-01 7:57 ` Alex Mizrahi
2015-06-01 10:13 ` Mike Hearn
1 sibling, 1 reply; 67+ messages in thread
From: Alex Mizrahi @ 2015-06-01 7:57 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
> He also said that the equation for miners has many variables, as it
> should.
He only said that AFTER I called him on his bullshit.
Before that he wrote it like there is 100% certainty that only the party
producing big blocks is punished:
"That orphan rate increase will go to whoever is producing the 20MB blocks,
NOT you."
> There is no disadvantage if the network speed is the same
> between the miners.
Which is exactly not the situation they were discussing. This assumption is
not reasonable.
[-- Attachment #2: Type: text/html, Size: 1135 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 7:57 ` Alex Mizrahi
@ 2015-06-01 10:13 ` Mike Hearn
2015-06-01 10:42 ` Pindar Wong
` (2 more replies)
0 siblings, 3 replies; 67+ messages in thread
From: Mike Hearn @ 2015-06-01 10:13 UTC (permalink / raw)
To: Alex Mizrahi; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
Whilst it would be nice if miners in China can carry on forever regardless
of their internet situation, nobody has any inherent "right" to mine if
they can't do the job - if miners in China can't get the trivial amounts of
bandwidth required through their firewall and end up being outcompeted then
OK, too bad, we'll have to carry on without them.
But I'm not sure why it should be a big deal. They can always run a node on
a server in Taiwan and connect the hardware to it via a VPN or so.
[-- Attachment #2: Type: text/html, Size: 636 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 10:13 ` Mike Hearn
@ 2015-06-01 10:42 ` Pindar Wong
2015-06-01 11:26 ` Peter Todd
2015-06-01 11:02 ` Chun Wang
2015-06-01 12:29 ` Warren Togami Jr.
2 siblings, 1 reply; 67+ messages in thread
From: Pindar Wong @ 2015-06-01 10:42 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn <mike@plan99•net> wrote:
> Whilst it would be nice if miners in China can carry on forever regardless
> of their internet situation, nobody has any inherent "right" to mine if
> they can't do the job - if miners in China can't get the trivial amounts of
> bandwidth required through their firewall and end up being outcompeted then
> OK, too bad, we'll have to carry on without them.
>
I'd rather think of mining as a responsibility than a right per se, but
you're right in so far as it's competitive and self-correcting.
>
> But I'm not sure why it should be a big deal. They can always run a node
> on a server in Taiwan and connect the hardware to it via a VPN or so.
>
>
Let's agree to disagree on this point.
p.
------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 1997 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 10:42 ` Pindar Wong
@ 2015-06-01 11:26 ` Peter Todd
2015-06-01 12:19 ` Pindar Wong
0 siblings, 1 reply; 67+ messages in thread
From: Peter Todd @ 2015-06-01 11:26 UTC (permalink / raw)
To: Pindar Wong; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2346 bytes --]
On Mon, Jun 01, 2015 at 06:42:05PM +0800, Pindar Wong wrote:
> On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn <mike@plan99•net> wrote:
>
> > Whilst it would be nice if miners in China can carry on forever regardless
> > of their internet situation, nobody has any inherent "right" to mine if
> > they can't do the job - if miners in China can't get the trivial amounts of
> > bandwidth required through their firewall and end up being outcompeted then
> > OK, too bad, we'll have to carry on without them.
> >
>
> I'd rather think of mining as a responsibility than a right per se, but
> you're right in so far as it's competitive and self-correcting.
It's important to remember that the service Bitcoin miners are providing
us is *not* transaction validation, but rather decentralization.
Validation is something every full node does already; there's no
shortage of it. What's tricky is designing a Bitcoin protocol that
creates the appropriate incentives for mining to remain decentralized,
so we get good value for the large amount of money being sent to miners.
I've often likened this task to building a robot to go to the grocery
store to buy milk for you. If that robot doesn't have a nose, before
long store owners are going to realise it can't tell the difference
between unspoilt and spoilt milk, and you're going to get ripped off
paying for a bunch of spoiled milk.
Designing a Bitcoin protocol where we expect "competition" to result in
smaller miners in more geographically decentralized places to get
outcompeted by larger miners who are more geographically centralized
gets us bad value for our money. Sure it's "self-correcting", but not in
a way that we want.
> > But I'm not sure why it should be a big deal. They can always run a node
> > on a server in Taiwan and connect the hardware to it via a VPN or so.
> >
> >
> Let's agree to disagree on this point.
Note how that VPN, and likely VPS it's connected too, immediately adds
another one or two points of failure to the whole system. Not only does
this decrease reliability, it also decreases security by making attacks
significantly easier - VPS security is orders of magnitude worse than
the security of physical hardware.
--
'peter'[:-1]@petertodd.org
00000000000000000e187b95a9159d04a3586dd4cbc068be88a3eafcb5b885f9
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 11:26 ` Peter Todd
@ 2015-06-01 12:19 ` Pindar Wong
0 siblings, 0 replies; 67+ messages in thread
From: Pindar Wong @ 2015-06-01 12:19 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]
Two very valid and important points. Thank you for making these
observations Peter.
p.
On Mon, Jun 1, 2015 at 7:26 PM, Peter Todd <pete@petertodd•org> wrote:
> On Mon, Jun 01, 2015 at 06:42:05PM +0800, Pindar Wong wrote:
> > On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn <mike@plan99•net> wrote:
> >
> > > Whilst it would be nice if miners in China can carry on forever
> regardless
> > > of their internet situation, nobody has any inherent "right" to mine if
> > > they can't do the job - if miners in China can't get the trivial
> amounts of
> > > bandwidth required through their firewall and end up being outcompeted
> then
> > > OK, too bad, we'll have to carry on without them.
> > >
> >
> > I'd rather think of mining as a responsibility than a right per se, but
> > you're right in so far as it's competitive and self-correcting.
>
> It's important to remember that the service Bitcoin miners are providing
> us is *not* transaction validation, but rather decentralization.
> Validation is something every full node does already; there's no
> shortage of it. What's tricky is designing a Bitcoin protocol that
> creates the appropriate incentives for mining to remain decentralized,
> so we get good value for the large amount of money being sent to miners.
>
> I've often likened this task to building a robot to go to the grocery
> store to buy milk for you. If that robot doesn't have a nose, before
> long store owners are going to realise it can't tell the difference
> between unspoilt and spoilt milk, and you're going to get ripped off
> paying for a bunch of spoiled milk.
>
> Designing a Bitcoin protocol where we expect "competition" to result in
> smaller miners in more geographically decentralized places to get
> outcompeted by larger miners who are more geographically centralized
> gets us bad value for our money. Sure it's "self-correcting", but not in
> a way that we want.
>
> > > But I'm not sure why it should be a big deal. They can always run a
> node
> > > on a server in Taiwan and connect the hardware to it via a VPN or so.
> > >
> > >
> > Let's agree to disagree on this point.
>
> Note how that VPN, and likely VPS it's connected too, immediately adds
> another one or two points of failure to the whole system. Not only does
> this decrease reliability, it also decreases security by making attacks
> significantly easier - VPS security is orders of magnitude worse than
> the security of physical hardware.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000e187b95a9159d04a3586dd4cbc068be88a3eafcb5b885f9
>
[-- Attachment #2: Type: text/html, Size: 3390 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 10:13 ` Mike Hearn
2015-06-01 10:42 ` Pindar Wong
@ 2015-06-01 11:02 ` Chun Wang
2015-06-01 11:09 ` Pindar Wong
` (2 more replies)
2015-06-01 12:29 ` Warren Togami Jr.
2 siblings, 3 replies; 67+ messages in thread
From: Chun Wang @ 2015-06-01 11:02 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn <mike@plan99•net> wrote:
> Whilst it would be nice if miners in China can carry on forever regardless
> of their internet situation, nobody has any inherent "right" to mine if they
> can't do the job - if miners in China can't get the trivial amounts of
> bandwidth required through their firewall and end up being outcompeted then
> OK, too bad, we'll have to carry on without them.
>
> But I'm not sure why it should be a big deal. They can always run a node on
> a server in Taiwan and connect the hardware to it via a VPN or so.
Ignorant. You seem do not understand the current situation. We
suffered from orphans a lot when we started in 2013. It is now your
turn. If Western miners do not find a China-based VPN into China, or
if Western pools do not manage to improve their connectivity to China,
or run a node in China, it would be them to have higher orphans, not
us. Because we have 50%+.
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 11:02 ` Chun Wang
@ 2015-06-01 11:09 ` Pindar Wong
2015-06-01 11:20 ` Chun Wang
2015-06-01 13:21 ` Mike Hearn
2 siblings, 0 replies; 67+ messages in thread
From: Pindar Wong @ 2015-06-01 11:09 UTC (permalink / raw)
To: Chun Wang; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
I think it would be helpful if we could all *chill* and focus on the solid
engineering necessary to make Bitcoin succeed.
p.
On Mon, Jun 1, 2015 at 7:02 PM, Chun Wang <1240902@gmail•com> wrote:
> On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn <mike@plan99•net> wrote:
> > Whilst it would be nice if miners in China can carry on forever
> regardless
> > of their internet situation, nobody has any inherent "right" to mine if
> they
> > can't do the job - if miners in China can't get the trivial amounts of
> > bandwidth required through their firewall and end up being outcompeted
> then
> > OK, too bad, we'll have to carry on without them.
> >
> > But I'm not sure why it should be a big deal. They can always run a node
> on
> > a server in Taiwan and connect the hardware to it via a VPN or so.
>
> Ignorant. You seem do not understand the current situation. We
> suffered from orphans a lot when we started in 2013. It is now your
> turn. If Western miners do not find a China-based VPN into China, or
> if Western pools do not manage to improve their connectivity to China,
> or run a node in China, it would be them to have higher orphans, not
> us. Because we have 50%+.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 2189 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 11:02 ` Chun Wang
2015-06-01 11:09 ` Pindar Wong
@ 2015-06-01 11:20 ` Chun Wang
2015-06-01 13:59 ` Gavin Andresen
2015-06-01 13:21 ` Mike Hearn
2 siblings, 1 reply; 67+ messages in thread
From: Chun Wang @ 2015-06-01 11:20 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
I cannot believe why Gavin (who seems to have difficulty to spell my
name correctly.) insists on his 20MB proposal regardless the
community. BIP66 has been introduced for a long time and no one knows
when the 95% goal can be met. This change to the block max size must
take one year or more to be adopted. We should increase the limit and
increase it now. 20MB is simply too big and too risky, sometimes we
need compromise and push things forward. I agree with any solution
lower than 10MB in its first two years.
On Mon, Jun 1, 2015 at 7:02 PM, Chun Wang <1240902@gmail•com> wrote:
> On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn <mike@plan99•net> wrote:
>> Whilst it would be nice if miners in China can carry on forever regardless
>> of their internet situation, nobody has any inherent "right" to mine if they
>> can't do the job - if miners in China can't get the trivial amounts of
>> bandwidth required through their firewall and end up being outcompeted then
>> OK, too bad, we'll have to carry on without them.
>>
>> But I'm not sure why it should be a big deal. They can always run a node on
>> a server in Taiwan and connect the hardware to it via a VPN or so.
>
> Ignorant. You seem do not understand the current situation. We
> suffered from orphans a lot when we started in 2013. It is now your
> turn. If Western miners do not find a China-based VPN into China, or
> if Western pools do not manage to improve their connectivity to China,
> or run a node in China, it would be them to have higher orphans, not
> us. Because we have 50%+.
On Mon, Jun 1, 2015 at 7:02 PM, Chun Wang <1240902@gmail•com> wrote:
> On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn <mike@plan99•net> wrote:
>> Whilst it would be nice if miners in China can carry on forever regardless
>> of their internet situation, nobody has any inherent "right" to mine if they
>> can't do the job - if miners in China can't get the trivial amounts of
>> bandwidth required through their firewall and end up being outcompeted then
>> OK, too bad, we'll have to carry on without them.
>>
>> But I'm not sure why it should be a big deal. They can always run a node on
>> a server in Taiwan and connect the hardware to it via a VPN or so.
>
> Ignorant. You seem do not understand the current situation. We
> suffered from orphans a lot when we started in 2013. It is now your
> turn. If Western miners do not find a China-based VPN into China, or
> if Western pools do not manage to improve their connectivity to China,
> or run a node in China, it would be them to have higher orphans, not
> us. Because we have 50%+.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 11:20 ` Chun Wang
@ 2015-06-01 13:59 ` Gavin Andresen
2015-06-01 14:08 ` Chun Wang
` (3 more replies)
0 siblings, 4 replies; 67+ messages in thread
From: Gavin Andresen @ 2015-06-01 13:59 UTC (permalink / raw)
To: Chun Wang; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]
On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240902@gmail•com> wrote:
> I cannot believe why Gavin (who seems to have difficulty to spell my
> name correctly.) insists on his 20MB proposal regardless the
> community. BIP66 has been introduced for a long time and no one knows
> when the 95% goal can be met. This change to the block max size must
> take one year or more to be adopted. We should increase the limit and
> increase it now. 20MB is simply too big and too risky, sometimes we
> need compromise and push things forward. I agree with any solution
> lower than 10MB in its first two years.
>
>
Thanks, that's useful!
What do other people think? Would starting at a max of 8 or 4 get
consensus? Scaling up a little less than Nielsen's Law of Internet
Bandwidth predicts for the next 20 years? (I think predictability is
REALLY important).
I chose 20 because all of my testing shows it to be safe, and all of my
back-of-the-envelope calculations indicate the costs are reasonable.
If consensus is "8 because more than order-of-magnitude increases are
scary" -- ok.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1588 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 13:59 ` Gavin Andresen
@ 2015-06-01 14:08 ` Chun Wang
2015-06-01 15:33 ` Mike Hearn
2015-06-01 14:46 ` Oliver Egginger
` (2 subsequent siblings)
3 siblings, 1 reply; 67+ messages in thread
From: Chun Wang @ 2015-06-01 14:08 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
That is good. I oppose 20MB because I estimate it may increase the
overall orphan rate to an unacceptable level. 5MB, 8MB or probably
10MB should be ok.
On Mon, Jun 1, 2015 at 9:59 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
> On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240902@gmail•com> wrote:
>>
>> I cannot believe why Gavin (who seems to have difficulty to spell my
>> name correctly.) insists on his 20MB proposal regardless the
>> community. BIP66 has been introduced for a long time and no one knows
>> when the 95% goal can be met. This change to the block max size must
>> take one year or more to be adopted. We should increase the limit and
>> increase it now. 20MB is simply too big and too risky, sometimes we
>> need compromise and push things forward. I agree with any solution
>> lower than 10MB in its first two years.
>>
>
> Thanks, that's useful!
>
> What do other people think? Would starting at a max of 8 or 4 get
> consensus? Scaling up a little less than Nielsen's Law of Internet
> Bandwidth predicts for the next 20 years? (I think predictability is REALLY
> important).
>
> I chose 20 because all of my testing shows it to be safe, and all of my
> back-of-the-envelope calculations indicate the costs are reasonable.
>
> If consensus is "8 because more than order-of-magnitude increases are scary"
> -- ok.
>
> --
> --
> Gavin Andresen
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 14:08 ` Chun Wang
@ 2015-06-01 15:33 ` Mike Hearn
2015-06-01 16:06 ` Ángel José Riesgo
0 siblings, 1 reply; 67+ messages in thread
From: Mike Hearn @ 2015-06-01 15:33 UTC (permalink / raw)
To: Chun Wang; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]
I'm OK with a smaller size + a formula that ramps it up over time. We are
far from having enough demand to fill 10MB blocks, let alone 20MB today.
To put it in perspective, to be feeling squeezed inside 10MB within two
years, we would need to double usage five times. I wish I knew a way to
make that happen. So the chances of us going to 20MB blocks full of real
transactions any time soon is close to zero short of some amazing killer
app that takes the world by storm (in which case: yay, nice problem to
have). As long as capacity significantly outpaces organic growth, we should
avoid problems.
The reason to pick 20MB then is merely one of expedience: we have to pick a
number, 20 is tested and seems to work, and we don't want to get caught by
surprise if demand does outstrip expectations.
Still, I question the underlying logic. We have no idea what connectivity
into China will look like a few years from now: it's seems to be a function
of politics rather than hardware trends. It might go down rather than up.
So 10 vs 20 feels a bit arbitrary. We can't let the Chinese government
dictate how Bitcoin is used, that would never be accepted by the rest of
the world. But if we optimistically assume things don't get worse, and 10
== more acceptance, then alright - it should make no difference in practice.
[-- Attachment #2: Type: text/html, Size: 1472 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 15:33 ` Mike Hearn
@ 2015-06-01 16:06 ` Ángel José Riesgo
0 siblings, 0 replies; 67+ messages in thread
From: Ángel José Riesgo @ 2015-06-01 16:06 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3312 bytes --]
Hi everyone,
I'm a long-time lurker of this mailing list but it's the first time I post
here, so first of all I'd like to thank all of the usual contributors for
the great insights and technical discussions that can be found here. As
this is such a momentous point in the history of Bitcoin, I'd just like to
throw in my opinion too.
First, I agree with Oliver Egginger's message that it's much more elegant
to keep the numbers as powers of 2 rather than introducing somewhat
arbitrary numbers like 20. This also makes it easier to count the level of
support for what would be a clear spectrum of discrete levels (1, 2, 4, ...
32, 64, ..., infinite). If a temporary peace accord can be reached with a
value like 8 or 16, this will buy us some time for both the user base to
continue growing without hitting the limit and for newer technologies like
the lightning network to be developed and tested. We will also see whether
the relatively small increase causes any unexpected harm or whether (as I
expect) everything continues to run smoothly.
Personally, I'd like to see Bitcoin grow and become what I think most
Bitcoin users like myself expect from it: that it should be a payment
network directly accessible to people all over the world. In my opinion, it
is the proposition of Bitcoin as a form of electronic money that
additionally makes it a good store of value. I don't believe in the idea
that it can exist as just some sort of digital gold for a geeky financial
elite. And I haven't been persuaded by those who claim the scarcity of
block space is an economic fundamental of Bitcoin either. It seems to me
there's a lot of batty economic ideas being bandied about regarding the
supposed long-term value of the cap without much justification. In this
sense, my sympathies are with those who want to remove the maximum block
size cap. This was after all the original idea, so it's not fair for the
1MB camp to claim that they're the ones preserving the essences of Bitcoin.
But, anyway, I also think that a consensus at this point would be much
better than a head-on confrontation between two incompatible pieces of
software competing to gain the favour of a majority of exchanges and
merchants. With this in mind, can't we accept the consensus that raising
the hard-coded limit to a value like 8MB buys us a bit of time and should
be at least palatable to everyone? This may not be what the staunch
supporters of the 1MB limit want, but it's also not what I and others would
want, so we're talking about finding some common ground here, and not about
one side getting their way to the detriment or humiliation of the other.
The problem with a compromise based on a one-off maximum-size increase, of
course, is that we're just kicking the can down the road and the discussion
will continue. It's not a solution I like, but how can we get people like
say Greg Maxwell or Pieter Wuille to accept something more drastic? If they
find a new maximum-size cap acceptable, then it could be a reasonable
compromise. A new cap will let us test the situation and see how the
Bitcoin environment reacts. The next time the discussion crops up (probably
very soon, I know...), we may all have a better understanding of the
implications.
Ángel José Riesgo
[-- Attachment #2: Type: text/html, Size: 3518 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 13:59 ` Gavin Andresen
2015-06-01 14:08 ` Chun Wang
@ 2015-06-01 14:46 ` Oliver Egginger
2015-06-01 14:48 ` Chun Wang
2015-06-01 16:43 ` Yifu Guo
2015-06-01 20:01 ` Roy Badami
3 siblings, 1 reply; 67+ messages in thread
From: Oliver Egginger @ 2015-06-01 14:46 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
On Mon, Jun 1, 2015 at 3:59 PM, Gavin Andresen wrote:
> What do other people think? Would starting at a max of 8 or 4 get
> consensus? Scaling up a little less than Nielsen's Law of Internet
> Bandwidth predicts for the next 20 years? (I think predictability is
> REALLY important).
>
> I chose 20 because all of my testing shows it to be safe, and all of my
> back-of-the-envelope calculations indicate the costs are reasonable.
>
> If consensus is "8 because more than order-of-magnitude increases are
> scary" -- ok.
It would feel better for me if you would keep the power of two:
2^0 = 1MB
2^1 = 2MB
2^2 = 4MB
2^3 = 8MB
.
.
.
But that's only personal. Maybe other people feeling the same.
- oliver
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 14:46 ` Oliver Egginger
@ 2015-06-01 14:48 ` Chun Wang
0 siblings, 0 replies; 67+ messages in thread
From: Chun Wang @ 2015-06-01 14:48 UTC (permalink / raw)
To: Oliver Egginger; +Cc: bitcoin-development
The current max block size of 1000000 bytes is not power of two anyway.
On Mon, Jun 1, 2015 at 10:46 PM, Oliver Egginger <bitcoin@olivere•de> wrote:
> On Mon, Jun 1, 2015 at 3:59 PM, Gavin Andresen wrote:
>> What do other people think? Would starting at a max of 8 or 4 get
>> consensus? Scaling up a little less than Nielsen's Law of Internet
>> Bandwidth predicts for the next 20 years? (I think predictability is
>> REALLY important).
>>
>> I chose 20 because all of my testing shows it to be safe, and all of my
>> back-of-the-envelope calculations indicate the costs are reasonable.
>>
>> If consensus is "8 because more than order-of-magnitude increases are
>> scary" -- ok.
>
> It would feel better for me if you would keep the power of two:
>
> 2^0 = 1MB
> 2^1 = 2MB
> 2^2 = 4MB
> 2^3 = 8MB
> .
> .
> .
>
> But that's only personal. Maybe other people feeling the same.
>
> - oliver
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 13:59 ` Gavin Andresen
2015-06-01 14:08 ` Chun Wang
2015-06-01 14:46 ` Oliver Egginger
@ 2015-06-01 16:43 ` Yifu Guo
2015-06-01 20:01 ` Roy Badami
3 siblings, 0 replies; 67+ messages in thread
From: Yifu Guo @ 2015-06-01 16:43 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]
Nielsen's Law of Internet Bandwidth is simply not true, but if you look at
data points like http://www.netindex.com/upload/ which will show we are at
least on the right track, but this is flawed still.
The fact of the matter is these speed tests are done from local origin to
local destination within the city, let alone the country ( see note about
how these test are only conducted 300 miles within the server). and our
current internet infrastructure is set up with CDNs for the web and media
consumption.
these data points can not and should not be used to model the connectivity
of a peer to peer network.
Uplink bandwidth is scarce is China and expensive, avg about $37 per 1mbps
after 5, but this is not the real problem. the true issue lies in the
ISP transparent proxy they run. this is not a problem isolated in just
China, Thailand and various other countries in Asia like Lebanon. I have
also heard in various IRCs that southern France also face this similar
issue due to poor routing configurations they have that prevents
connections to certain parts of the world, unsure if this is a mistake or a
geopolitical by-product.
As for your question earlier Gavin, from Dallas TX to a VPS in Shanghai
on 上海电信/Shanghai telecom, which is capped at 5mbps the data results match
my concerns, I've gotten low as 83 Kbits/sec and as high as 9.24 Mbits/sec.
and other ranges in between, none are consistent. ping avg is about 250ms.
The temporary solution I recommend again from earlier is MPTCP:
http://www.multipath-tcp.org/ which allows you to multiple
interfaces/networks for a single TCP connection, this is mainly developed
for mobile3g/wifi transition but I found uses to improve bandwidth and
connection stability on the go by combining a local wifi/ethernet
connection with my 3g phone tether. this allows you to set up a middlebox
somewhere, put shadowsocks server on it, and on your local machine you can
route all TCP traffic over the shadow socks client and MPTCP will
automatically pick the best path for upload and download.
On Mon, Jun 1, 2015 at 9:59 AM, Gavin Andresen <gavinandresen@gmail•com>
wrote:
> On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240902@gmail•com> wrote:
>
>> I cannot believe why Gavin (who seems to have difficulty to spell my
>> name correctly.) insists on his 20MB proposal regardless the
>> community. BIP66 has been introduced for a long time and no one knows
>> when the 95% goal can be met. This change to the block max size must
>> take one year or more to be adopted. We should increase the limit and
>> increase it now. 20MB is simply too big and too risky, sometimes we
>> need compromise and push things forward. I agree with any solution
>> lower than 10MB in its first two years.
>>
>>
> Thanks, that's useful!
>
> What do other people think? Would starting at a max of 8 or 4 get
> consensus? Scaling up a little less than Nielsen's Law of Internet
> Bandwidth predicts for the next 20 years? (I think predictability is
> REALLY important).
>
> I chose 20 because all of my testing shows it to be safe, and all of my
> back-of-the-envelope calculations indicate the costs are reasonable.
>
> If consensus is "8 because more than order-of-magnitude increases are
> scary" -- ok.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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: 5474 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 13:59 ` Gavin Andresen
` (2 preceding siblings ...)
2015-06-01 16:43 ` Yifu Guo
@ 2015-06-01 20:01 ` Roy Badami
2015-06-01 20:15 ` Roy Badami
3 siblings, 1 reply; 67+ messages in thread
From: Roy Badami @ 2015-06-01 20:01 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
> What do other people think? Would starting at a max of 8 or 4 get
> consensus? Scaling up a little less than Nielsen's Law of Internet
> Bandwidth predicts for the next 20 years? (I think predictability is
> REALLY important).
TL;DR: Personally I'm in favour of doing something relatively
uncontroversial (say, a simple increase in the block size to something
in the 4-8GB range) with no further increases without a further hard
fork.
I'm not sure how relevent Nielsen's Law really is. The only relevent
data points Nielsen has really boil down to a law about how the speed
of his cable modem connection has changed during the period 1998-2014.
Interesting though that is, it's not hugely relevent to
bandwidth-intensive operations like running a full node. The problem
is he's only looking at the actual speed of his connection in Mbps,
not the amount of data usage in GB/month that his provider permits -
and there's no particular reason to expect that both of those two
figures follow the same curve. In particular, we're more interested
in the cost of backhaul and IP transit (which is what drives the
GB/month figure) than we are in improvements in DOCSIS technology,
which have little relevence to node operators even on cable modem, and
none to any other kind of full node operator, be it on DSL or in a
datacentre.
More importantly, I also think a scheduled ramp up is an unnecessary
complication. Why do we need to commit now to future block size
increases perhaps years into the future? I'd rather schedule an
uncontroversial hard fork now (if such thing is possible) even if
there's a very real expectation - even an assumption - that by the
time the fork has taken place, it's already time to start discussing
the next one. Any curve or schedule of increases that stretches years
into the future is inevitably going to be controversial - and more so
the further into the future it stretches - simply because the
uncertainties around the Bitcoin landscape are going to be greater the
further ahead we look.
If a simple increase from 1GB to 4GB or 8GB will solve the problem for
now, why not do that? Yes, it's quite likely we'll have to do it
again, but we'll be able to make that decision in the light of the
2016 or 2017 landscape and can again make a simple, hopefully
uncontroversial, increase in the limit at that time.
So, with the proviso that I think this is all bike shedding, if I had
to pick my favourite colour for the bike shed, it would be to schedule
a hard fork that increases the 1GB limit (to something in the 4-8GB
range) but with no further increases without a further hard fork.
Personally I think trying to pick the best value of the 2035 block
size now is about as foolish as trying to understand now the economics
of Bitcoin mining many halvings hence.
NB: this is not saying that I think we shouldn't go above 8GB in the
relatively foreseeable future; quite the contrary, I strongly expect
that we will. I just don't see the need to pick the 2020 block size
now when we can easily make a far better informed decision as to the
2020 block size in 2018 or even 2019.
As to knowing what the block size is going to be for the next 20 years
being "REALLY important"? 100% disagree. I also think it's
impossible, because even if you manage to get consensus on a block
size increase schedule that stretches out to 2035 (and my prediction
is you won't) the reality is that that block size schedule will have
been modified by a future hard fork long before we get to 2035.
What I personally think is REALLY important is that the Bitcoin
community demonstrates an ability to react appropriately to changing
requirements and conditions - and we'll only be able to react to those
conditions when we know what they are! My expectation is that there
will be several (hopefully _relatively_ uncontroversial) scheduled
hard forks between now and 2035, and each of those will be discussed
in suitable detail before being agreed. And that's as it should be.
roy
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 20:01 ` Roy Badami
@ 2015-06-01 20:15 ` Roy Badami
0 siblings, 0 replies; 67+ messages in thread
From: Roy Badami @ 2015-06-01 20:15 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
On Mon, Jun 01, 2015 at 09:01:49PM +0100, Roy Badami wrote:
> > What do other people think? Would starting at a max of 8 or 4 get
> > consensus? Scaling up a little less than Nielsen's Law of Internet
> > Bandwidth predicts for the next 20 years? (I think predictability is
> > REALLY important).
>
> TL;DR: Personally I'm in favour of doing something relatively
> uncontroversial (say, a simple increase in the block size to something
> in the 4-8GB range) with no further increases without a further hard
> fork.
And the other bit I should have added to my TL;DR:
If we end up spending a significant proportion of the next 20 years
discussing the then _next_ hard fork, that's a *good* thing, not a
*bad* thing. Hard forks need to become, if not entirely routine, then
certainly less scary. A sequence of (relatively) uncontroversial hard
forks over time is way more likely to gain consensus than a single
hard fork that attempts to set a schedule for block size increases out
to 2035. IMHO.
>
> I'm not sure how relevent Nielsen's Law really is. The only relevent
> data points Nielsen has really boil down to a law about how the speed
> of his cable modem connection has changed during the period 1998-2014.
>
> Interesting though that is, it's not hugely relevent to
> bandwidth-intensive operations like running a full node. The problem
> is he's only looking at the actual speed of his connection in Mbps,
> not the amount of data usage in GB/month that his provider permits -
> and there's no particular reason to expect that both of those two
> figures follow the same curve. In particular, we're more interested
> in the cost of backhaul and IP transit (which is what drives the
> GB/month figure) than we are in improvements in DOCSIS technology,
> which have little relevence to node operators even on cable modem, and
> none to any other kind of full node operator, be it on DSL or in a
> datacentre.
>
> More importantly, I also think a scheduled ramp up is an unnecessary
> complication. Why do we need to commit now to future block size
> increases perhaps years into the future? I'd rather schedule an
> uncontroversial hard fork now (if such thing is possible) even if
> there's a very real expectation - even an assumption - that by the
> time the fork has taken place, it's already time to start discussing
> the next one. Any curve or schedule of increases that stretches years
> into the future is inevitably going to be controversial - and more so
> the further into the future it stretches - simply because the
> uncertainties around the Bitcoin landscape are going to be greater the
> further ahead we look.
>
> If a simple increase from 1GB to 4GB or 8GB will solve the problem for
> now, why not do that? Yes, it's quite likely we'll have to do it
> again, but we'll be able to make that decision in the light of the
> 2016 or 2017 landscape and can again make a simple, hopefully
> uncontroversial, increase in the limit at that time.
>
> So, with the proviso that I think this is all bike shedding, if I had
> to pick my favourite colour for the bike shed, it would be to schedule
> a hard fork that increases the 1GB limit (to something in the 4-8GB
> range) but with no further increases without a further hard fork.
>
> Personally I think trying to pick the best value of the 2035 block
> size now is about as foolish as trying to understand now the economics
> of Bitcoin mining many halvings hence.
>
> NB: this is not saying that I think we shouldn't go above 8GB in the
> relatively foreseeable future; quite the contrary, I strongly expect
> that we will. I just don't see the need to pick the 2020 block size
> now when we can easily make a far better informed decision as to the
> 2020 block size in 2018 or even 2019.
>
> As to knowing what the block size is going to be for the next 20 years
> being "REALLY important"? 100% disagree. I also think it's
> impossible, because even if you manage to get consensus on a block
> size increase schedule that stretches out to 2035 (and my prediction
> is you won't) the reality is that that block size schedule will have
> been modified by a future hard fork long before we get to 2035.
>
> What I personally think is REALLY important is that the Bitcoin
> community demonstrates an ability to react appropriately to changing
> requirements and conditions - and we'll only be able to react to those
> conditions when we know what they are! My expectation is that there
> will be several (hopefully _relatively_ uncontroversial) scheduled
> hard forks between now and 2035, and each of those will be discussed
> in suitable detail before being agreed. And that's as it should be.
>
> roy
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 11:02 ` Chun Wang
2015-06-01 11:09 ` Pindar Wong
2015-06-01 11:20 ` Chun Wang
@ 2015-06-01 13:21 ` Mike Hearn
2 siblings, 0 replies; 67+ messages in thread
From: Mike Hearn @ 2015-06-01 13:21 UTC (permalink / raw)
To: Chun Wang; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]
>
> Ignorant. You seem do not understand the current situation. We
> suffered from orphans a lot when we started in 2013. It is now your
> turn.
Then please enlighten me. You're unable to download block templates from a
trusted node outside of the country because the bandwidth requirements are
too high? Or due to some other problem?
With respect to "now it's your turn". Let's imagine the hard fork goes
ahead. Let us assume that almost all exchanges, payment processors and
other businesses go with larger blocks, but Chinese miners do not.
Then you will mine coins that will not be recognised on trading platforms
and cannot be sold. Your losses will be much larger than from orphans.
This can happen *even* if Chinese miners who can't/won't scale up are >50%
hashrate. SPV clients would need a forced checkpoint, which would be messy
and undesirable, but it's technically feasible. The smaller side of the
chain would cease to exist from the perspective of people actually trading
coins.
If your internet connectivity situation is really so poor that you cannot
handle one or two megabits out of the country then you're hanging on by
your fingernails anyway: your connection to the main internet could become
completely unusable at any time. If that's really the case, it seems to me
that Chinese Bitcoin is unsustainable and what you really need is a
China-specific alt coin that can run entirely within the Chinese internet.
[-- Attachment #2: Type: text/html, Size: 1845 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 10:13 ` Mike Hearn
2015-06-01 10:42 ` Pindar Wong
2015-06-01 11:02 ` Chun Wang
@ 2015-06-01 12:29 ` Warren Togami Jr.
2 siblings, 0 replies; 67+ messages in thread
From: Warren Togami Jr. @ 2015-06-01 12:29 UTC (permalink / raw)
Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]
Whilst it would be nice if miners in *outside* China can carry on forever
regardless of their internet situation, nobody has any inherent "right" to
mine if they can't do the job - if miners in *outside* China can't get the
trivial amounts of bandwidth required through their firewall *TO THE
MAJORITY OF THE HASHRATE* and end up being outcompeted then OK, too bad,
we'll have to carry on without them.
On Mon, Jun 1, 2015 at 12:13 AM, Mike Hearn <mike@plan99•net> wrote:
> Whilst it would be nice if miners in China can carry on forever regardless
> of their internet situation, nobody has any inherent "right" to mine if
> they can't do the job - if miners in China can't get the trivial amounts of
> bandwidth required through their firewall and end up being outcompeted then
> OK, too bad, we'll have to carry on without them.
>
> But I'm not sure why it should be a big deal. They can always run a node
> on a server in Taiwan and connect the hardware to it via a VPN or so.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 2030 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 22:55 ` Alex Mizrahi
2015-05-31 23:23 ` Ricardo Filipe
@ 2015-06-01 13:15 ` Gavin Andresen
1 sibling, 0 replies; 67+ messages in thread
From: Gavin Andresen @ 2015-06-01 13:15 UTC (permalink / raw)
To: Alex Mizrahi; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]
On Sun, May 31, 2015 at 6:55 PM, Alex Mizrahi <alex.mizrahi@gmail•com>
wrote:
> Yes, if you are on a slow network then you are at a (slight) disadvantage.
>> So?
>>
>
> Chun mentioned that his pool is on a slow network, and thus bigger blocks
> give it an disadvantage. (Orphan rate is proportional to block size.)
>
You said that no, on contrary those who make big blocks have a disadvantage.
> And now you say that yes, this disadvantage exist.
>
>
Did you just lie to Chun?
>
Chun said that if somebody produced a big block it would take them at least
6 seconds to process it.
He also said he has nodes outside the great firewall ("We also use Aliyun
and Linode cloud services for block
propagation.").
So I assumed that he was talking about the "what if somebody produces a
block that takes a long time to process" attack -- which doesn't work (the
attacker just increases their own orphan rate).
If the whole network is creating blocks that takes everybody (except the
person creating the blocks) six seconds to broadcast+validate, then the
increase in orphan rate is spread out over the whole network. The
network-wide orphan rate goes up, everybody suffers a little (fewer blocks
created over time) until the next difficulty adjustment, then the
difficulty drops, then everybody is back in the same boat.
If it takes six seconds to validate because of limited bandwidth, then he
should connect via Matt's fast relay network, which optimize new block
announcements so they take a couple orders of magnitude less bandwidth.
If it takes six seconds because he's trying to validate on a raspberry
pi.... then he should buy a better validating machine, and/or help test the
current pending pull requests to make validation faster (e.g.
https://github.com/bitcoin/bitcoin/pull/5835 or
https://github.com/bitcoin/bitcoin/pull/6077 ).
If Chun had six seconds of latency, and he can't pay for a lower-latency
connection (or it is insanely expensive), then there's nothing he can do,
he'll have to live with a higher orphan rate no matter the block size.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 4741 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 1:31 ` [Bitcoin-development] Fwd: " Chun Wang
2015-05-31 2:20 ` Pindar Wong
2015-05-31 12:40 ` Gavin Andresen
@ 2015-05-31 12:52 ` Gavin Andresen
2015-05-31 13:31 ` [Bitcoin-development] [Bulk] " gb
2015-05-31 14:17 ` [Bitcoin-development] " Dave Hudson
2015-05-31 14:34 ` Yifu Guo
3 siblings, 2 replies; 67+ messages in thread
From: Gavin Andresen @ 2015-05-31 12:52 UTC (permalink / raw)
To: Chun Wang; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]
On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240902@gmail•com> wrote:
>
> If someone propagate a 20MB block, it will take at best 6 seconds for
> us to receive to verify it at current configuration, result of one
> percent orphan rate increase.
That orphan rate increase will go to whoever is producing the 20MB blocks,
NOT you.
Or, we can mine the next block only on
> the previous block's header, in this case, the network would see many
> more transaction-less blocks.
>
Are you sure that is the best strategy? If a big block is slow to
propagate, I suspect it will be better to punish the miner that created it
by refusing to build on it until it has been fully validated.
I'll try to find time to run a couple of simulations.
>
> Our orphan rate is about 0.5% over the past few months. If the network
> floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB
> block could contain an average of 50000 transactions, hundred of
> thousands of sigops, Do you have an estimate how long it takes on the
> submitblock rpccall?
>
I can benchmark it. It should be pretty fast, and sipa has a couple of
patches pending to make the UTXO cache much faster.
It can be fast because the vast majority of the work of validating all
those transactions can happen as they are received into the memory pool.
> For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars
> per month.
You should be able to handle 20MB blocks no problem; if I round up to 100MB
per block that works out to 1.3Mbps.
We also use Aliyun and Linode cloud services for block
> propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for
> 100Mbps connectivity at Aliyun.
That speed will handle 20MB blocks no problem.
If each 20MB block is 100MB of data up/down the wire (I'm vastly
over-estimating, after optimization it should be 40MB) then you'll be
paying...uhhh:
0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13 $ /
GB = $57
Less than $2 per day in bandwidth.
> For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
That's OK, you'll 1.3Mbps or less.
> I think we can accept 5MB block at most.
>
Are you worried about paying too much, or do 20MB blocks "feel like too
much" ?
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 4287 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] [Bulk] Re: Fwd: Block Size Increase Requirements
2015-05-31 12:52 ` Gavin Andresen
@ 2015-05-31 13:31 ` gb
2015-05-31 19:49 ` Gavin Andresen
2015-05-31 14:17 ` [Bitcoin-development] " Dave Hudson
1 sibling, 1 reply; 67+ messages in thread
From: gb @ 2015-05-31 13:31 UTC (permalink / raw)
To: bitcoin-development
Aren't you calculating bandwidth for a singly-connected node? A "highly
connected" miner could have 30-100 node connections so you probably need
to increase your traffic estimates by that factor.
I.e. For 100MB blocks, 30-100 Mbps and $60-$100 per day data costs.
> You should be able to handle 20MB blocks no problem; if I round up to
> 100MB per block that works out to 1.3Mbps.
>
>
> We also use Aliyun and Linode cloud services for block
> propagation. As of May 2015, the price is 0.13 U.S. dollars
> per GB for
> 100Mbps connectivity at Aliyun.
>
>
> That speed will handle 20MB blocks no problem.
>
>
> If each 20MB block is 100MB of data up/down the wire (I'm vastly
> over-estimating, after optimization it should be 40MB) then you'll be
> paying...uhhh:
>
>
> 0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13
> $ / GB = $57
>
>
> Less than $2 per day in bandwidth.
>
> For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
>
>
> That's OK, you'll 1.3Mbps or less
> --
> --
> Gavin Andresen
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] [Bulk] Re: Fwd: Block Size Increase Requirements
2015-05-31 13:31 ` [Bitcoin-development] [Bulk] " gb
@ 2015-05-31 19:49 ` Gavin Andresen
0 siblings, 0 replies; 67+ messages in thread
From: Gavin Andresen @ 2015-05-31 19:49 UTC (permalink / raw)
To: gb; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
On Sun, May 31, 2015 at 9:31 AM, gb <kiwigb@yahoo•com> wrote:
> Aren't you calculating bandwidth for a singly-connected node? A "highly
> connected" miner could have 30-100 node connections so you probably need
> to increase your traffic estimates by that factor.
>
> I.e. For 100MB blocks, 30-100 Mbps and $60-$100 per day data costs.
>
No, randomly connected gossip networks (which is what the Bitcoin p2p
network is) don't work that way, bandwidth is (roughly) O(N) where N is the
number of bytes relayed to everybody.
(it is actually a small multiple of N, because of the overhead of 'inv'
messages, and if we ever get really serious about scaling up we'll need to
fix the protocol to reduce that overhead, but that won't be a problem for
years).
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1311 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 12:52 ` Gavin Andresen
2015-05-31 13:31 ` [Bitcoin-development] [Bulk] " gb
@ 2015-05-31 14:17 ` Dave Hudson
1 sibling, 0 replies; 67+ messages in thread
From: Dave Hudson @ 2015-05-31 14:17 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]
> On 31 May 2015, at 13:52, Gavin Andresen <gavinandresen@gmail•com> wrote:
>
> On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240902@gmail•com <mailto:1240902@gmail•com>> wrote:
> If someone propagate a 20MB block, it will take at best 6 seconds for
> us to receive to verify it at current configuration, result of one
> percent orphan rate increase.
>
> That orphan rate increase will go to whoever is producing the 20MB blocks, NOT you.
There's an interesting incentives question if the mining fees ever become large enough to be interesting. Given two potential blocks on which to build then for the best interests of the system we'd want miners to select the block that confirmed the largest number of transactions since that puts less pressure on the network later. This is at odds with the incentives for our would-be block maker though because the incentive for mining would be to use whichever block left the largest potential fees available; that's generally going to be the smaller of the two.
This, of course, only gets worse as the block reward reduces and fees become the dominant way for miners to be paid (and my hypothesis that eventually this could lead to miners trying to deliberately orphan earlier blocks to "steal" fees because the fixed block reward is no longer the dominant part of their income).
When coupled with the block propagation delay problem increasing the risk of orphan races I'm pretty sure that this actually leads to miners having an incentive to continually mine smaller blocks, and that's aside from the question of whether smaller blocks will push up fees (which also benefits miners).
Cheers,
Dave
[-- Attachment #2: Type: text/html, Size: 2691 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-05-31 1:31 ` [Bitcoin-development] Fwd: " Chun Wang
` (2 preceding siblings ...)
2015-05-31 12:52 ` Gavin Andresen
@ 2015-05-31 14:34 ` Yifu Guo
2015-05-31 14:47 ` Gavin Andresen
3 siblings, 1 reply; 67+ messages in thread
From: Yifu Guo @ 2015-05-31 14:34 UTC (permalink / raw)
To: Chun Wang; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 3309 bytes --]
I will abstain on this wrangle of "when",
Instead I'd like to address some of the network topology health issues
that's been brought up in this debate.
Due to how blocks are being broadcast by miners at the moment, it is not
difficult to find the origin node of these blocks. These more influential
origin nodes are a minority, about <100 out of ~6000, <2%. These data
points are important to certain attack vectors. It is highly recommended
that pools adopt broadcast logic that rotates broadcasting nodes and
increase their node count.. Eloipool has this implanted for those seeking
to adopt/see it in action in the wild.
China is a particular worse-case due to the sporadic nature of their
internet infrastructure, especially connecting from/to outside of gfw, on a
average node-walk I can get up to a 10% difference while I know for a fact
some of the nodes shown to be down are up.
In F2Pool's case, I see 6 replay nodes, I don't know if that's enough or
that's all the nodes F2Pool runs, but it may be beneficial to set up
multi-homing with shadowsocks over mptcp to increase the stability. also
see if you can get a CERNET connection to be part of your rotations since
their backbone is quite good.
comments, question and grievances welcome.
On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240902@gmail•com> wrote:
> On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen <gavinandresen@gmail•com>
> wrote:
> >> Bad miners could attack us and the network with artificial
> >> big blocks.
> >
> >
> > How?
> >
> > I ran some simulations, and I could not find a network topology where a
> big
> > miner producing big blocks could cause a loss of profit to another miner
> > (big or small) producing smaller blocks:
> >
> > http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
> >
> > (the 0.3% advantage I DID find was for the situation where EVERYBODY was
> > producing big blocks).
>
> If someone propagate a 20MB block, it will take at best 6 seconds for
> us to receive to verify it at current configuration, result of one
> percent orphan rate increase. Or, we can mine the next block only on
> the previous block's header, in this case, the network would see many
> more transaction-less blocks.
>
> Our orphan rate is about 0.5% over the past few months. If the network
> floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB
> block could contain an average of 50000 transactions, hundred of
> thousands of sigops, Do you have an estimate how long it takes on the
> submitblock rpccall?
>
> For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars
> per month. We also use Aliyun and Linode cloud services for block
> propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for
> 100Mbps connectivity at Aliyun. For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
>
> I think we can accept 5MB block at most.
>
> (sorry forgot to cc to the mailing list)
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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: 4946 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-29 23:42 ` Chun Wang
2015-05-30 13:57 ` Gavin Andresen
@ 2015-05-31 7:05 ` Peter Todd
2015-05-31 12:51 ` Gavin Andresen
1 sibling, 1 reply; 67+ messages in thread
From: Peter Todd @ 2015-05-31 7:05 UTC (permalink / raw)
To: Chun Wang; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]
On Sat, May 30, 2015 at 07:42:16AM +0800, Chun Wang wrote:
> Hello. I am from F2Pool. We are currently mining the biggest blocks on
> the network. So far top 100 biggest bitcoin blocks are all from us. We
> do support bigger blocks and sooner rather than later. But we cannot
> handle 20 MB blocks right now. I know most blocks would not be 20 MB
> over night. But only if a small fraction of blocks more than 10 MB, it
> could dramatically increase of our orphan rate, result of higher fee
> to miners. Bad miners could attack us and the network with artificial
> big blocks. As yhou know, other Chinese pools, AntPool, BW, they
> produces ASIC chips and mining mostly with their own machines. They do
> not care about a few percent of orphan increase as much as we do. They
> would continue their zero fee policy. We would be the biggest loser.
> As the exchanges had taught us, zero fee is not health to the network.
> Also we have to redevelop our block broadcast logic. Server bandwidth
> is a lot more expensive in China. And the Internet is slow. Currently
> China has more than 50% of mining power, if block size increases, I
> bet European and American pools could suffer more than us. We think
> the max block size should be increased, but must be increased
> smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
> and so on. Thanks.
Great to hear from you!
Yeah, I'm pretty surprised myself that Gavin never accepted the
compromises offered by others in this space for a slow growth solution,
rather than starting with over an order of magnitude blocksize increase.
This is particularly surprising when his own calculations - after
correcting an artithmetic error - came up with 8MB blocks rather than
20MB.
Something important to note in Gavin Andresen's analysises of this issue
is that he's using quite optimistic scenarios for how nodes are
connected to each other. For instance, assuming that connections between
miners are direct is a very optimistic assumption that depends on a
permissive, unregulated, environment where miners co-operate with each
other - obviously that's easily subject to change! Better block
broadcasting logic helps this in the "co-operation" case, but there's
not much it can do in the worst-case.
Unrelated: feel free to contact me directly if you have any questions
re: the BIP66 upgrade; I hear you guys were planning on upgrading your
mining nodes soon.
--
'peter'[:-1]@petertodd.org
00000000000000000db932d1cbd04a29d8e55989eda3f096d3ab8e8d95eb28e9
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Bitcoin-development] Block Size Increase Requirements
2015-05-31 7:05 ` [Bitcoin-development] " Peter Todd
@ 2015-05-31 12:51 ` Gavin Andresen
0 siblings, 0 replies; 67+ messages in thread
From: Gavin Andresen @ 2015-05-31 12:51 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]
On Sun, May 31, 2015 at 3:05 AM, Peter Todd <pete@petertodd•org> wrote:
> Yeah, I'm pretty surprised myself that Gavin never accepted the
> compromises offered by others in this space for a slow growth solution
>
What compromise? I haven't seen a specific proposal that could be turned
into a pull request.
> Something important to note in Gavin Andresen's analysises of this issue
> is that he's using quite optimistic scenarios for how nodes are
> connected to each other.
NO I AM NOT.
I simulated a variety of connectivities; see the .cfg files at
https://github.com/gavinandresen/bitcoin_miningsim
The results I give in the "are bigger blocks better" blog post are for
WORST CASE connectivity (one dominant big miner, multiple little miners,
big miner connects to only 30% of little miners, but all the little miners
connected directly to each other).
> For instance, assuming that connections between
> miners are direct is a very optimistic assumption
Again, I did not simulate all miners directly connected to each other.
I will note that miners are VERY HIGHLY connected today. It is in their
best interest to be highly connected to each other.
> that depends on a
> permissive, unregulated, environment where miners co-operate with each
> other - obviously that's easily subject to change!
Really? How is that easily subject to change? If it is easily subject to
change, do bigger blocks have any effect? Why are 1MB blocks not subject to
change?
I talk about "what if your government bans Bitcoin entirely" here:
http://gavinandresen.ninja/big-blocks-and-tor
... and the issues are essentially the same, independent of block size.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 3115 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread