Category Archives: RSK

Blockchain: Links And Resources (138)

Previous Post
Next Post

Blockchain Resources

RSK Brings Blockchain Regtech Leader Coinfirm and its AML/CTF Platform Into its Federation

Ethereum: Precompiled contract for pairing check

Precompiled contracts for adition and scalar multiplication on the elliptic curve

Abstraction of transaction origin and signature

Alibaba Launches Cryptocurrency Mining Platform

Ethereum Classic

Stay tuned!

Angel “Java” Lopez

Versioning of Entities in Ethereum/RSK

In these past two years, I wrote posts about blockchains, Ethereum, and the RSK project. Many times, I wrote about a personal experiment, with personal projects, or about a proposal, experiments using open source published code. And many times, I needed additional information in the Ethereum/RSK blockchain. An example: I should write about supporting more than a kind of virtual machine, or the support of colored ether, but in such proposal, a need appears: having extra information in a Transacion or into an Account state.

Currently, Ethereum projects and derivates,, like Ethereum/RSK, encoded the core entities using RLP (Run Lenght Prefix) encoding, specified in the Yellow Paper. Using a dedicated encoding ensures that every implementation obtains the same hash derived from the encoded format of an entity. The hash of a block header is derived from its encoded representation.

Internally, each entity is serialized to a list of RLP encoded items. If an entity, an AccountState, has two internal fields, balance and nonce, then the encoded representation is an RLP list with length 2.

My proposal is: if you need an additional field o fields into a core entity, it should be discussed in the project community, as any other improvement proposal. But the way to implement, any future extension, is the same. Take as an example the above described AccountState. Initially, its encoded form has TWO RLP items in a list. When you received the encoded bytes, RLP can determine THE NUMBER OF items. If the number of items is TWO, then the encoded representation is the original one. BUT if the number of items is GREATER THAN TWO, the third fields should be a byte (or two bytes) DECLARING THE VERSION of the encoding. Maybe, version 1 for AccountState is the way to say that the FOURTH item is the color of the balance, and version 2 indicates that the FIFTH item represents another field added later, etc….

When you serialized the AccountState, if the additional fields have their default version, you only serialize TWO ITEMS, WITHOUT version field. In this way, the encoded is the same than the original, and it is a normal form that avoid the lost of consensus (ie another node serializing the AccountState with THREE fiekds, with version 0; such serialization should be forbidden). So, any AccountState (any combination of its internal state) has a NORMAL FORM of serialization. If the first additional field has a non-default value, and the second one has a default value, then the version included in serialization should be 1 (ONE). A version could have many added fields. My example only discuss the addition of a field in version 1 and another one in version 2.

This serialization strategy could be applied to the core entities like

  • Blocks
  • Block Headers
  • Account States
  • Transactions
  • Transaction Receipts

And when a new version is included, it does not affect the previous serialized entities.

I should write about some application of these ideas.

Stay tuned!

Angel “Java” Lopez



Blockchain: Links And Resources (131)

Previous Post
Next Post

RSK Mines Its Genesis Block – Bitcoin Now Has an Ethereum-Like Smart Contracts Platform

Bitcoin Diamond/Super Bitcoin/BitCore: What You Need To Know

IOHK | Prof. Elias Koutsoupias, area leader, game theory.

Después de Paypal y Facebook, Peter Thiel apuesta fuerte al Bitcoin

How to call a contract method using the eth_call JSON-RPC API

Make Bitcoin Mining Transparent Again

Video: How ShapeShift CEO Erik Voorhees Makes Sense of Crypto Assets

Building your own blockchain in R

Stay tuned!

Angel “Java” Lopez

Blockchain: Links And Resources (130)

Previous Post
Next Post

RSK Beta Brings Ethereum-Style Smart Contracts Closer to Bitcoin

if you invested $1000 USD on 01/01/2017 into the following coins, you would now have…

RBC Report: Crypto and Blockchain Could Unlock $10 Trillion Market

Why Bitcoin Needs Fiat (And This Won’t Change in 2018)

