Search content
Sort by
Showing 20 of 144 results by twobitcoins
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.
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.
sturle, thank you for your efforts to provide factual and level-headed information. Regarding 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?
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?
The image URL is on ebayimg.com. I found the listing here:
http://www.ebay.com/itm/IN-HAND-Butterfly-Labs-Bitforce-Single-60-GH-s-ASIC-Bitcoin-Miner-Ready-to-ship-/251318328943?pt=LH_DefaultDomain_0&hash=item3a83bd5e6f
http://www.ebay.com/itm/IN-HAND-Butterfly-Labs-Bitforce-Single-60-GH-s-ASIC-Bitcoin-Miner-Ready-to-ship-/251318328943?pt=LH_DefaultDomain_0&hash=item3a83bd5e6f
Algorithmic optimizations for sale to ASIC vendors (15+% improvement)
Summary
I 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.
Details
These 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:
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.
I 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.
Details
These 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.)
(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.
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.
Re: BFGMiner 3.1.2: modular ASIC/FPGA, GBT, Strtm, RPC, Lnx/OpnWrt/PPA/W64, BFLSC
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.
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.
Re: 40 BTC+ Challenge for GPU Optimized Hashing Algorithm
Here is the description I was in the process of writing up while awaiting your reply:
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]
Quote
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.
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]
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.
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.
Re: error: txNew does name not a type (.1 BTC reward for solution)
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):
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!
Code:
{
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();
}
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!
Re: error: txNew does name not a type (.1 BTC reward for solution)
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:
Code:
CCoinsViewCache view(*pcoinsTip, true);
view.SetCoins(txNew.GetHash(), CCoins(txNew, 0));
view.Flush();
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:
Code:
// 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;
}
// (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.
Re: error: txNew does name not a type (.1 BTC reward for solution)
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:
Or if you have a non-static member function in CTxMemPool, you can call it like this:
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]
If you don't want to add a member function to CTxMemPool, you can do something like this directly in AppInit2:
Code:
{
LOCK(mempool.cs);
mempool.addUnchecked(hash, txNew);
}
LOCK(mempool.cs);
mempool.addUnchecked(hash, txNew);
}
Or if you have a non-static member function in CTxMemPool, you can call it like this:
Code:
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]
Re: error: txNew does name not a type (.1 BTC reward for solution)
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).
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).