Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Thy Shizzle]

[-- Attachment #1.1: Type: text/plain, Size: 3456 bytes --]

Ah sorry, I just thought you were saying doesn't matter which side let 'em burn.

If I were the Chinese and people moved to 20mb MAX size blocks and said stuff you, I'd just start firing out small coinbase only blocks now, if they truly have >50% hashing power and they collaborate chances are they can build a longer chain of just coinbase for themselves then the rest of the network doing big blocks. They don't even have to propagate this chain to you in a hurry right? And then they never have to receive a 20mb block from you because they have a longer chain without 20mb blocks and always ahead of your big blocks. As long as it is the longest chain it is Authority so let you guys transact your coinbase from the blocks you create etc. then whamo along come the chinese and supply a longer chain of just coinbase only blocks which invalidates all your previous transactions and gives them all the coinbase they stamped, while invalidating yours.

But who cares about them right :p
________________________________
From: Warren Togami Jr.<mailto:wtogami@gmail.com>
Sent: ‎2/‎06/‎2015 4:19 AM
Cc: Bitcoin Dev<mailto:bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

By reversing Mike's language to the reality of the situation I had hoped
people would realize how abjectly ignorant and insensitive his statement
was.  I am sorry to those in the community if they misunderstood my post. I
thought it was obvious that it was sarcasm where I do not seriously believe
particular participants should be excluded.

On Mon, Jun 1, 2015 at 3:06 AM, Thy Shizzle <thyshizzle@outlook.com> wrote:

>  Doesn't mean you should build something that says "fuck you" to the
> companies that have invested in farms of ASICS. To say "Oh yea if they
> can't mine it how we want stuff 'em" is naive. I get decentralisation, but
> don't dis incentivise mining. If miners are telling you that you're going
> to hurt them, esp. Miners that combined hold > 50% hashing power, why would
> you say too bad so sad? Why not just start stripping bitcoin out of
> adopters wallets? Same thing.
>  ------------------------------
> From: Warren Togami Jr. <wtogami@gmail.com>
> Sent: ‎1/‎06/‎2015 10:30 PM
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
>
>   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.
>
>

[-- Attachment #1.2: Type: text/html, Size: 6155 bytes --]

[-- Attachment #2: Type: text/plain, Size: 79 bytes --]

------------------------------------------------------------------------------

[-- Attachment #3: Type: text/plain, Size: 188 bytes --]

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Pindar Wong]

[-- Attachment #1: Type: text/plain, Size: 4064 bytes --]

It would be helpful to hear from the other miners, and perhaps arrange some
testing and telemetry in China with 8 ...  that's even a Chinese lucky
number ;)

p.


On Tue, Jun 2, 2015 at 5:32 AM, Thy Shizzle <thyshizzle@outlook.com> wrote:

>  Ah sorry, I just thought you were saying doesn't matter which side let
> 'em burn.
>
> If I were the Chinese and people moved to 20mb MAX size blocks and said
> stuff you, I'd just start firing out small coinbase only blocks now, if
> they truly have >50% hashing power and they collaborate chances are they
> can build a longer chain of just coinbase for themselves then the rest of
> the network doing big blocks. They don't even have to propagate this chain
> to you in a hurry right? And then they never have to receive a 20mb block
> from you because they have a longer chain without 20mb blocks and always
> ahead of your big blocks. As long as it is the longest chain it is
> Authority so let you guys transact your coinbase from the blocks you create
> etc. then whamo along come the chinese and supply a longer chain of just
> coinbase only blocks which invalidates all your previous transactions and
> gives them all the coinbase they stamped, while invalidating yours.
>
> But who cares about them right :p
>  ------------------------------
> From: Warren Togami Jr. <wtogami@gmail.com>
> Sent: ‎2/‎06/‎2015 4:19 AM
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
>
>  By reversing Mike's language to the reality of the situation I had hoped
> people would realize how abjectly ignorant and insensitive his statement
> was.  I am sorry to those in the community if they misunderstood my post. I
> thought it was obvious that it was sarcasm where I do not seriously believe
> particular participants should be excluded.
>
> On Mon, Jun 1, 2015 at 3:06 AM, Thy Shizzle <thyshizzle@outlook.com>
> wrote:
>
>  Doesn't mean you should build something that says "fuck you" to the
> companies that have invested in farms of ASICS. To say "Oh yea if they
> can't mine it how we want stuff 'em" is naive. I get decentralisation, but
> don't dis incentivise mining. If miners are telling you that you're going
> to hurt them, esp. Miners that combined hold > 50% hashing power, why would
> you say too bad so sad? Why not just start stripping bitcoin out of
> adopters wallets? Same thing.
>  ------------------------------
> From: Warren Togami Jr. <wtogami@gmail.com>
> Sent: ‎1/‎06/‎2015 10:30 PM
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
>
>    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: 7079 bytes --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Roy Badami]

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

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Roy Badami]

> 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

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 2822 bytes --]

