Gold collapsing. Bitcoin UP.

[cypherdoc]

and you thought Bitcoin was volatile?  pfft.  peanuts to the stock mkt; huge opening gap down from last nights futures dump, all the way back up to retest the flat, followed by another huge dump down.  it will only get worse:

[1714293759]

1714293759

[cypherdoc]

I favor Adam Backamoto's

stop equating Adam to Satoshi.  no contest.

you have a serious Daddy problem.

[cypherdoc]

oh my, ugly as hell:

[tvbcof]

I favor Adam Backamoto's

stop equating Adam to Satoshi.  no contest.

you have a serious Daddy problem.

No where near as serious as those who consider cypherdoc to be some sort of daddy figure.  There are probably vastly fewer who consider you to be 'the LeBron James of Bitcoin' than you and your attorney might imagine.  Probably there are a handful though which is pretty sad.

The LeBron assertion is hilariously funny though one way or another.  Whether it was you or your attorney who came up with that one, kudos for the comic relief.

[lunarboy]

 lots of short hair in Greece in the next few weeks.  


Haircuts all round https://www.ecb.europa.eu/press/pr/date/2015/html/pr150706.en.html

http://www.zerohedge.com/news/2015-07-06/it-begins-ecb-adjusts-greek-ela-haircuts-full-depositor-bail-sensitivity-analysis

[cypherdoc]

meanwhile, my full nodes sit here totally unstressed and under-utilized.  

[cypherdoc]

meanwhile, my full nodes sit here totally unstressed and under-utilized.  

i thought gmax et al said "large" blocks were going to collapse my nodes?

[hdbuck]

wow, Varoufakis out.  one less Bitcoin Bear; altho we still have lots of them roaming around here:

http://www.nytimes.com/2015/07/07/business/international/yanis-varoufakis-abruptly-resigns-as-greek-finance-minister.html?hp&action=click&pgtype=Homepage&module=a-lede-package-region&region=top-news&WT.nav=top-news&_r=0

heh, this guys is not so out.
I predict he will come back very shortly, once it will be crystal clear that the EUsters wont be able to find any deal..
Could be president of the new Greek's central bank! ^^

[iCEBREAKER]

Even if mining pools set higher fees, aren't the unconfirmed TX's still added to their mempools?

No.

In other words, cypherdoc is clueless about how Bitcoin works.

Moar like the LeBron of Lasik, am I right?   

[gmaxwell]

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.

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.

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.

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

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.

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.

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.

[cypherdoc]

the spammers smell blood.  and the core devs do nothing:

[tvbcof]

Even if mining pools set higher fees, aren't the unconfirmed TX's still added to their mempools?

No.

In other words, cypherdoc is clueless about how Bitcoin works.

Moar like the LeBron of Lasik, am I right?   

Doubtful.  Dr. Lowelife spends every waking moment on bitcointalk and reddit so it seems.  A malpractice suite which stuck is one hypothesis which springs to mind, and could explain an early and intense interest in asset protection.  A clinic full of subordinate eye frying minions would be another.  Neither these or countless others are really interesting enough for me to spend much time on, but perhaps others who are more into such things would ferret out this mystery.

Many of my co-workers kept a stock market ticker within easy visual reach and referred to them about 60 times per hour as they performed the tasks of the day.  That's fine for code monkeys, but for someone doing eye surgery with laser beams it's an entirely different ball of wax.

[iCEBREAKER]

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.

Basic misunderstanding there

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.
 

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.

The more gmax patiently ELI5s basic Bitcoin 101 to Frap.doc, the more Frap.doc looks like a five year old.   

[domob]

meanwhile, my full nodes sit here totally unstressed and under-utilized.  

i thought gmax et al said "large" blocks were going to collapse my nodes?

I've been reading this thread since a long time, and mostly enjoyed the economic insights it used to be about.  However, I can only agree with those who see cypherdoc's reputation fading with his supposedly technical comments like the one above.  It has been pointed out repeatedly and should be clear as day - currently we have the 1 MB limit you are complaining about.  That's precisely why your nodes are "unstressed and under-utilized".  From the current stress on your nodes, you can at best guess very vaguely at what they would be doing with larger blocks.  I don't see why that's an argument you make in favour of increasing the blocksize.  (Same as your comments about "full" blocks that were debunked by others above.)

[cypherdoc]

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.

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.

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.

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

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.

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?

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.

[cypherdoc]

meanwhile, my full nodes sit here totally unstressed and under-utilized.  

i thought gmax et al said "large" blocks were going to collapse my nodes?

I've been reading this thread since a long time, and mostly enjoyed the economic insights it used to be about.  However, I can only agree with those who see cypherdoc's reputation fading with his supposedly technical comments like the one above.  It has been pointed out repeatedly and should be clear as day - currently we have the 1 MB limit you are complaining about.  That's precisely why your nodes are "unstressed and under-utilized".  From the current stress on your nodes, you can at best guess very vaguely at what they would be doing with larger blocks.  I don't see why that's an argument you make in favour of increasing the blocksize.  (Same as your comments about "full" blocks that were debunked by others above.)

