How RGB++ handles Bitcoin reorgs?

[phroi]

TLDR: even if Bitcoin reorgs, RGB++ has it covered. The Bitcoin inclusion block proof only appears in the witness of the RGB++ Nervos tx, so this particular information is not carried on in the next RGB++ tx of that particular cell.

Follows the original issue content:

Hello RBG++ folks, I would really like to thank you one by one, RBG++ and related projects changed overnight Nervos from an unknown chain to an over-hyped one, what a fantastic achievement, congratulations on your success! 🥳🎉🎉

Nowadays I hear about RBG++ literally everywhere and likely in the future I'll also build on top too, so I'd like to fully understand how RBG++ works in adverse conditions. The whitepaper has not a single mention of this, which got me kind of worried. Also we were talking about this in Nervos Dev chat, but so far we didn't receive a single reply from a RBG++ folk, which got me even more worried.

As per title, I'm wondering: How RGB++ handles Bitcoin reorgs?

As @abcfamily asked on Discord:

what happens if both the CKB and BTC transactions are confirmed and submitted but BTC undergoes a reorg and rollback the RGB++ block? How does CKB deal with BTC roll backs?

And I'd like to add: What happens if multiple chained RGB++ are rolled back? How RGB++ handles this event?

I'm not 100% sure how RBG++ assumes the BTC finality, depending on this RBG++ could be either:

1. Hacked into the wrong state (with a signed BTC tx never broadcasted on the BTC side)
2. Not recoverable in some (low probability) scenarios (with a reorg of one or multiple chained RGB++ txs)

RGB++ seems to follow option 2 as @Matt-RUN-CKB says:

finality comes from 6 block confirmations for a transaction's inclusion (checking the pow)

This mean that if RGB++ tries to re-broadcast a tx on the Bitcoin side, it will have a different inclusion block and PoW. Given the reorgs existence, this makes state mismatch between chains possible to create (with low probability, sure) and pretty difficult to recover from. Even more, if RGB++ were to going mainstream, this issue will become apparent pretty fast.

I thought a little about this problem and this is the only recovery mechanism that came to mind: assuming RGB++ is deployed by type, this recovery can happens in batches, by updating the RBG++ script on the Nervos side and hard-coding the cells to recover.

Then again, assuming RGB++ doesn't have a recovery mechanism seems unfair to all the hard-work poured into this project and the success it brought to Nervos.

Please, can you describe the recovery mechanism that you envisioned?

As usual I'm asking here since GitHub issues are SEO friendly and very likely in the future there will be other L1 developers wondering the same 😉

Love & Peace, Phroi

P.S.: By the way, what a curious name resemblance with CKB++, the first name I chose for iCKB!!

[Flouse]

Thank you for bringing up this important security consideration regarding the RGB++ protocol.

I hope A Deep Dive into RGB++: Security Analysis helps provide some context and clarity on the security analysis.

Let me know if you have any other questions.

[phroi]

Hey @Flouse & @chesterchen2010, thank you for your super speedy reply!!

On Discord ABCFamily, @Matt-RUN-CKB and me were kind of worried about this situation and no-one linked us this Nervos Talk page. From the linked whitepaper I see that you acknowledge that this problem exist and you analyzed it, perfect! :+1:

Please, correct me if I'm wrong, your proposed solution is to use a new lock: BTC Time Lock. Pretty sure I didn't fully understand it, but using that lock a dev/user is able to specify a custom number of BTC block to wait for. Given the exponential decay of re-orgs compared to block numbers, even waiting a single block more can make a big difference in avoiding a re-org and so losing funds.

If you are so gentle to entertain my curiosity then, let me ask a couple questions:

1. What I am missing in my explanation of BTC Time Lock?

2. Is this the new default lock or a user/dev can choose it over the original one?

3. Let's say this re-org actually occurs and it's longer than the length handled by this lock, fund are still lost, correct or wrong?

4. At this point the probability of one of the RGB++ users losing funds while using RGB++ is pretty low, then again this probability increases dramatically the moment RGB++ becomes mainstream as the number of users and RGB++ txs explodes. Is there any additional recovery mechanism, for this unlikely but still realistic scenario?

Love & Peace, Phroi

[Flouse]

Please, correct me if I'm wrong, your proposed solution is to use a new lock: BTC Time Lock. Pretty sure I didn't fully understand it, but using that lock a dev/user is able to specify a custom number of BTC block to wait for. Given the exponential decay of re-orgs compared to block numbers, even waiting a single block more can make a big difference in avoiding a re-org and so losing funds.

