Addresses

Address is a reference in RSCoin, which represents wallet, i.e. entity holding some coins.

In RSCoin we use two types of addresses:

• Simple
• Multisig

Simple

Simple address is an address, which is controlled by exactly one party. In particular, it's party holding secret key (further SK), from which address is generated (recall that address is represented by public component of Ed25519 key pair).

To perform transaction, user signs it with it's SK, provides this signature along with transaction, this way proving it's having this address in control. For details see Transactions.

Multisig

Multisignature address is an address, controlled by few parties. More specifically, multisig is an M-of-N address. It means that address is controlled by N parties and at least M parties have to confirm the transaction to get it performed. Under confirming we mean signing transaction with party's secret key.

In case of simple addresses, we don't even need to store all of them in system, cause address itself determines it's owner. However in case of multisig addresses we need to introduce some storage, so that when someone would like to perform transaction with multisig address, system would have possibility to check, which parties control this address.

Committing transaction, which has a multisig address is split in two steps:

1. Registering MS address
2. Performing a transaction

For handling MS addresses we have two cases, when we need to collect signatures. For this purpose we introduced special entity, Notary.

Registering MS address

Main idea behind first step, Registering MS address is gathering signatures of all N parties (instead of single user's signature). This is done in following:

1. User proposes ms allocation request to Notary

   In the request user sends ms allocation data, which is basically list of all N parties and M threshold.

   Along with this he attaches his signature of data. I.e. signature of ms allocation data, done with User's SK.

2. MS allocation request is registered on Notary

3. All N parties of MS address should request ms allocation data from Notary, sign it with their key and return the key to Notary

4. Once this is done and Notary has all N signatures required, it publishes ms allocation data along with them to Bank

5. Bank checks all signatures are correct and relevant to ms allocation data and publishes this data on the next HBlock, this way address gets known to all participants of system.

After step 5, address is registered on system and can be used as input or output in transactions.

Performing a transaction

Second step, Performing a transaction is described in section Transactions.

Allocation key and spending key

// (?) Before reading this section, I recommend you to read Transactions.

Recall, that MS address allocation contains following fields:

• List of parties
• Threshold

In simplest case, party in the list is represented by it's PK. So that we can sign transaction by paired SK, this way conforming our agreement to perform this transaction. Same holds for ms address registration.

But consider following case: what if we want PK1 for transaction confirmation and PK2 for ms address registration be separated. So for registering MS address we would sign ms allocation data we use SK1 and SK2 for transaction confirmation.

For this case we designed following distinction: party in the list is represented either by PK or by pair of public keys allocationPK and spendingPK (as described above).

But what's the benefit of introducing such scheme with two distinguished keys? Suppose we have a system, in which money are sent to address at one time and are to be spent only some time later, say in two months. This way we may generate two key pairs (allocationSK, allocationPK) and (spendingSK, spendingPK). Right after generation we drop spendingSK to flash card, that is then put to some secure storage (such as deposit box in Switzerland) and retrieved back only after two months. With no access to spendingSK there is no possibility to confirm transaction (and hence spend money). Then, after two months, one takes that flash card back and is able to spend money.

DDOS attack prevention

Going even further, we might think of following security concern: how do we prevent DDOS attacks?

More particularly, we have basic RSCoin inrastructure with Bank and Mintettes (Infrasture), with simple addresses already secured from DDOS by design.

All we have to consider is MS address-related stuff. So, what are potential leaks of introducing multisigs in a described above way? It turns out that it's only Notary, on which some concerns may arise. Address registration process is handled by Notary (no Bank or Mintettes participate in this process). Transaction sending also, cause transaction is to get Bank or Mintettes only after all signatures are collected by Notary. And after they're collected, transaction is proceed just in the same exact way it would be proceed in case of transaction, that uses only simple addresses as inputs.

On Notary there are two potential leaks:

• you can DDOS Notary with transactions that don't even need to get ever signed
• you can DDOS Notary with MS allocation requests

First case we prevent by simply blocking some MS addresses in case some simingly adversary activity. We limit amount of pending (i.e. not signed) transactions for particular MS address and introduce some TTL for pending transactions so that they won't consume all the memory eventually.

But second case is slightly more difficult. We can not limit anything by address cause we have not yet address known to system. And attacker may potentially generate as many addresses as he need and we would have no possibility to distinguish among them. There exist at least few ways of how we could manage this. We decided to leverage potential load from DDOS via address allocations on separate entity (or entities). This is made in following: among ms allocation and it's sign by allocation key Notary excepts requester to provide signature of his allocation key by some other key, key we trust.

This could be extended to concept of certificate chains. Along with allocation request we provide a chain of PKs and signatures, proving our identity. Like we have few PKs hardcoded in system, so called root PKs. Root PK is authorized by definition. If some other PK can provide a signature of self, made by authorized key, then it's also authorized. This way we mantain a chain of arbitrary length, which proves that we are actually a known actor of system.

And we then request User to provide along with allocation request a signature, made by authorized party. This way we leverage possible load on a set of authorized parties, not Notary.

Implementation

In current RSCoin we implement limited size cert chain of max length 2.

Basically, it's triple (masterPK, allocationPK, allocatuionPK.sig), where allocatuionPK.sig is made by masterSK.

• Master key: (masterSK, masterPK)
• Allocation key: (allocationSK, allocationPK)