[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[yslyung]

Just translating p2pool as it exists into C, C++, C#, Objective C, Swift, Java, Perl, Lisp, whatever, is not going to suddenly bring the mining masses here.  I know a number of us have listed out the problems previously, and a number of us have had discussions on potential solutions to those problems; however, nobody has been able to successfully crack the nut.  Maybe the problem is that we're all trying to solve p2pool's problems while keeping ourselves in the context of the existing structure.  Let's try another approach.  Forget p2pool even exists.

We as a community want a new pool to be created.  Here is a list of high-level bullet points we would want to have in our new pool:

• Decentralized
• Easy to use
• Performant
• Scalable
• Inclusive

Please feel free to add to these points and/or provide more details/solutions.

This is exactly what I'm suggesting JB - a complete re-write. But in order to achieve this I think we should do the donation bounty option from within the current p2pool structure, as it's (I think) an excellent way of raising awareness in the community as well as raising funds, while the amount of work involved in making the changes are minimal & simple.

To accomplish that, we'll need somebody to fork the p2pool code and change the donation function to point to a community agreed upon address.  Then we'll need everyone to download and use that new fork, in addition to every node starting up with donations set - assuming we keep it the same and make the donation optional.

So...

1) Who wants to fork the code and write?
2) Who do we make the keepers of the honey pot?

vote for raven to rewrite the donation addy
keeper windpath

[1713555749]

1713555749

[1713555749]

1713555749

[1713555749]

1713555749

[windpath]

Just translating p2pool as it exists into C, C++, C#, Objective C, Swift, Java, Perl, Lisp, whatever, is not going to suddenly bring the mining masses here.  I know a number of us have listed out the problems previously, and a number of us have had discussions on potential solutions to those problems; however, nobody has been able to successfully crack the nut.  Maybe the problem is that we're all trying to solve p2pool's problems while keeping ourselves in the context of the existing structure.  Let's try another approach.  Forget p2pool even exists.

We as a community want a new pool to be created.  Here is a list of high-level bullet points we would want to have in our new pool:

• Decentralized
• Easy to use
• Performant
• Scalable
• Inclusive

Please feel free to add to these points and/or provide more details/solutions.

This is exactly what I'm suggesting JB - a complete re-write. But in order to achieve this I think we should do the donation bounty option from within the current p2pool structure, as it's (I think) an excellent way of raising awareness in the community as well as raising funds, while the amount of work involved in making the changes are minimal & simple.

To accomplish that, we'll need somebody to fork the p2pool code and change the donation function to point to a community agreed upon address.  Then we'll need everyone to download and use that new fork, in addition to every node starting up with donations set - assuming we keep it the same and make the donation optional.

So...

1) Who wants to fork the code and write?
2) Who do we make the keepers of the honey pot?

vote for raven to rewrite the donation addy
keeper windpath

For something like this, where the coins could be sitting around a long time I'd propose maybe a 3 of 5 multisig, I'd be willing to be 1 of the 5...

Still have to define the criteria for success.

Also, I'm unable to decode Forrest's donation script, I'm sure there is someone who could, anyone want to give it a try?

Here is what I get from python command line, obviously not a pub key hash:

Code:

^??7?Jn?Kdѳ?D2?ه??2Vxk??)2?#÷M???Z?U)5&VfK?

Here is the script:

Code:

DONATION_SCRIPT = '4104ffd03de44a6e11b9917f3a29f9443283d9871c9d743ef30d5eddcd37094b64d1b3d8090496b53256786bf5c82932ec23c3b74d9f05a6f95a8b5529352656664bac'.decode('hex')

I believe the (intentional) complexities of this script are what causes blockchain.info to flag p2pool generation TXs as potential double spends...

[IYFTech]

As I suggested earlier, I think a minimum of 3 multi-signatories who should be trusted legendary members - and would like to suggest Ognasty as one of them, as he is also a p2pool user.

I'm no coder I'm afraid, so can't help out with the donation adjustment - maybe ck/kano can decipher it? We will also need someone to look after the git page of course, as well as the new p2pool thread. I'm not sure how JB would feel about this? He has the gift of words & how to lay them down..... This whole deal will require a massive amount of PR both here & on other outlets/forums in order to educate & persuade all node users to switch over to the honeypot'd code, so care should be taken to make sure everything is in place & ready.

There is much to do - but at least we are doing something. I like it. 

[rav3n_pl]

Wait, did I miss somewhere fact, that Forrestv abandoned project?

[rav3n_pl]

Here is what I get from python command line, obviously not a pub key hash:

Code:

^??7?Jn?Kdѳ?D2?ه??2Vxk??)2?#÷M???Z?U)5&VfK?

Here is the script:

Code:

DONATION_SCRIPT = '4104ffd03de44a6e11b9917f3a29f9443283d9871c9d743ef30d5eddcd37094b64d1b3d8090496b53256786bf5c82932ec23c3b74d9f05a6f95a8b5529352656664bac'.decode('hex')

I believe the (intentional) complexities of this script are what causes blockchain.info to flag p2pool generation TXs as potential double spends...

Simple:

Code:

rav3n@bitrav3n:~$ bitcoin-cli decodescript '4104ffd03de44a6e11b9917f3a29f9443283d9871c9d743ef30d5eddcd37094b64d1b3d8090496b53256786bf5c82932ec23c3b74d9f05a6f95a8b5529352656664bac'
{
    "asm" : "04ffd03de44a6e11b9917f3a29f9443283d9871c9d743ef30d5eddcd37094b64d1b3d8090496b53256786bf5c82932ec23c3b74d9f05a6f95a8b5529352656664b OP_CHECKSIG",
    "reqSigs" : 1,
    "type" : "pubkey",
    "addresses" : [
        "1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4"
    ],
    "p2sh" : "3HW5FVVo3TpKD1rPpsHX2VeJNmfE4Lqe91"
}

[windpath]

Wait, did I miss somewhere fact, that Forrestv abandoned project?

No, I don't believe he has.

This is an attempt to create an incentive for someone to come up with a solution to the scalability issues.

Perhaps if the pot got big enough Forrest would focus back on P2Pool, and I for one would be ecstatic if he figured it out and claimed the bounty.

I don't fault him at all for not being active, he is young and has other interests, P2Pool has represented an enormous contribution and I am grateful for all his work.

Since virtually no one I'm aware of pays the donation this could be an opportunity to create an incentive that gets work moving again.

We still need to define the criteria for success very clearly before we can start thinking about setting up a pot though...

[Meuh6879]

the problem of P2Pool is that you must have a dedicate PC to run bitcoin core server mode and P2Pool client (or server).
with the only ethernet autonomous miner bitcoin, the miners don't want a complex point-of-connexion to mine.

that's why new pool from manufactured miner device are a success.

P2Pool is good for an emergency system in my sense.
I trust and believe in P2Pool ... but i'm not the one that have 700TH/s in power  

[K1773R]

Wait, did I miss somewhere fact, that Forrestv abandoned project?

No, I don't believe he has.

This is an attempt to create an incentive for someone to come up with a solution to the scalability issues.

Perhaps if the pot got big enough Forrest would focus back on P2Pool, and I for one would be ecstatic if he figured it out and claimed the bounty.

I don't fault him at all for not being active, he is young and has other interests, P2Pool has represented an enormous contribution and I am grateful for all his work.

Since virtually no one I'm aware of pays the donation this could be an opportunity to create an incentive that gets work moving again.

We still need to define the criteria for success very clearly before we can start thinking about setting up a pot though...

ah, really?
https://bitcointalk.org/index.php?topic=329860.msg3537926#msg3537926
forrestv said he will take onto those problems... nothing more to say.

[windpath]

Wait, did I miss somewhere fact, that Forrestv abandoned project?

No, I don't believe he has.

This is an attempt to create an incentive for someone to come up with a solution to the scalability issues.

Perhaps if the pot got big enough Forrest would focus back on P2Pool, and I for one would be ecstatic if he figured it out and claimed the bounty.

I don't fault him at all for not being active, he is young and has other interests, P2Pool has represented an enormous contribution and I am grateful for all his work.

Since virtually no one I'm aware of pays the donation this could be an opportunity to create an incentive that gets work moving again.

We still need to define the criteria for success very clearly before we can start thinking about setting up a pot though...

ah, really?
https://bitcointalk.org/index.php?topic=329860.msg3537926#msg3537926
forrestv said he will take onto those problems... nothing more to say.

Yes, unfortunately he took the 2k from the Litecoin devs in November 2013 and has not yet come up with a solution...

[windpath]

I know a bunch of us have nodes in the northeast US...

Anyone planning on attending the MIT Bitcoin Expo this coming weekend?

I'll be there and would love to meet some of you folks face to face (perhaps over a cocktail or 3)

http://mitbitcoinexpo.org/

Tix are $175 for non students, impressive lineup of speakers...

[TheAnalogKid]

So, here's an oddball suggestion to re-think P2Pool.

Does the mining itself really have to be distributed?  What if we all "solo-mined", but then pooled together the solved block income and then just distributed the income amongst all miners recorded as having done work?

It would be a centralized, de-centralized pool.  Follow me on this...

First, why re-invent the wheel and try to rewrite the P2Pool code?  We know the inherent issues with it and it seems that most agree it is a daunting, if insurmountable, task given the time required to do so and the lack of the most important thing - money - to provide the incentive.

It would seem to me to be a much better use of resources to find things that could be leveraged together that already exist, and just contract those to write the needed subsequent "glue" bits to make it all work.

I've been mining on Nastypool, with the NastyPoP payout method, and this is what gave me the idea.

Why not use the CKpool/CKDB solo method, and have everyone currently running a P2Pool node setup their own CKPool solo nodes.  Miners connect to them and it would be pretty much normal solo mining, without the issues of ever increasing share difficulty.  Latency would be no longer an issue, because you're not racing each other and the other nodes to get your shares in the chain faster, you could mine wherever and have more of your work count, instead of being DOA.

Then, at the top level, here's the code that would need to be implemented - the ability to catalog and share the information about each miner on each node, the amount of work they're doing, and finally the blocks that are solved.

From that info, you could run periodic payouts for all miners (maybe weekly, every 3 or 5 days, whatever) based upon all the pooled BTC from all the blocks and transactions solved during that period.

You could implement a 3 of 5 majority (5 of 7, whatever of whatever), where trusted stakeholders (windpath, CK/Kano, etc) run the major nodes which form a distributed cluster of the main information store.  You could also have one entity hold the "hot" wallet containing that rounds' BTC, and payout the distributions. 

The resources for pool nodes and onwers would be less, since you'd probably need to only replicate database transactions now, instead of full sharechains, etc.
The CKpool code is written in C/C++ and is performant and scalable, something which P2Pool will never be.

If the theory of luck and variance holds true, where over time an amount of hashrate will still solve the same amount of blocks, it shouldn't matter whether you're solo mining with 200GH/s, or 200TH/s, over time you'll still get the same payout.  Even if your miner never solved a block on your own solo node, you'd still get equal payouts from the nodes who did solve them.

If you leave the 0.9% (or even round it up to 1.0%) fee in there like CK/Kano have for their pool, it allows money to flow back to the developers who are spending their time writing and maintaining this.  If you do round it up to 1.0%, maybe that 0.1% could be re-distributed to those running a pool node, as a thank you for the services.  As much as I like 0 fee, it really doesn't draw people in anymore - I see pools with 4% fees running with miners on them, because they offer a gamble at something.

I don't know, just tossing the idea out there.  Might be completely stupid and unfeasible, but honestly at this point I think P2Pool's days are numbered without finding a solution, and it'll probably have to be pretty radical for it to work.

[Gws24]

You could implement a 3 of 5 majority (5 of 7, whatever of whatever), where trusted stakeholders (windpath, CK/Kano, etc) run the major nodes which form a distributed cluster of the main information store.  You could also have one entity hold the "hot" wallet containing that rounds' BTC, and payout the distributions.

And that is centralization and imho unwanted.

[TheAnalogKid]

You could implement a 3 of 5 majority (5 of 7, whatever of whatever), where trusted stakeholders (windpath, CK/Kano, etc) run the major nodes which form a distributed cluster of the main information store.  You could also have one entity hold the "hot" wallet containing that rounds' BTC, and payout the distributions.

And that is centralization and imho unwanted.

Then build the code so that every node keeps that information store, instead of just 3 or however many, and then it's not centralized.  99% of the nodes could then drop off and as long as one is running you're still good.

The biggest hurdle is the "caretaker" of the wallet holding the BTC during the current "round", or don't have the concept of a round, and continue to use immediate PPLNS payouts to worker addresses.  Then you're also not centralized there either.

[yslyung]

p2pool is 0 fees & it does sounds centralised

[windpath]

I've been thinking about this for a while with decentralized and trust-less at the top of my list.

I think a solution based on serial micro-payments (or similar) makes more sense and will protect the trust-less decentralized nature of P2Pool.

Today I saw this video, it's "Lecture 3 - Mechanics of Bitcoin" from the Princeton University course, the link starts at 34:30 where he starts to talk about serial micro-payments.

His example is for by the minute telephone billing, it's not the actual solution for P2Pool, but pretty close (I hope)

If you watch, in his example, replace Alice with P2Pool and Bob with a miner...

https://www.youtube.com/watch?v=t3hJsFpPmXs&feature=youtu.be&t=34m30s

I guess my first question is can anyone tell me why something like this would not work?

[TheAnalogKid]

I guess my first question is can anyone tell me why something like this would not work?

Not sure how micropayments are connected to the core problems of P2Pool being the performance/scalability and the relativity of higher hashrate to larger share diffs.

Unless it's in reference to what was said before, the ability to "credit" smaller miners for work they have completed which may have fallen off the chain because there's been no block in more than 3 days.

[Chupacabras]

I've been thinking about this for a while with decentralized and trust-less at the top of my list.

I think a solution based on serial micro-payments (or similar) makes more sense and will protect the trust-less decentralized nature of P2Pool.

Today I saw this video, it's "Lecture 3 - Mechanics of Bitcoin" from the Princeton University course, the link starts at 34:30 where he starts to talk about serial micro-payments.

His example is for by the minute telephone billing, it's not the actual solution for P2Pool, but pretty close (I hope)

If you watch, in his example, replace Alice with P2Pool and Bob with a miner...

https://www.youtube.com/watch?v=t3hJsFpPmXs&feature=youtu.be&t=34m30s

I guess my first question is can anyone tell me why something like this would not work?

Good info. Thanks.

[kano]

I guess my first question is can anyone tell me why something like this would not work?

Not sure how micropayments are connected to the core problems of P2Pool being the performance/scalability and the relativity of higher hashrate to larger share diffs.

Unless it's in reference to what was said before, the ability to "credit" smaller miners for work they have completed which may have fallen off the chain because there's been no block in more than 3 days.

Both are unrelated to a solution.

P2pool already does effectively do micropayments, though there is an issue with that already in that a small miner will get lots of tiny payouts that will then require more in transaction fee to spend them than the amount of the payouts ...

As for falling off the end of the chain, well that's a two fold issue.
Firstly, if you want to have a higher % of paid shares, you simply increase the size of the chain.
However, at the moment, the % of paid shares is already so high, I'd not understand why anyone would want to increase that ... due to the problem of:
The larger the chain, the larger the block coinbase transaction will be and the smaller the average size of the 'micropayments'

