Re: [bitcoin-dev] CTV dramatically improves DLCs

Lloyd, This is an excellent write up, the idea and benefits are clear. Is it correct that in the case of a 3/5th threshold it is a total 10x * 30x = 300x improvement? Quite impressive. I have a few notes of possible added benefits / features of DLCs with CTV: 1) CTV also enables a "trustless

Re: [bitcoin-dev] [dlc-dev] CTV dramatically improves DLCs

Thibaut, CSFS might have independent benefits, but in this case CTV is not being used in the Oracle part of the DLC, it's being used in the user generated mapping of Oracle result to Transaction Outcome. So it'd only be complimentary if you came up with something CSFS based for the Oracles.

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

I probably need to reset it -- I ran into some issues with the IBD latch bug IIRC and had difficulty producing new blocks. I sent funds as a manual faucet to at least one person... not aware of anyone else finding use for the signet. In part this is due to the fact that in order to run a signet,

Re: [bitcoin-dev] Improving RBF Policy

Gloria, This is a brilliant post! Great job systematizing many of the issues. Quite a lot to chew on & I hope other readers of this list digest the post fully. Three things come to mind as partial responses: under: - **DoS Protection**: Limit two types of DoS attacks on the node's > mempool:

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

Hi Russell, Thanks for this email, it's great to see this approach described. A few preliminary notes of feedback: 1) a Verify approach can be made to work for OP_TXHASH (even with CTV as-is) E.g., suppose a semantic added for a single byte stack[-1] sighash flag to read the hash at stack[-2],

[bitcoin-dev] BIP-119 CTV Meeting #2 Agenda for Tuesday January 25th at 12:00 PT

Bitcoin Developers, The 2nd instance of the recurring meeting is scheduled for Tuesday January 25th 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

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

ck as transaction X (or maybe transactions LIST)". This could be >>>>> named SIGHASH_EXTERNAL. Doing this would be a lot more similar to other >>>>> bitcoin transactions, and no special account would need to be created. Any >>>>> transaction could

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

There's a potential mild bytes savings, but the bigger deal is that the >>>> API should be much less vulnerable to pinning issues, fix dust leakage for >>>> eltoo like protocols, and just generally allow protocol designs to be fully >>>> abstracted from pay

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

n> >> >> >> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud >> wrote: >> >>> Do you have any back-of-the-napkin math on quantifying how much this >>> would improve the situation vs existing methods (eg cpfp)? >>> >>> >>> >>

Re: [bitcoin-dev] CTV BIP review

Thanks for the detailed review. I'll withhold comment around activation logic and leave that for others to discuss. w.r.t. the language cleanups I'll make a PR that (I hope) clears up the small nits later today or tomorrow. Some of it's kind of annoying because the legal definition of covenant

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

fying how much this would > improve the situation vs existing methods (eg cpfp)? > > > > On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Happy new years devs, >> >> I figured I would share some th

[bitcoin-dev] SASE Invoices

Devs, I was recently speaking with Casey R about some of the infrastructural problems with addresses and felt it would be worth summarizing some notes from that conversation for y'all to consider more broadly. Currently, when you generate (e.g., a Taproot address): - The key may or may not be a

Re: [bitcoin-dev] bip39

This is a good point, but can be addressed by having a non-void whitespace character (e.g., win x estate). changing BIP39 would be hard since software expects a standard list; it would also be possible to rejection sample for seeds that do not contain these pairs, unclear how much entropy would

Re: [bitcoin-dev] BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c)

High level feedback: It would be nice if this field was not distinct from BIP32 derivation descriptors so that you could have a single representation for the Extended Key that doesn't need some additional field only in PSBT. If I understood correctly, and this is just an arbitrary hash being

Re: [bitcoin-dev] Bitcoin Legal Defense Fund

If I understand the intent of your message correctly, that's unfortunately not how the law works. If there is a case that is precedent setting, whether it directly involves bitcoin or not, a bitcoin focused legal fund might want to either offer representation or file an amicus brief to guide the

[bitcoin-dev] Documenting the lifetime of a transaction during mempool congestion from the perspective of a rational user

