Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

s in a global value network. -- @JeremyRubin <https://twitter.com/JeremyRubin> On Thu, Oct 20, 2022 at 3:28 PM Peter Todd wrote: > On Sun, Oct 16, 2022 at 01:35:54PM -0400, Jeremy Rubin via bitcoin-dev > wrote: > > The Bitcoin white paper says: > > > > The proof-of

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

If they do this to you, and the delta is substantial, can't you sweep all such abusers with a cpfp transaction replacing their package and giving you the original txn? On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > >

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

Excellent proposal and I agree it does capture much of the spirit of sponsors w.r.t. how they might be used for V3 protocols. The only drawbacks I see is they don't work for lower tx version contracts, so there's still something to be desired there, and that the requirement to sweep the output

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

appening now, a fight over something that seems obviously not incentive compatible. -- @JeremyRubin <https://twitter.com/JeremyRubin> On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor wrote: > On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev < > bitcoin-dev@lists.linuxfounda

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

(If anyone thinks these three are > similar properties you can make some trivial counterexamples) > > > My take is the opposite unless I'm missing something. Participants are > always incentivized to choose the rational solution (Not to waste > electricity on a minority chain). &

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

n as an > assumption, rather it is something that ought to be a consequence of the > design. > > Anyhow, the above is simply a comment on "honest majority", and I'm not > trying to make a specific claim about RBF here, though I do have my > opinions and I do see how it is r

[bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

The Bitcoin white paper says: The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The

[bitcoin-dev] Spookchains: Drivechain Analog with One-Time Trusted Setup & APO

*also available here on my blog with nicer formatting: https://rubin.io/bitcoin/2022/09/14/drivechain-apo/ * This post draws heavily from Zmnscpxj's fantastic post showing how to make drivechains with recursive covenants. In this post, I will

Re: [bitcoin-dev] More uses for CTV

Presigned transactions have to use a N-of-N (2-2 for ln, more for pools) multisignature which is computed over the network whereas in-script commitments can be done 1 key that is a non-secret point (e.g., just the generator I think works). For large protocol trees (e.g., of size N) the savings

Re: [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY

I can't find a link, but I've discussed this before somewhere a while ago... perhaps one of the IRC meetings? I'll see if I can't turn something up. The main reason not to was validation performance -- we already usually compute the flat hash, so the merkle tree would be extra work for just CTV.

[bitcoin-dev] CTV Meeting #9 Reminder + Agenda (Tuesday, May 17th, 12:00 PT / 7PM UTC)

Developers, A reminder that the regularly scheduled CTV Meeting is tomorrow at 12:00 Pacific Time in ##ctv-bip-review in Libera. In terms of agenda, we'll keep it as an open forum for discussion guided by the participants. We'll try to go over, minimally: - Rusty's OP_TX - Adding OP_CAT / CSFS

Re: [bitcoin-dev] Adding SIGHASH to TXID

Have you seen the inherited ID proposal from John Law on this list? It's a pretty thorough treatment of this type of proposal, curious if you think it overlaps what you had in mind? Honestly, I've yet to fully load in exactly how the applications of it work, but I'd be interested to hear your

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

Antoine, One high level reason to not prefer APO is that it gets 'dangerously close' to fully recursive covenants. E.g., just by tweaking APO to use a Schnorr signature without PK commitment, Pubkey Recovery would be possible, and fully recursive covenants could be done. Short of that type of

[bitcoin-dev] CTV Meeting #8 Reminder + Agenda (Tuesday, May 3rd, 12:00 PT / 7PM UTC)

Developers, A reminder that the regularly scheduled CTV Meeting is tomorrow at 12:00 Pacific Time in ##ctv-bip-review in Libera. In terms of agenda, we'll keep it as an open forum for discussion guided by the participants. Feel free to propose meeting topics in the IRC in advance of the meeting

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

Ok, got it. Won't waste anyone's time on terminology pedantism. The model that I proposed above is simply what *any* correct timestamping service must do. If OTS does not follow that model, then I suspect whatever OTS is, is provably incorrect or, in this context, unreliable, even when servers

[bitcoin-dev] On The Drama

Developers, I know that some of you may be interested in hearing my perspective on what happened and why. I still do not know exactly what happened and why. However, I can offer a brief explanation of what I perceived my main actions to be and the response to them: 1. I published and shared to

[bitcoin-dev] Working Towards Consensus

Developers, There is much to say about the events of the last two weeks and the response to them. I've been searching for the right words to share here, but I think it best that short of a more thoughtful writeup I start with a timely small step with the below comments. First, let me be clear: I

Re: [bitcoin-dev] CTV Signet Parameters

Sorry I didn't see this snippet fully earlier, but I caught it in Optech (cc harding) > *(I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte* > *hash on the stack evaluate as true? I guess that means everyone's > using**sapio to > construct the txs?)* Not quite: it would

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

Generally speaking, I'm not too fond of these mechanisms, for reasons others have expounded upon, but I will point out the following: Taproot means that top-level keys can be used in a ring signature scheme to collect coin votes from, e.g., all individual coins above a certain value at a certain

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

I can't find all of my earlier references around this, I thought I made a thread on it, but as a reminder, my thoughts for mild tweaks to APO that make it a bit less hacky are as follows: - Remove OP_1 key punning and replace it with OP_GENERATOR and OP_INTERNALKEY (maybe OP_EXTERNALKEY too?).

Re: [bitcoin-dev] What to expect in the next few weeks

for explaining the nuance to me. -- @JeremyRubin <https://twitter.com/JeremyRubin> On Tue, Apr 26, 2022 at 3:47 AM Anthony Towns wrote: > On Mon, Apr 25, 2022 at 10:48:20PM -0700, Jeremy Rubin via bitcoin-dev > wrote: > > Further, you're representing the state of affairs as if there'

Re: [bitcoin-dev] What to expect in the next few weeks

I'm a bit confused here. The "personal blog" in question was sent to this list with an archive link and you saw an replied to it. The proposal to make an alternative path hadn't gotten buy in sufficient from those iterating, and given the propensity of people to blow things out of proportion in

Re: [bitcoin-dev] What to expect in the next few weeks

The reason there was not a mailing list post is because that's not a committed plan, it was offered up for discussion to a public working group for feedback as a potential plan. You've inaccurately informed the list on something no one has communicated committed intent for. This was an alternative

Re: [bitcoin-dev] CTV Signet Parameters

t; wrote: > On Thu, Apr 21, 2022 at 10:05:20AM -0500, Jeremy Rubin via bitcoin-dev > wrote: > > I can probably make some show up sometime soon. Note that James' vault > uses > > one at the top-level https://github.com/jamesob/simple-ctv-vault, but I > > think the second use

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

I think I've discussed this type of concept previously somewhere but cannot find a link to where. Largely, I think the following: 1) This doesn't reduce burden of maintenance and risk of consensus split, it raises it: A) as we now have a bunch of tricky code around reorgs and mempool around

