Bitcoin Forum

Anyone who has been following crypto-currencies for long has realized that any popular (and thus hard to mine) crypto-currency ends up resorting to mining pools.  These pools become new points of centralization.    In the case of ProtoShares, a CPU coin, profiteers flooded the market with hash power and forced out the little guy who wants to mine on his home computer.  These profiteers didn't care about the coin, they just saw the price difference between the coin and the cost of mining and took advantage of the profit opportunity.   

Then we have pools that came out and captured more than 80% of the hash power due to a slight optimization advantage.  These pools had a single bug in their miner that prevented more than one transaction from being included in a block and thus caused delays for the entire network like a legitimate 51% attack.

In Bitcoin land, large ASIC firms and mining pools are a potential threat.   Even having a couple large pools is a problem and represents a kind of 'special node' in the network that if taken out or compromised could enforce white lists, black lists, or transaction delays.   A new solution is required that make the use of large pools, whether ASIC, GPU, or CPU less profitable than solo-mining for individual users.   

I have a new proposal that aims to eliminate botnets and profiteers from being a threat to GPU or CPU based coins and could be useful toward encouraging solo-mining with bitcoin by increasing the costs associated with large centralized ASIC miners. 

The basic idea is this:  blocks have a random vesting time between 1 day and 1 year with an average of 6 months.   Any pool operator would have to maintain 6 months of inventory and operating expenses on their books while exposed to price fluctuations in the underlying currency.   Mining pools would have to charge much higher fees to cover the cost of capital and a 51% attack on Bitcoin would not be able to finance itself from the immediate sale of the BTC mined.   Meanwhile, solo-miners with ASICs are back to a lottery system.   New crypto-currencies wouldn't have to worry about fly-by-night pools or profiteers that mine and dump.   The average rate of currency introduction would be the same, just delayed 6 months on average and this would also prevent a lot of short-run PUMP and DUMP scams.   

http://bitsharestalk.org/index.php?topic=905.0

Interesting proposal.

Cost of carrying extra capital means you will get lower network hashrate for the same aggregate amount spent on securing the network.

Also it means I can't reliably mine virgin coins (for removing taint issue) when I need to spend them near-term. It is a forced savings program.

I am generally against any arbitrary limit that is not helping the party who is investing. I guess you can argue it helps the overall health of the system thus coin value, but individually miners might not calculate it that way.

Perhaps you are aware of the new selfish-mining attack which is a vulnerability when any entity has control over 25% of the network hashrate. Perhaps your proposal fixes it.

I am aware of the selfish miner attack and that is solved by allowing new blocks to replace the current head block provided it is 'more difficult'.  Someone attempting to be a 'selfish miner' who starts working on a 2nd block without taking credit for the first block has a significant chance that when the rest of the network finds the first block, his second block will have been built on an invalid chain.    He would then have to find 3 blocks before the primary network found 2 blocks because miners do not switch 'chains' until their chain is more than 2 blocks behind the other chain.

To clarify, miners do not switch chains to a fork that is split based upon an easier hash unless it has more than 2 block advantage.

Interesting idea for a solution to selfish-mining. We are getting off-topic a bit from your OP. You mean miners choose the chain with the hashes with the lowest value below the threshold for "difficulty". But the problem is that the longer we wait, the lower hashes can be. So you resolve that by choosing the chain with the lowest total of all hashes I presume. I suppose you've worked out the probabilities and game theory and convinced yourself this converges.

I assume you are aware of the equation for orphan rate:

https://bitcointalk.org/index.php?topic=260180

You've got to make sure you have convergence. This will impact on the minimum block period.

P.S. You got this conceptual idea from the mini-blockchain ;) Clever application.

I believe my network will converge much faster because it will never diverge in the first place because network latency is practically removed from the equation.   In the instances where there is an orphan block today it occurs because two people broadcast at about the same time.  Miners accept the first block found therefore half of the miners use one block and another half use the other.   This process is not resolved until one side of the network finds the next block.   

Under my system, two miners broadcast at the same time and everyone will immediately converge on the best chain without ambiguity.  The only potential for 'orphans' resulting in divergence is if two back-to-back blocks are found in a space less than the propagation delay AND the first block had a higher hash.   

More slightly off-topic discussion... So if a miner has already started working and a new solution comes later with a much lower hash, does the miner throw away the current work? I guess not. So miners only consider re-starting work up to the maximum propagation delay you expect? Hardcoded?

