Topic: Payment Channel Payouts: An Idea for Improving P2Pool Scalability (Read 3450 times)

A way to reduce the liquidity requirement of hubs in lightning p2pool, potentially by three orders of magnitude. The first part of this post briefly summarizes the original lightning p2pool proposal in a slightly new way, the second part introduces this new idea.


The original proposal had this as the script of the coinbase output.


Control of the coinbase is divided, between the hub and the successful hasher, in a complicated way.

In the case where everyone cooperates, branch (1) is used to send the coinbase to the hub. (But only after the hub has sent all the hashers the correct amount of money according to the state of the sharechain)

The successful hasher could defect, either by becoming unresponsive or trying to hold the hub to ransom on a Mutually Assured Distruction (MAD) basis. To avoid that, branch (2) allows the hub to collect the money on its own. It must reveal the preimage X which allows every other hasher in p2pool to collect their rightfully-owed money.

The hub could also defect, by being unresponsive or holding the successful hasher to ransom via MAD. Branch (3) avoids this by providing a timeout (of 1 week in this example) after which the successful hasher can collect the entire coinbase. This punishes the hub, providing a disincentive to doing this.

Now, we remind ourselves of the Schnorr signature + taproot + MAST proposal, which will probably be added to bitcoin one day via a soft fork. Using Schnorr signatures it allows any N-of-N multisig to take up the same blockchain space as a single signature. MAST allows any syntax tree with N branches to be efficiently committed to, spending via one branch only requires log2(N) data to be added to the blockchain. Taproot is a way to combine Schnorr and MAST which avoids having to reveal any MAST merkle proof if it never gets used.

------

With all this mind, we propose another script of the coinbase output, this time with two hubs. The hubs have preimages X and Y. The "OR" statements are left out for readability, branches are numbered and successful hasher is abbreviated to SH. The hubs both periodically broadcast hash-locked channel updates, same as in the original proposal.

The proposed coinbase script for the situation with 2 hubs:


What we have is a branch covering every possible combination of cooperate and defect:

* Branch (1) is a 3-of-3 multisig for everyone cooperates, it is the most common situation.
* Branch (2) is when SH defects, it allows the two hubs to divide the money equally between them, but they must reveal the preimages so that every other hasher can get paid as well.
* Branches (3) and (4) are used when one hub defects, it allows SH and the other hub to take their money and punish the defecting hub by stealing it's money too.
* Branches (5) and (6) cover the situation where SH and one hub both defects, it allows the remaining hub to punish them the other hub and get the money (but it must reveal its preimage).
* Branch (7) covers the situation where both hubs defect, the SH punishes them both.

The most important branches are (1) and (2). In the vast majority of cases all the payment channels will be honestly updated and branch (1) will be used. All the other branches are required to make it impossible to hold anyone else to ransom via MAD. The OP_CHECKSEQUENCEVERIFY timeouts are staggered so at each step there is plenty of time to respond.

Branch (1) can be efficiently executed in a single Schnorr signature. All the other branches can be hidden in a MAST merkle tree, hidden in a taproot scheme.

This reduces the liquidity requirement because each hub only needs to own half a much bitcoins as before. Today's block reward is around 12.5 btc, under this idea each hub only needs to provide 6.125 btc. All the other incentives and procedures as the same as before.

--------

Next, let's extend the scheme to using 3 hubs. Each hub has preimages X, Y and Z. The coinbase script for that situation would be:


This is very similar to before. There are 15 branches now, most of which would be never executed and are hidden in MAST. Branches (1) and (2) are again the most important. As before, it's not possible for any entity or group of entities to hold anyone else to ransom via MAD. All the hubs can be punished if they misbehave. Each hub only needs to provide 3 times less liquidity as before.

If any branch but (1) is executed then the MAST proof size is only log2(15) = 4 hashes.

Left as an exercise to the reader, you can work out that with N hubs the number of branches for a similar scheme is 2^(N+1) - 1, which means the merkle proof for any branch except for (1) is of size N.

If we choose N = 10 to have 10 hubs, the most common branch (1) of the 10-of-10 multisig is still just the same size as a Schnorr single sig. For any other branch the merkle proof size is only 10 hashes. But each hub requires 10 times less liquidity.

If we choose N = 100 we have 100 hubs. As before, the branch (1) is just a single sig and each hub requires 100 times less liquidity.

We can also use the previous idea of using multiple coinbase outputs. We can have 10 coinbase outputs, each with N = 100 hubs, so that would be 1000 hubs altogether, each requiring 1000 times less liquidity than the original proposal.

1000 is more of a demonstration to show how well this scheme scales. In reality it would run up against other bottlenecks like the bandwidth requirement for all those channel updates.

Maybe an obvious point, but the successful hashers (successful grinders) can create multiple coinbase outputs to use multiple hubs, reducing the liquidity requirement of each hub.

An example of coinbase transactions paying to three hubs instead of one:


Using N coinbase outputs reduces the liquidity requirements of a hub by a factor of 1/N.

So if you chose N = 5, today's block reward of around 12.5 btc means each hub only needs to provide liquidity for a reward of 2.5 btc.

Each output only costs about 20 more bytes to create (and about the same to spend because of the segwit discount).

This is an easy way to have many more people being able to run these p2pool hubs. Because of pareto's principle, reducing requirements by 1/N means the number of additional people who own that many bitcoins is much more than a factor of N. (Note that hubs need to own around 50 times the block reward, so more than just 2.5 btc)

An interesting exchange with something familiar with mining in China

