Gold collapsing. Bitcoin UP.

[iCEBREAKER]

i didn't say this full block spam attack we're undergoing wasn't affecting my node at_all.  sure, i'm in swap, b/c of the huge #unconf tx's but it hasn't shut down or stressed my nodes to any degree.  one of the arguments by Cripplecoiners was that these large block attacks would shut full nodes down from destabilization resulting in centralization.  i'm not seeing that.

The 1MB sanity check/safety limit is the reason you aren't seeing nodes destabilized by "huge #unconf tx's."

We would be "seeing that" if gavin@tla.mit.gov and hearn@google.mil had gotten their way and successfully rammed through their poorly researched, hilariously ill-conceived 20MB proposal.

Luckily, Team Gavincoin got fukkin' r3kt exactly as I foretold:

[1714041309]

1714041309

[1714041309]

1714041309

[TPTB_need_war]

Luckily, Team Gavincoin got fukkin' r3kt exactly as I foretold:

Oh I didn't realize we are modeling this in a video game.

[smooth]

Conclusions are valid in substance but in terms of not getting blocks for days, that's not really a big problem for a pool (or solo mining farm) being run as a business. Most expenses (hosting, etc) are going to run monthly, possibly somewhat more often (paying workers), but not daily. Once you look at a one-month window it is about the same as Litecoin: almost certain to find a block in a month. With some ability to draw on reserves or credit in the event of a few bad months it should still be viable.

I think you missed the economic reasoning, which is that pools have to compete at near 0 margins which means any losses due to overpaying some ephemeral miners during periods (e.g. any variant of pool hopping or just miners who come and go for any reason), is bankruptcy relative to those with larger hashrate share which don't incur that variance in profitability.

That is not clear as long as the pools are differentiated (for example by geography/latency, support, value added features). They have to compete but they are providing a service and can charge for it. f2pool charges 4% for PPS. Presumably they have some (imperfect) defenses against pool hoppers that to make that margin profitable. AntPool charges 2.5% for PPS and likewise must be able to cover losses. AntPool offers PPLNS which isn't susceptible to hopping at all, but obviously shifts some variance to miners.

I agree variance favors large pools to a point (and I said so in my previous post). At some point though, possibly as little as 1% of total hash rate (where blocks are found essentially every month), the variance isn't necessarily significant to operations, and things like geographic diversity may dominate. At, say, 0.01% it would be catastrophic so this certainly puts a lower limit on pool size without some other form of centralization (sharing rewards between pools, which could include sybils).

At some much smaller fraction (e.g. <0.00001%) solo mining becomes a lottery with a low ticket cost and variance might be desired or irrelevant.

[IIOII]

i didn't say this full block spam attack we're undergoing wasn't affecting my node at_all.  sure, i'm in swap, b/c of the huge #unconf tx's but it hasn't shut down or stressed my nodes to any degree.  one of the arguments by Cripplecoiners was that these large block attacks would shut full nodes down from destabilization resulting in centralization.  i'm not seeing that.

The 1MB sanity check/safety limit is the reason you aren't seeing nodes destabilized by "huge #unconf tx's."

We would be "seeing that" if gavin@tla.mit.gov and hearn@google.mil had gotten their way and successfully rammed through their poorly researched, hilariously ill-conceived 20MB proposal.

Luckily, Team Gavincoin got fukkin' r3kt exactly as I foretold:
[img]

If you ask me, Gavin is a burden for Bitcoin, because he is constantly out for a power grab (the Bitcoin Foundation was his first attempt). His narcissistic behavior is unacceptable and his suggestions are unscientific (although he claims to be "chief scientist") and lack substance. He should be forced to surrender his development privileges.

Sadly, so many people follow him blindly, just because he enjoys the public spotlight.

[TPTB_need_war]

Conclusions are valid in substance but in terms of not getting blocks for days, that's not really a big problem for a pool (or solo mining farm) being run as a business. Most expenses (hosting, etc) are going to run monthly, possibly somewhat more often (paying workers), but not daily. Once you look at a one-month window it is about the same as Litecoin: almost certain to find a block in a month. With some ability to draw on reserves or credit in the event of a few bad months it should still be viable.

