|
FWIW, bitcoin is already being used to fund new investments...
|
|
|
|
Does anybody know of an alternative that would let me access from multiple computers? I do not always have access to mining machines because of work/travel/etc. I started a topic before finding this topic to ask this question. http://bitcointalk.org/index.php?topic=3598.0mtgox works fine as simply a place to store bitcoins. |
|
|
|
|
Ok, implemented the H==0 test shortcut (hey, everyone uses, might as well document it) and pyminer.py now gets 250 Khash/sec for one thread, on my box.
|
|
|
|
I'm not sure you caught my point.
You're right, I didn't catch your point. I have to chew on that, though. What we need is a binary buffer with the right endianness, not a python long integer, right? No, we really do need a 256-integer, because that is the fundamental proof-of-work test in the bitcoin system, comparing two 256-bit integers: hash < target Almost every practical miner simplifies this test to simply verify that the final, most-significant 32 bits are zero. |
|
|
|
Protocol buffers for the P2P networking protocol have already been discussed. Not really realistic now, but "it would have been nice." For the purposes of this thread, protocol buffers have three disadvantages: - Duplicates data structure layout of a C/C++ data structure. You wind up encoding C/C++ data structure -> another C/C++ data structure. Python hides this from the programmer, but it is the same net result.
- Less flexible than JSON in describing dynamic, multi-dimensional data structures, because the structure of every data field is compiled into the application. Simple JSON is much more flexible, and data structures may be changed at will.
- Like current JSON, requires a native -> encoded -> native encoding for each miner client
Basically, any packetized protocol -- let us say JSON-over-TCP (rather than JSON-over-HTTP) -- requires some amount of low-level raw binary parsing to locate message boundaries. To simply pass through data unchanged, rather than decoding compressed JSON, comes for free in such protocols. Therefore, logically, any JSON-over-TCP protocol already has the ability to skip the pointless native->encoded->native step that each miner client performs, by using this pass-through method. Passing raw binary work directly from bitcoind to the client eliminates the possibility of bugs and problems related to the unnecessary encoding+decoding an additional JSON step would require. |
|
|
|
And remember, that bufreverse/wordreverse/encode/long sequence exists solely to build a 256-bit integer.
If you accept the patch that basically makes “hash = hash[::-1]” instead of a call to bufreverse() followed by a call to wordreverse(), there is no longer any use for wordreverse(), plus bufreverse() is ever only used in one place. The “hash[::-1]” (i.e., “reverse the entire buffer”) could be explained in a comment above the invocation. I'm not sure you caught my point. If one (a) iterates over each 4-byte sub-string, (b) uses struct.unpack to perform endian conversion, and (c) uses Python integer math to build a 256-bit long, there should be no need for hash=hash[::-1] or bufreverse/wordreverse. |
|
|
|
I don't mind optimizing bufreverse/wordreverse, but I would like to avoid optimizing Miner.work() so heavily that it cannot be read. That's the function that must be most-readable to other humans.  And remember, that bufreverse/wordreverse/encode/long sequence exists solely to build a 256-bit integer. It would probably be more optimal to simply build a 256-bit integer using a per-word loop and shifts, such as s = 'binary string...'
r = 0L
for i in range(8):
w32 = struct.unpack('>I', s[i:i+4])
r = r | (w32 << (i * 32))
According to the docs, we can specify the byte order to struct.unpack() |
|
|
|
Call me crazy, but does anyone else see it as a problem that the BTC economy can and will "lose" coins over time?
Been covered exhaustively in these forums; search around for hoarding and lost-coin subjects. |
|
|
|
It is computational expensive to repeatedly concatenate strings in Python. I suggest using [].append() in the bufreverse() and wordreverse() methods: Updated the source code with your suggestions. Thanks -- this is my second python program, so I guarantee there are other improvements that expert Python programmers can discover. |
|
|
|
If I were to rewrite bitcoin from scratch, I would - use another algorithm than ECDSA
- drop the script engine entirely, and simply support one or more fixed-format data structures for transaction signing
What's wrong with ECDSA? Patent issues lead it to be excluded from major distros like Fedora. |
|
|
|
If I were to rewrite bitcoin from scratch, I would - use another algorithm than ECDSA
- drop the script engine entirely, and simply support one or more fixed-format data structures for transaction signing
|
|
|
|
Would it be hard to get the miner to send an email message everytime the block was accepted?
The easiest would be to specify a program to be executed, when a block/share is accepted. Then you can write a script / batch file to send an email, play a sound, send an SMS, whatever. |
|
|
|
Here is a new high performance, highly optimized CPU miner: https://github.com/jgarzik/pyminerThis pulls a whopping 256 Khash/sec per thread on my box. The main purpose is to demonstrate the mining algorithm, in a small amount of portable code. And to have a bit of fun. |
|
|
|
You are being too literal. Even python must do this step: work = json_result['data']
OK, I didn't told that the pointer lookup is not needed/performed inside, automatically. It is just done by standard libraries presented in every language and there is no need to implement binary stuff again. There is no difference between this and struct.unpack() in python, except that the JSON decode is more work, more data, and less efficient. Doing all the extra, pointless work of binary->text->compression->text->binary also increases the chances for programmer error.
Well, we are talking about personal opinions. My opinion is that high level programming is much easier and error prone than low level implementation. Thanks to this attitude, we're programming in high level languages and not in assembler. And you still does not give the calculation of bandwidth savings against JSON RPC over TCP. The precise packet sizes were given in first post. WORK message can easily be made smaller, too. Once you have a binary, packetized protocol, the easiest
Correct. But I hope you don't want to say that import json json.decode(sock.read()) is harder to do than creating own parsing library for every language (C, Python, Java, PHP?) and unpacking binary data, right? I don't want to be personal in any way, I think it's great that you open this topic. I'm just finding some equilibrium between hardcore lowlevel stuff and almost standard protocol implemented anywhere. I'm simply not convicted that this protocol need such heavy overoptimization. If you are packetizing data for JSON-over-TCP, you are unpacking binary data to obtain message size of message sent via TCP. Furthermore, inside each work unit, existing miner clients are unpacking binary data in order to perform hashing (miners hash binary data!). High-level python language happily unpacks binary data -- we have miners written in Python and Java today. Or see ArtForz's bitcoin client: http://pastebin.com/ZSM7iHZw"don't do additional, redundant, unneeded work" is not heavy optimization. It is reducing complexity in the miner client. |
|
|
|
One request: (approx) 20 bytes of request, 300? bytes of response EVERY MINUTE ==> 320 bytes per minute per worker.
Well, I know that I'm again mixing protocol and getwork implementation. But there is no big point in supporting getwork over tcp and still sending job every 5 seconds. So I'm talking about real situation, about using TCP protocol and real pushwork implementation at once. The protocol supports multiple use cases: - getwork polling (ie. how every single miner is written today). C:GETWORK S:WORK C:GETWORK S:WORK ...
- push mining C:CONFIG(push mining) S:WORK S:WORK S:WORK S:WORK ...
- monitorblocks C:CONFIG(monitor blocks) S:BLOCK S:BLOCK S:BLOCK ...
The protocol supports LAN or WAN, bitcoind or pool server. If the miner client prefers polling over push mining, they may choose to do so. |
|
|
|
Because sending work as compressed JSON involves - encoding binary data to hexidecimal
Absolutely marginal overhead. Average CPU core can encode megabytes of data to hexadecimal per second. - storing that hexidecimal string in JSON structure
So 2x more data (two bytes for one raw byte) for payload itself. For one mining job, only few bytes is really required, most of current data sending to client are not used (source: m0mchil). Much more effective way is to change job payload itself. Which is also in your proposal, for storing message payload. Again, I don't see real trouble here. - receiving pointer to hex string
That's why I told I'm probably too highlevel. I really don't care about finding pointer in hex string. It is much more cost effective to leave this job on computers and high level libraries than fiddling with bits on low level protocol. Don't forget that this protocol have to be reimplemented in many languages, so using standard protocol, you save tens of hours of labour for programming and bug fixing. You are being too literal. Even python must do this step: work = json_result['data'] It is obviously more simple -- less CPU usage and less bandwidth usage -- to send binary work data directly. Remember, binary data is the common case for mining.
You are right that raw binary protocol is really the most effective. But let's find some reasonable level of optimizations. It does not need to be _perfect_. It need to be effective AND easy to handle/debug. Don't forget that you are optimizing nanoseconds of CPU job and then perform one SQL request, which is 100x slower than any protocol parsing. Doing all the extra, pointless work of binary->text->compression->text->binary also increases the chances for programmer error. Once you have a binary, packetized protocol, the easiest, least error-prone thing to do is receive (or create, in bitcoind's case) a raw binary packet, and pass that directly to a connected miner. |
|
|
|
I just read the sources and mixing binary protocol with json compressed data looks weird for me. Why not simply use (compressed) json RPC over TCP and define only RPC methods?
Because sending work as compressed JSON involves - encoding binary data to hexidecimal
- storing that hexidecimal string in JSON structure
- compressing JSON
- (sent to client)
- decompressing JSON
- receiving pointer to hex string
- decoding hex string to binary data
It is obviously more simple -- less CPU usage and less bandwidth usage -- to send binary work data directly. Remember, binary data is the common case for mining. JSON is in the protocol for flexible feature negotiation and configuration. But we must to avoid today's binary->text->compressed->text->binary redundant data encoding, because the miners work on binary data. |
|
|
|
I respectfully disagree. I don't want to see Bitcoin creating upwards of 30% or more CPU usage by just turning on Coin Generation, even with it set to use the least amount of processors/cores. Sure, I can and have been turning Coin Generation on/off, but I would imagine more and more "common" users out there (not hardcore Bitcoin enthusiasts) might like to have the program more convenient and more "green" by only generating coins (and therefore taxing the CPU, using energy, and creating heat) when the system is idle for X time.
When it takes a year to earn a single block, you are not being green. You are spending $$$ in electricity, for a single 50 BTC block. Any environmentalist with an iota of common sense will see this as pointlessly burning coal to generate wasted electricity. Input your hash rate here to see how useless is CPU mining: http://www.alloscomp.com/bitcoin/calculator.php |
|
|
|
What about increase time interval between requests? And ban for who will be use the frequent requests.
This is not a network protocol issue. You can easily add these rules to your pool server or bitcoind, once the protocol is deployed. |
|
|
|
I wasn't sure if I should post this topic here in "Project Development" or in "Development & Technical Discussion". Maybe I'll post there too.
I would think surely others have requested a similar feature, but didn't find it by doing forum searches. The one feature I would like to see is something to the effect of Coin Generation being on, but a setting/option that can be checked that tells Bitcoin to pause coin generation unless the computer/PC has not been in use for X minutes, where you can change the X value. So, for example, one can set Bitcoin to pause (not generate bitcoins) unless the PC has not been in use for 2 minutes. Obviously, the option would have no effect if coin generation is currently off (un-checked).
CPU mining is pretty useless. The only work I see being put into the official bitcoin client would be to hide the Generate Coins option so that newbies don't trip over it. |
|
|
|
|
Show Posts
