Pooled/Remote Mining - Open Source - Updated 2010-12-24 - page 6.

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

Scratch that.

It seems to have come back around and seems a bit more normal the last few minutes.

Quote from: FairUser on December 05, 2010, 07:39:27 AM

I just notice my bitcoinr log file showed the server was down for a few minutes, and now it shows the additional line:

0 blocks generated since 2010-12-05 12:16:18 UTC

Thanks for the extra info.

However, I've noticed my bitcoinr log also says "Server reports my khash/s as 566" very consistently.
This use to say "Server reports my khash/s as 833" very consistently.
I'm seeing the same behavior accross my 3 boxes I have running bitcoinr.

I'm curious as to what changed on the server side, cause I didn't change a thing on my end and it seems to report less khash/s now than it did before the change.

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: FairUser on December 05, 2010, 07:39:27 AM

I just notice my bitcoinr log file showed the server was down for a few minutes, and now it shows the additional line:

0 blocks generated since 2010-12-05 12:16:18 UTC

The server stopped for some reason. I've restarted it.

Quote from: FairUser on December 05, 2010, 07:39:27 AM

However, I've noticed my bitcoinr log also says "Server reports my khash/s as 566" very consistently.
This use to say "Server reports my khash/s as 833" very consistently.
I'm seeing the same behavior accross my 3 boxes I have running bitcoinr.

I'm curious as to what changed on the server side, cause I didn't change a thing on my end and it seems to report less khash/s now than it did before the change.

The khash rate seems to be oscillating for me. It reports 400 khash/s then the next report it's 1600. The average of those 2 is 1,000 which is the normal rate for my cpu. Odd. The total combined khash rate is also oscillating. I think the server is overloaded. It's pegged at a 100% CPU right now with 143 clients.

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

I just notice my bitcoinr log file showed the server was down for a few minutes, and now it shows the additional line:

0 blocks generated since 2010-12-05 12:16:18 UTC

Thanks for the extra info.

However, I've noticed my bitcoinr log also says "Server reports my khash/s as 566" very consistently.
This use to say "Server reports my khash/s as 833" very consistently.
I'm seeing the same behavior accross my 3 boxes I have running bitcoinr.

I'm curious as to what changed on the server side, cause I didn't change a thing on my end and it seems to report less khash/s now than it did before the change.

matt

newbie

Activity: 1

Merit: 0

jon_smark

member

Activity: 90

Merit: 10

Hi,

I get a compilation error when building under Ubuntu Lucid in an x86_64 arch. I just got the latest version from github, and the only modification I made was adding the following code to the end of cmake-bitcoinr/CMakeLists.txt as described previously in this thread.

Code:

IF(NOT WIN32)
TARGET_LINK_LIBRARIES(bitcoinr pthread)
ENDIF(NOT WIN32)

Anyway, though the invocation of 'cmake .' succeeds:

Code:

-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Boost version: 1.40.0
-- Found the following Boost libraries:
-- date_time
-- filesystem
-- program_options
-- regex
-- system
-- thread
-- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
-- Found BerkeleyDB: /usr/lib/libdb.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/smark/software/bitcoin-pool

the actual compilation fails:

Code:

