You are viewing a single comment's thread from:
RE: Steem Monsters Tech Talk - Part 3 - Now With More Decentralization!
To do that they would need to control the transaction id, the block id, and the previous block id of their purchase transaction. The transaction id is easy enough to control for a sophisticated developer, but the block id can only be controlled by the block producer (witness) who creates the block.
So in order to exploit the algorithm you would need to have at least two block producers collude when they are scheduled to create sequential blocks. I consider this to be sufficiently secure, but please let me know if you disagree or if you think I've missed something!
Are you sure a single witness cannot exploit the algorithm? It seems to me that adding the previous block hash doesn't actually add anything. In fact, the previous block hash is incorporated already into the current block hash.
An attacking witness would use the following strategy for a block they were slated to mine: cycle through potential transaction IDs until it constructs a flush random seed. I'm not sure exactly how one can grind transaction IDs, but there are probably some fields that are arbitrary or could have multiple possible values.
Is it correct to say that witnesses can know which Steem monsters would be included in their purchase if its in a block they are mining? This would seem like an unacceptable characteristic in the long term.
Check out the links in my comment on my gist. IIRC some of those references attempt to address this issue.
Yes, I suppose you're right that the previous block ID doesn't really add any additional difficulty since it's already known. What do you think about using the next block ID instead of the previous one? It would make purchases take an additional 3 seconds or so to go through but I think that's acceptable.
I've thought about this a bit more and it's a hard problem to address. I also realized witnesses don't need to be grinding their Steem Monster purchase transaction but instead could grind something related to the block composition that is difficult to detect, such as transaction ordering (i.e. the suspected method used for covert AsicBoost).
I think lookahead is probably better than lookbehind, in terms of creating a randomness beacon that cannot be controlled by a single witness. But just a single block lookahead is probably insufficient. For example, a witness could submit their transaction one block before they were scheduled to mine. Then they would be able to engineer the lookahead block to yield a flush Booster Pack.
I am not sure if there is a perfect solution, but raising the bar to require two colluding witnesses most of the time would be a start. Perhaps this could be done by having each block hash following a transaction delay the settlement by 0, 1, 2, or 3 blocks. Perhaps the following pseudo-algorithm:
This seems overly complicated and only partially effective. Maybe there is a way to get a randomness oracle on Steem, that say posts the NIST Randomness Beacon for the timestamp of the previous block. Then you could do a lookahead that takes transaction id, transaction block id, and randomness beacon from the oracle for a lookahead block.
I'll look a bit into some existing literature such ast Proofs-of-delay and randomness beacons in Ethereum.
Another thing to consider is that a "flush booster pack" would have to be "mined". You would need to add some type of nonce into the block and then generate the hash, run the card pack generation code, check the results, update the nonce and repeat until you find a pack that is good enough for you.
You have at most 3 seconds to do this or you will miss your block. The more packs that are purchased the more computation this would take. The whole idea behind DPoS is that we trust the top witnesses not to do things like this. If it's found that a top witness is doing this, then they would lose their votes (at least in theory), and then not be able to produce more blocks.
So from that perspective I think what is implemented now is probably sufficient.
I'm guessing you could probably evaluate 1000s of booster packs by grinding transaction order within a 3 second window. However, this also brings up another potential solution: using a key derivation function that takes 3+ seconds of computational work to generate a random seed from transaction & block info. This would make it impossible to evaluate booster pack outcomes within the 3 second interval. airBitz / Edge uses a similar approach to slow down brute force attempts to break into a wallet.
That's an interesting point about how DPoS does provide some protection because witnesses have their future earning ability at stake via their reputation. In a proof of work system, there is a large cost to forgoing a PoW solution because it doesn't generate the proper random seed. However, with PoW there is no reputation cost since blocks can be mined anonymously. In Steem there is no immediate cost to picking a block with the right block hash. However, there is a longterm reputational risk if you get caught.
It will be interesting to see if good cards start occurring more than would be expected by chance!
Dear @yabapmatt
I tried to contact you via discord... There are a lot of bots out of control without upvoting due to a bug in the steem blockchain. Please, have a look at the post:
https://steemit.com/witness-category/@mahdiyari/why-steem-was-down-blockchain-bugs-and-problems-witness-and-seed-nodes
I guess you should change the nodes on which the bots have being connected.
Regards
3 seconds doesn't sound too bad, it could be "hid away" with some animation.