what can i do to get connections unstuck from zero? "version" : 110000,
"protocolversion" : 70002,
"walletversion" : 60000,
"balance" : 0.00000000,
"blocks" : 366904,
"timeoffset" : 0,
"connections" : 0,
"proxy" : "",
"difficulty" : 51076366303.48192596,
"testnet" : false,
"keypoololdest" : 1407033834,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"relayfee" : 0.00001000,
"errors" : " " |
|
|
|
To all the talented devs out there reading this thread, here's your chance to be a part of the new XT core team. |
|
|
|
how does it not correlate with my theory? yours is just a long term zoom out of the hashrate which obscures the shorter effect of the stress test.
I think, everybody can see that the hashrate is growing. No matter if there is "stress test" or not. And it is obvious that bitcoin price was $318 during the time you took days off. Haha Odalv: You should keep in mind this while posting. Maybe then you would take a full quote of a post, instead of just extracting a part out of its context in order to prove your point. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
But I guess that intellectual honesty has never been your goal here [/quote]  edit: are you on drugs ? [/quote] Fixed. Troll. |
|
|
|
how does it not correlate with my theory? yours is just a long term zoom out of the hashrate which obscures the shorter effect of the stress test.
I think, everybody can see that the hashrate is growing. No matter if there is "stress test" or not. And it is obvious that bitcoin price was $318 during the time you took days off. Haha Odalv: You should keep in mind this while posting. But I guess that intellectual honesty has never been your goal here |
|
|
|
|
missed the part about KNC and 16nm. sure, that could be it also altho given that post is from June 3 it's not clear if those are online yet.
|
|
|
|
notice how the extra fees paid by full blocks actually strengthened the mining hashrate during the last attacks. probably the extra revenue from tx fees encouraged miners to bring on more hashrate. that's a good thing and could actually be even better if they were allowed to harvest/clear all the additional fees in the bloated mempools:  your willingness to connect two dots is astounding notice how i used that graph in a series of graphs and data to support my supposition. unlike you who is here to troll and cherrypick. Do not spread nonsenses. How this chart correlates with your theory.  And look at this http://www.kncminer.com/blog/newsarchive#changing-the-game-againhow does it not correlate with my theory? yours is just a long term zoom out of the hashrate which obscures the shorter effect of the stress test. |
|
|
|
decision to force a fee market is a centralized solution
On it's face this is a nonsense argument since any development decisions are centralized in the same manner. Increase the blocksize, decrease the blocksize, or leave it alone, they are all (centralized) development decisions. It's also false that anything is really centralized about it because if there were truly a consensus for change (over the objections of the 'centralized' developers) there would be a successful fork. Yes all dev decisions are essentially centralized, including the decision to NOT do something. Since that is trivially true, I am talking about the effect of the decision. And in one case miners can optimize their profitability by choosing to include transactions while in another case they are artificially limited. Listen to New Liberty, he got this completely right. Whether miners can optimize their profitability is beside the point, because in doing so they also influence others' costs, and they are most certainly not optimizing that. The idea of a sensible market arising for block size in the current structure if the consensus block size rule (which is the only mechanism for the "others" in the previous paragraph to participate in such a market) is a fantasy. i don't get this at all. as a former miner, given all the investment in mining equipment one has to make along with all the labor and ongoing costs, any profit the miner makes is deserved; and it's often not that much of a profit. full nodes, otoh, only have to rent a vps at most which is minimal cost. all this complaining by LukeJr et al about everyone else forcing him to bear costs in Bitcoin is ridiculous. by running a full node you're helping to prop your investment in the coin and you should be using it to secure your own tx's; which should be a security measure you're willing to pay for. as the user base grows, if we let it, then merchant base grows with it and they will be more than willing from a security and fiduciary standpoint to increase the availability of full nodes across the network. and as far as game theory with miners goes, they sure do have an incentive to optimize the size of their blocks thru fear of orphaning and thru fear of causing disruption to full nodes and users which both would decrease their surrounding security and tx throughput in terms of fees by users. not to mention constantly having a Damocle's Sword over their heads via their hashers who can move to another pool in an instant. |
|
|
|
notice how the extra fees paid by full blocks actually strengthened the mining hashrate during the last attacks. probably the extra revenue from tx fees encouraged miners to bring on more hashrate. that's a good thing and could actually be even better if they were allowed to harvest/clear all the additional fees in the bloated mempools: your willingness to connect two dots is astounding notice how i used that graph in a series of graphs and data to support my supposition. unlike you who is here to troll and cherrypick. |
|
|
|
Greg has made it abundantly clear that he is a Bear on Bitcoin. he should step down as a core dev. and what's this about him not thinking Bitcoin can be used on small devices? smartphones are KEY to Bitcoin's long term success.
Yeah... maybe you need to read this again. What did I tell you about putting words in people's mouth. "A bear on Bitcoin"  So much non sense! dude, you need to read Satoshi's post again. he's arguing to keep Bitcoin and BitDNS separate b/c either one of them might want to increase their size: The networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about unreasonably limiting the size of the chain so it's easy for lots of users and small devices.bolded part mine. |
|
|
|
Greg has made it abundantly clear that he is a Bear on Bitcoin. he should step down as a core dev. and what's this about him not thinking Bitcoin can be used on small devices? smartphones are KEY to Bitcoin's long term success. |
|
|
|
Now its Frap.doc's turn to get rekt: Piling every proof-of-work quorum system in the world into one dataset doesn't scale.
Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
i find it amusing that you bash Satoshi on the one hand but when you find a morsel quote of his (which you've misread) you latch onto it as gospel. if you read the actual link you posted, Satoshi was talking about how Bitcoin should not be combined with BitDNS. he's not even talking about tx's. he wanted them to be separate with their own fates. he also drew an extreme example of how BitDNS might want to include other huge datasets while Bitcoin might want to keep it small as an example of how the decision making might diverge btwn the two. not that Bitcoin users wanted to keep a small blockchain. |
|
|
|
1-3mb are ok. 8mb is too much right now (yes the miners are wrong, there's bad stuff they haven't seen yet).
Getting blocks that take >10mins to validate is not a good thing.
I believe Gavin wants to limit TXN size to 100kiB at the same time the bigger block hard fork comes into effect. Shouldn't this very much remove your worries about an increase in blocksize? And, yes, I agree, faster validation is even better than putting another artificial limit into the code base. he's backed off the 100kB tx limit in deference to limiting the #sigops and simplifying the hashing process. for details, someone provide the link to his ML post. |
|
|
|
i think this proves that miners are perfectly capable of handling bigger blocks as evidenced by the "no delays" in confirmation intervals. if anything i find it interesting that they get sped up to <10 min during these attacks. with bigger blocks, we'd clear out that mempool in an instant:  Well, no. Bigger blocks just make the "attacks" marginally more expensive. Individually, I could also swamp the mempool at any of the proposed sizes. The "attacks" are providing some funding, so I don't really mind them all that much. This tragedy of the commons is not quite so tragic as the UTXO set growth and chain size would be with a similar attack on larger blocks, especially if combined with a validation time attack (TX with many inputs and outputs in a tangled array). Very large blocks would be a much more vulnerable environment in which to conduct such an attack. We'll get to the point of ameliorating these vulnerabilities, and the right people are working on it. Patience... Bitcoin is still in beta, its so young. Lets give it the chance to grow up without breaking it along the way. so looking at the peak of the last attack ~40BTC per day worth of tx fees were harvested. let's say we go to 20MB blocks tomorrow. since real tx's only amount to ~500kB per block worth of data, you'd have to essentially fill the 20MB all by yourself and spend 20MB*40BTC=800BTC per day give or take. at $290/BTC that would equal $232000 per day. and then you'd have to sustain that to even dent the network; say for a month. that would cost you $7,000,000 for one month. you sure you can do that all by yourself?  Why would you doubt it? b/c i'm assuming it would be cost prohibitive for you? and pretty much anyone else i might add altho i'm sure you'd argue not for a gvt; which actually might be true which is why i advocate NO LIMIT as that would throw a huge amount of uncertainty as to just how successfully one could jack the mempool in that scenario as it removes user disruption and thus greatly increases the financial risk ANY attacker would be subject o. But in your example of 20MB, there are much easier and cheaper ways to DoS the network, as mentioned.
i know; your normal sized convoluted multi-input block that would have to, btw, be constructed as a non-standard tx block that is self mined by a miner which makes it unlikely b/c you'd have to believe a miner would be willing to risk his reputation and financial viability by attacking the network in such a way which has repercussions. that's also good news in that it removes a regular spammer or gvt attacker (non-miner) from doing this. and finally, that type of normal sized but convoluted validation block will propagate VERY slowly which risks orphaning which makes that attack also unlikely. |
|
|
|
i think this proves that miners are perfectly capable of handling bigger blocks as evidenced by the "no delays" in confirmation intervals. if anything i find it interesting that they get sped up to <10 min during these attacks. with bigger blocks, we'd clear out that mempool in an instant: Well, no. Bigger blocks just make the "attacks" marginally more expensive. Individually, I could also swamp the mempool at any of the proposed sizes. The "attacks" are providing some funding, so I don't really mind them all that much. This tragedy of the commons is not quite so tragic as the UTXO set growth and chain size would be with a similar attack on larger blocks, especially if combined with a validation time attack (TX with many inputs and outputs in a tangled array). Very large blocks would be a much more vulnerable environment in which to conduct such an attack. We'll get to the point of ameliorating these vulnerabilities, and the right people are working on it. Patience... Bitcoin is still in beta, its so young. Lets give it the chance to grow up without breaking it along the way. so looking at the peak of the last attack ~40BTC per day worth of tx fees were harvested. let's say we go to 20MB blocks tomorrow. since real tx's only amount to ~500kB per block worth of data, you'd have to essentially fill the 20MB all by yourself and spend 20*40BTC=800BTC per day give or take. at $290/BTC that would equal $232000 per day. and then you'd have to sustain that to even dent the network; say for a month. that would cost you $7,000,000 for one month. you sure you can do that all by yourself? |
|
|
|
notice how the extra fees paid by full blocks actually strengthened the mining hashrate during the last attacks. probably the extra revenue from tx fees encouraged miners to bring on more hashrate. that's a good thing and could actually be even better if they were allowed to harvest/clear all the additional fees in the bloated mempools: |
|
|
|
|
Show Posts