Devs, This email is primarily about existing wallet behaviors and user preferences, and not about CTV. However, towards the end I will describe the relevance of CTV, but the email is worth reading even if you have no interest in CTV as the problems described exist today. One point of confusion

Re: [bitcoin-dev] Bitcoin Legal Defense Fund

A further point -- were it to be a norm if a contributor to something like this be denied their full capacity for "free speech" by social convention, it would either encourage anonymous funding (less accountable) or would disincentivize creating such initiatives in the future. Both of those

Re: [bitcoin-dev] OP_PUSH_KEY_* & BIP-118 0x01 Pun

Note: BIP-118 as-is enables something similar to OP_PUSH_KEY_INTERNAL_TAGGED via the following script fragment: witness: program: DUP 0x01 CHECKSIG SWAP DUP TOALTSTACK CHECKSIG FROMALTSTACK It's unclear how useful this might be, since the signature already covers the transaction. --

[bitcoin-dev] OP_PUSH_KEY_* & BIP-118 0x01 Pun

Hi Devs, Two small transaction introspection opcodes that are worth considering are OP_PUSH_KEY_INTERNAL or OP_PUSH_KEY_EXTERNAL which can return the taproot key for the current input. While the internal key could be included in the tree already, and this is just a performance improvement, the

[bitcoin-dev] Summary of BIP-119 Meeting #1 Tuesday January 11th

Hi Devs, Below you'll find my summary of the BIP-119 Meeting held earlier today. Overall the meeting was pleasant although fast paced. Thank you all for attending and participating. I look forward to seeing (more of) you next time! Meeting notes available here:

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

Please see the following bips PRs which are follow ups to the concrete actionables raised by Peter. Thanks for bringing these up, it certainly improves the reviewability of the BIP. https://github.com/bitcoin/bips/pull/1271 https://github.com/bitcoin/bips/pull/1272 -- @JeremyRubin

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

Hi Peter, Thank you for your review and feedback. Apologies for the difficulties in reviewing. The branch linked from the BIP is not the latest, the branch in the PR is what should be considered https://github.com/bitcoin/bitcoin/pull/21702 for review and has more thorough well documented tests

[bitcoin-dev] BIP-119 Meeting Reminder and Prelim Agenda

Hi all, As a reminder the first meeting for CTV will be this Tuesday at 12:00PM PT. Based on feedback, I have included a preliminary agenda and time allocation for the meeting at the end of this email. The main part of the meeting will run for 1.5 hours, and will be followed by a post meeting

[bitcoin-dev] Why CTV, why now? Was RE: Stumbling into a contentious soft fork activation attempt

Hi Devs, There's a lot of noise in the other thread and it's hard to parse out what merits a response or not without getting into a messy quagmire, so I figured a separate email with high level points was the best way to respond. Covenants are an important part of Bitcoin's future, not for

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

Happy new years devs, I figured I would share some thoughts for conceptual review that have been bouncing around my head as an opportunity to clean up the fee paying semantics in bitcoin "for good". The design space is very wide on the approach I'll share, so below is just a sketch of how it

[bitcoin-dev] BIP-119 Deployment and Review Workshops

BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALNAME:BIP-119 Events X-WR-TIMEZONE:UTC BEGIN:VTIMEZONE TZID:America/Los_Angeles X-LIC-LOCATION:America/Los_Angeles BEGIN:DAYLIGHT TZOFFSETFROM:-0800 TZOFFSETTO:-0700 TZNAME:PDT

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Derivatives and Options

