belcher



Offline



Activity: 261

Merit: 328







Sr. MemberActivity: 261Merit: 328 Payment Channel Payouts: An Idea for Improving P2Pool Scalability August 30, 2017, 04:37:40 PM

Last edit: December 21, 2017, 02:26:17 PM by belcher #1





== 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:



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:



Code: 2of2 multisig of hub + successful hasher

OR

hub pubkey + H(X)



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:



Code: 2of2 multisig UTXO ----> [total - balance btc] hub-pubkey

----> [balance btc] hasher-pubkey + H(X)



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:



Code: 2of2 multisig of hub + successful hasher

OR

hub pubkey + H(X)

OR

successful hasher pubkey + OP_CSV 6 months



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 ==



*)



*)



*)



*) 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: 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://bitcointalk.org/index.php?topic=18313.msg13057899#msg13057899 the scaleability problems of p2pool*) https://bitcointalk.org/index.php?topic=18313.msg20943086#msg20943086 making the PPLNS window longer*) book: The Evolution of Co-Operation by Robert Axelrod, for explaining iterated prisoner's dilemma effects in detailThanks to the p2pool developer veqtrus for reviewing thisThis is also posted on the bitcoin dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014893.html

- CoinJoin that people will actually use.

PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129 1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use.PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129

kano



Offline



Activity: 3262

Merit: 1294





Linux since 1997 RedHat 4







LegendaryActivity: 3262Merit: 1294Linux since 1997 RedHat 4 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability August 30, 2017, 05:31:04 PM #2 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 ... lowest fee PPL N S 3 Days Here on Bitcointalk:

Discord support invite at Majority developer of the c k pool code - k for k ano

Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks! Pool: https://kano.is Here on Bitcointalk: Forum support invite at https://kano.is/ developer of the cpool code -foranoHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - andempty blocks!

belcher



Offline



Activity: 261

Merit: 328







Sr. MemberActivity: 261Merit: 328 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability August 30, 2017, 06:34:36 PM

Last edit: September 04, 2017, 05:00:41 PM by belcher #3



Quote from: kano on August 30, 2017, 05:31:04 PM 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.

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.





Quote from: kano on August 30, 2017, 05:31:04 PM Next you seem to think that the next problem is that P2Pool can't pay small enough amounts.



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.



Quote from: kano on August 30, 2017, 05:31:04 PM 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.



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



Quote from: kano on August 30, 2017, 05:31:04 PM 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.



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:





Quote from: kano on August 30, 2017, 05:31:04 PM 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 ...



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. 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://bitcointalk.org/index.php?topic=18313.msg13057899#msg13057899 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 stageWhat'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.

- CoinJoin that people will actually use.

PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129 1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use.PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129

jtoomim



Offline



Activity: 818

Merit: 1001







Hero MemberActivity: 818Merit: 1001 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability August 30, 2017, 07:40:26 PM

Last edit: August 30, 2017, 08:43:49 PM by jtoomim #4 Quote from: belcher on August 30, 2017, 06:34:36 PM 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.



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.



Quote from: kano on August 30, 2017, 05:31:04 PM 3) P2Pool STILL doesn't support segwit, even though every other pool does

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



Code: Generating a share with 1000700 bytes (40274 new) and 1943 transactions (90 new)

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.



Quote P2Pool's default fee is 1% which is already more, for example than my pool's fee. 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.



Quote == Payment Channels ==

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. 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. $65 to $80/kW/month on clean, cheap hydro power.

http://Toom.im Hosting bitcoin miners for/kW/month on clean, cheap hydro power.

belcher



Offline



Activity: 261

Merit: 328







Sr. MemberActivity: 261Merit: 328 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability August 31, 2017, 02:43:14 AM #5 Quote from: jtoomim on August 30, 2017, 07:40:26 PM Quote from: belcher on August 30, 2017, 06:34:36 PM 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.



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. 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.

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



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.





Quote from: jtoomim on August 30, 2017, 07:40:26 PM 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.



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.



Quote from: jtoomim on August 30, 2017, 07:40:26 PM Quote == Payment Channels ==

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.

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.

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. 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.

- CoinJoin that people will actually use.

PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129 1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use.PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129

jtoomim



Offline



Activity: 818

Merit: 1001







Hero MemberActivity: 818Merit: 1001 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability August 31, 2017, 03:06:16 PM #6 Quote from: belcher on August 31, 2017, 02:43:14 AM 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.

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.



