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

[Pindar Wong]

On Mon, Jun 1, 2015 at 7:58 AM, Ricardo Filipe 
wrote:

> 2015-06-01 0:40 GMT+01:00 Pindar Wong :
> >
> >
> > On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe <
> ricardojdfil...@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 :
> >> >> 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
> >
> >
>
--
___
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

[Ricardo Filipe]

2015-06-01 0:40 GMT+01:00 Pindar Wong :
>
>
> On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe 
> 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 :
>> >> 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
>
>

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

On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe 
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 :
> >> 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
>
--
___
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

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

[Alex Mizrahi]

>
> 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] [Bulk] Re: Fwd: Block Size Increase Requirements

[Gavin Andresen]

On Sun, May 31, 2015 at 9:31 AM, gb  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
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Max Block Size: Simple Voting Procedure

[Stephen Morse]

This is likely very similar to other proposals, but I want to bring voting
procedures back into the discussion. The goal here is to create a voting
procedure that is as simple as possible to increase the block size limit.

Votes are aggregated over each 2016 block period. Each coinbase transaction
may have an output at tx.vout[0] with OP_RETURN data in it of the format:

  OP_RETURN {OP_1 or OP_2}

OP_2 means the miner votes to increase the block size limit. OP_1 means the
miner votes to not increase the block size limit. *Not including such a
vote is equivalent to voting to NOT increase the block size. *I first
thought that not voting should mean that you vote with your block size, but
then decided that it would be too gameable by others broadcasting
transactions to affect your block size.

If in a 2016 block round there were more than 1008 blocks that voted to
increase the block size limit, then the max block size increases by 500 kb.
The votes can start when there is a supermajority of miners signaling
support for the voting procedure.

A few important properties of this simple voting:

   - It's not gameable via broadcasting transactions (assuming miners don't
   set their votes to be automatic, based on the size of recent blocks).
   - Miners don't have to bloat their blocks artificially just to place a
   vote for larger block sizes, and, similarly, don't need to exclude
   transactions even when they think the block size does not need to be raised.
   - The chain up until the point that this goes into effect may be
   interpreted as just lacking votes to increase the block size.

We can't trust all miners, but we have to trust that >50% of them are
honest for the system to work. This system makes it so that altering the
maximum block size requires >50% of miners (hash power) to vote to increase
the consensus-limit.

Thanks for your time. I think this is an important time in Bitcoin's
history. I'm not married to this proposal, but I think it would work. I
think a lot of the proposals mentioned on this mailing list would work. I
think it's time we just pick one and run with it.

Please let me know your thoughts. I will start working on a pull request if
this receives any support from miners/core devs/community members, unless
someone with more experience volunteers.

Best,
Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Jorge Timón]

On May 31, 2015 5:08 PM, "Gavin Andresen"  wrote:
>
> On Sun, May 31, 2015 at 10:59 AM, Jorge Timón  wrote:
>>
>> Whatever...let's use the current subsidies, the same argument applies,
it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
>> Miner B would still go out of business, bigger blocks still mean more
mining and validation centralization
>
> Sorry, but that's ridiculous.
>
> If Miner B is leaving 18BTC per block on the table because they have bad
connectivity, then they need to pay for better connectivity.

Well, I was assuming they just can't upgrade their connection (without
moving thei operations to another place). Maybe that assumption is
ridiculous as well.

> If you are arguing "I should be able to mine on a 56K modem connection
from the middle of the Sahara" then we're going to have to agree to
disagree.

No, I'm not suggesting that.

> So: what is your specific proposal for minimum requirements for
connectivity to run a full node? The 20MB number comes from estimating
costs to run a full node, and as my back-and-forth to Chang Wung shows, the
costs are not excessive.

Well, you were I think assuming a new desktop connecting from somewhere in
the US. I would be more confortable with an eee pc from a hotel in India,
for example. But yeah, targeting some concrete minimum specs seems like the
right approach for deciding "how far to go when increasing centralization".

But "hitting the limit will be chaos" seems to imply that completely
removing the consensus maximum blocksize is the only logical solution. What
happens when we hit the limit next time? When do we stop kicking the can
down the road? When do we voluntarily get that "chaos"?
Again, "that's too far away in the future to worry about it" is not a very
conving answer to me.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Gavin Andresen]

On Sun, May 31, 2015 at 10:59 AM, Jorge Timón  wrote:

> Whatever...let's use the current subsidies, the same argument applies,
> it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
> Miner B would still go out of business, bigger blocks still mean more
> mining and validation centralization
>
Sorry, but that's ridiculous.

If Miner B is leaving 18BTC per block on the table because they have bad
connectivity, then they need to pay for better connectivity.

If you are arguing "I should be able to mine on a 56K modem connection from
the middle of the Sahara" then we're going to have to agree to disagree.

So: what is your specific proposal for minimum requirements for
connectivity to run a full node? The 20MB number comes from estimating
costs to run a full node, and as my back-and-forth to Chang Wung shows, the
costs are not excessive.

-- 
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Jorge Timón]

Whatever...let's use the current subsidies, the same argument applies, it's
just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
Miner B would still go out of business, bigger blocks still mean more
mining and validation centralization. The question is how far I we willing
to go with this "scaling by sacrificing decentralization", but the answer
can't be "that's to far away in the future to worry about it, right now as
far as we think we can using orphan rate as the only criterion".
On May 31, 2015 4:49 PM, "Gavin Andresen"  wrote:

> On Sun, May 31, 2015 at 10:46 AM, Jorge Timón  wrote:
>
>> Here's a thought experiment:
>>
>> Subsidy is gone, all the block reward comes from fees.
>>
> I wrote about long-term hypotheticals and why I think it is a big mistake
> to waste time worrying about them here:
>http://gavinandresen.ninja/when-the-block-reward-goes-away
>
>
> --
> --
> Gavin Andresen
>
--
___
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

[Gavin Andresen]

On Sun, May 31, 2015 at 9:45 AM, Alex Mizrahi 
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
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Gavin Andresen]

On Sun, May 31, 2015 at 10:46 AM, Jorge Timón  wrote:

> Here's a thought experiment:
>
> Subsidy is gone, all the block reward comes from fees.
>
I wrote about long-term hypotheticals and why I think it is a big mistake
to waste time worrying about them here:
   http://gavinandresen.ninja/when-the-block-reward-goes-away


-- 
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Jorge Timón]

On May 30, 2015 10:38 PM, "Gavin Andresen"  wrote:
>
> Mining is a competitive business, the marginal miner will ALWAYS be going
out of business.
>
> That is completely independent of the block size, block subsidy, or
transaction fees.

No, the later determines who can be profitable.
Here's a thought experiment:

Subsidy is gone, all the block reward comes from fees.
Miner A has great connectivity and mines 20 MB blocks, with an average of
20 btc per block.
Miner B has a connectivity such that 2 MB blocks puts it on a reasonable
orphan rate, so it gets an average of 2 btc per block mined.
But the difficulty is the same for all and it can rise up to miner A
breaking even after energy costs.
Will miner B be profitable with this setup? The answer is no and miner B
will just go out of business. In that sense too, bigger blocks mean more
mining centralization.
--
___
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

[Gavin Andresen]

On Sun, May 31, 2015 at 10:34 AM, Yifu Guo  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
--
___
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

[Yifu Guo]

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 <1240...@gmail.com> wrote:

> On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen 
> 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 5 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."*
--
___
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

[Dave Hudson]

> On 31 May 2015, at 13:52, Gavin Andresen  wrote:
> 
> On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240...@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


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

> 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.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[gb]

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



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

[Gavin Andresen]

On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240...@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 5 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
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Gavin Andresen]

On Sun, May 31, 2015 at 3:05 AM, Peter Todd  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
--
___
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

[Gavin Andresen]

On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240...@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 5 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
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: A measured response to save Bitcoin Core

[Eric Lombrozo]

Drak,

I mostly agree with your assessment...except for your last claim.

Not that I wouldn't like to find a way to avoid politics, but like I've
argued before, it is inevitable that sooner or later any consensus protocol
that seeks dynamism will encounter politics.

The block size discussion, while ultimately necessary, for now is in the
best case merely serving as an example of the kind of political issues we
*really* need to be finding some solution for...and in the worst case is a
distraction and evasion.

Some protocol updates will be merely technical optimizations or feature
enhancements that are fairly uncontroversial...but some will inevitably be
highly controversial with real-world economic consequences, winners and
losers. We lack a process for deciding these issues. No matter how
sophistocated we make the protocol, somethings will inevitably require
external input to make these issues decidable...it is a Goedelian
implication. This external input could be some sort of vote (of which
hashing power is a particular kind) or perhaps something else.

There's something to be said for building the dynamics of hard forks *into*
our model rather than avoiding it at all costs.  However, forks are the
easy part. The difficulty is in merging different branches. Perhaps we
should learn a thing or two from git. Perhaps the question we should be
asking is not "how do we avoid hard forks" but "how can we design the
network to allow for merging?"

- Eric Lombrozo
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: A measured response to save Bitcoin Core

[Btc Drak]

On Sun, May 31, 2015 at 1:29 AM, Matt Whitlock 
wrote:

> 3. What *is* clear at this point is that Gavin will move ahead with his
> proposal, regardless of whether the remainder of the Bitcoin Core
> committers agree with him. If he has to commit his changes to Bitcoin XT
> and then rally the miners to switch, then that's what he'll do. He believes
> that he is working in the best interests of Bitcoin (as I would hope we all
> do), and so I do not fault him for his intentions. However, I think his
> proposal is too risky.
>

I seriously doubt if miners and merchants who's income depends on bitcoin
are going to risk a network split. Gavin isn't pedalling some mempool
policy which doesn't affect consensus. The changes have to be universally
adopted by miners and full nodes. If there is any uncertainty about that
global acceptance, those financially dependent on bitcoin will not take the
risk just to be political. You can see how conservative the mining
community is already by their slow upgrade of Bitcoin Core as it is. Even
if some miners and merchants generally support the idea of bigger blocks,
they most certainly are not going to take the risk of leading a hard fork
when there is substantial risk of it failing.

Until there is actual consensus among the technical community I wouldn't be
too concerned.


> 4. I also think that ignoring the immediate problem is too risky. If
> allowing significantly larger blocks will cause a serious problem for
> Bitcoin (which is a possibility that we cannot rule out, as we lack
> omniscience), then NOT making any change to Bitcoin Core will virtually
> *assure* that we cause exactly this problem, as the popular (non-technical)
> consensus appears to be in favor of Bitcoin XT and a larger block size
> limit. If we do nothing, then there's a very real chance that Bitcoin XT
> takes over, for better or worse.
>

I don't think anyone is ignoring the issues, nor that everyone accepts that
blocksize may have to eventually change. The overwhelming technical
majority do not agree there is a problem that needs to be immediately
addressed. It would be far more helpful if we focused on stuff that helps
enable level 2 technologies so that bitcoin can actually scale, (like
R/CLTV and malleability fixes which are being delayed by BIP66 rollout and
pending the new "concurrent soft-forks" proposal).


> 7. It's not a given that blocks will immediately expand to meet the hard
> limit. In fact, there are strong and compelling arguments why this will NOT
> happen. But in any software system, if a given scenario is *possible*, then
> one MUST assume that it will happen and must have a plan to handle it.
>

But of course it would be dealt with if and when it becomes necessary. It's
not like there is blanket opposition to increasing the blocksize ever, it's
the matter of if, when and how; but when is defintely not now.

9. My proposal is that we raise the block size limit *gradually*, using an
> approximately smooth function, without a step discontinuity. We can employ
> a linear growth function to adjust the block size limit *smoothly* from 1
> MB to 20 MB over the course of several years, beginning next March.
>

Automatic or dynamic blocksize increase risks being very difficult to shut
down if later we find it is negatively impacting the ecosystem... and
that's part of the reluctance with bigger blocks because we still have not
studied the potential downsides enough beyond some sketchy and disputed
calculations and overall it's not addressing scalability at all.


> 10. This is the difference between cannonballing into the deep end of the
> pool and walking gingerly down the steps into the shallow end. Both get you
> to the eventual goal, but one is reckless while the other is measured and
> deliberate. If there's a problem that larger blocks will enable, then I'd
> prefer to see the problem crop up gradually rather than all at once. If
> it's gradual, then we'll have time to discuss and fix it without panicking.


Extending blocksize now would be nothing more than a political move. I have
no idea what will be decided in the end, but I do know that in order for
bitcoin to survive, changes must be based on well thought out and discussed
technical merits and not the result of political pressure. Politics and
good software do not mix.

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

Re: [Bitcoin-development] Proposal: A measured response to save Bitcoin Core

[s7r]

Hi,

For the less crypto engineering experts but highly interested in Bitcoin
and working with Bitcoin on daily basis reading the list, what would be
an easy to understand explanation about how does this solution represent
a good fix?

So, we have a hard cap of 1 MB block currently. This is not enough
because more and more people use Bitcoin and the transaction volume
increased (yeey, good news). So, rather than fixing the issue for good,
we just increase the block size hard cap to 20 MB. I will not discuss if
this causes problems or not. But what are the future plans, when the 20
MB hard cap will be reached? Increase it again? This doesn't sound like
a fix, it sounds more like pushing the can down the road. Obviously if 1
MB is not enough now, we have the reasonable suspicion that 20 MB could
not be enough in few years.

What is the explanation that 20 MB blocks will be sufficient for life
time? Is it because 'probably other solutions will appear, such as
micropayment channels and offchain transactions'?  If this is the case,
those can easily function with 1 MB blocks as well, and we should see
those in action sooner rather than later.

I run multiple full nodes, including one with Bitcoin XT and I don't
want to see Bitcoin XT and Bitcoin Core divide into different consensus
and create 2 altcoins instead of one Bitcoin.

On 5/31/2015 3:29 AM, Matt Whitlock wrote:
> Greg, Pieter, Jeff, and Wladimir,
> 
> I'll try to be brief to respect your time.
> 
> 1. I don't want to see Bitcoin die.
> 
> 2. As has been discussed on this list and elsewhere: Bitcoin could 
> potentially die due to economic and/or game-theoretic complications arising 
> from raising the block size limit, but Bitcoin could also die due to 
> usability complications arising from NOT raising the block size limit. 
> Strong, personally held opinions by various members of this community 
> notwithstanding, it is not clear which of these scenarios is more likely.
> 
> 3. What *is* clear at this point is that Gavin will move ahead with his 
> proposal, regardless of whether the remainder of the Bitcoin Core committers 
> agree with him. If he has to commit his changes to Bitcoin XT and then rally 
> the miners to switch, then that's what he'll do. He believes that he is 
> working in the best interests of Bitcoin (as I would hope we all do), and so 
> I do not fault him for his intentions. However, I think his proposal is too 
> risky.
> 
> 4. I also think that ignoring the immediate problem is too risky. If allowing 
> significantly larger blocks will cause a serious problem for Bitcoin (which 
> is a possibility that we cannot rule out, as we lack omniscience), then NOT 
> making any change to Bitcoin Core will virtually *assure* that we cause 
> exactly this problem, as the popular (non-technical) consensus appears to be 
> in favor of Bitcoin XT and a larger block size limit. If we do nothing, then 
> there's a very real chance that Bitcoin XT takes over, for better or worse.
> 
> 5. I'd like to propose a way that we can have our cake and eat it too. My 
> proposal attempts to satisfy both those who want larger blocks AND those who 
> want to be extremely cautious about changing the fundamental economic 
> parameters of Bitcoin.
> 
> 6. Something I've never understood about Gavin's (et al.) proposal is why 
> there is a massive step right up front. Assuming we accept his argument that 
> we're critically close to running out of capacity, I still must ask: why do 
> we need a 20x increase all at once?
> 
> 7. It's not a given that blocks will immediately expand to meet the hard 
> limit. In fact, there are strong and compelling arguments why this will NOT 
> happen. But in any software system, if a given scenario is *possible*, then 
> one MUST assume that it will happen and must have a plan to handle it.
> 
> 8. My primary objection is not to raising the block size limit; my objection 
> is to raising it *suddenly*. You can argue that, because we'll have plenty of 
> time before March 2016, it's not "sudden," but, whether we do it now or a 
> year from now or a decade from now, a step function is, by definition, sudden.
> 
> 9. My proposal is that we raise the block size limit *gradually*, using an 
> approximately smooth function, without a step discontinuity. We can employ a 
> linear growth function to adjust the block size limit *smoothly* from 1 MB to 
> 20 MB over the course of several years, beginning next March.
> 
> 10. This is the difference between cannonballing into the deep end of the 
> pool and walking gingerly down the steps into the shallow end. Both get you 
> to the eventual goal, but one is reckless while the other is measured and 
> deliberate. If there's a problem that larger blocks will enable, then I'd 
> prefer to see the problem crop up gradually rather than all at once. If it's 
> gradual, then we'll have time to discuss and fix it without panicking.
> 
> 11. I am offering to implement this proposal and submit a pu

Re: [Bitcoin-development] Block Size Increase Requirements

[Peter Todd]

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


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development