https://www.reddit.com/r/Bitcoin/comments/7wyq10/urgent_call_to_miners_mining_at_btccom_btccom_is/du4uoo1/?context=6

https://archive.is/Wt2FJ

So looks like a good p2pool selling point is fraud-resistance, since the pool cannot cheat the hashers out of their payments.

See the quote by this guy:



Right now anyone who wants to work on the idea in OP should just work on Lightning. The payment channels can be connected to Lightning so then hashers would be paid to their LN wallet with the funds available for spending immediately.




Maybe, I'd recommend fleshing this idea out more so it's easier to follow.

I remain unconvinced that segwit payment channels are necessary for an incremental improvement. You're welcome to believe in the God of Gaps, but code is written by people and unless you lock them in a hotel room and pay both the cleaning and writing bills (not to mention plumbing, electricity, faraday cage maintenance, etc), people write code slowly and generally pick the lowest-hanging fruit off the least-forbidding tree.

Why not just mine to a multisig of the smallest N miners, and leave them to coordinate between them how the payouts are distributed? This can start out as manual config mediated by a trusted Mth party, and evolve into all your payment channel voodoo wowee.

Many good and well researched points, you have convinced me.

This scenario would probably be one in which the capital cost of the miner itself is nearly zero. If the miner capital cost is high, then the miner needs to be run nearly 24/7 in order to make a profit. Currently, capital costs (or amortized depreciation, if you prefer) is the greatest cost in Bitcoin mining, and electricity costs are the second-greatest cost. I expect capital costs of miners will always be significant, but will probably eventually be slightly less than electricity costs. If you're only running your miners when the sun shines (8-12 hours a day), then those capital costs become much harder to recoup.

Utility-scale solar is probably going to always be cheaper than rooftop solar. As of Dec 2016, the cost (LCOE) of rooftop solar was about 3x higher than utility-scale solar ($0.05/kWh vs $0.15/kWh). If it ever makes sense to mine at home with rooftop solar, then it will probably make even more sense to mine in a warehouse in the middle of a desert where it's sunny 360 days out of the year. That said, solar has a long way to go before it can catch up to hydro, which is about $0.015 to $0.05/kWh with 24/7 uptime.

Solar power is great, but it is not very well suited to mining. It's better suited to supplying the grid and helping with peak load, since solar power peaks when demand peaks, rather than trying to supply a 24/7 load like mining. Wind is usually cheaper, and might make a better partner, but still not perfect. Ultimately, hydro, nuclear, or (ugh) fossil fuels are what make the most economic sense.

https://www.reddit.com/r/Bitcoin/comments/6y8305/if_pool_miners_run_segwit2x_they_get_a_better/dmmzl99/

At the moment and in the near future, you are certainly right, I'm not contending that.
In the longer term, I'm not fully convinced. It might hold even more true, that centralization has the strongest incentives. But there could also be decentralizing incentives, that would have an effect similar to a rebate or subsidy, for smaller operations. How large a share of the total hashrate that would amount to, I have no idea.

Imagine a future where mining efficiency increases are very slow, because maximum efficiency has almost been reached. Imagine also that solar power is the most efficient source for producing electricity.
The roofs of houses are unused area, that will make sense to have produce solar power in the future. The homeowners will have periods that produce excess electricity. They could sell it to the market, but since the production of solar power will be very correlated between different producers in the same area, the prices will plummet at exactly the times that you would want to sell it.
It would either have to go to waste, be stored in a battery, or used for something else. That something else could be bitcoin mining. The hardware and setup will cost money, and you have to have a positive return on investment, but since we are assuming advances in efficiency are very slow, you will have a long time to make that return.

There is also the scenario where you live in a cold climate, and your best option for heating your house is, in some way, converting electricity to heat. In that case, why not produce that heat using bitcoin miners? You would get money back on the electricity you pay for.

In case neither of those cases would be profitable, there is at least a subset of them that overlap. But that might be such a small contribution to the total hashrate that it would be negligible.

No, it won't be realistic for that. Mining equipment is already commoditized. In the longer run, we can expect marginal revenue to be much closer to marginal cost. Right now, an S9 earns around $0.60/kWh, so electricity costs don't really matter much. However, people will continue to buy mining hardware as fast as it is produced until revenue equals about $0.08/kWh-$0.10/kWh. We've been at that revenue level a few times before, but the BTC exchange rate increases have recently outstripped manufacturers' ability to keep up with demand, so difficulty adjustments have been slow.

If your house has cheap electricity (e.g. Seattle), you might pay $0.07/kWh, and make a net (assuming no other costs like cooling) of $0.01 to $0.03/kWh. On the other hand, industrial miners like me will be paying $0.03/kWh, and will make a net of $0.05 to $0.07/kWh. My electricity is cheaper than solar and is online 24/7. People like me will be netting between 2.3x and 5.0x as much as home miners. When that happens, home miners will be unable to make a full return on their investment, but industrial miners like me will still be raking in the money.

And that's without even talking about the economies of scale in setting up a datacenter. When you are building your capacity for hundreds or thousands of miners at a time, it takes a lot less time and equipment per miner to build and maintain the infrastructure.

Industrialized mining can be a lot more decentralized than current pooled mining is. I have an industrial-scale facility, for example (1.2 PH/s on Bitcoin), and yet my hashrate is only about 1/5,000th of Bitcoin's total hashrate. If we could get more (or most?) industrial Bitcoin farms to use p2pool, we could help a lot with the mining centralization issue.

But let's not blindly chase the home mining dream, please. That dream died in 2014. And let's not pretend that writing code to make small payouts possible is going to suddenly create demand for small payouts and revitalize home mining.

In the longer run, when miner efficency improvements are marginal and mining equipment is commoditized, could it not be a realistic scenario that regular households and small businesses mine at home, using the heat to heat up the building? At least in areas with colder climate and low electricity costs.

With the progress of solar energy, there could be a case made for having excess average energy production, to account for peak times, and feeding the extra energy into mining.

These, or similar type scenarios, could be a great decentralizing pressure on mining, and would benefit from solutions to the problems discussed in this thread, no?

A discussion on what we want the mining ecosystem to look like.

Bitcoin requires decentralized mining for its value proposition and long-term survival. In the original emails on the cypherpunk list it was described that this would come about that the long tail of the power law distribution means that lots of small miners would outnumber the largest miners. For this to happen it means small miners have to be equally as efficient per-unit-hashpower as large miners.

There are several reasons that contribute to this not happening:


https://github.com/libbitcoin/libbitcoin/wiki/Pooling-Pressure-Risk

The only one of these reasons that p2pool deals with is the variance of payouts


https://github.com/libbitcoin/libbitcoin/wiki/Variance-Discount-Flaw

Here is a corrected scheme for making the payment channels be revokeable. It has the added benefit that if something goes wrong and X is revealed then all the payment channels don't need to be closed. Also the payment channel addresses now just look like 2of2 multisig so they save space and improve privacy too.

I have edited the OP to include that fix so that it's the first thing people read.

Here is the original OP for history reasons:




This is also posted on the bitcoin dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014893.html

Pooled mining in bitcoin contributes to miner centralization. P2Pool is one solution but has bad scalability; additional hashers require the coinbase transaction to be larger, bigger miners joining increase the variance of payouts for everyone else, and smaller miners must pay extra to consolidate dust payouts. In this email I propose an improved scheme using payment channels which would allow far more individual hashers to mine on p2pool and result in a much lower payout variance.


== Intro ==

P2Pool is a decentralized pool that works by creating a P2P network of hashers. These hashers work on a chain of shares similar to Bitcoin's blockchain. Each hasher works on a block that includes payouts to the previous shares' owners and the node itself. The point of pooling is to reduce the variance of payout, even though on average the reward is the same (or less with fees). The demand for insurance, and the liquid markets for options show that variance does have costs that people are willing to pay to avoid.

Here is an example of a p2pool coinbase transaction: https://blockchain.info/tx/d1a1e125ed332483b6e8e2f128581efc397582fe4c950dc48fadbc0ea4008022

It is 5803 bytes in size, which at a fee rate of 350 sat/b is worth 0.02031050 btc of block space that p2pool cannot sell to any other transaction. As bitcoin inflation goes down and miners are funded more by fees, this puts p2pool at more and more of a disadvantage compared to trusted-third-party mining pools.

As each hasher is paid to their own bitcoin address, this limits the number of hashers taking part as adding more individual people to the payout transaction increases its size. Also small payouts cost a disproportionate amount in miner fees to actually spend, which hurts small miners who are essential to a decentralized mining ecosystem.

This could maybe be solved by keeping a separate balance state for each user that is independent from the payouts, and make payouts only when that balance state exceeds some reasonable threshold. But this increases the variance which goes against the aim of pooled mining.


== Payment Channels ==

What's needed is a way to use off-chain payments where any number of payments can be sent to each individual hasher without using the blockchain. Then the N of the pay-per-last-N-shares (PPLNS) of p2pool can be increased to something like 6-12 months of shares and so as long as a small miner can mine a share every few months they will always get a payout when p2pool finds a block. The payment channels would be in a hub-and-spokes system and would work in a similar way to coinswap, lightning network, atomic cross-chain swaps or any other contract involving hashlocks and timelocks.

There would still be a sharechain but with hashers paying the entire block reward to a hub. This hub would have a one-way payment channel open to every hasher in p2pool and there would be created a situation where if the hub gets paid then the hashers cannot fail to get paid. Because cheating is impossible, the hub and hashers will agree to just release the money to each other without resorting to the blockchain.

The coinbase address scriptPubKey would be this, block rewards are paid to here:

     2of2 multisig
     hub + successful hasher
  OR
     hub pubkey + H(X)
  OR
     successful hasher pubkey + OP_CSV 6 months

A 2of2 multisig between the hub and the "successful" hasher which found the block, although with a hashlock and timelock. H(X) is a hash value, where the preimage X is generated randomly by the hub and kept secret, but X will be revealed if the hub spends via that execution path. The OP_CSV execution path is there to stop any holdups or ransom, in the worst case if the hub stalls then the successful hasher can steal the entire coinbase as punishment after 6 months.

Each payment channel address has this scriptPubKey:

     2of2 multisig
     hub-C + hasher-C
  OR
     2of2 multisig + H(X)
     hub-U + hasher-U

The pubkeys hub-C/hasher-C refer to 'cooperative' pubkeys. Hub-U/hasher-U refer to 'uncooperative' pubkeys. Before a hasher starts mining the hub will open a one-way payment channel to the hasher, and pays some bitcoin to it (let's say 0.5btc for example).

The hashers mine a sharechain, a solved share contains the hasher's cooperative and uncooperative pubkey. The hub keeps up with the sharechain and announces partially-signed transactions going to each hasher. The transactions are updated states of the payment channel, they pay money to each hasher in proportion to the work that the hasher contributed to the sharechain. The transaction contains a signature matching the hub-U pubkey, the hasher could sign it with their hasher-U key and broadcast except they still need the value of X.

If a hasher is successful and finds a share that is also a valid bitcoin block, they broadcast it to the network.

Now, the hub can spend the block reward money on its own but only by revealing X. Each hasher could then take that X and combine it with the partially-signed transaction and broadcast that to get their money. So if the hub gets paid then the hashers cannot fail to get paid. Since defecting is pointless, the hub signs the hub-C signature of the partially-signed transaction and sends it to each hasher, then the successful hasher signs the 2of2 multisig sending the block reward money to the hub. The successful hasher gets a small bonus via an updated payment channel state for finding the block, to discourage withholding same as today's p2pool.

These payment channels can be kept open indefinitely, as new blocks are found by p2pool the hub creates new partially-signed transactions with more money going to each hasher. When the hasher wants to stop mining and get the money, they can add their own hasher-C signature and broadcast it to the network.

If there's ever a problem and the hub has to reveal X, then all the payment channels to hashers will have to be closed and reopened with a new X, because their security depends on X being unknown.


== Hubs ==

The hub is a central point of failure. It cannot steal the money, but if it gets DDOS'd or just becomes evil then the whole thing would stop working. This problem could be mitigated by having a federated system, where there are several hubs to choose from and hashers have payment channels open with each of them. It's worth noting that if someone has a strong botnet they could probably DDOS individual p2pool hashers in the same way they DDOS hubs or even centralized mining pools.

The hub would need to own many bitcoins in order to have payment channels while waiting for blocks to be mined. Maybe 50 times the block reward which today would be about 650 bitcoins. The hub should receive a small percentage of each block reward to provide them with an incentive, we know from JoinMarket that this percentage will probably be around 0.1% or less for large amounts of bitcoin. Prospostive hub operators should write their bids on a forum somewhere and have their details added to some list on github. Hashers should have an interface for blacklisting, whitelisting, lowering and raising priority for certain hubs in case the hub operators behave badly.

As well as the smart contract, there are iterated prisoner's dilemma effects between the hub and the hashers. If the hub cooperates it can expect to make a predictable low-risk income from its held bitcoins for a long time to come, if it does something bad then the hashers can easily call off the deal. The hub operator will require a lot of profit in order to burn its reputation and future income stream, and by damaging the bitcoin ecosystem it will have indirectly damaged its own held bitcoins. A fair pricing plan will probably have the hub taking a small percent to start with and then 12 months later that percentage goes up to take into account the hub's improved reputation.


== Transaction Selection ==

All the hashers and hub need to know the exact value of the block reward in advance, this means they must know what the miner fees will be. This is probably the most serious problem with this proposal.

One possible way to solve this is to mine transactions into shares and so use the sharechain to make all the hashers and hubs come to consensus about exactly which transactions they will mine, and so exactly what the total miner fee will be. A problem here is that this consensus mechanism is slow, immediately after a bitcoin block is found all the p2pool hashers will have to wait 30-120 seconds before they know what transactions to mine, so this would make them uncompetitive as a mining operation.

Another way to deal with this is to have the hub just choose all the transactions, announcing the transactions, total miner fee and merkle root for the hashers to mine. This would work but allows the hub to control and censor bitcoin transactions, which mostly defeats the point of p2pool as an improvement to bitcoin miner centralization.

Another way is to have the hashers and hub estimate what the total miner fee value will be. The estimate could start from the median miner fee of the last few blocks, or from the next 1MB of the mempool. The hub would announce all the partially-signed transactions to every hasher, and then periodically (say every 60 seconds) announce updated versions depending on how the mempool changes. Let's analyze what happens if the estimated and actual rewards are different. If the actual block reward is lower than the estimated reward, then the hub can update the payment channel state to slightly lower values to take that into account when it announces the cooperative hub-C signatures. The hashers can't use the higher channel state without knowing X. The successful hasher will get their bonus for finding the block which should help in encouraging them to actually sign the hub's payout transaction. If the actual block reward is higher than the estimated reward, the hub would hopefully still update the hasher's payment channel states because of the interated-prisoners-dilemma effects. But if the actual reward is much higher then the hub may find it profitable to burn its reputation and take the money by revealing X, one situation where this might happen is if someone accidently pays a very high miner fee and a hasher mines it without it being taken into account in the hub's regular payment channel state updates. Apart from that very specific situation, this scheme of estimating the total miner fee should work.


== Some Notes ==

*) Block rewards are locked for 100 blocks before they can be spent, so the cooperative signatures should be exchanged after 100 blocks just in case the block gets made stale/orphaned. While the hashers are waiting for the 100 reward maturity period, they should mine with another hub as the payout.

*) Today's p2pool has a feature for donating to individual hashers, this could be replicated in the payment channel system by having each share also contain the hasher's bitcoin address for donations (or possibly their LN payment code)

*) Each hasher should probably be made to pay some bitcoins into the payment channel address too, to stop DOSers locking up all the hub's bitcoins. If the hasher doesn't find a share within some timeout then the hub should close the payment channel.

*) Now that we have segwit all these payment channel schemes are much easier to code.

*) The hashers must keep their money locked up in the payment channel for months before enough collects. This could be a problem because some miners don't really want to hold bitcoin long term. I wonder if theres some way to link up these channels to LN so they can sold straight away. They could also use futures contracts to sell the coins today at a discount and actually deliver the coins later when they close the channel.


== References ==

*) https://en.bitcoin.it/wiki/P2Pool how p2pool works

*) https://bitcointalksearch.org/topic/m.13057899 the scaleability problems of p2pool

*) https://bitcointalksearch.org/topic/m.20943086 making the PPLNS window longer

*) book: The Evolution of Co-Operation by Robert Axelrod, for explaining iterated prisoner's dilemma effects in detail

Thanks to the p2pool developer veqtrus for reviewing this

edit: the OP has been edited to fix this problem

I realized a way OP's payment channel scheme is broken, because old payments cant be revoked.

So for example, p2pool is working on a block which has a high total fee, the hubs send updated channel states with the new balance, the hashers obviously can't broadcast it because they don't know the value of X. Let's say that block isn't found by p2pool or for some other reason the total fee is now much lower. The problem is that the hashers will still know the earlier updated payment channel state, if its balance is higher than this new balance then the hashers could make money by forcing the hub to reveal X and so the hashers get a higher balance while the hub is left with a lower block reward.

In concrete numbers now. P2Pool is mining a block with reward 4 btc, there are 4 hashers who get 1 btc each. The hub sends updated states which add 1 btc to each hasher's balance. Suddenly there is an accidental-high-fee transaction with a fee of 8 btc, the hub updates each hasher's state to add 3 btc to the balance. Sadly some other pool mined that transaction, and the next block p2pool is working on has a reward of 4 btc again. The hub sends out an updated state paying 1 btc as before, but the hashers remember the old state of 3 btc, when one of them finds a block they don't sign the hub's reward transaction and force the hub to reveal X. The hub gets the 4 btc block reward but each hasher uses the now-revealed value of X to take 12 btc from the hub, leaving the hub 8 btc out of pocket!

The way to solve this is to create a system where old payments can be revoked. This shouldn't be too hard since LN already does this, I'll write a post here shortly explaining how.

The reason it's not a realistic assumption is because of the miner centralization already existing today, the very problem that the OP is aiming to solve. The ecosystem it's aiming for is that Bitcoin mining would be decentralized with the long tail of the power law being the majority, and a big factor in stopping this is that all the small miners just join a centralized pool.

P2Pool can't compete with a trusted-third-party pool right now because if its hashpower went up then the difficulty of the sharechain would go up too, and all the small miners would find their variance of payouts goes up. To reduce this variance requires the length of the sharechain to be increased massively (to cover something like 6 months instead of 3 days).

The resource usage could be improved by recoding the whole thing, although few programmers want to do that because of the scalability problems. The sharechain in the p2pool-pc idea wouldn't need to contain transactions for example, each share wouldn't be much larger than 80 bytes.


They are not equivalent, a payment happens every block in the payment channel idea, there's no "every n blocks" thing happening.

Not to mention in the periodic sharechain payments idea, small miners still have a pay a disproportionate amount in miner fees. This factor goes up as miner fees go up as they're expected to long-term.


Yes I agree. It's not a fundamental problem and could be fixed with lots more coding. As other people have already discussed, the scalability problems discourage any programmer from actually doing the coding.



Right now the main source is p2pool's low share of total hashpower. This is because of the scalability problem where an increase in hashrate would make p2pool simply stop working as a way to reduce payout variance.

Sorry, but that is not a remotely realistic assumption. Proof of Work systems have huge economies of scale. Miner size tends to follow a power law distribution. The reason for this is that different people in different regions pay different amounts for electricity, and usually pay less the more power they use. For example, I pay 2.8 cents per kWh because I moved to a city with very cheap power just so I could build a mine, and because I use more than 200 kW of power.

Under more realistic assumptions, the system I proposed can work fine. It's basically equivalent to the system used by the current existing large pools, in which payouts are made once the balance exceeds a per-user threshold. Traditional pools are able to make their payouts work just fine.

It's also worth mentioning that p2pool can not readily scale to having 48148 shares in the share chain. Currently, the number is 8640, and I've considered reducing that number in order to improve performance.

No, they are equivalent. In one case, you have a payment channel with state that doesn't get committed to the blockchain except after every n blocks, and in the other case you have a balance stored in the sharechain that gets committed to the blockchain every n blocks. The sharechain balance method does not need to increase variance at all; you can get paid the exact same amount as if you had gotten paid every block, but you get those payments 1/nth as often.

Because the code is slow, unfair to miners with slow CPUs and network connectivity, and difficult to set up properly.


It's because you're misunderstanding the sources of p2pool's payout variance.

This is all true today. But the situation would be vastly different if p2pool had more hash power: the difficulty of its sharechain would go up and the S9 would experience a much greater variance in payouts.

That's the entire point of this thread is that p2pool has scalability problems and so it works fine today but can't become larger. This lack of a solution is possibly one reason not much development happens, because few people will rewrite something in C++ if it just breaks when more people use it.

Let's put some numbers on this: Say for maximum decentralization p2pool was made up entirely of those S9s with 13.5 TH/s each, and if p2pool had 10% of global hashrate (which is 6,500,000 TH/s today), that would take 48148 such S9 units. The coinbase transaction would be 1.6MB in size (at 34 bytes per output), bigger than the blocksize limit without even any space left over for other transactions. Let's say we limited the coinbase transaction to 10kb (so a 1% penalty in block space already), which is 289 outputs, and used your trick of keeping an internal state and paying out in groups. That would mean each S9 hasher gets paid once every 166 p2pool blocks. All those 289 outputs need to be consolidated which costs more miner fees that a large centralized miner doesn't have to pay. P2Pool is a great idea and a cool project, but this paragraph shows that in its current form it's just not scalable. Any miner following his short term self-interest will just hook up to a centralized pool like kano's and get paid far more regularly.



This solution would be different in a very important way: it's variance of payouts would be much higher and would get worse as more individual hashers join p2pool, as you say the frequency of payouts would be lower. A payment channel solution would allow a hasher to get paid with every single block that p2pool finds even if that payment is just 1000 satoshi.

