There are key moments where the values and culture of a community are solidified. We are at one of those moments. RSK plan to propose a hardfork that impacts Sovryn funds. Sovryn, as the largest community on Rootstock, must decide how to proceed.
On October 4’th, the RSK PoWPeg stopped processing peg-out transactions. More information on the bug can be found here. By extraordinary coincidence, this was the same day that a different exploit was used to attack Sovryn. The attacker attempted to peg-out part of the funds (~10BTC), and due to the coincidence in timing, the funds have been stuck in PoWPeg ever since.
The upshot is that, currently, 10BTC of Sovryn’s funds are in the PoWPeg and the proposed hardfork will send them to the attacker. Therefore, Sovryn must decide if to support the hardfork or not.
Implications of Rejecting the Hardfork
If the community does not support the hardfork, several things could potentially happen, including:
RSK could choose to move forward with the hardfork without consensus, potentially causing the Rootstock network to fork.
RSK, or other parties, could pay miners to include non-standard transactions into Bitcoin blocks, and thus PoWPeg transactions would be processed anyway.
A different hardfork could be proposed so that the funds are not sent to the attacker and/or are returned to Sovryn.
What is at Stake?
Sovryn Funds - 10 BTC is not an insignificant amount of value for Sovryn. It is also not a critical loss.
Peg Liquidity - the longer the PoWPeg outage continues, the more risk to ecosystem liquidity and peg parity there is. Currently, FastBTC can plug the gap. With additional liquidity, FastBTC could plug the gap for longer still, but this is suboptimal.
Ecosystem Security - The ability to pause contracts and retrieve funds can provide a smart contract ecosystem with tools to combat malicious actors. An ecosystem that can provide security and safety assurances is required if we are to build a world on Bitcoin. However, censorship resistance and rules without rulers is at least as important. This is much bigger than Sovryn dapps - it speaks to the needs of a successful ecosystem.
PoWPeg “Reputation” - PowPeg is not a trustless Bitcoin peg. While we aspire to introduce a cryptographically trustless peg to Bitcoin, we are not there yet. However, this nuance is usually lost. People view PoWPeg as either “immutable” or “centralized”. The decision we make, may strengthen one or the other of these incorrect perceptions. It may also set a precedent. Should we treat PoWPeg as censorship resistant, even in ways that it is not? Should we take advantage of an improbable scenario to thwart an attack or would this create a precedent we do not want?
Sovryn Values - What this comes down to is Sovryn’s hierarchy of values. Lot’s of things are valuable; funds, security, censorship resistance, transparency, etc. The hard question is which values are we willing to sacrifice in the name of others?
Debate and a SIP
This is an important opportunity for Sovryn to explicitly have a debate about our values and to enshrine them in precedent. I hope we have a robust discussion. Due to the time sensitive nature of the matter at hand, I think we should conclude this debate with a SIP vote within a week.
Since Sovryn has the largest and most active community governance on Rootstock - I would like us to act as a platform for the entire Rootstock community to discuss this, and invite all to participate in the debate.
Thanks for laying all this out so clearly. This is a very interesting, very complex situation. I’ll offer some thoughts, not because I have perfect clarity about how to respond but to help clarify my own thinking. And to get the ball rolling for others to weigh in and bring further perspective.
A couple of questions first:
How much influence or voting power does the Sovryn community have in this decision? If we have very little, then maybe it’s not worth taking a position on this.
How likely is #3 (a different hardfork that returns funds to Sovryn), based on discussion with RSK? If that seems unlikely, then again it may not be worth taking a position in favor of it.
If we do have a lot of influence and RSK is vehemently opposed to #3 as a solution, then perhaps they could offer to reimburse Sovryn the 10 BTC so that there is no record of having appeared to change the rules after the fact.
In my understanding, there has been no pretense that this is a trustless peg. RSK has already admitted that it isn’t trustless by shutting down Powpeg-out in the face of a discovered issue. They will most likely vote in a hard fork that changes the rules. A hard fork that preserves Sovryn funds isn’t fundamentally different.
Also, this is different from rolling back the blockchain in an Ethereum-type move. The Powpeg is a federated system running on RSK that can be stopped by design. If I understand correctly, it was stopped by design because an incompatibility with the latest Bitcoin Core was discovered. Transfers ceased before the exploit transfer was completed and written to the blockchain. A change in the code must happen for any transfer going forward to be successful.
I respect the idea that “code is law” in Bitcoin and its dependents. But I think a sound argument can be made that the code in this case includes a path to emergency stops and forks in keeping with governance, and that creates a valid opportunity for Sovryn to have its funds recovered.
My inclination is that we support the hardfork and let the peg-out happen. The effects of rejecting the hardfork are unsure, as mentioned. Let’s not risk splintering the Rootstock community. Hardforks are for improving things, and resolving bugs, not blocking transactions. The idea that ‘control and power’ need to be wielded to protect and give safety assurances is an idea all-too familiar from the institutions that Sovryn tries to offer an alternative to, if you ask me.
I think that he highest priority must be to get the peg-out working again. I would support the easiest and fastest solution for that to happen. Sovryn seems to be getting traction and recent events have shown again that a system like Sovryn and RSK are very important. We must present a flawless system as soon as possible.
But we should examine if a different hard fork is possible and reasonable to get the stolen funds back.
I don’t think Sovryn would damage PoWPeg reputatuion by doing so. If reputation is lost, it is because of the bug that stopped it from working.
Let the RSK network do the changes it needs and end the transaction that took the 10rBTC, if nothing more Sovryn team should look into making sure all centralized exchanges know that those 10BTC will be stolen goods and advice mixers on the BTC side so that they stop thosovrye coins from moving.
We as Sovryn shouldn’t look into getting those funds back by reserving the transaction but by law enforcement and centralized parties stoping the transaction if it hits their wallets.
I pretty much agree 100% with this course of action. Save the 10 BC if possible…Vitalik did the same thing, and is still the master of his universe . …but if this is not possible, it is vest to eat the loss and ensure that the powpeg is up…functioning RSK is a must for the project
I think the main priority is to get the POWpeg back up and running and restore trust in rsk. This pause is really not a good look as we see many CEXs pausing user’s funds as well. The “greater good” choice would be to hard fork and move on as our main priority and any way of stopping funds if possible from leaving the system
I agree that getting the POWPeg back up and running is the first priority. Bitcoin’s Timechain value is rooted in its nearly uninterrupted 13 year uptime. Imo, taking the hit on the 10 BTC exploit shows that the Sovryn community cares more for the code-is-laws ethos and immutability, even if it is only enforced by social consensus at this point.
Conditional question: Does the exchequer cover the hack? Or are the funds lost to the individuals who have funds stuck? (I do not have funds stuck, but I feel this is relevant to the decision)
2022-10-24 14:14 UTC - Sovryn developers deploy a fix for the vulnerability and the Exchequer multisig triggers the contract logic update to implement the fix. All of the funds removed from the lending pool by the exploit transactions are returned. The returned funds come from the funds recovered, with the balance covered by the Sovryn treasury.
It makes sense for the Sovryn brand to not get involved with manipulating user transactions. 10 BTC as stated before is not critical. If it were 500 BTC and it meant the death of Sovryn not to recover the funds, I’d probably opine differently.
Thank you. I spent an hour-an-a-half reading and mapping this out. It also helped with understanding how the lending pool and Lend, Borrow, Margin Trade protocol interact. Good heads-up by Sovryn Users to notice the unusual trading activity, great detective work by the developers/contributor. Agree 100% to let the 10 RBTC go to get POWpeg back up asap.
I believe the btc recovery solution by manipulating the transactions should be the last solution on the option list.
Censorship is difficult subject. We all want to be free to do as we please and this works in a perfect world where everyone acts in their neighbours interest not his interest .
The hack proves that we live in a world where good and bad people live. Could we make a tool that censors only the bad people?
Who decides who the bad people are?
Would this tool be used for evil reasons - to censor and control?
My opinion is that censoring tools should be avoided. It is hard to make a censoring tool that cuts only one way, if not impossible.
In our case we know what happened, it was an exploit! Which meant that the code was not secure enough.
We can argue that the attacker was evil! We can also argue that the Sovryn coders were not on their toes and this particular exploit slipped through their fingers.
I believe that we should not complicate this matter a lot more that it currently is. We should treat those 10BTc as a bug bounty claim and get the pow peg working again asap.
Hi! I’m not part of Sovryn community (I wish I had time to) so I will refrain from giving my personal opinion here.
I just want you to have more information (hopefully objective) about the additional risks and costs of delaying the currently proposed no-censorship hard-fork (RSKIP 358).
Every Rootstock network upgrade requires time, community effort and money. The RSKIP 358 emergency hardfork that was proposed by Adrian took several weeks to analyze, to code, and to test. New testing environments were created specifically to make sure the type of bug that caused the peg to pause never happens again. Coinspect was hired and paid to audit the code. At least 7 people were involved in the fix (devs, QA, devops, researchers, communication, coordination, and mining pool admins). We had many meeting with mining pools to prepare migration of non-standard txs. I estimate that money/work spend on fixing this bug is probably ~4 BTC, without considering opportunity costs for not doing other important stuff. Proposing a different hard fork at this point would require months of discussions and probably spending ~3 BTC in coding, testing and security auditing. Since we are short of core devs, this means delaying other important node improvements. The community will be spending more to recover the funds than the funds recovered.
Also, if the Roostock community decides to delay the peg for at least one additional month, the Fast Pegs can ran out of liquidity which means that the 1:1 peg could break (in either direction!), which means having a floating rBTC value. This is very bad publicity and it could add a speculative side to the peg, and increase the politics surrounding the peg (currently it has none).
Finally I invite the Sovryn community to collaborate with the rskj node become Rootstock core devs. We need people to code and review the improvements to the rskj node.
(edit: I lowered the estimated costs as some people worked part-time)