On Fri, Dec 24, 2021, 8:42 AM Prayank wrote: > Hi Jeremy, > > > Wheres the info come from? Well, multiple places. We could get it from a > third party (maybe using an attestation chain of some sort?), or there are > certain ways it could be self-referential (like for powswap >

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Autonomous Organizations (DAOs) Will Save Bitcoin

Oscar, Sapio is essentially a 'Compiler toolchain' you run it once and then send money to the contract. This is like Solidity in Ethereum. Sapio Studio is a GUI for interacting with the outputs of a Sapio contract. This is like Metamask/web3.js in Ethereum. It's really not comparable to

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

> If you introduce signing into mining, then you will have cases, where > someone is powerful enough to produce blocks, but cannot, because signing > is needed. Then, your consensus is no longer "the heaviest chain", but "the > heaviest signed chain". That means, your computing power is no longer

[bitcoin-dev] [Bitcoin Advent Calendar] History and Future of Sapio

Hi devs, This post details a little on the origins of Sapio as well as features that are in development this year (other than bugfixes). https://rubin.io/bitcoin/2021/12/23/advent-26/ cheers, Jeremy -- @JeremyRubin

[bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Autonomous Organizations (DAOs) Will Save Bitcoin

Hi Devs, Enjoy! https://rubin.io/bitcoin/2021/12/22/advent-25/ I'm really excited about opportunities for capital formation to happen natively in Bitcoin. This is actually a really big deal and something (I think) to pay close attention to. This is basically like running a little company with

[bitcoin-dev] [Bitcoin Advent Calendar] POWSWAP: Oracle Free Bitcoin Hashrate Derivatives

Hi devs, Today's post details how to make fully trustless hashrate derivative contracts that can be embedded on-chain, inside of channels, options, or inside of DCFMPs. These contracts can be used today without CTV, but they obviously get better with CTV :) enjoy:

[bitcoin-dev] [Bitcoin Advent Calendar] Derivatives and Options

Hi Devs, Today's post is on building options/derivatives in Sapio! https://rubin.io/bitcoin/2021/12/20/advent-23 Enjoy! Cheers, Jeremy -- @JeremyRubin ___ bitcoin-dev mailing

[bitcoin-dev] [Bitcoin Advent Calendar] NFTs Part Two: Auctions, Royalties, Mints, Generative, Game Items

Hi Devs! More on NFTs today! Code demos of dutch auctions of NFTs + royalties, and then discussion of a few other concepts I'm excited about. https://rubin.io/bitcoin/2021/12/19/advent-22/ Particularly novel is the combination of attestation chains, lightning invoices, and NFTs to create

[bitcoin-dev] [Bitcoin Advent Calendar] Packaging Sapio Applications

hi devs, today's topic is packaging Sapio applications. maybe a bit more annoying than usual, but important. https://rubin.io/bitcoin/2021/12/18/advent-21/ I think WASM is really really cool! It's definitely been very helpful for Sapio. It'd be kinda neat if at some point software like Bitcoin

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

Small idea: ease into getting rid of full-rbf by keeping the flag working, but make enforcement of non-replaceability something that happens n seconds after first seen. this reduces the ability to partition the mempools by broadcasting irreplaceable conflicts all at once, and slowly eases

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains

Yep, these are great points. There is no way to punish signing the wrong thing directly, just not changing your answers without risk to funds. One of the interesting things is that upon a single equivocation you get unbounded equivocation by 3rd parties, e.g., you can completely rewrite the

[bitcoin-dev] Globally Broadcasting Workshares to Improve Finality Heuristics

An interesting concept occurred to me today while chatting with Nic Carter. If we set Bitcoin Core up to gossip headers for work shares (e.g., expected 500 headers per block would have 20kb overhead, assuming we don't need to send the prev hash) we'd be able to have more accurate finality

[bitcoin-dev] [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains

Today's post is pretty cool: it details how covenants like CTV can be used to improve on-chain bitcoin signing oracles by solving the timeout/rollover issue and solving the miner/oracle collusion issue on punishment. This issue is similar to the Blockstream Liquid Custody Federation rollover bug

[bitcoin-dev] [Bitcoin Advent Calendar] Part One: Implementing NFTs in Sapio

I know NFTs are controversial, but here's my take on them in Sapio: https://rubin.io/bitcoin/2021/12/16/advent-19/ If you don't like NFTs, don't worry: the results and techniques are entirely generalizable here and can apply to many other types of things that aren't stupid JPGs. E.g., - If you

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

high level response: including a small number of block headers (10?) directly as op_return metadata (or something) doesn't have that high overhead necessarily, but could be super effective at helping miners participate with lower hashrate. the reason to include this as on-chain data is so that

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

I could add a comparison to p2pool if you want, but bear in mind this is a blog post designed to introduce a complex topic to a wide audience, not a literature review of all possible designs and prior art. In particular, while P2Pool and DCFMP share a goal (decentralize mining), the approaches to

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

Hi Billy! Thanks for your response. Some replies inline: On Wed, Dec 15, 2021 at 10:01 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Looks like an interesting proposal, but it doesn't seem to quite match the > goals you mentioned. As you do mention, this

[bitcoin-dev] [Bitcoin Advent Calendar] Sapio Studio Payment Pool Walthrough

Hi Devs, Today's post is showing off how the Sapio Studio, the GUI smart contract composer for Sapio, functions. https://rubin.io/bitcoin/2021/12/15/advent-18/ In contrast to other posts this is mostly pictures. This is a part of the project that could definitely use some development assistance

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

I've received some confused messages that whatever I was replying to didn't come through, I've reproduced Bob's e-mail below that I was responding to for context: *This, quite simply, is not a "pool". A pool is by definition a tool to reduceprofit variance by miners by

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

Bitcoin didn't invent the concept of pooling: https://en.wikipedia.org/wiki/Pooling_(resource_management). This is a Bitcoin Mining Pool, although it may not be your favorite kind, which is fixated on specific properties of computing contributions before finding a block. Pooling is just a general

[bitcoin-dev] [Bitcoin Advent Calendar] A Defense of Having Fun (and maybe staying poor)

Hi Devs, Today's post is a little more philosophical and less technical. Based on the private feedback I received (from >1 persons, perhaps surprisingly) I'll continue to syndicate the remaining posts to this list. Here it is: https://rubin.io/bitcoin/2021/12/14/advent-17/ To having a little

[bitcoin-dev] [Bitcoin Advent Calendar] Composability in Sapio Contracts

Devs, Here's today's post: https://rubin.io/bitcoin/2021/12/13/advent-16/ It covers how you can use Sapio modules composably. This is an active area of research for the Sapio platform, so definitely welcome and appreciate ideas and feedback. One area I'm particularly happy with but also unhappy

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

Hey there! Thanks for your response! One of the reasons to pick a longer window of, say, a couple difficulty periods would be that you can make participation in the pool hedge you against hashrate changes. You're absolutely spot on to think about the impact of pooling w.r.t. variance when fees

[bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

Howdy, welcome to day 15! Today's post covers a form of a mining pool that can be operated as sort of a map-reduce over blocks without any "infrastructure". https://rubin.io/bitcoin/2021/12/12/advent-15/ There's still some really open-ended questions (perhaps for y'all to consider) around how

[bitcoin-dev] [Bitcoin Advent Calendar] Payment Channels in a CTV+Sapio World

hola devs, This post details more formally a basic version of payment channels built on top of CTV/Sapio and the implications of having non-interactive channel creation. https://rubin.io/bitcoin/2021/12/11/advent-14/ I'm personally incredibly bullish on where this concept can go since it would

[bitcoin-dev] [Bitcoin Advent Calendar] Payment Pools/ Coin Pools

This post showcases building payment pools / coin pools* in Sapio! https://rubin.io/bitcoin/2021/12/10/advent-13/ There will be many more posts in the series that will take this concept a lot further and showcase some more advanced things that can be built. I think that payment pools are

[bitcoin-dev] [Bitcoin Advent Calendar]: Congestion Control

Today's post is a follow up to some older content about congestion control & CTV. It's written (as with the rest of the series) to be a bit more approachable than technical, but there are code samples in Sapio of constructing a payout tree. today's post:

[bitcoin-dev] [Bitcoin Advent Calendar] Inheritance Schemes

Devs, For today's post, something near and dear to our hearts: giving our sats to our loved ones after we kick the bucket. see: https://rubin.io/bitcoin/2021/12/08/advent-11/ Some interesting primitives, hopefully enough to spark a discussion around different inheritance schemes that might be

Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit

IMO this is not a big problem. The problem is not if a 0 value ever enters the mempool, it's if it is never spent. And even if C2/P1 goes in, C1 still can be spent. In fact, it increases it's feerate with P1's confirmation so it's somewhat likely it would go in. C2 further has to be pretty

Re: [bitcoin-dev] Take 2: Removing the Dust Limit

Bastien, The issue is that with Decker Channels you either use SIGHASH_ALL / APO and don't allow adding outs (this protects against certain RBF pinning on the root with bloated wtxid data) and have anchor outputs or you do allow them and then are RBF pinnable (but can have change). Assuming you

[bitcoin-dev] Take 2: Removing the Dust Limit

Bitcoin Devs (+cc lightning-dev), Earlier this year I proposed allowing 0 value outputs and that was shot down for various reasons, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html I think that there can be a simple carve out now that package relay is being

Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

-- @JeremyRubin Hi! On Tue, Dec 7, 2021 at 4:33 PM ZmnSCPxj wrote: > Good morning Jeremy, > > > > > Here's the day 6 post: https://rubin.io/bitcoin/2021/12/03/advent-6/, > the topic is why smart contracts (in extended form)

[bitcoin-dev] [Bitcoin Advent Calendar] Contract Primitives and Upgrades to Bitcoin

This post is a mini high level SoK covering basic details of a number of different new proposed primitives that folks might find useful -- I think there's less to discuss around this post, since it is at a higher level and the parts contained here could be discussed separately. If something isn't

[bitcoin-dev] [Bitcoin Advent Calendar] Vaults

Last one for today -- sorry for the overload, I had meant to post as the series kicked off... This post covers building various vaults/better cold storage using sapio https://rubin.io/bitcoin/2021/12/07/advent-10/. In an earlier post I motivated why self-custody is so critical (see

[bitcoin-dev] [Bitcoin Advent Calendar] Sapio Primer

This post covers a basic intro to Sapio and links to more complete docs. https://rubin.io/bitcoin/2021/12/06/advent-9/ I've previously shared Sapio on this list, and there's been a lot of progress since then! I think Sapio is a fantastic system to express Bitcoin ideas in, even if you don't want

[bitcoin-dev] [Bitcoin Advent Calendar] Review of Smart Contract Concepts

This post covers some high-level smart contract concepts that different opcodes or proposals could have (or not). https://rubin.io/bitcoin/2021/12/04/advent-7/ Interested to hear about other properties that you think are relevant! Best, Jeremy -- @JeremyRubin

[bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

Hi! Over the next month I'm doing a one-a-day blog post series till Christmas, and I think some of the posts might be appropriate for discussion here. Unfortunately I forgot to start the calendar series syndicated here too... The first few posts are less bitcoin development related and

Re: [bitcoin-dev] On the regularity of soft forks

*> ... in this post I will argue against frequent soft forks with a single or minimal* *> set of features and instead argue for infrequent soft forks with batches* *> of features.* I think this type of development has been discussed in the past and has been rejected. from: Matt Corallo's post:

Re: [bitcoin-dev] [Lightning-dev] Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin

John let me know that he's posted some responses in his Github repo https://github.com/JohnLaw2/btc-iids probably easiest to respond to him via e.g. a github issue or something. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

[bitcoin-dev] Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin

Bitcoin & LN Devs, The below is a message that was shared to me by an anon account on Telegram (nym: John Law). You can chat with them directly in the https://t.me/op_ctv or https://t.me/bips_activation group. I'm reproducing it here at their request as they were unsure of how to post to the

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

I'm a bit skeptical of the safety of the control byte. Have you considered the following issues? > The low bit of C indicates the parity of X; if it's 0, X has even y, > if it's 1, X has odd y. > > The next bit of C indicates whether the current script is dropped from > the merkle path, if it's

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

I like this proposal, I think it has interesting use cases! I'm quick to charitably Matt's comment, "I’ve been saying we need more covenants research and proposals before we move forward with one", as before we move forward with *any.* I don't think that these efforts are rival -- different

Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect

ally start to > discourage the usage. Otherwise, by introducing new discouragement waivers, > e.g not rejecting the usage of the top 8 bits, I think we're moving away > from the policy design principle we're trying to establish (separation of > mempool policies signaling from co

Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters

If you make the to be reorged flag 2 bits, 1 bit can mark final block and the other can mark to be reorged. That way the nodes opting into reorg can see the reorg and ignore the final blocks (until a certain time? Or until it's via a reorg?), and the nodes wanting not to see reorgs get continuous

Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect

uld be weird/bad to change the semantic in transaction version 3. -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Sun, Sep 5, 2021 at 7:36 PM David A. Harding wrote: > On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev

Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect

In working on resolving this issue, one issue that has come up is what sequence values get used by wallet implementations? E.g., in Bitcoin Core a script test says BIP125_SEQUENCE_NUMBER = 0xfffd # Sequence number that is rbf-opt-in (BIP 125) and csv-opt-out (BIP 68) Are any other numbers

[bitcoin-dev] Note on Sequence Lock Upgrades Defect

Hi Bitcoin Devs, I recently noticed a flaw in the Sequence lock implementation with respect to upgradability. It might be the case that this is protected against by some transaction level policy (didn't see any in policy.cpp, but if not, I've put up a blogpost explaining the defect and patching

Re: [bitcoin-dev] Is there a tool like Ethereum EVM at present for Bitcoin script?

Will update those soon / in November. Sapio needs the rust Bitcoin taproot ecosystem to mature, as well as a spec for miniscript taproot (altho we can kinda monkey patch one in without it). To be honest, I had some technical difficulties with getting Libera to work and I gave up... But perhaps I

Re: [bitcoin-dev] Is there a tool like Ethereum EVM at present for Bitcoin script?

This has actually never been true (Sapio assumes extensions). If the extensions are not present, you can stub them out with a signing federation instead, configurable as flags, and you can also write many contracts that do not use the ctv based components at all. The protocol for emulation is a

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

one interesting point that came up at the bitdevs in austin today that favors remove that i believe is new to this discussion (it was new to me): the argument can be reduced to: - dust limit is a per-node relay policy. - it is rational for miners to mine dust outputs given their cost of

Re: [bitcoin-dev] src/httprpc.cpp InterruptHTTPRPC

This is probably best to open as an issue in github! -- @JeremyRubin On Thu, Aug 12, 2021 at 11:03 AM Ali Sherief via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I am using Bitcoin Core's HTTP RPC server as a

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

You might be interested in https://eprint.iacr.org/2017/1066.pdf which claims that you can make CT computationally hiding and binding, see section 4.6. with respect to utreexo, you might review https://github.com/mit-dci/utreexo/discussions/249?sort=new which discusses tradeoffs between different

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

some additional answers/clarifications > Question for Jeremy: would you also allow zero-value outputs? Or would > you just move the dust limit down to a fixed 1-sat? > I would remove it entirely -- i don't think there's a difference between the two realistically. > > Allowing 0-value or

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

Under no circumstances do I think we should *increase* the dust limit. That would have a mildly confiscatory effect on current Lightning Channel operators, among others. Generally, the UTXO set will grow. We should work to accommodate the worst case scenario under current consensus rules. I think

[bitcoin-dev] Removing the Dust Limit

We should remove the dust limit from Bitcoin. Five reasons: 1) it's not our business what outputs people want to create 2) dust outputs can be used in various authentication/delegation smart contracts 3) dust sized htlcs in lightning (

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

High level feedback: you should spec out the opcodes as separate pieces of functionality as it sounds like OP_CD is really 3 or 4 opcodes in one (e.g., amounts to outputs, output addresses, something with fees). One major drawback of your approach is that all transactions are twice as large as

Re: [bitcoin-dev] [Lightning-dev] Eltoo / Anyprevout & Baked in Sequences

On Sun, Jul 11, 2021 at 10:01 PM Anthony Towns wrote: > On Thu, Jul 08, 2021 at 08:48:14AM -0700, Jeremy wrote: > > This would disallow using a relative locktime and an absolute > locktime > > for the same input. I don't think I've seen a use case for that so > far, > > but ruling it

Re: [bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]

I thought about this, but at the time of writing I couldn't come up with something I thought was substantially better. I spent a few more cycles thinking on it -- you can definitely do better. It's not clear how much better Winternitz might be, or if it would be secure in this context? Here's some

Re: [bitcoin-dev] Taproot Fields for PSBT

Suggestion: It should be allowed that different keys can specify different sighash flags. As an example, if chaperone signatures were desired with anyprevout, it would be required to specify that the anyprevout key sign with APO and the chaperone sign with ALL. As another example, Sapio emulator

Re: [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences

> > This would disallow using a relative locktime and an absolute locktime > for the same input. I don't think I've seen a use case for that so far, > but ruling it out seems suboptimal. I think you meant disallowing a relative locktime and a sequence locktime? I agree it is suboptimal. What

[bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences

I made a comment on https://github.com/bitcoin/bips/pull/943#issuecomment-876034559 but it occurred to me it is more ML appropriate. In general, one thing that strikes me is that when anyprevout is used for eltoo you're generally doing a script like: ``` IF 10 CSV DROP 1::musigkey(As,Bs)

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

Hah -- ZmnSCPxj that post's a doozy -- but it more or less makes sense the argument you're making in favor of permitting recursion at the transaction level. One part that's less clear is if you can make a case against being recursive in Script fragments themselves -- ignoring bitcoin script for

[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]

Dear Bitcoin Devs, As mentioned previously, OP_CAT (or similar operation) can be used to make Bitcoin "quantum safe" by signing an EC signature. This should work in both Segwit V0 and Tapscript, although you have to use HASH160 for it to fit in Segwit V0. See [my

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

I don't think Elements engineering decisions or management timelines should have any bearing on what Bitcoin adopts, beyond learning what works/doesn't. Same as litecoin, dogecoin, or bitcoin cash :) With my understanding of elements it makes sense that you wouldn't want to break compatibility

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

heh -- I pointed out these evil multisig covenants in 2015 :) https://medium.com/@jeremyrubin/regulating-bitcoin-by-mining-the-regulator-miner-attack-c8fd51185b78 I'm relatively unconcerned by it except to the extent that mining centralizes to the point of censoring other traffic. Overall, I

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

Re-threading Sanket's comment on split R value: I also am in general support of the `OP_CHECKSIGFROMSTACK` opcode. We would > need to update the suggestion to BIP340, and add it to sigops budget. I > have no strong preference for splitting R and s values or variable-length > messages. > Back to

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

> > Do you have concerns about sophisticated covenants, and if so, would you > mind describing them? Personally, not in particular worried about arbitrary covenants as I think that: 1 validation costs can be kept in check; 2 you're free to burn your coins it you want to. I *do* care that when

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound to the txdata? When might you use this? And yes -- "Add OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY to follow the semantics from bip340-342 when witness program is v1." is a bit light on detail for what the BIP

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

tes. > > I think this design we are aiming for would be perfectly suited for > Bitcoin as well. > > On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Li

[bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed) specification for "CheckDataSig", more or less the same thing as CHECKSIGFROMSTACK https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md. In contrast to Element's implementation, it does not have

[bitcoin-dev] Templates, Eltoo, and Covenants, Oh My!

Dear Bitcoin Devs, I recently put a blog post up which is of interest for this list. Post available here: https://rubin.io/blog/2021/07/02/covenants/ (text reproduced below for archives). The main technical points of interest for this list are: 1) There's a similar protocol to Eltoo built with

Re: [bitcoin-dev] CheckSigFromStack for Arithmetic Values

Yep -- sorry for the confusing notation but seems like you got it. C++ templates have this issue too btw :) One cool thing is that if you have op_add for arbitrary width integers or op_cat you can also make a quantum proof signature by signing the signature made with checksig with the lamport.

[bitcoin-dev] CheckSigFromStack for Arithmetic Values

Dear Bitcoin Devs, It recently occurred to me that it's possible to do a lamport signature in script for arithmetic values by using a binary expanded representation. There are some applications that might benefit from this and I don't recall seeing it discussed elsewhere, but would be happy for a

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

If the parties trust each other, rbf is still opt-in. Just don't do it? On Sat, Jun 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > services providers are offering zero-conf channels, where you can start > to spend instantly [0]. I believe

  1   2   3   >