feat(one-time-keys): first pass at adapting DBCs to one-time-keys

[davidrusu]

This PR adapts DBC's to enforce one-time-keys by using the DBC owner as the spend book key.

Status:

• library building
• tests passing
• update mint REPL

[dan-da]

this was a lot of work / big change. nice job. couple high level q's/comments:

1. Since owner's pubkey is now the spendbook key, it would seem to me that this is truly one-time usage. eg if Bob invoices Alice and she pays to Bob's key twice and then Bob tries a single reissue with both DBC's as inputs, what would happen? I would expect that the entire reissue fails because the 2nd input would be considered a dup. If that is the case I can see it working technically, but as far as real-world usage, I have concerns/misgivings as there is a potential to accidentally create unspendable DBCs. It would almost seem better to also have an "unspent book" for tracking unspent DBCs, and the mint could thus prevent Alice from issuing two DBCs to Bob's single pubkey in the first place. Of course a global unspent book requires more space and coordination between mint sections, so may not be feasible.

An alternative model, that I believe @dirvine was suggesting is that multiple DBCs could be created with the same pubkey and they could all be spent, but only if they are all inputs to the same reissue operation. So that seems a sort of half-way to this design, but it precludes using the pubkey as the spentbook key.

2. Since owner pubkey has replaced the DbcContent hash as the DBC identifier does that mean there is no longer a proof of the spent DBC's contents in the spendbook? iow, previously was it important that the DBC's content's hashed to a stored identifier, because it seems we now lose that property.

[dirvine]

I have concerns/misgivings as there is a potential to accidentally create unspendable DBCs.

@dan-da I think we are fine here as the user will check the outputs are not to spent keys. The mint can also do that check to refuse re-issue if we wished, but likely not required.

Key derivation play a big part here though.