Contracts affecting miner behavior

JasperJasper Eindhoven, the NetherlandsPosts: 514Member mod
In a earlier thread, i noted that bets using psuedorandom values based on blockchain hashes can be affected by miners colluding with one of the gamblers. Basically if they have a winning block they can withold it. I also suggested a solution.(which i am sure many others would also have suggested, unless i am wrong, of course) (https://forum.ethereum.org/discussion/comment/2758/#Comment_2758)

Trying to calculate when the payout is good enough for miners to collude, i realized that the miners might not entirely withhold the block. They might also offer it the moment they see another potential block winner, depending if the bet went better/worse on the other block.(the whole point to wait is to see that) If they put it out there once they see it, and have enough eyes on the network to spot an adversary block, their block might still win.

In principle the order contracts are executed can affect the outcome, and people could put bounties for miners on that to.

I dont know what extent this is a problem. These actions are inhibited by the reward miners risk losing in their behavior, but with a 1 minute block time the reward in a block may be outstripped by transactions offering rewards. To be honest, dont know enough about GHOST and uncles, possibly it gives some protection, though my impression about uncles might actually save some of the block reward for colluding miners. Either way, it brings up that things can be connected this way.

Aside; i'll put the miner collusion calculation on the wiki later.(start a forum topic on it if you want)

Comments

  • mode80mode80 Posts: 64Member ✭✭
    I'm interested in your calculation. My unexplored assumption is that with 10,000+ nodes the 0.001% advantage gained by any one miner cheating is acceptable for small value bets.

    For large bets (lotteries) you'd have to worry about mining pool operators.

    I can imagine smart-contract based mining pools offering provably non-tampered operation.
  • JasperJasper Eindhoven, the NetherlandsPosts: 514Member mod
    Note: went a bit nuts.. It is long, and still doesnt cover it. Short of it is that 1) if random seeds are easily set, you're screwed, 2) if ?/2>B with B block reward, cheating by dropping blocks can easily occur, but cheaters can do better by just holding on to their blocks secretly. 3) really, the difficulty in estimating whether it will happen seems to rely largely on figuring how they may make deals with each other.

    Note2: also note that properly implemented promising H(R) and then later revealing R should protect that party against it completely. (described in the linked thread)

    To be honest i have some trouble analysing it. Looking at the case where you use odd/even timestamp. Essentially you have two groups, A, B if the miner is selfish(many miners are selfish) people from these groups can offer ethers for the result to go their way. The miner would choose the group that offers the most. (It is not like miners necessarily also do the bets)

    Now, if winnings[A] > winnings[B], then it 'ultimately' makes sense for A to give G=winnings[A]-winnings[B] because B will take anything at all above nothing. But A isnt a single entity, its a whole group, lets say they win a_i each. How much each gives is a Schelling point.

    Assuming some honest entities, it becomes more complicated. However, anyone ever offering anything to a selfish miner will be able to affect the outcome. There may be a big organization for betting that can certainly do it.

    For smaller parties the cost and uncertainty whether their payment was the cause might hinder the effect. I dont think we should count uncertainty whether a bad thing might happen as a reason to feel safe about it..

    I have figured a list from worst to less worse:

    1. Random seed partially settable by miner.
    2. Random value(the above) settable by miner.
    3. Miners drop blocks for random values.(hashes used as seeds)
    4. Miners hold-on-to blocks, and try push it onto the blockchain at the last second if they see a competing block that isnt good enough for them either.

    1. is worse, especially if the is a range the random seed is is large. The reason is that the miner can then scan for many more possibilities than just A/B, he cant comply to every bribe, but fewer bribes are incompatible with each other. All he needs to do is can 'mine' the seed possibilities for the best ones. For srand for 10^6 tries, i get 23 even values at seed 681480.

    3. and 4. need more treatment, but in those cases all that is needed is enough difference in outcome for a single party to warrant the(potential to) drop a block reward. To indicate when this may start happening for multiple belts, you can look at equally valued independent bets with the same odds. These follow the binomial distribution, at large counts, for N attempts at probability p the variation of numbers of outcomes is σ?sqrt(N)⋅p⋅(1-p) so if the block reward is B and bet size is S, expect trouble with Sσ>B, at least when there is a single party involved.

    Could look at it more generally f(r) is the frequency of reward r in the bets and h the reward in a winning block, if <r> >B+h you can drop a block.

    But you dont have too. You can place blockchain watchers around the world, and if a competitor comes up with another winning block with reward c, it is possible that c<h in that case you push your block onto the blockchain just after you see it. If you have p probability of your block being the accepted one, you <r>=ph + (1-p)c which is higher than c. But the expectation of being able to do this also improves the chance that you would hold on to it aswel! (p depends on how quickly the network communicates, how interconnected it is, and how quickly you can respond.)
Sign In or Register to comment.