Draft: alternative to signer counter

[Gilthoniel]

Let's imagine the client transaction has a timestamp instead of a signer counter:

ClientTransaction {
  ...,
  Timestamp: time.Time,
}

Then a client transaction would only be accepted if all the following holds:

1. block_timestamp > Timestamp > block_timestamp - x * block_interval
2. Blocks in the interval [block_timestamp - x * block_interval; block_timestamp] do not contain the hash of the client transaction in the accepted transaction. And no duplicate of course.

That allows the client to create transactions without a shared state and it allows the conodes to verify the unique usage by window of x blocks. The transaction is drop outside of the window in any cases.

Note: shower thought so let me know if you see a way to break it.

[ineiti]

That was one of the initial ways to solve the #1442, but then it got rejected because the leader can censor transactions and the followers need to check for the whole window whether a transaction has already been applied or not.

[Gilthoniel]

Thanks for the reference.

Concerning the censorship, a leader can already drop any transactions it wants. It's not because of that replay attack protection that it will be able. A censorship protection would either rotate the leader or verify that transactions are passing so signer counter or timestamp doesn't change anything at this point.

Yes they need but keep x sets of hash isn't that expensive compared to the downside of the signer counter solution.

Of course => IMHO

[ineiti]

In the case of signer counter, if the leader refuses to include a transaction, a next leader can include it, even if several blocks passed.

In the case of a timestamp, you have to include the possibility that all malicious nodes in turn get elected as leader, before an honest node will include the transaction. So the window where you need to check the timestamp can get quite big and will increase with the number of nodes.

But, yes, including a timestamp is better from an engineering point of view, and I prefer it, too. But I lost that argument against the theoretical view of @LefKok ;)

[nkcr]

Where are we with this proposal? I am experiencing a lot of "got counter=N, but need N+1", which forces me to add some ugly delays and retry mechanisms...

[ineiti]

As this proposal is quite breaking in many ways and will probably insert new problems, I'd prefer doing something like #2145 .

In the meantime, you can add WaitPropagation, like here: https://github.com/dedis/cothority/blob/master/byzcoin/bcadmin/main.go#L145

Then you don't need sleep.

If you do the CreateTransaction in the same command/process, then you can also use byzcoin.Client.UseNode(x) where x is the first node replying from something like GetProof. By always contacting the same node, you assure that you get the correct proof from the transaction.

Where would be a good place to write this up? Or another question: where did you first search (which would indicate a good place to put it ;)?