I think you missed the economic reasoning, which is that pools have to compete at near 0 margins which means any losses due to overpaying some ephemeral miners during periods (e.g. any variant of pool hopping or just miners who come and go for any reason), is bankruptcy relative to those with larger hashrate share which don't incur that variance in profitability.

That is not clear as long as the pools are differentiated (for example by geography/latency, support, value added features). They have to compete but they are providing a service and can charge for it. f2pool charges 4% for PPS. Presumably they have some (imperfect) defenses against pool hoppers that to make that margin profitable. AntPool charges 2.5% for PPS and likewise must be able to cover losses. AntPool offers PPLNS which isn't susceptible to hopping at all, but obviously shifts some variance to miners.

I agree variance favors large pools to a point (and I said so in my previous post). At some point though, possibly as little as 1% of total hash rate (where blocks are found essentially every month), the variance isn't necessarily significant to operations, and things like geographic diversity may dominate. At, say, 0.01% it would be catastrophic so this certainly puts a lower limit on pool size without some other form of centralization (sharing rewards between pools, which could include sybils).

But any margin they charge can be beat by a pool that has less variance and thus doesn't have to account for the risk in their margins.

As to whether other (economic and marketing) factors such as geographical distance or jurisdiction could defend higher margins, I have not analyzed the pool market (distinguished from the in-band economics) but one would think that a Sybil attack could put servers in multiple locations. This wouldn't impact the advantage of having them share risk by sharing block rewards, unless there was Coasian jurisdictional obstruction to doing so (which they could probably subvert any way).

I don't know where the inflection point occurs where increasing hashrate share as it pertains to variance risk becomes over weighed by other factors in terms of relative profitability and marketing, but it looks unlikely to be as low as 1% which already somewhat centralized (51 pools maximum can do a 51% attack). Perhaps I should endeavor to attempt some mathematical model. And it appears unlikely that we can optimize away all of the latency costs, so that is another factor giving higher profitability to higher hashrate, with 1% share no where near diminishing returns on that vector in isolation. It is a complex model perhaps ... would need to spend more time thinking about it. Is anyone doing research in this area?

I'd be very surprised if we don't have 10 controlling entities (perhaps hidden) of pools that can do a 51% attack, especially as we scale up transaction volume to Visa scale.

At some much smaller fraction (e.g. <0.00001%) solo mining becomes a lottery with a low ticket cost and variance might be desired or irrelevant.

I suppose you're thinking of 21 Inc's plan for zombie miners?

[iCEBREAKER]

ok, i'm not getting the bolded part.  this graph shows 37 MB worth of unconf tx's, no?:

No clue, no node I have access to is seeing that much-- they may have turned off the minfee rules (not unreasonable for a metrics thing)...

Even given that, again, 37MB doesn't explain your swap.

yeah, i had noticed that.  strange...

Maybe a bloated swap file is a surprise Easter egg 'feature' of XT nodes?

As I said weeks ago, good luck getting BTC core devs to help fix it when your Gavinsista troll fork goes haywire.   

[smooth]

I suppose you're thinking of 21 Inc's plan for zombie miners?

Somewhat. I'm simply thinking that a large number of smaller miners (whether of the variety envisioned by 21 Inc or otherwise) has an advantage because none of them particularly care about variance or actually prefer it, both for lottery reasons and because in general increased variance is a good way to reduce effective transaction costs.

[thezerg]

You people are getting vicious and inane.  Name calling like a pack of 8 year olds? 

On another topic:

http://rusty.ozlabs.org/?p=515

The obvious place to look is CheckBlock: a simple 1MB block takes a consistent 10 milliseconds to validate, and an 8MB block took 79 to 80 milliseconds, which is nice and linear.  (A 17MB block took 171 milliseconds).

Weirdly, that’s not the slow part: promoting the block to the best block (ActivateBestChain) takes 1.9-2.0 seconds for a 1MB block, and 15.3-15.7 seconds for an 8MB block.  At least it’s scaling linearly, but it’s just slow.

Not quite Peter R's calculated value, but indicative that there may be issues hidden in the code that do sum up to significant block delay.

[iCEBREAKER]

You people are getting vicious and inane.  Name calling like a pack of 8 year olds? 

I know right?  If you're going to start referring to Bitcoin as "Cripplecoin" /r/buttcoin is over ==> there.

