BitAlias II

Privacy and Security++

Introducing Stealth Payments and Simplified Alias Verification (SAV)

Introduction

The initial draft of BitAlias was not designed with privacy in mind, thus all payments where public. BitAlias II is introducing unlimited public and stealth payments. Furthermore, a new way to do Simplified Alias Verification (SAV) will be introduced to increase security, which works very similar to SPV-proofs.

The protocol described in the initial blog post fundamentally stays the same. There are 4 well-defined transactions:

1. ANN: announce that you will register an alias in the next 3–30 blocks
2. REG: actually register your alias and make it public to the world.
3. TRANS: transfer your alias to a new set of addresses (public key)
4. RENEW: extends the lifetime of your alias

Alias <—> Public Key => unlimited public and private Addresses

After the registration, your alias gets connected to your public key (from your sending address) and not directly to your address. Here is the little change made to the original protocol. By multiplication of the generator point G from the public key with a deterministic or random scalar, basically unlimited public and private addresses can be derived.

Sending and Receiving Bitcoins

With knowing the name for a BitAlias (e.g. yanislav) one can lookup the associated public key on the blockchain, directly or using an interface. After having found out the public key (e.g. 026306c0ca53ffe…866b531fbc75e041) we need to multiply it with a number.

Derivation Functions in Javascript using Bitcore

Public BitAlias Addresses

For public payments (e.g. sending donations to websites) a simple deterministic index (1, 2, 3, 4…) is used for generating the payment address by multiplication with the index as a scalar.

Stealth BitAlias Addresses

For private payments we use a very big random number which gets hashed and then encrypted by the sender using the public key of the recipient. The result of the encryption gets sent with the transaction inside the OP_RETURN (data) field; thus the recipient must try to decrypt all OP_RETURN data transactions.

View Keys

For thin-clients, in order to avoid doing the scanning for stealth transactions by themselves, view keys are introduced. With a public view key the protocol prefix (S) for BitAlias stealth transactions gets encrypted. Using the private view key the recipient can check whether the payment is for him. Because having only the private view key one can not spend the coins, the scan process for payments can be delegated to another entity which pings the recipient every time he receives a new payment to a stealth address.

The view key itself is derived by using ‘VIEW’ as the purposeString in the derivation function above.

BALI: BitAlias OP_RETURN Prefix

All BitAlias data transactions (which contain an OP_RETURN output) get prefixed with BALI (inside OP_RETURN)

SAMPLE BITALIAS REG TRANSACTION OP_RETURN ASM SCRIPT
    OP_RETURN BALI:REG:yanislav

For stealth payments the OP_RETURN field is also used to pass a secret number to the recipient. Using this secret he can generate the private spending key for the bitcoins.

BITALIAS STEALTH OP_RETURN ASM SCRIPT
    OP_RETURN BALI:[S]*:S[SECRET]**
        * = encrypted with the public view key
        * = encrypted with the public spending key

Simplified Alias Verification

In order to have a global state of all valid and legal BitAlias transactions for every Bitcoin block a new Simplified Alias Verification (SAV) scheme is introduced. Similarly to how SPV (Simplified Payment Verification) works, this involves creating a new Merkle tree for every block. The Merkle trees themselves get chained in a new virtual (nested) blockchain inside the Bitcoin blockchain. This way, for verification, downloading the whole blockchain is no longer necessary. Only the block headers, the transaction itself and the Merkle branch of it need to be downloaded.

While the transactions themselves can be verified using SPV, SAV allows to verify that the transaction is a valid and legal BitAlias transaction (one of the four above).

The general security level for thin clients increases since they only need to have a copy of the block headers and fetch afterwards the transaction with its Merkle branch to verify a BitAlias.

Valid but Illegal transactions

Additionally to valid and legal BitAlias transactions the BitAlias block chain will contain illegal transactions (but not invalid), for providing additional security against spoofing. A syntactically valid but semantically illegal transaction is e.g. a transaction where somebody tries to transfer an alias to another Bitcoin address after having successfully transferred it already in the past.

Mining

No mining is involved in the creation of the BitAlias block chain, but miners who want to support BitAlias could embed the BitAlias Merkle root into the coinbase transaction, when they mine a block, in order to provide a sort of decentralized (soft) check-pointing-service.

Conclusion

By knowing one simple alias, payers can generate unlimited* private and public addresses for any BitAlias user. If implemented properly, this could be a true revolution for the usability of Bitcoin.

Please get in touch if you want to help!

Development fund address: 15yXLHu3AjoLLkhr1XB8WfqPXiwsgt4GuJ