suemto

I'm designing the non-interactive transaction feature plus stealth address feature on node. First of all, we must agree that a Hard Fork will be there to make these features take effect from a block height. And then, an important "backward compatibility" topic comes here!

Gernally speaking, we can take advantage of the HF(Hard Fork) to break most of backward compatibility, simplify a lot of version handling issues, such as nodes compatibility (old version nodes will be splitted from the new version nodes network), wallets compatibility (old version wallets can not work with new version node), etc. Any backward compatibility need special handling on the version conversion which need extra efforts and complexity. Let's have a detailed list here:

node backward compatibility

1. Suppose the HF node version will be v6.0, and the old versions are v4.x and v5.x.
2. Suppose the HF will start from block height 768,000 or about 1 May 2021. (quite draft number here, to be changed.)
3. Nodes with v6.0 will build

suemto

I am formally hired by MWC community as one of the fulltime developers from 1st Nov. 2020. First of all, thanks for all of your donations and support in this open community!

I will update the progress here from time to time, normally monthly or weekly but not strict. This thread is for the remaining time of 2020, there will be another thread for next quarter.

1st week

Not much in the 1st week, the main works are these:

• Start a little on the code framework, main coding is committed into mwcproject/mwc-node#24. These initial code can help to figure out the picture of the detailed workloads on each related module. I'm not trying to make the code works at this moment, just trying to touch everything related.
• Backward Compatibility draft and discussion on here (I will move it into the Forum once @privateidentity set up forum f

suemto

Estimated Task Lists:

• Node:
  • Documentation for NIT and SA(Stealth Address) features
  • Rebase (Chery-Pick) from Grin for latest works there
  • Security lib (rust-secp256k1-zkp) rebase and adaptation for NIT and for SA feature
  • Keychain adaptations for both features
  • TxKernel evolution (consensus broken)
  • Transaction structure evolution (consensus broken)
  • p2p message evolution (consensus broken)
• Validation logic in Transaction/Block/Chain