You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue proposes a new feature to enhance the asset minting process. It introduces the option for a minter to generate the asset group witness by signing a PSBT using an external signer, independent of tapd. This will enable the minter to securely store the private asset group key in cold storage throughout the minting process.
Batch Minting Overview
At a high level, the current batch minting process involves the following steps:
The MintAsset RPC endpoint is called to add a new asset to a minting batch. This batch remains open across multiple calls to this endpoint.
The SealBatch RPC endpoint is invoked, triggering the tapgarden.ChainPlanter, which generates asset group witnesses where applicable. This step blocks the tapgarden.ChainPlanter instance until complete.
The FinalizeBatch RPC endpoint is called, initiating the tapgarden.ChainPlanter. If the batch has not already been sealed, it is sealed at this stage. A new tapgarden.BatchCaretaker state machine is then started, anchoring the Taproot artifacts to a Bitcoin transaction, which is subsequently broadcast.
If a batch has not been sealed using the SealBatch RPC endpoint then the FinalizeBatch RPC endpoint will call into the same batch sealing routine.
Minimal Solution
A minimal solution could take the following approach:
Extend the Seedling (asset minting request) to include a new flag when passed into the MintAsset RPC endpoint. This flag indicates that the asset group witness should be generated using the new external PSBT signing flow. This ensures that if the FinalizeBatch RPC endpoint is called prematurely, the default batch sealing process fails, avoiding unintended behavior.
Introduce a new RPC endpoint, QuerySealBatchPSBTs, which returns all PSBTs required for the minter to externally sign and generate asset group witnesses for each flagged seedling in the batch. This endpoint should send a new request type to tapgarden.ChainPlanter which will need to be refactored where relevant. The endpoint name seems appropriate, as "seal" appears to refer almost exclusively to asset witness creation based on the code.
The signed PSBTs are then submitted by the signer through the SealBatch RPC endpoint. The endpoint uses the newly generated group witnesses to seal the batch as usual.
It introduces the option for a minter to generate the asset group witness by signing a PSBT using an external signer, independent of tapd.
Isn't that already possible? In that the existence of SealBatch allows the caller to generate that custom witness.
Or is it that that route assumes they can make the virtual tx, and we want to give them a PSBT with that pre-populated along with whatever other supporting meta data?
Or is it that that route assumes they can make the virtual tx, and we want to give them a PSBT with that pre-populated along with whatever other supporting meta data?
@Roasbeef Yes, I believe we currently assume the user can generate their own asset group VM transaction. Our goal is to provide them with a pre-populated PSBT that they can sign and return to us.
This issue must be completed first: #1226
This issue proposes a new feature to enhance the asset minting process. It introduces the option for a minter to generate the asset group witness by signing a PSBT using an external signer, independent of tapd. This will enable the minter to securely store the private asset group key in cold storage throughout the minting process.
Batch Minting Overview
At a high level, the current batch minting process involves the following steps:
MintAsset
RPC endpoint is called to add a new asset to a minting batch. This batch remains open across multiple calls to this endpoint.SealBatch
RPC endpoint is invoked, triggering thetapgarden.ChainPlanter
, which generates asset group witnesses where applicable. This step blocks thetapgarden.ChainPlanter
instance until complete.FinalizeBatch
RPC endpoint is called, initiating thetapgarden.ChainPlanter
. If the batch has not already been sealed, it is sealed at this stage. A newtapgarden.BatchCaretaker
state machine is then started, anchoring the Taproot artifacts to a Bitcoin transaction, which is subsequently broadcast.If a batch has not been sealed using the
SealBatch
RPC endpoint then theFinalizeBatch
RPC endpoint will call into the same batch sealing routine.Minimal Solution
A minimal solution could take the following approach:
Extend the
Seedling
(asset minting request) to include a new flag when passed into theMintAsset
RPC endpoint. This flag indicates that the asset group witness should be generated using the new external PSBT signing flow. This ensures that if theFinalizeBatch
RPC endpoint is called prematurely, the default batch sealing process fails, avoiding unintended behavior.Introduce a new RPC endpoint,
QuerySealBatchPSBTs
, which returns all PSBTs required for the minter to externally sign and generate asset group witnesses for each flagged seedling in the batch. This endpoint should send a new request type totapgarden.ChainPlanter
which will need to be refactored where relevant. The endpoint name seems appropriate, as "seal" appears to refer almost exclusively to asset witness creation based on the code.The signed PSBTs are then submitted by the signer through the
SealBatch
RPC endpoint. The endpoint uses the newly generated group witnesses to seal the batch as usual.See also this LND signing gist: https://gist.github.com/guggero/569241aa9fec57e287101187bd28d1c5
The text was updated successfully, but these errors were encountered: