Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 202. (Read 2591920 times)

Can't see why one would bail: Luck is luck, if the pool has some time without blocks there will be time with blocks. This is the same for Slush, Eclipse, Eligius, BTC50, and whatever other pool you decide to use. It's basic statistics, you will not get a better deal anywhere else because there *is* no better deal.

There are however worse deals :-)

P2Pool is distributed, with no central place that a govt can choke. That's why I like it and why I'll stick with it as is.

Mine on!

+1

I've only been using it for backup for a while now. My node has been running regardless but I am seriously considering not even bothering and just run a bitcoin node on it for the networks sake.

I moved mine this past weekend for the same reasons. Stuck with it as long as I could. I will continue to check in to see about any progress for the future.

Very understandable as I moved mine already and all the hash I rented has been worthless. Stick a fork in me as I am done.

Well, I'm sorry to have to say that after using p2pool for nearly 3 years I am forced to move my hash away to a centralized pool. After over 2 years of trying to get some kind of development happening with p2pool without any success whatsoever, I really don't have any choice. The hash rate is falling daily, meaning soon even the suggestion made by IYFTech will not be viable, if it isn't already, due to lack of blocks being solved. Unless something is done NOW to get some kind of bounty organized, p2pool will be no more.

Time is running out ladies & gentlemen, good luck.

That's not entirely accurate... p2pool calculates share value based upon the weight of the share, which is directly affected by the share difficulty compared to the network minimum difficulty when the share was found.  You are paid for however many weighted shares you have on the payout list when the block is found.  There are far more miners on p2pool with less than 10TH/s than there are with more than that hash rate.  For example, I've got a single S3 that mines on p2pool at 440GH/s.  You can see my payouts over time for that rig.  As an example, the last block, that rig made 0.00996171BTC.

Not at all, currently 33 p2pool miners are < 1TH/s

The lowest payment on the last block was 0.00168945 BTC
i.e. 0.68% of the pool.
If the pool was 1.5PHs that's 10.2THs
Thus 1THs would be ~0.00017 BTC
As difficulty goes up, 1THs payout goes down ...

I take it you think that 1THs is too small to mine on p2pool?

If you were using something like 'rpcallowip=192.168.1.*' before, change it to 'rpcallowip=192.168.1.0/24' (or equivalent that suits your local network).

Ah! I thought I was going crazy. Do you recall off hand what the syntax is?

Edit: I wasn't using rpcallow before. Is it required now??

added: rpcallowip=::/0

and still getting 401.

rpcallowip format changed

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.


Do we have to specify the password now or something?
 

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:


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:

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

Good info. Thanks.

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.

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?

p2pool is 0 fees & it does sounds centralised