Edit: and just to throw an issue into the basket that same may not notice (but I consider obvious )
The bitcoin developers are effectively against p2pool since they are against micropayments.
They make comments about small transactions and large fees compared to those small transactions and how small transaction are SPAM (yeah there's a very vocal moron on the subject of SPAM)
If you watch the bitcoin debug.log of the standard bitcoind (not the abortion that moron hides changes in) you will see it spitting out comments about dust transactions and ignoring them all the time ...
Any design of p2pool that supports smaller miners or smaller payouts is directly in contrast with that unless there is some separate store of the smaller shares/payouts to be 'banked' and then paid out once they exceed some consensual limit.
The 'banking' is the issue, since the current design uses the coinbase txn as the distributed bank proof - but you can't go throwing the unpaid part of the bank in there ...

Edit2: and then to add in some possibly useful information
If you look at how a normal pool works, you see related hints on how to solve some of the problems.
An example would be large vs small miners.
A normal (good) pool adjusts the share rate to be X shares per minute based on the miner rate.
Maybe p2pool could consider some (more complex) version of that in the share chain to force miners to use a diff related to their hash rate and thus allow smaller miners to reduce their variance.
Of course it has the problem of abuse by larger miners splitting up their 'farm' to multiple addresses and thus acting like multiple smaller miners - so that would have to be resolved some way I've got no idea how

[windpath]

The bitcoin developers are effectively against p2pool since they are against micropayments.

Yes, I'm cherry picking the quote to respond to, and the rest I will get back with you on later, but this statement simply is not fair or true.

The smallest paid share in the p2pool share chain is currently (right now) 0.00108623 BTC ($0.27).

This hardly represents what most would consider a micro-payment, its over a quarter USD (not a couple pennies, or fractions there of).

Here is an (older) quote from a dev:

“I think P2Pool makes mining fun again.” -gmaxwell, Bitcoin Core Developer

And I would agree, it does.

TL;DR: Core dev's have nothing against, and in fact support decentralization and trust-less mining pools...

And my thought, is that serial micro-payments will actually reduce smaller payouts....

Lets say the smallest miner on the pool should be able to earn a single bit per block (0.00000100, 100 Satoshi))

The way I see them working:

Let say a miner starts on the pool with 1 TH/s.

Lets further assume that the payout is around .001 BTC per block found (for the sake of argument).

This miner opts-in to the serial micro-payment structure by setting up his multi-sig, a 2 of 2, 1 key signed by the pool on block generation, and 1 signed by him to spend.

If the miner does not spend the previous payouts they are included in the next block the pool finds, along with the .001 from the current block, effectively now a .002 payout (creating a potential double spend of an unspent multi-sig tx).

However since the first found blocks coins never got the second sig, the coins are not spent and are still available in a trust-less way.

This miner goes on to have a payout of .001 per block found, without ever signing the 2nd key for the payout, that only the miner has, and the payouts accrue over time, lets say for 10 blocks...

On the 10th block found the miner decides that .01 (10*.001) is enough to justify a payout and signs the 10th round of the .001 payout block transactions (that accrue), resulting in a payout of .01 (instead of 10 payouts of .001) to the address they specified when they set up the multi-sig and the accrued txs are all signed at once reducing tx fees.

This is grossly simplified, and I'm still wrapping my head around how to explain it, but I feel like I'm onto something.

If anyone gets it and thinks it might work, or has other holes to poke please do....


Edit: watch the video to get a feel for how serial multi-sig works:

If you watch, in his example, replace Alice with P2Pool and Bob with a miner...

https://www.youtube.com/watch?v=t3hJsFpPmXs&feature=youtu.be&t=34m30s

[norgan]

ok I'm having a brainfart or something has changed in the config.

installed bitcoind 0.10.0 with existing bitcoin.conf from 0.9. Ran p2pool and get 401 authorization required.

Code:

C:\p2pool\run_p2pool.py -a 1MinerGcfwXJW6BETKLPQTmKYomc1uGAXy --bitcoind-config-path C:\D Drive\Bitcoin\bitcoin.conf -n 59.167.237.19:9333 -n 115.70.176.17:9333 -n 203.219.14.204:9333 --max-conns 30 --give-author 0 --iocp --irc-announce 
pause

Do we have to specify the password now or something?