📅 Original date posted:2022-03-08
📝 Original message:Logs here: https://gnusha.org/ctv-bip-review/2022-03-08.log
Notes:
1) Sapio Updates
Sapio has Experimental Taproot Support now.
See logs for how to help.
Rust-bitcoin can also use your help reviewing, e.g.
https://github.com/rust-bitcoin/rust-miniscript/pull/305
Adding MuSig support for the oracle servers would be really cool, if
someone wants a challenge.
2) Transaction Sponsors
What sponsors are vs. RBF/CPFP.
Why there's not a BIP # assigned (despite it being written up as a BIP+impl
in
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html,
should only get a number if it seems like people agree).
3) James' Vaults Post
James' vaults are similar to prior art on recursive CTV vaults (Kanzure's /
Jeremy's), where the number of steps = 1.
Actually ends up being a very good design for many custody purposes, might
be a good "80% of the benefit 20% of the work" type of thing.
People maybe want different things out of vaults... how customizable must
it be?
4) Mailing list be poppin'
Zmn shared a prepared remark which spurred a nice conversation.
General sentiment that we should be careful adding crazy amounts of power,
with great power comes great responsibility...
Maybe we shouldn't care though -- don't send to scripts you don't like?
Math is scary -- you can do all sorts of bizarre stuff with more power
(e.g., what if you made an EVM inside a bitcoin output).
Things like OP_EVICT should be bounded by design.
Problem X: Infrastructure issue for all more flexible covenants:
1) generate a transition function you would like
2) compile it into a script covenant
3) request the transition/txn you want to have happen
4) produce a satisifaction of the script covenant for that transaction
5) prove the transition function *is* what you wanted/secure
Quantifying how hard X is for a given proposal is a good idea.
You can prototype covenants with federations in Sapio pretty easily... more
people should try this!
5) General discuss
People suck at naming things... give things more unique names for protocols!
Jeremy will name something the Hot Tub Coin Machine
Some discussion on forking, if theres any kind of consensus forming, doing
things like
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018833.html
How much does a shot-on-goal cost / unforced errors of not making an
activating client available precluding being able to activate
luke-jr: never ST; ST is a reason enough to oppose CTV
jamesob: <javascript> OP_DOTHETHING
best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220308/1b56b098/attachment.html>;
Jeremy Rubin [ARCHIVE] /
npub1xu…fzef0
2023-06-07 23:05:51
in reply to nevent1q…szy0
Author Public Key
npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0Published at
2023-06-07 23:05:51Event JSON
{
"id": "4205cfb78455c293730b2d46a76ca4c57307d48d09fcada9538b1f178ead5d1a",
"pubkey": "372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a",
"created_at": 1686179151,
"kind": 1,
"tags": [
[
"e",
"83acd5370ccb9fe968098a1396b47a2e00f389e32ecf7150596370fd89c05c58",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2022-03-08\n📝 Original message:Logs here: https://gnusha.org/ctv-bip-review/2022-03-08.log\n\nNotes:\n\n1) Sapio Updates\n\nSapio has Experimental Taproot Support now.\nSee logs for how to help.\nRust-bitcoin can also use your help reviewing, e.g.\nhttps://github.com/rust-bitcoin/rust-miniscript/pull/305\nAdding MuSig support for the oracle servers would be really cool, if\nsomeone wants a challenge.\n\n2) Transaction Sponsors\n\nWhat sponsors are vs. RBF/CPFP.\nWhy there's not a BIP # assigned (despite it being written up as a BIP+impl\nin\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html,\nshould only get a number if it seems like people agree).\n\n3) James' Vaults Post\n\nJames' vaults are similar to prior art on recursive CTV vaults (Kanzure's /\nJeremy's), where the number of steps = 1.\nActually ends up being a very good design for many custody purposes, might\nbe a good \"80% of the benefit 20% of the work\" type of thing.\nPeople maybe want different things out of vaults... how customizable must\nit be?\n\n4) Mailing list be poppin'\n\nZmn shared a prepared remark which spurred a nice conversation.\nGeneral sentiment that we should be careful adding crazy amounts of power,\nwith great power comes great responsibility...\nMaybe we shouldn't care though -- don't send to scripts you don't like?\nMath is scary -- you can do all sorts of bizarre stuff with more power\n(e.g., what if you made an EVM inside a bitcoin output).\nThings like OP_EVICT should be bounded by design.\nProblem X: Infrastructure issue for all more flexible covenants:\n 1) generate a transition function you would like\n 2) compile it into a script covenant\n 3) request the transition/txn you want to have happen\n 4) produce a satisifaction of the script covenant for that transaction\n 5) prove the transition function *is* what you wanted/secure\nQuantifying how hard X is for a given proposal is a good idea.\nYou can prototype covenants with federations in Sapio pretty easily... more\npeople should try this!\n\n5) General discuss\nPeople suck at naming things... give things more unique names for protocols!\nJeremy will name something the Hot Tub Coin Machine\nSome discussion on forking, if theres any kind of consensus forming, doing\nthings like\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018833.html\nHow much does a shot-on-goal cost / unforced errors of not making an\nactivating client available precluding being able to activate\nluke-jr: never ST; ST is a reason enough to oppose CTV\njamesob: \u003cjavascript\u003e OP_DOTHETHING\n\nbest,\n\nJeremy\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220308/1b56b098/attachment.html\u003e",
"sig": "9c1d6fab9637b171801ea176f60c4a8beb9d26b0eb0a68dc2f5bf1489a62de0961538966faac0ed88a73e01488e6dd690242e60adbf4e54f9d9bbaf008699926"
}