I forgot that this needs D16687 to be sorted out first

I forgot that this needs D16687 to be sorted out first

remove dead/commented code (the todo is done in a couple of commits, and is not critical)

restore coercing secret_exponent to int (see D14490)

rebase

use GENERATOR and POINT_AT_INFINITY constants. These need to be placed after the ECPubkey class is defined.

Use the constants GENERATOR and POINT_AT_INFINITY rather than functions.

properly handle point at infinity

properly hand point at infinity (not an error)

point at infinity shouldn't be an error on the ECC side, this needs some more work

rebase

rebase

rebase

rebase

rebase

replace the magic 32 number with a constant

rebase

fix fusion.py

this silently breaks fusion

and more... hopefully that's all of them

and another one

i missed one

Build build-chronik-plugins failed with exit code 1

It is mysterious. I don't see any explcit error except for that one.

use a verb in the function name, as per suggestion

I missed one

review items

We figured out my issue for running the explorer, I wasn't running cargo run in the right folder.
The result looks good, each UTXO shows the correct token now.

The code looks good as far as I can tell, but I'm having trouble running the test plan to check the result.

with a nit in the test

OK. It requires python >= 3.8, which is fine. I added a suggestion about an alternative way to pass the input data to stdin, your pick.

I tried adding a .prettierignore file to web/explorer with a explorer-server/templates line, but it does not seem to have any effect, prettier still messes up the html files in this directory. So not sure how to what I suggested.

I agree that it looks a lot more readable like this, and everything looks good to me. I'm just wondering whether applying markdown formatting to html files makes sense in the first place. Does it add anything useful vs just disabling prettier altogether for this project?

rebase on latest master

use Sha256d instead of [u8; 32] everywhere and use integer arithmetic in branch_length

Looks good.
As discussed above, there is some ambiguity about TX_AVALANCHE_RECONSIDERABLE currently only being used for non-finalized conflicting txs (tx added to the TxConflicting pool). The pool will need to be renamed if/when we start adding other type of transactions to it, but that can be done if/when needed.