-
Notifications
You must be signed in to change notification settings - Fork 205
Addresses in Beam
----------- WIP -------------
There're (too) many different kinds of addresses in Beam:
- Regular (a.k.a. new-style)
- Legacy (BBS-only, a.k.a. old-style)
- Offline
- Max-privacy
In addition to those kinds of addresses, there's more terminology:
- Payment Tokens, that consist of an address with the requested payment amount
- Vouchers
- Endpoints (alternatively called as Signature, or Identity)
- Payment proof
Some of the above things are permanent, some expire, and some are intended for single usage. In addition to that, when the wallet is restored, the addresses are not preserved (new wallet instance generates new addresses). All this is very confusing. Here we'll explain in details how things work, why historically so many kinds of addresses were implemented, and what is relevant today.
First and foremost:
Beam is based on UTXO model (set of coins, in simple words). There're 2 types of UTXOs:
- MW (MimbleWimble) UTXOs.
- Shielded TXOs. Those are created and spent using in Lelantus-MW txs.
Both kinds of UTXOs are opaque, and look like random data. No addresses that expose who owns them, and the value is concealed.
Each UTXO has its secret key, which is needed to build a valid tx that spends it. Means whoever knows that secret key - actually owns the coin.
Each wallet has the Master Key (initialized from the secret seed phrase). It is used to derive all the coin keys. When the coins are generated by the wallet, they're encoded such that they can re recognized by the corresponding Owner Key (also derived from the Master Key).
This means the following:
- All the coins belong to the wallet that generated it. They can be recognized by its Owner Key, and then spent in the future txs using its Master Key.
- Coins do NOT belong to addresses.
- Addresses are only used between the wallets to communicate and build txs (more about this later). After the tx is included in a block - addresses don't matter.
Beam is based on MW, where transactions are built interactively. Means users must communicate to build a transaction.
For this we developed an SBBS system, that allows wallets to exchange encrypted messages anonymously. Wallets can generate public/private key pairs, where the public key is used to encrypt messages, and private key can decrypt them.
That's how addresses were born on Beam. Address in fact meant SBBS address, a public key to encode messages, that can only be decoded by the appropriate private key.
Here're some notes regarding the SBBS encryption:
- All encrypted messages are opaque (look like random data), the sender/receiver of the message is also opaque, and the message is protected against tampering (using HMAC scheme).
- Using the SBBS address one can only encrypt messages, not decrypt.
- There's no feasible way to realize that a specific SBBS message was encoded by a given SBBS address.
- Means you can share your SBBS address to different users, they won't be able to see when you communicate with others.
- Users can generate as many SBBS addresses as they want.
- In order to receive the SBBS message, one tries to decrypt all the incoming SBBS traffic. Only the intended messages would be successfully decrypted and pass HMAC verification.
- If you listen to several active SBBS addresses - the wallet will try to decrypt each message by each address private key.
- The more active SBBS addresses - the harder the wallet works to receive the messages.
As we said, a wallet may generate multiple SBBS addreses. It may also deactivate a specific address, which means it'd stop trying to decrypt incoming SBBS messages by its private key.
Theoretically there was no good reason to have more than 1 SBBS address. User could just live fine with only a single SBBS address, and share it freely. As we've said, all the messages are completely opaque, and the communication is anonymous.
There's only limited scenarios where a user may need more than 1 address. If the user wishes to provide several addresses that look like of different users (for example, have several accounts at an exchange, with different SBBS addresses for funds withdrawal).
However, due to user habits and some misconceptions, users insisted on changing addresses regularly. That's why we implemented automatic SBBS address generation and expiration
Unlike other blockchain designs, in Beam there're no addresses on the blockchain per se. As a result, if Alice sends funds to Bob, there's no way to prove it later from the blockchain data (Bob has plausible deniability).
To address this, we implemented a Payment Proof. It's a signature, signed by the recipient of the funds, that it indeed accepts the specific amount from the specific sender. It is signed by the receiver and verified by the sender during the transaction negotiation stage (all this happens off-chain).
The Payment Proof signature signed the following:
- Identity (pubkey) of the sender
- Identity (pubkey) of the receiver (the signature is signed by the corresponding private key).
- Amount and asset type being-received
- Transaction Kernel ID. If the tx was negotiated but not broadcasted and accepted in a block - the Payment Proof is considered invalid (i.e. there was an intention of the tx, but it didn't take place actually).
Identities of both sender/receiver were in fact their SBBS addresses. That is, the same key was used both for SBBS messages encryption, and to identify the owner of the funds.
With the hardware wallet the things work differently. The Master Key and all the coin keys are managed entirely in the HW wallet. The software wallet gets the Owner Key that can recognize coins (but not spend them), and handles all the communication and blockchain state change logic.
The SBBS address must be managed by the software wallet, it's too complex for the HW wallet to decrypt all the SBBS traffic. On the other hand, when the Payment Proof is signed/verified - it must be done with the key that is managed by the HW wallet.
This is where we decided to split the SBBS address and the user identity. The SBBS address is the address you're communicating with, and the Identity is the public key of the final receiver/sender of the funds. For standard wallets both are managed by the wallet, but with the HW wallet they're managed in different places.
To support this, we defined a new-style address (now called a Regular address).
First, the address format was changed. The older SBBS address was just a hex-encoded pubkey. We decided to change it into an encoded collection of arbitrary number of parameters (to support possible future parameters for various address/token types).
The Regular address consists of the following fields:
- SBBS address
- User Identity
Historically we had several names for the above user identity: Identity, HW Identity, Signature, and etc. All that lead to confuses, so we decided to give a distinctive way to this: the Endpoint.
The rationale behind this name is the following. Suppose Alice sends funds to Bob, both use HW wallet. Conceptually you may treat this situation as this: Alice's HW wallet is the ultimate sender of the funds, Bob's HW wallet is the ultimate receiver. And they negotiate the transaction with each other. The software wallets of Alice and Bob are just intermediate entities, they're not part of the transaction negotiation.
In other words, the Endpoint is the final source/destination of the funds.