Also as bitcoin inflation drops to zero, that 0.13% figure will get larger.


No that was not my thought process. I was concerned about miner centralized (a serious problem given that we've just been in a 2-year long block size drama) and wanted to learn why p2pool isn't more relevant.

What I'm hearing is people don't see the point of payment channels and I need to explain more the problem they actually solve. I thought saying "they allow a massive reduction in payout variance" would be enough but apparently not.

A payout of 0.00005913 BTC per block (47 days on mainnet) corresponds to a hashrate of about 90 GH/s. That's roughly the hashrate of the first-generation Avalon miner from over four years ago. A machine like that earns about 0.5 cents per kWh. Electricity costs more than that, so such a machine will never be profitable. P2pool does not need to concern itself with the economics of mining with obsolete hardware.

Mining with a single S7 (a 2-year-old machine, still slightly profitable to run) on p2pool will result in a payout of approximately 0.05 btc per block on mainnet and 0.03 btc per block on jtoomimnet (which has more hashrate and finds blocks more often). That is about 100x greater than the transaction fee would be for spending the payout.

The most common miner nowadays is the S9, which has a hashrate of 13500 GH/s and earns 0.10 to 0.15 BTC per block on p2pool.

For the record, the jtoomimnet branch of p2pool supports segwit just fine. From one of nodes just now:


Otherwise, I pretty much agree with kano. Adding payment channels to p2pool is trying to solve a problem that doesn't exist yet when there are other problems that do exist and actually matter. The coinbase transaction causes us to lose about 0.13% of our potential revenue. If that ever increased and started to become a problem, the obvious first step is to make payouts for smaller miners every other block, or every third block, or every 10th block instead of every single block. That's basically equivalent to payment channels -- payments are settled on-chain with a lower frequency than off-chain payments -- but about 1/4th as difficult to implement.

Few people mine with the default fee. The majority of p2pool's hashrate mines with a 0% fee. Correct me if I'm wrong, but I think that's less than Kano's pool. The average fee that p2pool users choose to use (based on the block that belcher linked to) is 0.0326%. The last payout in the coinbase transaction is always forrestv's fee address.

It sounds to me like your thought process was something like this: "Payment channels are so cool! I wonder where we could use them? Hmm... maybe p2pool?" instead of "P2pool is so cool, but it has a few problems that make it hard for me to use it. How could we fix those problems?" The first type of thinking is dangerous in software engineering, and tends to cause more problems than it solves.

Thanks for the comments kano.


I've come across people saying "well the average income is the same so variance doesn't matter". It seemed like a good idea to explain why reducing variance is useful.

Your pool may have a lower fee, but its still a trusted-third-party, so it has different aims to p2pool and we can't really compare them.



Yes, this is a problem with the existing p2pool.

If you look at the p2pool coinbase transaction I linked, the smallest miner involved was paid 0.00005913 BTC while the largest miner was paid 4.27252711 BTC, both of these miners have to pay the same amount in fees to actually spend their payment, so the smaller miner makes less money per-unit-hashpower, which contributes to miner centralization. Maybe it's not the biggest contribution but still a contribution and one thing my idea solves so I'll mention it.


Someone could have a low hashrate even if they own a new ASIC.


Yes I know there are other problems with p2pool. The fact that my idea doesn't solve everything at once doesn't make it a bad idea.

In fact I'd say p2pool's scalability problem is the underlying issue that causes most of the others. I'm not the only one who believes this: https://bitcointalksearch.org/topic/m.13057899



My idea doesn't involve sidechains. Sidechains and payment channels are different things.

And obviously nobody has implemented it yet because it's only an idea at this stage

What's more, segwit was only activated on bitcoin's mainnet less than week ago, and it's essentially a requirement to build payment channel systems that work well.

If the first point of your argument is that people have to pay 'more' to reduce their variance on a pool, then you've already failed at the starting line.
P2Pool's default fee is 1% which is already more, for example than my pool's fee.

Next you seem to think that the next problem is that P2Pool can't pay small enough amounts.
Well considering that mining is a loss when mining with CPUs or GPUs or even old ASICs, you seem to be trying to cater for a small minority of people who want to lose money mining, and adding up to not much of a total hash rate.
Helping people to lose money doesn't really sound like a reason to change P2Pool - especially since you'd hope many of them would be smart enough to realise this.

Wanting more miners is making more hash rate consider using P2Pool, not by catering for a small hash rate increase for miners who are mining at a loss.

Your whole solution seems to be based on allowing tiny payments, but ignoring problems that are already known with P2Pool.
For example, veqtrus is against changes that jtoomin is attempting to add to P2Pool to resolve a list of problems. e.g.
1) P2Pool is unfair to smaller miners - larger miners get the advantage of power to more likely confirm their own shares than smaller miners do
 This is clearly visible seeing the large variance in DOA rates on different P2Pool pools - though this is also in part due to point "X" below
2) P2Pool produces small blocks - there's a limit of something like 100K of transactions added per share - thus it works out that something like 39% of P2Pool blocks are expected to be smaller than 1MB - i.e. usually smaller than most pools - and that size reduces as the P2Pool blocks found are closer to the previous network block.
The P2Pool coinbase transaction is not their biggest concern.
3) P2Pool STILL doesn't support segwit, even though every other pool does

"X" There's also simple issues like the fact that a P2Pool pool will need to have many resources similar to a normal pool to ensure they can compete well against normal pools, and other P2Pool pools; yet there certainly seems to be people trying to skimp on that to save costs running their own P2Pool pool - or worse:

Another bazaar problem that exists with P2Pool is centralisation - yep there are not as many P2Pool pools as there are miners on P2Pool, so there are large centrally controlled P2Pool pools that manage many miners, and this also increases share latency for those who do no set up their own P2Pool pool.
P2Pool has less centralisation than normal pools, but not "no centralisation" - this has become the more common use of P2Pool for a while now.

Then of course you are also advocating using something that's not even implemented yet - side chain payment channels - on P2SH transactions ... which are the source of many bitcoin bugfixes ... such as the most recent ... segwit which is yet another bugfix for P2SH ...

Pooled mining in bitcoin contributes to miner centralization. P2Pool is one solution but has bad scalability; additional hashers require the coinbase transaction to be larger, bigger miners joining increase the variance of payouts for everyone else, and smaller miners must pay extra to consolidate dust payouts. In this email I propose an improved scheme using payment channels which would allow far more individual hashers to mine on p2pool and result in a much lower payout variance.


== Intro ==

P2Pool is a decentralized pool that works by creating a P2P network of hashers. These hashers work on a chain of shares similar to Bitcoin's blockchain. Each hasher works on a block that includes payouts to the previous shares' owners and the node itself. The point of pooling is to reduce the variance of payout, even though on average the reward is the same (or less with fees). The demand for insurance, and the liquid markets for options show that variance does have costs that people are willing to pay to avoid.

Here is an example of a p2pool coinbase transaction: https://blockchain.info/tx/d1a1e125ed332483b6e8e2f128581efc397582fe4c950dc48fadbc0ea4008022

It is 5803 bytes in size, which at a fee rate of 350 sat/b is worth 0.02031050 btc of block space that p2pool cannot sell to any other transaction. As bitcoin inflation goes down and miners are funded more by fees, this puts p2pool at more and more of a disadvantage compared to trusted-third-party mining pools.

As each hasher is paid to their own bitcoin address, this limits the number of hashers taking part as adding more individual people to the payout transaction increases its size. Also small payouts cost a disproportionate amount in miner fees to actually spend, which hurts small miners who are essential to a decentralized mining ecosystem.

This could maybe be solved by keeping a separate balance state for each user that is independent from the payouts, and make payouts only when that balance state exceeds some reasonable threshold. But this increases the variance which goes against the aim of pooled mining.


== Payment Channels ==

P2pool's problems described above come from the fact that it's payout uses on-chain payments. We know the blockchain doesn't scale so it's natural to look for off-chain solutions.

What's needed is a way to use off-chain payments where any number of payments can be sent to each individual hasher without using the blockchain. Then all the parameters of p2pool can be modified to drastically reduce the payout variance. The N of the pay-per-last-N-shares (PPLNS) of p2pool can be increased to something like 6-12 months of shares and so as long as a small miner can mine a share every few months they will always get a payout when p2pool finds a block. The payment channels would be in a hub-and-spokes system and would work in a similar way to coinswap, lightning network, atomic cross-chain swaps or any other contract involving hashlocks and timelocks.

There would still be a sharechain but with hashers paying the entire block reward to a hub. This hub would have a one-way payment channel open to every hasher in p2pool and there would be created a situation where if the hub gets paid then the hashers cannot fail to get paid. Because cheating is impossible, the hub and hashers will agree to just release the money to each other without resorting to the blockchain.

The coinbase address scriptPubKey where block rewards are paid to would be this:


A 2of2 multisig between the hub and the "successful" hasher which found the block, although with a hashlock and timelock. H(X) is a hash value, where the preimage X is a randomly-generated nonce which is kept secret by the hub, but X must be revealed if the hub spends via that execution path.

Each payment channel between the hub and a hasher is a 2of2 multisig between them.

The hashers mine a sharechain, a solved share contains the hashers pubkey. The hub keeps up with the sharechain and announces partially-signed transactions going to each hasher. The transactions are updated states of the payment channel, they pay money to each hasher in proportion to the work that the hasher contributed to the sharechain.

This is the form of an updated state of the payment channel:


If broadcasted, this transaction would allow the hasher to take the balance of the payment channel but only if it knows the value of X.

If a hasher is successful and finds a share that is also a valid bitcoin block, they broadcast it to the network.

Now, the hub can spend the block reward money on its own but only by revealing X. Each hasher could then take that X and combine it with the updated state transaction to get their money. So if the hub gets paid then the hashers cannot fail to get paid. Since defecting is pointless, the hub creates a new partially-signed transaction simply spending the 2of2 multisig output to each hasher, which now does not have any hashlock conditions. A hasher could at any time sign with their own private key and broadcast to get the money settled on the blockchain. After that, the successful hasher signs the 2of2 multisig block reward sending the block reward money to the hub. The successful hasher gets a small bonus via an updated payment channel state for finding the block, to discourage withholding same as today's p2pool. If everything goes well then the hub never reveals X, for mining a new block it announces a new value of H(X).

These payment channels can be kept open indefinitely, as new blocks are found by p2pool the hub creates new updated states with more money going to each hasher. When the hasher wants to stop mining and get the money, they can add their own signature and broadcast the most recent state to the network.

== Hubs ==

The hub is a central point of failure. It cannot steal the money, but if it gets DDOS'd or just becomes evil then the whole thing would stop working. This problem could be mitigated by having a federated system, where there are several hubs to choose from and hashers have payment channels open with each of them. It's worth noting that if someone has a strong botnet they could probably DDOS individual p2pool hashers in the same way they DDOS hubs or even centralized mining pools.

