📅 Original date posted:2023-01-10
🗒️ Summary of this message: Discussion on proposed improvements to Bitcoin's vault system, including using pay-to-contract construction for recovery path and a generic OP_UNVAULT.
📝 Original message:Thanks for the thoughtful reply AJ.
> I don't think that makes sense? With a general scheme, you'd only be
> bloating the witness data (perhaps including the witness script) not
> the scriptPubKey?
Sorry, sloppy language on my part. To be charitable, I'm talking about
the "figurative sPK," which of course these days lives in the witness
for script-path-ish spends. Maybe the witness discount means that
"complicated" scripts aren't as big a deal, depending on the actual
difference in raw script size.
> I think it might be better to use a pay-to-contract construction for
> the recovery path, rather than an empty witness.
So I guess the one advantage that what you're proposing has over just
using a recovery-path key signature is that it's all derivable from your
cold privkey; you don't have to worry about accidentally losing the
recovery-path key.
Of course you're still vulnerable to spurious sweeps if the
sha256(secret) value gets found out, which presumably you'd want in an
accessible cache to avoid touching the cold secret every time you want
to sweep.
What do you think about the idea of making the recovery-path
authorization behavior variable on a single byte flag preceding the 32
byte data push, as I mentioned in another post? I think it may make
sense to leave this option open to end-users (and also allow for some
upgradeability).
> I think a generic OP_UNVAULT can be used to simulate OP_CTV: replace
> "<h> OP_CTV" with "<000..0> 0 <h> OP_UNVAULT".
Yup, that's an inefficient way of emulating CTV. If people want CTV, we
should just look at activating CTV. Greg Sanders has a thing about
"jetting" CTV into this proposal (I think) so that the code-paths are
shared, but I haven't figured out how that would work. They really
don't share that much code AFAICT.
> The paper seems to put "OP_UNVAULT" first, but the code seems to
> expect it to come last, not sure what's up with that inconsistency.
Again some sloppy notation on my part. What I sort of meant in the paper
was a kind of functional notation `OP_VAULT(param1, param2, ...)`. Let's
chalk that up to my inexperience actually working on script stuff.
> I think there's maybe a cleverer way of batching / generalising
> checking that input/output amounts match.
>
> [...]
>
> * set C = the sum of each output that has a vault tag with
> #recovery=X
This would also need to take into account that the <spend-delay>s are
compatible, but your point is well taken.
> I think one meaningful difference between these two approaches is that
> the current proposal means unvaulting locks up the entire utxo for the
> delay period, rather than just the amount you're trying to unvault.
This is a really good point and I think is one that's important to
incorporate with a change to the existing proposal.
A simple fix for facilitating the use of a "partial revault" while the
OP_UNVAULT UTXO is outstanding would be to allow for an optional
third output that is a redeposit back to the identical OP_VAULT sPK that
is being spent by the OP_UNVAULT transaction, then the script
interpreter would just ensure that the nValue of those two outputs sums
to the sum of the input nValues.
I can see what you're saying about having more generic "group amounts by
compatible vault params, and then compare to similarly grouped outputs,"
but I'm just wondering if there are other uses that enables besides the
partial-revault thing I mentioned above. If not, I'd probably rather just
stick
with something simple like having the third optional re-vault output.
> Changing the unvault construction to have an optional OP_VAULT output
> would remedy that, I think.
Oh - okay, this is what you're saying. Right!
Is that a sufficient change, or are there other benefits that the more
complicated clever-I/O-vault-grouping would enable that you have in
mind?
> What would it look like to just hide all this under taproot?
>
> [...]
>
> It also needs some way of constructing "unvault[X]", which could be a
> TLUV-like construction.
>
> That all seems possible to me; though certainly needs more work/thought
> than just having dedicated opcodes and stuffing the data directly in
> the sPK.
I think this is a very important comparison to do, but I'm eager to see
code for things like this. There have been a lot of handwavey proposals
lately without tangible code artifacts. I'm eager to see what these
alternatives look like in practice - i.e. in functional tests.
Thanks again for the great mail.
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230110/a5579378/attachment.html>;
James O'Beirne [ARCHIVE] /
npub1dp…ymz3t
2023-06-07 23:18:19
in reply to nevent1q…737n
Author Public Key
npub1dpdfw74plzm03mzglkdegp3hqn6qs9yffqefa5kh98mru49nrg7szymz3tPublished at
2023-06-07 23:18:19Event JSON
{
"id": "6b93d5e0b251c6c363cebaf515ed6a2aa18f0f2564b539443c8608240a779f05",
"pubkey": "685a977aa1f8b6f8ec48fd9b94063704f408148948329ed2d729f63e54b31a3d",
"created_at": 1686179899,
"kind": 1,
"tags": [
[
"e",
"a84542afe0efb7efffac7c1bbcfb71ebcb322bb4dd5fb2586b4f66533f300f6e",
"",
"root"
],
[
"e",
"7d99cc28b2423b37d3ddaf79a56b3f2d860f70850836378bb99156f25edc3759",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2023-01-10\n🗒️ Summary of this message: Discussion on proposed improvements to Bitcoin's vault system, including using pay-to-contract construction for recovery path and a generic OP_UNVAULT.\n📝 Original message:Thanks for the thoughtful reply AJ.\n\n\n\u003e I don't think that makes sense? With a general scheme, you'd only be\n\u003e bloating the witness data (perhaps including the witness script) not\n\u003e the scriptPubKey?\n\nSorry, sloppy language on my part. To be charitable, I'm talking about\nthe \"figurative sPK,\" which of course these days lives in the witness\nfor script-path-ish spends. Maybe the witness discount means that\n\"complicated\" scripts aren't as big a deal, depending on the actual\ndifference in raw script size.\n\n\n\u003e I think it might be better to use a pay-to-contract construction for\n\u003e the recovery path, rather than an empty witness.\n\nSo I guess the one advantage that what you're proposing has over just\nusing a recovery-path key signature is that it's all derivable from your\ncold privkey; you don't have to worry about accidentally losing the\nrecovery-path key.\n\nOf course you're still vulnerable to spurious sweeps if the\nsha256(secret) value gets found out, which presumably you'd want in an\naccessible cache to avoid touching the cold secret every time you want\nto sweep.\n\nWhat do you think about the idea of making the recovery-path\nauthorization behavior variable on a single byte flag preceding the 32\nbyte data push, as I mentioned in another post? I think it may make\nsense to leave this option open to end-users (and also allow for some\nupgradeability).\n\n\n\u003e I think a generic OP_UNVAULT can be used to simulate OP_CTV: replace\n\u003e \"\u003ch\u003e OP_CTV\" with \"\u003c000..0\u003e 0 \u003ch\u003e OP_UNVAULT\".\n\nYup, that's an inefficient way of emulating CTV. If people want CTV, we\nshould just look at activating CTV. Greg Sanders has a thing about\n\"jetting\" CTV into this proposal (I think) so that the code-paths are\nshared, but I haven't figured out how that would work. They really\ndon't share that much code AFAICT.\n\n\n\u003e The paper seems to put \"OP_UNVAULT\" first, but the code seems to\n\u003e expect it to come last, not sure what's up with that inconsistency.\n\nAgain some sloppy notation on my part. What I sort of meant in the paper\nwas a kind of functional notation `OP_VAULT(param1, param2, ...)`. Let's\nchalk that up to my inexperience actually working on script stuff.\n\n\n\u003e I think there's maybe a cleverer way of batching / generalising\n\u003e checking that input/output amounts match.\n\u003e\n\u003e [...]\n\u003e\n\u003e * set C = the sum of each output that has a vault tag with\n\u003e #recovery=X\n\nThis would also need to take into account that the \u003cspend-delay\u003es are\ncompatible, but your point is well taken.\n\n\n\u003e I think one meaningful difference between these two approaches is that\n\u003e the current proposal means unvaulting locks up the entire utxo for the\n\u003e delay period, rather than just the amount you're trying to unvault.\n\nThis is a really good point and I think is one that's important to\nincorporate with a change to the existing proposal.\n\nA simple fix for facilitating the use of a \"partial revault\" while the\nOP_UNVAULT UTXO is outstanding would be to allow for an optional\nthird output that is a redeposit back to the identical OP_VAULT sPK that\nis being spent by the OP_UNVAULT transaction, then the script\ninterpreter would just ensure that the nValue of those two outputs sums\nto the sum of the input nValues.\n\nI can see what you're saying about having more generic \"group amounts by\ncompatible vault params, and then compare to similarly grouped outputs,\"\nbut I'm just wondering if there are other uses that enables besides the\npartial-revault thing I mentioned above. If not, I'd probably rather just\nstick\nwith something simple like having the third optional re-vault output.\n\n\n\u003e Changing the unvault construction to have an optional OP_VAULT output\n\u003e would remedy that, I think.\n\nOh - okay, this is what you're saying. Right!\n\nIs that a sufficient change, or are there other benefits that the more\ncomplicated clever-I/O-vault-grouping would enable that you have in\nmind?\n\n\n\u003e What would it look like to just hide all this under taproot?\n\u003e\n\u003e [...]\n\u003e\n\u003e It also needs some way of constructing \"unvault[X]\", which could be a\n\u003e TLUV-like construction.\n\u003e\n\u003e That all seems possible to me; though certainly needs more work/thought\n\u003e than just having dedicated opcodes and stuffing the data directly in\n\u003e the sPK.\n\nI think this is a very important comparison to do, but I'm eager to see\ncode for things like this. There have been a lot of handwavey proposals\nlately without tangible code artifacts. I'm eager to see what these\nalternatives look like in practice - i.e. in functional tests.\n\n\nThanks again for the great mail.\nJames\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230110/a5579378/attachment.html\u003e",
"sig": "5627f80474c9397560d0bcc335497f593adafd2d236dc102110555ac4cabd536472150467c0cacf10b3eaccc1d9060e49d72b1b2726ebece4a4fb274d284903d"
}