Bitcoin Forum
December 10, 2016, 01:13:11 AM *
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 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »
  Print  
Author Topic: p2pool - Decentralized, Absolutely DoS-Proof, Pool Hopping-Proof Pool [archival]  (Read 31740 times)
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
June 28, 2011, 02:47:53 PM
 #21

What miner are you using? It seems to be submitting shares with a fixed difficulty of 1 rather than paying attention to the 'target' in the getwork message, in which case frequent messages like this would be normal.

I'm working on a successor to p2pool that is completely decentralized. I'd recommend not trying to use p2pool as it is now; technically it's fine - there network is up and I'm mining on it, but it probably won't generate a block before I finish the successor. Also, accordingly, the SVN repo is in flux; if you still want to use p2pool, use the released version.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481332391
Hero Member
*
Offline Offline

Posts: 1481332391

View Profile Personal Message (Offline)

Ignore
1481332391
Reply with quote  #2

1481332391
Report to moderator
Shevek
Sr. Member
****
Offline Offline

Activity: 252



View Profile
June 29, 2011, 07:56:44 AM
 #22

What miner are you using? It seems to be submitting shares with a fixed difficulty of 1 rather than paying attention to the 'target' in the getwork message, in which case frequent messages like this would be normal.

cpuminer

I'm using a toy miner on p2pool, only for testing purposes.

I'm working on a successor to p2pool that is completely decentralized. I'd recommend not trying to use p2pool as it is now; technically it's fine - there network is up and I'm mining on it, but it probably won't generate a block before I finish the successor. Also, accordingly, the SVN repo is in flux; if you still want to use p2pool, use the released version.

p2pool is a great idea! I bet it will sometime implemented naturally on bitcoin client because it is the p2p-way to mine, as the whole bitcoin project is. Go on!

So I'll follow your advice and I'll get fresh versions from SVN for my tests.

Proposals for improving bitcoin are like asses: everybody has one
1SheveKuPHpzpLqSvPSavik9wnC51voBa
iopq
Hero Member
*****
Offline Offline

Activity: 644


View Profile
June 30, 2011, 03:10:33 AM
 #23


p2pool is a great idea! I bet it will sometime implemented naturally on bitcoin client because it is the p2p-way to mine, as the whole bitcoin project is. Go on!

there should be a more general solution where you join a network and then the bitcoins get distributed by the client itself somehow without any kind of operator
in fact this should be done with the bitcoin network somehow

Un zafado cualquiera
Full Member
***
Offline Offline

Activity: 159


aquí dice algo personal.


View Profile
June 30, 2011, 04:54:27 AM
 #24

maybe if you create a token which find another ones maybe you can do a solution but I don't know how it can be done. If you can get a a selectable group of decentralized miners...It can be a way.
huayra.agera
Full Member
***
Offline Offline

Activity: 154



View Profile
June 30, 2011, 10:02:26 AM
 #25

Having this integrated with the BitCoin client would be very nice and I strongly agree that this should have been the mining process all along.

BTC: 1JMPScxohom4MXy9X1Vgj8AGwcHjT8XTuy
hawks5999
Full Member
***
Offline Offline

Activity: 168



View Profile WWW
July 01, 2011, 12:00:59 AM
 #26

Having this integrated with the BitCoin client would be very nice and I strongly agree that this should have been the mining process all along.

So I'm just trying to understand the implication of this:

If, let's say, I have 1 Gh/s of mining the current network hashrate is: 11148 GH/s. Is the suggestion that every time a block is found (every ~10 minutes) that I would get 1/11148 of 50BTC (or 0.00448511) every ~10 minutes?


■ ▄▄▄
■ ███
■ ■  ■               
LEDGER  WALLET    ████
■■■ ORDER NOW! ■■■
              LEDGER WALLET
Smartcard security for your BTCitcoins
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
Decentralized. Open. Secure.
Un zafado cualquiera
Full Member
***
Offline Offline

Activity: 159


aquí dice algo personal.