1. What I am missing in my explanation of BTC Time Lock?

A: Yes, you are right. The MIN_BTC_TIME_LOCK_AFTER is set to 6. If a user/sender wants to enhance the security level of an rgbpp-leap transaction, he/she can increase BTCTimeLock.after, to require more BTC block confirmations before the rgbpp-asset can be accessed.

2. Is this the new default lock or a user/dev can choose it over the original one?

A: When unlocking a RGBPP_lock, all output cells that have a non-null type must use one of the following locks:

• RGBPP_lock
• BTC_TIME_lock, which requires: lockargs.after ≥ 6 ; lockargs.new_bitcoin_tx == btc_tx.

See also: RGBPP_Lock Unlock Logic

3. Let's say this re-org actually occurs and it's longer than the length handled by this lock, fund are still lost, correct or wrong?
4. At this point the probability of one of the RGB++ users losing funds while using RGB++ is pretty low, then again this probability increases dramatically the moment RGB++ becomes mainstream as the number of users and RGB++ txs explodes.

A: This situation is similar to Bitcoin's security mechanisms, where a transaction is considered secure after a certain number of confirmations. Both the BTC Time Lock and Bitcoin's confirmation security rely on the assumption that a transaction remains valid as long as it is part of the longest chain.

When using Bitcoin, you indeed face similar challenges regarding transaction finality and the risk of reorganization.

Is there any additional recovery mechanism, for this unlikely but still realistic scenario?

Higher Certainty through More BTC Block Confirmations

To achieve higher certainty that a transaction is secure and irreversible, Bitcoin users are encouraged to wait for more block confirmations, typically ranging from 3 to 6 blocks. Each additional confirmation evidently reduces the risk of a transaction being reversed due to a blockchain reorganization. It relies on the consensus mechanism of Proof-of-Work (PoW).

Users can achieve higher certainty by waiting for more confirmations, a.k.a increasing the BTCTimeLock.after value in the RGB++ protocol.

[Flouse]

By the way, when deciding on the appropriate level of asset protection, users/dApps might consider the following factors:

• Transaction Value: Higher-value transactions may warrant longer waiting periods for confirmations or increased time locks (BTCTimeLock.after) to ensure greater security.
• Risk Tolerance: Users/DApps should assess their individual risk tolerance and choose a reasonable BTCTimeLock.after that matches with their comfort level regarding potential losses.

By making informed decisions based on these considerations, users can enhance the security of their transactions in both Bitcoin and RGB++.

[phroi]

What I take from our discussion is:

• The risk of losing funds while using RBG++ is real, but can be easily minimized as much as needed (if users are aware and understand the risks involved, which doesn't seem to be the case at the moment).
• No additional recovery exists at the moment.

Sounds like a Russian roulette, where you can choose which gun to use. Not that crypto security in general is that much different tho.

Please, could you take in consideration the solution I proposed earlier for recovery?

Assuming RGB++ is deployed by type, this recovery can happens in batches, by updating the RBG++ script on the Nervos side and hard-coding the cells to recover.

Maybe a different script can be deployed for user who would prefer to be 100% sure not to lose their funds while using RGB++.

I understand that this entails social considerations and possibly loss of funds if the lock that control this script is compromised. Then again, also this risk can be minimized by increasing its multisig quorum.

Feel free to discuss internally this proposal and let me know.

Love & Peace, Phroi

[phroi]

P.S.: Another question, that maybe could give perspective on this issue, please would you be able to calculate how many Bitcoin confirmations are necessary to achieve the same probabilistic security level of commonly used signature locks?

(I can rephrase if necessary)

[Flouse]

P.S.: Another question, that maybe could give perspective on this issue, please would you be able to calculate how many Bitcoin confirmations are necessary to achieve the same probabilistic security level of commonly used signature locks?

(I can rephrase if necessary)

To address your question about calculating the number of Bitcoin confirmations necessary, see

1. https://learnmeabitcoin.com/technical/blockchain/chain-reorganisation/

   • Recent Chain Reorganisations
   • Reorganisation Frequency

2. Probability of replacing top x BTC blocks in the blockchain based on percentage mining power

How to achieve the same level of security in Nervos CKB?

See The Back-of-Envelope Calculation of the Transaction Confirmation Number

[Flouse]

Please, could you take in consideration the solution I proposed earlier for recovery?

Assuming RGB++ is deployed by type, this recovery can happens in batches, by updating the RBG++ script on the Nervos side and hard-coding the cells to recover.

Maybe a different script can be deployed for user who would prefer to be 100% sure not to lose their funds while using RGB++.

I understand that this entails social considerations and possibly loss of funds if the lock that control this script is compromised. Then again, also this risk can be minimized by increasing its multisig quorum. Feel free to discuss internally this proposal and let me know.

---

1. First, it's open to discuss any improvements about RGB++ protocol.

2. Second, as you mentioned, your proposed approach does come with its own set of social considerations and potential risks. The possibility of loss if the lock controlling this script is compromised is a significant concern. I agree that increasing the multisig quorum could help mitigate this risk, but we must also consider how to ensure transparency and accountability in the recovery process. I believe this topic warrants further discussion, especially regarding:

   • Governance: Who decides which assets can be recovered and how recovery is executed?

   • Security Measures: What additional safeguards can be implemented to protect the recovery script? This may require more development efforts and thorough code reviews to ensure robustness and security.

     I look forward to hearing more detailed thoughts on this proposal.

3. Third, simple solutions are preferable, IMO. Emphasizing simplicity in design and implementation is often the best approach, especially in complex systems like blockchain protocols. Why not just use PoW consensus's probabilistic finality to simplify the process without introducing additional security assumptions?

   Probabilistic Finality: PoW achieves probabilistic finality, meaning that the probability of a transaction being reversed decreases significantly as more blocks are mined to the chain. (See the probability calculation) This model does not require absolute consensus but rather relies on the statistical improbability of a long fork occurring.

   Again, increasing block confirmations for important assets, as discussed in deciding on the appropriate level of asset protection, is a straightforward and effective method to enhance security for Bitcoin and RGB++ protocol. By requiring more block confirmations, the risk of transaction reversals decreases significantly, providing users with greater confidence in the safety of their assets. This approach leverages the existing structure of the PoW blockchains without introducing additional complexities or security assumptions, making it a practical solution for safeguarding valuable transactions.

[phroi]

About my proposal, yeah, I would reply in the same way as the developer/organization who has to implement it, I understand well!!

To address your question about calculating the number of Bitcoin confirmations necessary, see

1. https://learnmeabitcoin.com/technical/blockchain/chain-reorganisation/

   • Recent Chain Reorganisations
   • Reorganisation Frequency

2. Probability of replacing top x BTC blocks in the blockchain based on percentage mining power

These links made me understand much better the issue, thanks!!

I got the picture. It's a dynamic problem that depends on the distribution of hashing power, involved players and incentives, which change over time.

In the last few years nobody had enough incentives and/or percentage hashing-power to re-org deeper than one block.

That said, black swan reorg events happened in bitcoin past and may possibly occur again in the future.

For now it feels like a safer Roussian roulette.

[phroi]

Thank you @Flouse for your kind replies and the time you invested in them!! 🙏

I pray others will find this issue as useful as I did.

Closing for now 🤗

Love & Peace, Phroi

[Flouse]

Thank you @phroi once again for raising this important security discussion. As you mentioned, it appears to be more SEO-friendly, which will likely help other RGB++ protocol developers or researchers.

We plan to organize A Deep Dive into RGB++: Security Analysis along with related FAQs in this repository to enhance the documentation.

[phroi]

Given the SEO of this issue, please, feel free to change the issue title to something more neutral. Your call!!

Transforming this info in documentation is the right thing to do. Also it would be nice to directly raise user awareness too. This whole process should have helped in this regard.

Also feel free to reply in Telegram Nervos Nation general channel, they asked my opinion and I replied with my understanding. Maybe you or other RGB++ folks may want to correct me or add some more information.

Love & Peace, Phroi

[phroi]

Just talked with Hanssen in the Nervos Discord dev-chat. I'd like to retract any comment on RGB++ being like a (safe) Russian Roulette as I now understand that even if Bitcoin reorgs, RGB++ is 100% safe (as far as I can tell)

The reason is technically pretty simple:

1. The Bitcoin inclusion block proof only appears in the witness of the RGB++ Nervos tx, so this particular information is not carried on in the next RGB++ tx of that particular cell. Basically this info disappears after that single use.
2. Nervos RGB++ lock script tracks in its args only the bitcoin UTXO.

In case of a Bitcoin re-org: sure the proof changes for 1, but it doesn't really matter because the RGB++ bitcoin tx will be re-broacasted and re-included, generating the very same RGB++ UTXO, needed by 2 to work.

All this was really interesting and educational.

Love & Peace, Phroi