📅 Original date posted:2022-03-09
📝 Original message:What is ST? If it may be a reason to oppose CTV, why not talk about it more
explicitly so that others can understand the criticisms?
It seems that criticism isn't really that welcomed and is just explained
away.
Perhaps it is just my subjective perception.
Sometimes it feels we're going from "don't trust, verify" to "just trust
jeremy rubin", i hope this is really just my subjective perception. Because
I think it would be really bad that we started to blindly trust people like
that, and specially jeremy.
On Wed, Mar 9, 2022, 00:37 Jeremy Rubin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220309/aebc98d4/attachment-0001.html>;
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 23:05:51
in reply to nevent1q…255m
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 23:05:51Event JSON
{
"id": "ac11e7a0469305e4217682b2687c750022281a530f4b31f7521d465e319c26ad",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686179151,
"kind": 1,
"tags": [
[
"e",
"83acd5370ccb9fe968098a1396b47a2e00f389e32ecf7150596370fd89c05c58",
"",
"root"
],
[
"e",
"4205cfb78455c293730b2d46a76ca4c57307d48d09fcada9538b1f178ead5d1a",
"",
"reply"
],
[
"p",
"372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a"
]
],
"content": "📅 Original date posted:2022-03-09\n📝 Original message:What is ST? If it may be a reason to oppose CTV, why not talk about it more\nexplicitly so that others can understand the criticisms?\nIt seems that criticism isn't really that welcomed and is just explained\naway.\nPerhaps it is just my subjective perception.\nSometimes it feels we're going from \"don't trust, verify\" to \"just trust\njeremy rubin\", i hope this is really just my subjective perception. Because\nI think it would be really bad that we started to blindly trust people like\nthat, and specially jeremy.\n\n\nOn Wed, Mar 9, 2022, 00:37 Jeremy Rubin via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Logs here: https://gnusha.org/ctv-bip-review/2022-03-08.log\n\u003e\n\u003e Notes:\n\u003e\n\u003e 1) Sapio Updates\n\u003e\n\u003e Sapio has Experimental Taproot Support now.\n\u003e See logs for how to help.\n\u003e Rust-bitcoin can also use your help reviewing, e.g.\n\u003e https://github.com/rust-bitcoin/rust-miniscript/pull/305\n\u003e Adding MuSig support for the oracle servers would be really cool, if\n\u003e someone wants a challenge.\n\u003e\n\u003e 2) Transaction Sponsors\n\u003e\n\u003e What sponsors are vs. RBF/CPFP.\n\u003e Why there's not a BIP # assigned (despite it being written up as a\n\u003e BIP+impl in\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html,\n\u003e should only get a number if it seems like people agree).\n\u003e\n\u003e 3) James' Vaults Post\n\u003e\n\u003e James' vaults are similar to prior art on recursive CTV vaults (Kanzure's\n\u003e / Jeremy's), where the number of steps = 1.\n\u003e Actually ends up being a very good design for many custody purposes, might\n\u003e be a good \"80% of the benefit 20% of the work\" type of thing.\n\u003e People maybe want different things out of vaults... how customizable must\n\u003e it be?\n\u003e\n\u003e 4) Mailing list be poppin'\n\u003e\n\u003e Zmn shared a prepared remark which spurred a nice conversation.\n\u003e General sentiment that we should be careful adding crazy amounts of power,\n\u003e with great power comes great responsibility...\n\u003e Maybe we shouldn't care though -- don't send to scripts you don't like?\n\u003e Math is scary -- you can do all sorts of bizarre stuff with more power\n\u003e (e.g., what if you made an EVM inside a bitcoin output).\n\u003e Things like OP_EVICT should be bounded by design.\n\u003e Problem X: Infrastructure issue for all more flexible covenants:\n\u003e 1) generate a transition function you would like\n\u003e 2) compile it into a script covenant\n\u003e 3) request the transition/txn you want to have happen\n\u003e 4) produce a satisifaction of the script covenant for that transaction\n\u003e 5) prove the transition function *is* what you wanted/secure\n\u003e Quantifying how hard X is for a given proposal is a good idea.\n\u003e You can prototype covenants with federations in Sapio pretty easily...\n\u003e more people should try this!\n\u003e\n\u003e 5) General discuss\n\u003e People suck at naming things... give things more unique names for\n\u003e protocols!\n\u003e Jeremy will name something the Hot Tub Coin Machine\n\u003e Some discussion on forking, if theres any kind of consensus forming,\n\u003e doing things like\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018833.html\n\u003e How much does a shot-on-goal cost / unforced errors of not making an\n\u003e activating client available precluding being able to activate\n\u003e luke-jr: never ST; ST is a reason enough to oppose CTV\n\u003e jamesob: \u003cjavascript\u003e OP_DOTHETHING\n\u003e\n\u003e best,\n\u003e\n\u003e Jeremy\n\u003e\n\u003e --\n\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220309/aebc98d4/attachment-0001.html\u003e",
"sig": "041e33d8e996f469c78ec5e366ea8036aac70bb51d4d3cc70f5a4a50bc4cc2d6c203cd9a030280f29f28fae721e3f3f3c9524b280d076dbbda49b934508338cf"
}