Concern Re: RSKIP 201

[YagoBit]

I recently became aware of this proposal as part of the Iris hardfork. I see that it has already been added to main. However, it does not seem that there was much opportunity for public review and comment.

This is a very significant change to the security assumptions of the core asset of the entire ecosystem. I would like to request that this issue be reopened to allow for further review and debate.

[YagoBit]

Two weeks ago I opened this issue - I would think an extremely important issue, that goes to the very heart of the RSK system - and it still has not be addresses or commented on. I would like to ask that this issue receive the attention it deserves please. The RSK system is extremely limited by the current peg, and increasing centralisation is not a step forward, it is a step backwards.

I think we should consider opening up the RBTC peg to other methods of deposit.

[SergioDemianLerner]

Hi YagoBit. The inclusion of the emergency multisignature was discussed with the community in several opportunities and accepted in Q1 2020. I believe that you were part of some of those discussions. We analyzed all risks related with the Powpeg and the risk that was highly scored was the risk that the PowHSMs get bricked by a firmware error, even more than the risk of a pegnatory collusion to block the peg. In that opportunity it was decided that an emergency multisignature with a exaggeratedly long time-lock was the solution, so that in case of a full Powpeg censorship or malfunction there was a chance to recover the funds. Keep in mind that in the same community discussion it was decided that making encrypted backups of the private keys (as the Liquid federation does) implied a HIGHER centralization risk that the emergency multisig.

Therefore it was accepted by the community that the Powpeg and the emergency multisig proposals would be applied together, or none of them would be applied.

The RSKIP201 itself was finalized later, only because the technical description of how the multisig script is built is orthogonal to the decision to use it, which was made almost a year ago when the Powpeg was designed.

Sometime later you proposed an alternative system where the network was able to reimburse the owners of bitcoins in RSK by creating time-locked Bitcoin transactions at periodic checkpoints, but that proposal could not be efficiently achieved in RSK with the scripting limitations of Bitcoin, and it was not proposed to the community.

The code of RSKIP201 has already been implemented and Iris is in the final stages of testing. However, if you have a better proposal to mitigate the risks that I mentioned, then open a discussion thread in the research forum, you can still convince the community to change plans, but that will delay Iris, so your arguments should be really strong.

[SergioDemianLerner]

The reason why your open issue was not addressed before is that we didn't see it. The RSKIP reviewers have lots of pending reviews. We're using the research forum for RSKIP discussions: https://research.rsk.dev/

[YagoBit]

Thanks Sergio. Your concerns are well understood. The potential for total loss of funds is a serious concern that must indeed be addressed. It is because this matter is so crucial that I think we must examine multiple other options. As you mention, I have proposed at least one alternative, TimeShot. I do not think TimeShot is currently our best path forward (although it may be part of the mix) and have been working on other alternatives.

Regarding the community discussion and decision is Q1 2020, I did indeed participate in discussion with you and others. However, I do not believe I was aware of any open, public, community forum in which it was discussed. Could you please point me to those discussions? I think it would be very valuable to consider them.

I have long said that one of the reasons I chose to build on Rootstock and not on Liquid was my discomfort with the Liquid peg, and I would not want to see that system replicated on Rootstock.