Sergio Demian Lerner June 2020 AMA
On June 4th 2020, IOVlabs Chief Innovation Officer Sergio Demian Lerner participated on an AMA session. Here are the questions and answers:
In looking over the whitepaper there is both “Smart Bitcoin”, RBTC, the native token for, RSK Smart Contracts, which appears to be only to pay for tx fees/gas. Is there a reason that RIF Token is truly necessary, or in theory could everything have been done with RBTC?
“RSK” is the name of the Smart Contract platform (originally it was called Rootstock, and that’s why in the RSK community we still call ourselves rootstockers). RSK Smart Contract native currency is RBTC and all the basic platform services like smart-contract execution and transactions are paid with RBTC (which is 1:1 pegged to BTC). On the other hand RSK Infrastructure Framework (RIF) token is intended to allow any token holder to consume decentralized infrastructure services that are compatible with the RIF Protocol Specifications.
Is the RIF token essentially ERC20 on the Rootstock network? I was under the impression that there is some dev fee/founder’s reward as well – is that true and is that paid out in RIF tokens?
You’re reading the RSK Smart Contract whitepaper. That whitepaper describes RSK Smart Contract. The RSK Infrastructure Framework (RIF) project came much later, and has its own foundational white paper. The transactions fees in RSK are split: 80% is paid to the miners, 19% is paid to a team that improves and maintains the RSK reference implementation, and 1% goes to the federation functionaries for their services. Note that RSK Smart Contract does not have a subsidy, so all payments must come from real network usage and real transactions by real people. There’s no speculation.
In a sense RSK Smart Contract is like looking at Bitcoin in the future, when the subsidy value is lower than transaction fees collected (if that ever happens).
…“when the subsidy value is lower than transaction fees collected (if that ever happens).” With subsidy going to 0, how could that be a matter of “if”?
Well, that will be in 120 years or so. We may all be dead by Covid-87 by then but I was referring to a more near future, say next 20 years. What will happen in 120 years is not very relevant for today’s problems, because the community will have enough time to get consensus about possible changes.
So is RIF Token basically just like ERC tokens?
Yes, it’s an ERC20 token that can be used for a wide range of 2nd layer services like oracles, decentralized storage (RIF Storage), domain names marketplace (RNS), self sovereign identity, secure communications, watchtowers staking. It’s like chainlink+filecoin+gram+sovern all under a single utility token.
Could you let me know which of the major vulnerabilities you found was the most critical for Bitcoin?
Satoshi embedded in the reference client a feature to distribute notifications on all nodes in case a vulnerability was found. This was the alert system (remember?). Alerts could be signed by Satoshi or by other core members that had the required private keys. Alerts were the first message that was broadcast to nodes after the initial protocol handshake, and nodes would flood the network with new alerts as fast as possible to make sure every node knew about a security update. I turned out that the code had a vulnerability, and this was the first signature malleability vulnerability in Bitcoin. You could take a freshly generated alert and mutate it fast in so many ways that nodes would fill their RAM memory with clones and crash, not before sending all to their peers. Pushing them to crash also. This was because the signature was part of the unique id of the alert, so all mutated alerts were considered different. The core team could not emit an alert to protect the network, because doing so would put the network at the risk that the alarm would be mutated by an attacker. Even if I never simulated an attack, we all agreed at that time that the vulnerability would take down the whole network until all (or almost all) nodes upgrade. Like herd immunity, you need a high percentage of nodes to upgrade to protect the rest. And during the attack, every node became malicious. It was pretty bad.
What are RSK’s Smart Contract most prominent technical features?
Well, there was a lot of development put into the 1:1 peg and the federation. RSK Smart Contract peg is a very interesting system. For instance, it has all the functionality of Liquid’s peg, plus dynamic federations (the protocols for the federation to dynamically add or remove members in complete transparency and in a time-delayed way). Also the RSK Smart Contract merge-mining subsystem is unique, as it uses several techniques to monitor for forks (Armadillo) and to compress SPV proofs. Finally I like Unitrie, the unique binary trie that RSK Smart Contract uses for storing all the information (both accounts and smart-contract code). This structure is very memory-efficient enabling storing millions on accounts in memory. This increases the amount of accounts or storage cells that can be accessed in a block , and so it increases the scalability of the RSK network.
So RSK Smart Contract has a high scalability, but it is my understanding that RSK Infrastructure Framework (RIF) is part of the mix precisely to help provide an even higher scalability, can you tell me more about how RIF data can still be recorded on the RSK blockchain and at the same time offering such a large improvement in scale?
The RSK Infrastructure Framework (RIF) solution for scalability is called RIF Payments. RIF Payments is an API to integrate with many payments solutions under a single API and SDK. One of the main services registered in RIF Payments is RIF Lumin Network. RIF Lumino Network is a 2nd layer payment channel network (PCN) with properties similar to Bitcoin’s lightning network (low latency, low cost). Since RKS onchain transaction costs are also lower than Bitcoin, opening and closing Lumino channels is less costly and more dynamic. That also makes Lumino transactions cheaper. You can get more info at https://www.rifos.org/payments.
Having said that, the RSK Smart Contracts onchain layer is much more scalable than Bitcoin mainly because transactions are smaller (technically the testnet has been recently stressed with 150 tps without problems). The problem, often misunderstood, is not how many transactions a CPU can process per second in isolation, nor how many transactions the existing network can process, but how many transactions can be processed by the network while keeping the resources consumed (storage, memory, CPU and bandwidth) at a minimum to keep the network decentralized so that a relatively cheap computer can join. In line with this reasoning, the RSK community plans to deploy the LTCP compression protocol that can decrease transaction sizes 5 times, increasing scalability, maybe as much as 3x.
What type of daily activity does rootstock see compared to eth? Is there a website comparing like number of txs, or btc/eth/value locked in smart contracts?
The number of transactions in RSK have been steadily increasing since the genesis block. The last wave of transactions came with the launch of money-on-chain stable coin (a token that is pegged to the USD with collateral in RBTC). The RSK explorer: https://explorer.rsk.co/ shows all current and past transactions but not statistics.
It would be interesting to see how tx count and value locked compares to ETH at least and maybe other smart contract platforms. Maybe messari or someone is already tracking?
You can see the circulating supply here: https://explorer.rsk.co/ – Currently it’s 190 BTC. You have to take into account that for 2 years the federation has artificially limited the amount of funds that could be pegged-in, to make sure the network was robust enough. This year, the federation is increasing this artificial cap, as its members have announced. Increasing the cap is not a hard-fork, but a message they can send to the bridge contract, and they can only vote for increasing it, but not for decreasing it.
The game-changer here is a new version of the HSM (hardware security module) that the all federation functionaries will soon be running. This upgrade provides the level of security of a security enclave running an embedded SPV node which follows hashrate. You can compare this to the pBTC token, but our solution uses a secure element in the HSM that does not share any resource with the main CPU, instead of pBTC which is based on Intel SGX, whose security has been broken over and over in the last couple of years (18 vulnerabilities in total!)
How is the RSK Smart Contract peg system different from Liquid’s?
There are several differences. An article that I posted some time ago summarizes them, but I will summarize the summary in the next reply.
One difference is that Liquid peg-out is a process that generally requires KYC, with the exception of some participant exchanges that allow peg-outs for low amounts of btc . To peg-out a large amount you must be registered in the Crypto Exchange of one of their functionaries. RSK Smart Contract peg-out does not require KYC. RSK has a nice property I call all-or-nothing censorship-resistance which means that if the federation functionaries want to censor a peg-out transaction, they need to censor all remaining peg-out transactions. Therefore, they have no choice other than to keep their HSMs connected if they want to keep being a functionary. Another difference is that the RSK Federation has all the procedures embedded in the HSM to perform a secure federation update, to either add or remove members. This feature, called dynamic federation, is still lacking on Liquid. In RSK, the migration process is transparent and there is a forced delay of 15 days to allow the community to verify the profile of the new federation members and react accordingly.
I’d like to add that building a successful and secure federated two-way-peg with hardware security modules that has been running without any security incident for 2 years it’s a remarkable feat. I don’t want to give names, but other projects that aimed less than RSK had security incidents and network disruptions.
How long it took you to do the original and your last research about the Patoshi pattern?
The original research took me one night. And the following day I didn’t eat nor I remember having stood up from my chair. I just waited looking at the traffic on my site go astronomically high, and wondered if what I had done was good or bad for Bitcoin. And I saw everything that I had made, and behold, it was very good. My last research about Patoshi in 2019 took me a lot more, because I wanted to bring more scientific rigor to the table, so that some old and weak arguments against the Patoshi research could be easily removed from serious discussions.
How did you discover the “three privacy-related flaws” to correlate the blocks? Just reading the early client or there’s something more? Please, comment on this a little.
It took me several years to understand the relation between the three privacy flaws. During those years I received help and clues from other researchers that decided to dig deeper into the mystery of the Patoshi pattern. There is ALWAYS something more. I have collected a number of clues and rarities in the Patoshi pattern over these years. I’m still interested in understanding the reason why the Patoshi pattern exists, but I don’t want to dig any more into the private matters of Satoshi. That’s why I generally ignore the many people that write to me to tell me who Satoshi really is. I feel I contributed enough to the transparency of Bitcoin.
After this research, do you think that this was fair or this could make us think differently about Satoshi? Why?
Assuming Satoshi =/= Patoshi, I believe, based on the past history of Satoshi coins, that Satoshi won’t use his coins ever. Therefore I think that there couldn’t be a fairer and more altruistic way for Bitcoin to be born.
In the Nonce Restriction in all Patoshi Blocks paragraph you talked about a proof that you found to check the pattern by other ways. Please, comment on how you get the proof.
The last article shows one (there are others) ways of checking that the pattern is real. It involved comparing the timestamp of all consecutive blocks. Two consecutive Patoshi’s blocks would never show inverted timestamps (the second lower than the first) while all the other combinations show very often inverted timestamps. This implies that there was a single clock source to stamp the timestamps, and this property holds for all coinbases in the Patoshi set. So we have the nonce LSB, the particular extraNonce/time slope, and the non-inversions of clocks. But there is still another characteristic of Patoshi blocks related to the way the nonce was scanned. Maybe I will publish it soon, because I still don’t have an explanation that satisfies me, for that oddity.
At the end of the article, you stated that “there is evidence that links the Patoshi patterns to Satoshi, based on public information sources and the blockchain”. Could you comment on this? How can you link the pattern with Satoshi?
There are people that have published private information involving transactions between them an Satoshi. For example Hal Finney, Mike Hearn, and Dustin Trammel. All those transactions can be easily spotted in the blockchain because at that time the number of transactions in each block was very low.
If you look at Satoshi’s inputs consumed in the transactions that these people attribute to Satoshi, you’ll see they all belong to the Patoshi pattern. That’s why it is believed that Satoshi is Patoshi, but this is not hard evidence, as people can lie, or forget what happened.
I wanted to know if you can recommend us, a few books or papers or articles about Bitcoin that you find interesting. It may be about the tech stuff, or social, or economical.
Any person working on cryptocurrency research reads about 2-3 new papers a day, so I cannot tell you one that somehow compresses all the research. I would look for good surveys of knowledge , like old Princeton’s https://wws.princeton.edu/system/files/research/documents/Felten_SoK.pdf . Similar SoK exists for 2nd layer networks, interoperability, privacy, interoperability, sharding, and so on.
What are your plans and contributions to foster RSK decentralization?
Several new things are coming from IOV Labs Innovation Team First, since the early whitepaper we envisioned a smooth transition to a drivechain. We published the first drivechain implementation and BIP (this is something not so well known in the ecosystem).
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013174.html
But soft-forking Bitcoin is difficult because we must all consent to the changes, and so we think maybe it’s not the right time to pursue that. To decentralize RSK’s federation meanwhile, I’ve been temporarily calling Discrete Dynamic Drivechain (DDD, until I find a more catchy name). This is a drivechain built on top of a federation so miners can take part on the peg multi-sig, with a contribution that grows accordingly to their hashrate. So in practice, it’s a drivechain. The paper is ready and I have circulated among a few researchers in IOV Labs to collect feedback, and I will publish to the whole RSK community soon. I think this could be a great addition to RSK to make it the most decentralized platform. I have also written a paper on how to improve Bitcoin’s decentralization (a protocol I called Nakamore) that I hope to publish soon.
Do you think if the core developers themselves could be decentralized or if Bitcoin´s core developers group is decentralized at all?
I think it’s decentralized enough. That doesn’t mean it’s easy to be part. Maybe the Bitcoin core developers disagree with me on this, but when I interacted with them in the 2012-2014 period and I felt you had to earn their trust with BIPs, your code or other contributions before they would merge your code. In a sense it’s a psychological security barrier. However, the people that I know that decided to contribute to Bitcoin development and worked hard to do it managed to get their code merged. But you have to be willing to accept criticism and rework your code. I would love to hear what’s like to be a Bitcoin core developer now.
Do you trust the RSK federation functionaries? Why? From a user standpoint what are the advantages or disadvantages one could draw from it?
This is the type question I like to answer. We can analyze this from two points of view: technical, operational and reputational. From the technical perspective RSK peg is probably one of the most secure multi-signature systems in existence in the ecosystem (I’m counting with all functionaries running the HSM 2.0, which still is not the case, but that will change soon). Each HSM2 functionary runs an isolated node connected to an HSM that follows the hashrate of the RSK blockchain. The HSM2 will not sign any peg-out transaction unless this is commanded by the RSK bridge smart-contract and has enough cumulative work so that cheating the HSM2 becomes too difficult if not impossible without hacking a mining pool.
All communications between functionaries is done through the RSK blockchain. There are no hidden messages between them and there is no subsystem that allows them to do it. It’s all transparent. The bridge smart-contract builds the peg-out transaction and won’t let any of them pick anything related to the transaction to sign. The whole transaction content is decided by RSK consensus.From the other points of view, there is still much work to do. Initially we sought that keeping the federation functionary names secret (known companies in the ecosystem) would be superior in terms of security (you can’t attack what you cannot easily find). In the case of a federation I think that this “obscurity” (in cryptographic parlance) has paid off well, but now we’re entering a new stage where other similar projects (such as Liquid) has published their functionary names and so I was told the that RSK federation will do the same. I hope that happens in the next months.
Do you think RSK can or will move away from a centralized federation in the future? I think I’ve heard Diego talk about this to a certain extent.
As I mentioned before, we will soon show to the RSK and Bitcoin community a proposal to migrate the RSK federation to a pseudo-drivechain where both the functionaries and the miners will need to attest the peg-out transaction by signing it. This will be a middle step before migrating again to a real drivechain, which requires a Bitcoin soft-fork, and therefore it could take several years to reach consensus on the final protocol.
What are you focusing your research in right now?
Several things at the same time. I do research for RSK/Ethereum, RSK Infrastructure Framework (RIF) and Bitcoin. I’m currently finalizing a new consensus protocol for proof-of-work that is called Nakamore which aims to replace Nakamoto consensus in Bitcoin. It’s simple but very ambitious. It has some superb properties for increased decentralization. I’m also working in a new drivechain proposal for RSK that I talked about in a previous response. My last publication was about Synchain, a new type of federated sidechain that provides fast peg-ins and peg-outs and prevents double-spend attacks on the peg. You can read more here: https://blog.rootstock.io/noticia/syncchain-synchronized-sidechains-for-improved-security-and-usability/
What reads do you recommend for someone who wants to enter Bitcoin research? I’m finishing my master’s in Computer Science, doing my thesis in game theory. I’ve read Satoshi’s paper, the Lightning Network, most of the RSK blog, Ethereum’s yellow paper and some more.
This same question was asked before… YOU HAVE TO READ EVERYTHING! There are new cryptocurrency-related protocols every day. You have to read them all. Everything related to SNARKs, everything related to PBFT and other forms of consensus, everything related to scalability. Everything related to digital signatures, batch verification and multi-party protocols. Everything related to distributed storage and proofs of replication. Everything related to security. You will suffer, but in a good way.
Please tell us more about Nakamore. Can you give a brief description then? What branch do you pick or not the one with the most cumulative difficulty?
Wait only a few weeks! I’m waiting for feedback from people I trust before I publish the idea
What is the story behind the patenting of ASICBoost?
It’s a long story and it put me in a very difficult situation. From the beginning we wanted the technology to be free, we were suspicious that ASIC manufacturers may use it covertly. Also I wondered what would happen if only one manufacturer was capable of creating an ASICBoost miner much faster than the others centralizing mining chip production even more. We took the decision to patent it to prevent that from happening. I still think it was the best choice with the limited information we had at that time. The story has the happiest possible end, and the one I always wanted: the patent is currently in a defensive patent license pool, so if you want to use the ASICBoost technology you have to put all the patents that go in the same product in the same open patent pool. Now nobody can use ASICBoost without contributing back to the community.
Where do you think ethereum stands as a platform? Is it with or vs rsk? I ask this because I am only invested in future price prediction.
First, I at this point believe in cooperation more than competition, I think platforms designers and developers should collaborate because, even if I’m a monetary maximalist, our ethos is the same: most of us want to build an open and censor-resistant decentralized financial system and we benefit much more from collaboration than from aggression. I want the new financial system to be on top of Bitcoin, because I think other attempts have a much higher chance of failure. Having said that, I don’t think all platforms are the same and each platform has its own risk/stability profile.
For example, Ethereum 2.0 is a risky and ambitious project. It’s not an evolution of Ethereum 1.0, but a complete rewrite. By doing everything from scratch, Ethereum developers were able to choose improved technical solutions for most components, helped by the lessons learned from past failures with Ethereum 1.0. Therefore I think that some of the components in Ethereum 2.0 will work great. That doesn’t mean everything will go smoothly, as risks abound in any migration, let alone a migration of such magnitude. No other project has done or plans to do such a migration. Because the Ethereum 2.0 project is taking several years, certain technologies picked for Ethereum 2.0 will be shown to be inferior to other solutions. For example, Avalanche consensus may show to be much stronger or even practically tested that Eth2.0 proof-of-stake before Ethereum 2.0 is launched. I think that there is even a small chance Ethereum 2.0 is cancelled and Ethereum 3.0 development starts because better technology is created constantly. Look at the advances of zkSNARKs in the last months!
RSK community, on the other hand, has a more conservative plan to use 2nd layer scalability solutions already proven to work. I share the opinions of many members of the RSK community about this. First, I firmly believe in proof-of-work as the basis of consensus security and decentralization. Other security protections, such as stake-based checkpoints, can be built on top of it. I believe that onchain layer optimizations together with second layer scaling and privacy solutions can solve the real world financial needs for tens of millions of users. The “world computer” idea of Ethereum 1.0 does not go well with decentralization. I believe in building a solid stack based on 2nd layer solutions, going from execution scalability as in Arbitrum to decentralized storage as in RIF Storage. That’s what I think RIF is important. However, the RSK community is preparing RSK to avoid the problems that Ethereum had in the past, especially about state bloat. Some of the RSKIPs that are being discussed or have already been implemented are key to reduce the resource consumed by nodes, such as the Unitrie, parallel transaction execution, storage rent, light clients, state-pruned but fully validating nodes, LTCP transaction compression, signature batching, Ephemeral data, etc.
We have a toolbox of scaling proposals that, if accepted by the RSK community, can take RSK to the next level without putting immutability and security at risk. There is a trade-off between being too innovative and securing people’s funds. And if we want to go further, then the recent Syncchain paper we publish shows how to build shards on top of RSK without resetting the blockchain. IOVlabs through its platforms RSK Smart Contract, RSK Infrastructure Framework (RIF) and Taringa! set the foundations in order to push forward a fairer and more inclusive financial system. I think the RSK community shares that vision and takes it quite seriously.
Do you see RSK gaining traction and do you feel it’s already become a true part of BTC´s ecosystem ? And do you feel supported by other parts of the bitcoin community, like Square, the different Lightning teams or Core?
I will give you my personal opinion, which involves personal interactions with other Bitcoiners. RSK idea and initial codebase originated in LATAM, not in Silicon Valley. That meant we had to break through a cultural barrier. That may have delayed us in reaching more Bitcoiners. But the main obstacle wasn’t this, but the fact that we decided to use the EVM as our virtual machine to run smart-contracts, even if I had a previous fully-built VM from my QixCoin project.
Using the Ethereum VM was an excellent strategic decision, so that we could port Ethereum dApps to RSK and share knowledge between both communities. But early Bitcoiners were not very fond of the Ethereum project so they were doubtful to support RSK. Also, as codebases between Bitcoin and RSK are completely different, there is few direct involvement of Bitcoin Core developers in RSK. Lighting Network is also a different stack from the RIF Lumino Network.
But that’s the past. Nowadays the benefits of DeFi for Bitcoin are quite clear. No Bitcoiner can deny that there is a huge untapped market, and that centralized lending solutions are dangerous: they can replicate the same problems of the old traditional financial system, with data leakage and government interventions.
And my perception now is that RSK will become the de-facto DeFi platform for Bitcoiners.
Would you go back in time and post about your brainfart idea “dagcoin” again now that you know that it has led to the abomination that is IOTA? https://bitcointalk.org/index.php?topic=117763
Broken custom trinary hash function. Totally centralized. One month inactive. That is not the original dagcoin idea.
What happens if the US government orders a shutdown? Is selective censorship possibile? Thanks.
I suppose you’re asking for the shutdown of the federation or selective censorship of peg-out transactions. Let’s first analyze censorship: if a federation functionary attempts to censor a transaction, the others functionaries will execute the peg-out transaction, so the censorship will fail. If all of them attempt to censor a transaction, then the functionaries can no longer continue performing some other peg-outs, as peg-outs are linked with UTXOs, and functionaries cannot choose the UTXOs in order to break one peg-out from a chain. So this leads to a complete halt of the federation, and that’s why selective censorship is not possible.
Regarding a complete shutdown of the federation by a single government, it would be very difficult to do as the functionaries are geographically distributed over the world. Anyway, I think a shutdown attempt would only make RSK stronger and more resilient to subsequent attacks, as the RSK federation would rapidly expand and decentralize itself into a hundred individual users around the world, each running an HSM2 device (an SPV enclaves that follow proof-of-work) and full nodes over Tor. Peg-in transactions can be fully decentralized because it only requires communicating with the bridge smart contract.