The hub would need to own many bitcoins in order to have payment channels while waiting for blocks to be mined. Maybe 50 times the block reward which today would be about 650 bitcoins. The hub should receive a small percentage of each block reward to provide them with an incentive, we know from JoinMarket that this percentage will probably be around 0.1% or less for large amounts of bitcoin. Prospostive hub operators should write their bids on a forum somewhere and have their details added to some list on github. Hashers should have an interface for blacklisting, whitelisting, lowering and raising priority for certain hubs in case the hub operators behave badly.

As well as the smart contract, there are iterated prisoner's dilemma effects between the hub and the hashers. If the hub cooperates it can expect to make a predictable low-risk income from its held bitcoins for a long time to come, if it does something bad then the hashers can easily call off the deal. The hub operator will require a lot of profit in order to burn its reputation and future income stream, and by damaging the bitcoin ecosystem it will have indirectly damaged its own held bitcoins. A fair pricing plan will probably have the hub taking a small percent to start with and then 12 months later that percentage goes up to take into account the hub's improved reputation.


== Transaction Selection ==

All the hashers and hub need to know the exact value of the block reward in advance, this means they must know what the miner fees will be. This is probably the most serious problem with this proposal.

One possible way to solve this is to mine transactions into shares and so use the sharechain to make all the hashers and hubs come to consensus about exactly which transactions they will mine, and so exactly what the total miner fee will be. A problem here is that this consensus mechanism is slow, immediately after a bitcoin block is found all the p2pool hashers will have to wait 30-120 seconds before they know what transactions to mine, so this would make them uncompetitive as a mining operation.

Another way to deal with this is to have the hub just choose all the transactions, announcing the transactions, total miner fee and merkle root for the hashers to mine. This would work but allows the hub to control and censor bitcoin transactions, which mostly defeats the point of p2pool as an improvement to bitcoin miner centralization.

Another way is to have the hashers and hub estimate what the total miner fee value will be. The estimate could start from the median miner fee of the last few blocks, or from the next 1MB of the mempool. The hub would announce all the partially-signed transactions to every hasher, and then periodically (say every 60 seconds) announce updated versions depending on how the mempool changes. Let's analyze what happens if the estimated and actual rewards are different. If the actual block reward is lower than the estimated reward, then the hub can update the payment channel state to slightly lower values to take that into account. The hashers can't use the higher channel state without knowing X. The successful hasher will get their bonus for finding the block which should help in encouraging them to actually sign the hub's payout transaction. If the actual block reward is higher than the estimated reward, the hub would hopefully still update the hasher's payment channel states because of the interated-prisoners-dilemma effects. But if the actual reward is much higher then the hub may find it profitable to burn its reputation and take the money by revealing X, one situation where this might happen is if someone accidentally pays a very high miner fee and a hasher mines it without it being taken into account in the hub's regular payment channel state updates. Apart from that very specific situation, this scheme of estimating the total miner fee should work. Note that hashers can choose which hub to mine for from their federation of hubs, they should avoid mining transactions which make the block reward much higher than the announced payment channel state, this should avoid the problem.


== Some Notes ==

*) Block rewards are locked for 100 blocks before they can be spent, so the cooperative signatures should be exchanged after 100 blocks just in case the block gets made stale/orphaned. While the hashers are waiting for the 100 reward maturity period, they should mine with another hub as the payout.

*) Today's p2pool has a feature for donating to individual hashers, this could be replicated in the payment channel system by having the hashers sign a LN payment code using the same pubkey that appears in the sharechain. Each LN payment code is then donated to in proportion to the work in the sharechain. After p2pool matures there should be an organized social movement asking for donations to the p2pool hashers. The economic majority has an incentive to support decentralized mining, and in the past when the status quo p2pool was bigger then it did receive them, so this is a realistic ask. The UASF movement was successful so we know such social movements are possible. The donation drive should continue until all public centralized mining pools have low hash power.

*) Each hasher should probably be made to pay some bitcoins into the payment channel address too, to stop DOSers locking up all the hub's bitcoins. If the hasher doesn't find a share within some timeout then the hub should close the payment channel. Another way to rate-limit DOS is for the hub to require a solved PoW challenge before opening a channel.

*) Now that we have segwit all these payment channel schemes are much easier to code.

*) The hashers must keep their money locked up in the payment channel for months before enough collects. This could be a problem because some miners don't really want to hold bitcoin long term. I wonder if theres some way to link up these channels to LN so they can sold straight away. They could also use futures contracts to sell the coins today at a discount and actually deliver the coins later when they close the channel. Edit: according to roasbeef such a connection with LN is indeed possible, then hashers would get bitcoins in their LN wallet which would be available for spending immediately. This would work by having bidirectional payment channels between hub and hashers, and the hub having open payment channels with the rest of the network. Then hashers can send their mining income via the hub to anyone in the lightning network

*) In order to stop holdups or ransom, there is an added OP_CSV execution path in the coinbase. The coinbase output actually has this script:


Then the hub has a time limit to spending the coinbase and revealing X, if they don't then the successful hasher can steal the entire coinbase after 6 months.


== References ==

*) https://en.bitcoin.it/wiki/P2Pool how p2pool works

*) https://bitcointalksearch.org/topic/m.13057899 the scaleability problems of p2pool

*) https://bitcointalksearch.org/topic/m.20943086 making the PPLNS window longer

*) book: The Evolution of Co-Operation by Robert Axelrod, for explaining iterated prisoner's dilemma effects in detail

Thanks to the p2pool developer veqtrus for reviewing this

This is also posted on the bitcoin dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014893.html