smark@mymachine:~/software/bitcoin-pool$ make
[ 11%] Building CXX object cmake-bitcoinr/CMakeFiles/bitcoinr.dir/__/src/remote/remoteminerclient.cpp.o
In file included from /home/smark/software/bitcoin-pool/src/remote/../headers.h:127,
from /home/smark/software/bitcoin-pool/src/remote/remotebitcoinheaders.h:33,
from /home/smark/software/bitcoin-pool/src/remote/remoteminerclient.h:30,
from /home/smark/software/bitcoin-pool/src/remote/remoteminerclient.cpp:19:
/home/smark/software/bitcoin-pool/src/remote/../net.h: In member function ‘void CNode::EndMessage()’:
/home/smark/software/bitcoin-pool/src/remote/../net.h:710: warning: invalid access to non-static data member ‘CMessageHeader::nMessageSize’ of NULL object
/home/smark/software/bitcoin-pool/src/remote/../net.h:710: warning: (perhaps the ‘offsetof’ macro was used incorrectly)
/home/smark/software/bitcoin-pool/src/remote/../net.h:718: warning: invalid access to non-static data member ‘CMessageHeader::nChecksum’ of NULL object
/home/smark/software/bitcoin-pool/src/remote/../net.h:718: warning: (perhaps the ‘offsetof’ macro was used incorrectly)
/home/smark/software/bitcoin-pool/src/remote/../net.h:719: warning: invalid access to non-static data member ‘CMessageHeader::nChecksum’ of NULL object
/home/smark/software/bitcoin-pool/src/remote/../net.h:719: warning: (perhaps the ‘offsetof’ macro was used incorrectly)
/home/smark/software/bitcoin-pool/src/remote/remoteminerclient.cpp: In member function ‘void RemoteMinerClient::SendFoundHash(int64, const std::vector >&, unsigned int)’:
/home/smark/software/bitcoin-pool/src/remote/remoteminerclient.cpp:631: error: conversion from ‘long long int’ to ‘const json_spirit::Value_impl, std::allocator > > >’ is ambiguous
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:283: note: candidates are: json_spirit::Value_impl::Value_impl(double) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:275: note: json_spirit::Value_impl::Value_impl(uint64_t) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:267: note: json_spirit::Value_impl::Value_impl(int64_t) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:259: note: json_spirit::Value_impl::Value_impl(int) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:251: note: json_spirit::Value_impl::Value_impl(bool) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:219: note: json_spirit::Value_impl::Value_impl(typename Config::String_type::const_pointer) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/remoteminerclient.cpp:637: error: conversion from ‘int64’ to ‘const json_spirit::Value_impl, std::allocator > > >’ is ambiguous
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:283: note: candidates are: json_spirit::Value_impl::Value_impl(double) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:275: note: json_spirit::Value_impl::Value_impl(uint64_t) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:267: note: json_spirit::Value_impl::Value_impl(int64_t) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:259: note: json_spirit::Value_impl::Value_impl(int) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:251: note: json_spirit::Value_impl::Value_impl(bool) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:219: note: json_spirit::Value_impl::Value_impl(typename Config::String_type::const_pointer) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/remoteminerclient.cpp: In member function ‘void RemoteMinerClient::SendMetaHash(int64, const std::vector >&, unsigned int, const std::vector >&, const uint256&, unsigned int)’:
/home/smark/software/bitcoin-pool/src/remote/remoteminerclient.cpp:658: error: conversion from ‘long long int’ to ‘const json_spirit::Value_impl, std::allocator > > >’ is ambiguous
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:283: note: candidates are: json_spirit::Value_impl::Value_impl(double) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:275: note: json_spirit::Value_impl::Value_impl(uint64_t) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:267: note: json_spirit::Value_impl::Value_impl(int64_t) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:259: note: json_spirit::Value_impl::Value_impl(int) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:251: note: json_spirit::Value_impl::Value_impl(bool) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:219: note: json_spirit::Value_impl::Value_impl(typename Config::String_type::const_pointer) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/remoteminerclient.cpp:664: error: conversion from ‘int64’ to ‘const json_spirit::Value_impl, std::allocator > > >’ is ambiguous
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:283: note: candidates are: json_spirit::Value_impl::Value_impl(double) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:275: note: json_spirit::Value_impl::Value_impl(uint64_t) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:267: note: json_spirit::Value_impl::Value_impl(int64_t) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:259: note: json_spirit::Value_impl::Value_impl(int) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:251: note: json_spirit::Value_impl::Value_impl(bool) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:219: note: json_spirit::Value_impl::Value_impl(typename Config::String_type::const_pointer) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/remoteminerclient.cpp:667: error: conversion from ‘int64’ to ‘const json_spirit::Value_impl, std::allocator > > >’ is ambiguous
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:283: note: candidates are: json_spirit::Value_impl::Value_impl(double) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:275: note: json_spirit::Value_impl::Value_impl(uint64_t) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:267: note: json_spirit::Value_impl::Value_impl(int64_t) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:259: note: json_spirit::Value_impl::Value_impl(int) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:251: note: json_spirit::Value_impl::Value_impl(bool) [with Config = json_spirit::Config_vector, std::allocator > >]
/home/smark/software/bitcoin-pool/src/remote/../json/json_spirit_value.h:219: note: json_spirit::Value_impl::Value_impl(typename Config::String_type::const_pointer) [with Config = json_spirit::Config_vector, std::allocator > >]
make[2]: *** [cmake-bitcoinr/CMakeFiles/bitcoinr.dir/__/src/remote/remoteminerclient.cpp.o] Error 1
make[1]: *** [cmake-bitcoinr/CMakeFiles/bitcoinr.dir/all] Error 2
make: *** [all] Error 2

