[bitcoin-dev] Call for Proposals for Scaling Bitcoin Hong Kong

The second Scaling Bitcoin Workshop will take place December 6th-7th at the Cyberport in Hong Kong. We are accepting technical proposals for improving Bitcoin performance including designs, experimental results, and comparisons against other proposals. The goals are twofold: 1) to present

[bitcoin-dev] 1 Year bitcoin-dev Moderation Review

Hi bitcoin-dev, I'm well aware that discussion of moderation on bitcoin-dev is discouraged*. However, I think that we should, as a year of moderation approaches, discuss openly as a community what the impact of such policy has been. Making such a post now is timely given that people will have the

Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY

I think ​the following implementation may be advantageous. It uses the same number of opcodes, without OP_CAT. Avoiding use of OP_CAT is still desirable as I think it will be difficult to agree on semantics for OP_CAT (given necessary measures to prevent memory abuse) than for OP_LEFT. Another

Re: [bitcoin-dev] Script Abuse Potential?

added by Satoshi >> <https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-8458adcedc17d046942185cb709ff5c3R425> >> on the famous August 15, 2010 "misc" commit, at the same time that OP_CAT >> was disabled. >> The previous limit was 5000 bytes.

Re: [bitcoin-dev] Script Abuse Potential?

It is an unfortunate script, but can't actually ​do that much ​ it seems​ . The MAX_SCRIPT_ELEMENT_SIZE = 520 Bytes. ​ Thus, it would seem the worst you could do with this would be to (1-520*2)*520*2 bytes ~=~ 10 MB. ​Much more concerning would be the op_dup/op_cat style bug, which under a

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

I think it's probably safer to have a fork-to-minumum (e.g. minimal coinbase+header) after a certain date than to fork up at a certain date. At least in that case, the default isn't breaking consensus, but you still get the same pressure to fork to a permanent solution. I don't endorse the above

Re: [bitcoin-dev] UTXO growth scaling solution proposal

Hi Major, I think that you'll enjoy Peter Todd's blogpost on TXO commitments[1]. It has a better scalability improvement with fewer negative consequence. Best, Jeremy [1] https://petertodd.org/2016/delayed-txo-commitments -- @JeremyRubin

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

I'm also highly interested in the case where you sign a delegate conditional on another delegate being signed, e.g. a bilateral agreement. In order for this to work nicely you also need internally something like segwit so that you can refer to one side's delegation by a signature-stable identity.

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

