I can restore a user's old Phoenix history – and still be shipping a send button that will never work.
The awkward boundary following Boreas. Dusk mainnet shut down new Phoenix transactions when it switched on at June 10. Testnet was introduced at 4,000,000, on August 7. Rusk still carries on Phoenix decoders and historical execution support though, as old blocks need to be replayable.
So, now “my node understands Phoenix” doesn't mean “Phoenix is alive” anymore.
The wallet failure is evident. I restore historical state, unravel activity in old shielded send and leave a Phoenix send flow open, and it's all fine and dandy until the user signs. At admission, the node refuses the new transaction as Phoenix is retired for new execution.
I would split out the historical ability from the live ability in the client. Phoenix is readable for replay and accounting. The new spending should bypass the archive and go straight to Moonlight.
I'm caught in the backward compatibility trap. No code which preserves yesterday's Dusk state should be confused with the permission to create tomorrow's transaction.
#dusk $DUSK @Dusk
The awkward boundary following Boreas. Dusk mainnet shut down new Phoenix transactions when it switched on at June 10. Testnet was introduced at 4,000,000, on August 7. Rusk still carries on Phoenix decoders and historical execution support though, as old blocks need to be replayable.
So, now “my node understands Phoenix” doesn't mean “Phoenix is alive” anymore.
The wallet failure is evident. I restore historical state, unravel activity in old shielded send and leave a Phoenix send flow open, and it's all fine and dandy until the user signs. At admission, the node refuses the new transaction as Phoenix is retired for new execution.
I would split out the historical ability from the live ability in the client. Phoenix is readable for replay and accounting. The new spending should bypass the archive and go straight to Moonlight.
I'm caught in the backward compatibility trap. No code which preserves yesterday's Dusk state should be confused with the permission to create tomorrow's transaction.
#dusk $DUSK @Dusk