Any idea of what might wrong here? Thanks in advance!
Jon.

doublec

legendary

Activity: 1078

Merit: 1005

For those not following the other thread, the pool generated its first block today:

http://blockexplorer.com/block/00000000000233334b157d901714baf59e5b9236227b2878844e52244da4195e

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: puddinpop on December 02, 2010, 06:56:29 PM

I suggest server operators let everyone know the time they will be updating, and everyone else make their best effort to update their clients at that time.

I will most likely be doing this after the weekend sometime. I'll post a more exact date/time later.

I've been requested to set up a git repository with changes specific to getting the remote miner compiled on linux. I've done this and it's at: https://github.com/doublec/bitcoin-pool

The 'master' branch should build the remote miner only on linux by running cmake followed by make. The 'bitcoin-remote-20101201' branch contains the source originally from puddinpop for that version with no changes. You can get a diff to see my (minor) changes to get things to build by diffing these two branches.

puddinpop

member

Activity: 103

Merit: 17

I've updated the first post with the latest release. This includes a backwards incompatible change. Clients and servers both need to run either the old version or this version. Otherwise the clients will hammer the server with connections, only to be disconnected over and over. I suggest server operators let everyone know the time they will be updating, and everyone else make their best effort to update their clients at that time.

puddinpop

member

Activity: 103

Merit: 17

Quote from: bober182 on December 02, 2010, 06:27:34 PM

Assuming blocks are generated roughly every ten minuets what I can do is generate a block by myself for the full 50 BTC for about 9 minuets then hop on to the server and pump a fast hash rate the server will calculate that I should get some bitcoins even tho I have not helped out a lot. If you count Hashes that are sent it will fix this. Also if some one disconnects 10 seconds before the block is found and they where the leading hash speed they get nothing and everyone else gets a lot more then they should.

If a client disconnects who was generating a large amount of hashes, and the block was subsequently solved, then he wasn't involved in the creation of the block at all. It doesn't matter if he provided 99.99% of all hashes up to that point if none of those hashes generated a block. One and only one client generates the block. You value total hashes contributed more than hash rate at a point in time, but others may not value this distribution method as much as the current method. Some may think one method is more fair than the other. Both methods will be available in the next release, and the server operator will need to decide what to use.

Quote from: BitLex on December 02, 2010, 06:32:01 PM

not sure if i like the count-all-hashes-idea,
it kinda erases the lottery-style of bitcoin.

Well, as you can see, some people like the "count all hashes contributed" approach, and some prefer the "connected client hash rate" method. I'm in the process of uploading a new version which includes the new method.

BitLex

hero member

Activity: 532

Merit: 505

and why do you expect the pool to get "the next" block?
it's not only you and the pool on the network, there's others creating blocks all the time and you might get nothing for a very long time.

not sure if i like the count-all-hashes-idea,
it kinda erases the lottery-style of bitcoin.

bober182

full member

Activity: 308

Merit: 100

Assuming blocks are generated roughly every ten minuets what I can do is generate a block by myself for the full 50 BTC for about 9 minuets then hop on to the server and pump a fast hash rate the server will calculate that I should get some bitcoins even tho I have not helped out a lot. If you count Hashes that are sent it will fix this. Also if some one disconnects 10 seconds before the block is found and they where the leading hash speed they get nothing and everyone else gets a lot more then they should.