Then that still defeats selfish-mining because of the increasing probability that the hash found later will be lower than the held back hash solution discovered earlier. Effectively you've increased the gamma in the selfish-mining research paper.

hmmm... but variance is an issue. If the selfish-miner has a very low valued hash, it is still probably worth holding it back.

Nevertheless your idea reduces orphan rate.

The tradeoff is it doesn't converge if the rate of competing block generation is less than the propagation delay?

If implemented, this intent could be easily defeated by an external BTC derivatives market which would undoubtedly form.

Damn you Soros. Why didn't I see that!

I am sure such a derivatives market would form.  And it does not defeat the intent.   A coin today is more valuable than a coin in 6 months, so the cost of mining in the pool with immediate payout would still be higher than mining solo.   The coins mined would still be delivered to those taking a LONG TERM approach AND the pool operator would have to be trusted or individual selling the future contract would only provide payment upon a block being found with their private key and thus shift the trust from the pool to the long-term investor.  

There is clearly money to be made by facilitating pools, but those mining on the pools would face a much higher cost of doing business and if you push the time horizon out to a two or more years initially then the risks would be much higher and finding people willing to finance over that period of time would be much harder.  

interesting idea...

How about people start adopting this new mining protocol? https://en.bitcoin.it/wiki/Getblocktemplate

This allows the miner to build the block rather than the pool, so the miner can implement their own policy as to what goes into the block.  This means that pool operators with a large share of hashing power cannot abuse that power to do things like exclude certain transactions from blocks, or have unreasonably high fee thresholds.  The content of the block would be based on the transaction policies of the person who happened to mine it, which would have a lot of variation since each block would likely come from a different miner.

This also means that the miner who first finds the block can broadcast the block, which makes it impossible for the pool to do "selfish mining".

This works well for people running 'full nodes' but it seems most 'miners' are using specialized light-weight clients. 

No pool at this time actually supports miners picking and choosing transactions with GBT.  They use GBT the same way pools use stratum.  They give you the block contents, you mine it.  You have no say.

There is a whole new level of complication added to the Miner<->Pool dynamic when it comes to letting miners pick transactions.  Specifically, the pool needs to know which transactions you're including every time you send in shares so it can validate your share results are correct.  This is a MASSIVE amount of bandwidth that would be required when looking at even a 10% fraction of the pool opting for it, not to mention a large increase in stale rates for most miners since they would have to upload 300-500KB to the pool to tell them the block contents.  Hell, GBT is already a complete major bandwidth hog compared to Stratum because it has to send miners the entire block contents when it pushes work instead of just a merklebranch.

