Replace u64 with Amount type in TxOut

[sgeisler]

Some places, most prominently TxOut, were still using u64s for amounts (in sat). This PR replaces these with the Amount newtype and also implements the consensus encode traits for Amount to make it all work.

[sanket1729]

Does it make sense to restrict the Amount type with a MoneyRange check? https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/amount.h#L26

This might leak APIwise and will most probably be followed by unwrap() for all use cases. Might also make it awkward to model -1 amount in null TxOut creation.

Side note, also conflicts with #598.

[sgeisler]

@sanket1729 At which level would you want to enforce MoneyRange (I think in rust-bitcoin that would be max_money(…))? On the TxOut level by making value private? Or by introducing some newtype? Or just opportunistically e.g. in consensus decode without really guaranteeing the invariant?

As a side note, I think we represent none-amounts as u64::MAX.

[dr-orlovsky]

utACK 3b5f89f

I think that Amount type should be definitely improved with MoneyRange-like functionality, since we guarantee at API level that Amount can't exceed consensus value (having internal value made private) - but that's probably better to do in a separate PR.

[dr-orlovsky]

Needs rebase

[dr-orlovsky]

utACK c193bc7

[sanket1729]

utack c193bc7. Needs rebase

[sanket1729]

My thinking was similar to what dr-orlovsky suggested. But I think we need a more careful review of bitcoin core codebase to make sure none-amounts don't do random things.

[sanket1729]

In the interest of taproot release, postponing this again to 0.29 :(

[tcharding]

Hi @sgeisler, this seems like a change we want, do you have time to work on this still? I have rebased it locally, if you don't have time to work on it feel free to close this and I'll re-open and shepard it in for you (incl. co-authored-by tag).

[apoelstra]

I believe that @sgeisler has left this space and somebody else will need to create a new version of this PR.

[tcharding]

Sweet, cheers.

[sgeisler]

incl. co-authored-by tag

No need, probably easier to just redo it anyway with all these conflicts.