puddinpop

member

Activity: 103

Merit: 17

Quote from: bober182 on December 02, 2010, 06:14:58 PM

Is the other one not flawed then Assuming each block is generated every 10 minuets can I not connect a lot of C/GPU power for the final minuet and get a bigger share ever tho I did little work.

I'm at a loss to understand why you think sending a deluge of valid hashes near the end of block generation, or any other time for that matter, would somehow result in a flawed implementation. The hashes are either valid or not. It doesn't matter how many are sent, or when they are sent. They are either valid and counted, or not valid and discarded.

bober182

full member

Activity: 308

Merit: 100

Is the other one not flawed then Assuming each block is generated every 10 minuets can I not connect a lot of C/GPU power for the final minuet and get a bigger share ever tho I did little work.

puddinpop

member

Activity: 103

Merit: 17

Quote from: bober182 on December 01, 2010, 07:36:49 PM

BUG
If I close all my miners and restart them I lose all the Coins from the current Block that i should have received. Maybe use a table or array to store address in memory so people on the go can use it or even if there internet goes out.

That's not a bug, that is how it was designed to work, and you're not losing anything, as no blocks were generated while you were connected. You need to be connected and actively contributing to get a share of the coins. Now I am currently working on an alternate distribution method that would count all hashes sent to the server since the last solved block, and distribute based on that. The server operator will have to select which distribution method they want to use.

bober182

full member

Activity: 308

Merit: 100

BUG
If I close all my miners and restart them I lose all the Coins from the current Block that i should have received. Maybe use a table or array to store address in memory so people on the go can use it or even if there internet goes out.

doublec

legendary

Activity: 1078

Merit: 1005

Some changes I had to make to the latest source to get building on Linux:

1. I had to add the following lines to the end of cmake-bitcoinr/CMakeLists.txt

IF(NOT WIN32)
TARGET_LINK_LIBRARIES(bitcoinr pthread)
ENDIF(NOT WIN32)

It needed pthread to link on Linux. I made it 'NOT WIN32' in case it's needed on Mac too.

2. In src/remote/remotebitcoinheaders.h, removed the "../blah.h" includes and replaced them all with a single:

#include "../headers.h"

This got things included in the right order. Not sure if that's the optimal fix.

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: puddinpop on December 01, 2010, 05:40:48 PM

I've updated the first post with the newest source and binaries.

Thanks, I've updated the my pool server to use this. I like the extra information the remote client shows!

puddinpop

member

Activity: 103

Merit: 17

I've updated the first post with the newest source and binaries.

The main changes are

Decreased bandwidth utilization, especially for incoming bandwidth to the server. This will only take effect is both server and client are running this new version. If there is a mismatch between client and server version, the bandwidth usage will actually be slightly increased.
More details displayed by the CPU miner, including the number of blocks generated by the server since it was started, and how many coins the client will get if the current block is solved. Please note that the first block sent by the server to the client won't have any coins being distributed to the client because it has effectively 0 hash/s at that time.

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: ?? on ??

If you want people to connect to you, create a new thread stating such, in the main post give your IP address, and link the binaries and a simple how to.

Keep it up-to-date if new releases come out.

I started a webpage with details: http://www.bluishcoder.co.nz/bitcoin-pool/

~~I'll start a thread once I've got the GPU situation and/or some linux binaries sorted.~~
Actually probably better just to a thread. Thread here: https://bitcointalksearch.org/topic/join-a-pooled-bitcoin-mining-effort-2027

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: da2ce7 on November 30, 2010, 12:46:15 AM

My GPU mining computer melted... (stupid Aussie summer heat)... One I have it back running (1 week approx) I'll volunteer to join for debugging.

Unfortunately it seems there's no GPU enabled remote miner client. What is your GPU setup? CUDA or OpenCL? Windows, Linux or Mac?

Topic: Pooled/Remote Mining - Open Source - Updated 2010-12-24 - page 6. (Read 59069 times)