NoShore: Groundwork for on-the-go offline payments

UPDATE 2024/12/10 Thanks to feedback and ideas provided so far, the functionality referred to as "tower" will be funded through a donation-setting in its code (easily disabled). Tower will still be implemented as part of the proposal, but at no cost, which reduced the overall amount requested from 70 to 45 XMR.

NoShore: Groundwork for on-the-go offline payments

A step towards enabling our grandparents to transact Monero;

TL;DR The document proposes a shell-based environment that users can run to enable offline payments with supporting merchants, whereas the actual signing device will be developed separately in an upcoming iteration.

Why

Many of us excited about technology are fine with scanning QR-codes, authorizing spends after scrutinizing their details and constantly having to keep phones synced. We are used to finding solutions.

For everyday users though, any additional step can pose a major hurdle. Swiping a card and passing a pen over a bill has been the standard for simple payments for decades. Even here, given multiple accounts at various institutions, something as basic as remembering a four-digit PIN can become stressful.

Such difficulties, however, pale when compared to the complexity of our current Monero payment processes.

Merchants who aren't euphoric about Monero and simply want to do business will not want to put up with delays incurred by customers handling their phones - much less so, their employed clerks.

Customers, on the other hand, can easily be overwhelmed and give up, deciding that "this technology simply doesn't work for them".

On either side, people become barred from ever fully appreciating the utility of XMR as real-life money.

What

To lower the barriers, a payment process resembling those that average shoppers are familiar with shall be developed:

A merchant presents the customer with a point-of-sale device that displays the amount the client is expected to pay.

The client's device is in flight mode. It only communicates with the merchant's device to provide the details necessary to prepare a transaction.

Finally, the client's device sends a signed transaction to the merchant's device, which in turn submits it to the Monero network.

Within seconds, the merchant knows that the transaction has been accepted. While the receipt is being printed, it might already be getting included in a block.

The client leaves the store with the products - and the peace of mind of not even having revealed location data.

How

The usability-improvements are achieved by offloading the workload to a back-end.

While in the legacy financial system, credit card companies provide merchants with certified devices, the Monero ecosystem requires a decentralized configuration.

For secure operation, the design identifies four tasks:

1. Transaction signing: The client's offline unit (nickname "ghost")
2. Payment coordination: The merchant's point-of-sale unit (nickname "gate")
3. Transaction building: The client's online service (nickname "tower")
4. Output scanning: The client's live wallet service (nickname "sentry")

Each of these tasks are handled as separate concerns by the respective modules to be implemented:

• sentry ensures that tower stays up-to-date about available funds
• gate asks tower to prepare payments and ghost to sign them
• tower prepares transactions as requested by gate
• ghost signs transactions prepared by tower, forwarded by gate

This setup can be simulated today by starting four RPC-instances respectively and manually passing the data as required. What is missing is automation, error-handling and simplify deployment.

Use cases

Except for gate, the modules have to be configured by the user - or somebody capable of helping them.

The average shopper cannot be expected to administer the required services.

The long-term route thus entails several stages of simplification, applicable in different scenarios, coherent with each corresponding trust level:

Average shoppers

Assuming everyday shopping could be done today, if we handed any existing Monero app to somebody inexperienced and not enthusiastic about Monero, chances are they would give up at scanning the first QR code.

If, however, we can take care of the setup for them, reducing their part to simply presenting a signing device, frustration becomes rather unlikely.

Intimate circles

In any kind of interest group, there's a regular need for payments among the members: Membership fee, drinks, joint-travel and organized events. In theory, Monero could be used, but it's not practical - especially if the club is formed around a completely unrelated topic.

In most cases, though, there are one or two tech-enthusiasts regardless of the general topic. If those take care of running the required back-end modules, all that's left for the other members is to use the signing devices for their payment-needs within the circle, likely appreciating the simplicity.

Grand scheme

Note that by no means is it necessary for "everyone" to adopt the processes outlined here - Monero will not be changed by NoShore in any way. Nevertheless, the author envisions scenarios like the above as potential stepping stones towards broader adoption. Especially when tower is provided in a "federated" manner - many users utilizing one deployment - scaling can happen and suddenly one circle finds itself trading with another ...

