public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5
Date: Wed, 9 Mar 2022 11:08:06 +0000	[thread overview]
Message-ID: <CABm2gDqMcgcyYErNgMe9shXUxX5E85n+VqheDf1_E1mPq3ijLg@mail.gmail.com> (raw)
In-Reply-To: <CAD5xwhgvW_ATpWuMv1fF6hhjTyp8imkxfAY1CcCvYk1AwgqfhA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 10332 bytes --]

  reply	other threads:[~2022-03-09 11:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09  0:36 [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5 Jeremy Rubin
2022-03-09 11:08 ` Jorge Timón [this message]
2022-03-09 14:42   ` ZmnSCPxj
2022-03-10 11:28     ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABm2gDqMcgcyYErNgMe9shXUxX5E85n+VqheDf1_E1mPq3ijLg@mail.gmail.com \
    --to=jtimon@jtimon.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jeremy.l.rubin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox