 Show Posts
|
|
Pages: « 1 [2]
|
|
Some feature request ...
- Sorting the worker stat by the worker name
- batch create workers (or after create the worker, go back to profile page )
Why? Because I am trying to build a big cluster of workers (~30 hosts)..... (I may will give more details later)
|
|
|
|
.....
By giving up on this piece of work and moving to the next I might be missing out on a) finding another solution within the same block of work, and therefore another share in the eventual 50 BTC, and b) more importantly, finding a solution within the block that reaches the main bitcoin difficulty threshold and so the whole pool is missing out on a chance of generating 50 BTC.
.....
You are right. --- But, consider this: 1. The miner is general purpose. It have to work with the official bincoin client. 2. You have to get a new block when a new block is generated on the network (this is every ~30sec). You need extra lucks to get two blocks in 30s. Of course you can have it work for more blocks, but the only time saved is one json-rpc request. |
|
|
|
|
While you are at it.. could you add JSONP support as well?
yes, I am implementing a javascript, browser-based miner... It is doing 0.1 Hash/s now (Hash/s, not kHash/s). But I think it can be optimized.
|
|
|
|
According to the json rpc spec http://json-rpc.org/wiki/specification : Response ¶
It has three properties:
* [....]
* id - This must be the same id as the request it is responding to. But currently, it always give a GUID, ignoring the client's request id. Any chance correcting this? |
|
|
|
running ./configure for the .5 release, i get this: configure: error: Missing required libcurl >= 7.10.1 this is on ubuntu lucid 32bit, with libcurl 7.19.7-1ubuntu1 installed. any thoughts on why it'd think 7.19.7 is not >= 7.10.1 ? sudo apt-get install libcurl4-openssl-dev |
|
|
|
Actually I'm pretty sure you can use the built in crypto without any modification, since it is already a multiple of 64 it won't try to pad it. Python code makes it really simple: def checkwork(block, difficulty_rep):
s = hashlib.sha256(block.decode('hex'))
val = int(s.hexdigest(), 16)
diff = int(difficulty_rep, 16)
return val < diff
what is that "block" object? I tried to print out some hash from the "cpuminer" and repeat it in perl with no success: perl code: #!/usr/bin/perl
use Digest::SHA qw/ sha256_hex/;
$raw = pack 'H*', '00000001258124a1e0837367309ed9433af69c741513067793bf1f490000c0c800000000f2a45d9b1294bf78d27fe1d77558fbedf2b1eb37bb5f1808d7b77e33d809b8fb4d1c26d21b04864c01000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000';
$head = substr($raw, 0, 0x80); # first 80 byte
$head_le = pack "N*", unpack "V*", $head; # first 80 byte, endian-swapped
print sha256_hex($head), "\n";
print sha256_hex($head_le), "\n"; my output: feca1e6a511bf10a01177086ae141115f0d554fc8758c640b81f9d3121d6cbc9
06f33a488390fb281b7d2fc68140a7ad69f8397caa04475c7f65f0b5f3f4922f output generated with cpu-miner: DBG: data:
00000001258124a1e0837367309ed9433af69c741513067793bf1f490000c0c800000000f2a45d9b1294bf78d27fe1d77558fbedf2b1eb37bb5f1808d7b77e33d809b8fb4d1c26d21b04864c01000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
DBG: hash1:
697c6991ecddeb98d9af8f02a249b7e4006c8ae107a0991d4be8a88f4c9fcf1b
DBG: hash:
924638a8a492065a924f699ca1c13dd1fb4af43bb1c6d9ce8cab2e9bb6189ea7 patch i used again cpuminer: diff --git a/sha256_generic.c b/sha256_generic.c
index 444e913..b9ba930 100644
--- a/sha256_generic.c
+++ b/sha256_generic.c
@@ -250,11 +250,23 @@ bool scanhash_c(const unsigned char *midstate, unsigned char *data,
n++;
*nonce = n;
+char *hs;
+hs = bin2hex(data - 64, 128);
+fprintf(stderr, "DBG: data:\n %s\n", hs);
+free(hs);
+
runhash(hash1, data, midstate);
runhash(hash, hash1, sha256_init_state);
stat_ctr++;
+hs = bin2hex(hash1, 32);
+fprintf(stderr, "DBG: hash1:\n %s\n", hs);
+free(hs);
+hs = bin2hex(hash, 32);
+fprintf(stderr, "DBG: hash:\n %s\n", hs);
+free(hs);
+
|
|
|
|
|
hmm...
I was doing this because there are no perl module allow me to access the sha256 internals (at least not without saving the state to disk).
Does it means there are no way using the OS-provided crypto function that do complete sha256 hash work?
I think the "via" code do the extra padding as well, or does it?
|
|
|
|
The document say midstate is the hash of first half of data. But I can not repeat this in perl...  For example, I have got a work like this (from the PMS pool) "data": "000000014e010ed08a87644d4a7d9b9852e8d0c5f5d3fc253917fc2b0000201600000000cec99c8365ef81d58321dbfea0473d01fd513ffa84132a0138d82ead5fd705264d12a5dd1b04864c00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
...
"midstate": "4e3b9b00f856803067ebe0aa4026eac253a77a70374d6e490b50c947d549f74e"
My code: use Digest::SHA qw/ sha256_hex /;
$data = '000000014e010ed08a87644d4a7d9b9852e8d0c5f5d3fc253917fc2b0000201600000000cec99c8365ef81d58321dbfea0473d01fd513ffa84132a0138d82ead'; # first 64 bytes
$data_raw = pack("H*", $data ); # unpack it as a byte string
print "sha_raw = " . sha256_hex( $data_raw ) . "\n";
$data_swapped = pack "N*", unpack "V*", $data ; # endian swap
print "sha_swapped = " . sha256_hex( $data_swapped ) . "\n";
Output: sha_raw = bb4c09641e2d71c977b78edfd86c9793251e8e03f7ea211dcf7c71b7e231c7ac
sha_swapped = 8cbe144c95e66e244959719dabc1cfd4812275548ba099d78361fad1bfa7123b Anybody can help me on this? |
|
|
|
GSM networks only support well certain sound frequencies, but I'm sure it would be easy to encrypt digital 0s and 1s when using the correct frequency.
It is not "frequency". GSM use very lossy codec (as low as ~6.5kbit/s). Depends on which provider you use, and which circuit it takes, it may transfer over some other VoIP networks. You cannot expect any reasonable bandwidth / latency doing the "encrypt digital 0s and 1s when using the correct frequency" thing. Sending with SMS is the only sane option. |
|
|
|
You would need to know the IP address(es) being used for bitcoin by the bank. It might not be easy to discover that.
but it should absolutely not be relied upon as security measure If you are the bank, no. This attack vector, even if possible, is defeated if the bank has even one peer that is unknown to the attacker or for which the attacker cannot reliably spoof. An encrypted tunnel to another bitcoin bank would be enough. Just one peer? That peer need lots of bandwidth to support the bank. |
|
|
|
I put this under the category of "I own my data, and should be able to do with it what I want."
Being able to import and export bitcoin keypairs to/from wallets seems an obvious need to me.
+1 The usage of BerkeleyDB make me feel uncomfortable. BDB is known to change format between versions. And this make making alternative implementation harder. Exporting to something simpler (i.e. parsable with no external library) would be nice. |
|
|
|
|
May you create a new board for the pooled mining effort(s) ?
There are two pooled miners.
Two long threads discussing how to use it, and one thread complaining ...
They are not "Development & Technical Discussion"
|
|
|
|
the cryptopp 5.6.0 in bitcoinr tree: 133khash/s
the cryptopp 5.6.1 (provided in debian): 200khash/s
Sorry, I was mixing up some binaries. The improvement was not that great. -- in fact, that was statistically insignificant. |
|
|
|
Disclaimer: I have some experience in developing p2p network (freenet), but is a newbie in bitcoin. Please correct me if I am wrong. Observations - Generating private-club fake coins are easy
Get 100 notes from the "cloud", or a botnet. All "easy" coins are yours. - Getting fake coins accepted network-wide is hard
When the network grow large, it is impossible. - But you don't need it accepted network-wide
Banks, such as MyBitCoin, does not return the same coin you save. If you can make it accept your fake coin, you can get some real coin from it.
So the idea is: Fraud the bank. Some idea how to connect to the bank: - Dominate the bank's peer connection:
- The -addnode= / -connect= option, does it work that way?
- DoS the bank (or bank's peers), force the bank bootstrap/connect new client
- Exploit the topology. I don't know if bitcoin work this way, but some network (like Kad and Freenet) have certain topology. Exploit it to get as near to the bank as possible.
- Wait until the bank crash.
If the bank don't backup all its blocks, it have to re-download from the net, make this more then possible.
I have no idea if this really works. All these idea seems to be easy to protect from, provide that you know the attack. This post is just trying to raise some awareness, or just some idea brainstorming. |
|
|
|
I have patched the "bitcoinr" to use system provided crypto, here is the result: CPU: Premium III Mobile (yes, i know this is very very old) Compiled with gcc 4.4, -O3 -msse the cryptopp 5.6.0 in bitcoinr tree: 133khash/s the cryptopp 5.6.1 (provided in debian): 200khash/s Here is the patch to use system-provided cryptopp (if available, with fallback) https://github.com/j16sdiz/bitcoin-pool/commit/121a0a570bed15fc347cff091e740a02bd8e1a3f |
|
|
|
|
I saw you are using a modified cryptopp 5.6.0, which disable SSE2 on 32-bit x86.
On the official website, there is a newer version 5.6.1 which fix a few SHA-256 related bug. I guess you may be interested:
- fixed several bugs in the SHA-256 x86/x64 assembly code:
--- incorrect hash on non-SSE2 x86 machines on non-aligned input
--- incorrect hash on x86 machines when input crosses 0x80000000
--- incorrect hash on x64 when compiled with GCC with optimizations enabled
|
|
|
|
|