Who

For five years uninterrupted, fullmetalScience has been providing the OpenAlias-as-a-Service XMR.ID.

A desire to more quickly navigate payments led to the birth of xmr.zone, where tools for hackers on-the-go are published.

One of those tools, XMRPC, simplifies interaction with the Monero RPC. Its 1000+ lines-of-code already written will reduce the amount of effort required to implement this proposal.

Development

This separation of concerns into modules means that each module can be enhanced or even replaced according to new needs or with new technologies.

For this CCS, each module will be implemented as POSIX-compliant shell script, while the four tools will communicate among each other through SSH.

The idea is to keep things simple and avoid the dependency hell often encountered when "modern" scripting languages are employed.

By plugging into monero-wallet-rpc and other executables, development overhead stays minimal, modules don't easily get outdated and updates are rarely critical.

fullmetalScience's usual standards apply:

• code is made portable across Linux/Mac/BSD/Android
• readability through meaningful variable- and function names
• prevention and handling of errors with clear explanations
• edge cases are considered and treated in order to take the user by the hand wherever reasonably possible
• generic code is made reusable by adding it to XMRPC in a DRY manner
• semantic versioning indicates breaking changes

Privacy

All three of sentry, tower and ghost can be fully controlled by the user.

To obfuscate locations, the connections between sentry, tower and gate can be routed through anonymity networks like Tor and I2P.

Ghost works without an Internet connection altogether. It only exposes a transient signature to gate, meaning that not even the sender's wallet address will be revealed!

Effectively, the design allows users to sign payments on-the-go without giving away identity data or location.

Integrity

Where applicable, exchanged data will be made tamper-proof through digital signatures. Nefarious merchants cannot change the parameters of a payment after it has been signed by the customer.

Obscurity

By ghost passing a signature instead of an address, wallet-related data remains hidden. Apart from the tower's domain and port, which will preferably be on an anonymity network, the process reveals the same information to a merchant that any other Monero transaction would too.

Anonymity

For RPC-to-node communication, XMRPC can already use Tor. The proposed modules can also be configured to communicate over anonymity networks. All physical locations will be obscured unless the user opts to operate the services on clearnet.

Security

Communication channels may be secured further by restricting connections on the network layer through Tor- and/or I2P-certificates or through the use of VPN's like WireGuard or OpenVPN.

Safety

Tower can deny preparing a transaction if an amount exceeds a user-defined limit. By adding a signature over the entire transaction data, ghost can trust that it's signing for the amount actually agreed upon.

Refer to the remarks on a companion app below for additional safety measures that can be added in the future.

Documentation

All modules will be published in a dedicated "NoShore"-section at xmr.zone.

The section for sxmo-onfire on xmr.zone can serve as a reference for the quality of documentation to be expected.

Process

Milestones

The project's value is estimated based on seven major sections: the four modules, SSH-functionality, common features and debugging, documentation;

For the sake of simplicity, development is compressed into a single milestone and thus payout.

A working implementation of all four modules will be available not later than two months after the proposal is fully funded.

While the proposal is in the funding stage, XMRPC will be reviewed and extended with functionality in preparation of a smooth implementation.

Scope boundaries

Ghost's functionality will be provided by triggering commands on gate through SSH. Since finding gate's host in the first place becomes much more reasonable once NFC is added, this is not part of proposal and left for a later iteration. Note that later iterations do not necessarily have to be financed through CCS, as it's the authors mission to make the simplest form of XMR payments a reality.

All steps will handle spendable outputs available at the moment of payment. The ~20-minute lock-time inherent to Monero has to be dealt with separately.

Dates

If funded before December 31, 2025, NoShore will be usable and ready for review by February 28th, 2025.

If the proposal remains unfunded, it may expire by March 31, 2025.

It may also expire if not delivered within two months after full funding is achieved.

Monero Circular Economy Pledge (MCEP)

To foster circular economies, the author pledges to:

• use the funds obtained through this proposal only to purchase other products or services with XMR
• not use exchanges to convert the XMR into a fiat currency
• seek out and transact with other MCEP businesses where possible