Re: [bitcoin-dev] CTV Signet Parameters

Hi Russell, Thank you for your feedback here. > However, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told > that bare-CTV hasn't even appeared on the CTV signet). Unlike the general > smart-contracting case, bare-CTV does not have any branches. All it can do > is commit to a

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

> You'd be confiscating your own funds by making an absurd spending condition. > By this argument, ALL softforks would have to be ruled out. The argument is that transactions which can be relayed and in the mempool and then confirmed should not ever be restricted. This is so that old node's

Re: [bitcoin-dev] CTV Signet Parameters

Missed one for part 2: Shesek's social recovery wallet using CTV to enforce timelocks without expiry, using his Minsc toolchain: https://twitter.com/shesek/status/1511619296367153153

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

> While reverting Segwit wouldn't be possible, it IS entirely possible to do an > additional softfork to either weigh witness data at the full 4 WU/Byte rate > (same as other data), or to reduce the total weight limit so as to extend the > witness discount to non-segwit transactions (so scriptSig

Re: [bitcoin-dev] CTV Signet Parameters

Probably merits a more thorough response, but, I wanted to respond on the framework above: 1a) can you make transactions using the new feature with bitcoin-cli, eg createrawtransaction etc? (*YES)* since ~Feb 2020, this has existed:

[bitcoin-dev] 7 Theses on a next step for BIP-119

Devs, In advance of the CTV meeting today, I wanted to share what my next step is in advocating for CTV, as well as 7 theses for why I believe it to be the right course of action to take at this time. Please see the post at https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/. As always, open