Blockchain Voting Is Here for Enterprise, But Where Are the Users?

Sidechains Project Pushes Ahead with Bitcoin BIP Submission

Peter Gaži: Ouroboros and Ouroboros Praos

Interview: Charles Hoskinson (ADA)

Stay tuned!

Angel “Java” Lopez


Connecting Blockchains (7)

Previous Post

It’s time to present a proposal to solve the problem of a bidirectional communicacion between heterogeneus blockhains, like Bitcoin and Ethereum/RSK. Having more support for logic (and state) in Ethereum/RSK, this solution will use smart contracts to accomplish the mission. Although there is a current implementation in RSK to connect the two blockchains, my aim is to explore an alternative one, simpler, in order to understand the problem and what are the hard parts of any solucion. So, there are common points, but also it is a departure of that implementation,

One goal I want to purse is simplicity. What are the minimal parts to take into consideration to solve the problem? One consequence: avoid UTXO (the selection of unspent transaction outputs from Bitcoin to transfer from Ethereum/RSK) logic into consensus (current RKS bridge implementation has a lot of logic to manage this case). And I want to reach a solution that can be easily implemented in many platforms, so I avoid custom code (like precompiled contracts in Java) when possible. So, I adopted Solidity as programming language to write smart contracts.

If both blockchains were homogeneus, ie Ethereum/RSK, the solution should be simpler: instead of two ways transfer, I could implement the one-way solution: how to transfer from blockchain A to blockchain B. The same solucion could be applied in inverse order.

But the current problem involves different blockchains. The main idea is depicted by this figure:

There are transactions (solid lines) and queries (get data, from source to target, after a target query). Transactions are movements that resides in the target blockchain. As I discussed in previous posts, there is an special BTC bridge account, that receives fund from a BTC user. Then, all this system should emit an Ethereum/RSK transaction that transfer value from an special Ethereum/RSK bridge account to the corresponding user Ethereum/RSK account (each user in BTC has automatically a corresponding account in Ethereum/RSK).

But smart contracts cannot get data from the external world: an smart contract cannot READ the Bitcoin blockchain. The facts that occurs in the external world should be informed by special nodes with custom offline code, that READ Bitcoin blockchain, detecting the new blocks and the transfers to the special BTC Bridge account.

So, the solution needs that special accounts, named Federators or Oracles, accounts in which the system trust. It’s a common pattern in smart contracts: having oracles, special external entities, that send transactions with new fact data, ie, a football match result to an sport bet contract.

The federation is a set that should be build at the start of this system, and it could evolve: new federators could enter into the system, and some federators could leave it. By now, the proposal to be described has a fixed federation since inception. I could discuss the evolution of federation in later posts.

A federator is connected to the Bitcoin mainnet, and detects:

  • New blocks in Bitcoin
  • Transactions that has special bridge BTC account as a member (as sender or receiver)

Also, a federator could emit:

  • A BTC transaction to transfer funds from special bridge BTC account to a normal user BTC account

These are the interaction of a federator with Bitcoin. For security reasons, the BTC transfer described above involves multisignatures outputs, that need the signature of many federators to be valid. I will discuss the built of such transaction in the next post.

The federator also emits:

  • Transactions to Ethereum/RSK informing the appearance of a new BTC transaction with funds transferred to BTC bridge account
  • Transactions to Ethereum/RSK informing the appearance of a BTC transaction that transfer funds from BTC bridge account to a normal BTC user

Then, these transactions communicate the external FACTS that this set of oracle should inform to Ethereum/RSK blockchain.

A federator also query Ethereum/RSK:

  • To know if there is a new Ethereum/RSK transaction from normal user to Ethereum/RSK bridge account

Using Ethereum/RSK as a communication device, a federator also sends to that blockchain:

  • Proposal of BTC transaction to be broadcasted to Bitcoin mainnet, to comply with the Ethereum/RSK transaction (user to Ethereum/RSK should be reflected by a corresponding Bitcoin transaction)
  • Sign any proposed BTC transaction by other federator

