Thanks for the info. That helps.

Oatmo

What does the US Government have to do with this. This is a Japanese company with proceedings in a Japanese bankruptcy court. It also seems that the U.S. government doesn't recognize bitcoin as worth anything at all, so it seems doubtful that they would even investigate. Am I missing something?

I haven't been on the forum in a while, and looked around. I apologize if this has already been answered, and if it has, please point me to the thread.

Can someone post a concise answer as to the exact problem with Mt. Gox and whether the others have the problem or not.

Please correct me. From what I can see:

1. The Bitcoin protocol has a transaction ID, which can be changed shortly after transaction initiation (but not after the transaction is confirmed?)
2. Mt. Gox used this transaction ID for their internal accounting, while others claim that they do not use it to identify transactions.
3. Mt. Gox customers would do a withdrawl, change the transaction ID, then complain to customer service that they didn't receive their coins. The Mt. Gox system was fooled because of using the transaction ID, and then customer service would send the coins again.

So:

1) This is known in the bitcoin software.
2) Proper accounting systems do not use the transaction ID to track payouts.

No known other exchanges have the problem (or if they do, they're not saying).

Please correct me and add any other pertinent information.

Thanks,

Oatmo

The bankruptsy is in Japan, so U.S. law has nothing to do with it.

Didn't see this mentioned anywhere here:

http://www.irs.gov/pub/irs-pdf/p2104.pdf

pp. 249-255.

Basically the taxpayer advocate is saying that the IRS needs to tell us how to handle bitcoin transactions on our taxes.

Wohoo, my client works.

Can someone post 2.2.3.0 to mega, it's only got 2.2.2.0..

Oatmo

I deleted the block database, and now I'm stuck in the same place..

{
"version" : 2020100,
"protocolversion" : 60002,
"walletversion" : 60000,
"balance" : 7657.69043275,
"blocks" : 25019,
"connections" : 2,
"proxy" : "",
"difficulty" : 0.15711984,
"testnet" : false,
"keypoololdest" : 1371618202,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"mininput" : 0.00010000,
"errors" : ""
}

I'm stuck on the same..

Sorry, was on the other thread. Just read up.

I'm in with stbgfltc. He's been doing the coding. Most of the rest of us have just been giving advice, so I'm happy to see the support. I don't think this is a big problem. I'm sorry that I'm not contributing more, but I have too many current projects.. hopefully in a month or two, I can support the coin more.

I'm stuck on block 30105 with the new client. Where are there directions on how to setup the config file with the addnode command so that I can hopefully get started again?

Posted in the other thread about the retarget algorithm. I'll repost that here is a few minutes.

Oatmo

I'm not quite sure I understand the problem, but let me suggest some stuff for the variation problem. I'm not a statistician, but it seems like 2 standard deviations from the mean is a good trigger. How about you take the last 30 samples, compute the mean and standard deviation. If the new sample is more than 2 standard deviations from the mean, then force a retarget. In a random process (as I remember it), >95% of samples should be within 2 standard deviations of the mean. That means that less than 5% of retargets would be from a random event, and 95% of the would be triggered by changes in hashing power.

I agree. Retarget on every block, but use the last 30 to figure out the new value. That adds enough ballast to keep the system running smoothly, and also let's the difficulty go up with every block that's too fast, and go down with every block which is too slow. In the end the protection against hash spikes will be enough hashing power all the time to keep it stable.

We have to be careful using single block times to do anything, because this is a random process. I like the 5 blocks in less than 2 minutes causing a retarget. How about the forced retarget is 2 hours, or less than 12 blocks in 1 hour, or alternatively forced at 2 hours, or less than 6 blocks in 30 minutes. Currently we are looking at the last 30 blocks for the retarget, I propose in the 5 blocks in 2 minutes, or <6 blocks in 30 minutes that we use the last 15 blocks to calculate the new difficulty. This will dampen the effect and reduce overshoots.

Just a note. It looks like the current 4 hour force retarget isn't working. Can we debug why we aren't getting a retarget after 4 hours. Let's get that fixed, and also add the quick retarget up based on 5 or 15 blocks, and target that for 3-4k blocks away.

Or if I am reading the block chain wrong, let me know.. We should have seen a retarget on 28988.

Oatmo

Block   Approx. Time   Transactions   Value Out   Difficulty   Outstanding   Average Age   Chain Age   % CoinDD
28994   2013-07-28 04:53:19   2   40   3.661   579860   22.8843   51.4496   21.7942%
28993   2013-07-28 04:26:37   2   40   3.661   579840   22.8666   51.431   21.808%
28992   2013-07-28 03:51:19   4   41.0932966   3.661   579820   22.8428   51.4065   21.8262%
28991   2013-07-28 01:09:40   2   40   3.661   579800   22.7314   51.2942   21.9104%
28990   2013-07-28 00:15:53   2   40   3.661   579780   22.6948   51.2569   21.9385%
28989   2013-07-27 23:13:50   2   40   3.661   579760   22.6525   51.2138   21.971%
28988   2013-07-27 22:04:37   3   1194.45011157   3.661   579740   22.6053   51.1657   22.0074%
28987   2013-07-27 19:57:34   2   40   3.661   579720   22.531   51.0775   22.029%
28986   2013-07-27 19:54:54   2   40   3.661   579700   22.5299   51.0757   22.0304%
28985   2013-07-27 18:54:23   2   40   3.661   579680   22.4887   51.0336   22.0625%
28984   2013-07-27 17:56:43   2   40   3.661   579660   22.4494   50.9936   22.0931%
28983   2013-07-27 17:51:17   2   123.00550875   3.661   579640   22.4464   50.9898   22.096%
28982   2013-07-27 17:36:49   4   160.32731993   3.661   579620   22.4378   50.9798   22.1016%
28981   2013-07-27 17:34:05   1   20   3.661   579600   22.4372   50.9779   22.1011%
28980   2013-07-27 17:33:25   1   20   3.661   579580   22.4375   50.9774   22.1015%

I'll second how much he has done. I reviewed the code, and gave him some comments, and he took them and did all of them. From what I could see, not only did we make a hugely beneficial change for the coin, but he also factored the code so that future changes to the algorithm are really easy to make, and really obvious to review and see whether they work. At this point, from what I can see, the coin seems to be working well. There's a few minor tweaks which can improve it, which is what were talking about now, no where near the serious situation we have before the algo update. This is a community coin, so everyone is welcome to suggest improvements, and the community will discuss and improve them.

I'm not quite sure what the problem is that started this thread. I downloaded the new client, and had no problems with it, and nothing looked wrong with the dates. By all means if there is an issue, everyone is willing to fix it. Maybe we are missing something. Please post the exact links to the files which have the problem so that we can get to the bottom of this.

Oatmo

Totally Agree... Figure out if there is anything else worth updating, then make it a long ways out. Nothing is killing us at this point, it's just an improvement.

Everything looks good since the algo update. One possible future update suggestion is that just like we have the 4 hour forced retarget for too slow, it's probably a good idea to have one for too fast as well... Something like if you get 15 blocks (30 minutes worth) in less than 7.5 minutes (running 4x too fast) then you force a retarget as well. This would more effectively handle cases where a ton of hash power gets added quickly without generating a ton of orphans.

Just a thought.

Oatmo

Looking great.. See that the block explorer has been updated. I assume coinchoose will be close behind. Seems to be running great. Thanks for the hard work making this happen for the community.

Oatmo

How did we finally end up calculating the difficulty change when we hit the 4 hour forced update? Is it since the last difficulty change, or is it over the last 30 blocks?

Oatmo

Wish I had time to finish mine now, but I've got a more pressing project to do first.