[feature]: Add a 'memo' or 'custom' property in QueryAssetRatesRequest v4.2

[lukegao209]

After adding a memo or custom field to the QueryAssetRatesRequest, the PriceOracle can use this field for business logic decisions and provide different pricing based on the type of transaction. For example:

1.	The user is just transferring assets between two tapd instances;
2.	Paying a BTC invoice using an asset;
3.	The user is conducting a P2P exchange through an invoice.”

This approach would allow for more dynamic and context-based pricing models.

[lukegao209]

@guggero will this issue be added to V5.0?

[guggero]

cc @dstadulis

[ffranr]

I believe this feature would be an excellent addition for price oracle developers. Here’s how I propose we approach it:

A typical wallet tapd node would have a very different relationship with its price oracle compared to a large edge tapd node. The edge node's price oracle could formulate asset rates with greater context based on the edge node's books, providing deeper insight. In contrast, a wallet node would function as a light client to a public, naive price oracle service.

To account for these differing relationships, I suggest introducing a command-line argument flag named --self-hosted-price-oracle. When set to true, this flag would allow the price oracle to handle queries with additional context. When unset, the wallet node could retain its privacy by interacting with a publicly shared price oracle without revealing sensitive information.

The additional context we could provide to a self-hosted price oracle includes:

1. Counterparty Peer Public Key
   Refer to this pull request. I still believe this would be valuable for debugging during price oracle development and for edge node logging flexibility.

2. Intent Field in QueryAssetRatesRequest
   Add an Intent field to QueryAssetRatesRequest. This field should be a string enum with predefined values, while also allowing custom messages. Here are the predefined enum values I suggest:

   • PayInvoiceIntent: Used when the RFQ request initiator peer intends to pay an invoice using a tap asset.
   • PayInvoiceRespIntent: Used when the edge node is determining an acceptable response rate to the RFQ request initiator peer, where the peer is attempting to pay an invoice using a tap asset.
   • QualifyPayInvoiceRespIntent: Used by the RFQ request initiator peer when qualifying the accept rate returned by the edge node in response to a pay-invoice flow.
   • RecvPaymentIntent: Used when the RFQ request initiator peer intends to receive a tap asset as payment for settling an invoice.
   • RecvPaymentRespIntent: Used when the edge node is determining an acceptable response rate to the RFQ request initiator peer, where the peer is attempting to receive payment for an invoice in the form of a tap asset.
   • QualifyRecvPaymentRespIntent: Used by the RFQ request initiator peer when qualifying the accept rate returned by the edge node in the receive-payment-for-invoice flow.

   Some of these values may not typically apply to wallet nodes, as they often do not set --self-hosted-price-oracle. However, some wallet nodes might still choose to use a self-hosted price oracle in certain cases.

3. Rate Hint
   A rate hint is currently included in QueryAssetRatesRequest for each query. However, for a wallet node querying a public price oracle service, providing a rate hint may not be appropriate. In such cases, the public price oracle acts more like a simple price ticker, and including a rate hint could pose a privacy risk without offering any meaningful benefit. Since tapd already has an internal threshold to qualify acceptable asset rates, I propose treating the rate hint as additional context, only applicable when --self-hosted-price-oracle is enabled.

[dstadulis]

This is great issue, lukegao209! Since v0.5 will be released imminently, including #1159 in v0.6 will be most apt. This feature highly valuable so delivering as soon as possible if valued by everyone. If feature delivery timing is critical for an immediate business need, additional resources might be able to be allocated to expedite implementation.

[lukegao209]

Thank you for your response! Based on our research, when users engage in asset swaps, buy/sell transactions, or pay BTC invoices, they often require different BTC price rates depending on the specific business scenario. I believe that adding this functionality would significantly expand the use cases for v0.5.

[ffranr]

During the community call (just now), a user requested that the peer identifier be made available to the price oracle to enable more favorable pricing. This could be achieved by providing both the price-requesting peer and the counterparty information.

[bitcoin-coder-bob]

Since the price oracle can be publicly facing we may want a way for the price-requesting peer to provably self identify. That way if I the peer am entitled to some preferred rate, that no one can impersonate me when communicating with the price oracle to get my special rate as well.

[ffranr]

Since the price oracle can be publicly facing we may want a way for the price-requesting peer to provably self identify. That way if I the peer am entitled to some preferred rate, that no one can impersonate me when communicating with the price oracle to get my special rate as well.

@bitcoin-coder-bob In my opinion, the idea has merit, but I would caveat that it addresses a privacy issue rather than a permission issue. This is because the price oracle's price can ultimately be ignored by one or both peers during the RFQ process—it's more of a guide than an immutable truth. I think this idea relates to privacy because it could prevent a situation where another user pretends to query as a given peer, thereby protecting that peer's price preference from being leaked.