Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate

On Sun, Jan 28, 2024 at 12:27:06PM -0500, Murch via bitcoin-dev wrote: > I agree in the detail, but not about the big picture. You are right that > it’s a problem that `tx_LM` and `tx_HS` spend the same input and therefore > are direct conflicts. > > Luckily, it is unnecessary for my scenario

Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

On Tue, Jan 30, 2024 at 05:07:16AM +, ZmnSCPxj wrote: > Sent with Proton Mail secure email. > > On Tuesday, January 30th, 2024 at 4:38 AM, Peter Todd > wrote: > > > On Tue, Jan 30, 2024 at 04:12:07AM +, ZmnSCPxj wrote: > > > > > Peter Todd proposes to sign multiple versions of

Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

On Thu, Jan 25, 2024 at 05:49:26PM +, jlspc wrote: > Hi Peter, > > If feerate-dependent timelocks (FDTs) (1) are supported, it would be possible > to use CTV to define a transaction with a fixed fee and no anchor outputs, as > long as it's racing against a transaction with an FDT.

Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

On Fri, Jan 26, 2024 at 10:28:54PM -0800, Brandon Black wrote: > Hi Peter, > > On 2024-01-24 (Wed) at 19:31:07 +0000, Peter Todd via bitcoin-dev wrote: > > It is > > expected that CTV would be usually used with anchor outputs to pay fees; by > > creating an input of the

Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

floppy disk guy > > Sent with Proton Mail secure email. > > On Wednesday, January 24th, 2024 at 7:31 PM, Peter Todd via bitcoin-dev > wrote: > > > CheckTemplateVerify(1) is a proposed covenant opcode that commits to the > > transaction that can spend an output. Namely, # of inputs

Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