I postulated that selfish-mining can be easily defeated by spying on the pools (http://hackingdistributed.com/2013/11/09/no-you-dint/#comment-1136318528). Bytemaster, I also mentioned your proposed solution there and linked back to this thread.


Also there is the problem when miners don't agree about which transactions should be placed in the block, i.e. a Tragedy of the Commons outcome.

It seems to me that competition will keep the pools reasonable in size if the transaction fee is cast in stone. Because as transaction volume rises, the cost of subsidizing a pool to gain market share thus increases. However, if income from transactions is significant, then the network is vulnerable to my Transactions Withholding Attack.

If we could limit the income of the pool operator and insure all the rest goes to the pool's miners, then we could surely limit the size of pools.

Talk about care of coin, little guy, profiteering, same share for everyone.... reminds me of communism.

Would you care so much or spend so much of energy for coin with zero value?

I don't care about same share for everyone, I care about decentralizing control of transaction selection and increasing hash power relative to price paid (inflation/etc).

I am thinking the pool operator (server) does so little relative to work of the pool miners that it doesn't need to charge a very high fee. Thus there isn't much ability (incentive for pool miners) to undercut competitors based on fee.

So there just needs to be a slightest incentive to encourage pool miners to seek out another pool as a pool grows large. This will encourage a proliferation of pools.

How do pool miners know that a pool server isn't cheating them by paying some of the earnings to themselves pretending to be a pool miner?

Go down that line of thought and you will discover what I am thinking.

The only way you can prove a pool isn't cheating is by estimating the hash rate of the pool and comparing it to the number of blocks found.  Unfortunately, you could probably still skim a couple of a percent this way.

Why don't you just use P2Pool? Is there any reason?

Modern protocols (GBT & Stratum) both have the full coinbase transaction visible to the miners, meaning you can verify that the block being built will be paid to a certain address or has a certain message encoded in the block that identifies the pool.  This allows you to audit if the pool is trying to skim blocks if certain users start seeing work without a coinbase message that identifies the pool.  In the case of BTC Guild, it's both, they always pay to the same address and always include "Mined by BTC Guild" in the coinbase message.

It's not no-trust, but all it would take is a few % of users monitoring this to determine if a pool was trying to skim blocks by sending a certain % of work that doesn't include identifying marks.

Couldn't the pool validate your shares without knowing the full merkle tree?  So the miner provides the PoW via the block header, plus a merkle branch which proves that the pool is paid in the coinbase transaction.

Reading this, only understanding 30% of it :(

Sincere question, maybe it was covered here but I couldn't understand it.  What is the real world chance that one day in the close future (next 12 months say), somebody will do something like this 51% attack thing, or some fault will be discovered, that creates big problems for bitcoin?  Is it a high risk of happening?

To submit a block, the pool has to have the entire raw block worth of data.  So if the block is 500KB, the miner would have to upload the full 500KB being used to build the block to the pool, plus a bit of overhead for the JSON markup, assuming the miner was actually involved in building the block.

There are *some* ways to shrink this, where the pool dictates what transactions can be selected, with a tx-id integer (instead of full hash) so the miner could just upload a list of the transactions they included in the block, or a list of ones they excluded.  But once the miner is introducing their own transactions from their local node that the pool wasn't originally aware of, this is no longer possible, since the pool needs to know the raw transaction.



A 51% is extremely unlikely.  Even the largest pools now represent less than 30% of the actual network hash rate.  Luck spikes make their 24-hour block percentage above 30%, but this can't be predicted and is not reliable.  The 51% attack threat is having enough power to guarantee eventually you will make the longest chain as long as you keep trying.  If the largest pools were DDoS'd, most of that hash rate filters down to backup pools, so the argument that you just DDoS the largest pools to make a 51% attack easier is not quite accurate.

30% sounds an extremely alarming rate to me. It's not a radical stretch of imagination to envision them getting the extra 21% power required.
I would feel much more comfortable with the strongest miner having, say, 5% of the hashpower.

How could anything less than 100% of the pool miners know if some of the coinbase transactions were to addresses not owned by pool miners who contributed shares?

Since you can never know if you are the 100% (because mining pool shares* are not recorded in the block chain), thus seems to me there is no way to verify if there is skimming or not, as bytemaster and I wrote.

*For those who don't know the terminology, a pool share is a proof-of-work hash below some threshold that is easier than the current network difficulty. It might also be a block solution.


I was waiting for bytemaster to answer because I wanted to know his thoughts. Seems to me that you have no way to stop the Share Withholding Attack since it is decentralized. And every peer has to run more of a full client if I am not mistake. And there is a lot more overhead I believe. And perhaps also much less resistance against denial-of-service flooding. Frankly I didn't analyze for long enough to be very sure of my initial intuition which is to stay away from it.

I know it is generally impossible to enforce reputation on a 100% decentralized system. So I am intuitively skeptical of P2Pool.

P2Pool already solved (almost?) all of these problems. Why don't you just use it? It's really great... what does it miss?

It is a great project and I advice everyone to use it.

https://en.bitcoin.it/wiki/P2Pool#Payout_logic


Incorrect. The miner can still be paid for the shares he generated which were not a block solution, because another peer might generate the block solution after. Thus the share withholding miner can parasite income off the pool while robbing the pool of his major contribution to the revenue. So this brings revenue to the miner, while parasiting on the pool. If enough shares are from attackers, this destroys the economics of the honest miners in the pool and probably destroys the pool.

So if you owned a centralized pool, it would probably be in your interest to attack all the P2Pools.

Whereas centralized pools could (in a redesigned block chain) implement Meni Rosenfeld's oblivious shares to thwart the share withholding attack.

So as I wrote upthread, P2Pool is not a sustainable nor reliable solution.

I have designed a new Proof-of-Stake system that requires no mining at all and therefore entirely prevents centralization of mining leaving only 51% ownership of the money supply as a means of attack.

http://bitsharestalk.org/index.php?topic=1138.msg11955#msg11955

hi
i noticed you deleted you telegram account recently
why?
i am still waiting the letter and when it arrives how can i contact you?
please contact me at @AmbrogioOrfeu on telegram