This might be unpopular because of bad re-org behavior, but I believe the utility of this construction can be improved if we introduce functionality that makes a script invalid after a certain time (correct me if I'm wrong, I believe all current timelocks are valid after a certain time and invalid

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

What do you think about having it be OP_CHECK_TXID_TEMPLATE_DATA where the hash checked is the TXID of the transaction with the inputs set to ... (maybe appended to the fee paid)? This allows for a variable number of inputs to be allowed (e.g., one, two, etc). This also fixes potential bugs

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

ZmnSCIPxj, I think you're missing the general point, so I'm just going to respond to one point to see if that helps your understanding of why OP_COSHV is better than just pre-signed. The reason why MuSig and other distributed signing solutions are not acceptable for this case is they all require

Re: [bitcoin-dev] Safety of committing only to transaction outputs

Hi Johnson, As noted on the other thread, witness replay-ability can be helped by salting the taproot key or the taproot leaf script at the last stage of a congestion control tree. I also think that chaperone signatures should be opt-in; there are cases where we may not want them. OP_COSHV is

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

ding signature may also be > applicable to COHV > > On 21 May 2019, at 4:58 AM, Jeremy via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hello bitcoin-devs, > > Below is a link to a BIP Draft for a new opcode, > OP_CHECKOUTPUTSHASHVERIFY. This opco

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

Hi Russell, Thanks for this detailed comparison. The COSHV BIP does include a brief comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more detailed. I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's clearly one of the more flexible options available and

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

Hi Russell, Thanks for the response. I double checked my work in drafting my response and realized I didn't address all the malleability concerns, I believe I have now (fingers crossed) addressed all points of malleability. *The malleability concerns are as follows:* A TXID is computed as: def

[bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

Hi All, OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. OP_SECURETHEBAG does more or less the same thing, but fixes malleability issues and lifts the single output restriction to a known number of inputs restriction. OP_CHECKOUTPUTSVERIFY had some issues with malleability of

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> Good morning aj, >>>> >>>> >>>> Sent with ProtonMail Secure Email. >>>> >>>> ‐‐‐ Original Message ‐‐‐ >>>> On Wednesday

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

I agree in principal, but I think that's just a bit of 'how things are' versus how they should be. I disagree that we get composability semantics because of OP_IF. E.g., the script "OP_IF " and "OP_END" are two scripts that separately are invalid as parsed, but together are valid. OP_IF

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

This is insufficient: sequences must be committed to because they affect TXID. As with scriptsigs (witness data fine to ignore). NUM_IN too. Any malleability makes this much less useful. -- @JeremyRubin On Fri, Jun 21, 2019 at

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

Morning, Yes, in general, Bitcoin does not do anything to prevent users from discarding their keys. I don't think this will be fixed anytime soon. There are some protocols where, though, knowing that a key was once known to the recipients may make it legally valid to inflict a punitive measure

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

ter solution. > > Matt > > On 5/20/19 8:58 PM, Jeremy via bitcoin-dev wrote: > > Hello bitcoin-devs, > > > > Below is a link to a BIP Draft for a new opcode, > > OP_CHECKOUTPUTSHASHVERIFY. This opcode enables an easy-to-use trustless > > congestion control tech

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

> * I do not think CoinJoin is much improved by this opcode. > Typically, you would sign off only if one of the outputs of the CoinJoin transaction is yours, and this does not really improve this situation. Coinjoin benefits a lot I think. Coinjoin is improved because you can fit more users

[bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

Hello bitcoin-devs, Below is a link to a BIP Draft for a new opcode, OP_CHECKOUTPUTSHASHVERIFY. This opcode enables an easy-to-use trustless congestion control techniques via a rudimentary, limited form of covenant which does not bear the same technical and social risks of prior covenant designs.

Re: [bitcoin-dev] [Lightning-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout

Awhile back, Ethan and I discussed having, rather than OP_CAT, an OP_SHA256STREAM that uses the streaming properties of a SHA256 hash function to allow concatenation of an unlimited amount of data, provided the only use is to hash it. You can then use it perhaps as follows: // start a new hash

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Three changes I would like to make to the OP_CTV draft. I think this should put the draft in a very good place w.r.t. outstanding feedback. The changes can all be considered/merged independently, though, they are written below assuming all of them are reasonable. 1) *Make the hash commit to the

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

I've prepared a draft of the changes noted above (some small additional modifications on the StandardTemplateHash described in the BIP), but have not yet updated the main branches for the BIP to leave time for any further feedback. See below: BIP:

Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

Johan, The issues with mempool limits for OP_SECURETHEBAG are related, but have distinct solutions. There are two main categories of mempool issues at stake. One is relay cost, the other is mempool walking. In terms of relay cost, if an ancestor can be replaced, it will invalidate all it's

[bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Bitcoin Developers, Pleased to announce refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY (replaces previous OP_SECURETHEBAG BIP). Primarily: 1) Changed the name to something more fitting and acceptable to the community 2) Changed the opcode specification to use the argument off of the

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Thanks for the feedback Russell, now and early. It deeply informed the version I'm proposing here. I weighed carefully when selecting this design that I thought it would be an acceptable tradeoff after our discussion, but I recognize this isn't exactly what you had argued for. First off, with

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

pairs of (vault, > control) keys and a chain of transactions that each spend the previous > control UTXO such that the newly created UTXO becomes controlled by the > control key of the next pair, together with vault key in that pair. > > В Sat, 22 Jun 2019 23:43:22 -0700 > Jeremy

Re: [bitcoin-dev] [Lightning-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout

the elements on the stack and compare to a known hash. How is that sort of thing weak to midstateattacks? -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Fri, Oct 4, 2019 at 4:16 AM Peter Todd wrote: > On Thu, Oct 03, 2019 at 10:02:14PM -0700, J

Re: [bitcoin-dev] [Lightning-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout

Good point -- in our discussion, we called it OP_FFS -- Fold Functional Stream, and it could be initialized with a different integer to select for different functions. Therefore the stream processing opcodes would be generic, but extensible. -- @JeremyRubin

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

I've updated the main branch (ctv) to match ctv-v2, and pushed branches ctv-v1 which points at the prior versions. Thanks to Dmitry Petukhov for helping me fix several typos and errors. I also wanted to share some some "non-technical" tax analysis covering the use of OP_CTV for batched payments.

Re: [bitcoin-dev] Removing Single Point of Failure with Seed Phrase Storage

As a replacement for paper, something like this makes sense v.s. what you do with a ledger presently. However, shamir's shares notoriously have the issue that the key does exist plaintext on a device at some point. Non-interactive multisig has the benefit of being able to sign transactions

Re: [bitcoin-dev] op_checktemplateverify and number of inputs

Hi Billy, Restricting the number of inputs is necessary to preclude TXID malleability. Committing to all of the information required necessitates that the number of inputs be committed. This allows us to build non-interactive layer 2 protocols which depend on TXID non-malleability (most of them

Re: [bitcoin-dev] CTV through SIGHASH flags

I think these ideas shows healthy review of how OP_CTV is specified against alternatives, but I think most of the ideas presented are ill advised. -- @JeremyRubin On Sat, Feb 1, 2020 at 2:15 PM Bob McElrath via bitcoin-dev <

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

re CTV ensures that certain input is > > > present in the transaction. > > > > > > scriptSig of that input can contain a signature that commits to > > > certain prevout. Unless it is possible to forge an identical > > > signature (and I don't know how strong are

Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)

Dave, I think your point: *When schnorr and taproot are done together, all of the following transaction types can be part of the same set: - single-sig spends (similar to current use of P2PKH and P2WPKH) - n-of-n spends with musig or equivalent (similar to current use of

Re: [bitcoin-dev] Taproot public NUMS optimization (Re: Taproot (and graftroot) complexity)

I am working on CTV, which has cases where it's plausible you'd want a taproot tree with a NUMS point. The need for NUMS points is a little bit annoying. There are a few reasons you would want to use them instead of multisig: 1) Cheaper to verify/create. If I have a protocol with 1000 people in

Re: [bitcoin-dev] Modern Soft Fork Activation

It's not at a "directly implementable policy state", but I think you might be interested in checking out the spork protocol upgrade model I proposed a while back. https://www.youtube.com/watch?v=J1CP7qbnpqA=youtu.be It has some interesting properties around the 5 properties you've mentioned. 1)

Re: [bitcoin-dev] OP_CTV Workshop & CFP February 1st, 2020

It's not too late to sign up to attend the workshop; but we are approaching capacity! Please fill out the form if you'd like to participate as soon as possible so that we can plan accordingly. Feel free to forward this posting to people who don't follow this list but you think should attend. --

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

https://utxos.org/uses/ Yes, you should check out the material at the link above. Specifically non interactive channels solve this problem of one sided opens, where the other party is passive/offline. On Mon, Jan 13, 2020, 12:42 PM Joachim Strömbergson via bitcoin-dev <

[bitcoin-dev] OP_CTV Workshop & CFP February 1st, 2020

Dear Bitcoin Developers, On February 1st, 2020 in San Francisco (location to be shared with attendees only) I will be hosting a workshop to aid in reviewing and advancing OP_CHECKTEMPLATEVERIFY. The workshop will be from 10am-5pm. The basic schedule of events (subject to change) is in the footer

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

Hi everyone, Sorry to just be getting to a response here. Hadn't noticed it till now. *(Plug: If anyone or their organizations would like to assist in funding the work described below for a group of developers, I've been working to put resources together for funding the above for a few months

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

Hi Andrew, If you use SIGHASH_ALL it shall sign the COutPoints of all inputs which commit to the scriptPubKeys of the txn. Thus the 341 hash doesn't need to sign any additional data. As a metadata protocol you can provide all input transactions to check the scriptPubKeys. Best, Jeremy --

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

At the end of the day I don't really care that much I just prefer something that doesn't throw taproot in for another review cycle. A side effect of this proposal is it would seem to make it not possible to produce a signature for a transaction without having access to the inputs. This is

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

It's also not something that's trivial to set up in any scheme because you have to have an ordering around when you set up the tx intended to be the inverse lock before you create the tx using it. -- @JeremyRubin On Thu, Sep

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

CTV does not enable this afaiu because it does not commit to the inputs (otherwise there's a hash cycle for predicting the output's TXID. -- @JeremyRubin On Thu, Sep 3, 2020 at 7:39 AM Dmitry Petukhov wrote: > Just had an

Re: [bitcoin-dev] reviving op_difficulty

Yep this is a good example construction. I'd also point out that modulo a privacy improvement, you can also script it as something like: IF IF CLTV B DROP CHECKSIG ELSE CLTV DROP A CHECKSIG ENDIF ELSE 2 A B 2 CHECKMULTI ENDIF This way you equivalently have cooperative closing / early closing

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

Actually we already have service bits (which are sadly limited) which allow negotiation of non bilateral feature support, so this would supercede that. -- @JeremyRubin On Fri, Aug 21, 2020 at 1:45 PM Matt Corallo wrote: > This

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

As for an example of where you'd want multi-round, you could imagine a scenario where you have a feature A which gets bugfixed by the introduction of feature B, and you don't want to expose that you support A unless you first negotiate B. Or if you can negotiate B you should never expose A, but

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

I have a proposal: Protocol >= 70016 cease to send or process VERACK, and instead use HANDSHAKEACK, which is completed after feature negotiation. This should make everyone happy/unhappy, as in a new protocol number it's fair game to change these semantics to be clear that we're acking more than

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

> > > > > > > * >> On 8/21/20 5:17 PM, Jeremy wrote: >> As for an example of where you'd > want multi-round, you could imagine a scenario where you have a feature A > which gets bugfixed by the introduction of feature B, and you don't want to > expose that you support A unless you first negotiate

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil wrote: > I said security, not privacy. You are in fact exposing the feature to any > node that wants to negotiate for it. if you don’t want to expose the buggy > feature, then disable it. Otherwise you cannot prevent peers from accessing > it.

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

Hi Suhas, Thanks for your thoughtful response! Overall I'll boil down my thoughts to the following: If we can eventually come up with something clever at the user+policy layer to emulate a sponsor like mechanism, I would still greatly prefer to expose that sort of functionality directly and in

Re: [bitcoin-dev] Floating-Point Nakamoto Consensus

If I understand correctly, this is purely a policy level decision to accept first-seen or a secondary deterministic test, but the most-work chain is still always better than a "more fit" but less work chain. In any case, I'm skeptical of the properties of this change. First-seen has a nice

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

Responses Inline: Would it make sense that, instead of sponsor vectors > pointing to txids, they point to input outpoints? E.g.: > > 1. Alice and Bob open a channel with funding transaction 0123...cdef, >output 0. > > 2. After a bunch of state updates, Alice unilaterally broadcasts a >

[bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

Hi Bitcoin Devs, I'd like to share with you a draft proposal for a mechanism to replace CPFP and RBF for increasing fees on transactions in the mempool that should be more robust against attacks. A reference implementation demonstrating these rules is available

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

Hi David! Thanks for taking a look, and great question. > Is this in the reference implementation? It is indeed in the reference implementation. Please see https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx#diff-24efdb00bfbe56b140fb006b562cc70bR741-R743 There is no

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

Hi Cory! Thanks for taking a look. CC nopara as I think your questions are the same. I think there are a few reason we won't see functionally worse privacy: 1. RBF/CPFP may require the use of an external to the original transaction to pay sufficient fee. 2. RBF/CPFP may leak which address was

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

Antoine, Yes I think you're a bit confused on where the actual sponsor vector is. If you have a transaction chain A->B->C and a sponsor S_A, S_A commits to txid A and A is unaware of S. W.r.t your other points, I fully agree that the 1-to-N sponsored case is very compelling. The consensus rules

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

s. Is it even possible for this > attacker to create the middle transaction with RBF disabled? > > Thank you, > Joachim > > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, November 26, 2019 1:50 AM, Je

[bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation

te: > В Sun, 7 Jun 2020 15:45:16 -0700 > Jeremy via bitcoin-dev wrote: > > > What I think we'll eventually land on is a way of doing a tx > > that contributes fee to another tx chain as a passive observer to > > them. While this breaks one abstraction around how depen

Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

Stellar work Antoine and Gleb! Really excited to see designs come out on payment pools. I've also been designing some payment pools (I have some not ready code I can share with you guys off list), and I wanted to share what I learned here in case it's useful. In my design of payment pools, I

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

Concept ack! It might be nice to include a few negotiation utility functions either in this bip or at the same time in a separate bip. An example we might want to include is a "polite disconnect", whereby a node can register that you don't want to connect in the future due to incompatibility. It

[bitcoin-dev] Extension to BIP Format for Multiple Required SigHash Flags

- *# The Issue:* - Currently the PSBT BIP has a slight "conceptual gap" where it is possible to both: - - 1) Have a PSBT which obtains multiple signatures per-input with any set of SIGHASH Flags - 2) Have a PSBT which obtains multiple signatures per-input with a fixed SigHash type applying to all

Re: [bitcoin-dev] New PSBT version proposal

One thing I think should be added in V2 is the ability to specify sighash flags per-key as opposed to per-input. The per-key restriction is unfitting given that there are circumstances where multisig signers may validate heterogenous logic. -- @JeremyRubin

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

The API of a sponsor-like mechanism is close to ideal in my opinion: - compatible with non malleable transactions - 0 overhead if fees accurately estimated - watchtower friendly - post hoc, requires minimal 'protocol awareness' - friendly with most mempool eviction policies, not much new required

Re: [bitcoin-dev] Opinion on proof of stake in future

re: 2, there's been some promising developments with Verifiable Delay Functions that make me think that the block regulation problems are solvable without requiring brute-force search proof of work. Are those inapplicable for some reason? ___ bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

Proof-of-stake tends towards oligopolistic control, which is antithetical to bitcoin. Proof-of-stake also has some other security issues that make it a bad substitute for Proof-of-work with respect to equivocation (reorgs). Overall you'll find me *personally* in the camp that it's OK to explore

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

> > 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] 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] 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] 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] 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

[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.

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

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

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] 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] 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

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

[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] 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] Fee estimates and RBF

Hi Prayank, Very glad to hear you are weathering the storm OK, wishing you and yours safety in the weeks ahead. I think you'll be interested to see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html especially with regards to background services. In the long

Re: [bitcoin-dev] [Lightning-dev] L2s Onchain Support IRC Workshop

I'd be excited to join. Recommend bumping the date to mid June, if that's ok, as many Americans will be at Bitcoin 2021. I was thinking about reviving the sponsors proposal with a 100 block lock on spending a sponsoring tx which would hopefully make less controversial, this would be a great

Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

Zac -- this is kind of offtopic for this thread, which is primarily to do with making software/standards that supports existing practices in the bitcoin community rather than new standards/formats for a similar task. I think there have been some other related posts recently where it might be more

Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

Inline responses On Fri, Apr 23, 2021, 11:18 AM David A. Harding wrote: > On Tue, Apr 20, 2021 at 08:46:07AM -0700, Jeremy via bitcoin-dev wrote: > > > > > > * > Script is technically "too wide" a type as what I really want is to > > only return coins wit

Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

I guess in the interest of being clear; I don't particularly want a OP_RETURN address either, they're just annoying to program around, and they exist historically, as well as perhaps in the future. Maybe people will start using the annex space to add any metadata required? E.g. stealth addresses.

Re: [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core

I'm not sure of the existing behavior is of when we issue a getdata request, but noting that there could be a privacy implication of this sort of change. Could you (or someone else) expand on why this is not a concern here? -- @JeremyRubin

[bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

We had a very productive meeting today. Here is a summary of the meeting -- I've done my best to summarize in an unbiased way. Thank you to everyone who attended. 1. On the use of a speedy trial variant: - There are no new objections to speedy trial generally. - There is desire to know if Rusty

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

Michael, Your response strikes me as ingenuine with regards to "other projects" as it is a project I understand you to be one of the parties spearheading. I think it's misleading to not clarify that in your response. Your NACK on MTP based ST does not have any merit. The only argument you made

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

25, 2021, 12:02 AM Anthony Towns wrote: > On Tue, Mar 23, 2021 at 08:46:54PM -0700, Jeremy via bitcoin-dev wrote: > > 3. Parameter Selection > > - There is broad agreement that we should target something like a May 1st > > release, with 1 week from rc1 starttime/startheigh

[bitcoin-dev] Response to Rusty Russell from Github

In response to https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3679489, reproduced below. Rusty, I concur with the gist of what you're saying -- Speedy Trial alone is not the final word on activation logic. There are likely better procedures for releasing and

[bitcoin-dev] Taproot Activation Meeting Notes, April 6th: The CoinFlip

Bitcoin Developers, The second fortnightly taproot activation meeting has just concluded. Below are my notes: 1) On AJ's mods to MTP - luke-jr is still NACK any MTP related thing - It is generally uncontested that the Mods are fine; that it should be LOT (via LAST_CHANCE) compatible -

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

l" is a retarget period here... Code: https://gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a04ff69#file-repeated_trials-py -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Mon, Apr 5, 2021 at 3:35 AM Anthony Towns wrote: > On S

  1   2   3   >