AllPay Protocol

AllPay Protocol

Acquiring an Allegory name from a reseller


Registering with an Allpay proxy-provider

(i) JSON-RPC API request, method name: PS_ALLPAY_REGISTRATION_TX
Request format:

{
	"xPubKey": <subscriber's xPubKey>,
	"addressCount": <number of unique addresses to be generated>,
	"allegoryHash": <hash of subscriber's Alegory metadata>
}

(ii) JSON response to PS_ALLPAY_REGISTRATION_TX Response format:

{
	"regTx": <serialized registration transaction>
}
regTx is the partially signed Allpay registration transaction. Its Allegory metadata contains the address-commitment and provider-utxo-set-commitment as computed by the proxy provider.

(iii) REST API POST request, resource path: /v1/relaytx/
Path parameters: none, query parameters: none
Request payload encoding: JSON, payload format:

{
	"rawTx": <serialized transaction>
}

  1. Generate xPubKey and set number of addresses to be generated.
  2. Compose Allpay registration transaction: generate set of addresses, build Merkle tree for address set and compute tree root (address-commitment), generate provider UTXO set and compute provider-utxo-set-commitment. Add computed commitments to Allegory metadata of the transaction, along with other details like proxy-provider URI and expiry time.

Using an Allpay name to send Bitcoin to a recipient

  1. Validate name ownership by verifying chain of Allegory name roots up to the Genesis transaction
  2. Generate provably correct address; create an address from recipient's xPubKey and compose a Merkle proof (MProof) for the address
  3. Compose partially signed transaction (PST), set inputs supplied by sender & add proxy-provider UTXO.
  4. Simplified Name Verification; independently verify if address is that of recipient using Merkle commitment and provided Merkle proof (MProof)

(i) REST API GET request, resource path: /v1/allegory/name/
Path parameters: Allegory name, query parameters: none

(ii) JSON-RPC API request, method name: PS_ALLPAY_TX
Request format:

{
	"name": <hash of recipient's Allegory metadata>,
	"inputs": [<transaction input>]
}

(iii) REST API POST request, resource path: /v1/relaytx/
Path parameters: none, query parameters: none
Request payload encoding: JSON, payload format:

{
	"rawTx": <serialized transaction>
}


Allpay Proxy Provider Service Flow

  1. The proxy-provider generates a private key that is used to spawn one or more Bitcoin addresses. A certain number of Bitcoin is then acquired with these addresses.
  2. At the initialization of service, or at regular intervals thereafter, the proxy-provider consolidates these amounts as inputs in a single transaction that has a multiple number of outputs addressed to itself, each output having an equal amount of nominal spendable Satoshi value.
  3. These outputs are designated as 'proxy-provider UTXOs', and the set of these outputs is called the 'UTXO pool'.
  4. For every new subscriber that registers with the proxy-provider service, a predetermined number of proxy-provider UTXOs, selected randomly from the UTXO pool are marked as 'commited proxy-provider UTXOs'. The commitment is to the subscriber. A Merkle tree is computed using these UTXOs, and the resulting Merkle root, referred to as 'provider UTXO set commitment' is included in the subscriber's Allpay registration transaction Allegory metadata.
  5. The UTXO pool consists of proxy-provider UTXOs that are NOT committed to any subscriber. It follows that when a UTXO from the pool is committed to a subscriber, it is removed from the pool.
  6. Whenever any sender that is using an Allpay wallet wishes to send Bitcoin to a subscriber, the transaction must include a proxy-provider UTXO from the committed set for that subscriber. This UTXO is supplied by the proxy-provider. A Merkle path that leads to the provider UTXO set commitment is also supplied to the sender so that s/he can independently verify that the proxy-provider UTXO belongs to the committed set.
  7. At the end of the subscription period or upon the termination of subscription, the proxy-provider has to prove to the subscriber that all the proxy-provider UTXOs committed to it are no longer spendable. It can do this by:
    1. spending all the unspent proxy-provider UTXOs back into the UTXO pool, where it can commit them to another subscriber down the line, and
    2. sending the committed proxy-provider UTXOs to the subscriber so s/he can verify that
      1. all the UTXOs are spent, and
      2. all the UTXOs belong to the commitment set and the set contains no more UTXOs than what have been sent.
    (ii)[b] can be achieved by simply computing the Merkle root using all the provided UTXOs and verifying it against the provider UTXO set commitment in the Allpay registration transaction.

  1. There is nothing intrinsically special about a proxy-provider UTXO. Its value is derived from the fact that it is a part of a commitment made to a subscriber, legitimized by being recorded in the Allegory metadata of a transaction included on the chain.
  2. Proxy-provider UTXOs used in Allpay-enabled transactions can be spent back to the proxy-provider service, and the Satoshi value makes its way back to the UTXO pool of the proxy-provider.