Transactions

• Overview
• Coin Hours
• Unspent Outputs (UXTOs)
• UXTOs and Transaction malleability
• Transaction privacy
  • What is CoinJoin?
    • CoinJoin Hardening
• Avoiding Key Reuse
• Final remarks

Overview

Transactions over the Skycoin network allow users to transfer SKY among each other in a fast, secure and reliable way. Each transaction is constructed out of several elements. This section will describe each element and demonstrate how to use them together to build complete transactions.

The figure above shows the elements of a Skycoin transaction. Computationally speaking, a Skycoin transaction is a data structure with the following elements:

• Length: A transaction’s size is defined as the length of its binary serialization, encoded according to the Skycoin Binary Encoding Format. This is the same binary representation that is used to calculate the transaction’s txid.
• Type: Transaction’s version. When a node tries to process a transaction, it must verify whether it supports the transaction’s type. This is intended to provide a way to update skycoin clients and servers without crashing the network. If the transaction is not compatible with the node, it should not process it. The only accepted version is 0. Reserved for future use.
• Txid: Transaction’s identifier. It is a SHA256 of the serialization of the whole transaction, and it is used to reference a specific transaction within the blockchain.
• Inner Hash: The SHA256 hash of the inputs and outputs of the transaction. It is used to protect against transaction mutability. This means that the transaction cannot be altered after its creation.
• Timestamp: Represents the time at which the transaction was created. It is used by Skycoin nodes to determine which block of Skycoin’s blockchain the transaction belongs to.
• Sigs: A list of secp256k1 signatures created by signing the inner hash with the private key associated with the address of the corresponding unspent output in the inputs array.
• Inputs: A list of SHA256 hashes of the unspent outputs being spent.
• Outputs: A list of unspent outputs to create. When the transaction is added to the blockchain, these unspent outputs will be added to the unspent output pool. An output contains a destination address and an amount of coins and coin hours.

Coin Hours

Unlike Bitcoin, Skycoin users don’t need to give away part of their balance as incentive from miners to process their transaction. Instead, they use Coin Hours as fees. Coin Hours are automatically generated by holding SKY in a wallet (1 Coin Hour by every hour you hold a 1 Coin). Coin Hours are similar to “Gas” in Ethereum or coin aging in Bitcoin, but are exchange-tradeable and are a separate parallel currency in Skycoin. This way, Coin Hours work as a spam prevention mechanism, and a way to allocate scarce resources (like bandwidth or storage) without the need to rely on the coin supply for this.

In future versions of the Skycoin protocol, Coin Hours will have an exchange rate against SKY, allowing for an optimal displacement of resources according to demand.

See Coin Hours in the Skycoin Github Wiki for more information.

Unspent Outputs (UXTOs)

Unspent outputs (UXTOs) are consumed and created by transactions.

The figure above shows the elements of a Skycoin transaction output. Computationally speaking, a Skycoin transaction output is a data structure with the following elements:

• Hash: The SHA256 hash of the serialized output structure.
• Source Transaction: The txid of the transaction that created this output.
• Address: The address that “owns” this output. For this output to be spent, a transaction’s signatures array must have a valid signature corresponding with this address.
• Coins: The number of Skycoin assigned to this output.
• Hours: The number of Coin Hours assigned to this output.

UXTOs and Transaction malleability

Skycoin’s UXTO model eliminates several deficiencies that allow Bitcoin transactions to be tampered with. Unlike Bitcoin UXTO, Skycoin transaction signatures sign all mutable state of the transaction (the inner hash). In Bitcoin, attackers can make non-functional modifications to a transaction without rendering it invalid. For example, an attacker can add some data to the signature script which will be dropped before the previous pubkey script is processed.

Although the modifications are non-functional—so they do not change what inputs the transaction uses nor what outputs it pays—they do change the computed hash of the transaction. Since each transaction links to previous transactions using hashes as a transaction identifier (txid), a modified transaction will not have the txid its creator expected.

