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:

ANN: announce that you will register an alias in the next 3–30 blocks REG: actually register your alias and make it public to the world. TRANS: transfer your alias to a new set of addresses (public key) 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.