|
The large number of bitcoin days destroyed on 2013-12-21 can be seen mostly in block 276158, and on 2014-02-05 can be seen mostly in block 284349. In both cases, the coins were last moved around 2011-03-01, and the coins seem to be controlled by the same entity.
For example, if you start with the 45592.95 BTC in address 1Kq6sr5A9bM82u1vRTByjCvvixm5dxwQuV, you can see that they are split into outputs of less than 5000 BTC on 2011-03-01. Some of those outputs are redeemed on 2013-12-21 and others are redeemed on 2014-02-05. The same is true of the 150000 BTC in address 1LYJHSep7gAtvePMPVdsXvnKeNM7ifHkEK.
As far as I can tell, the coins were just moved to a different storage location, and there is no connection to recent market activity or the issues with Mt. Gox.
|
|
|
|
|
I haven't seen any published withdrawal limits, but it seems their site limits individual withdrawal requests to 999999.99 USD.
|
|
|
|
sturle, thank you for your efforts to provide factual and level-headed information. Regarding this: Regarding other fiat withdrawal option, I expect most of their problems will be resolved within a month, and the fastest fiat withdrawal option (except domestic JPY and manual express international wire) to take less than a week before Christmas. I'm willing to bet 1 BTC on this.
I haven't seen any evidence that the international wire transfer situation is improving. What do you base your optimism on? Do you have information that isn't publicly known? |
|
|
|
SummaryI have developed algorithmic optimizations for Bitcoin mining which reduce the number of calculations needed per hash, resulting in a performance improvement of 15% or more compared with the best publicly known techniques. I am offering to sell information about these optimizations to ASIC vendors interested in incorporating them into a future chip design. DetailsThese techniques are not theoretical. I have successfully implemented them in my private GPU miner and used them for several years. For reference, here are some performance numbers from my GPU miner: - 5970 @ 725 MHz: 828.4 Mh/s
- 6990 @ 880 MHz: 965.8 Mh/s
- 7970 @ 925 MHz: 676.5 Mh/s
If you compare those numbers with other published hash rates, making sure to adjust for clock speed, you'll find that they are 15-20% faster than the best hash rates achieved by other miners. I estimate that at least a 15% improvement comes from algorithmic optimizations which are not publicly known, and which should be applicable to other technologies like custom ASICs. The precise performance improvement achievable may be slightly different on a custom ASIC compared with an AMD GPU due to differences in the relative costs of various operations on the two technologies, but I expect it to be in the same ballpark. I should say up front that these techniques are not without drawbacks. They are somewhat more complex than the typical well-known mining optimizations, making them more difficult to put into practice. In particular, changes may be needed to infrastructure like mining software, pools, and protocols. It is not a drop-in replacement. Still, it may be worth doing if it results in a 15+% higher hash rate for given hardware and electricity costs. Also, please don't expect this information to come cheaply. The ability to increase the performance of a generation of ASIC-based products by 15+% is quite valuable, and I will expect to be well compensated for disclosing these techniques. If you would like to discuss using these optimizations in your ASIC design, email miningalgorithm at gmail.com.
|
|
|
|
By the way, the .atsuo file does not belong in the repository. It stores per-user settings like the set of open windows. (See suo file source control.) |
|
|
|
Nasser informed me he plans to check this code into git this weekend.
Excellent. Thanks! |
|
|
|
|
Apparently BFL is now shipping devices with firmware version 1.2.6.
Luke, do you think you could check with BFL about releasing the latest source code? I suspect you have better contacts than the typical customer.
|
|
|
|
I have also have 100% CPU usage problem with 3.1.2.
After doing some "git bisect", the problem seems caused by this commit: 9484dc1a468a1e5323abc0ea0666c353ba7678d6
The previous commit 75b58b16a546deb4bb7ca25ca7520ec8788ddf2a and before is fine,
after that all builds start with immediate 100% CPU usage.
And if the first pool is not stratum, 3.1.2 will hangs on start. I see this hang. It occurs in bytes_cpy. A size of 0 results in an infinite loop. |
|
|
|
Here is the description I was in the process of writing up while awaiting your reply: The first part of your algorithm only looks back in the buffer by 32 or 256 bytes, so you only need a window of approximately 256 bytes to implement that part.
It seems you are counting on the second part of your algorithm which calls CityHashCrc128 on the entire 128MB buffer to require a full 128MB of memory. But CityHashCrc128 can be computed incrementally. Looking at the code for CityHashCrc128, it calls CityHashCrc256, which calls CityHashCrc256Long, which (aside from a bit of initialization code) reads and processes the input data completely sequentially. Therefore you can compute the first and second parts of your algorithm at the same time, and only a buffer of about 256 bytes is required. You'll have to execute the first part sequentially rather than in 8 parallel threads. It should achieve extremely good parallelization on GPUs. Perhaps the whole thing can even fit in the registers with no memory usage at all.
I'm not sure why you say it is "inherently single threaded and thus not faster on a GPU". I see no problem running as many computations in parallel as an AMD GPU has "stream processing units" -- e.g. 3200 on a 5970. The conditionals don't create much of a problem -- GPUs can implement conditionals by suppressing execution of instructions per stream processing unit, so the slowdown will be no worse than if you enter the conditional 100% of the time. It should still be way faster than a CPU. Here is an address you can send to: [removed] |
|
|
|
|
Will you give me the bounty if I explain why your algorithm doesn't require anywhere near the 128MB that you think it does?
|
|
|
|
|
I just completed a sale to CanaryInTheMine. Everything went smoothly.
When transferring the credits, BFL's web site asked me to "Confirm transfer of NaN credits". I took a risk and clicked OK anyway, and the transfer went through just fine.
|
|
|
|
|
Theoretical bug in libblkmaker:
parse_txn populates txn->hash but is missing a call to "my_flip(txn->hash, 32);".
|
|
|
|
|
The tag for 3.1.0 is missing on github. Thanks!
|
|
|
|
Oh... the code was quite different back then. I think the way to proceed in general is to extract the parts of ConnectBlock that are needed to add the transaction to the index. I think it will look something like this (without error checking): {
CTxDB txdb;
txdb.TxnBegin();
CBlockIndex* pindex = mapBlockIndex.find(hashGenesisBlock)->second;
unsigned int nTxPos = pindex->nBlockPos + ::GetSerializeSize(CBlock(), SER_DISK, CLIENT_VERSION) - 1 + GetSizeOfCompactSize(block.vtx.size());
CDiskTxPos posThisTx(pindex->nFile, pindex->nBlockPos, nTxPos);
txdb.UpdateTxIndex(txNew.GetHash(), CTxIndex(posThisTx, txNew.vout.size()));
txdb.TxnCommit();
}
You could try putting that in LoadBlockIndex inside "if (mapBlockIndex.empty())" right at the end. Again, I'm just copying bits of code from here and there, so no guarantees it will work. Thanks for the coins, though! |
|
|
|
Interesting behavior now... I can send the coins from the genesis block, but they never confirm.  Yes, I don't think adding to the memory pool is going to help with what you are trying to do. The memory pool is for transactions that are not yet in blocks. When a new transaction is created, it gets relayed to nodes across the network and stored in their memory pools. Mining nodes use the memory pool to find transactions to include in mined blocks. The genesis block transaction doesn't really belong there since it is already part of a block (and also since it is a coinbase transaction). You need to add the transaction to the set of unspent transaction outputs. I don't know exactly how to do it properly, but the critical piece of code seems to be the call to SetCoins in CTransaction::UpdateCoins(). You might be able to do it like this: CCoinsViewCache view(*pcoinsTip, true);
view.SetCoins(txNew.GetHash(), CCoins(txNew, 0));
view.Flush();
I'd recommend putting that code right where the genesis block is created: in main.cpp, in InitBlockIndex(), inside "if (!fReindex)", right at the end. I can't guarantee that it will work, but it might. Make sure you start with a fresh data directory. To make reindexing work, I think you'll also need to do the same thing in CBlock::ConnectBlock inside this special case for the genesis block: // Special case for the genesis block, skipping connection of its transactions
// (its coinbase is unspendable)
if (GetHash() == hashGenesisBlock) {
CCoinsViewCache viewTmp(view, true);
viewTmp.SetCoins(vtx[0].GetHash(), CCoins(vtx[0], 0));
viewTmp.Flush();
view.SetBestBlock(pindex);
pindexGenesisBlock = pindex;
return true;
}
Or maybe you can simply remove the special case and let the rest of the function run, but I don't know if any of the rest of the code in that function will create problems. |
|
|
|
I would not recommend skipping the lock. Locks prevent conflicts between multiple threads. That kind of thing would not be detected by the compiler, but can create very hard to debug problems. If you don't want to add a member function to CTxMemPool, you can do something like this directly in AppInit2: {
LOCK(mempool.cs);
mempool.addUnchecked(hash, txNew);
}
Or if you have a non-static member function in CTxMemPool, you can call it like this: mempool.addGenesis(hash, txNew);
As for whether adding the genesis block coinbase transaction to the memory pool is the right way to solve your problem, I am skeptical, but I'm not familiar enough with the "proper" way to do it to give better advice. Here is an address you can send coins to: [removed] |
|
|
|
|
You have to put that code inside a function. Executable statements can't be at file scope.
I'm not sure when you want the code to run, but for example if you are trying to run it on startup, you could place it at the end of AppInit2 in init.cpp (before the return statement).
|
|
|
|
|
rBXKmRXRkVsDte1FLBJEKBPStCW9jAnvWn
|
|
|
|
|
Should there be a git tag for the 3.0.0 release? I don't see one.
|
|
|
|
|
Show Posts
