Feature Request: "instant" transfers for common use case

[d-Martian]

Value: Ability for "Instant" transfers is a deciding factor for Monero adoption for many common practical use cases, even for zero-confirmations. If anything, for preliminary approval.

Issue: even without any confirmations, wallets aren't able to reliability receive a transaction in the mempool in a near-instant time frame.

this is due to the monero protocol:

• monero transactions propagate with no regard to where the nodes are that the receiver wallet is connected to.
• dandelion++ adds delay through several server hops in broadcasting of a transaction

Solution: wallet devs can solve this without any affect on monero protocol with this proposed workaround concept: local transfer of tx message from sender wallet to receiver wallet, and receiver wallet transmits to network.

Receiver wallet needs only verify the tx is accepted by its connected trusted node, which circumvents delay for network propogation for receiver.

Development: Local transfer: integrate components for animated QR generation & reading Handling of how sending wallet interfaces with nodes for best display

Use conditions: Sender wallet and Receiver wallet are physically in immediate proximity, or a trusted third channel is available to transmit an animated QR.

[SamsungGalaxyPlayer]

Wouldn't it be simpler to share a common, agreed-upon, third-party Monero node?

[d-Martian]

Wouldn't it be simpler to share a common, agreed-upon, third-party Monero node?

this could be a more simple solution to implement, pending a fast relay from the node mempool.

Perhaps the qr code for payment could include a remote node for the sender to broadcast to.

Would this be sufficient to reduce lag to < 5 seconds?

[SChernykh]

Wouldn't it be simpler to share a common, agreed-upon, third-party Monero node?

Monero node sends new transactions to connected wallets without delay only if it's not a restricted RPC (port 18081). Restricted nodes (port 18089) only send broadcasted transactions (Dandelion++ fluff phase), so there's still a Dandelion++ delay there. I'm not sure how sharing an unrestricted node credentials with basically everyone would work in practice.

Edit: disregard this. Seller can connect to unrestricted port (18081) to see all transactions immediately, buyers can connect to restricted port (18089) to send transactions.

[HeathenPagan]

In case we are talking about releasing a customer from the queue faster, does the vendor run a xmr node? If so can they allow customers to connect to the same node from their wallet so that the vendor's node confirms the transaction to both vendor and customer and lets the customer go? It is somewhat like providing wifi to customers. As customers are waiting in line vendor advises customers to connect to their node and synch their wallets. By the time customers reach the counter their wallets are fully synced and the transaction is processed by the vendor's node and both parties are sure that the node will send the transaction.

[d-Martian]

In case we are talking about releasing a customer from the queue faster, does the vendor run a xmr node? If so can they allow customers to connect to the same node from their wallet so that the vendor's node confirms the transaction to both vendor and customer and lets the customer go? It is somewhat like providing wifi to customers. As customers are waiting in line vendor advises customers to connect to their node and synch their wallets. By the time customers reach the counter their wallets are fully synced and the transaction is processed by the vendor's node and both parties are sure that the node will send the transaction.

That is essentially correct. Another way to put it would be that the receiver (vendor) is able to verify the sender's transaction is valid and correct locally (whether to a local node or a reliable remote node) prior to network propagation. This has no network confirmations, but the transaction portion is taken care of very quickly, and is very suitable for a wide variety of common use cases.

• Payment was accepted, but vendor still needs to provide service and can be alerted to any network confirmation issues.
• Where low value transactions occur and speed is more valuable than a low-risk of double spends which would be high effort and low reward IRL.

Let the transaction be snappy, or it's a barrier to adoption which is entirely unnecessary. Other forms of electronic payments have risks to vendors of reversals and other issues (e.g. paypal disputes) that are far more likely to occur than a double-spend in many common situations.

This also won't lead to any change for those who require confirmations as they see fit.

[d-Martian]

In case we are talking about releasing a customer from the queue faster, does the vendor run a xmr node? If so can they allow customers to connect to the same node from their wallet so that the vendor's node confirms the transaction to both vendor and customer and lets the customer go? It is somewhat like providing wifi to customers. As customers are waiting in line vendor advises customers to connect to their node and synch their wallets. By the time customers reach the counter their wallets are fully synced and the transaction is processed by the vendor's node and both parties are sure that the node will send the transaction.

I see this as a good explanation, as well. Ideally, the vendor would have their own node or could at least transfer an address:port to the sender in the request QR code along with the amount and address.

Dandelion++ helps shield all parties' IPs by default, and wallets let users connect to nodes they trust. This feature would opt-in privacy details only between sender-receiver that don't matter for in-person transactions.

To cover all bases, the sender can--in addition to sending the tx to the receiver's wallet or specified node--also transmit the transaction to the wallet's configured node to ensure payment. This can protect buyers from "shady sellers" by ensuring buyers can prove records.

• example: A vendor re-selling event tickets accepts the first offers but waits for higher bidders, withholding broadcast of earlier buyers' tx to the end of the payment-window and then not ever submitting/submitting late.

While the specifics vary on circumstance, the change proposed is ultimately simple and app-level, and yet suitable for a wide range of practical applications.

Additionally, this change doesn't increase the risks of zero-confirmation transactions by encouraging them in unsuitable applications, but rather provides a user experience that reduces unnecessary friction causing barriers to adoption.

Extraneous editorialization:

I would love to see Monero set an example for crypto payments that work IRL as they need to in order to be used regularly, and addressing the issue of easy, snappy POS transactions is at the crux of all the feedback--from optimistic and brutally cynical--that I've gotten from a wide variety of crypto enthusiasts who've put their best faith efforts into real world adoption.

Cake has done so much from its inception to make using a monero a piece of cake, and so I thought this feature request best proposed here. It might seem low-priority to be able to use monero at the corner store for snacks, but that's what will make a large segment of the population see monero as money, and doing that would be monumental for monero's resilience, longevity, and impact when and where it's needed most.

Also, everyone's going to want to use the fast wallet :)