no, memory is not just used for 1MB blocks.  it's also used to store the mempools plus the UTXO set.  large block attacks have the potential to collapse a full node by overloading the memory.  at least, that's what they've been arguing.

[Adrian-x]

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.

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.

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.

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

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.

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.

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.

I have highlighted in red what should be considers external capital investment costs and part of the business decisions of miners, how these issues are resolved is not part of the bitcoin protocol. Its not up to the developers to optimize for miners in China or the moon, or on earth for that matter.

If someone was to build 60% of the hashing power, all the power too them, the Bitcoin protocol manages only so much and then there is game theory and the Nash equilibrium to manage the extreme circumstances like 60% of the hashing power coming from a single facility in China or the Moon.    

When it comes to orphaning races miner sizes matters as does optimizing your business to leverage the inherent limitations in technology, and the guidelines of the protocol. Managing orphans is an essential function that keeps the incentives in the Bitcoin Protocol distributed and functioning, reporting a 4% orphan rate from memory when your pool was small and starting out is very different than publishing verifiable numbers. The protocol was designed with the fact that we dont live in a harmonious world where resources are not optimally distributed.

Why should we change it?

[traderCJ]

Even if mining pools set higher fees, aren't the unconfirmed TX's still added to their mempools?

No.

In other words, cypherdoc is clueless about how Bitcoin works.

Moar like the LeBron of Lasik, am I right?   

Doubtful.  Dr. Lowelife spends every waking moment on bitcointalk and reddit so it seems.  A malpractice suite which stuck is one hypothesis which springs to mind, and could explain an early and intense interest in asset protection.  A clinic full of subordinate eye frying minions would be another.  Neither these or countless others are really interesting enough for me to spend much time on, but perhaps others who are more into such things would ferret out this mystery.

Many of my co-workers kept a stock market ticker within easy visual reach and referred to them about 60 times per hour as they performed the tasks of the day.  That's fine for code monkeys, but for someone doing eye surgery with laser beams it's an entirely different ball of wax.

So now we know what his "highly successful business" entailed.  

[gmaxwell]

no, memory is not just used for 1MB blocks.  it's also used to store the mempools plus the UTXO set.  large block attacks

Again, you're wrong on the technology. The UTXO set is not held in ram. (There is caching, but its arbritary in size, controlled by the dbcache argument).

have the potential to collapse a full node by overloading the memory.  at least, that's what they've been arguing.

"They" in that case is sketchy nutballs advocating these "stress tests", and _you_ arguing that unconfirmed transactions are the real danger.

Super weird that you're arguing that the Bitcoin network is overloaded with average of space usage in blocks, while you're calling your system "under utilized" when you're using a similar proportion of your disk and enough of your ram to push you deeply into swap.

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.

PeterR wasn't saying anything about mempools, and-- in fact-- he responded expressing doubt about your claim that mempool size had anything to do with this.  Moreover, I gave instructions that allow _anyone_ to measure verification times for themselves.  Your argument was that miners would be burned by unconfirmed transactions, I responded that this isn't true-- in part because they can keep whatever mempool size they want.

To further make the point about mempools, here is what the mempool looks like on a node with mintxfee=0.0005 / minrelaytxfee=0.0005 set:


$ ~/bitcoin/src/bitcoin-cli  getmempoolinfo
{
    "size" : 301,
    "bytes" : 271464
}

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.

Their response was not to use smaller blocks, their response was to stop validating entirely.  (And, as I pointed out-- other miners are apparently mining without validating and still including transactions).

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.

If we're going to accept that every correlation means causation;  what should we say about the correlation between finding out that you've taken hundreds of thousands of dollars in payments for paid shilling and finding out loud and opinionated you are on this blocksize subject?

In this case, these forks are only visible by someone mining an invalid block, which no one had previously done for over a year.

if they are seeing inc orphans, why haven't they retracted their support of Gavin's proposal

They are no longer seeing any orphans at all, they "solved" them by skipping validation entirely. They opposed that initial proposal, in fact, and suggested they could at most handle 8MB, which brought about a new proposal which used 8MB instead of 20MB though only for a limited time. Even there the 8MB was predicated on their ability to do verification free mining, which they may be rethinking now.

i don't believe that.

I am glad to explain things to people who don't understand, but you've been so dogmatically grinding your view that it's clear that every piece of data you see will only "confirm" things for you; in light of that I don't really have unbounded time to waste trying. Perhaps someone else will.

[Odalv]

... what should we say about the correlation between finding out that you've taken hundreds of thousands of dollars in payments for paid shilling and finding out loud and opinionated you are on this blocksize subject?

I will not be surprised if this is true. Only I'll expect higher price  ... few millions. He is fighting hard.