What do we do a day before Christmas? We write NIPs. https://github.com/nostr-protocol/nips/pull/1658
Discussion
Yes!
Beautiful!
🎄🫡
A baby step to add exchange features to #nostr .. amen !
I’m curious why we need this as a NIP? We could create a bot that does all the calculations and posts it to nostr. Or multiple accounts for different kinds like commodities, equities, etc. Could do it all in terms of sats too. Might be useful in case the USD loses value or something.
Yeah, you can do all that and post to Nostr as Asset prices as designed by the NIP.
We code.
Published my first app on Zapstore this morning.
Now going to migrate from Alby shared hub as it's going to be deprecated in a few days.
It never ends.
Excellent. I will need this to create nostr-based ehash exchanges.
You didn't actually say anything about your link, and I'm not clicking a GitHub link, but there happens to be a preview in my app that says "asset prices by vitorpamplona" (makes me wonder if primal used my device's internet connection to load that from GitHub)
When you say "asset prices" as the title of the nip it sounds like you want a simple database format for tracking real-time updates in a data value, but with the spec saying it should only be used for asset prices?
NIPs that would make sense for this topic would cover a commodity market where you can submit bids and asks for an asset, or a simple database format for tracking real-time updates in any data value in general
Not worth clicking a GitHub link to find out if I'm missing anything on this one tho
Yes, Primal already downloaded the whole page to get the opengraph tags and show the preview. "Not clicking a GitHub link doesn't make any sense". Your phone already gave your data to GitHub.
But I didn't let GitHub waste my time, I made you do that yourself 🤙
I think this is close to what DLC's need, if the feed publisher uses fixed timestamps, eg something that is always on the hour and minute, 12:00:00 13:00:00 14:00:00 etc for an hourly price feed.
That way, the exact format and content of the possible prices can be determined ahead of time when creating the DL contracts.
Oh, we probably can't use ASCII prices? This may be better for categorical outcomes.
Would this be too far out of scope from what you originally had in mind?
Interesting... What's an ASCII price? But yes, we can use another format if it can enable other uses.
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.