[Peter R]

http://rusty.ozlabs.org/?p=515

The obvious place to look is CheckBlock: a simple 1MB block takes a consistent 10 milliseconds to validate, and an 8MB block took 79 to 80 milliseconds, which is nice and linear.  (A 17MB block took 171 milliseconds).

Weirdly, that’s not the slow part: promoting the block to the best block (ActivateBestChain) takes 1.9-2.0 seconds for a 1MB block, and 15.3-15.7 seconds for an 8MB block.  At least it’s scaling linearly, but it’s just slow.

Not quite Peter R's calculated value, but indicative that there may be issues hidden in the code that do sum up to significant block delay.

The processing time, τ, in my model includes more than what Rusty is considering above.  It includes all delays between the moment the miner has enough information to begin mining (an empty block) on the block header, to the moment he's validated the previous block, created a new non-empty block template, and has his hashing power working on that new non-empty block.  I realize the way I wrote my post, I implied that the validation times were the significant part of τ (which they appear not to be), but that doesn't actually change the results provided the processing time (τ) does indeed tend to increase monotonically with the size of the previous block.  I've edited my post to make this more clear.

Last night, I showed based empirical data that this delay (τ) is significantly larger when the previous block was large, than when the previous block was not large, for F2Pool.  For AntPool, the delay (τ) did not appear to be correlated with the size of the previous block.  

Greg mentioned that he thought the big τ values I'm measuring are due to the lag it takes to re-assign the hashpower to the new non-empty block.  

[kano]

Coz someone linked a post earlier in this thread ...

For pools that normally mine full blocks as well as uncommon empty blocks, the empty blocks are the work the pool sends every block change.
They are of the opinion that because Luke-jr's eloipool is shit slow at handling block changes, they should send out empty work first and then full work soon after it.
Obviously the empty work is mined for a small % of the average block change length so it would also mean that the miners finding block with the empty work would be a smaller % of all the blocks found by the pools that do this.

As I've explained in the empty blocks thread, when comparing eligius with it's empty block change work and my pool https://kano.is/ with our full block change work, my pool beats eligius on average sending out block change work.
During normal times when the relay is working and there isn't a massive spam test running, my pools beats eloipool >90% of the time with block changes.

[cypherdoc]

bad, bad:

[cypherdoc]

Uber bad:

[cypherdoc]

Coz someone linked a post earlier in this thread ...

For pools that normally mine full blocks as well as uncommon empty blocks, the empty blocks are the work the pool sends every block change.
They are of the opinion that because Luke-jr's eloipool is shit slow at handling block changes, they should send out empty work first and then full work soon after it.
Obviously the empty work is mined for a small % of the average block change length so it would also mean that the miners finding block with the empty work would be a smaller % of all the blocks found by the pools that do this.

As I've explained in the empty blocks thread, when comparing eligius with it's empty block change work and my pool https://kano.is/ with our full block change work, my pool beats eligius on average sending out block change work.
During normal times when the relay is working and there isn't a massive spam test running, my pools beats eloipool >90% of the time with block changes.

hey, the great kano.  thx for the explanation.

why haven't i seen Eligius mining 0 tx blocks, or have i just missed it?  so this SPV mining is not confined to China?  i thought this was primarily an inferior connectivity issue behind the GFC?  why haven't we seen it before with Eligius if this is his norm?

[cypherdoc]

look at what we're facing with this latest spam attack.  note the little blip back on May 29 which was Stress Test 1.  Stress Test 2 is the blip in the middle with the huge spikes of the last couple of days on the far right.  this looks to me to be the work of a non-economic spammer looking to disrupt new and existing users via stuck tx's which coincides with the Grexit and trouble in general in the traditional fiat markets.  they want to discourage adoption of Bitcoin.  the fastest way to eliminate this attack on users is to lift the block size limit to alleviate the congestion and increase the expense of the spam:

So you think that it would be best to simply put all that spam on the blockchain, and have everyone that ever wants to validate it go through that spam for eternity?  Wouldn't it be better to simply let the network and miners adjust their fee policies instead as they see fit and make sure that the spam is not even mined unless they pay "enough" fees?

the problem with the latter approach is that you are going to kill new user growth as well as adversely affect existing user experience.  as solex said earlier, even $0.14 is too much.

