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 that'

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 n

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 term,

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

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

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

ACK adding Kalle. Kalle is a qualified reviewer / editor and well suited for this role. -- @JeremyRubin On Thu, Apr 22, 2021 at 7:09 PM Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Unless there

[bitcoin-dev] And Then What? Defining a Complete Process for Upgrades

This letter is particularly aimed at addressing Rusty Russell's quest for a development process that respects all groups in a balance of powers. However, in the spirit of open discussion, I'm sending it directly to the list. This proposal is aimed to be compatible with Taproot's ST, and I hope wil

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

Hi All, Introducing the notion that we might want to have an address type defined for OP_RETURN. I came across this when writing some code that wanted to handle common classes of user transactions generically, it's kind of annoying that you have to write code that's effectively: ``` try { pri

[bitcoin-dev] Taproot Activation Meeting 4/20 Cancelled

Dear Bitcoin Developers, There are no current agenda items or technical issues to weed out, everything has been through the grinder, and Bitcoin Core seems to be on a roll with getting Release Candidate 1 with Speedy Trial MTP in the pipe. If anyone is hazy on the details -- it has been a little

Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

I think you need to hard deprecate the PoW for this to work, otherwise all old miners are like "toxic waste". Imagine one miner turns on a S9 and then ramps up difficulty for everyone else. On Fri, Apr 16, 2021, 2:08 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote:

Re: [bitcoin-dev] Designing Bitcoin Smart Contracts with Sapio (available on Mainnet today)

Hi ZmnSCPxj, Funny you mention BlueSpec -- I actually took 6.175[1] in my undergraduate studies with Arvind, BlueSpec's creator, and have often cited it as an inspiration for Sapio given that the target of program compilation is essentially a transaction circuit and I have a decent amount of exper

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

For every workaround, someone may have a long lost stash that you'd be confiscating :) https://bitcoin.stackexchange.com/questions/90127/why-does-this-coinbase-transaction-have-two-op-return-outputs ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfou

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

NACK -- I happen to have a vault where I made emergency backup pre-signed transactions containing two OP_RETURN outputs and have subsequently lost the private key in an unfortunate boating incident. This proposed rule change would serve to confiscate my funds. -- @JeremyRubin

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC

I concur that reviewing #21377 is the best path at this time. However, I want to draw attention to the middle road here: If Core chooses to not release activation params (which has been discussed as a general concept previously), #21377 can also be used to safely issue a community release. It's

Re: [bitcoin-dev] maximum block height on transaction

You could accomplish your rough goal by having: tx A: desired expiry at H tx B: nlocktime H, use same inputs as A, create outputs equivalent to inputs (have to be sure no relative timelocks) Thus after a timeout the participants in A can cancel the action using TX B. The difference is the coin

[bitcoin-dev] Designing Bitcoin Smart Contracts with Sapio (available on Mainnet today)

Bitcoin Developers, I'm very excited to introduce Sapio[0] formally to you all. Sapio empowers Bitcoin Developers to craft smart contracts in an intuitive, safe, and composable way. Sapio challenges the notion that you can't make complex smart contracts for B

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

Update: the coin has flipped in favor of MTP https://blockstream.info/block/a6bcbf09849fe895b5d18ed884e8d558a57fc4f5e95c Further, there seems to be some agreement between Andrew and AJ w.r.t. reverting one of the changes AJ made recently ( https://github.com/bitcoin/bitcoin/p

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

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

). Note, each "trial" 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

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

We'll be having another meeting this Tuesday, as per https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html. If you can't make it feel free to leave a comment on any agenda item below, or if you think there are other things to be discussed. Agenda: 1. AJ's update to MTP ti

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

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

not matter much. On Thu, Mar 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

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 fo

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

Re: [bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight

Meeting Reminder: A few people have pinged me asking when the meeting is. It is in the title of the email, apologies if that was unclear. 19:00 UTC this Tuesday (12pm Pacific Time). If you would like to pre-register a comment please try to send it to the list today or tomorrow if possible, it wi

[bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight

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

Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

ZmnSCPxj, The chief reason to use SIGHASH_NONE (or SIGHASH_SINGLE for partial funds delegations) is to make it so that the delegator can dynamically choose things like a change output. Otherwise you need to know exactly what you want beforehand. I'd note that you can also achieve a decent amount

Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

inline responses -- @JeremyRubin On Mon, Mar 15, 2021 at 11:10 PM ZmnSCPxj wrote: > Good morning Jeremy, > > This is a very cool idea! > > > Multiple Delegates: By signing a txn with several delegate outputs, it > is possible t

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

I think Luke is pointing out that with the Signature and the Message you should be able to recover the key. if your address is H(P) and the message is H(H(P) || txn), then the you can use the public H(P) and the signature to recover the PK and verify that H(P) == P (I think you then don't even hav

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

Can you expand on the timeline issue? Which timelines are incompatible and why? It does seem like a release done *today* cannot happen anyways, so it sounds like it's already too late... or do you mean beginning the release process today? -- @JeremyRubin

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

Please announce such meetings with more than ~24 hours notice -- this has happened several times and while I recognize the pace of development on this issue I think that slotting a consensus meeting with less than 24 hours is inappropriate. I think we should proactively postpone it a week so that

[bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

I'm aware that some folks (I think nullc, sipa, myself... maybe more?) are aware of how to do script delegation in Bitcoin today (without any modifications to Bitcoin), but realized in a conversation with Andrew P that the technique is not widely known. So I figured it made sense to do a brief expl

[bitcoin-dev] Taproot: What are you building?

Hi! As a minor diversion while discussing activation parameters, I felt it would be meaningful to collect a survey on what people are already using Taproot for in either conceptual, prototype, or implemented/spec phases. I suspect there are a lot of people tinkering with Taproot one way or anothe

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

Thank you for resurfacing and collating this concept. At this time I don't see major issues with this course of action and think it represents not only a reasonable compromise between all different perspectives, but also gives us an opportunity to learn more about less 'slow' yet safe consensus up

[bitcoin-dev] In defense of a configurable LOT if LOT=false is released

The short script* below could function as a cross platform (need only have python 2 and curl) way to make a LOT=False function like a LOT=true node. This sort of script was mentioned recently in the ##taproot-activation IRC channel. It is unclear to me with this sort of script what happens if a LO

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

has been correctly reconfigured) generating invalid blocks. > > As for "Taproot" took too long, hey, at least if its locked in people can > just build things assuming it exists. Some > already are, but once its clearly locked in, there's no reason to not > continue other

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

I agree with much of the logic presented by Matt here. BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a "tiny" parameter has the potential to cause great network disruption and confusion (rationality is not too useful a concept here gi

Re: [bitcoin-dev] Taproot NACK

I have good news for you: Taproot does not enable monero-like privacy features any moreso than already exist in Bitcoin today. At its core, taproot is a way to make transactions with embedded smart contracts less expensive, done so in a manner that may marginally improve privacy dependent on user b

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

Not responding to anyone in particular, but it strikes me that one can think about the case where a small minority (let's say H = 20%?) of nodes select the opposite of what Core releases (LOT=false, LOT=true). I'm ignoring the case where a critical bug is discovered in Taproot for reasons I could e

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

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

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 a

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

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

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 th

[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 [here](https://github.com/bitcoin/

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 3,

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 ide

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] New tipe of outputs that saves space and give more privacy

You may wish to review bip-119 ChecktemplateVerify, as it is designed to support something very similar to what you've described. You can see more at https://utxos.org On Tue, Aug 25, 2020, 6:48 AM Jule.Adka via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hey, there! I have a ne

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

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 B

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 for

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

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 v

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

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 don'

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

n> On Sun, Jun 7, 2020 at 11:02 PM Dmitry Petukhov wrote: > В 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 >

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

use a very small fee > rate in order to DoS other participants. 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. > > ‐‐‐ Origin

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 limiting

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 -- @Jere

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 now

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 withou

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 i

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

; > > The ability to commit to scriptSig of a non-segwit input could be > > > used for on-chain control of spending authorization (revoking the > > > spending authorization), where CTV ensures that certain input is > > > present in the transaction. > > > > >

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

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 a

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@lists.linuxfo

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&feature=youtu.be It has some interesting properties around the 5 properties you've mentione

[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] 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] 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: https://github.com/JeremyRubin/bips/blob/ctv-v2/b

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

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 res

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

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 child

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

ments 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] [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 wi

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

t to spend if you > prepare a number of taproot branches with different 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 vaul

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 alrea

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

33 AM ZmnSCPxj via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> Good morning aj, >>>> >>>> >>>> Sent with ProtonMail Secure Email. >>>> >>>> ‐‐‐ Original Message ‐‐‐

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 1

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

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 com

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 woul

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

ent for requiring a prevout binding 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_C

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 in

<    1   2   3   >