---

---

Outlook

This proposal is for an implementation that will be usable now.

Future developments like FCMP++ and Seraphis may allow to further simplify the design.

FCMP++ might be able to bring reduced lock-times, but also make transaction-scanning slightly more compute-intensive. In any case, users can save battery when wallets offload scanning to NoShore's tower.

Seraphis, with its concept of full-view keys, should allow to do away with sentry, effectively reducing NoShore's requirements by ~25%.

Given positive reception by the community, this proposal enables a wealth of developments independent of those protocol-level improvements:

Ghost as hardware-device

The creation of a minimal hardware that requires no maintenance and allows to issue payments with maximum simplicity has been a long-term vision of the author.

In fact, this desire to offline-sign transactions on the go resulted in this proposal taking form.

With the present implementation, ghost will be running an (offline) RPC itself, but for later, the idea is to minimize it's requirements.

In the context of achieving a major reduction, vthor's recently funded CCS for "XmrSigner" is a promising candidate.

Ideally, the final state is to make payments as simple as swiping a debit card, with specialized open-source hardware readily available to moneristas.

Ghost as mobile app

Before transitioning to specialized hardware, ghost can be implemented as a native mobile application that communicates with gate over NFC.

In turn, before developing a native application, ghost (from this proposal) can be adapted for use in Termux.

Especially if Termux'es NFC-API turns out to be capable, Android-users can start to experiment with mobile offline-singing not long after this proposal is implemented.

Ghost companion-app

Readers familiar with using credit/debit cards have likely worked with companion-apps that allow to change PIN's, set limits or ask for confirmation when paying.

In the context of NoShore, a companion-app would communicate with tower in order to set hard-spending limits, confirm payments when amounts exceed soft-limits, define per-merchant trust-levels, see the currently available balance or offer sub addresses to fund the account.

Gate as mobile application

Gate can be taken on a similar path as ghost by iterating development from PC through stages of NFC-capable mobile applications.

Having gate as a point-of-sale hardware - known from the legacy financial system - may be reasonable when seeking to avoid user error on the merchant's side.

Deployment improvements

Within the scope of this this proposal, the provided tools can be run after a git clone followed by installing packages from the operating system's repositories.

Docker images and/or Alpine Linux .apkovl files can be created to further simplify deployment, helping less-experienced users to get started.

Ultra-light wallet

This is a secondary use case for NoShore:

By hosting all of sentry, tower and gate oneself, one can enable ultra-light wallet-functionality that doesn't require any on-device syncing at all.

A custom wallet can request tower and gate to respectively prepare and publish a transaction.

There's a dmenu-style interface for XMRPC in the making for xmr.zone. It could be extended to work with this "ultra-light" concept.

---

Thank you for taking the time to read and consider this proposal.

Feel free to ask your questions in the comments!

fullmetalscience-noshore.md

