📅 Original date posted:2023-01-18
🗒️ Summary of this message: Three changes have been implemented based on suggestions from Greg Sanders and AJ Towns, improving the proposal for Bitcoin vaults. These changes include improved privacy and efficiency, the ability to manage remaining vault balances separately, and the introduction of a replacement parameter for recovery processes. The author plans to make minor updates to the paper and start writing a BIP draft.
📝 Original message:I've implemented three changes based on suggestions from Greg Sanders
and AJ Towns.
I've segmented the changes into commits that should be
reasonable to follow, even though I'll probably rearrange the commit
structure later on.
1. Greg's suggestion: OP_UNVAULT outputs can now live behind
scripthashes. This means that the lifecycle of a vault can live entirely
within, say, Taproot. In this case the only thing that would reveal
the operation of the vault would be the content of the witness stack
when triggering an unvault or recovering. So I think no real privacy
benefits over the previous scheme, but certainly some efficiency ones
since we're moving more content from the scriptPubKey into the witness.
Commit here:
https://github.com/bitcoin/bitcoin/pull/26857/commits/cd33d120c67cda7eb5c6bbfe3a1ea9fb6c5b93d1
2. AJ's suggestion: unvault trigger transactions can now have an extra
"revault" output that redeposits some balance to the same vault
scriptPubKey from which it came. This is nice because if the delay
period is long, you may want to manage a remaining vault balance
separately while the spent balance is pending an unvault.
Commit here:
https://github.com/bitcoin/bitcoin/pull/26857/commits/cf3764fb503bc17c4438d1322ecf780b9dc3ef30
3. AJ's suggestion: instead of specifying <recovery-spk-hash>, introduce
a replacement parameter: <recovery-params>. This contains the same
target recovery sPK hash as before, but the remaining bytes contain a
scriptPubKey that functions as authorization for the recovery process.
This allows users to optionally avoid the risk of "recovery replays" at
the expense of having to maintain a recovery key. Users can opt out of
this by passing OP_TRUE for the recovery sPK. I guess maybe I could even
support just omitting an sPK altogether for the legacy behavior.
Commit here:
https://github.com/bitcoin/bitcoin/pull/26857/commits/fdfd5e93f96856fbb41243441177a40ebbac6085
The suggestions were good ones, and I think they've improved the
proposal.
My next steps are to do minor updates to the paper and start writing a
BIP draft.
Thanks to achow for the valuable feedback, which I'm still mulling on.
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230118/a1c7719a/attachment.html>;
James O'Beirne [ARCHIVE] /
npub1dp…ymz3t
2023-06-07 23:18:25
in reply to nevent1q…g5dq
Author Public Key
npub1dpdfw74plzm03mzglkdegp3hqn6qs9yffqefa5kh98mru49nrg7szymz3tPublished at
2023-06-07 23:18:25Event JSON
{
"id": "fe9762c872e5039e5350710261f211a7b283ec56efc438ea5e5a88e3ba636e97",
"pubkey": "685a977aa1f8b6f8ec48fd9b94063704f408148948329ed2d729f63e54b31a3d",
"created_at": 1686179905,
"kind": 1,
"tags": [
[
"e",
"a84542afe0efb7efffac7c1bbcfb71ebcb322bb4dd5fb2586b4f66533f300f6e",
"",
"root"
],
[
"e",
"65e7a85e5d1c3fc82597a1d81eb9de2d737149438f4105c1ade4e3785435fdcd",
"",
"reply"
],
[
"p",
"3030ec2d70259fdd55ba8e063740c139c3daaa618f86e3fae34cebcb73c742ba"
]
],
"content": "📅 Original date posted:2023-01-18\n🗒️ Summary of this message: Three changes have been implemented based on suggestions from Greg Sanders and AJ Towns, improving the proposal for Bitcoin vaults. These changes include improved privacy and efficiency, the ability to manage remaining vault balances separately, and the introduction of a replacement parameter for recovery processes. The author plans to make minor updates to the paper and start writing a BIP draft.\n📝 Original message:I've implemented three changes based on suggestions from Greg Sanders\nand AJ Towns.\n\nI've segmented the changes into commits that should be\nreasonable to follow, even though I'll probably rearrange the commit\nstructure later on.\n\n1. Greg's suggestion: OP_UNVAULT outputs can now live behind\nscripthashes. This means that the lifecycle of a vault can live entirely\nwithin, say, Taproot. In this case the only thing that would reveal\nthe operation of the vault would be the content of the witness stack\nwhen triggering an unvault or recovering. So I think no real privacy\nbenefits over the previous scheme, but certainly some efficiency ones\nsince we're moving more content from the scriptPubKey into the witness.\n\n Commit here:\nhttps://github.com/bitcoin/bitcoin/pull/26857/commits/cd33d120c67cda7eb5c6bbfe3a1ea9fb6c5b93d1\n\n2. AJ's suggestion: unvault trigger transactions can now have an extra\n\"revault\" output that redeposits some balance to the same vault\nscriptPubKey from which it came. This is nice because if the delay\nperiod is long, you may want to manage a remaining vault balance\nseparately while the spent balance is pending an unvault.\n\n Commit here:\nhttps://github.com/bitcoin/bitcoin/pull/26857/commits/cf3764fb503bc17c4438d1322ecf780b9dc3ef30\n\n3. AJ's suggestion: instead of specifying \u003crecovery-spk-hash\u003e, introduce\na replacement parameter: \u003crecovery-params\u003e. This contains the same\ntarget recovery sPK hash as before, but the remaining bytes contain a\nscriptPubKey that functions as authorization for the recovery process.\nThis allows users to optionally avoid the risk of \"recovery replays\" at\nthe expense of having to maintain a recovery key. Users can opt out of\nthis by passing OP_TRUE for the recovery sPK. I guess maybe I could even\nsupport just omitting an sPK altogether for the legacy behavior.\n\nCommit here:\nhttps://github.com/bitcoin/bitcoin/pull/26857/commits/fdfd5e93f96856fbb41243441177a40ebbac6085\n\n\nThe suggestions were good ones, and I think they've improved the\nproposal.\n\nMy next steps are to do minor updates to the paper and start writing a\nBIP draft.\n\nThanks to achow for the valuable feedback, which I'm still mulling on.\n\nJames\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230118/a1c7719a/attachment.html\u003e",
"sig": "797e5fffc5294a6bd54e371a96c106dfc095148995607cc55117c70e1186aad33285edb7d38cb8edfe7c8f5bdb8496ec285d742166688b6a01fb328e7c36c713"
}