Skip to content

Latest commit

 

History

History
155 lines (116 loc) · 4.76 KB

cap-0008.md

File metadata and controls

155 lines (116 loc) · 4.76 KB
Raw

Preamble

CAP: 0008
Title: Self Identified Pre-Auth Transaction
Author: Jeremy Rubin
Status: Draft
Created: 2018-11-13
Discussion: https://github.com/stellar/stellar-protocol/issues/99
Protocol version: TBD

Simple Summary

We introduce a new variant of Preauthorized Transaction which refers to the account it resides on automatically.

Abstract

For a given deterministic account, a pre-auth transaction cannot be added until after it's generating transaction is constructed because the Account ID is not yet known.

Self Identified Pre-Auth Transactions address this issue by allowing the source ID to be a special value.

Motivation

Adding Pre-Auth transactions to Deterministic accounts enables the creation of on-chain finite automata. Such automata are highly desirable for applications like starlight as they allow for channel creation to be a non-interactive lazy operation, minimizing the latency and privacy loss of channel creation, increasing the throughput of channels created per second, and decreasing the code complexity of such applications as such automata can be guaranteed to succeed and not partially fail.

Specification

We assume CAP-0007 is accepted.

We extend the AccountID type:

enum AccountIDType
{
    ACCOUNT_ID_TYPE_ED25519 = KEY_TYPE_ED25519,
    ACCOUNT_ID_TYPE_HASH_DET_ACCOUNT = 3,
    ACCOUNT_ID_TYPE_NEWEST_DET_ACCOUNT = 4,
    ACCOUNT_ID_TYPE_SELF = 5,
};


union AccountID switch (AccountIDType type)
{
case ACCOUNT_ID_TYPE_ED25519:
    uint256 ed25519;
case ACCOUNT_ID_TYPE_HASH_DET_ACCOUNT:
    uint256 ed25519;
case ACCOUNT_ID_TYPE_NEWEST_DET_ACCOUNT:
    void;
case ACCOUNT_ID_TYPE_SELF:
    void;
};

and the SignerKey type:

enum CryptoKeyType
{
    KEY_TYPE_ED25519 = 0,
    KEY_TYPE_PRE_AUTH_TX = 1,
    KEY_TYPE_HASH_X = 2,
    KEY_TYPE_PRE_AUTH_SELF_TX = 3,
};

enum SignerKeyType
{
    SIGNER_KEY_TYPE_ED25519 = KEY_TYPE_ED25519,
    SIGNER_KEY_TYPE_PRE_AUTH_TX = KEY_TYPE_PRE_AUTH_TX,
    SIGNER_KEY_TYPE_HASH_X = KEY_TYPE_HASH_X,
	SIGNER_KEY_TYPE_PRE_AUTH_SELF_TX = KEY_TYPE_PRE_AUTH_SELF_TX,
};


union SignerKey switch (SignerKeyType type)
{
case SIGNER_KEY_TYPE_ED25519:
    uint256 ed25519;
case SIGNER_KEY_TYPE_PRE_AUTH_TX:
    /* SHA-256 Hash of TransactionSignaturePayload structure */
    uint256 preAuthTx;
case SIGNER_KEY_TYPE_PRE_AUTH_SELF_TX:
    /* SHA-256 Hash of TransactionSignaturePayload structure */
    uint256 preAuthTx;
case SIGNER_KEY_TYPE_HASH_X:
    /* Hash of random 256 bit preimage X */
    uint256 hashX;
};

ACCOUNT_ID_TYPE_SELF may be used generally in the body of any transaction -- not just pre-auth -- to refer to the source of a transaction (not the operation).

An incoming transaction for a given account, if there are insufficient signatures and there are SIGNER_KEY_TYPE_PRE_AUTH_SELF_TX entries, should set the source account to ACCOUNT_ID_TYPE_SELF and hash it and see if there are any matches, and treat them like a pre-auth transaction is treated otherwise.

Rationale

This enables the adding of pre-auth transactions to deterministic accounts at the time of creation.

It also enables a general purpose shorthand for referring to the source account, which makes implementing certain contracts simpler (as there is no need to traverse the transaction and fill in all templated locations for self). This makes invoice creation simpler.

An alternative approach could template more than just the source account, such as sequences and other fields. Such templates should be considered independently of this change even at the cost of potential redundancy because this feature is limited in scope and complexity and doesn't introduce transaction malleability issues. In a sense, it is not even a templating feature as it can't be used for anything except a self-reference -- it is purely a feature to address a hash cycle issue.

Before this proposal is finalized, it should be decided if SIGNER_KEY_TYPE_PRE_AUTH_SELF_TX should be allowed to be used on non deterministic accounts. Strictly speaking there is no reason to allow it on regular accounts, but perhaps it simplifies downstream software if they do not need to differentiate between normal and deterministic accounts.

It's also possible to not introduce a new type of pre-auth for this change, and just to overload the existing pre-auth to match. However, this makes preauth checking more expensive in many cases (because the hash needs to be recomputed with the self key). Furthermore, it is more explicit to use a new signer type, which makes it easier for spendability solvers to analyze pre-auths of both variants for pattern matching.

Backwards Compatibility

This proposal requires updating existing APIs to accept the new key types and updating siganture validation to handle the new pre-auth type.

Implementation

No implementation yet.