To do all these actions, the proposed system is:

Green rounded rectanbles are SMART CONTRACTS in Ethereum/RSK

A Federator/Oracle should manage an Ethereum/RSK account to send transactions. At the beggining of the process, each federator decect blocks and bridge BTC transactions from Bitcoin mainnet. When they have enough confirmations for a BTC transaction that transfer funds from BTC user to BTC bridge account (this step could be modified, an alternative to be discussed in next posts), a federator emits a transaction with the new BTC transaction data (hash, block hash, transaction index, sender account (an Ethereum/RSK address, translated from the original BTC user account to the Ethereum/RSK system), amount to be transferred).

The Receiver contract is like a voting system. It accepts transaction fact messages ONLY from federation members (maybe from other oracles, too, alternative to be discussed). But only when that fact has ENOUGH confirmations from the other federators, maybe m > n / 2 + 1 (n is the federation size), then it send a transaction to Bridge contract. This contract only trust in the Receiver instance. Then, the Bridge instance transfer funds from its own balance to the final user Ethereum/RSK account.

When the Bridge contract receives a transfer from a user Ethereum/RSK account, then it emits a transaction to the Sender contrac instance. This instances has state that can be query by the federators. The state consists of the list of transactions that are pending, that still need to be broadcasted to Bitcoin mainnet, to reflect the devolution of BTC to the user. It is the second part of a 2-way communication.

No federator could release BTC funds alone. Each one needs the help of the others to build a valid BTC transaction. Then, when a new pending Ethereum/RSK release transaction appers in the state of the Sender instance, a federator could build (using custom code) a proposed BTC transaction. This process involves the translatioin of the user Ethereum/RSK account address to his/her BTC address, and the selection of valid UTXOs to be applied in the new transaction to pay the user. All this process is OFFCHAIN, it does not affect consensus, and could be improved and adapted to the changes of Bitcoin implementation.

The proposed BTC transaction is sent to the Sender, as a serialized byte array. The other federators could detect the proposed transaction, and they could send a new one, adding their own signature, or they could proposed a second transaction (double spent issues to be discussed in next posts). When a transaction (a byte array in Sender instance) has enough signatures, any federator could broadcast it to the Bitcoin mainnet.

When a federator detect that the broadcasted transaction WAS confirmed in Bitcoin mainnet, it should inform the Sender. This instance, when it have ENOUGH federator confirmations, remove the pending transaction.

There are many details to be discussed. Some important ones: both Receiver and Sender could use a BTCRelay instance (an special contract, already written), that validates that a given BTC transaction exists in the blockchain with enough confirmations.

There is some initial code in my github projects, but I hope I will present a more complete picture in the next posts, with referred code implementation. Remember: talk is easy, show me the code!

Stay tuned!

Angel “Java” Lopez

Blockchain: Links And Resources (126)

Previous Post
Next Post

A Justice System for the Internet Age

What are some predictions about the value of Bitcoin in 1-5 years?

Entrevista a Diego Gutierrez Zaldívar

CrowdSale code

Ten years in, nobody has come up with a use for blockchain

Smart Contract Languages Development to Follow
What languages I’ll keep a close look at next year (2018)

Criptomonedas e Impuestos en Argentina

Why Bitcoin Worth Anything?

Stay tuned!

Angel “Java” Lopez


Blockchain: Links And Resources (125)

Previous Post
Next Post

The convergence of AI and Blockchain: what’s the deal?

Bitcoin Diamond

El bitcoin es sólo la punta del iceberg

¿Es posible fabricar bitcoins desde tu computadora y ganar dinero?

Everything You Need to Know About Blockchain But Were Too Embarrassed to Ask

Exclusive: Telegram to Release Blockchain Platform, Native Cryptocurrency

Introduction to Blockchains & What It Means to Big Data

Etherparty & RSK Partnership Fuels Future Adoption of Smart Contract Technology

Stay tuned!

Angel “Java” Lopez