Search content
Sort by
Showing 20 of 78 results by TeaRex
You can also use -q 0 to disable the queue entirely.
Hmmm... at -q 0 Phoenix (current git running on Windows 7 x64, 64-bit Python 2.7.2) just keeps complaining that the queue is empty and never starts any actual mining.
The queue issue seems to be the reason why I get relatively high amounts of rejects when running against a local proxy; the proxy adds another layer of pre-fetching which of course makes the issue worse (and which you, jedi95, aren't responsible for at all).
Thank you VERY MUCH for this fix!! The errors are completely gone and, judging from about 30 minutes of mining, the only remaining problem with the combination Phoenix 1.7.1 and cdhowie's proxy seems to be a relatively high number of rejects. Nothing earth shattering though so it might just have been bad luck. I'll keep trying and report back later.
What exactly are you connecting to?
I'm connecting to cdhowie's Apache-MySQL-PHP based mining proxy (last Git version from June 7). It's running on the same machine, and it worked perfectly with older phoenix, including the Git version from October 12 "Fixed issue with immediate disconnects on RPC servers not impl..." What seems to have broken it is the Git update from October 30 "Modify RPCProtocol to use httplib instead of Twisted for persistent HT..."
By the way, I get the problem I described above both for the Precompiled Win32 version and when running the source code directly on 64-Bit Python for Windows.
Thank you for looking into this.
Thanks for still working on this! 1.7.0 seems to have some major bugs however; it keeps disconnecting/reconnecting/idling and also throws out error messages like this:
My command line was:
Code:
[04/11/2011 02:49:43] Phoenix v1.7.0 starting...
[04/11/2011 02:49:46] Connected to server
[04/11/2011 02:49:50] Result: f278c955 accepted
[04/11/2011 02:49:57] Disconnected from server
[04/11/2011 02:50:05] Result: 1ff83ef6 accepted
[359.95 Mhash/sec] [2 Accepted] [0 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
File "twisted\internet\defer.pyc", line 1076, in gotResult
File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks
File "twisted\internet\defer.pyc", line 388, in errback
File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks
--- ---
File "twisted\internet\defer.pyc", line 542, in _runCallbacks
File "minerutil\RPCProtocol.pyc", line 134, in errback
File "minerutil\RPCProtocol.pyc", line 416, in _failure
File "minerutil\RPCProtocol.pyc", line 227, in stop
File "minerutil\RPCProtocol.pyc", line 57, in closeConnection
exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:50:12] Connected to server
[04/11/2011 02:50:22] Disconnected from server
[04/11/2011 02:50:36] Failed to connect, retrying...
[04/11/2011 02:50:36] Result: 84e0e226 rejected
[04/11/2011 02:50:45] Warning: work queue empty, miner is idle
[04/11/2011 02:50:47] Failed to connect, retrying...
[04/11/2011 02:50:47] Result: b27b0f3e rejected
[04/11/2011 02:51:02] Connected to server
[04/11/2011 02:51:13] Result: 2d5ce285 rejected
[04/11/2011 02:51:24] Result: 7cfcd8b4 rejected
[04/11/2011 02:51:37] Result: c6a5693f rejected
[04/11/2011 02:51:49] Disconnected from server
[04/11/2011 02:51:52] Result: c1db4b62 accepted
[04/11/2011 02:51:55] Result: 0a76485d accepted
[04/11/2011 02:51:59] Result: 2c040a77 accepted
[362.59 Mhash/sec] [5 Accepted] [5 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
File "twisted\internet\defer.pyc", line 1076, in gotResult
File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks
File "twisted\internet\defer.pyc", line 388, in errback
File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks
--- ---
File "twisted\internet\defer.pyc", line 542, in _runCallbacks
File "minerutil\RPCProtocol.pyc", line 134, in errback
File "minerutil\RPCProtocol.pyc", line 416, in _failure
File "minerutil\RPCProtocol.pyc", line 227, in stop
File "minerutil\RPCProtocol.pyc", line 57, in closeConnection
exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:52:03] Connected to server
[04/11/2011 02:52:12] Disconnected from server
[04/11/2011 02:52:26] Connected to server
[04/11/2011 02:52:29] Result: 07de0847 accepted
[04/11/2011 02:52:36] Disconnected from server
[04/11/2011 02:52:45] Result: cec287f6 accepted
[363.54 Mhash/sec] [7 Accepted] [5 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
File "twisted\internet\defer.pyc", line 1076, in gotResult
File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks
File "twisted\internet\defer.pyc", line 388, in errback
File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks
--- ---
File "twisted\internet\defer.pyc", line 542, in _runCallbacks
File "minerutil\RPCProtocol.pyc", line 134, in errback
File "minerutil\RPCProtocol.pyc", line 416, in _failure
File "minerutil\RPCProtocol.pyc", line 227, in stop
File "minerutil\RPCProtocol.pyc", line 57, in closeConnection
exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:52:50] Connected to server
[04/11/2011 02:53:00] Disconnected from server
[04/11/2011 02:53:01] Result: 893a5bf2 accepted
[04/11/2011 02:53:12] Failed to connect, retrying...
[04/11/2011 02:53:20] Result: db96c309 accepted
[04/11/2011 02:53:24] Warning: work queue empty, miner is idle
[04/11/2011 02:53:26] Connected to server
[04/11/2011 02:53:28] Result: ad7467bb accepted
[04/11/2011 02:53:37] Disconnected from server
[04/11/2011 02:53:40] Result: 0bc82c1e accepted
[04/11/2011 02:53:42] Result: 4f28a758 accepted
[04/11/2011 02:53:49] Failed to connect, retrying...
[04/11/2011 02:54:01] Warning: work queue empty, miner is idle
[04/11/2011 02:54:03] Connected to server
[04/11/2011 02:54:09] Result: a7930a31 accepted
[04/11/2011 02:54:14] Disconnected from server
[04/11/2011 02:54:22] Result: d86fb292 accepted
[04/11/2011 02:54:25] Result: 6b91137e rejected
[04/11/2011 02:54:25] Result: 491bf929 rejected
[355.15 Mhash/sec] [14 Accepted] [7 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
File "twisted\internet\defer.pyc", line 1076, in gotResult
File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks
File "twisted\internet\defer.pyc", line 388, in errback
File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks
--- ---
File "twisted\internet\defer.pyc", line 542, in _runCallbacks
File "minerutil\RPCProtocol.pyc", line 134, in errback
File "minerutil\RPCProtocol.pyc", line 416, in _failure
File "minerutil\RPCProtocol.pyc", line 227, in stop
File "minerutil\RPCProtocol.pyc", line 57, in closeConnection
exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:54:29] Connected to server
[04/11/2011 02:54:33] Result: 558860c6 accepted
[04/11/2011 02:54:38] Disconnected from server
[04/11/2011 02:54:53] Connected to server
[354.42 Mhash/sec] [15 Accepted] [7 Rejected] [RPC (+LP)]
[04/11/2011 02:49:46] Connected to server
[04/11/2011 02:49:50] Result: f278c955 accepted
[04/11/2011 02:49:57] Disconnected from server
[04/11/2011 02:50:05] Result: 1ff83ef6 accepted
[359.95 Mhash/sec] [2 Accepted] [0 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
File "twisted\internet\defer.pyc", line 1076, in gotResult
File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks
File "twisted\internet\defer.pyc", line 388, in errback
File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks
--- ---
File "twisted\internet\defer.pyc", line 542, in _runCallbacks
File "minerutil\RPCProtocol.pyc", line 134, in errback
File "minerutil\RPCProtocol.pyc", line 416, in _failure
File "minerutil\RPCProtocol.pyc", line 227, in stop
File "minerutil\RPCProtocol.pyc", line 57, in closeConnection
exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:50:12] Connected to server
[04/11/2011 02:50:22] Disconnected from server
[04/11/2011 02:50:36] Failed to connect, retrying...
[04/11/2011 02:50:36] Result: 84e0e226 rejected
[04/11/2011 02:50:45] Warning: work queue empty, miner is idle
[04/11/2011 02:50:47] Failed to connect, retrying...
[04/11/2011 02:50:47] Result: b27b0f3e rejected
[04/11/2011 02:51:02] Connected to server
[04/11/2011 02:51:13] Result: 2d5ce285 rejected
[04/11/2011 02:51:24] Result: 7cfcd8b4 rejected
[04/11/2011 02:51:37] Result: c6a5693f rejected
[04/11/2011 02:51:49] Disconnected from server
[04/11/2011 02:51:52] Result: c1db4b62 accepted
[04/11/2011 02:51:55] Result: 0a76485d accepted
[04/11/2011 02:51:59] Result: 2c040a77 accepted
[362.59 Mhash/sec] [5 Accepted] [5 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
File "twisted\internet\defer.pyc", line 1076, in gotResult
File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks
File "twisted\internet\defer.pyc", line 388, in errback
File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks
--- ---
File "twisted\internet\defer.pyc", line 542, in _runCallbacks
File "minerutil\RPCProtocol.pyc", line 134, in errback
File "minerutil\RPCProtocol.pyc", line 416, in _failure
File "minerutil\RPCProtocol.pyc", line 227, in stop
File "minerutil\RPCProtocol.pyc", line 57, in closeConnection
exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:52:03] Connected to server
[04/11/2011 02:52:12] Disconnected from server
[04/11/2011 02:52:26] Connected to server
[04/11/2011 02:52:29] Result: 07de0847 accepted
[04/11/2011 02:52:36] Disconnected from server
[04/11/2011 02:52:45] Result: cec287f6 accepted
[363.54 Mhash/sec] [7 Accepted] [5 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
File "twisted\internet\defer.pyc", line 1076, in gotResult
File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks
File "twisted\internet\defer.pyc", line 388, in errback
File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks
--- ---
File "twisted\internet\defer.pyc", line 542, in _runCallbacks
File "minerutil\RPCProtocol.pyc", line 134, in errback
File "minerutil\RPCProtocol.pyc", line 416, in _failure
File "minerutil\RPCProtocol.pyc", line 227, in stop
File "minerutil\RPCProtocol.pyc", line 57, in closeConnection
exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:52:50] Connected to server
[04/11/2011 02:53:00] Disconnected from server
[04/11/2011 02:53:01] Result: 893a5bf2 accepted
[04/11/2011 02:53:12] Failed to connect, retrying...
[04/11/2011 02:53:20] Result: db96c309 accepted
[04/11/2011 02:53:24] Warning: work queue empty, miner is idle
[04/11/2011 02:53:26] Connected to server
[04/11/2011 02:53:28] Result: ad7467bb accepted
[04/11/2011 02:53:37] Disconnected from server
[04/11/2011 02:53:40] Result: 0bc82c1e accepted
[04/11/2011 02:53:42] Result: 4f28a758 accepted
[04/11/2011 02:53:49] Failed to connect, retrying...
[04/11/2011 02:54:01] Warning: work queue empty, miner is idle
[04/11/2011 02:54:03] Connected to server
[04/11/2011 02:54:09] Result: a7930a31 accepted
[04/11/2011 02:54:14] Disconnected from server
[04/11/2011 02:54:22] Result: d86fb292 accepted
[04/11/2011 02:54:25] Result: 6b91137e rejected
[04/11/2011 02:54:25] Result: 491bf929 rejected
[355.15 Mhash/sec] [14 Accepted] [7 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
File "twisted\internet\defer.pyc", line 1076, in gotResult
File "twisted\internet\defer.pyc", line 1066, in _inlineCallbacks
File "twisted\internet\defer.pyc", line 388, in errback
File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks
--- ---
File "twisted\internet\defer.pyc", line 542, in _runCallbacks
File "minerutil\RPCProtocol.pyc", line 134, in errback
File "minerutil\RPCProtocol.pyc", line 416, in _failure
File "minerutil\RPCProtocol.pyc", line 227, in stop
File "minerutil\RPCProtocol.pyc", line 57, in closeConnection
exceptions.AttributeError: 'NoneType' object has no attribute 'close'
[04/11/2011 02:54:29] Connected to server
[04/11/2011 02:54:33] Result: 558860c6 accepted
[04/11/2011 02:54:38] Disconnected from server
[04/11/2011 02:54:53] Connected to server
[354.42 Mhash/sec] [15 Accepted] [7 Rejected] [RPC (+LP)]
My command line was:
Code:
start "GPU 0" /min /affinity 0x08 phoenix.exe -q 2 -a 100 -u http://gpu0:pass@127.0.0.1:80/ -k phatk2 DEVICE=0 WORKSIZE=128 BFI_INT VECTORS FASTLOOP=false AGGRESSION=12
Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
The t1 variable in phatk2 is a dummy to make the compiler behave a certain way.
I figured as much; my question was more along the lines of, if the OpenCL compiler (I use the one from the Windows Catalyst 11.7 drivers) complains about it being unused, will it still "behave a certain way" then, or will t1 just be removed and the desired behaviour doesn't happen.
Whatever, just answers this if you feel like it, I don't want to steal more of your time. Thanks again for such a great miner.
Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Could you run Phoenix with the -v option and post the last few log entries before the miner stopped working? The "idle timeout" simply ensures that ask() always returns after no more than 15 seconds. The idle issue on RPC was caused by a combination of the memory leaks and ask() never running its callbacks. By fixing the memory leaks and adding a timeout to ask() it should prevent the RPC protocol from hanging.
The increase in stale shares might be due to your internet connection not working normally. It also might be due to the keep-alive issue I just fixed in 1.6.1. Try 1.6.1 out once your internet connection is working normally again and see if you still have a high stale count.
Also, I am considering forcing a failover if the miner goes idle for more than 1 minute. This will make getting stuck idling impossible, (assuming the backup server is up) since the entire protocol object is destroyed and re-created when switching servers.
The increase in stale shares might be due to your internet connection not working normally. It also might be due to the keep-alive issue I just fixed in 1.6.1. Try 1.6.1 out once your internet connection is working normally again and see if you still have a high stale count.
Also, I am considering forcing a failover if the miner goes idle for more than 1 minute. This will make getting stuck idling impossible, (assuming the backup server is up) since the entire protocol object is destroyed and re-created when switching servers.
Did another git pull this morning, and the stale shares issue is gone now, back to well below 1% for the last few hours. Jood job.
The miner hasn't yet locked up again so I can't tell if whatever problem that caused it is also solved. I'll add a -v as soon as I'm back at my machine tonight and then we will see.
About failover... I'm pointing the miner at my local mining proxy (cdhowie) which lives on the same machine. What do you think, should I use the same address as backup url, so even if not actually switching servers it will still reset the protocol if it's idle? Of course that wouldn't help with the proxy itself going down, but in my experience the proxy is very well behaved once you've figured out how to configure the underlying Apache for more concurrent threads and longer timeouts.
EDIT: One more thing, the phatk2 kernel produces a warning about variable t1 being defined but never used in the kernel (line 153 I think) on start-up, but then works fine as it seems. Is that normal and expected behaviour? Or am I missing out on an optimization that way?
Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Hello jedi95,
first I'd like to thank you for going from SVN to Git and for today's fixes and addition.
With the current (as of the time of this posting) RPC code in Git I don't get the constant disconnects and reconnects as I had with the last SVN version; but I still get far more rejected shares, up from 1 or 2% to about 10%, compared to the code from SVN r101.
Also with the current RPC code the miner at some point just stopped mining, possibly because my Internet connection is behaving a bit like a moody child today. However this time it didn't reconnect when the line came back a short time later. Maybe your new idle timeout at work here? Or is this a misunderstanding on my part, I have to admit I haven't yet checked the code.
Keep up the good work!
first I'd like to thank you for going from SVN to Git and for today's fixes and addition.
With the current (as of the time of this posting) RPC code in Git I don't get the constant disconnects and reconnects as I had with the last SVN version; but I still get far more rejected shares, up from 1 or 2% to about 10%, compared to the code from SVN r101.
Also with the current RPC code the miner at some point just stopped mining, possibly because my Internet connection is behaving a bit like a moody child today. However this time it didn't reconnect when the line came back a short time later. Maybe your new idle timeout at work here? Or is this a misunderstanding on my part, I have to admit I haven't yet checked the code.
Keep up the good work!
Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
The RPC code in the newest SVN version r115 is still not working right. Connections go up and down all the time with lots of idles. Maybe revert it back for the time being? I can do that by hand of course if need be but it's a bit of a hassle to maintain.
FWIW, the phatk2 kernel is exactly as fast as the r115 phatk kernel on my 6990. I measured over 24 hours with one of them on the first and one on the second GPU core of that card; there was no significant deviation in the number of shares produced by each core, less than 10 shares difference.
FWIW, the phatk2 kernel is exactly as fast as the r115 phatk kernel on my 6990. I measured over 24 hours with one of them on the first and one on the second GPU core of that card; there was no significant deviation in the number of shares produced by each core, less than 10 shares difference.
Die Rechnung ist recht einfach,
Dann stell sie doch hier mal rein. Wenn Deine Rechnung Sinn ergibt und nachvollziehbar ist, dann wäre sie doch ein Gewinn für die Mitleser.
Re: Ask miners? What do you want from your pool? How can we make MT.Red Better?
As soon as 3-4 bigger pools run delayed (currently only 2 huge pools run delayed prop.) there will be measures against this.
Can you describe those measures? What would they be like? I honestly don't know.
cdhowie's proxy lets you mine on port 80 without problems. In fact I'm doing just that since it means I won't have to open more than one port (I need port 80 anyway for the proxy's web admin interface). The proxy itself is port agnostic, you just need to configure the Apache it runs on to use the correct port.
If you run that proxy on Windows note that you'll have to greatly increase the Timeout and ThreadsPerChild values in the Apache httpd.conf, otherwise the proxy will give more stales than necessary and will stop working after some hours. I use Timeout 4200 and and ThreadsPerChild 1024 which works well.
If you run that proxy on Windows note that you'll have to greatly increase the Timeout and ThreadsPerChild values in the Apache httpd.conf, otherwise the proxy will give more stales than necessary and will stop working after some hours. I use Timeout 4200 and and ThreadsPerChild 1024 which works well.
Hallo btcpool24!
Persönlich liebe ich als Miner Deine PPS-Auszahlung, aber im Interesse des dauerhaften Bestehens Deines Pools solltest Du mal das hier lesen und gedanklich auf Deinen Pool anwenden:
http://de.wikipedia.org/wiki/Martingalespiel
Fazit: Mit reinem PPS gehst Du - je nach Deinem vorhandenen Kapital - früher oder später mit Sicherheit pleite, weil irgendwann zwangsläufig zu viele lange Blöcke nacheinander kommen werden. Mit genügend Kapital kannst Du die Wahrscheinlichkeit, dass dies im Zeitraum X passiert, beliebig weit absenken (müsstest Du allerdings genau durchrechnen, die nötigen Summen werden für längere Zeiträume schnell sehr hoch), allerdings sinkt die Wahrscheinlichkeit nie auf Null. Nur unendliches Kapital würde Dich prinizipiell schützen.
Grüße TeaRex.
Persönlich liebe ich als Miner Deine PPS-Auszahlung, aber im Interesse des dauerhaften Bestehens Deines Pools solltest Du mal das hier lesen und gedanklich auf Deinen Pool anwenden:
http://de.wikipedia.org/wiki/Martingalespiel
Fazit: Mit reinem PPS gehst Du - je nach Deinem vorhandenen Kapital - früher oder später mit Sicherheit pleite, weil irgendwann zwangsläufig zu viele lange Blöcke nacheinander kommen werden. Mit genügend Kapital kannst Du die Wahrscheinlichkeit, dass dies im Zeitraum X passiert, beliebig weit absenken (müsstest Du allerdings genau durchrechnen, die nötigen Summen werden für längere Zeiträume schnell sehr hoch), allerdings sinkt die Wahrscheinlichkeit nie auf Null. Nur unendliches Kapital würde Dich prinizipiell schützen.
Grüße TeaRex.
Re: Ask miners? What do you want from your pool? How can we make MT.Red Better?
I'd love to see some kind of anti pool hopping. I admit that I (manually) hopped a bit for a while, but now with bithopper and stuff being widely adapted there's no way for a non hopper or even a casual manual hopper (like I was) to come out even.
I'd suggest going with the tried and true delayed block announcements that deepbit and now btcguild also use - people already know this method and it's easy enough for the non mathematical mind to understand, so they'd probably trust it more than other solutions such as pay per last N shares.
With your pool size you'd probably need more than one hour for it to be reasonably effective, maybe four hours or so.
Otherwise, keep up the good work! From here in northern Germany, MtRed's server is among the very fastest as far as time between establishing the HTTP connection and receiving the getwork or getting confirmation of the share submission is concerned, only some small German pools such as the new (and I fear non-viable) BTCpool24 are faster. I like that as it keeps miners running more smoothly. Also your stale rates are pretty low.
I'd suggest going with the tried and true delayed block announcements that deepbit and now btcguild also use - people already know this method and it's easy enough for the non mathematical mind to understand, so they'd probably trust it more than other solutions such as pay per last N shares.
With your pool size you'd probably need more than one hour for it to be reasonably effective, maybe four hours or so.
Otherwise, keep up the good work! From here in northern Germany, MtRed's server is among the very fastest as far as time between establishing the HTTP connection and receiving the getwork or getting confirmation of the share submission is concerned, only some small German pools such as the new (and I fear non-viable) BTCpool24 are faster. I like that as it keeps miners running more smoothly. Also your stale rates are pretty low.
IF (big if) somebody managed to insert a noticable amount of real child porn in such a way that a simple one line command could extract it, waits for it to be really deep in the chain before announcing it to the public, and if this happened before the filtering and pruning mechanisms are implemented - I'd imagine we could have a problem. Or maybe embed ROT13s of phrases that are highly offensive and inflaming to lots of religious people and would likely prevent them from ever accepting bitcoin as long as they remain in the chain - say "Allah is evil and not a true god" or some such. Again in such a way that anybody could extract them with a simple command.
In such a case what could be done after the fact? Could they still be trimmed out of the chain without invaldiating the block links and the whole transaction history after they were included? Or is that impossible at this point?
In such a case what could be done after the fact? Could they still be trimmed out of the chain without invaldiating the block links and the whole transaction history after they were included? Or is that impossible at this point?
Re: Bitcoin is NOT ready for mainstream because of 4 major problems
I haven't seen the code you had to port & integrate. But from your description it was little-endian single-threaded C code not using exceptions.
It had its own built in preemptive scheduler and used lots of critical sections (many of them implemented ad-hoc rather than through a consistent API), but since all the target systems were single-core at least no more than one thread at a time would be scheduled. I survived it.
Quote
Now you have people saying single WALLET.DAT "isn't all that bad" design. I just checked, you think so too. Who erased your memory?
Maybe we're talking past each other. I was talking about usability of bitcoind for a low-volume bitcoin user (at least one tech savvy enough to run a command line tool) as being "not all that bad" in this particular sentence. I wasn't referring to back-end issues and I guess bitcoind in its current state might not scale well enough for a big site to use it unpatched. But really my whole point was about externally visible design features and usability, not about internal design which I can really comment on, never having extensively studied the code and being myself mostly a self taught tinkerer-coder with not all that much of a grip on more abstract software engineering issues.
EDIT: Also, since Bitcoin public keys can be easily derived from the private keys (not the case with RSA such as used in PGP), does it really help all that much to keep them in separate files? Granted, a file with only the public keys in them might be useful for receive-only situations.
Re: Deterministic Paper Wallet Generator & Bitcoin Utility for Windows (SOURCE)
Or you could just send people here, less of a hassle than dealing with python eggs and stuff:
http://www.lfd.uci.edu/~gohlke/pythonlibs/
http://www.lfd.uci.edu/~gohlke/pythonlibs/
Re: Bitcoin is NOT ready for mainstream because of 4 major problems
Then let me tell you something -- in my nearly a decade of being a professional software developer I've had to work with code bases much worse than the current bitcoin code. Internal projects edited by hundreds of programmers over the years, never refactored because of time constraints.
Yeah, I've been "through the desert of #ifdefs on a thread with no name" too. Tens of thousands of lines of code with more preprocessor stuff than actual C code because it had to work on five different proprietary MS-DOS based compilers for embedded processors. My job was enabling this twisted mess (which was also its own operating system) to be built as a Linux application without breaking anything in the other builds...
The current client code is certainly better than that by far. That still doesn't make it an ideal base for building more complex bitcoin enabled applications on it. And even if bitcoind itself isn't all that bad, the GUI is really in need of some serious professional attention by people who know a bunch about design and usability issues, not just about algorithms. Unfortunately most self confessed geeks, including myself, are far better at the latter...