You should probably consider setting up some sort of arrangement in case you die, perhaps setting up some sort of geekier version of the Nobel prize?
Well, I do actually, but it would end up going to family members. I don't know if I would have enough to setup something as large as the Nobel prize unless it really did turn into a billions of value. |
|
|
|
Oh, I'm still alive and kicking.  Yeah, still have them, though like was said, it would not be possible to sell them all at once and become an instant millionaire. No one is going to buy that many at once. I have kept my client running 24/7 since then though, managed to generate a bit more before the collective mining groups took over  Without the massive server farm I had going before, I'm just down to my personal desktop, so it's never gotten over the 371k since. I do keep many, many backups though just in case  from someone who has alot of btc to lose from a hacker; do u keep a separate client and wallet online with minimal to no btc in it? if so, how do i split off a separate wallet as well? Yes, the wallet file sits a (2) CD-R and (1) flash drive (was just curious how long that flash drive would stay good) in a safe deposit box at the local bank. The wallet file on my PC is not the same one that has all the BTC in it for security reasons. While it is fun to fantasize about being rich, I know realistically, the BTC would work better as a monthly paycheck than a lotto ticket. |
|
|
|
Oh, I'm still alive and kicking. Yeah, still have them, though like was said, it would not be possible to sell them all at once and become an instant millionaire. No one is going to buy that many at once. I have kept my client running 24/7 since then though, managed to generate a bit more before the collective mining groups took over Without the massive server farm I had going before, I'm just down to my personal desktop, so it's never gotten over the 371k since. I do keep many, many backups though just in case |
|
|
|
The bad chain is also slowed down as more nodes upgrade.
We've already generated 14 blocks since 74638. The builds of 0.3.10 were uploaded about 2 and 3 hours ago. Of the nodes I'm connected to, more than half are already 0.3.10. I would say we probably already have more power than the bad chain.
I think it'd probably be a good idea still to come out with another version that rejects connections from older versions - otherwise the network might remain rather fragmented for a while. :/ We want to keep the older clients connected so that when the correct chain overtakes the incorrect chain, they will switch back to the correct chain. Although I don't know the specifics of how far back in the chain the old chain will accept a branched chain. The old clients should accept it all the way back to the last snapshot of release, so this being found so quickly and so long after the last release, it should work in theory. Here's a good test of the theory |
|
|
|
I'm chucking as much CPU at this as I can. Yeah, bit of an unfair advantage I guess until everyone upgrades.  My wife's PC already generated 2 of the new blocks (LOL), luck is on her side I guess. |
|
|
|
Here's what I have: All of these have the updated blocks, all of them had the block chain wiped, reloaded old one, updated all versions to 0.3.10; I hope that is the right number so far? IP Address: 12.53.130.10 - (Linux CentOS 5.5) 99.59.167.147 - (Linux Mandriva 2010.0) 64.186.154.76 - (Windows Server 2003 x64 Enterprise) 64.186.155.104 - (Windows Server 2008 x64 Call Center Edition) As you can see, I like variety in OS I guess. I've opened them all up to as many connections as they can take (with the undocumented connection option now), so I can kill two birds with one stone. Help restore the network and test part of the netcode |
|
|
|
|
I'm working on upgrading my CentOS machines (have to custom compile for it), once I get them updated, they should be able to connect to as many clients as they want/can then.
|
|
|
|
[edit] Just saw your post, I'll build one to less than 74,000 then, should at least save you technical people a few minutes of downloading the new chain. Just leave the old one alone! Older is better. What block number is it? Anywhere from 60000-74000 is good. The one that you've had available for a while has been vetted and is the best choice. I've put the block number with the file, so you'll know exactly where each stops at. BitCoinBlocks_Linux_67309.zip BitCoinBlocks_Windows_67300.zip I've leave them be. Glad to know I could help  |
|
|
|
Cool, works for me! |
|
|
|
Yeah, a little confusing  So I don't need to create one, or do I need to take what you guys already have and just throw it up on the FTP? Can you dump block data from a windows machine onto a Linux/Mac machine? [edit] Just saw your post, I'll build one to less than 74,000 then, should at least save you technical people a few minutes of downloading the new chain. |
|
|
|
74637 is the last good block
Ok, good, I've relabeled the old block chain on my site, I'll try to get as close to that number as I can. Basically, I'm just loading up two clients, one with the old chain, another with the sorta bad chain at the end. I'm going to let the first client get as close to the number as I can before stopping it. Then snapshot off that block chain. Since it does about 500 at a time, I'll probably be able to get it close to 74,501 |
|
|
|
|
I can build a block chain to the desired number using a combo of the old block chain and a client with the latest block chain (minus the bad stuff), what number should I shot for?
|
|
|
|
knightmb, do you still have any of your monster network available to turn on to help build the new valid chain?
Not anymore, was shutdown on the last day of the month for July, all I have left are about a 2 dozen servers, but near nothing of what I had before. |
|
|
|
Oh, yeah, just noticed this topic. I can't remember when those block chains were snapshot, but I'll update it to be more descriptive (like block 64,000, etc.) Good thing I keep those around. My web server sits on a fiber, so it won't be a big deal everyone starts to download those files at once (at least for the more technical people). [edit] Shutting down all the remaining servers and super-nodes I left running. Hope that helps. |
|
|
|
It's in my original post: A simple(?) modification of the algorithm would be to apply the adjustment after a certain amount of time rather than at a certain block number. The switch could still be synced to take effect for the next block, so time synchronization between clients would not need to be super exact to have the vast majority of them agree on when the new difficulty is to be applied.
Also, the difficulty adjustment should probably take into account the adjustments of the number of bitcoins minted per event (now 50, halved every 4 years). Halving the number of bitcoins generated each time is equivalent to doubling the difficulty as far as profitability is concerned, and such a drastical drop in profitability is unnecessary if it can be avoided easily. I'm not sure if the current adjustment algorithm already takes that into account somehow, but I couldn't see any obvious adjustment for it in the source code.
How will you account for latency and time hacking then? |
|
|
|
What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.
Sure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs. I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm. I'll bite. How would you fix the algorithm? |
|
|
|
A good analogy to this is mp3 audio vs ogg audio. Ogg is newer and superior to mp3, and yet mp3 is literally *everywhere*, whereas almost no-one uses ogg. Why? Because one of the *properties* of mp3 is its universal usage. Ogg may eventually overtake mp3, but it would take a long time, and certainly not be a cut and dry instant process.
Thoughts?
Ogg is used everywhere; games, audio players, movies, etc. Maybe not the best example. |
|
|
|
What happens when we desire to return additional information, beyond tx-id?
For the sake of future compatibility, it seems like the flag should present a choice between returning (a) just the current 'sent', or (b) a JSON map containing tx-id, and perhaps other things.
A 'gettransaction tx_id' API call is on my short list. What do other folks think; should sendtoaddress .... true return just the tx_id, and you have to make another API call to get details if you need them? Or should it return an Array? Depends on how fancy you want to be. If you go beyond a boolean, you could just append flags for any reason or function needed. This would leave it open to more functions rather than stacking a ton of booleans on the function as it's usefulness grows. sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to] -tx_id : returns the tx ID of the receiving bitcoin address -dance : returns dance high scores -moon : return current moon phase So one would simply put in sendtoaddress -tx-_id <bitcoinaddress> <amount> [comment] [comment-to] instead of sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to] true false true true false if a lot of functions were added to it later. |
|
|
|
Just add a flag (like true/false) to the function with the default "false" so it works with older uses of the function call. Like sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to] [return transaction ID, default false] So sendtoaddress 1FtDzyajiHKa9QbXiNxqztB 1.00 "Blah Comment" "Blah From" true returns sent XYZ.... But sendtoaddress 1FtDzyajiHKa9QbXiNxqztB 1.00 "Blah Comment" "Blah From" returns sent Also without having to break compatibility. I think it would be a handy addition. |
|
|
|
|
Show Posts
