You are viewing a single comment's thread from:

RE: Theory: How to side-step soft-consensus

in #steem5 years ago

Ok I am doing some phone math with me so bare with me. Let’s say only 1 witness is running this code.

There is a 1/21 chance they are in the last position and a 1/21 chance they are in the first position in the next round. 1/21 * 1/21 = 0.00226757 probability of this happening.

123 second per 2 complete rounds / 0.00226757 = 54243 second before this occurs = 15.068 hours.

So we could expect this transaction to go through in less than one day. Interesting. This would obviously be faster if more than 1 witness are running this code.

Sort:  

Also, if you're ok with the possibility of more than one transaction getting accepted, you can shorten the wait to 66 seconds, if it's well-timed so that the transaction is broadcasted in the final block of the round.

The problem with doing this is if you're doing transfers, there's a chance that while one transfer is being reversed, and you move on to the next round attempt, both are accepted.

So 126 is good for attempting one-and-only-one transaction. Otherwise 66 is good, but slightly risky. And blindly spamming is probably also fine, but overkill, and not much more risky.

This makes me think it might be possible to predict a beneficial shuffle formation:

https://steemit.com/steem/@dantheman/steem-witness-scheduling-algorithm

Especially this point:

After 21 witnesses have been selected, they are shuffled using the block time as a seed to a random number generator.

Yes that would be a major improvement. So you think it might be possible that if a libre witness is randomly assigned to spot 21 of 21, they could create a block that makes the below-20 witness mine first in the subsequent block?

Is there any protection to the other top 20 witnesses pretending the libre witness was offline and discarding those blocks?

Is there any protection to the other top 20 witnesses pretending the libre witness was offline and discarding those blocks?

I believe they are already "protected" otherwise that would cause a fork.

Oh wow. Great find. I can’t believe you were able to dig that up.

Check it out:

https://steemd.com/b/42329700
https://steemd.com/b/42329701

Two sequential blocks from backup witnesses. How could this happen unless the were from two different shuffle rounds?

Problem is, the first block did not contain censored ops, so this opportunity was wasted.

It would have to be two different rounds I would think. For a given block, is there a way to know which spot in a round it is?

I was thinking about this some more. You would want to submit the operation on the last block of the round, but you would first need to know when that is, otherwise your timing would be off. Correct?