Quoting what I said above: "Upgrade" includes upgrading their bitcoind/bitcoin-qt etc to 0.8+ OR setting the DB_CONFIG entries mentioned above. AND not OR. There is no point in setting anything in 0.7-; 0.7 can NOT make a block that 0.8 rejects. 0.7 AND 0.8 can both make blocks that 0.7 will reject due to a bug in 0.7-. 0.8 can be configured to only make blocks that are accepted by everyone. When everyone was on 0.7, if it made a block that it itself rejected than nothing bad happened. with 0.8 you had the fork risk suddenly come up. If you are going to be messing with your install then you should do so by switching to 0.8 with the right config not by trying to mess with the bugged 0.7 Releasing a 0.8.1 won't fix anything. All that it can do is clamp the value that you can set the max generated block size to. The problem is the code is still there, and so is 0.8. If somebody wants to compile a custom 0.8.1 from source with the limit at 1MB, they can. Default configuration is included in the source code and as such anyone who compiles an 0.8.1 without explicitly altering said code would get the new configuration. If a person (or a pool) wanted to cause trouble, they could simply change the code in their 0.8.1 checkout and compile, or use 0.8. Of course they need to be able to solo-mine their own blocks. Generating a block that's complex enough to overflow the lock tables of old 0.7 bdb based systems is still valid. If more than 51% of the hash power applies the DB_CONFIG fixes (even on 0.7) then they'll accept it and build on it. This wont cause trouble to anyone except for themselves, they will be generating blocks that are rejected by the chain until and unless 51+% are using 0.8+, at which point those using obsolete bugged version are forced to upgrade. What actually needs to happen is a new fixed 0.6.x, 0.7.x need to come out There is already a fixed 0.7, its called 0.8. |
|
|
|
The bug is that in all versions of bitcoin prior to 0.8 the maximum number of transactions that can fit in a block is not universally definable, because the limit varies based on the exact hardware and software configuration a particular node happens to be running.
It's possible for 0.7 nodes to produce valid blocks that other 0.7 nodes can't process.
And yet the current solution is "everyone use 0.7 not 0.8". BTC and all other mining guilds switched back to 0.7 to prevent a hard fork. How can you migrate off of the buggy version when attempting to migrate off of it causes a fork? No, not true. What we need is: 1) end users to get off 0.7/below and need to upgrade. 2) merchants to get off 0.7/below and need to upgrade. 3) when people run a miner program as part of a 3rd party pool, still need to upgrade. Their pool runs 0.7, not the person running the miner. 4) a couple of large pools stay on 0.7 to buy time for #1/#2/#3 to happen. "Upgrade" includes upgrading their bitcoind/bitcoin-qt etc to 0.8+ OR setting the DB_CONFIG entries mentioned above. The DB_CONFIG changes will fix the problems *that we know about* in 0.7 and earlier. Naturally there's still potentially more problems in 0.7 lurking. However, those pools running this 0.7 bitcoind cannot "fix" the DB_CONFIG settings - if they did they might as well just run 0.8. Once the vast majority of nodes are "fixed" (there's only 10,000 of them), then the big pools can go back to 0.8. (nodes: http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html) The reason 0.8 can't be taught to reject valid blocks that will break 0.7 and earlier is that there's no exact number. It's an internal artifact that depends on the run-time state of an individual node. For example, it has been observed by some folks that simply stopping/starting bitcoind 0.7 will cause it to validate and accept the block their copy had previously crashed on. The "pools on 0.7" thing is just a tactic to by time for people to upgrade. It is not a solution, and it won't last. Prediction: the moment sufficient hashpower switches over, somebody will generate another BDB-buster. It probably won't be a big pool, but somebody who wants the transaction fees will do it. 0.8 doesn't need to be taught to reject anything, the problem is 0.7 and earlier reject valid blocks due to a bug in 0.7 and earlier. 0.7 can actually CREATE blocks that it will itself reject due to that bug. Demanding EVERYONE switch to 0.8 is not realistic either. What needs to happen is that 0.8.1 should be released where its the same as 0.8 only it changes the default CONFIGURATION such that it will NOT create 0.7- incompatible blocks. When over 90% of the network are using 0.8+ this limitation can be safely removed and people using 0.7 or earlier will be forced to upgrade. Until such a hypothetical 0.8.1 is released you can MANUALLY apply the needed configuration files using the instructions in: https://bitcointalk.org/index.php?topic=152030.msg1620853#msg1620853 |
|
|
|
So, a regular user who isn't mining should simply have waited a couple of hours and the issue of the fork would be resolved by the network... fine, great...
But what about miners? How is this going to be resolved for miners going forward?
Reddit said that BTCGuild and their ilk have changed back to 0.7, that's great for them but what about people using p2pool? p2pool interfaces with your BC client and as such it would mean everyone with p2pool has to downgrade to 0.7...
Are there plans for a 0.8.1 which resolves this or what?
Anyone knows the answer? Edit your bitcoin.conf: #Maximum size, in bytes, of blocks you create, large blocks can be rejected by the standard bitcoin node 0.7 and maybe earlier:
# 250000 is standard and safe for the network, 100000 lowers the latency of getblocktemplate calls which is good for p2pool's efficiency
blockmaxsize=100000
#How many bytes of the block should be dedicated to high-priority transactions,
#included regardless of the fees they pay
blockprioritysize=20000
#Minimum block size you want to create; block will be filled with free transactions
#until there are no more or the block reaches this size:
blockminsize=10000
#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.0005
Edit: oh, and restart your bitcoind process to apply changes. Thank you very much. This should be stickied |
|
|
|
The bug is that in all versions of bitcoin prior to 0.8 the maximum number of transactions that can fit in a block is not universally definable, because the limit varies based on the exact hardware and software configuration a particular node happens to be running.
It's possible for 0.7 nodes to produce valid blocks that other 0.7 nodes can't process.
And yet the current solution is "everyone use 0.7 not 0.8". BTC and all other mining guilds switched back to 0.7 to prevent a hard fork. How can you migrate off of the buggy version when attempting to migrate off of it causes a fork? The most obvious solution is if 0.8+ could be configured to make blocks that are going to be accepted as valid by both 0.7- and 0.8+. Also that is the safest way to mine. Hence my question, how do I configure my 0.8 to only make blocks that are readable by 0.7-? i think i read that the simple solution was to keep them below 500KB. Is there a command line argument I can use to do that? |
|
|
|
The bug is that in all versions of bitcoin prior to 0.8 the maximum number of transactions that can fit in a block is not universally definable, because the limit varies based on the exact hardware and software configuration a particular node happens to be running.
It's possible for 0.7 nodes to produce valid blocks that other 0.7 nodes can't process.
And yet the current solution is "everyone use 0.7 not 0.8". BTC and all other mining guilds switched back to 0.7 to prevent a hard fork. How can you migrate off of the buggy version when attempting to migrate off of it causes a fork? The most obvious solution is if 0.8+ could be configured to make blocks that are going to be accepted as valid by both 0.7- and 0.8+. Also that is the safest way to mine. Hence my question, how do I configure my 0.8 to only make blocks that are readable by 0.7-? |
|
|
|
Miners can still use 0.8 as long as they don't create problematic blocks. People running p2pool can stay on 0.8 as long as the don't increase the soft block size limit too high.
Is there a way to configure 0.8 to not increase the block size over the limit? Because the bug (can't handle blocks over a certain size limit) isn't in 0.8 its in 0.7, and the bug cannot be resolved unless the entire network abandons 0.7 and earlier. The solving of the fork by going back to the bugged version is a serious problem. |
|
|
|
So, a regular user who isn't mining should simply have waited a couple of hours and the issue of the fork would be resolved by the network... fine, great...
But what about miners? How is this going to be resolved for miners going forward?
Reddit said that BTCGuild and their ilk have changed back to 0.7, that's great for them but what about people using p2pool? p2pool interfaces with your BC client and as such it would mean everyone with p2pool has to downgrade to 0.7...
Are there plans for a 0.8.1 which resolves this or what?
Anyone knows the answer? |
|
|
|
|
So, a regular user who isn't mining should simply have waited a couple of hours and the issue of the fork would be resolved by the network... fine, great...
But what about miners? How is this going to be resolved for miners going forward?
Reddit said that BTCGuild and their ilk have changed back to 0.7, that's great for them but what about people using p2pool? p2pool interfaces with your BC client and as such it would mean everyone with p2pool has to downgrade to 0.7...
Are there plans for a 0.8.1 which resolves this or what?
|
|
|
|
As far as I understand it bitcoin transactions are public transactions between anonymous parties. If someone captures your wallet then they could look at every transaction you made.
However, is there a reason why you couldn't prevent that and maintain your privacy by destroying an older wallet?
Every transaction still stays in the block chain. So it is traceable. You don't have to own someones wallet to see their transactions. Yes but how would you know who they are? Each transaction is done by a long string of random numbers not a name and address. To tie a name to an account you need to actually capture someone's wallet. Although you could also make assumptions by, for example, noticing that pierre36's credit card was used to buy bitcoins from mtgox for a specific bitcoin account. you could also see a string of money transferring from one wallet to the next but you can't know who owns the wallet in each step. It can be one guy shuffling his money or multiple people trading. And heck, you could buy coins for account A with a credit card, then transfer some of them to account B you own, then pay some of them to party C with account B. Then destroy both account A and B. Despite being public it becomes very anonymous very fast |
|
|
|
|
As far as I understand it bitcoin transactions are public transactions between anonymous parties. If someone captures your wallet and identifies you then you are no longer anonymous and then they could look at every transaction you made (public records).
However, is there a reason why you couldn't prevent that and maintain your privacy by destroying an older wallet?
|
|
|
|
Stopping peer to peer is a very difficult task. You'll either need to stop all the peers or their underlying network.
I suppose stopping the internet or making computers illegal would be extremely unpopular for any kind of government/authority!
http://en.wikipedia.org/wiki/Deep_packet_inspectionActually they wouldn't even need that, they just need basic filtering to detect the existence of bitcoin activity and then police raids your house. |
|
|
|
Pool is dying now.. Lost 1/4 of the hashrate. Perhaps it'll come back if there's a good day. Although that would take a 4-7 block streak to bring luck just up to 100%PPS levels for 90 days.
I think it's strange that bad luck streaks at non-PPS pools freak miners out less than bad luck at p2Pool - a pool where a pool op cannot maliciously cause bad luck (lookin' at you, Bitclockers 2011 - early 2012). I was under the understanding that hashrate has nothing to do with luck. Successfully finding coins fluctuates and could be said to vary based on luck but hashrate is constant for a given hardware barring bugs. He is saying that because of the luck, miners are leaving the pool, not that the luck is lowering the hash rate. I think its also likely that GPU miners are going offline in general and ASIC miners are not pointing at p2pool because of the initial reports of problems with stratum. Thanks, I misunderstood. I mixed up this thread and another I have open about a recently reported bug with tanking hashrates that happens on certain miner configurations (for all pools) |
|
|
|
Pool is dying now.. Lost 1/4 of the hashrate. Perhaps it'll come back if there's a good day. Although that would take a 4-7 block streak to bring luck just up to 100%PPS levels for 90 days.
I think it's strange that bad luck streaks at non-PPS pools freak miners out less than bad luck at p2Pool - a pool where a pool op cannot maliciously cause bad luck (lookin' at you, Bitclockers 2011 - early 2012). I was under the understanding that hashrate has nothing to do with luck. Successfully finding coins fluctuates and could be said to vary based on luck but hashrate is constant for a given hardware barring bugs. |
|
|
|
How do I make p2pool work for both bitcoin and litecoin simultanously?
change a port in the conf. both try to use 9332. thanks |
|
|
|
if bit coins steps out of anomise stauts.... and is more accepted for everday tranasactions... then this could get really big.
as of now.. much of bit coins use is for gray areas of the law..... if those gray areas get sorted out.. bit coins may not be needed.... unless they can find there way into a larger amount of merchaints,,, and find a way to make it more easy to get them
it hurts my head just thinking about the invonveinces of aqquiring bit coins
There is nothing "gray" about drug cartels. Its flat out illegal. And newsflash, the vast majority of criminal activity occurs with traditional currencies rather then bitcoin You can't just "sort out" the fact drug cartels now use bitcoin alongside traditional currencies |
|
|
|
|
Thank you, this does allow more control but I was hoping for a way to cap it by % usage or even better, temperature.
Also the minimum I can set it (via the AMD catalyst control panel) is not low enough when running full blast. Default is 800MHz and I can only reduce it to 500.
|
|
|
|
|
I had heard someone else suggest before that a single hostile government or large organization could initiate a 51% attack on bitcoin to corrupt the network.
Especially if they develop their own ASIC hardware
... has anyone estimated the hash rate of the world's top supercomputers?
|
|
|
|
If there's no worm / incentive for the early bird, then things never happen.
I think it's as fair as it could be that people get compensated for inventing things that deliver UNIMAGINABLE VALUE.
Also, there's no such thing as "fairness."
There certainly is fairness. Its just that fairness doesn't mean everyone enjoys the fruits of other's labors. Bitcoin is fair. This is why people use it and this is why people want to make it unfair via redistribution |
|
|
|
Adding a "Data directory" field in the options I guess.
That way only maybe a "datadir.conf" file would be at the default location pointing to the actual location.
That is a great idea! better then mine |
|
|
|
He doesn't have any, which is why he's advocating for change!
Then he can send me his dollars. Anyone who is advocating equality, please put your money where your mouth is and redistribute your own funds. |
|
|
|
|
Show Posts