[bitcoin-dev] CTV Meeting #7 Reminder + Agenda (Tuesday, April 19th, 12:00 PT / 7PM UTC)

Devs, Apologies for the delay in posting the reminder. As noted on March 22nd, the 7th meeting was postponed to the time of the 8th meeting given the Miami conference scheduling conflicts. We'll hold the meeting tomorrow at noon Pacific time as usual. The Agenda for the meeting will be an open

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

the 'lots of people' stuff (get confused, can't figure out what i'm quoting, actually are reading this conversation) is an appeal to an authority that doesn't exist. If something is unclear to you, let me know. If it's unclear to a supposed existential person or set of persons, they can let me

Re: [bitcoin-dev] A Calculus of Covenants

note of clarification: this is from the perspective of a developer trying to build infrastructure for covenants. from the perspective of bitcoin consensus, a covenant enforcing primitve would be something like OP_TLUV and less so it's use in conjunction with other opcodes, e.g. OP_AMOUNT. One

[bitcoin-dev] A Calculus of Covenants

Sharing below a framework for thinking about covenants. It is most useful for modeling local covenants, that is, covenants where only one coin must be examined, and not multi-coin covenants whereby you could have issues with protocol forking requiring a more powerful stateful prover. It's the

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

> nonsense marketing I'm sure the people who are confused about "blockchain schemes as \"world computers\" and other nonsense marketing" are avid and regular readers of the bitcoin devs mailing list so I offer my sincerest apologies to all members of the intersection of those sets who were

[bitcoin-dev] Pleb.fi/miami2022 Invitation + CTV Meeting #7 postponement

Devs, I warmly invite you to join for pleb.fi/miami2022 if you are interested to participate. It will be April 4th and 5th near miami. The focus of this pleb.fi event will be the ins and outs of building bitcoin stuff in rust with a focus on Sapio and a hackathon. As the CTV Meeting overlaps

[bitcoin-dev] CTV BIP Meeting #6 Notes on Sapio Studio Tutorial

Devs, Tutorial: https://rubin.io/bitcoin/2022/03/22/sapio-studio-btc-dev-mtg-6/ Meeting Logs: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020157.html Summary: The 6th CTV meeting was a Sapio Studio tutorial. Sapio Studio is a Bitcoin Wallet / IDE for playing with Bitcoin

Re: [bitcoin-dev] CTV dramatically improves DLCs

I've created a prototype of this protocol in Sapio for your perusal: https://github.com/sapio-lang/sapio/blob/master/sapio-contrib/src/contracts/derivatives/dlc.rs Feel free to tweak the test and use it as a benchmark, i tested 1 oracle with 100,000 different payouts and saw it take around 13s

Re: [bitcoin-dev] Speedy Trial

Boker tov bitcoin devs, A mechanism of soft-forking against activation exists. What more do you > want? > Agreed -- that should be enough. > Are we supposed to write the code on behalf of this hypothetical group of > users who may or may not exist for them just so that they can have a node >

Re: [bitcoin-dev] Covenants and feebumping

Hi Antoine, I have a few high level thoughts on your post comparing these types of primitive to an explicit soft fork approach: 1) Transaction sponsors *is* a type of covenant. Precisely, it is very similar to an "Impossible Input" covenant in conjunction with a "IUTXO" I defined in my 2017

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

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

[bitcoin-dev] OP_AMOUNT Discussion

Hi Devs, Recently, I've been getting a lot of questions about OP_AMOUNT. It's also come up in the context of "CTV is unsafe because it can't handle differing amounts". Just sharing some preliminary thinking on it: It could come in many variants: OP_PUSHAMOUNT OP_AMOUNTVERIFY OP_PUSHAMOUNTSPLIT

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)

[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] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations

inputs would also make sense as it'd bloat the utxo set and could be > emulated by using the input that is spending it. > > Cheers, > Christian > > On Sat, 5 Mar 2022, 07:33 Anthony Towns via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Fri, M

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

This may be of interest: https://github.com/sapio-lang/sapio/blob/01830132bbbe39c3225e173e099f6e1a0611461c/sapio/examples/subscription.py Basically, a (old, python) sapio contract whereby you can make cancellable subscriptions that are essentially a time based autopay scheme whereby cancellation

Re: [bitcoin-dev] One testnet to rule them all