View Profile
July 01, 2011, 12:58:38 AM
 #27


If, let's say, I have 1 Gh/s of mining the current network hashrate is: 11148 GH/s. Is the suggestion that every time a block is found (every ~10 minutes) that I would get 1/11148 of 50BTC (or 0.00448511) every ~10 minutes?



Probably that is the case
huayra.agera
Full Member
***
Offline Offline

Activity: 154



View Profile
July 01, 2011, 09:23:28 AM
 #28

Any updates on the successor so that we can try it out? Thanks!

BTC: 1JMPScxohom4MXy9X1Vgj8AGwcHjT8XTuy
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
July 04, 2011, 09:42:30 AM
 #29

Working on it - I've pretty much completely formulated the 'plan', and I'm now beginning updating the code.

I've been on vacation since the day after the initial release, so I haven't had much time to code (though I've had lots of time to think!).

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
Shevek
Sr. Member
****
Offline Offline

Activity: 252



View Profile
July 04, 2011, 11:39:46 AM
 #30

Working on it - I've pretty much completely formulated the 'plan', and I'm now beginning updating the code.

I've been on vacation since the day after the initial release, so I haven't had much time to code (though I've had lots of time to think!).

Nice news! Recently I've SVN-loaded the code and some errors appeared when miner is on.

I'll wait until you say it is ready for re-testing.

Proposals for improving bitcoin are like asses: everybody has one
1SheveKuPHpzpLqSvPSavik9wnC51voBa
GimEEE
Member
**
Offline Offline

Activity: 112

Ride or Die


View Profile WWW
July 04, 2011, 04:11:17 PM
 #31

About the first point : okay, I didn't consider that. This pool is still not very scalable though (even if it represents 10% of the network, that's 1 share every 10 seconds).
About the second point : seems complicated. How about simply putting the 599 previous shares in every found share, and when one is a "winner", pay all the previous 599 shares ? Regardless whether they are from a previous block or not. This is much simpler, allows complete decentralization and still pool-hop resistant.
Brilliant plan!
1) Totally decentralized
2) Each client can pick the Factor (ease factor) {F} from 1 = no sharing (they keep the whole blockreward), up to an arbitrary maximum of 600 (integer only).
3) Clients will only share work history with other clients set to the SAME ease factor (as normal BTC client does) and building a chain of addresses up to {F} length (older address/submissions are dropped after normal btc chain confirms the new ones are validly added, maybe 12 rounds of normal btc chain adds) This will allow picking which network to work in based on your own variables and hopefully there will be some stats on the different networks block history to help choose where to start.
4) If blocks are added too quickly, client can be set to automatically lower the ease Factor (go to {F} = {F} - 1), so every time the network gets to be at the critical size, it automatically slows down the fastest miners. I'd suggest 10 minutes as the target time for submitting blocks across each {F} network as a whole, and no single miner on each {F} network is allowed to submit 2 blocks in 10 minutes, unless the second is a winning block. So if a client would submit 2 in 10 minutes, instead it lowers down {F} factor.
5) blocks are based off the current or previous main BTC blocks, so if work is submitted promptly, it must be included by the other miners onto the p2p block chain, with minimal stale blocks. It will use a similar check for adding blocks as the main client, with the added check of comparing the work to main client (current or previous round).
6) If a winning block is found before {F} blocks were submitted, the winner keeps the extra shares.


EXAMPLE:
At F = 600, XXX miners connect and mine fast, building the speed up to submit shares every 10 minutes. blocks are created, adding to the chain. at 400 chain length, the next block is a winner, giving winner 1/3 of reward (credit for blocks 1-199 & 600 -or- 1 & 402-600, depending how you count it), and the previous 400 submitters get rewarded for each block they added (200-599)
After blocks are found faster, maybe if 100 blocks were added in last hour, triggers the split for all clients set to auto lower {F} - all client set to auto adjust go to (or create if necessary) a new network.
Also, Any clients that find 2 blocks per 10 minutes will do the same. Being the first miners on any {F} will be just as good as being a later miner, allowing them to add blocks and start the chain, to eventually get all the shares contributed.
On long rounds, the earliest shares contributed will not get rewarded, but that's a drawback for not contributing shares continuously.