Quote 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.

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.



Quote 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.

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





Quote 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.

It's because you're misunderstanding the sources of p2pool's 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. $65 to $80/kW/month on clean, cheap hydro power.

http://Toom.im Hosting bitcoin miners for/kW/month on clean, cheap hydro power.

belcher



Offline



Activity: 261

Merit: 328







Sr. MemberActivity: 261Merit: 328 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability August 31, 2017, 04:41:52 PM #7 Quote from: jtoomim on August 31, 2017, 03:06:16 PM Quote from: belcher on August 31, 2017, 02:43:14 AM 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.

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. 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.

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.



Quote from: jtoomim on August 31, 2017, 03:06:16 PM Quote 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.

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. 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.

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.



Quote from: jtoomim on August 31, 2017, 03:06:16 PM Quote 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.

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

Yes I agree. It's not a fundamental problem and could be fixed with lots more coding.





Quote from: jtoomim on August 31, 2017, 03:06:16 PM Quote 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.

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

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

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. 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.

- CoinJoin that people will actually use.

PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129 1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use.PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129

belcher



Offline



Activity: 261

Merit: 328







Sr. MemberActivity: 261Merit: 328 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability September 01, 2017, 12:55:53 AM

Last edit: April 28, 2018, 01:14:43 PM by belcher #8 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.





- CoinJoin that people will actually use.

PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129 1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use.PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129

belcher



Offline



Activity: 261

Merit: 328







Sr. MemberActivity: 261Merit: 328 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability September 02, 2017, 03:10:24 AM

Last edit: September 02, 2017, 04:22:24 PM by belcher #9



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:



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:



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 ==



*)



*)



*)



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

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 multisighub + successful hasherORhub pubkey + H(X)ORsuccessful hasher pubkey + OP_CSV 6 monthsA 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 multisighub-C + hasher-COR2of2 multisig + H(X)hub-U + hasher-UThe 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://bitcointalk.org/index.php?topic=18313.msg13057899#msg13057899 the scaleability problems of p2pool*) https://bitcointalk.org/index.php?topic=18313.msg20943086#msg20943086 making the PPLNS window longer*) book: The Evolution of Co-Operation by Robert Axelrod, for explaining iterated prisoner's dilemma effects in detailThanks to the p2pool developer veqtrus for reviewing this

- CoinJoin that people will actually use.

PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129 1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use.PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129

belcher



Offline



Activity: 261

Merit: 328







Sr. MemberActivity: 261Merit: 328 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability September 06, 2017, 08:34:22 PM #10



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:



Quote There are several manifestations of of pooling. One is geographic, where independent miners become physically closer together. Another is cooperative, where formerly-independent miners join forces and co-locate grinding. Another is virtual, where miners become grinders and aggregate hash rate to a single remote miner. Another is the existence of relays, which aggregate miner hash power. Another is capital flow, since the higher hash rate associated with greater capital utilization is a form of co-location.

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



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



Quote Consider then that a tiny miner might have to wait years before any reward. Despite being rewarded proportionally a smaller miner is faced with a perceived deficiency in relation to the larger miner. It can improve cash flow to receive a fraction of the reward more frequently. There is also the possibility that a mine is misconfigured and can never succeed. For these reasons miners discount high variance. Smaller miners will convert their mines to grinds and pay an aggregating miner for reduced variance. This is the rationale behind P2Pool, but because distributed variance reduction is less efficient the pooling pressure remains.

https://github.com/libbitcoin/libbitcoin/wiki/Variance-Discount-Flaw 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:The only one of these reasons that p2pool deals with is the variance of payouts

- CoinJoin that people will actually use.

PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129 1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use.PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129

dieselapa



Offline



Activity: 7

Merit: 0







NewbieActivity: 7Merit: 0 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability September 07, 2017, 07:49:47 AM #11 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?

jtoomim



Offline



Activity: 818

Merit: 1001







Hero MemberActivity: 818Merit: 1001 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability September 08, 2017, 06:55:53 PM #12 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. $65 to $80/kW/month on clean, cheap hydro power.

http://Toom.im Hosting bitcoin miners for/kW/month on clean, cheap hydro power.

dieselapa



Offline



Activity: 7

Merit: 0







NewbieActivity: 7Merit: 0 Re: Payment Channel Payouts: An Idea for Improving P2Pool Scalability September 09, 2017, 09:36:57 AM #13 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 