This isn’t a problem for most Bitcoin transactions which are designed to be added to the blockchain immediately. But it does become a problem when the output from a transaction is spent before that transaction is added to the blockchain.

In Skycoin, the fact that signatures are associated to UXTO inputs renders transaction malleability attacks useless.

Transaction privacy

Bitcoin transactions are not fully anonymous, but pseudo-anonymous. Public addresses can be associated to users’ identities. Therefore, users need to implement additional techniques to enhance their transaction privacy. Nevertheless, the integration of privacy schemes in Bitcoin is not seamless, and requires a certain level of expertise and knowledge level, which makes highly unlikely their mainstream adoption.

To address this issue, Skycoin includes built-in support of Gmaxwell CoinJoin.

What is CoinJoin?

CoinJoin is a protocol that combines multiple transactions into a single one, named CoinJoin transaction.

Instead of broadcasting the transaction, the client can send it to a CoinJoin server, which will receive multiple transactions from Skycoin clients and combine them with other transactions. The CoinJoin server then requests the needed signatures from each client and broadcasts the signed transaction onto the Skycoin network.

The structure of Skycoin transactions provides native CoinJoin support by splitting the signatures, inputs and outputs into separate arrays.

CoinJoin Hardening

There are several practices CoinJoin servers can adopt to further increase transaction privacy. Here we list a few of them:

• CoinJoin servers can reject outputs held by addresses that engage in address reuse.
• CoinJoin servers can reject outputs from addresses which have received transactions from addresses engaged in reuse.
• CoinJoin servers can require that all created outputs must belong to unused addresses.
• CoinJoin servers can turn a unary CoinJoin into a binary CoinJoin, or a binary CoinJoin into a ternary Coinjoin (in general, an n-ary CoinJoin into an (n+1)-nary CoinJoin) by using an internal mixed wallet owned by the CoinJoin server.
• Privacy concerned users can run their own CoinJoin servers.
• CoinJoin servers can federate and and be configured to mix wallet transactions through other CoinJoin servers (this is called Global Mixing).
• CoinJoin servers can fix the number of coins per output to a constant. For instance, they can determine that all outputs generated by CoinJoin transactions shall have up to 5 SKY per output, and only employ unused adresses, thus causing a transaction recipient expecting 100 SKY to receive 20 potentially unrelated on-chain transactions instead of a single on-chain transaction with 100 SKY.
• CoinJoin servers can require that each output created by a CoinJoin transaction is a power of a certain natural number. For example, powers of 2.

CoinJoin servers can be funded by collecting the CoinHour balances of outputs flowing through them.

The reason that CoinJoin is natively supported by the network is because Skycoin was intended to be seamlessly used by any user, regardless of his/her technological expertise. In this way, the power of anonymity is given to any person who trades Skycoin.

Avoiding Key Reuse

In a regular transaction, both the sender and receiver reveal to each other all public keys or addresses used in it. This allows either person to use the public blockchain to track past and future transactions involving the other person’s same public keys or addresses.

If the same public key is reused often, as happens when people use Bitcoin addresses (hashed public keys) as static payment addresses, other people can easily track the receiving and spending habits of that person, including how many satoshis they control in known addresses.

It doesn’t have to be that way. If each public key is used exactly twice—once to receive a payment and once to spend that payment—the user can gain a significant amount of financial privacy.

To enforce this behavior, a CoinJoin server can can require that all created outputs must belong to unused addresses, as explained in CoinJoin Hardening section.

Final remarks

• To the date, there is no equivalent to Bitcoin’s Pay To Public Key Hash (P2PKH) nor Pay To Script Hash (P2SH) transaction types in Skycoin, as there is no scripting language for Skycoin transactions. Note: There is CX for scripting but this is not part of the core Skycoin blockchain
• In Skycoin transactions, a signature is required for every unspent output consumed as input.