I did wonder what the post actually meant, I recommend appending /s after
sarcasm so it's clear. Lots gets lost in text. But I agree with you btw his
response was not particularly tactful.

On Mon, Jun 1, 2015 at 7:19 PM, Warren Togami Jr. <wtogami@gmail.com> wrote:

> By reversing Mike's language to the reality of the situation I had hoped
> people would realize how abjectly ignorant and insensitive his statement
> was.  I am sorry to those in the community if they misunderstood my post. I
> thought it was obvious that it was sarcasm where I do not seriously believe
> particular participants should be excluded.
>
> On Mon, Jun 1, 2015 at 3:06 AM, Thy Shizzle <thyshizzle@outlook.com>
> wrote:
>
>>  Doesn't mean you should build something that says "fuck you" to the
>> companies that have invested in farms of ASICS. To say "Oh yea if they
>> can't mine it how we want stuff 'em" is naive. I get decentralisation, but
>> don't dis incentivise mining. If miners are telling you that you're going
>> to hurt them, esp. Miners that combined hold > 50% hashing power, why would
>> you say too bad so sad? Why not just start stripping bitcoin out of
>> adopters wallets? Same thing.
>>  ------------------------------
>> From: Warren Togami Jr. <wtogami@gmail.com>
>> Sent: ‎1/‎06/‎2015 10:30 PM
>> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
>> Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
>>
>>   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: 5032 bytes --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Adam Back]

So lets rephrase that and say instead more correctly it is the job of
miners (collectively) to be well connected globally - and indeed there
are incentivised to be or they tend to receive blocks at higher
latency and so are at increased risk of orphans.  And miner groups
with good block latency in-group and high hashrate are definitionally
the well connected, so the cost of getting good connectivity to high
hashrate groups is naturally borne by people outside of those groups.
Or thats the incentive anyway.

Adam


On 1 June 2015 at 19:30, Mike Hearn <mike@plan99.net> wrote:
> I don't see this as an issue of sensitivity or not. Miners are businesses
> that sell a service to Bitcoin users - the service of ordering transactions
> chronologically. They aren't charities.
>
> If some miners can't provide the service Bitcoin users need any more, then
> OK, they should not/cannot mine. Lots of miners have come and gone since
> Bitcoin started as different technology generations came and went. That's
> just business.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

I don't see this as an issue of sensitivity or not. Miners are businesses
that sell a service to Bitcoin users - the service of ordering transactions
chronologically. They aren't charities.

If some miners can't provide the service Bitcoin users need any more, then
OK, they should not/cannot mine. Lots of miners have come and gone since
Bitcoin started as different technology generations came and went. That's
just business.