On Tue, Jan 30, 2024 at 04:12:07AM +, ZmnSCPxj wrote: > Peter Todd proposes to sign multiple versions of offchain transactions at > varying feerates. > However, this proposal has the issue that if you are not the counterparty > paying for onchain fees (e.g. the original acceptor of the

Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate

On Mon, Jan 22, 2024 at 01:12:45PM -0500, Murch via bitcoin-dev wrote: > Hi Peter, > > On 1/18/24 13:23, Peter Todd via bitcoin-dev wrote: > > Reposting this blog post here for discussion: > > > > https://petertodd.org/2024/one-shot-replace-by-fee-rate > &

[bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

CheckTemplateVerify(1) is a proposed covenant opcode that commits to the transaction that can spend an output. Namely, # of inputs, # of outputs, outputs hash, etc. In practice, in many if not most CTV use-cases intended to allow multiple parties to share a single UTXO, it is difficult to

Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate

On Mon, Jan 22, 2024 at 10:52:01PM +, Peter Todd via bitcoin-dev wrote: > An even simpler fix would be to just require that all unconfirmed inputs in a > replacement come from the *same* replaced transaction. That would make certain > rare, but economically viable, replacements i

Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate

On Mon, Jan 22, 2024 at 01:12:45PM -0500, Murch via bitcoin-dev wrote: > Hi Peter, > > On 1/18/24 13:23, Peter Todd via bitcoin-dev wrote: > > Reposting this blog post here for discussion: > > > > https://petertodd.org/2024/one-shot-replace-by-fee-rate > &

[bitcoin-dev] Full-RBF Peering Bitcoin Core v26.0 Released

Available from: https://github.com/petertodd/bitcoin/tree/full-rbf-v26.0 eg: git clone -b full-rbf-v26.0 https://github.com/petertodd/bitcoin.git What is this? It's Bitcoin Core v26.0, with Antoine Riard's full-rbf peering code, and some additional minor updates to it. This does two things

[bitcoin-dev] One-Shot Replace-By-Fee-Rate

Reposting this blog post here for discussion: https://petertodd.org/2024/one-shot-replace-by-fee-rate --- layout: post title: "One-Shot Replace-by-Fee-Rate" date: 2024-01-18 tags: - bitcoin - rbf - pinning --- Currently Bitcoin Core implements a Replace-by-Fee (RBF) policy, where

Re: [bitcoin-dev] BIP process friction

On Wed, Jan 17, 2024 at 05:29:48PM +, Michael Folkson via bitcoin-dev wrote: > Hey Luke > > I'd be happy to pick up working on BIP 3 again ([0], [1]) in light of this > issue and others that are repeatedly cropping up (e.g. confusion on the > recommended flow for working on proposed

Re: [bitcoin-dev] BIP process friction

On Thu, Jan 18, 2024 at 04:47:33PM +, alicexbt via bitcoin-dev wrote: > Hi AJ, > > I like the idea and agree with everything you shared in the email except one > thing: > > > So I'm switching inquisition over to having a dedicated "IANA"-ish > > thing that's independent of BIP process

Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

On Tue, Jan 02, 2024 at 11:12:05AM +, Gloria Zhao wrote: > Hi Peter, > > > You make a good point that the commitment transaction also needs to be > included > > in my calculations. But you are incorrect about the size of them. > > > With taproot and ephemeral anchors, a typical commitment

Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

On Tue, Jan 02, 2024 at 11:12:05AM +, Gloria Zhao wrote: > Hi Peter, > > > You make a good point that the commitment transaction also needs to be > included > > in my calculations. But you are incorrect about the size of them. > > > With taproot and ephemeral anchors, a typical commitment

Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation

On Thu, Dec 21, 2023 at 09:59:04PM +, Antoine Riard wrote: > Hi Peter, > > > Obviously a local replacement cache is a possibility. The whole point of > my > > email is to show that a local replacement cache isn't necessarily needed, > as > > any alturistic party can implement that cache for

Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

On Wed, Dec 20, 2023 at 03:16:25PM -0500, Greg Sanders wrote: > Hi Peter, > > Thanks for taking the time to understand the proposal and give thoughtful > feedback. > > With this kind of "static" approach I think there are fundamental > limitations because > the user has to commit "up front" how

Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

On Wed, Dec 20, 2023 at 07:13:22PM +, Gloria Zhao wrote: > The "damage" of the pin can quantified by the extra fees Alice has to pay. > > For a v3 transaction, Mallory can attach 1000vB at 80sat/vB. This can > increase the cost of replacement to 80,000sat. > For a non-v3 transaction, Mallory

[bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

V3 transactions(1) is a set of transaction relay policies intended to aim L2/contracting protocols, namely Lightning. The main aim of V3 transactions is to solve Rule 3 transaction pinning(2), allowing the use of ephemeral anchors(3) that do not contain a signature check; anchor outputs that _do_

Re: [bitcoin-dev] Addressing the possibility of profitable fee manipulation attacks

On Sun, Dec 17, 2023 at 11:11:10AM +, ArmchairCryptologist via bitcoin-dev wrote: > ** A possible solution, with some caveats ** > > My proposed solution to this would be to add partial transaction fee burning. > If 50% or more of transaction fees were burned, this should effectively >

Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation

On Fri, Dec 15, 2023 at 10:29:22PM +, Antoine Riard wrote: > Hi Peter, > > > Altruistic third parties can partially mitigate replacement cycling(1) > attacks > > by simply rebroadcasting the replaced transactions once the replacement > cycle > > completes. Since the replaced transaction is in

[bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation

While this seems like a reasonably obvious idea, I couldn't find a previous example of it published on bitcoin-dev or elsewhere. So for the ability to cite it, I'll publish it now. # Summary Altruistic third parties can partially mitigate replacement cycling(1) attacks by simply rebroadcasting

Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

On Mon, Nov 13, 2023 at 02:18:16AM +, Antoine Riard wrote: > Your two latest mails. > > > The problem that OP_Expire aims to solve is the fact that Carol could > prevent > > Bob from learning about the preimage in time, while still getting a > chance to > > use the preimage herself. OP_Expire

Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

On Wed, Nov 08, 2023 at 12:51:31AM +, Peter Todd via bitcoin-dev wrote: > > In a post-package relay world, I think this is possible. And that > > replacement cycling attacks are breaking future dynamic fee-bumping of > > pre-signed transactions concerns me a lot. > &

Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

On Mon, Nov 06, 2023 at 06:45:21PM +, Antoine Riard wrote: > > I think you are misunderstanding a key point to my OP_Expire proposal: > because > > the ability to spend the preimage branch of the HTLC goes away when the > refund > > branch becomes available, replacing cycling or any similar

Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

On Tue, Nov 07, 2023 at 09:37:22AM -0600, Bryan Bishop via bitcoin-dev wrote: > Anti spam has been an issue for the moderators. It's relentless. Without > access to the underlying server, it has been difficult to fight spam. There > is some support for filters in mailman2 but it's not great.

Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

On Tue, Nov 07, 2023 at 11:03:30AM -0600, Ademan via bitcoin-dev wrote: > Hi Bryan, > > I don't really want my first (and last?) devlist message to be a fairly > off-the-cuff post on this topic, but here we go anyway. > > At the risk of sounding like a nostr evangelist (I promise I'm not), I

Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

On Tue, Nov 07, 2023 at 11:41:59AM -0800, Christopher Allen via bitcoin-dev wrote: > As Bitcoin-Core already uses GitHub, another possibility is to use the new > GitHub discussions feature. We increasingly have been using this at > Blockchain Commons as everyone is using already using GitHub. We

Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

On Fri, Nov 03, 2023 at 05:25:24AM +, Antoine Riard wrote: > > To be clear, are you talking about anchor channels or non-anchor channels? > > Because in anchor channels, all outputs other than the anchor outputs > provided > > for fee bumping can't be spent until the commitment transaction is

Re: [bitcoin-dev] The Pinning & Replacement Problem Set

On Thu, Nov 02, 2023 at 08:58:36AM +, John Carvalho via bitcoin-dev wrote: > Good morning, > > All layers and technologies "on" Bitcoin will fail in situations where > miners misbehave or the blocks & mempool remain consistently, overly full. > Consider this as a "law" of Bitcoin/blockchains.

Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

On Thu, Nov 02, 2023 at 05:24:36AM +, Antoine Riard wrote: > Hi Peter, > > > So, why can't we make the HTLC-preimage path expire? Traditionally, we've > tried > > to ensure that transactions - once valid - remain valid forever. We do > this > > because we don't want transactions to become

Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On Sat, Oct 21, 2023 at 09:05:35PM +0100, Antoine Riard via bitcoin-dev wrote: > In the meanwhile, lightning experts have already deployed mitigations which > are hardening the lightning ecosystem significantly in face of simple or > medium attacks. More advanced attacks can only be mounted if you

[bitcoin-dev] Full-RBF Peering Bitcoin Core v25.1 Released

Available from: https://github.com/petertodd/bitcoin/tree/full-rbf-v25.1 eg: git clone -b full-rbf-v25.1 https://github.com/petertodd/bitcoin.git What is this? It's Bitcoin Core v25.1, with Antoine Riard's full-rbf peering code, and some additional minor updates to it. This does two things

Re: [bitcoin-dev] Ordinals BIP PR

On Tue, Oct 24, 2023 at 03:56:55PM -0700, Olaoluwa Osuntokun via bitcoin-dev wrote: > TL;DR: let's just use an automated system to assign BIP numbers, so we can > spend time on more impactful things. Yes, an easy way to do that is to use a mathematical function, like SHA256() or Pubkey(). Of

Re: [bitcoin-dev] Ordinals BIP PR

On Mon, Oct 23, 2023 at 06:32:47PM +0200, Tim Ruffing wrote: > On Mon, 2023-10-23 at 15:35 +0000, Peter Todd via bitcoin-dev wrote: > > Thus > > we should limit BIP assignment to the minimum possible: _extremely_ > > widespread > > standards used by the _entire_ Bitc

Re: [bitcoin-dev] Proposed BIP for OP_CAT

On Sat, Oct 21, 2023 at 01:08:03AM -0400, Ethan Heilman via bitcoin-dev wrote: > OP_CAT fails if there are less than two values on the stack or if a > concatenated value would have a combined size of greater than the > maximum script element size of 520 Bytes. Note that if OP_CAT immediately

Re: [bitcoin-dev] [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

On Mon, Oct 23, 2023 at 11:10:56AM +, ZmnSCPxj wrote: > Hi all, > > This was discussed partially on the platform formerly known as twitter, but > an alternate design goes like this: > > * Add an `nExpiryTime` field in taproot annex. I would strongly suggest making it nExpiryHeight, and

Re: [bitcoin-dev] Ordinals BIP PR

On Fri, Oct 20, 2023 at 10:38:01PM -0700, Casey Rodarmor via bitcoin-dev wrote: > Dear List, > > The Ordinals BIP PR has been sitting open for nine months now[0]. I've > commented a few times asking the BIP editors to let me know what is needed > for the BIP to either be merged or rejected. I've

Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

On Fri, Oct 20, 2023 at 10:58:32PM -1000, David A. Harding wrote: > On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote: > > The basic problem here is after the HTLC-timeout path becomes spendable, > > the > > HTLC-preimage path remains spendable. That's bad, because in

Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote: > > Quite the contrary. Schnorr signatures are 64 bytes, so in situations like > > lightning where the transaction form is deterministically derived, signing > > 100 > > extra transactions requires just 6400 extra bytes. Even a very

Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On Fri, Oct 20, 2023 at 09:03:49PM -0400, Matt Corallo wrote: > > What are anchor outputs used for other than increasing fees? > > > > Because if we've pre-signed the full fee range, there is simply no need for > > anchor outputs. Under any circumstance we can broadcast a transaction with a > >

Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On Fri, Oct 20, 2023 at 05:05:48PM -0400, Matt Corallo wrote: > Sadly this only is really viable for pre-anchor channels. With anchor > channels the attack can be performed by either side of the closure, as the > HTLCs are now, at max, only signed SIGHASH_SINGLE|ANYONECANPAY, allowing you > to add

[bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

On Mon, Oct 16, 2023 at 05:57:36PM +0100, Antoine Riard via bitcoin-dev wrote: > Here enter a replacement cycling attack. A malicious channel counterparty > can broadcast its HTLC-preimage transaction with a higher absolute fee and > higher feerate than the honest HTLC-timeout of the victim

Re: [bitcoin-dev] Breaking change in calculation of hash_serialized_2

On Fri, Oct 20, 2023 at 05:19:19PM +, Fabian via bitcoin-dev wrote: > Hello list, > > on Wednesday I found a potential malleability issue in the UTXO set dump files > generated for and used by assumeutxo [1]. On Thursday morning theStack had > found the cause of the issue [2]: A bug in the

Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On Fri, Oct 20, 2023 at 10:31:03AM +, Peter Todd via bitcoin-dev wrote: > As I have suggested before, the correct way to do pre-signed transactions is > to > pre-sign enough *different* transactions to cover all reasonable needs for > bumping fees. Even if you just increase the fe

Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On Tue, Oct 17, 2023 at 02:11:20AM +0100, Antoine Riard wrote: > > I think if you want people to understand this exploit, you need to > explain in more detail how we have a situation where two different parties > can spend the same HTLC txout, without the first party having the right to > spend it

Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On Tue, Oct 17, 2023 at 10:34:04AM +, ZmnSCPxj via bitcoin-dev wrote: > Good morning Antoine et al., > > Let me try to rephrase the core of the attack. > > There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, `==` > are channels): > > A = B = C > > `A`

Re: [bitcoin-dev] Taproot Assets on Mainnet: Announcing tapd v0.3.0-alpha

On Wed, Oct 18, 2023 at 01:20:03PM -0700, Olaoluwa Osuntokun via bitcoin-dev wrote: > A technical specification for the Universe/Multiverse protocol can be found > here in the BIP: > https://github.com/Roasbeef/bips/blob/bip-tap-pr/bip-tap-universe.mediawiki. > > At a high level, a Universe

Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On October 16, 2023 6:57:36 PM GMT+02:00, Antoine Riard via bitcoin-dev wrote: >(cross-posting mempool issues identified are exposing lightning chan to >loss of funds risks, other multi-party bitcoin apps might be affected) > >As the HTLC-preimage spends an unconfirmed input that was already

Re: [bitcoin-dev] Compressed Bitcoin Transactions

On Fri, Sep 01, 2023 at 01:56:18PM +, Andrew Poelstra via bitcoin-dev wrote: > We can swag what the space savings would be: there are 122MM utxos right > now, which is a bit under 2^27. So assuming a uniform distribution of > prefixes we'd need to specify 28 bits to identify a UTXO. To

Re: [bitcoin-dev] Concern about "Inscriptions"

On Sun, Sep 03, 2023 at 06:01:02PM +0200, vjudeu via bitcoin-dev wrote: > > Given the current concerns with blockchain size increases due to > > inscriptions, and now that the lightning network is starting to gain more > > traction, perhaps people are now more willing to consider a smaller > >

Re: [bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now

On August 16, 2023 12:25:58 PM GMT+02:00, Peter Todd via bitcoin-dev wrote: >Since Andrew Chow criticized my use of OTS(1) to measure full-RBF adoption, Correction: Anthony Towns I am truly terrible with names... ___ bitcoin-dev mailing l

[bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now

Since Andrew Chow criticized my use of OTS(1) to measure full-RBF adoption, I've been doing high-fee full-RBF testing to re-confirm my findings. Specifically, that means sending a high fee tx1 with a fee more than sufficient to get mined in the next block. Then 30 seconds later, I send tx2, a

Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

On Sun, Aug 06, 2023 at 02:20:06PM +, josibake wrote: > Hi Peter, > > Thanks for the feedback! As you mentioned, this is a more general problem in > Bitcoin and not specific to BIP352. Therefore, if expiration dates are indeed > something we want, they should be proposed and discussed as

Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

On Fri, Aug 04, 2023 at 11:41:39AM -0700, Samson Mow wrote: > Why the 180 year limit? imho should plan for longer. You know, it was only 137 years ago that the first practical electric motor was invented; 143 years ago that the first practical light bulb was invented. 180 years is a long time.

Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

On Fri, Aug 04, 2023 at 03:27:17PM -0700, Brandon Black wrote: > I agree. Non-expiring addresses are a significant risk to bitcoin users. > > On 2023-08-04 (Fri) at 17:39:03 +0000, Peter Todd via bitcoin-dev wrote: > > Fixing this is easy: add a 3 byte field to silent pay

[bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

tl;dr: Wallets don't last forever. They are often compromised or lost. When this happens, the addresses generated from those wallets become a form of toxic data: funds sent to those addresses can be easily lost forever. All Bitcoin addresses have this problem. But at least existing Bitcoin

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

On Wed, Aug 02, 2023 at 01:38:21PM +0300, Daniel Lipshitz wrote: > Your assessment of my dishonesty is based on your assumption of how I > should be running GAP600, your assumptions are baseless and lack commercial > experience and likewise your conclusions are false. > > I have provided already

[bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs

https://github.com/bitcoin/bitcoin/pull/28130 Sjors Provoost suggested that I email this mailing list as notice of my intent to get a pull-req merged that would remove the arbitrary 80-byte, 1 output / tx, standardness restrictions on OP_Return outputs. His rationale was that removing these

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote: > Your research is not thorough and reaches an incorrect conclusion. > > As stated many times - we service payment processors and some merchants > directly - Coinspaid services multiple merchants and process a > significant amount

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

On Mon, Jul 31, 2023 at 01:26:11PM +0300, Daniel Lipshitz via bitcoin-dev wrote: > This would unnecessarily and extremely negatively impact merchants and > users who choose to accept 0-conf while using mitigation tools like GAP600. > This negative impact could be avoided by simply adding first

[bitcoin-dev] Pull-req to enable Full-RBF by default

FYI I have submitted a pull-req to Bitcoin Core to enable full-rbf by default: https://github.com/bitcoin/bitcoin/pull/28132 At the moment approximately 40% of the total Bitcoin hash power is mining full-rbf replacements, spread over 8 different pools. Multiple block explorers, including

Re: [bitcoin-dev] ZeroSync: Introducing Validity Proofs to Bitcoin

On Fri, May 12, 2023 at 02:12:03PM +0200, Robin Linus via bitcoin-dev wrote: > Hi all, > > Today we are publishing a summary of our research on "ZeroSync: Introducing > Validity Proofs to Bitcoin". > > > Here's the preface: > > We introduce ZeroSync, the first-ever proof system addressing

Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation

On Thu, Jun 01, 2023 at 05:21:39PM +, Dr Maxim Orlovsky via bitcoin-dev wrote: > Dear community, > > Some time ago we (LNP/BP Standards Association) announced the release of RGB > smart contract system [1]. In the subsequent discussion, we have referenced > [2] that the introduction of

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

On Sat, Jun 03, 2023 at 11:14:27AM +0200, Joost Jager via bitcoin-dev wrote: > Depending on policy to mitigate this annex malleability vector could > mislead developers into believing their transactions are immune to > replacement, when in fact they might not be. This potential misalignment >

[bitcoin-dev] Full-RBF Peering Bitcoin Core v25.0 Released

On Fri, May 26, 2023 at 11:39:17AM +0100, Michael Ford via bitcoin-dev wrote: > Bitcoin Core version v25.0 is now available from: > > https://bitcoincore.org/bin/bitcoin-core-25.0/ Available from: https://github.com/petertodd/bitcoin/tree/full-rbf-v25.0 eg: git clone -b full-rbf-v25.0

[bitcoin-dev] Full-RBF Peering Bitcoin Core v24.1 Released

On Fri, May 19, 2023 at 11:56:14AM +0100, Michael Ford via bitcoin-dev wrote: > Bitcoin Core version 24.1 is now available from: > > Available from: https://github.com/petertodd/bitcoin/tree/full-rbf-v24.1 eg: git clone -b full-rbf-v24.1

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

On Mon, May 08, 2023 at 06:37:34PM -0400, Luke Dashjr via bitcoin-dev wrote: > Action should have been taken months ago. Spam filtration has been a > standard part of Bitcoin Core since day 1. It's a mistake that the existing > filters weren't extended to Taproot transactions. We can address that,

Re: [bitcoin-dev] Witness script validation to reject arbitrary data

On Mon, May 08, 2023 at 08:16:41PM +, Moth via bitcoin-dev wrote: > From what I understand, things like inscriptions can only be inserted between > two specific flags - OP_FALSE and OP_IF. That's just an artifical limitation of the current inscription protocol. There are endless ways to

Re: [bitcoin-dev] tx max fee

On Sun, May 07, 2023 at 07:59:40PM -0400, Erik Aronesty via bitcoin-dev wrote: > possible to change tx "max fee" to output amounts? > > seems like the only use case that would support such a tx is spam/dos type > stuff that satoshi warned about > > its not a fix for everything, but it seems

Re: [bitcoin-dev] Using service bit 24 for utreexo signaling in testnet and signet

On March 2, 2023 6:20:35 PM GMT, Luke Dashjr via bitcoin-dev wrote: >This sounds like something that should be written up as a BIP and use a normal >service bit assignment...? The purpose of the experimental service bits is experiments. If the details of utreexo aren't nailed down and may

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

On Sat, Feb 18, 2023 at 01:28:38AM +, Andrew Poelstra wrote: > On Sat, Feb 18, 2023 at 02:03:15AM +0200, Peter Todd wrote: > > On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev > > >You could try statically analyze `` to determine whether the > > >IF branch could ever

Re: [bitcoin-dev] Codex32

On Sun, Feb 19, 2023 at 10:12:51PM +, Andrew Poelstra via bitcoin-dev wrote: > > What really did catch my attention, but which was kind of buried in the > > project documentation, is the ability to verify the integrity of each > > share independently without using a computer. For example, if

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev >You could try statically analyze `` to determine whether the >IF branch could ever be taken. For example there is no path through >the "inscription script" that would result in all the crap being dropped >by the end of

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

On Tue, Feb 07, 2023 at 01:35:12PM -0500, Russell O'Connor via bitcoin-dev wrote: > There is a bug in Taproot that allows the same Tapleaf to be repeated > multiple times in the same Taproot, potentially at different Taplevels > incurring different Tapfee rates. > > The countermeasure is that

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via bitcoin-dev wrote: > Peter Todd also suggests in this thread that the use of uncompressed > keys can cause "surprise" witness inflation, but (a) since segwit > uncompressed keys are also banned, so keys are a fixed 33 bytes (32 in >

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

On Tue, Feb 07, 2023 at 11:36:58AM +0200, Nadav Ivgi via bitcoin-dev wrote: > > Since Taproot (more generally any kind of MAST) spends have variable size > > Isn't this the case with any arbitrary script execution? Non-taproot This is even been true for P2PKH inputs: you can double the space of

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

On February 5, 2023 12:40:38 PM GMT+01:00, Aymeric Vitte wrote: >I think logically: > >- if you want to store something big and can afford several txs in your >design, then you use something like witness > >- if you want to store small things like signatures, addresses hashes >and some

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via bitcoin-dev wrote: >Since bytes in the witness are cheaper than bytes in the script pubkey, >there is a crossover point in data size where it will simply be cheaper to >use witness data. Where that crossover point is depends on

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

On February 5, 2023 12:09:02 AM GMT+01:00, Aymeric Vitte via bitcoin-dev wrote: >I don't know, what number would you advise? When I made the >bitcoin-transactions nodejs module some years ago the limit (from the >specs) was 512B 1) Allowing only one OpReturn output causes problems trying to

Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case

On Sat, Jan 14, 2023 at 10:15:30PM +0200, Daniel Lipshitz wrote: > We have standard commercial information about the payment processors, non > custodial liquidity providers and merchants which become our clients - we > do not have any kyc/aml information or telephone number on who is sending > our

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

On Fri, Feb 03, 2023 at 09:07:29PM -0500, Greg Sanders wrote: > I'm not particularly persuaded, but also not wedded to either idea. > > Fixed up tests for the OP_TRUE case here: > https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true Thanks. Looking through that, I think a lot of

Re: [bitcoin-dev] Purely off-chain coin colouring

On Sat, Feb 04, 2023 at 08:38:54PM +1000, Anthony Towns via bitcoin-dev wrote: > I think for bitcoin's blockspace, we ideally only want the first of > these to be true. We want small blocks because that makes it cheap to > verify bitcoin, which reduces the need to trust third parties and aids in >

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

On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote: > > OP_TRUE is the obvious way to do this, and it results with a 1 on the > stack, > which plays better with other standardness rules. > > What other standardness rules? MINAMALIF? How does that interact with the > proposal? It makes

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

On Thu, Feb 02, 2023 at 01:36:24PM -0500, Greg Sanders wrote: > Quickly checked, it fails a number of standardness tests in unit/functional > tests in Bitcoin Core, at least. > > OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I > just independently arrived at the same

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

On Thu, Feb 02, 2023 at 09:59:09AM -0500, Greg Sanders wrote: > Hi Peter, > > For the most principled of reasons: > > Because I have to change test vectors everywhere! Specifically, you mean you'd have to change tests that test something is non-standard? -- https://petertodd.org

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

On Fri, Jan 27, 2023 at 09:05:20AM -0500, Greg Sanders via bitcoin-dev wrote: > Hello again dev, > > Due to the interest in the proposal and the prodding of certain folks, I've > written up a short draft BIP of the Ephemeral Anchors idea here: >

Re: [bitcoin-dev] Purely off-chain coin colouring

On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote: > Hi *, > > Casey Rodarmor's ordinals use the technique of tracking the identity of > individual satoshis throughout their lifetime: > I think, however, that you can move inscriptions entirely off-chain. I > wrote a

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

On Thu, Feb 02, 2023 at 12:45:42PM +0100, Aymeric Vitte wrote: > As far as I can read nobody replied to the initial question: what is > considered as good/best practice to store in Bitcoin? Your answer is beyond not putting unspendable data in the UTXO set, the exact details don't really matter.

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

On Wed, Feb 01, 2023 at 02:02:41PM +, Andrew Poelstra wrote: > On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote: > > > > > > On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev > > wrote: > > >All other things

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

On February 1, 2023 8:36:52 AM GMT, Kostas Karasavvas wrote: >With OP_RETURN you publish some data that are immediately visible in the >blockchain. I would consider this better (more straightforward) for things >like time-stamping. You are incorrect. Time-stamps merely prove that data

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev wrote: >All other things being equal, which is better if you need to place a >64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent >taproot transaction such as: > >OP_FALSE >OP_IF >OP_PUSH my64bytes

Re: [bitcoin-dev] Pseudocode for robust tail emission

On Sun, Jan 01, 2023 at 11:42:50PM +1100, Alfie John wrote: > On 31 Dec 2022, at 10:28 am, Peter Todd via bitcoin-dev > wrote: > > > >> This way: > >> > >> 1. system cannot be played > >> 2. only in case of destructive halving: system

Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case

On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote: > GAP600 is not a trxs processor or liquidity provider we service merchants, > payment processors & non-custodial liquidity providers - our service is > purely the 0-conf enabling our clients to accept 0-conf. Clients access our >

Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

On Tue, Jan 10, 2023 at 05:10:37PM +, alicexbt via bitcoin-dev wrote: > Hi Peter, > > > Bringing up Whirlpool here is silly. Everyone knows Samourai has made, at > > best, > > some rather insane technical decisions. Quite likely downright malicious > > with > > their xpub collection. Their

Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

On Tue, Jan 10, 2023 at 10:14:47AM -1000, David A. Harding wrote: > On 2023-01-10 00:06, Peter Todd wrote: > > Remember, we'd like decentralized coinjoin implementations like > > Joinmarket to > > work. How does a decentralized coinjoin implement "conflict monitoring"? > > 1. Run a relay node

Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

On Tue, Jan 10, 2023 at 12:02:35AM -1000, David A. Harding wrote: > On 2023-01-09 22:47, Peter Todd wrote: > > How do you propose that the participants learn about the double-spend? > > Without > > knowing that it happened, they can't respond as you suggested. > > I can think of various

Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

On Tue, Jan 10, 2023 at 09:19:39AM +, alicexbt wrote: > Hi Peter, > > > ## How Full-RBF Mitigates the Double-Spend DoS Attack > > > > Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very > > straightforward way: the low fee transaction is replaced by the higher fee > >

Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

On Mon, Jan 09, 2023 at 09:11:46PM -1000, David A. Harding wrote: > On 2023-01-09 12:18, Peter Todd via bitcoin-dev wrote: > > [The quote:] > > > > "Does fullrbf offer any benefits other than breaking zeroconf > > business > > practices?"

  1   2   3   4   5   >