Signet degrades to a testnet if you make your key OP_TRUE. It's not about needing 21M coins it's about easily getting access to said coins for testing, where it's kinda tricky to get testnet coins. On Sat, Mar 5, 2022, 6:17 PM wrote: > > There's no point to pegging coins that are worthless

Re: [bitcoin-dev] One testnet to rule them all

There's no point to pegging coins that are worthless into a system of also worthless coins, unless you want to test the mechanism of testing pegging. As is, it's hard enough to get people set up on a signet, if they have to run two nodes and then scramble to find testnet coins and then peg them

Re: [bitcoin-dev] bitcoin scripting and lisp

It seems like a decent concept for exploration. AJ, I'd be interested to know what you've been able to build with Chia Lisp and what your experience has been... e.g. what does the Lightning Network look like on Chia? One question that I have had is that it seems like to me that neither

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

On Sat, Mar 5, 2022 at 5:59 AM Anthony Towns wrote: > On Fri, Mar 04, 2022 at 11:21:41PM +0000, Jeremy Rubin via bitcoin-dev > wrote: > > I've seen some discussion of what the Annex can be used for in Bitcoin. > > > https://www.erisian.com.au/meetbot/taproot-bip-review/20

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

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 the annex). I think

[bitcoin-dev] BIP-119 CTV Meeting #4 Notes

Today's meeting was a bit of a different format than usual, the prime focus was on getting CTV Signet up and running and testing out some contracts. In terms of discussion, there was some talk about what the goals of a signet should be, but no conclusions were really reached. It is very good a

Re: [bitcoin-dev] BIP-119 CTV Meeting #4 Draft Agenda for Tuesday February 22nd at 12:00 PT

Hi Devs, As promised, a Sapio Tutorial. In this tutorial we'll walk through how to use the Sapio CLI to generate contracts and play with them on the network. We'll use a congestion control tree because it's very simple! We will walk through this step-by-step during the meeting today. -1. Install

[bitcoin-dev] BIP-119 CTV Meeting #4 Draft Agenda for Tuesday February 22nd at 12:00 PT

Hi All, Apologies for the late posting of the agenda. The 4th CTV meeting will be held tomorrow at 12:00 PT in ##ctv-bip-review in Libera.chat. Tomorrow the conversation will be slightly more tutorial focused. If you have time in advance of the meeting, it might be good to do some of this in

Re: [bitcoin-dev] CTV Signet Parameters

nd running at > https://explorer.ctvsignet.com > > Best, > @0x0ff <https://twitter.com/0x0ff_> > > --- Original Message --- > On Thursday, February 17th, 2022 at 9:58 PM, Jeremy Rubin via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hi devs,

Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts

Morning! > > For the latter case, CPFP would work and already exists. > **Unless** you are doing something complicated and offchain-y and involves > relative locktimes, of course. > > The "usual" design I recommend for Vaults contains something that is like: { CSV CHECKSIG, CHECKSIG} or { CSV

Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts

opt-in or explicit tagging of fee account is a bad design IMO. As pointed out by James O'Beirne in the other email, having an explicit key required means you have to pre-plan suppose you're building a vault meant to distribute funds over many years, do you really want a *specific*

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

-- @JeremyRubin On Sat, Feb 19, 2022 at 1:39 AM Peter Todd wrote: > On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote: > > > As I said, it's a new kind of pinning attack, distinct from other types > > of pinning attack. > > > > I think pinning is

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

This is a fascinating post and I'm still chewing on it. Chiming in with two points: Point 1, note with respect to evictions, revivals, CTV, TLUV: CTV enables 1 person to be evicted in O(log N) or one person to leave in O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

> As I said, it's a new kind of pinning attack, distinct from other types of pinning attack. I think pinning is "formally defined" as sequences of transactions which prevent or make it less likely for you to make any progress (in terms of units of computation proceeding). Something that only

[bitcoin-dev] CTV Signet Parameters

Hi devs, I have been running a CTV signet for around a year and it's seen little use. Early on I had some issues syncing new nodes, but I have verified syncability to this signet using https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-signet-23.0-alpha. Please use this signet! ```

Re: [bitcoin-dev] Thoughts on fee bumping

The difference between sponsors and this issue is more subtle. The issue Suhas raised was with a variant of sponsors trying to address a second criticism, not sponsors itself, which is secure against this. I think I can make this clear by defining a few different properties: Strong Reorgability:

Re: [bitcoin-dev] Thoughts on fee bumping

James, Unfortunately, there are technical reasons for sponsors to not be monotone. Mostly that it requires the maintenance of an additional permanent TX-Index, making Bitcoin's state grow at a much worse rate. Instead, you could introduce a time-bound for inclusion, e.g. 100 blocks. However, this

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

Hi Rusty, Please see my post in the other email thread https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html The differences in this regard are several, and worth understanding beyond "you can iterate CTV". I'd note a few clear examples for showing that "CTV is just

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev > wrote: > > Whether [recursive covenants] is an issue or not precluding this sort > > of design or not, I defer to others. > > For reference, I believe the last time the merits of allowing recursive > covenants w

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

That's not really pinning; painning usually refers to pinning something to the bottom of the mempool whereas these mechanisms make it easier to guarantee that progress can be made on confirming the transactions you're interested in. Often times in these protocols "the call is coming inside the

[bitcoin-dev] CTV Meeting Notes #3

Bitcoin Developers, The Third CTV meeting was held earlier today (Tuesday February 8th, 2022). You can find the meeting log here: https://gnusha.org/ctv-bip-review/2022-02-08.log A best-effort summary: - Not much new to report on the Bounty - Non Interactive Lightning Channel Opens Non

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

Rusty, Note that this sort of design introduces recursive covenants similarly to how I described above. Whether that is an issue or not precluding this sort of design or not, I defer to others. Best, Jeremy On Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev <

Re: [bitcoin-dev] BIP-119 CTV Meeting #3 Draft Agenda for Tuesday February 8th at 12:00 PT

Reminder: This is in ~24 hours. There have been no requests to add content to the agenda. Best, Jeremy -- @JeremyRubin On Wed, Feb 2, 2022 at 12:29 PM Jeremy Rubin wrote: > Bitcoin Developers, > > The 3rd instance of the recurring meeting is scheduled for

Re: [bitcoin-dev] CTV dramatically improves DLCs

I'm not sure what is meant concretely by (5) but I think overall performance is ok here. You will always have 10mins or so to confirm the DLC so you can't be too fussy about performance! I mean that if you think of the CIT points as being the X axis (or independent axes if multivariate) of a

[bitcoin-dev] BIP-119 CTV Meeting #3 Draft Agenda for Tuesday February 8th at 12:00 PT

Bitcoin Developers, The 3rd instance of the recurring meeting is scheduled for Tuesday February 8th at 12:00 PT in channel ##ctv-bip-review in libera.chat IRC server. The meeting should take approximately 2 hours. The topics proposed to be discussed are agendized below. Please review the agenda

[bitcoin-dev] CTV Meeting #2 Summary & Minutes

This meeting was held January 25th, 2022. The meeting logs are available https://gnusha.org/ctv-bip-review/2022-01-25.log Please review the agenda in conjunction with the notes: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019807.html Feel free to make any corrections if

Re: [bitcoin-dev] Why CTV, why now?

I agree this emulation seems sound but also tap out at how the CT stuff works with this type of covenant as well. Happy hacking! On Tue, Feb 1, 2022, 5:29 PM Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Jan 05, 2022 at 02:44:54PM -0800, Jeremy via

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

Perhaps there is some misunderstanding. TXHASH + CSFSV doesn't allow for complex or recursive covenants. Typically CAT is needed, at minimum, to create those sorts of things. TXHASH still amounts to deploying a non-recursive covenant construction. This seems false to me. txhash txhash

Re: [bitcoin-dev] CTV dramatically improves DLCs

Apologies for the double post*, but I just had a follow up idea that's pretty interesting to me. You can make the close portion of a DLC be an "optimistic" execution with a choice of justice scheme. This enables closing a DLC somewhat securely without exposing the oracles on-chain at all.

[bitcoin-dev] BIP Draft: Minimum Viable TXIn Hash

Please see the following draft BIP which should decrease the amount of bytes needed per transaction. This is very much a draft BIP, as the design space for this type of improvement is large. This BIP can be rolled out by a soft fork. Improvements are around 12% for standard one in two out txn,

Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability

I think the catch here is that under STUA (short term use address) there is a strict incentive, you can reduce the transaction fee for these txns. This also fits with the general model that you pay the miners for security. My belief is that when there is a savings benefit to be had large players