Re: [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)

* Tuesday, March 8th. I think Noon PT == 8pm UTC? but dont trust me i cant even tell what day is what. -- @JeremyRubin On Mon, Mar 7, 2022 at 6:50 PM Jeremy Rubin wrote: > Hi all, > > There will be a CTV meeting tomorrow at noon PT. Agenda below: > > 1)

Re: [bitcoin-dev] bitcoin scripting and lisp

Good morning aj et al., > > They're radically different approaches and > > it's hard to see how they mix. Everything in lisp is completely sandboxed, > > and that functionality is important to a lot of things, and it's really > > normal to be given a reveal of a scriptpubkey and be able to rely

[bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)

Hi all, There will be a CTV meeting tomorrow at noon PT. Agenda below: 1) Sapio Taproot Support Update / Request for Review (20 Minutes) - Experimental support for Taproot merged on master https://github.com/sapio-lang/sapio 2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes) -

Re: [bitcoin-dev] bitcoin scripting and lisp

On Sun, Mar 06, 2022 at 10:26:47PM -0800, Bram Cohen via bitcoin-dev wrote: > > After looking into it, I actually think chia lisp [1] gets pretty much all > > the major design decisions pretty much right. There are obviously a few > > changes needed given the differences in design between chia and

Re: [bitcoin-dev] CTV vaults in the wild

Good morning Antoine, > Hi James, > > Interesting to see a sketch of a CTV-based vault design ! > > I think the main concern I have with any hashchain-based vault design is the > immutability of the flow paths once the funds are locked to the root vault > UTXO. By immutability, I mean there is

[bitcoin-dev] Jets (Was: `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT)

Good morning Billy, Changed subject since this is only tangentially related to `OP_FOLD`. > Let me organize my thoughts on this a little more clearly. There's a couple > possibilities I can think of for a jet-like system: > > A. We could implement jets now without a consensus change, and

Re: [bitcoin-dev] bitcoin scripting and lisp

Good morning Bram, > while in the coin set model each puzzle (scriptpubkey) gets run and either > assert fails or returns a list of extra conditions it has, possibly including > timelocks and creating new coins, paying fees, and other things. Does this mean it basically gets recursive

Re: [bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT

Let me organize my thoughts on this a little more clearly. There's a couple possibilities I can think of for a jet-like system: A. We could implement jets now without a consensus change, and without requiring all nodes to upgrade to new relay rules. Probably. This would give upgraded nodes

[bitcoin-dev] bitcoin scripting and lisp

> > After looking into it, I actually think chia lisp [1] gets pretty much all > the major design decisions pretty much right. There are obviously a few > changes needed given the differences in design between chia and bitcoin: > > - having secp256k1 signatures (and curve operations), instead of

Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations

Hi Jeremy, > I've seen some discussion of what the Annex can be used for in Bitcoin. For > example, some people have discussed using the annex as a data field for > something like CHECKSIGFROMSTACK type stuff (additional authenticated data) > or for something like delegation (the delegation is to

Re: [bitcoin-dev] CTV vaults in the wild

Hi James, Interesting to see a sketch of a CTV-based vault design ! I think the main concern I have with any hashchain-based vault design is the immutability of the flow paths once the funds are locked to the root vault UTXO. By immutability, I mean there is no way to modify the

Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations

On Sat, Mar 05, 2022 at 12:20:02PM +, Jeremy Rubin via bitcoin-dev wrote: > On Sat, Mar 5, 2022 at 5:59 AM Anthony Towns wrote: > > The difference between information in the annex and information in > > either a script (or the input data for the script that is the rest of > > the witness) is