|
Please provide full information about your platform - driver, SDK, OS. Did you tried with different values for worksize, '-f'? With catalyst 10.11, SDK 2.2 on windows I actually see slight improvement with vectors against previous version.
|
|
|
|
|
There are many questions still unclear about bitcoin. We have yet to see a lightweight client, freed of the block chain's burden. We still have to see how the TX fee market will develop. There is uncertainty about what the average number of transactions per minute would be in, say, two years.
Distributed DNS using bitcoin concepts is really cool. But isn't this a separate currency/commodity? Why not create a separate chain for it? Why force bitcoin users to support services they aren't aware of?
What if I want only BitDNS? And I don't need the payments stuff?
|
|
|
|
|
I will change my miner to check lower targets. Keep in mind that GPUs are perhaps 30x+ faster than CPUs. Are you going to adjust the target to control the number of results you receive from specific client? Because with target suitable for getting 1 result per minute from CPU, you may receive 1 result per SECOND from a GPU.
|
|
|
|
|
Great danger? But wait, isn't bitcoin invincible?! (Well, perhaps if it adopts random ports, protocol obfuscation, DHT bootstrapping...)
|
|
|
|
|
Thanks Mike!
Could you please try to run it on a single device? Or use '-d 0' and '-d 1' in two separate processes. poclbm is not optimized to run on more than one device (needs to maintain different queues to avoid choking one or the other). Perhaps there's better way to do this, don't know.
Anyway, even if you manage to get more of them it won't be 27x.
|
|
|
|
|
Search for 'GPU caps viewer' or other tool to check if your setup is OpenCL enabled. With AMD you need Stream SDK installed except you are using catalyst 10.10+, 'Accelerated Parallel Processing (APP)' flavor.
LobsterMan, please mention in your article 'GPU caps viewer' or something similar as a way to confirm OpenCL is working.
|
|
|
|
Thanks David. I forgot to remove that one and now I am unable to remove your quote of it  btchris, please send me a personal message. Since your are using the 'compiled' version (and nobody reported such problem recently with it) I want to know what is your GPU and how do you start poclbm (what parameters you use). |
|
|
|
|
Updated the miner to work with official bitcoin SVN 189.
|
|
|
|
|
Thank you satoshi, it is a small fix, I hope it will be ready tomorrow.
|
|
|
|
|
No need to do this, I'll change the miner to comply. I am just a little busy right now.
|
|
|
|
|
Initially it downloads 'blocks' from other peers. It does this in bundles of 500, but this still involves some disk activity. This will stop when you have all blocks.
At the moment the block chain will take about 100 MB of disk space. This is the public shared history of all transactions ever happened. It will grow with time. There are plans for some optimizations like removing spent transactions from disk.
About the CPU - bitcoin is trying to solve current block, containing all recent transactions. This could take a significant amount of time. Please search and read more past forum threads - all this is explained many times.
|
|
|
|
|
caveden, please reconsider. Regardless of what the generator is requiring for confirming the (spam) transaction, all other participants will pay with their disk space. This is a collective cost that any single participant can easily (and free) induce at the moment.
|
|
|
|
|
There is only one condition at the moment for a spammer to be able to flood the network - available balance. He could easily generate new addresses and make as many transactions to himself as he wish, not loosing balance in the process.
For me there is only one obvious solution to this... to introduce 0.01 (or other amount, could be discussed) mandatory transaction fee. This will effectively reduce spammer's balance with time, making him unable to spam further.
This is exactly the same phenomenon that allows other kinds of spam - lack of 'price' for some action. Even a small such price solves the problem.
Someone would grieve about 'free' bitcoin transactions. I would argue that small mandatory transaction fee would be far cheaper than the millions of spam transactions we are facing to deal with in the future.
|
|
|
|
I am really worried about this. It's highly possible that the problem is in my getwork patch, now used by many. I would really appreciate someone taking a look at the patch, specifically the CheckWork() and PrepareWork() functions in main.cpp Yes, it is reusing a key from the pool, but if block is found the key is never used again. Both functions should be thread safe. Theymos, are there other such generations? |
|
|
|
|
Just updated to SVN 181 and fixed getwork patch to wait 60 seconds between rebuilding the block with new transactions. This is actually the behavior of the original client, was forgotten in the patch by mistake. Fixes heavy CPU usage on every getwork request (this became obvious with recent heavy transaction spam). Please upgrade.
|
|
|
|
|
See first post for updated (SVN 179, 0.3.15) win32 getwork patched client
|
|
|
|
|
Difficulty adjustment will take place in less than 300 blocks.
|
|
|
|
|
Show Posts