it would be better to eliminate the block cap and eliminate the spammers ability to effect the users at_all.  this would allow new user growth to square the value of the network according to Metcalfe's Law.  

furthermore, the resulting user growth should inc tx's and inc merchants ALL of which should jack the price way high.  then, we all might be able to afford a full node.

by lifting the cap, the spammers no longer have a well defined block cap target and attacks would become dramatically more expensive.  also, gmax taught us that with minfee fine tuning on the part of the miners, they have the ability to defend themselves and the network from bloated 0confs sets which can help control memory overloads.  even full nodes have the capacity to do this if they want.  

furthermore, it gets core dev out of the business of picking winners and losers; a position they should want to give up for the good of Bitcoin and to minimize the pressure and spotlight.  let the miners and users work out the fee market.

[kano]

...
why haven't i seen Eligius mining 0 tx blocks, or have i just missed it?  so this SPV mining is not confined to China?  i thought this was primarily an inferior connectivity issue behind the GFC?  why haven't we seen it before with Eligius if this is his norm?

They do >2% since they started according to
https://bitcointalk.org/index.php?topic=1085800.msg11805900#msg11805900

I not sure how much verification eloipool does but it does enough to avoid the v2/v3 fork that happened so it's not completely without verification.

[cypherdoc]

...
why haven't i seen Eligius mining 0 tx blocks, or have i just missed it?  so this SPV mining is not confined to China?  i thought this was primarily an inferior connectivity issue behind the GFC?  why haven't we seen it before with Eligius if this is his norm?

They do >2% since they started according to
https://bitcointalk.org/index.php?topic=1085800.msg11805900#msg11805900

I not sure how much verification eloipool does but it does enough to avoid the v2/v3 fork that happened so it's not completely without verification.

wouldn't it be enough to just ask Luke how much verification he does?

[cypherdoc]

So you think that it would be best to simply put all that spam on the blockchain, and have everyone that ever wants to validate it go through that spam for eternity?  Wouldn't it be better to simply let the network and miners adjust their fee policies instead as they see fit and make sure that the spam is not even mined unless they pay "enough" fees?

Who decides what enough fees is?

I think this whole blocksize debate comes down to ideology.  It's not a technical decision. Some people think we need to keep 1 degree of freedom of control to shape Bitcoin "correctly," while others think we should let destiny take the wheel.

it certainly does.

you once described Bitcoin in a helpful way; it represents Hope. 

i also happen to think it represents Sound Money.  Bitcoin has become a public good which cannot be seen to be influenced by any group with a financial interest.  it's the People's Money after all.

[cypherdoc]

You think that because you are blinded.

My well informed, prescient suggestion is wholeheartedly support the pegged side chain direction; otherwise prepare to exchange your BTC for another monetary unit or accept centralization.

I've got to put this type of comment in the "give-up" file.
It would have merit if the following weren't the case:

x=Software & design optimizations. e.g. BitcoinCore is orders of magnitude faster in many respects than in 2009.
y=Moore's "Law" and Nielsen's "Law" and other relevant descriptions of the rate of improvement in computing technology

x*y > rate-of-growth-of-the-world-economy  (here's a visual)



It is only a matter of time before Bitcoin can handle a large proportion of world transactions. The key thing is not to f*ck up the process in the meantime.

others think we should let destiny take the wheel.

I think this is the only viable option.

yes solex.  i think this is the only way.

[kano]

...
why haven't i seen Eligius mining 0 tx blocks, or have i just missed it?  so this SPV mining is not confined to China?  i thought this was primarily an inferior connectivity issue behind the GFC?  why haven't we seen it before with Eligius if this is his norm?

They do >2% since they started according to
https://bitcointalk.org/index.php?topic=1085800.msg11805900#msg11805900

I not sure how much verification eloipool does but it does enough to avoid the v2/v3 fork that happened so it's not completely without verification.

wouldn't it be enough to just ask Luke how much verification he does?

Because his answers are often misleading

A good example of this in the "Empty Block" discussion is how people were saying they aren't confirming transactions.
His answer was that they are confirming transactions ... previous transactions.
So the statement needed to be "they aren't confirming new transactions" which of course is what was meant, but he decided to avoid the issue with a technicality