The only way to make sure people you agree with can speak is to support the rights of people you don't agree with.
carbonc
Member
**
Offline Offline

Activity: 104


View Profile
July 06, 2011, 01:20:17 AM
 #32

I majorly support this project.

once I get some coins I will try to donate what the wife doesn't bleed out of me.
Un zafado cualquiera
Full Member
***
Offline Offline

Activity: 159


aquí dice algo personal.


View Profile
July 06, 2011, 01:33:04 PM
 #33

Please post a TODO list
hashcoin
Full Member
***
Offline Offline

Activity: 122


View Profile
July 06, 2011, 02:20:44 PM
 #34

Keeping track of the last 600 shares in a distributed environment seems hard.  Let me suggest an alternative for you that seems much simpler, and in fact I came up with specifically to design a decentralized pool:

http://forum.bitcoin.org/index.php?topic=25540.0

noone in that thread understood it, but hopefully as a programmer it should be clear to you.  The idea is simple: just auction the block reward to the N highest bidders, where a "bid" is a share and "high" means "low hash".
Boing7898
Sr. Member
****
Offline Offline

Activity: 266


View Profile
July 07, 2011, 08:44:28 AM
 #35

This is hard to make as a P2P botnet  Grin
Can't wait to try this Cheesy

Ohai.
GRC: FtWgehaapGH5cKSmMPEH91sVzxLUioNZ3s
GimEEE
Member
**
Offline Offline

Activity: 112

Ride or Die


View Profile WWW
July 07, 2011, 06:27:18 PM
 #36

Keeping track of the last 600 shares in a distributed environment seems hard.  Let me suggest an alternative for you that seems much simpler, and in fact I came up with specifically to design a decentralized pool:
http://forum.bitcoin.org/index.php?topic=25540.0
noone in that thread understood it, but hopefully as a programmer it should be clear to you.  The idea is simple: just auction the block reward to the N highest bidders, where a "bid" is a share and "high" means "low hash".
Your method there is rather askew from the standard btc client and mining protocol, no?

The only way to make sure people you agree with can speak is to support the rights of people you don't agree with.
nanotube
Hero Member
*****
Offline Offline

Activity: 485


View Profile WWW
July 10, 2011, 02:08:12 AM
 #37

hi,
see also: http://forum.bitcoin.org/index.php?topic=27216.0

Join #bitcoin-market on freenode for real-time market updates.
Join #bitcoin-otc - an over-the-counter trading market. http://bitcoin-otc.com
OTC web of trust: http://bitcoin-otc.com/trust.php
My trust rating: http://bitcoin-otc.com/viewratingdetail.php?nick=nanotube
Litt
Sr. Member
****
Offline Offline

Activity: 350


View Profile
July 10, 2011, 06:08:47 PM
 #38

this is definitely a step in the right direction and I will be watching this closely. We need to always always thinks of new ways to decentralize.
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
July 10, 2011, 06:31:40 PM
 #39

I'm back and I've resumed full time work on this. Smiley Watch SVN if you're interested...

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
Shevek
Sr. Member
****
Offline Offline

Activity: 252



View Profile
July 11, 2011, 09:24:00 AM
 #40

I'm back and I've resumed full time work on this. Smiley Watch SVN if you're interested...

Is the last revision usable? I've tried it but crashes:

Code:
Fatal error:
Traceback (most recent call last):
  File "/home/shevek/bitcoin/p2pool/p2pool/main.py", line 188, in main
    tracker = p2pool.Tracker()
TypeError: __init__() takes exactly 2 arguments (1 given)

Proposals for improving bitcoin are like asses: everybody has one
1SheveKuPHpzpLqSvPSavik9wnC51voBa
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »
  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!