Spark docs#676
Conversation
# Conflicts: # api-reference/activities/spark-prepare-lightning-receive.mdx # docs.json # features/networks/spark-flows.mdx
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
omkarshanbhag
left a comment
There was a problem hiding this comment.
Gave this a first pass!! Looking good, thanks for the cleanup here.
Main comments are on static deposit security caveats! Will give another second pass tomorrow.
| --- | ||
|
|
||
| [Spark](https://www.spark.money/) is a Bitcoin Layer 2 network that uses an identity key system for onchain addressing. Turnkey supports Spark address derivation and signing via plain [BIP-340 Schnorr](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) signatures. | ||
| [Spark](https://www.spark.money/) is a Bitcoin Layer 2 that uses FROST threshold signing across a collective of operators to enable fast, low-fee transfers and Lightning payments without giving up self-custody of the underlying BTC. Turnkey provides enclave-based key management for Spark: your identity key, leaf keys, deposit keys, and Lightning preimages are generated and used inside the Turnkey enclave, and never leave it. |
There was a problem hiding this comment.
@andrewkmin We should caveat here that keys WILL leave the enclave if the static deposit flow is used.
| ### Static deposits export a key from the enclave | ||
|
|
||
| The returned signature will always have `V = "00"` since Schnorr signatures do not use a recovery ID. | ||
| Static deposit addresses are reusable: one address can receive many deposits, each creating a separate Spark leaf. To make that work, the SSP needs to process deposits while your wallet is offline, which means it needs co-signing capability on the static deposit key. This is the **only** Spark flow that uses [`EXPORT_WALLET_ACCOUNT`](/api-reference/activities/export-wallet-account) to take a raw private key out of the Turnkey enclave. |
There was a problem hiding this comment.
Couple things here! Since this is one of the main security concerns for us, and seeing export will probably lightly spook clients at the very least we should:
- Maybe call this out in a special "callout box" or whatever format markdown uses for special notes
- Reference this section by linking it in our caveat at the top of our page where we mention that no keys leave the enclave
- Have a further "reassuring" note that this is expected and say that this key having been exported is irrelevant after claiming static deposits (and then link to a section on how to claim static deposits)
There was a problem hiding this comment.
Maybe also we outline the "risk window" where an SSP + SO could collude and behave and point to spark docs here.
Follow up for #650