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

2022-02-17 Thread ZmnSCPxj via bitcoin-dev
Good morning Dave, > On Mon, 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 >

Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

2022-02-17 Thread ZmnSCPxj via bitcoin-dev
Good morning shymaa, > I just want to add an alarming info to this thread... > > There are at least 5.7m UTXOs≤1000 Sat (~7%),  > 8.04 m ≤1$ (10%),  > 13.5m ≤ 0.0001BTC (17%) > > It seems that bitInfoCharts took my enquiry seriously and added a main link > for dust analysis: >

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

2022-02-17 Thread ZmnSCPxj via bitcoin-dev
`OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY` == In late 2021, `aj` proposed `OP_TAPLEAFUPDATEVERIFY` in order to implement CoinPools and similar constructions. `Jeremy` observed that due to the use of Merkle tree paths, an `OP_TLUV`

[bitcoin-dev] CTV Signet Parameters

2022-02-17 Thread Jeremy Rubin via bitcoin-dev
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

2022-02-17 Thread James O'Beirne via bitcoin-dev
> 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] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-17 Thread Anthony Towns via bitcoin-dev
On Fri, Feb 11, 2022 at 12:12:28PM -0600, digital vagabond via bitcoin-dev wrote: > Imagine a covenant design that was > flexible enough to create an encumbrance like this: a script specifies a > specific key in a multisig controlled by some authority figure (or a branch > in the script that

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

2022-02-17 Thread Russell O'Connor via bitcoin-dev
On Thu, Feb 17, 2022 at 9:27 AM Anthony Towns wrote: > > I guess that's all partly dependent on thinking that, TXHASH isn't > great for tx introspection (especially without CAT) and, (without tx > introspection and decent math opcodes), DLCs already provide all the > interesting oracle behaviour

Re: [bitcoin-dev] Thoughts on fee bumping

2022-02-17 Thread Anthony Towns via bitcoin-dev
On Thu, Feb 10, 2022 at 07:12:16PM -0500, Matt Corallo via bitcoin-dev wrote: > This is where *all* the complexity comes from. If our goal is to "ensure a > bump increases a miner's overall revenue" (thus not wasting relay for > everyone else), then we precisely *do* need > > Special consideration

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

2022-02-17 Thread Anthony Towns via bitcoin-dev
On Mon, Feb 07, 2022 at 09:16:10PM -0500, Russell O'Connor via bitcoin-dev wrote: > > > For more complex interactions, I was imagining combining this TXHASH > > > proposal with CAT and/or rolling SHA256 opcodes. > Indeed, and we really want something that can be programmed at redemption > time.