most important aspect is maximizing profit over say a 6 month period. during that period, i imagine variance would average out right?
Probably at 200 GH/s. Still safest to use Eligius  |
|
|
|
is there a difference besides the fees? at that rate would it be more profitable to mine alone?
i got a single opinion that it would make sense to go with p2pool over solo mining. just looking for a deeper pool of opinion. There are probably 2 main factors you're interested in: fees and variance. Variance is the "random" factor of how far your earnings may swing from one day/week/month to the next. It would definitely be better to go p2pool over solo mining. With 200 GH/s, you probably don't need to worry too much about variance. That being said, even with 350 GH/s, Eligius (my pool) still has pretty wide swings of variance, so it won't be variance-free either. If low variance is important to you, definitely give Eligius a try at least; using our SMPPS reward system, it evens out the variance by saving extra earnings from the high swings to cover the low swings. As a result, you basically get a nearly-perfectly predictable income. Even if you don't care about variance, Eligius (optionally) offers the same decentralization as p2pool with the getmemorypool protocol (which I have also written a proxy for). |
|
|
|
My best guess, at this point, is that your wallet has a corrupt private key which was not properly detected in older versions. Could you check debug.log?
I copied 0.4.4 back, and now I'm getting a slightly different error. Does 0.4.2 still work? This looks like blkindex.dat got corrupted somehow. |
|
|
|
I'm getting
Error loading wallet.dat: Wallet corrupted Even after restoring your backup? Can you join #bitcoin-dev to troubleshoot? No, i was using 0.4.2 before, and it worked fine. When i changed to 0.4.4, i got that error, and when i restored the old executable, it was working fine again. Seems like an incompatible wallet version to me. My best guess, at this point, is that your wallet has a corrupt private key which was not properly detected in older versions. Could you check debug.log? |
|
|
|
I'm getting
Error loading wallet.dat: Wallet corrupted Even after restoring your backup? Can you join #bitcoin-dev to troubleshoot? |
|
|
|
Bitcoin version 0.4.4rc3 and 0.5.3rc3 are now available for download. These are bugfix-only releases based on 0.4.0 and 0.5.1, respectively. Please report bugs by replying to this forum thread. Stable source code is hosted at Gitorious: http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.4rc3#.tar.gz http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3rc3#.tar.gzWindows binaries are on my site: http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.4/test/ http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.5.3/test/BUG FIXESSince 0.4.3 and 0.5.2: - Various compile warning fixes.
- Updated fallback seed nodes, chosen based on uptime and version.
- February 15, 2012 testnet difficulty calculation changes.
- Reannounce UPnP port forwarding rules every 20 minutes, to work around routers that expire them.
- Verify integrity of private keys in wallet file at startup.
- Don't store completely invalid transactions in memory.
- Recommend a secure password for bitcoind, when none is set, and increase JSON-RPC delay when a wrong password is attempted.
- Fix incorrect memory release, which may have caused crashes.
- Use UPnP IP in version messages when available, and never send non-routable IPs.
- Do not attempt to create "CAddress" objects for invalid accepts.
- Several shutdown-related fixes.
- Various wallet locking fixes.
- Fixed memory leaks.
- Fixed a wrong error message when failing to get external IP from webservice.
- New checkpoint at block 168,000.
- A fix for a potential DoS attack.
- BIP 30: Forbid overwriting unspent transactions with duplicates.
Just since 0.5.2: - Make transaction description read-only.
- Add "About Qt" menu option to show built-in Qt About dialog.
- Add missing "Clear all" tooltip.
- Fix building test framework with shared boost libraries.
- Revert to global blockchain download progress indication.
- Minor translation/capitalization fixes.
- Restructure credit transaction decomposition to fix issue #689.
- Enable accessible widgets Qt module on win32, so that people with screen readers such as NVDA can make sense of it.
- Prevent window from being shown momentarily when using -min
- Fix Minimize to the tray instead of the taskbar.
- Fix parsing of invalid bitcoin URIs (with bitcoin:// instead of simply bitcoin:)
- Don't overwrite user-entered labels with ones from the address book.
- Display a message box with help on Windows for --help
- Don't show splash screen when -min is specified on the command line.
- Don't show weird tooltip when last received block has a future timestamp.
Thanks to everybody who contributed code or helped test these releases: Pieter Wuille Luke Dashjr Wladimir J. van der Laan Gavin Andresen Matt Corallo Lars Rasmusson Janne Pulkkinen Gregory Maxwell Daniel Folkinshteyn Chris Moore |
|
|
|
|
Someone exploited the fact that BIP 16 isn't active to steal 0.004 BTC from someone who tried to use it. rc1 is enforcing BIP 16 unless you use -pushtoscripthashtime (see some other thread for what to set it to). In short, this problem is because 0.6.0rc* includes BIP 16 support before it is accepted by the Bitcoin network (as an attempt to force BIP 16 despite objections).
Disclaimer: BIP 17 would have the same problem if it were included in the client before network acceptance.
Edit: To clarify, the person who lost 0.004 BTC in this exploit must have intentionally modified his client to allow him to create such an insecure transaction.
|
|
|
|
With that said, I would suggest this change be done on another block chain like Namecoin that does not have a large market cap and reputation to protect. Changing another block chain gives you faster deployment of the new code and redeployment should a flaw be discovered. Both BIPs have been tested on Bitcoin's "testnet", and BIP 17 (formerly "CODEHASHCHECK") has been tested on the main Bitcoin network. I assumed it was tested on testnet but that's not real world enough. People need to be able to use it day to day and give hackers time to pick it apart and find a flaw. Remember the OP_EVAL and the flaw found after it was considered. Perhaps, but in reality the only way to get real day-to-day testing is in the main chain. |
|
|
|
With that said, I would suggest this change be done on another block chain like Namecoin that does not have a large market cap and reputation to protect. Changing another block chain gives you faster deployment of the new code and redeployment should a flaw be discovered. Both BIPs have been tested on Bitcoin's "testnet", and BIP 17 (formerly "CODEHASHCHECK") has been tested on the main Bitcoin network. |
|
|
|
01000000 - version
0000000016375AF4A21B4CE2B2CE64B5A5B27B5EAB4C15E97DB66208C7938EF8 - previous hash
0C6B39F2051927306C8008A9DD29E9E33A8ABA9AB45A4D816C488B08E2368645 - merkle root
006B554F - timestamp
A436231C - bits
55FEC3C6 - nonce
01 - transaction number
01000000 - version
01 - inputs
0000000000000000000000000000000000000000000000000000000000000000FFFFFFFF - input
0A - script length
5468655069616368750B - script
FFFFFFFF - sequence
01 - outputs
00F2052A01000000 - value
43 - script length
4104475876434DAB12C149E7DC68AA4AEF44B7DAD9BC9B90CB1C6751EAD47DE7BA3AC7AA10C6BCDEB6DC42C85BB7588BC114C6E47072E0264FB1C33B6FBD69E040F2AC - script
00000000 - locktime I still get "False" as a response to this. Where am I making an error? 01000000 - version
WRONG: 0000000016375AF4A21B4CE2B2CE64B5A5B27B5EAB4C15E97DB66208C7938EF8 - previous hash
FIXED: f88e93c70862b67de9154cab5e7bb2a5b564ceb2e24c1ba2f45a371600000000 - previous hash
WRONG: 0C6B39F2051927306C8008A9DD29E9E33A8ABA9AB45A4D816C488B08E2368645 - merkle root
FIXED: 458636e2088b486c814d5ab49aba8a3ae3e929dda908806c30271905f2396b0c - merkle root
006B554F - timestamp
A436231C - bits
55FEC3C6 - nonce
01 - transaction number
01000000 - version
01 - inputs
0000000000000000000000000000000000000000000000000000000000000000FFFFFFFF - input
0A - script length
5468655069616368750B - script
FFFFFFFF - sequence
01 - outputs
00F2052A01000000 - value
43 - script length
4104475876434DAB12C149E7DC68AA4AEF44B7DAD9BC9B90CB1C6751EAD47DE7BA3AC7AA10C6BCDEB6DC42C85BB7588BC114C6E47072E0264FB1C33B6FBD69E040F2AC - script
00000000 - locktime |
|
|
|
I tried this yesterday (which is why I was asking). I changed the listener IP in the python script and connected my rigs. One rig worked just fine, but when I added more machines, cgminer couldn't get work quickly enough and kept disconnecting/reconnecting from/to the proxy. I only tested it for a short time though before going to bed.
Hmm, not sure what might cause that. How's it look on CPU usage? Can you create me a pcap file? tcpdump -i any -s0 -w pcap port 8337 or port 9332 |
|
|
|
Sure enough, 3.1.4 works. Weird.
Is this proxy meant to run an individual copy on each miner? In other words, it's not meant to run one instance with multiple miners?
It should be fine with multiple miners, but it only supports one upstream username. |
|
|
|
Hmmm... I was using 3.2.2. Perhaps I should try an earlier version?
I'm not sure what version introduced the bug. Just that 3.1.4 is bug-free. |
|
|
|
Hey Luke. I was giving gmp-proxy a try and ran into a snag. The server starts fine, but as soon as a mining client connects, I get an error regarding string conversion. I'm fairly certain I have everything configured correctly (unless the newest git isn't supposed to be used against Eligius yet?): ERROR:JSONRPCHandler:Error during JSON-RPC call: doJSON_getwork[]
Traceback (most recent call last):
File "/tmp/eloipool/jsonrpcserver.py", line 156, in _doJSON_i
rv = getattr(self, method)(*params)
File "/tmp/eloipool/jsonrpc_getwork.py", line 40, in doJSON_getwork
hdr = self.server.getBlockHeader(self.Username)
File "gmp-proxy.py", line 67, in MakeWork
MRD = getMRD()
File "gmp-proxy.py", line 47, in getMRD
MRD = makeMRD(mp)
File "gmp-proxy.py", line 26, in makeMRD
coinbase = a2b_hex(mp['coinbasetxn'])
TypeError: 'str' does not support the buffer interface This is a bug in CPython. It's fixed in git, and at least in 3.1.4. |
|
|
|
It's a nice draft, but it doesn't really specify how to encode a block. That's already part of the main Bitcoin protocol specification. Even the endianness of "previousblockhash" in getmemorypool is different to the one we can see encoded in getwork "data", so it can be quite confusing. That's because the getwork "data" is part of a SHA256 midstate, which interprets the little-endian data as big-endian... so effectively inverts every 32 bits. |
|
|
|
This is interesting but I don't understand the low level details. Does this imply that mining this way with the proxy achieves the same independence as p2p or solo regarding 51% attacks and/or voting? 51% attacks, yes, provided enough users choose to audit the blocks. "voting": in theory, but supporting it on Eligius would be a lot of work for effectively nothing (BIP 16 sucks, and it'll probably be over within a month anyway) |
|
|
|
Correct me if I am wrong, but what this means to the miners is that they now have a way to verify that the work they have done is being reflected in the blocks that the pool produces. This is a good improvement if implemented widely, but for now needs somewhat manual checking. Pretty much. They can also append their own stuff to the coinbase if they like. gmp-proxy uses that to generate local work, so you can have pretty much unlimited local miners running off a single work. |
|
|
|
|
Show Posts
