Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script

On Sat, Oct 28, 2023 at 12:51 AM Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > But AFAICT there are multiple perfectly reasonable variants of vaults, > too. One would be: > > 1. master key can do anything > 2. OR normal key can send back to vault addr without

Re: [bitcoin-dev] Proposed BIP for OP_CAT

I have to admit - I'm somewhat baffled at the enthusiasm for a "just CAT" softfork, since I can't see that it would achieve much. It's indicative to me that there isn't a compelling example to date that (i) actually has working code and (ii) only relies upon CAT. I'm not averse to CAT, just

Re: [bitcoin-dev] BIP for OP_VAULT

I'm glad to see that Greg and AJ are forming a habit of hammering this proposal into shape. Nice work fellas. To summarize: What Greg is proposing above is to in essence TLUV-ify this proposal. I.e. instead of relying on hashed commitments and recursive script execution (e.g. + later

[bitcoin-dev] BIP for OP_VAULT

Since the last related correspondence on this list [0], a number of improvements have been made to the OP_VAULT draft [1]: * There is no longer a hard dependence on package relay/ephemeral anchors for fee management. When using "authorized recovery," all vault-related transactions can be

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

Andrew, thanks for taking the time. > It seems like this proposal will encourage address reuse for vaults, > at least in some parts. It seems like it would not be difficult to > ensure that each vault address was unique through the use of key > derivation. I think it's worth stepping back and

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

> I don't see in the write up how a node verifies that the destination > of a spend using an OP_VAULT output uses an appropriate OP_UNVAULT > script. It's probably quicker for you to just read through the implementation that I reference in the last section of the paper.

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

I've implemented three changes based on suggestions from Greg Sanders and AJ Towns. I've segmented the changes into commits that should be reasonable to follow, even though I'll probably rearrange the commit structure later on. 1. Greg's suggestion: OP_UNVAULT outputs can now live behind

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

Thanks for the thoughtful reply AJ. > I don't think that makes sense? With a general scheme, you'd only be > bloating the witness data (perhaps including the witness script) not > the scriptPubKey? Sorry, sloppy language on my part. To be charitable, I'm talking about the "figurative sPK,"

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

Forwarding in some conceptual feedback from the pull request. >From ariard: > I've few open questions, like if the recovery path should be committed with a signature rather than protected by a simple scriptpubkey preimage. That's something I've wondered about too. I have to ruminate on AJ's

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

Greg explained his suggestion to me off-list, and I think it's a good one. To summarize, consider the normal "output flow" of an expected vault use: (i) output to be vaulted => (ii) OP_VAULT output => (iii) OP_UNVAULT "trigger" output => (iv) final output In my existing draft

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

oS, you have >> UTXOs that commit to multiple vault paths that have tweaked recovery >> destinations or something, or maybe it really is the right move to say that >> if recovery is triggered, you probably do want it for all of your inflight >> unvaultings. >

[bitcoin-dev] OP_VAULT: a new vault proposal

For the last few years, I've been interested in vaults as a way to substantially derisk custodying Bitcoin, both at personal and commercial scales. Instead of abating with familiarity, as enthusiasm sometimes does, my conviction that vaults are an almost necessary part of bitcoin's viability has

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

I'm also very happy to see this proposal, since it gets us closer to having a mechanism that allows the contribution to feerate in an "unauthenticated" way, which seems to be a very helpful feature for vaults and other contracting protocols. One possible advantage of the sponsors interface -- and

[bitcoin-dev] More uses for CTV

