This issue proposes adding support for specifying an amount within txo (transaction object) based Web Vouchers. Currently, the txo format allows including the transaction ID (txid), output (vout), and optionally a private key for spending. However, it lacks the ability to define a specific amount associated with the voucher.

Motivation:

The introduction of an amount field in txo Web Vouchers would provide greater flexibility and real-world applicability. It would enable scenarios where a voucher can represent a specific value within a supported cryptocurrency, such as Bitcoin.

Proposed Change:

We suggest extending the txo Web Voucher format to include an amount field. This field could be represented in the following ways:

1. Within the Existing URL Structure:

   • Add a new parameter after vout separated by a question mark (?). For example:

     urn:voucher:txo:chain:123456789abcdef:vout?amount=1000000
     

     This example specifies a voucher for 10000 satoshis (the smallest unit of Bitcoin).

2. Separate Field in the Linked Data Document:

   • Maintain the current URL structure for the voucher itself.
   • Introduce a new property within the Linked Data document retrieved through the well-known discovery URL (e.g., .well-known/voucher/txo:chain:123456789abcdefghi). This property would explicitly define the amount associated with the voucher.

Benefits:

• Enables Web Vouchers to represent specific value denominations in cryptocurrencies.
• Enhances the functionality and usefulness of txo Web Vouchers for real-world payment scenarios.
• Maintains compatibility with existing txo voucher implementations.

Next Steps:

1. Discuss the proposed change and preferred approach for incorporating the amount field.
2. Decide on the specific syntax or mechanism for representing the amount.
3. Update the Web Vouchers specification document to reflect the changes.

We welcome feedback and suggestions from the community on this proposal. Let's work together to improve the capabilities and adoption of Web Vouchers.

with url safe encoded json

the json will be self decribing

for example

urn:voucher:txo:

urn:voucher:cashu:

each subclass points to a voucher system, in the spec for now

later it can be split into a registry

Suggested text:

The concept of Web Vouchers introduces a standardized method for encoding and redeeming vouchers, voucher codes, or bearer tokens within Uniform Resource Names (URNs) for one-time payments and services on the Internet. This innovative approach aims to simplify and secure transactions across various online platforms, providing a universal solution for one-time codes that offer a wide range of applications from e-commerce discounts to secure access tokens for online services. By leveraging the existing infrastructure of URNs, Web Vouchers facilitate a seamless integration into current web ecosystems, offering a unique blend of versatility, security, and ease of use not found in existing systems.

as per nut-00

https://github.com/cashubtc/nuts/blob/main/00.md

remove for now

  <section>
    <h3>Implementations</h3>

    <h4>Client</h4>

    The first client implementation uses vouchers to interact with the lightning network.<br /><br />

    <a href="https://webvouchers.org/play/voucher.html">Client Demo</a>

    <h4>Server</h4>

    <a href="https://github.com/solidpayorg/webvouchers/blob/gh-pages/bin/lightning.js">Server Code</a>

  </section>

cashu

https://nostrapps.github.io/cashu/?token=urn:voucher:cashu:cashuAeyJ0b2tlbiI6W3sibWludCI6Imh0dHBzOi8vODMzMy5zcGFjZTozMzM4IiwicHJvb2ZzIjpbeyJhbW91bnQiOjIsImlkIjoiMDA5YTFmMjkzMjUzZTQxZSIsInNlY3JldCI6IjQwNzkxNWJjMjEyYmU2MWE3N2UzZTZkMmFlYjRjNzI3OTgwYmRhNTFjZDA2YTZhZmMyOWUyODYxNzY4YTc4MzciLCJDIjoiMDJiYzkwOTc5OTdkODFhZmIyY2M3MzQ2YjVlNDM0NWE5MzQ2YmQyYTUwNmViNzk1ODU5OGE3MmYwY2Y4NTE2M2VhIn0seyJhbW91bnQiOjgsImlkIjoiMDA5YTFmMjkzMjUzZTQxZSIsInNlY3JldCI6ImZlMTUxMDkzMTRlNjFkNzc1NmIwZjhlZTBmMjNhNjI0YWNhYTNmNGUwNDJmNjE0MzNjNzI4YzcwNTdiOTMxYmUiLCJDIjoiMDI5ZThlNTA1MGI4OTBhN2Q2YzA5NjhkYjE2YmMxZDVkNWZhMDQwZWExZGUyODRmNmVjNjlkNjEyOTlmNjcxMDU5In1dfV0sInVuaXQiOiJzYXQiLCJtZW1vIjoiVGhhbmsgeW91LiJ9

Leave it out for now

    <section>
      <h2>Design Considerations</h2>

      <p>There is often a public component, this is to allow the person owning/selling the voucher to know the
        voucher still contains value. The private part is what is used to redeem and claim the voucher credit. The
        private part is typically a one way retrieval process, e.g. tearing open the packet, scratching off the silver or
        a hologram.</p>

      <p>The the issuer, or mint, is often included in the URN. This is because you may have Starbucks, PayPal, CoinMode,
        Google, etc... could be issuing these vouchers. Whoever is issuing the voucher needs to be named somehow.</p>

      <p>Thirdley the currency needs to be described. This is either USD, BTC, GBP, starbuck points etc..</p>

      <p></p>Finally there is an optional expiry date option as many vouchers are handled
      by
      businesses who need to reclaim lost funds somehow and expiry solves this.</p>


      i.e. common fields could be

      <pre>
    voucher: to define it is some sort of voucher
    url: where to query and get more info about the voucher.
    public: very large integer value to verify amount voucher can be redeemed for.
    private: the redeeming number
    destination: platform specific could be a cryptoaddress or user handle
  </pre>


      This gives two urns. One to check a voucher and another to redeem it

      <h4>JSON key values</h4>

      The following are suggested JSON fields to tie to a voucher.

      <pre>
      {
        issuer:"acme",
        public: 12345678901234567890,
        is_valid: true,
        currency: "bitcoin",
        amount:1000000
        expires: 1238972934 (epoch time)
        redeem_url : "https://www.acme.com/redeem"
        remaining_uses : 1
        redeemed : false
        redeemed_by : "??"
        redeemed_dates : [ 123987234, 124789238 ]
      }</pre>
    </section>



  </section>