pulled into upstream
Eh no, not yet... Sorry, cross-thread stupidity on my part. Wallet encryption was pulled, not import/export -- though we do want to merge import/export soon! |
|
|
|
|
Thanks for taking over "the C miner" project!
|
|
|
|
...and how does the client inform the server that it supports this feature?
There is version in user-agent, server can determine miner and act accordingly. Sorry, this is not scalable approach. Please re-think. If all miners implement this, then each pool server must implement version checking code for every supported miner. Each pool server must update their source code for each updated or new miner. In contrast, if a miner client provides "X-Feature-Supported" in HTTP headers, then there is a simple check in the server that never needs to be updated. User-Agent is the wrong approach. |
|
|
|
Now, open up msg.c and head down to the check_hash function, specifically the return of better_hash. It looks like it is checking a hard coded 40 bits of 0's. Won't I need to change this spot too? What should I change this to based on the 10, 50, 100 scenarios?
Correct. In addition to changing EASY_TARGET, you must update check_hash. IMHO the bounty should go to the person submitting a patch that makes difficulty variable, without recompiling the source code! |
|
|
|
Read the whole paper.
You cannot "steal" existing coins without the proper keys.
With sufficient CPU power you can double-spend, and mine a lot of new coins for yourself.
With sufficient CPU power I hash my forged block that transfers all the coins to my account. Then with sufficient CPU power I confirm it six times in a row. Your version of history where I don't have all the coins is now an unofficial fork of the blockchain that the clients delete. To repeat, for the cheap seats: you cannot steal existing coins without the proper keys. |
|
|
|
|
Read the whole paper.
You cannot "steal" existing coins without the proper keys.
With sufficient CPU power you can double-spend, and mine a lot of new coins for yourself.
|
|
|
|
I made a ~6 BTC deposit and was prompted a 'minimum' fee of .03 ...
in fact a minimum fee of 0.03 means your transaction was *massive*. It sounds like 'the joint' is not running 0.3.24 either, and so, is using an older fee schedule with much higher fees. |
|
|
|
Bump. All users are encouraged to upgrade to 0.3.24, to avoid block chain download issues currently seen in the field.
just to be clear, if i don't have issues myself, do i help others by upgrading? Yes, most definitely. Nodes requesting block chain downloads can have their downloads cut off abruptly, on older versions of bitcoin. The more people running 0.3.24, the less this awful behavior will be seen. |
|
|
|
|
Bump. All users are encouraged to upgrade to 0.3.24, to avoid block chain download issues currently seen in the field.
|
|
|
|
Is there some gpg signature to verify the integrity of the files?
Yes. See the original post in this thread. |
|
|
|
Is this the "auth.cred_cache.expire" : 75, option?
No. And if not how do I get pushpool do keep it longer, or is the problem
somewhere else on the host?
The problem is with miners submitting old work. They should not submit work older than 60 seconds, much less 120 seconds. |
|
|
|
i've played a bit aroung with pushpoold and everything worked just fine.
But when I asked a friend for a little test something strange happened.
I have about 100MH/s my friend has 1500MH/s.
As soon as my friend joined for testing i got a lot of stales,
I looked it up in the datase and the reason is "unknown-work".
pushpool keeps a log of the last 120 seconds' worth of work received from bitcoind. unknown-work error occurs when a miner submits work that is not in that log. |
|
|
|
- most of JSON-RPC fields made optional (to reduce pools bandwidth)
...and how does the client inform the server that it supports this feature? From the server's perspective, it must support may different clients, and cannot know if 'target' or 'midstate' is optional without additional information. |
|
|
|
|
Just to be clear...
The upgrade / wallet update procedures are the same as with the last several bitcoin versions. There is nothing special about updating to this release, versus past releases.
The advice posted in this thread is standard, general advice that you should always follow when updating: back up your wallet (you are doing this anyway, right?)
|
|
|
|
Can someone complete the following line? I don't get it. Gavin Andresen (3):
Boost unit-testing framework. make -f makefile.{unix,osx,mingw} test_b
Block-chain lock-in at 134444
Do not use comma as thousands separator Using the comma as thousands s
That is referring to this git commit: Do not use comma as thousands separator
Using the comma as thousands separator causes problems for parts of the world
where comma == decimal point. Germans sending 0,001 bitcoins are unpleasantly
surprised when that results in 1 BTC getting sent.
|
|
|
|
Can we get an official Mac OS X binary up on the sourceforge and Bitcoin.org?
It is coming soon. OSX builds are always delayed a day or so, because they are not integrated into our gitian build process like linux/windows. |
|
|
|
I would consider this a bug. pushpoold should already know the target difficulty, so why can't it do a correct check? Also, doing a proper check would reduce the network activity between pushpoold and bitcoind slightly (it would submit less false Proof of Works to bitcoind).
Patches welcome... |
|
|
|
These installs seem to be getting more complex. I'll stick with 0.3.21.  To what does this refer? The installation procedure is unchanged since 0.3.21 (or before). |
|
|
|
|
Show Posts
