AllPay Protocol

Acquiring an Allegory name from a reseller

Registering with an Allpay proxy-provider

(i) Registration request, HTTP POST request with JSON encoded body:

{
		"name" : <integer array, subscriber's Allegory name>,
		"xpubKey" : <string, subscriber's XPubKey>,
		"addressCount" : <integer, number of addresses to generate on behalf of subscriber>
}

(ii) Response to registration request, JSON encoded body:

{
		"opReturn" : <hex-encoded output script, Allegory metadata with commitments>,
		"registrationFeeSats" : <integer, fee in Satoshi for registration>,
		"paymentAddress" : <string, address to make payment to>
}

(iii) Registration confirmation and transaction relay request, HTTP POST with JSON encoded body:

{
		"rawTx" : <base64, registration transaction>
}

(iv) Nexa relay request, HTTP POST

(v) Nexa relay response

(vi) Registration confirmation and relay result, JSON encoded body:

{
		"success": <boolean, Nexa broadcast success status>
}

1. Registration options
   • Allegory name
   • xPubKey
   • Number of addresses
2. Verify Allegory name against blockchain; if name has been created and has owner rights. Create address and UTXO commitment and generate Allegory metadata, store registration details as unconfirmed user.
3. Draft registration transaction with Allegory name input and output, Allegory metadata and fee payment to supplied address.
4. Verify payment amount and address, Allegory name input against blockchain; if input corresponds to registered name. Confirm user registration in subscriber database if payment and name input verified.

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.