This litepaper contains the key components towards unlocking 21M Bitcoin to secure the Proof-of-Stake Economy.
In conjunction, we’re excited to launch the Babylon Forum. This forum is intended to host conversations around three main topics:
Babylon protocol development: Discuss the core protocols (timestamping, data availability, staking), including the user experience, implementation of conditions, and how to participate.
Project development: Discover projects building on BabylonChain, or learn how to integrate Babylon Protocols into other projects.
New R&D: Research and ideas for new updates on Babylon’s protocols, including MEV, rollup sequencing, bridging, oracle, and other solutions. All ideas and contributions are welcome.
In conclusion, Bitcoin’s immense market capitalization, coupled with its potential, has been underutilized due to constraints in scalability, latency, and programmability. Our innovative approach eliminates the need for bridging Bitcoin to other chains, instead allowing Bitcoin to stake and bolster the security of PoS chains directly.
Recent developments like Ordinals have sparked a resurgence in Bitcoin’s functionality, and we’re confident that Bitcoin staking, as detailed in our LitePaper, will further ignite this momentum, inspiring the exploration of other trustless uses for Bitcoin.
Join us as we unpack the many possibilities in our Community Forum
Hi, it’s really interesting. However, it seems that there are still many parts not disclosed in the litepaper, so I would like to ask about how your Staking contracts are specifically built.
From what I understand, it appears to be a version of the CTV Vault, but I am unclear about how you implement slashing. Could you please share more details?
Additionally, is it true that only in the case of conflicting signatures on 2 conflicting blocks will there be a slash, while in all other cases, there won’t be?
Also, how does your design change if BIP 119 is not yet available on the Bitcoin mainnet?
What we want to achieve is that, once the secret key is leaked, it can be uses to spend the staked bitcoin, but the only allowed spending destination is a predefined burn address. The simplist way to achieve this is through BIP-119 (covenant/CTV). But it can be emulated in other ways.
Here is an example:
in the spending condition of the staking tx, besides the public EOTS key (whose secret key is leakable), add a jury public key.
construct a slashing tx that spends the above UTXO to a burn address. For this slashing tx to work, two signatures are needed, the secret key and the jury private key. We then ask the jury to pre-sign this slahsing tx.
This way, the only way to spend the staked bitcoin once you have the secret key, is to further sign the slashing tx presigned by the jury. The resulted fully signed tx will send the btc to the burn address. As long as the jury does not sign malicious slashing txs where the bitcoin is sent to other addresses, it is guaranteed that the staked bitcoin is burned if the secret key is leaked.
In the example, “Alice has 1 bitcoin and she wants to stake it on a PoS chain”. If we then follow “the unhappy path” where Alice “commits a safety offense to the PoS chain” the conclusion is that “her bitcoin got burned.”
This begs the question if you really intend to burn 100% of the stake, or whether it is just a simplification in aid of the litepaper’s readability?
The proposal to emulate a covenant by having a jury pre-sign the slashing transaction is intriguing. However, this introduces a trust assumption: the jury must not steal the staked BTC for themselves. One way to mitigate this trust assumption is by employing a multi-signature jury. The larger and more stringent the multi-sig setup, the less onerous the trust assumption becomes.
Jury Selection and Validator Participation
The question of who elects the jury is crucial. One possibility is to have the validator set of the PoS chain participate in the multi-sig jury. This could potentially align incentives and make the system more secure, but it also raises questions about the election and rotation of jury members. Selecting a fixed set of trusted entities doesn’t seem helpful, except in so far as to enable building out the rest of the system and hope for the best on a covenant OP_CODE making its way into bitcoin.
As for the type of signature scheme required, both a threshold signature scheme and a TapScript multi-sig could be viable options, but each have limitations. What is the current thinking on the best approach here and the trade-offs involved?
Efficiency Concerns in Bonding Process
The size and structure of the jury have direct implications for the efficiency of the bonding process. Here are some key considerations:
Coordination Challenges with a Large Jury: A large jury inherently complicates the coordination required for the pre-signing process. The more members involved, the more cumbersome it becomes to reach a consensus for signing a transaction, thereby slowing down the entire protocol.
Stricter Multi-Sig Thresholds: A stricter multi-sig threshold not only makes coordination more challenging but also reduces the system’s tolerance for offline behaviour from jury members. If a significant portion of the jury is offline or unresponsive, reaching the required threshold for transaction approval becomes difficult.
Scalability of Signature Generation: Validators may already be tasked with generating multiple signatures within a given timeframe. Adding the responsibility of participating in a multi-sig jury could strain the system, especially if a threshold signature scheme is chosen, which could be computationally intensive.
Incentive Structures and Risks
In a ‘full validator set jury,’ what would be the incentives for collusion to steal the locked BTC? This is a critical question. If the rewards for honest validation outweigh the potential gains from stealing the staked BTC, then the system is likely secure. However, this balance could be delicate and subject to staking inflows and outflows.
In summary, while the jury system is a way to emulate covenants, it introduces several complexities and trust assumptions that need to be carefully considered. I’m looking forward to hearing more about how these challenges could be addressed and would be happy to help think through solutions.
It seems like CTV covenants, APOAS covenants, and INSPECT_X covenants (as on Liquid) are all good solutions to remove the requirement for a jury. I think BTC staking is a very interesting and novel application to add to the discussion of covenants in bitcoin.
Hi Light, yes it can be OP_RETURN, so that the bitcoin is literally burned. The protocol is also flexible enough, such that it can also specify a community controlled BTC address where the “burned” bitcoins go to.
Hi Swambo, thanks a lot for your interest and detailed proposal!
You are concerned about jury stealing stakes. This depends on whether you assume jury collude with the staker or not.
If you assume collusion, then yes, a multi-sig jury will help and your analysis and proposal is very promising.
But if there is not collusion, which is more likely to be the case (as you mentioned, the jury can be the PoS validtors), then stealing is not possible. This is becuse the staker already specifies the burn destination in the slashing tx. By pre-signing this tx, jury can at most contribute to the burning of the stake, but not transfer it to another address.
Thanks for your response. I’m not convinced by the rationale, but I’m also trying to guess at many of the design choices that have been made and have a partial understanding of the system, so please bare with me.
Risks Associated with a Single-Sig Jury
Collusion between the jury and the staker is not necessary - the point of the extractable one-time signatures is that the staker’s signature would be leaked to the jury in the event the funds should be slashed. In the event that the staker’s key is leaked, the jury would technically have the ability to create a new valid signature.
Covenant vs. Pre-Signed Transaction
In a system with a Bitcoin covenant, the ‘committed slashing tx’ would be the only possible spending path. However, without a covenant, the ‘pre-signed slashing tx’ is not the only possible spending path. The jury could, in theory, create and authorize a new transaction that spends the utxo that was intended for the slashing tx. This is a crucial distinction and forms the basis of my motivation for a multi-sig jury.
The Reliability of an N-of-N Multi-Sig Jury
For the sake of argument, let’s consider an N-of-N multi-sig jury. In this setup, the assumption would be that no alternative spending path could be created as long as at least one of the N jury members remains honest. With a large and diversely motivated jury, this could be a highly reliable assumption.
I would be hesitant to stake any BTC if I had to rely on a single-sig jury. Even though this occurrence would only happen if I misbehave and double-sign a block, accidents are known to happen, and it’s a point of weakness that a malicious jury could target.
Ah I see. OK the actual implementation will look more like the following:
The slashing condition will require 3 sets of signatures: (staker_normal_sig, EOTS_sig, jury_sig).
Here the staker_normal_sig can be an arbitrary address he staker create. This way, even if the jury extracts the EOTS, it cannot transfer it.
Totally agree with you that the jury should be a multi-sig. My initial simplified answer is for people who are not expert in this field, which does not apply to you. You did a great guess with very limited information!
How large should the jury be, whether it should be N-of-N or M-of-N, whether it should pre-sign or post-sign, are design choices that will achieve different tradeoffs between liveness and slashability. But in any case, the bitcoin is safe as long as the staker does not act maliciously, and this is the most important property we achieve.