Bitcoin Forum
December 04, 2016, 10:40:55 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 5 6 7 8 9 »  All
  Print  
Author Topic: Pooled/Remote Mining - Open Source - Updated 2010-12-24  (Read 55750 times)
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
November 29, 2010, 10:47:16 PM
 #41

@davidonpda, I ran it previously but stopped since no one was using it and the client got outdated. I restarted it with puddinpop's recent version yesterday when I posted the IP address. The number of clients, as bober182 noted, has ranged from 2 to 10.

What's needed is a larger number of people to contribute (and hopefully someone with a GPU) so that the lesser powered CPU clients can start getting some benefit from being involved.

I'm not sure if that will happen though as the GPU clients are probably more likely to want to keep mining for themselves.
Every time a block is mined, a certain amount of BTC (called the subsidy) is created out of thin air and given to the miner. The subsidy halves every four years and will reach 0 in about 130 years.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480891255
Hero Member
*
Offline Offline

Posts: 1480891255

View Profile Personal Message (Offline)

Ignore
1480891255
Reply with quote  #2

1480891255
Report to moderator
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
November 30, 2010, 01:00:55 AM
 #42

@davidonpda, I ran it previously but stopped since no one was using it and the client got outdated. I restarted it with puddinpop's recent version yesterday when I posted the IP address. The number of clients, as bober182 noted, has ranged from 2 to 10.

What's needed is a larger number of people to contribute (and hopefully someone with a GPU) so that the lesser powered CPU clients can start getting some benefit from being involved.

I'm not sure if that will happen though as the GPU clients are probably more likely to want to keep mining for themselves.

Even GPU generators are beginning to be exposed to some high variance and that will only grow.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
bober182
Full Member
***
Offline Offline

Activity: 196

127.0.0.1


View Profile
November 30, 2010, 05:41:27 AM
 #43

But in theory assuming the current difficulty does not rise.
50 bitcoins are generated per block for now. If your going at 1000khash and it takes 1 month to get the coins this sucks.
Meanwhile, someone going at 4000khash will make 4 blocks before you make one. So 5 blocks have been made in one month and you have 50 bitcoins and your GPU nemesis has 200 bitcoins. If you use correct pooling that measures not speed at generation but how many hashes generated. After one week you may not find the winning hash but GPU will. You get 10 bitcoin he gets the other 40. After the month has ended and you and him generate 5 blocks together. You will still have 50 bitcoins and he will have his 200.
All this does is divide the way bitcoins are generated to a quicker approach. A weak machine will only get its fair 50 after the time it would normally take to generate a coin. If every last bitcoin user joined in on a network bitcoins would tick in at a and even rate still giving GPU and server farms more coins then the rest but allowing CPU users to get a bit of coins before they die.
I truly hope there wont be a competition with the pooled mining teams and that the server doesn't start taking fees.

13NuAQaChtoTgvX8J68Zjy4AUR6hhugpXM Donations for anything and everything.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If society abolishes adventure the only adventure left is to abolish society.
da2ce7
Legendary
*
Offline Offline

Activity: 1218


Live and Let Live


View Profile
November 30, 2010, 05:46:15 AM
 #44

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.

One off NP-Hard.
bober182
Full Member
***
Offline Offline

Activity: 196

127.0.0.1


View Profile
November 30, 2010, 05:53:51 AM
 #45

Can someone edit the first post to include the server IP so we can all join in this.
Also if the IP owner doesn't want to keep running it I will see if I can take over. Does This app work with domains instead of IPs?

13NuAQaChtoTgvX8J68Zjy4AUR6hhugpXM Donations for anything and everything.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If society abolishes adventure the only adventure left is to abolish society.
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
November 30, 2010, 08:48:53 AM
 #46

Can someone edit the first post to include the server IP so we can all join in this.
Also if the IP owner doesn't want to keep running it I will see if I can take over. Does This app work with domains instead of IPs?

I'm fine with keeping it running. It runs on a VPS which isn't doing much else. I'll be monitoring the CPU usage and bandwidth but it looks like it doesn't use much.
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
November 30, 2010, 09:25:06 AM
 #47

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?
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
December 01, 2010, 09:11:43 AM
 #48

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: http://bitcointalk.org/index.php?topic=2027.0
puddinpop
Member
**
Offline Offline

Activity: 103


View Profile
December 01, 2010, 10:40:48 PM
 #49

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
*
Offline Offline

Activity: 1078


View Profile
December 01, 2010, 11:47:09 PM
 #50

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!
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
December 01, 2010, 11:59:11 PM
 #51

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.

bober182
Full Member
***
Offline Offline

Activity: 196

127.0.0.1


View Profile
December 02, 2010, 12:36:49 AM
 #52

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.

13NuAQaChtoTgvX8J68Zjy4AUR6hhugpXM Donations for anything and everything.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If society abolishes adventure the only adventure left is to abolish society.
puddinpop
Member
**
Offline Offline

Activity: 103


View Profile
December 02, 2010, 11:12:19 PM
 #53

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
***
Offline Offline

Activity: 196

127.0.0.1


View Profile
December 02, 2010, 11:14:58 PM
 #54

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.

13NuAQaChtoTgvX8J68Zjy4AUR6hhugpXM Donations for anything and everything.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If society abolishes adventure the only adventure left is to abolish society.
puddinpop
Member
**
Offline Offline

Activity: 103


View Profile
December 02, 2010, 11:23:20 PM
 #55

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
***
Offline Offline

Activity: 196

127.0.0.1


View Profile
December 02, 2010, 11:27:34 PM
 #56

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.

13NuAQaChtoTgvX8J68Zjy4AUR6hhugpXM Donations for anything and everything.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If society abolishes adventure the only adventure left is to abolish society.
BitLex
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
December 02, 2010, 11:32:01 PM
 #57

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.

puddinpop
Member
**
Offline Offline

Activity: 103


View Profile
December 02, 2010, 11:43:32 PM
 #58

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.

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.

puddinpop
Member
**
Offline Offline

Activity: 103


View Profile
December 02, 2010, 11:56:29 PM
 #59

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.

doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
December 03, 2010, 04:30:26 AM
 #60

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.

Pages: « 1 2 [3] 4 5 6 7 8 9 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!