docs: registration of phase 1 stake #417
Conversation
| 1. Create `MsgCreateBTCDelegation` with the inclusion proof filled as defined | ||
| above and submit `MsgCreateBTCDelegation` to the Babylon network's btcstaking | ||
| module. If all verifications pass, your delegation becomes active on the Babylon | ||
| chain immediately since you've already proven your BTC is locked on Bitcoin. |
There was a problem hiding this comment.
That's not the case, they need to wait for covenants to submit their signatures.
| This specific message registers a BTC delegation with the Babylon chain along | ||
| with all of the necessary data required to create/register a stake. | ||
|
|
||
| #### 3.2.1. Protobuf definition |
There was a problem hiding this comment.
No need to have subsections here as we have only one.
| In the **Bitcoin-first flow**, the staker locks their BTC on the Bitcoin blockchain | ||
| first before interacting with Babylon. This flow is particularly suited for | ||
| stakers who already have their stakes on Bitcoin, such as those who have | ||
| participated in Babylon's Phase-1 and would like to transition their stake |
There was a problem hiding this comment.
| participated in Babylon's Phase-1 and would like to transition their stake | |
| participated in Babylon's Phase-1 and would like to register their stake |
| The signature for the `slashing_tx`, which is crucial for authorizing the | ||
| transaction in the event of a protocol violation, such as double-signing. | ||
| The signature, generated with the private key for the staker's secp256k1 | ||
| public key (`btc_pk`), should be compatible with ECDSA or Schnorr (BIP340). |
There was a problem hiding this comment.
It needs to be a Schnorr (BIP340) signature only.
| The timelock period for unbonding, measured in Bitcoin blocks, indicating | ||
| how long funds remain locked. It should be an unsigned integer (uint32) and | ||
| ensure that any `unbonding_time` you choose is more than that specified | ||
| by the `min_unbonding_time_blocks` parameter in the genesis file. |
There was a problem hiding this comment.
It's not in the genesis file but in the Babylon parameters. Do you think that it makes to have a 3.2. Babylon chain BTC Staking parameters section which explains the parameters of the x/btcstaking module, what they mean, and how they can be retrieved? As a lot of this data relates to the Babylon parameters.
| staker to unlock their funds by obtaining necessary signatures and broadcasting | ||
| the transaction to the Bitcoin network. | ||
| Details on what constitutes a valid unbonding transaction can be found | ||
| [here](./staking-script.md#unbonding-transaction). Once confirmed, the staker |
There was a problem hiding this comment.
"Once confirmed" is not true. Once the unbonding timelock expires the user can withdraw
| * Using our [TypeScript BTC staking library](https://github.com/babylonlabs-io/btc-staking-ts) | ||
| * Implementing the transaction generation themselves using the | ||
| [staking script specification](./staking-script.md) as a reference. | ||
| * `unbonding_value`: |
There was a problem hiding this comment.
Not sure I understand this parameter. I guess it refers to the unbonding fee, as I suppose that the staker can't set it to anything they want.
| * `unbonding_slashing_tx`: | ||
| The unbonding slashing transaction in hex format. This transaction spends the | ||
| unbonding transaction in cases of protocol violations such as double-signing. | ||
| To genertate or obtain the slashing transaction, you can use the libraries |
There was a problem hiding this comment.
We should not that this is a schnorr signature in hex format, like with the delegator_slashing_sig.
No description provided.