[-- Attachment #2: Type: text/html, Size: 490 bytes --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Warren Togami Jr.]

[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]

By reversing Mike's language to the reality of the situation I had hoped
people would realize how abjectly ignorant and insensitive his statement
was.  I am sorry to those in the community if they misunderstood my post. I
thought it was obvious that it was sarcasm where I do not seriously believe
particular participants should be excluded.

On Mon, Jun 1, 2015 at 3:06 AM, Thy Shizzle <thyshizzle@outlook.com> wrote:

>  Doesn't mean you should build something that says "fuck you" to the
> companies that have invested in farms of ASICS. To say "Oh yea if they
> can't mine it how we want stuff 'em" is naive. I get decentralisation, but
> don't dis incentivise mining. If miners are telling you that you're going
> to hurt them, esp. Miners that combined hold > 50% hashing power, why would
> you say too bad so sad? Why not just start stripping bitcoin out of
> adopters wallets? Same thing.
>  ------------------------------
> From: Warren Togami Jr. <wtogami@gmail.com>
> Sent: ‎1/‎06/‎2015 10:30 PM
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
>
>   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.
>
>

[-- Attachment #2: Type: text/html, Size: 3950 bytes --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Yifu Guo]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Ángel José Riesgo]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Chun Wang]

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

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Oliver Egginger]

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

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Chun Wang]

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

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Gavin Andresen]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Gavin Andresen]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Thy Shizzle]

[-- Attachment #1.1: Type: text/plain, Size: 2024 bytes --]

Doesn't mean you should build something that says "fuck you" to the companies that have invested in farms of ASICS. To say "Oh yea if they can't mine it how we want stuff 'em" is naive. I get decentralisation, but don't dis incentivise mining. If miners are telling you that you're going to hurt them, esp. Miners that combined hold > 50% hashing power, why would you say too bad so sad? Why not just start stripping bitcoin out of adopters wallets? Same thing.
________________________________
From: Warren Togami Jr.<mailto:wtogami@gmail.com>
Sent: ‎1/‎06/‎2015 10:30 PM
Cc: Bitcoin Dev<mailto:bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

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 #1.2: Type: text/html, Size: 3726 bytes --]

[-- Attachment #2: Type: text/plain, Size: 79 bytes --]

------------------------------------------------------------------------------

[-- Attachment #3: Type: text/plain, Size: 188 bytes --]

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Warren Togami Jr.]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Pindar Wong]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Peter Todd]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Chun Wang]

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%+.

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Thy Shizzle]

[-- Attachment #1.1: Type: text/plain, Size: 908 bytes --]

WOW!!!! Way to burn your biggest adopters who put your transactions into the chain.......what a douche.
________________________________
From: Mike Hearn<mailto:mike@plan99.net>
Sent: ‎1/‎06/‎2015 8:15 PM
To: Alex Mizrahi<mailto:alex.mizrahi@gmail.com>
Cc: Bitcoin Dev<mailto:bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

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 #1.2: Type: text/html, Size: 2134 bytes --]

[-- Attachment #2: Type: text/plain, Size: 79 bytes --]

------------------------------------------------------------------------------

[-- Attachment #3: Type: text/plain, Size: 188 bytes --]

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Pindar Wong]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Chun Wang]

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%+.

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Pindar Wong]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Alex Mizrahi]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Pindar Wong]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Ricardo Filipe]

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
>
>

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Pindar Wong]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Ricardo Filipe]

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
>

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Alex Mizrahi]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Gavin Andresen]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

On Sun, May 31, 2015 at 10:34 AM, Yifu Guo <yifu@coinapex.com> wrote:

> comments, question and grievances welcome.
>

Thanks for chiming in with facts, Yifu!

Do you have any real-world data on latency/bandwidth/cost through the gfw ?
Chung Wang's post was very helpful to get away from hypotheticals to "what
would it actually cost."

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 852 bytes --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Yifu Guo]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Dave Hudson]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Alex Mizrahi]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Gavin Andresen]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Gavin Andresen]

[-- 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 --]

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Pindar Wong]

[-- 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 --]

[Bitcoin-development] Fwd: Block Size Increase Requirements

[Chun Wang]

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)