Over the past few months there have been a few potential uses of OP_CHECKTEMPLATEVERIFY (BIP-119) (https://github.com/bitcoin/bitcoin/pull/21702) that I've found interesting. # Congestion control redux When I first heard of CTV, a presentation Jeremy did at Chaincode back in 2018 or '19, he

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

> The enumeration of covenants uses here excludes vaulting, > which I see as far and away the highest utility use for covenants Apologies for the double post, but I need to caveat this. To be more accurate, I see "coin pools" as the most potentially valuable use of covenants, since we need to

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

> APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to > certain usecases (respectively: Eltoo, congestion control, and > joinpools) The enumeration of covenants uses here excludes vaulting, which I see as far and away the highest utility use for covenants given that it allows

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

> There are at least three or four separate covenants designs that have > been posted to this list, and I don't see why we're even remotely > talking about a specific one as something to move forward with at > this point. To my knowledge none of these other proposals (drafts, really) have actual

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

Hey Antoine, Thanks for taking a look at the repo. > I believe it's reasonable to expect bugs to slip in affecting the > output amount or relative-timelock setting correctness I don't really see the vaults case as any different from other sufficiently involved uses of bitcoin script - I don't

[bitcoin-dev] CTV vaults in the wild

A few months ago, AJ wrote[0] > I'm not really convinced CTV is ready to start trying to deploy > on mainnet even in the next six months; I'd much rather see some real > third-party experimentation *somewhere* public first In the spirit of real third-party experimentation *somewhere* in public,

Re: [bitcoin-dev] Thoughts on fee bumping

> Is it really true that miners do/should care about that? De facto, any miner running an unmodified version of bitcoind doesn't care about anything aside from ancestor fee rate, given that the BlockAssembler as-written orders transactions for inclusion by descending ancestor fee-rate and then

Re: [bitcoin-dev] Thoughts on fee bumping

> What do you mean by monotone in the context of sponsor transactions? I take this to mean that the validity of a sponsor txn is "monotonically" true at any point after the inclusion of the sponsored txn in a block. > And when you say tx-index, do you mean an index for looking up a > transaction

Re: [bitcoin-dev] Thoughts on fee bumping

Thanks for your thoughtful reply Antoine. > In a distributed system such as the Bitcoin p2p network, you might > have transaction A and transaction B broadcast at the same time and > your peer topology might fluctuate between original send and > broadcast of the diff, you don't know who's seen

Re: [bitcoin-dev] Thoughts on fee bumping

> This entirely misses the network cost. Yes, sure, we can send > "diffs", but if you send enough diffs eventually you send a lot of data. The whole point of that section of the email was to consider the network cost. There are many cases for which transmitting a supplementary 1-in-1-out

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

I don't oppose recursive covenants per se, but in prior posts I have expressed uncertainty about proposals that enable more "featureful" covenants by adding more kinds of computation into bitcoin script. Not that anyone here is necessarily saying otherwise, but I am very interested in limiting

Re: [bitcoin-dev] Thoughts on fee bumping

> It's not that simple. As a miner, if i have less than 1vMB of transactions in my mempool. I don't want a 10sats/vb transaction paying 10sats by a 100sats/vb transaction paying only 1sats. I don't understand why the "<1vMB in the mempool" case is even worth consideration because the

[bitcoin-dev] Thoughts on fee bumping

There's been much talk about fee-bumping lately, and for good reason - dynamic fee management is going to be a central part of bitcoin use as the mempool fills up (lord willing) and right now fee-bumping is fraught with difficulty and pinning peril. Gloria's recent post on the topic[0] was very

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

> Technical debt isn't a measure of weight of transactions. Sorry, my original sentence was a little unclear. I meant to say that the notion that CTV is just a subpar waypoint en route to a more general covenant system may not be accurate if it is a more efficient way (in terms of

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

> I don't think implementing a CTV opcode that we expect to largely be obsoleted by a TXHASH at a later date is yielding good value from a soft fork process. This presumes the eventual adoption of TXHASH (or something like it). You're presenting a novel idea that, as far as I know, hasn't had

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

ACK for Kalle. On Mon, Apr 26, 2021, 09:55 Sjors Provoost via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > ACK for adding Kalle. > > Recent drama aside, having a single editor is not ideal. There's currently > 110 open pull requests to the BIPs repo. > > - Sjors > > > Op 23 apr.

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

Good morning all, Over the past weeks I've had a number of conversations with a few frequent contributors about this idea. I've condensed these discussions into a proposal document which you can view here: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal The document is

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

I recommend that anyone following this thread read through the recent IRC exchange between Greg Maxwell and Luke Dashjr: http://www.erisian.com.au/bitcoin-core-dev/log-2019-04-04.html The conversation starts on line 205 at

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

ion. > > /jonas > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012478.html > > > Am 02.04.2019 um 22:43 schrieb James O'Beirne via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org>: > > > > Hi, > &

[bitcoin-dev] assumeutxo and UTXO snapshots

Hi, I'd like to discuss assumeutxo, which is an appealing and simple optimization in the spirit of assumevalid[0]. # Motivation To start a fully validating bitcoin client from scratch, that client currently needs to perform an initial block download. To the surprise of no one, IBD takes a

Re: [bitcoin-dev] The new obfuscation patch & GetStats

Hey, Daniel. Patch author here. Thanks for the diligence; I think this indeed may be an oversight, though I'm going to need to look into a bit more thoroughly at home. Curious that it didn't fail any of the automated tests. Correct me if I'm wrong, but the only actual invocation of that method