docs: BTC eligibility Document - Staking TX #577
Conversation
| - **Merkle Root**: Inside `Q`, commits to spending rules (timelock, | ||
| unbonding, slashing) | ||
| - **Internal Public Key**: Used to derive `Q` | ||
| 3. **`OP_RETURN` Output**: Contains Babylon metadata (tag, `staker_pk`, |
There was a problem hiding this comment.
I wonder wheter we need to focus on op_return at all here. It was only necessary in phase-1 and it won't used in phase-2 at all.
|
|
||
| ### Sending a TX | ||
| A staking transaction is different to the other transactions. It creates a UTXO |
There was a problem hiding this comment.
I think the critical piece of infromation there here is that staking transactions must contain exactly one UTXO which commits to Babylon designed scripts.
All other UTXOs are ignored by Babylon
| 1. **Inputs**: References previous UTXOs, provides BTC | ||
| 2. **Taproot Output (`staking_output`)**: The vault that locks BTC. Commits | ||
| to a script tree composed of the three scripts (timelock, unbondng and slashing.) | ||
| - **Taproot Public Key**: Created in the Taproot output, commits to `m` |
There was a problem hiding this comment.
Imo it would be clearer if this whole info:
Taproot Public Key: Created in the Taproot output, commits to m (Merkle root)
Merkle Root: Inside Q, commits to spending rules (timelock, unbonding, slashing)
Internal Public Key: Used to derive Q
was presented in separate sub-section similiarty to what is done in current impl doc:
Taproot outputs are outputs whose locking script is an elliptic curve point Q created as follows:
Q = P + hash(P||m)G
where:
P is the internal public key
m is the root of a Merkle tree whose leaves consist of a version number and a script
For Bitcoin Staking transactions, the internal public key is chosen as:
P = lift_x(0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)
| ``` | ||
|
|
||
| <!-- should we still include serialisation format for OP_RETURN data? --> |
There was a problem hiding this comment.
I think I would leave out the op_return at all from this docs as it is inteneded for phase-2 and onwards.
|
|
||
| ### Sending a TX | ||
| The following are **not yet** needed. |
There was a problem hiding this comment.
I think I would delete this list. We do not know what inputs are used to create the staking transaction. It is possible the input to the staking transaction is previous staking output, then user would need to have those 😅
|
|
||
| ```go | ||
| func BuildV0IdentifiableStakingOutputsAndTx( |
There was a problem hiding this comment.
I would use functions without the op_return i.e
func BuildStakingInfo(
stakerKey *btcec.PublicKey,
fpKeys []*btcec.PublicKey,
covenantKeys []*btcec.PublicKey,
covenantQuorum uint32,
stakingTime uint16,
stakingAmount btcutil.Amount,
net *chaincfg.Params,
) (*StakingInfo, error) {
Two questions on this:
OP_RETURNdata?