0

The game

I found a game where each gambler needs to pay 0.02 ᴇᴛʜ to register a secret before the game before the games switch to status==reveal each day.

Then, during the status==reveal period no secret can be registered but each gambler who is revealing the secret behind the hash they registered is increasing a ++revealedcount counter. The person making revealedcount==5 is awarded the daily price (revealedcount is reset each day).

Currently, very few peoples are playing the game or at least, nobody seems to be playing it automatically.

How I’m thinking about winning each time

One way I’m thinking about is to pay 5 times 0.02 ᴇᴛʜ for 5 differents commitments and when status becomes reveal, then, post the reveal transactions in batch with a high fee and using an increasing gas price between each of them in order make sure I’ll get the transaction making revealedcount==5 (the price would offset the loss of the other 4 lost reveal tickets).

The problem

Nobody seems to be doing this currently and I think there’s might be a reason : The 5 transactions I will post may have the highest fee, but they will be far to fill the BLOCKGAS limit. This means there will be plenty of room for other transactions in the same block which will also include transactions from competitors on the same game.

While this the transactions paying the highest fee which are included inside a block first, is it the same inside a block ? I mean, does the transactions paying the highest fee are processed first inside the same block ?
Or rather what’s the behavior of the top mining pools ? Are transactions from the same Ethereum address grouped together regardless of their fees ?

Community
  • 1
user2284570
  • 1,008
  • 1
  • 12
  • 30
  • You don't need 5 transactions, you can do it all (5 registrations and 5 revealings) in a single atomic transaction via a contract function (which you implement and deploy). At least according to your own description of the system. – goodvibration Apr 18 '20 at 16:27
  • @goodvibration nope. First, there’s the timing based on the blocknumber for setting the status global storage variable which as I explained makes it impossible to post the registration and the revealing at the same period of time. Then tx.orign must be equal to msg.sender inside the isHuman modifier. – user2284570 Apr 18 '20 at 16:37
  • @goodvibration even if it was the case, this doesn’t change the problem as a miner can choose to process a competing transaction first with a lower fee first inside the same block. Having the higher fees than others will make my transaction will be included in the next block but this doesn’t prevent competing transactions from paying a lower fee than mine while still getting mined into the same block. – user2284570 Apr 18 '20 at 17:32
  • @Ismael mining pools tends to use custom software. This question is about what s the ordering for most blocks being mined. – user2284570 Apr 24 '20 at 15:08
  • @user2284570 the question provided by Ismael does provide an answer that is generic and not geth / parity specific, please see it here: https://ethereum.stackexchange.com/a/27399/16 – SCBuergel May 08 '20 at 09:06

0 Answers0