feat: new command phase1 stake to BTC delegation

[RafilxTenfen]

• add new command to create BTC delegation from BTC staking transaction stakercli daemon stake-from-phase1
• refractory of e2e test manager
• split e2e test files and test manager funcs

[RafilxTenfen]

not sure why this updated, just run proto-gen

[RafilxTenfen]

not fully convinced it is a good idea to retrieve the consumer delegation tx hash this way

[RafilxTenfen]

One last thing is that I noticed some flankiness in the integration test
for the same code:

• Run fail https://github.com/babylonlabs-io/btc-staker/actions/runs/12022509602/job/33514852376?pr=90
• Run Pass https://github.com/babylonlabs-io/btc-staker/actions/runs/12022509602/job/33515185226?pr=90

The failed one indicates that some datagen function from babylon to insert the covenant sig is not behaving as expected

2024-11-26T02:20:08.9985192Z     manager.go:1159: 
2024-11-26T02:20:08.9986075Z         	Error Trace:	/home/runner/work/btc-staker/btc-staker/itest/manager.go:1159
2024-11-26T02:20:08.9987678Z         	            				/home/runner/work/btc-staker/btc-staker/itest/e2e_test.go:977
2024-11-26T02:20:08.9988437Z         	Error:      	Received unexpected error:
2024-11-26T02:20:08.9990075Z         	            	invalid tx: txToSign inpunt index must point to output with provided script
2024-11-26T02:20:08.9990856Z         	Test:       	TestStakeFromPhase1
2024-11-26T02:20:08.9991493Z time="2024-11-26T02:17:42Z" level=info msg="Received shutdown signal. Stopping..."

The check that fails

	if txToSign.TxIn[0].PreviousOutPoint.Index != fundingOutputIdx {
		return fmt.Errorf("txToSign inpunt index must point to output with provided script")
	}

txToSign is the BTC staking tx, could it be due to the way that I create the staking tx with Phase1 commands?

[KonradStaniec]

tbh in this handler I would

• return error if transaction is not confirmed on BTC already (less state to hold on to)
• do the same thing that function handlePreApprovalCmd does but with inclusion proof . Maybe you can even reuse this function somehow. Then this new staking info will be saved in db only after send to Babylon succeeds.

This way we will avoid this waiting go rutine:

			go func() {
				// eventually tx is send to babylon and notifies the cmd request
				storedTx, err := app.waitForTrackedTransactionState(stkTxHash, proto.TransactionState_SENT_TO_BABYLON, time.Second, 20)

and we won't need to store delegation transaction txhash in db as it could be returned immediately from handlePreApprovalCmd function

[RafilxTenfen]

You are correct, it became much simpler! Thanks
One thing is that I would still keep the BTC delegation tx hash in the TrackedTransaction I believe it helps to track the transaction in the other side

Let me know if you want to be removed

[KonradStaniec]

One thing is that I would still keep the BTC delegation tx hash in the TrackedTransaction I believe it helps to track the transaction in the other side

hmm makes sense. Lets leave it then 👍

[KonradStaniec]

One last thing is that I noticed some flankiness in the integration test
for the same code:

Run fail https://github.com/babylonlabs-io/btc-staker/actions/runs/12022509602/job/33514852376?pr=90
Run Pass https://github.com/babylonlabs-io/btc-staker/actions/runs/12022509602/job/33515185226?pr=90
The failed one indicates that some datagen function from babylon to insert the covenant sig is not behaving as expected

Ahh I see, one of the test functions assumess that staking output index is zero:

func GenCovenantAdaptorSigs(
	covenantSKs []*btcec.PrivateKey,
	fpPKs []*btcec.PublicKey,
	fundingTx *wire.MsgTx,
	pkScriptPath []byte,
	slashingTx *bstypes.BTCSlashingTx,
) ([]*bstypes.CovenantAdaptorSignatures, error) {
	covenantSigs := []*bstypes.CovenantAdaptorSignatures{}
	for _, covenantSK := range covenantSKs {
		covMemberSigs := &bstypes.CovenantAdaptorSignatures{
			CovPk:       bbn.NewBIP340PubKeyFromBTCPK(covenantSK.PubKey()),
			AdaptorSigs: [][]byte{},
		}
		for _, fpPK := range fpPKs {
			encKey, err := asig.NewEncryptionKeyFromBTCPK(fpPK)
			if err != nil {
				return nil, err
			}
			covenantSig, err := slashingTx.EncSign(fundingTx, 0, pkScriptPath, covenantSK, encKey)
			if err != nil {
				return nil, err
			}
			covMemberSigs.AdaptorSigs = append(covMemberSigs.AdaptorSigs, covenantSig.MustMarshal())
		}
		covenantSigs = append(covenantSigs, covMemberSigs)
	}

	return covenantSigs, nil
}

but in test you create staking tx by:

	resFundRawStkTx, err := rpcBtc.FundRawTransaction(&tx, btcjson.FundRawTransactionOpts{
		FeeRate: btcjson.Float64(0.02),
	}, btcjson.Bool(false))

and FundRawTransaction by default does not make promises that your staking output will be at 0 index. So it can add change output at 0 position and staking output at index 1.

Simple fix is to set ChangePosition in FundRawTransactionOpts to 1 ,this way your staking output will always be at position 0 and change output at position 1 (though imo ideally functions in test would not make such assumptions 😅

[KonradStaniec]

Looks good 👍 thanks for tackling it !

Only few cleanup comments

[KonradStaniec]

I wodner whether this param is necessary i.e we have staking tx hash, we can retrieve staking transaction from the btc chain and check its height and based on that chose the param.

Non-blocking comment it can be tackled as future improvement imo.

[RafilxTenfen]

good point

[RafilxTenfen]

I had modified to get the Block Height from the tx hash in the CLI command, but that also added one more call to service, it was done this way to avoid sending the whole global params to the service app