[Antioch] Status Update (Jul-Sep 2020)

Quick update as most of my effort has been around getting things ready for HF3 aka v4.0.0.

Spent a few days last week investigating a bug that we identified in the way we handle params in the get_kernel_v2 api call. On the surface it appeared to be related to missing outputs but it was eventually tracked down to some dubious param handling when searching for kernels.

Fix was just merged to master and 4.0.x branches.

We are in the process of tagging and releasing v4.0.1 to include this fix. Announcement for this will be going out later today.


Also spent some time looking into what would be involved in modifying transaction inputs to only include the output commitment. We currently require the output “features” in addition to the output commitment when spending an output. This is redundant data in the context of both transactions and blocks. If we can fid a way to clean this up then it will help simplify the path toward supporting “duplicate outputs”.

As we currently enforce uniqueness in the utxo set this is not a consensus change, but it does introduce some complexities if nodes need to support both variants of transaction inputs during block propagation on the network.


Finally - spending time thinking about and discussing “replay attacks” and “play attacks”.
We still don’t have community consensus on the best approach to tackling this, but we do have a clearer understanding of the problem.

5 Likes

Quick update on what I’ve been focused on over the past couple of weeks.
There have been a lot of in depth conversations around planning and scope for the final scheduled hardfork in January.
Simply keeping on top of these has been a full time role.

One thing we know we want to do is remove the redundant input features specified in both transactions and blocks. We “spend” based on commitment and we currently enforce uniqueness in the utxo set so it is technically redundant to require a transaction to specify the features byte of the output being spent.
Ideally we can get rid of this dependency and simplify transaction and block serialization.
This is not a consensus change but p2p serialization is complicated here by the need to support backward compatibility for existing peers.

PR in progress here but it is a large PR with some invasive changes -

This is going to be tough to review and I’m still not entirely happy with the changes involved.
Off the back of this I took the opportunity to refactor and cleanup some code.
These were extracted as separate PRs -

I want to spend some time this week breaking the big WIP PR apart.
I am hopeful we can get this split out into a couple of smaller self-contained PRs that will be easier to review and merge.

If we can get this finished up this week then I can move onto whatever the next priority is for HF4.
And this is going to involve thinking a bit more about scope of work over the next few months.

8 Likes