Add oracle_announcement_v1 type for simplified oracle attestation

[matthewjablack]

At the last DLC Spec meeting, the Oracle Attestation Computation Change Proposal was discussed. With no serious concerns over the new proposal, there was consensus to switch over to this new scheme which improves performance for CET generation for Multi Oracle.

The current oracle_announcement_v0 TLV specifies:

signature is a Schnorr signature over a sha256 hash of the serialized oracle_event, using the tag announcement/v0

EDIT: The new scheme removes the need to hash the message in attestation computation. Perhaps an oracle_announcement_v1 should be introduced to account for this new scheme. There should also be some caution messages specified in the spec to ensure for clients to verify which version they're using to avoid outcomes that can't be attested.

[Tibo-lg]

First note that there is a PR open to implement the change: https://github.com/discreetlogcontracts/dlcspecs/pull/153

But reading your message now I worry that we might need to stay backward compatible? I feel it would be really nicer not to have to at the moment because there are still quite some incoming changes, but it's maybe something that should be discussed.

The new scheme removes the need to hash the message.

So the announcement still needs to get hashed before being signed, because in that case the point is to prove that the oracle has actually produced that message. Where the hash is removed is in attestation computation, where the oracle indicates which outcome number is the final one. So since the outcomes are defined in the announcement it is really important that it be properly signed.

[matthewjablack]

Where the hash is removed is in attestation computation

Ah yes, I meant during attestation computation. Thanks for the clarification @Tibo-lg.

At the moment there are quite a few implementations and announcements that do not use the new no hash oracle attestation (i.e. https://oracle.suredbits.com/). I agree that it would be a lot nicer not to have to be backwards compatible, but I don't know if this is possible with current implementations out there.

Based on my conversation with @Christewart the best migration path we saw is:

1. v0 announcement
2. v0/v1 announcements published by oracles
3. Slowly deprecate v0

[Christewart]

As Matthew says, i very much believe in this approach. We want to be transparent with breaking changes. TLVs give us this tool (that is the point of them, IMO)

If we allocate a new type for announcements, everyones software will easily be able to detect the change when de serializing announcements. Then they can make the choice of throwing an error saying "We do not support the new announcement" or in the future "We have deprecated v0 announcements and no longer support them"

If we try to re-purpose the old type, that isn't the case. I don't fully understand the low level changes going on, but I think the best we could do is try both schemes and see which one works? How is the alternative as transparent as bumping the TLV type?

Again, our goal should be to be as transparent as possible with breaking changes, making it easier for developers up the stack to understand what is going on. Especially in the early days of the protocol when changes are likely. If we have different TLVs, we can easily display a "version" on the oracle explorer which gives users some context of what announcements work for them and which ones don't.

[nkohen]

My plan has been to introduce a new TLV types for the new kind of announcement which has separated announcement and attestation keys as well as signatures by nonce keys of the announcement.

My plan is then to remove the old TLV types from the specification (possibly with a one-liner linking to an old commit of the specs). Point being that I don't think that the current announcement should be a part of the official specification, but there is nothing stopping its users from continuing to coordinate in non-spec-compliant ways.

[Tibo-lg]

Closing since we abandoned the no hash idea.