[bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

[bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

[Jeremy Rubin]

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

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>

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

Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

[ZmnSCPxj]

Good morning Jorge,

> 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?

ST is Speedy Trial.
Basically, a short softfork attempt with `lockinontimeout=false` is first done.
If this fails, then developers stop and think and decide whether to offer a UASF `lockinontimeout=true` version or not.

Jeremy showed a state diagram of Speedy Trial on the IRC, which was complicated enough that I ***joked*** that it would be better to not implement `OP_CTV` and just use One OPCODE To Rule Them All, a.k.a. `OP_RING`.

If you had actually read the IRC logs you would have understood it, I even explicitly asked "ST ?=" so that the IRC logs have it explicitly listed as "Speedy Trial".


> It seems that criticism isn't really that welcomed and is just explained away.

It seems that you are trying to grasp at any criticism and thus fell victim to a joke.

> 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.

Why "specially jeremy"?
Any particular information you think is relevant?

The IRC logs were linked, you know, you could have seen what was discussed.

In particular, on the other thread you mention:

> We should talk more about activation mechanisms and how users should be able to actively resist them more.

Speedy Trial means that users with mining hashpower can block the initial Speedy Trial, and the failure to lock in ***should*** cause the developers to stop-and-listen.
If the developers fail to stop-and-listen, then a counter-UASF can be written which *rejects* blocks signalling *for* the upgrade, which will chainsplit from a pro-UASF `lockinontimeout=true`, but clients using the initial Speedy Trial code will follow which one has better hashpower.

If we assume that hashpower follows price, then users who want for / against a particular softfork will be able to resist the Speedy Trial, and if developers release a UASF `lockinontimeout=true` later, will have the choice to reject running the UASF and even running a counter-UASF.


Regards,
ZmnSCPxj

Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

[Jorge Timón]

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

Thank you for explaining. I agree with luke then, I'm against speedy trial.
I explained why already, I think.
In summary: speedy trial kind of means is miners and not users who decide
the rules.
It gives users less opportunities to react and oppose a malevolent change
in case miners want to impose such change on them.


Why specially jeremy?

I personally distrust him more from experience, but that's subjective, and
kind of offtopic. Sorry, I should try to distrust all the other devs as
much as I distrust him in particular.
"Don't trust, verify", right?


On Wed, Mar 9, 2022, 14:42 ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Jorge,
>
> > 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?
>
> ST is Speedy Trial.
> Basically, a short softfork attempt with `lockinontimeout=false` is first
> done.
> If this fails, then developers stop and think and decide whether to offer
> a UASF `lockinontimeout=true` version or not.
>
> Jeremy showed a state diagram of Speedy Trial on the IRC, which was
> complicated enough that I ***joked*** that it would be better to not
> implement `OP_CTV` and just use One OPCODE To Rule Them All, a.k.a.
> `OP_RING`.
>
> If you had actually read the IRC logs you would have understood it, I even
> explicitly asked "ST ?=" so that the IRC logs have it explicitly listed as
> "Speedy Trial".
>
>
> > It seems that criticism isn't really that welcomed and is just explained
> away.
>
> It seems that you are trying to grasp at any criticism and thus fell
> victim to a joke.
>
> > 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.
>
> Why "specially jeremy"?
> Any particular information you think is relevant?
>
> The IRC logs were linked, you know, you could have seen what was discussed.
>
> In particular, on the other thread you mention:
>
> > We should talk more about activation mechanisms and how users should be
> able to actively resist them more.
>
> Speedy Trial means that users with mining hashpower can block the initial
> Speedy Trial, and the failure to lock in ***should*** cause the developers
> to stop-and-listen.
> If the developers fail to stop-and-listen, then a counter-UASF can be
> written which *rejects* blocks signalling *for* the upgrade, which will
> chainsplit from a pro-UASF `lockinontimeout=true`, but clients using the
> initial Speedy Trial code will follow which one has better hashpower.
>
> If we assume that hashpower follows price, then users who want for /
> against a particular softfork will be able to resist the Speedy Trial, and
> if developers release a UASF `lockinontimeout=true` later, will have the
> choice to reject running the UASF and even running a counter-UASF.
>
>
> Regards,
> ZmnSCPxj
>

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