Quote from: gmaxwell on July 06, 2015, 06:49:46 PM

Quote from: cypherdoc on July 06, 2015, 05:52:35 PM

since small pools can also connect to the relay network, and i assume they do, there is no reason to believe that large miners can attack small miners with large blocks. in fact, we've seen the top 5 chinese miners deprecated due to the GFC making it clear they CANNOT perform this attack despite what several guys have FUD'd.

Basic misunderstanding there--- Being a larger miner has two effects: One is throughput not latency related: Being larger creates a greater revenue stream which can be used to pay for better resources. E.g. if the income levels support one i7 CPU per 10TH/s of mining, then a 10x larger pool can afford 10x more cpus to keep up with the overall throughput of the network, which they share perfectly (relay network is about latency not so much about throughput-- its at best a 2x throughput improvement, assuming you were bandwidth limited); the other is latency related, imagine you have a small amount of hashpower-- say 0.01% of the network-- and are a lightsecond away on the moon. Any time there is a block race, you will lose because all of the earth is mining against you because they all heard your block 1+ seconds later. Now imagine you have 60% of the hashpower on the moon, in that case you will usually win because even though the earth will be mining another chain, you have more hashpower. For latency, the size of miner matters a lot, and the size of the block only matters to the extent that it adds delay.

i don't believe that. when i ran my small solo mining pool, i'll bet that the quality of my resources and bandwidth were superior to that of the large mining pools i've seen in the videos. furthermore, if my small pool is connected to the same relay network as a large miner, then the transmission of our respective blocks on the moon should reach earth at the same time, thus, our respective chances to find the next block simply goes back to our respective % hashrates compared to the network.

Quote

When it comes to orphaning races miner sizes matters, in some amount that is related to the product of the size-of-the-miner and time it takes to validate a block.

Quote

how can that be? mining pools all use a full node around which they coordinate their mining. all full nodes are relatively in sync with their mempools

There is no requirement that mempools be in sync, -- in fact, they're not and the whole purpose of the blockchain is to synchronize nodes. The mempools of nodes with identical fee and filtering policies and whom are similarly positioned on the network will be similar, but any change in their policies will make them quite different.

well, that was precisely Peter's mathematical point the other day that you summarily dismissed. f2pool and Antminer are NOT in a similar position on the network as they are behind the GFC. they have in fact changed their verification policies in response to what they deem are large, full blocks as a defensive measure. that's why their average validation times are 16-37sec long and NOT the 80ms you claim. thus, their k validation times of large blocks will go up and so will their number of 0 tx SPV defensive blocks. and that's why they've stated that they will continue to mine SPV blocks. thanks for making his point.

it also is a clear sign that miners do have the ability and financial self interest to restrict block sizes and prevent bloat in the absence of a block limit.

Quote

IBLT doesn't currently exist, and other mechenisms like the relay network protocol don't care about mempool synchronization levels.

Quote

pt being, it's statistically unlikely that full blocks today represent the magical level of "large" blocks that Satoshi set 6 yrs ago. the problems we are having with the forks are a result of the defensive tactics being taken from those full blocks.

Almost none of the blocks have been 1MB, the issues arise before then. _Consistent_ 1MB blocks wouldn't have been supportable on the network at the time that limit was put in place-- back in the 0.5.x-ish days we were getting up to 2minutes for a 100k block to reach the whole network; the 1MB was either forward-looking, set too high, or only concenred about the peak (and assuming the average would be much lower) ... or a mixture of these cases.

these SPV related forks have only occurred, for the first time ever, now during this time period where spammers are filling up blocks and jacking up the mempool. full blocks have been recognizable as 950+ and 720+kB. this is undeniable.

Quote

Quote

have the Chinese miners given you a technical reason why they're SPV'ing?

F2Pool reported that as block sizes grew they saw increased orphaning rates and that they were seeing an orphan rate of 4% though this was at a time before the relay network and when GHash in europe had ~50% of the hashpower under them. Excluding the recent issues they've had almost no orphans since, they report.

if they are seeing inc orphans, why haven't they retracted their support of Gavin's proposal for an immediate inc to 8MB?

Quote

Quote from: Wexlike on July 06, 2015, 05:56:53 PM

Then why don't we decrease the blocktime from 10 min down to let's say 2 min. This way we can also have more transactions/second without touching the blocksize.

Ouch, the latency related issues issues are made much worse by smaller interblock gaps once they are 'too small' relative to the network radius. When a another block shows up on the network faster than you can communicate about your last you get orphaned. And for throughput related bottlenecks it doesn't matter if X transactions come in the form of a 10mb block or 10 1mb blocks.