Hello, I'm new here.
I'm inspired to get involved so I have been reading the recent discussions. There is a lot of talk about 0-conf and how to prevent double spends.
One idea I have not seen mentioned is enforcing causal ordering. (I apologize if this has already been discussed and dismissed, but I didn't see it. (Description of causal ordering)
If we were able to enforce causal ordering of transactions during the transaction-propagation phase, this whole discussion would be moot, because we would have a definitive answer about which transaction happened *first*, and so the protocol could enforce the "first seen" convention as part of the consensus rules. Of a pair of transactions sharing the same input, only the "first seen" would be a valid transaction.
Now I know that this is a distributed system and clocks are wrong and timing is never guaranteed. But there has been some recent developments (in the last 5 years or so) regarding this problem. Google came out with Spanner and TrueTime a while back which purports to solve the problem of inconsistent clocks, and more recently there was a paper describing "Hybrid Logical Clocks" (see the HLC paper and a blog post describing the gist). I wonder whether this would work in Bitcoin Cash?
My initial thoughts about pros and cons of this approach:
Geez this got long. Trying too hard to make a good first impression I suppose.
I'm inspired to get involved so I have been reading the recent discussions. There is a lot of talk about 0-conf and how to prevent double spends.
One idea I have not seen mentioned is enforcing causal ordering. (I apologize if this has already been discussed and dismissed, but I didn't see it. (Description of causal ordering)
If we were able to enforce causal ordering of transactions during the transaction-propagation phase, this whole discussion would be moot, because we would have a definitive answer about which transaction happened *first*, and so the protocol could enforce the "first seen" convention as part of the consensus rules. Of a pair of transactions sharing the same input, only the "first seen" would be a valid transaction.
Now I know that this is a distributed system and clocks are wrong and timing is never guaranteed. But there has been some recent developments (in the last 5 years or so) regarding this problem. Google came out with Spanner and TrueTime a while back which purports to solve the problem of inconsistent clocks, and more recently there was a paper describing "Hybrid Logical Clocks" (see the HLC paper and a blog post describing the gist). I wonder whether this would work in Bitcoin Cash?
My initial thoughts about pros and cons of this approach:
- after waiting a few seconds to see whether there was a logically-earlier transaction submitted somewhere else on the network, you could be near-100% certain that the transaction you got is not a double spend. The only uncertainty is how long it takes another transaction anywhere on the network to propagate to your node. This completely eliminates the "minutes later", and realistically even the "seconds later" transactions.
- This would be a hard-fork change to the consensus rules, I believe. Because it changes the definition of a "valid" transaction.
- I think the transaction would have to have the HLC timestamp as part of the transaction, since now the transaction will live or die based on that timestamp. Would that mean changing the transaction format? Is that a harder sell?
- Adding to the above - this would also add a few more bytes to the payload of a transaction.
- HLC does use a "physical clock" as part of its algorithm. So the nodes would still have to be synced to something like an NTP server, and should be synced to within some delta. Would we have to bake the NTP chatter into the protocol as well? I don't really know what the behavior would be in the presence of a completely wrong clock on one of the nodes, which is all but guaranteed to happen.
- Maybe HLC is not the right algorithm but there are many other algorithms for partial ordering for distributed systems -- Vector Clocks, Lamport Timestamps, etc. We could try to figure out a scheme that works for this particular use case.
- I think I read that there is a "transaction sequence" field that is currently unused because it is always maxed out to help prevent double spends. Could we use that field to hold the timestamp?
Geez this got long. Trying too hard to make a good first impression I suppose.