POW with built in distributed mining

cobordismcobordism Member Posts: 6
In the bitcoin world mining is becoming centralised as miners join large mining pools in order to get a smoother, more even payout.

I have a suggestion of how the incentive to join pools could be severely weakened.

Suppose that the difficulty is some number - say 20 and assume that it takes you ten times longer to find a solution at difficulty 20 than at difficulty 19 &cetera...
My suggestion is that we declare a block 'solved' if it comes with a solution at difficulty 20 or 10 solutions at difficulty 19 or 100 solutions at difficulty 18 (or some combination of 18 and 19).
The idea being, that (in this toy model) it is just as much work to find 10 different solutions at 19 as 1 silution at 20.
If I find a solution at 19 I publish it instantly. If someone finds a solution at 19 and sees 9 others floating around, (or maybe 8 others, and 10 at level 18) then the miner quickly publish them as a valid block.

The block reward is split evenly among the 10 (or more) solutions.

The benefits: even with lower hashing power I will not have to join a pool; even if I can only expext to solve 100th of a block, I still have a chance at a payout.
We do not have to wait a full block for confirmation per se, you could see a transaction as 10% confirmed or 20% confirmed as partial solutions to a block containing your transaction are being published.

What do you say? Is something like this feasable?

Comments

  • kershykershy Member Posts: 46
    That's a very nice idea.

    One drawback I see is the amount of storage and networkload (10 blocks vs 1 block) would go up.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    The problem is that later on, you still need to be able to tell which blocks were really attached, even if an attacker mines from an older point much later on.

    In the case of a 'simple single chain' you know this, because there is this really hard long chain stacked ontop of this. You could try have the 'hardest' block reference the weaker blocks, but this gives that block complete power to decide whether to include the other blocks. I suppose you pay a little to the main block creator for including references to weaker blocks.

    Also the referenced blocks need to be valid, which requires all the gas and value send by accounts to actually be available for the accounts, and all signatures to be correct.(the latter implies you need the data send in the messages too)

    Ethereum will likely use 'GHOST' where there are 'uncle' blocks. However this is more about preventing non-main chains being worked than smoothness of payment for mining.
  • cobordismcobordism Member Posts: 6
    Hi, thanks for responding,
    @kershy In my head I viewed it not as 10 different blocks, but just one block with 10 different "signatures" - where a signature consists of a payout address, and a POW, i.e. a random number s.t. the resulting hash of the whole block is small enough to satisfy difficulty requirements.

    I did not think about what would happen if different people start working on a different set of transactions / contracts.

    Let me suggest what one might do to circumvent...

    We could say that a valid block consists of an ordered list of transactions, and an ordered list of signatures - where a signature this time consists of a (sub) list of transaction-id's worked on (only id - not the whole thing), a payout address and a random number...
    For this to be a valid block we'd require that it contain at least one transaction that was included in all signatures; and only those transactions are said to be 'confirmed' by this block.
    If a transaction is only contained in a subset of signatures so that it did not have a full block's worth of work done on it (say only 30%), then it shall only be considered confirmed after another block builds on top of this one (and this new block is not allowed to contain any transactions that contradict those in the first - even the ones with less than 100% POW so far). The gas reward for this transaction is only paid out after it is fully confirmed with 30% going to the previous block and 70% to the new one.
    Since a block starts with a hash of the previous one (including all of its transactions and signatures), the work put into the new block thus confirms the one before it, as always.
    @Jasper this should leave us still with a single chain of blocks.

    My idea was based on the premise that all we need to care about is the total work put into one block, not where the work was done.


    Having a system like this does change the difficulty calculation somewhat and the balance will be at a higher difficulty than if we had only allowed 'pure' solutions. This is not an issue however, the difficulty is what it is. The crucial difference is that my system allows distributed work.

    About Uncles
    Just read about Ghost..it does not seem as if my proposal interferes with Ghost in general. We can still include stale-block uncles just as before. An uncle has to be referenced by only one signature in order to count as included.
    A nuance might be the inclusion of incomplete blocks. Say we were working on a block and we had 90% of our work done and were missing just one signature; but then someone else comes along and publishes a complete solution leaving our 90% complete block orphaned.
    It would seem that this 90% block should be a perfect candidate for inclusion as an uncle in the next layer - and it only receives 90% of the reward it would get as a completed block uncle.

    ...as I'm writing I'm noticing all kinds of subtleties... I need to think more about the exact payouts and the incentive structure....

    I'll write more later, but for now, please comment and criticise and make suggestions.

    c.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    So basically instead of one solution, you have signed other lower-difficulty solutions. This doesnt decrease the overall difficulty much, because the expected pay is still the same, and those solutions would likely be found anyway.

    Picking a number of like 100 solutions does increase the size of a block, not very fast, but nevertheless. 3/sec on bitcoin right now or something, on ethereums block time, 180, so that would be bad early on.

    A 1/10'th difficulty only on average has something like 10 solutions floating around by the time the real block comes around. It may be less, in which case the miner has to wait before being valid. This decreases the overall difficulty, decreasing security, and in the meanwhile another miner may find a no.1 solution, so it increases splits.

    It may also be more than ten, which gives the miner a choice between them. This causes a super-linear reward, because it makes sense to choose your own ones, and a big miner is more likely to have 1/10'th solutions aswel. Could try counter this a bit with by not allowing the same public key too also get the 1/10'th solutions, and have a public key only count if it has 'pubkey initial solution'. Then you cant easily use many different public keys to mine. However, everyone has to get the pubkey initial solution and then some useful solution, so it is even more super-linear.

    This could use throwing math at, but i dont have any confidence that will lead somewhere useful.

    That bitcoin scalability paper is quite involved, i must i admit i havent gotten through it yet. Tend to agree that it seems unlikely they interfere much, although uncles may use the same lower-difficulty signatures as the main ones!


  • cobordismcobordism Member Posts: 6
    Thanks Jasper,
    I've also come to find too many problems with my idea. For example, I believe it will make the problem of selfish mining worse.

    Suppose we are in the simplified setting where every block requires 100 signatures. I mine on a block and find maybe 30 valid signatures while the rest of the network found 70. I keep my signatures secret and start mining the next block. By the time I find 6 more for the next block, the rest of the network has reached >95 for the previous one. I quickly publish the last block 70/30 with 30 of my signatures to ensure I get 30% of the payout and then I also publish at least 1 new signature for the next block to incentivise people to add signatures to it (as opposed to another, incompatible block). I keep the other 5 secret for now... and repeat.

    The more I think about it the more complicated it gets. Especially the problems of dishonest players and the role of propagation time make things difficult for me.
    I read about p2pool yesterday and my idea seems related. In fact collecting 100 signatures at lower difficulty is somewhat like running a global p2pool as long as we can ignore propagation times....maybe.

    Also, I'm sure that many people much smarter than myself have though about these things.

    sighh..


    I don't like the centralisation of mining in bitcoin. There are troubling rumours about ghash.io and it doesn't sound like people are taking this seriously enough.... at least not in the general (bitcoin) public. Even if they started out honest, power corrupts. Remember even people a central to bitcoin as Luke Jr, have abused their power as pool admins.


    What are the latest thought about ethereum? I hear some hybrid POW/POS? Dagger/ Ghost? ...or something with storage like Permacoin?

    best wishes,

    c.


    PS what is the bitcoin scalability paper to which you refer?
  • eaglgenes101eaglgenes101 Member Posts: 43
    Or simplest option: Reduce the incentive to be in a pool by making the probability of a payout fairly high and reducing the cost of mining so that miners with short budgets don't incur too much risk.
  • AcysbibAcysbib Member Posts: 54
    If you instead make it so each block can be split as long as there are enoúgh transactions with the signatures... And make it so the blocks can address several blocks back for validations, like ethereum does for uncles... And allow the chain to validate transactions 5 blocks back, or ten, or 5000 whatever it takes to make the model work, you might actually be able to break up the difficulty and the rewards for the difficulty worked at each level... The more blocks back, the lower the difficulty to jump into payments... As people would, in theory, be able to confirm signatures from old blocks (no more than 50 I would say... 64 maybe...) Adding to security, and those partial hashes could be added to the new main block via publication/confirmation. Granted, we are talking minimalistic rewards for mining old signatures with lesser hardware, but theoretically, that could be the stepping stone fore full node proof of stake. And a system that promotes payouts at almost every level of hashrate shouldn't harm the network. Once a block has reached full mini-epoc (5-64 blocks) the rewards for transaction fuels and confirmations on transactions are finalized. The block can be dumped into the "block chain" and since the blocks that are added to the block chain are several blocks ols, and the older they get diminishing rewards on the difficulty lowering, so as to discourage big mines from mining blocks just before placement to get sigs in the new block... While still leaving it open to anyone who couldn't mine a share on anything else before it gets set.

    It would make the rewards somewhat linear, but I cannot think of something to change it so hardware put in = payout in proportion... Not without breaking a lot of stuff...
  • JPSJPS Member Posts: 63
    Gravedigging

    When someone posts on a very old thread on a forum, it is called gravedigging.

    Gravedigging is frowned upon because the topic of the thread is usually dead - hence the term gravedigging.
  • AcysbibAcysbib Member Posts: 54
    Found it on Google... Didn't see age until after I posted... Sorry
Sign In or Register to comment.