Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 620D0C000B for ; Wed, 9 Mar 2022 11:07:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 3DDEE417D6 for ; Wed, 9 Mar 2022 11:07:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNWY804XPclS for ; Wed, 9 Mar 2022 11:07:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by smtp4.osuosl.org (Postfix) with ESMTPS id 463EB41678 for ; Wed, 9 Mar 2022 11:07:05 +0000 (UTC) Received: by mail-yb1-xb2c.google.com with SMTP id h126so3593437ybc.1 for ; Wed, 09 Mar 2022 03:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=EdQAGWJ2ztz1OwChoQJ7gevt0TKktzivNZmiDmT6fV8=; b=V8UFN5EP/Ov9yNYOUd9W4yanVVhv/y8KNCJk2xGyDhP7Q4ZwT/4Nw2R3h2N+XEKRnW dw85UBYaEXelcsSmrbR95B7m8THHKZitYAjh1RPTriLVS76vsz8/GWqk6YNwn55tWDcC QOTXgJwk+0J3pu/QWc0wGd0axpCj6WRKlcyS1c1H6Hg6CkvzL5IDWYyRMJ2NMYakqQ83 LE6UykY51XtNrwPSSqFS0Tli2OO8oZr8rW61RhRbHXwW3IBPlvDLDeZ0cyl+mjFdxaDa UKf24syh3ZujYGOPS0NxX2vTBjCNRsoUZONj/VFSz4vZBCDmIXNQo+oxTsB96ScD8/OZ BwqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=EdQAGWJ2ztz1OwChoQJ7gevt0TKktzivNZmiDmT6fV8=; b=MvF/RzJX2h0LrKp2zURGfts/rOt69LNVSxYV3mbb8LMzaTpGKoAQ51InSfNSxYlZeB uzZNCtoj3Qkeehl1mE2L0FpdPyBt+ZrelI1zAI74beHJrqyKceFR/dssKjc6WF9WRZnh 47UW3rTbVYtDD4axypq1x2RWZl324wpxvsdOY6nzH8V7wUAK8qn9O+Wc+o99ngufke7B 0fBv9IZa4adOLTuWd908eWW0PjUU9zqIO4Z97WDv4pryIYAgRsLJI4b8bP2g0Is48H9/ kL2/wZ3JUsUI/8fqw1yv139YkMkWByf5DV9UX8j84fF8e/12p8UinmJhNCnOUr+h96E1 D7HQ== X-Gm-Message-State: AOAM532X8O70u2xI68TOviMY0KkaPE02zta3hv9teWkjPhYKw2398OKL DIPAYbY95w3Jnd9BYQZEcj05XqBpYbNQqht1hQZmWw== X-Google-Smtp-Source: ABdhPJwyMYL/HyiodZlS9Gq/2oHYZpBYwujJLfD5x5mpy4hI8YZYC4PQPhb3p+MFV59sHHKPILjbQcPHESiofBtNALw= X-Received: by 2002:a25:fe0d:0:b0:628:9cd4:e8da with SMTP id k13-20020a25fe0d000000b006289cd4e8damr15207334ybe.511.1646824024157; Wed, 09 Mar 2022 03:07:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Wed, 9 Mar 2022 11:08:06 +0000 Message-ID: To: Jeremy Rubin , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000f7c0d105d9c71847" X-Mailman-Approved-At: Wed, 09 Mar 2022 13:12:11 +0000 Subject: Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2022 11:07:08 -0000 --000000000000f7c0d105d9c71847 Content-Type: text/plain; charset="UTF-8" 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: OP_DOTHETHING > > best, > > Jeremy > > -- > @JeremyRubin > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000f7c0d105d9c71847 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 an= d is just explained away.
Perhaps it is just my subj= ective perception.
Sometimes it feels we're goin= g from "don't trust, verify" to "just trust jeremy rubin= ", i hope this is really just my subjective perception. Because I thin= k 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:=

=
Notes:

1) Sapio Updates
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;color:#000000">
= Sapio has Experimental Taproot Support now.
See logs for how to help.
Rust= -bitcoin can also use your help reviewing, e.g.=C2=A0https://github.co= m/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 spon= sors are vs. RBF/CPFP.
Why there'= s not a BIP # assigned (despite it being written up as a BIP+impl in=C2=A0<= a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Sept= ember/018168.html" target=3D"_blank" rel=3D"noreferrer">https://lists.linux= foundation.org/pipermail/bitcoin-dev/2020-September/018168.html, should= only get a number if it seems like people agree).

3) James' Vaul= ts Post

James' vaults are similar to prior art on recursive CTV v= aults (Kanzure's / Jeremy's), where the number of steps =3D 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=C2=A0customizable must it= be?

4) Mailing list be poppin'

Zmn shared a prepared remar= k 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 y= ou don't like?
Math is scary -- y= ou can do all sorts of bizarre stuff with more power (e.g., what if you mad= e an EVM inside a bitcoin output).
T= hings like OP_EVICT should be bounded by design.
Problem X: Infrastructure issue for all more flexible covenants:
=C2=A0 =C2=A01) generate a transition functi= on you would like
=C2=A0 = =C2=A02) compile it into a script covenant
=C2=A0 =C2=A03) request the transition/txn you want to have happen
=C2=A0 =C2=A0 4) produce a satisifaction of the script covena= nt for that transaction
=C2=A0 =C2=A05) prove the t= ransition 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=C2=A0on forking, = if theres any kind of consensus forming, doing things like https://lists.linuxfoundation.org/pipe= rmail/bitcoin-dev/2021-April/018833.html
How much does a shot-on-goal cost / unforced errors of not making an ac= tivating client available precluding being able to activate
luke-jr: nev= er ST; ST is a reason enough to oppose CTV
jamesob: <javascript> O= P_DOTHETHING

best,

Jeremy

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000f7c0d105d9c71847--