+---
+vim: spell spelllang=en
+layout: fr
+title: |
+  NoShore: Groundwork for on-the-go offline payments
+author: fullmetalScience
+date: December 14, 2024
+amount: 45
+milestones:
+  - name: Project completion
+    funds: 100% (45 XMR)
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+---
+
+***UPDATE 2024/12/10**
+Thanks to feedback and ideas provided so far, the functionality referred to as "tower" will be funded through a donation-setting in its code (easily disabled). *Tower* will still be implemented as part of the proposal, but at no cost, which reduced the overall amount requested from 70 to 45 XMR.*
+
+
+# NoShore: Groundwork for on-the-go offline payments
+
+A step towards enabling our grandparents to transact Monero;
+
+**TL;DR** The document proposes a shell-based environment that users can run to enable offline payments with supporting merchants, whereas the actual signing device will be developed separately in an upcoming iteration.
+
+
+
+## Why
+
+Many of us excited about technology are fine with scanning QR-codes, authorizing spends after scrutinizing their details and constantly having to keep phones synced. We are used to finding solutions.
+
+For everyday users though, any additional step can pose a major hurdle. Swiping a card and passing a pen over a bill has been the standard for simple payments for decades. Even here, given multiple accounts at various institutions, something as basic as remembering a four-digit PIN can become stressful.
+
+Such difficulties, however, pale when compared to the complexity of our current Monero payment processes.
+
+Merchants who aren't euphoric about Monero and simply want to do business will not want to put up with delays incurred by customers handling their phones - much less so, their employed clerks.
+
+Customers, on the other hand, can easily be overwhelmed and give up, deciding that "this technology simply doesn't work for them".
+
+On either side, people become barred from ever fully appreciating the utility of XMR as real-life money.
+
+
+## What
+
+To lower the barriers, a payment process resembling those that average shoppers are familiar with shall be developed:
+
+A merchant presents the customer with a point-of-sale device that displays the amount the client is expected to pay.
+
+The client's device is in flight mode. It only communicates with the merchant's device to provide the details necessary to prepare a transaction.
+
+Finally, the client's device sends a signed transaction to the merchant's device, which in turn submits it to the Monero network.
+
+Within seconds, the merchant knows that the transaction has been accepted. While the receipt is being printed, it might already be getting included in a block.
+
+The client leaves the store with the products - and the peace of mind of not even having revealed location data.
+
+
+## How
+
+The usability-improvements are achieved by offloading the workload to a back-end.
+
+While in the legacy financial system, credit card companies provide merchants with certified devices, the Monero ecosystem requires a decentralized configuration.
+
+
+For secure operation, the design identifies four tasks:
+
+1. **Transaction signing**: The client's offline unit (nickname "ghost")
+2. **Payment coordination**: The merchant's point-of-sale unit (nickname "gate")
+3. **Transaction building**: The client's online service (nickname "tower")
+4. **Output scanning**: The client's live wallet service (nickname "sentry")
+
+
+Each of these tasks are handled as separate concerns by the respective modules to be implemented:
+
+* **sentry** ensures that *tower* stays up-to-date about available funds
+* **gate** asks *tower* to prepare payments and *ghost* to sign them
+* **tower** prepares transactions as requested by *gate*
+* **ghost** signs transactions prepared by *tower*, forwarded by *gate*
+
+This setup can be simulated today by starting four RPC-instances respectively and manually passing the data as required. What is missing is automation, error-handling and simplify deployment.
+
+
+### Use cases
+
+Except for *gate*, the modules have to be configured by the user - or somebody capable of helping them.
+
+The average shopper cannot be expected to administer the required services.
+
+The long-term route thus entails several stages of simplification, applicable in different scenarios, coherent with each corresponding trust level:
+
+
+#### Average shoppers
+
+Assuming everyday shopping could be done today, if we handed any existing Monero app to somebody inexperienced and not enthusiastic about Monero, chances are they would give up at scanning the first QR code.
+
+If, however, we can take care of the setup for them, reducing their part to simply presenting a signing device, frustration becomes rather unlikely.
+
+
+#### Intimate circles
+
+In any kind of interest group, there's a regular need for payments among the members: Membership fee, drinks, joint-travel and organized events. In theory, Monero could be used, but it's not practical - especially if the club is formed around a completely unrelated topic.
+
+In most cases, though, there are one or two tech-enthusiasts regardless of the general topic. If those take care of running the required back-end modules, all that's left for the other members is to use the signing devices for their payment-needs within the circle, likely appreciating the simplicity.
+
+
+#### Grand scheme
+
+Note that by no means is it necessary for "everyone" to adopt the processes outlined here - Monero will not be changed by NoShore in any way. Nevertheless, the author envisions scenarios like the above as potential stepping stones towards broader adoption. Especially when *tower* is provided in a "federated" manner - many users utilizing one deployment - scaling can happen and suddenly one circle finds itself trading with another ...
+
+
+## Who
+
+For five years uninterrupted, **fullmetalScience** has been providing the OpenAlias-as-a-Service [XMR.ID](https://xmr.id/ "Monero payments at yourname@xmr.id").
+
+A desire to more quickly navigate payments led to the birth of [xmr.zone](https://xmr.zone "tools and services for near-instant workflows"), where tools for hackers on-the-go are published.
+
+One of those tools, [XMRPC](https://xmr.zone/sxmo-onfire/xmrpc/ "CLI for Monero RPC Control"), simplifies interaction with the Monero RPC. Its 1000+ lines-of-code already written will reduce the amount of effort required to implement this proposal.
+
+
+
+## Development
+
+This separation of concerns into modules means that each module can be enhanced or even replaced according to new needs or with new technologies.
+
+For this CCS, each module will be implemented as POSIX-compliant shell script, while the four tools will communicate among each other through SSH.
+
+The idea is to keep things simple and avoid the *dependency hell* often encountered when "modern" scripting languages are employed.
+
+By plugging into `monero-wallet-rpc` and other executables, development overhead stays minimal, modules don't easily get outdated and updates are rarely critical.
+
+fullmetalScience's usual standards apply:
+
+* code is made portable across Linux/Mac/BSD/Android
+* readability through meaningful variable- and function names
+* prevention and handling of errors with clear explanations
+* edge cases are considered and treated in order to take the user by the hand wherever reasonably possible
+* generic code is made reusable by adding it to XMRPC in a [DRY](https://web.archive.org/web/20131204221336/http://programmer.97things.oreilly.com/wiki/index.php/Don't_Repeat_Yourself "Don't Repeat Yourself") manner
+* [semantic versioning](https://semver.org/ "Impact of changes identifyable by version number") indicates breaking changes
+
+
+### Privacy
+
+All three of *sentry*, *tower* and *ghost* can be fully controlled by the user.
+
+To obfuscate locations, the connections between *sentry*, *tower* and *gate* can be routed through anonymity networks like Tor and I2P.
+
+*Ghost* works without an Internet connection altogether. It only exposes a transient signature to *gate*, meaning that not even the sender's wallet address will be revealed!
+
+*Effectively, the design allows users to sign payments on-the-go without giving away identity data or location.*
+
+### Integrity
+
+Where applicable, exchanged data will be made tamper-proof through digital signatures. Nefarious merchants cannot change the parameters of a payment after it has been signed by the customer.
+
+### Obscurity
+
+By *ghost* passing a signature instead of an address, wallet-related data remains hidden. Apart from the *tower's* domain and port, which will preferably be on an anonymity network, the process reveals the same information to a merchant that any other Monero transaction would too.
+
+### Anonymity
+
+For RPC-to-node communication, XMRPC can already use Tor. The proposed modules can also be configured to communicate over anonymity networks. All physical locations will be obscured unless the user opts to operate the services on clearnet.
+
+### Security
+
+Communication channels may be secured further by restricting connections on the network layer through Tor- and/or I2P-certificates or through the use of VPN's like WireGuard or OpenVPN.
+
+### Safety
+
+*Tower* can deny preparing a transaction if an amount exceeds a user-defined limit. By adding a signature over the entire transaction data, *ghost* can trust that it's signing for the amount actually agreed upon.
+
+Refer to the remarks on a companion app below for additional safety measures that can be added in the future.
+
+
+
+## Documentation 
+
+All modules will be published in a dedicated "NoShore"-section at [xmr.zone](https://xmr.zone "tools and services for near-instant workflows").
+
+The [section for sxmo-onfire on xmr.zone](https://xmr.zone/sxmo-onfire "collection of portable productivity tools, focussed on complementing efficient workflows") can serve as a reference for the quality of documentation to be expected.
+
+
+
+## Process
+
+### Milestones
+
+The project's value is estimated based on seven major sections: the four modules, SSH-functionality, common features and debugging, documentation;
+
+For the sake of simplicity, development is compressed into a single milestone and thus payout.
+
+A working implementation of all four modules will be available not later than two months after the proposal is fully funded.
+
+*While the proposal is in the funding stage, XMRPC will be reviewed and extended with functionality in preparation of a smooth implementation.*
+
+
+### Scope boundaries
+
+*Ghost's* functionality will be provided by triggering commands on *gate* through SSH. Since finding *gate's* host in the first place becomes much more reasonable once NFC is added, this is not part of proposal and left for a later iteration. Note that later iterations do not necessarily have to be financed through CCS, as it's the authors mission to make the simplest form of XMR payments a reality.
+
+All steps will handle spendable outputs available at the moment of payment. The ~20-minute lock-time inherent to Monero has to be dealt with separately.
+
+
+### Dates
+
+If funded before December 31, 2025, NoShore will be usable and ready for review by February 28th, 2025.
+
+If the proposal remains unfunded, it may expire by March 31, 2025.
+
+It may also expire if not delivered within two months after full funding is achieved.
+
+
+## Monero Circular Economy Pledge (MCEP)
+
+To foster circular economies, the author pledges to:
+
+* use the funds obtained through this proposal only to purchase other products or services with XMR
+* not use exchanges to convert the XMR into a fiat currency
+* seek out and transact with other MCEP businesses where possible
+
+
+---
+---
+
+
+## Outlook
+
+This proposal is for an implementation that will be usable *now*.
+
+Future developments like FCMP++ and Seraphis may allow to further simplify the design.
+
+FCMP++ might be able to bring reduced lock-times, but also make transaction-scanning slightly more compute-intensive. In any case, users can save battery when wallets offload scanning to NoShore's *tower*.
+
+Seraphis, with its concept of full-view keys, should allow to do away with *sentry*, effectively reducing NoShore's requirements by ~25%.
+
+Given positive reception by the community, this proposal enables a wealth of developments independent of those protocol-level improvements:
+
+
+### Ghost as hardware-device
+
+The creation of a minimal hardware that requires no maintenance and allows to issue payments with maximum simplicity has been a long-term vision of the author.
+
+In fact, this desire to offline-sign transactions on the go resulted in this proposal taking form.
+
+With the present implementation, *ghost* will be running an (offline) RPC itself, but for later, the idea is to minimize it's requirements.
+
+In the context of achieving a major reduction, **vthor's** recently funded [CCS for "XmrSigner"](https://ccs.getmonero.org/proposals/vThorOfflineSigningLibrary_XmrSignerToProduction.html "Offline Signing Library for XmrSigner") is a promising candidate.
+
+Ideally, the final state is to make payments as simple as swiping a debit card, with specialized open-source hardware readily available to moneristas.
+
+
+### Ghost as mobile app
+
+Before transitioning to specialized hardware, *ghost* can be implemented as a native mobile application that communicates with *gate* over NFC.
+
+In turn, before developing a native application, *ghost* (from this proposal) can be adapted for use in Termux.
+
+Especially if Termux'es NFC-API turns out to be capable, Android-users can start to experiment with mobile offline-singing not long after this proposal is implemented.
+
+
+### Ghost companion-app
+
+Readers familiar with using credit/debit cards have likely worked with companion-apps that allow to change PIN's, set limits or ask for confirmation when paying.
+
+In the context of NoShore, a companion-app would communicate with *tower* in order to set hard-spending limits, confirm payments when amounts exceed soft-limits, define per-merchant trust-levels, see the currently available balance or offer sub addresses to fund the account.
+
+
+### Gate as mobile application
+
+*Gate* can be taken on a similar path as *ghost* by iterating development from PC through stages of NFC-capable mobile applications.
+
+Having *gate* as a point-of-sale hardware - known from the legacy financial system - may be reasonable when seeking to avoid user error on the merchant's side.
+
+
+### Deployment improvements
+
+Within the scope of this this proposal, the provided tools can be run after a `git clone` followed by installing packages from the operating system's repositories.
+
+Docker images and/or Alpine Linux .apkovl files can be created to further simplify deployment, helping less-experienced users to get started.
+
+
+### Ultra-light wallet
+
+This is a secondary use case for NoShore:
+
+By hosting all of *sentry*, *tower* **and** *gate* oneself, one can enable ultra-light wallet-functionality that doesn't require any on-device syncing at all.
+
+A custom wallet can request *tower* and *gate* to respectively prepare and publish a transaction.
+
+There's a dmenu-style interface for XMRPC in the making for *xmr.zone*. It could be extended to work with this "ultra-light" concept.
+
+---
+
+Thank you for taking the time to read and consider this proposal.
+
+Feel free to ask your questions in the comments!
+