Interesting... What's an ASCII price? But yes, we can use another format if it can enable other uses.
Discussion
Sorry, by ASCII, I meant the price is encoded as a string and JSON.
In practice, DLC numeric outcomes has a very complicated format, I don't know if it's possible to shoehorn that into your proposal:
https://github.com/discreetlogcontracts/dlcspecs/blob/master/NumericOutcome.md
Yeah, price is a string.
On the DLC, can we add other tags to facilitate?
Apologies, I think I need to retract my link above - that describes the work that clients have to do. Oracles don't have to do all that, though they do sign prefixes of the numeric outcome instead.
I suppose having a tag could work, but it looks like I'm at the limit of my knowledge on DLCs here.
In looking around, I also found this,
https://github.com/nostr-protocol/nips/pull/919
It may have more work in it, but not I'm sure if the PR is still active.
nostr:nprofile1qqs0awzzutnzfj6cudj03a7txc7qxsrma9ge44yrym6337tkkd23qkgpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgewaehxw309akxjemgw3hxjmn8wfjkccte9e3k7mf0qy88wumn8ghj7mn0wvhxcmmv9uuxfel8 was the last to touch that.
A numeric DLC oracle publishes a set of nonces, one per digit, for some future price/time/asset-pair event. Then when that time rolls around in the future, it signs each digit of the price using one of those pre-announced nonces, plus the oracle's static signing key. I think nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq3qamnwvaz7tmwdaehgu3wd4hk6tcpz9mhxue69uhkummnw3ezuamfdejj7qghwaehxw309amxjar0wghxummnw3erztnrdakj7qpqgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqyw43nv 's approach here is to simply sign a price inside by virtue of its inclusion in a signed nostr event object.
I really like the NIP88 proposal you linked, i've done some work on it and the draft seems like it'd fit most people's needs. I'd be in favor of standardizing the oracle events (kind 88 and 89), but not the DLC offer/accept events (kind 8888, 30088). I think we should spend more time improving the performance and privacy of the dlc specs before standardizing those messages downstream in Nostr.
The oracle messages are important to get started on right away, because without a vibrant market full of trustworthy oracles, nobody is going to use DLCs. Walk before you run, right?
https://github.com/nostr-protocol/nips/pull/919
perhaps one day, my nostr client can fetch announcements for tomorrow's bitcoin price from 9 different oracles, and use it to create a multi-oracle DLC offer which anyone on the same relays can accept. But for now i'd be happy with simply having nostr as an oracle platform which other apps can build off.