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

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 large the CPFP later will have to be. 1kvB is an arbitrary value that is two

Re: [bitcoin-dev] Proposed BIP for OP_CAT

> This is no longer an issue in the current age as tapscript enforces a maximum stack element size of 520 Bytes. I don't think there's a new limit related to tapscript? In the very beginning there was no limit, but a 5k limit was put into place, then 520 the same commit that OP_CAT was disabled:

Re: [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants

> I do not know if existing splice implementations actually perform such a check. Unless all splice implementations do this, then any kind of batched splicing is risky. As long as the implementation decides to splice again at some point when a prior splice isn't confirming, it will self-resolve

Re: [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS

Hi Brandon, Not going to dive too deep here, just adding a bit of color. > * If the top item on the stack is not a minimally encoded `OP_0`, `OP_1`, or `OP_2`; succeed immediately[^2]. I presume this was supposed to go to OP_4 now. > ### How does the efficiency compare to [bip118][]? Just

Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs"

Hi antoine, Simplicity was just a stand in for "functionally complete" handwave. Cheers, Greg On Thu, Jul 20, 2023, 1:46 AM Antoine Riard wrote: > Hi Greg, > > I'm very meeting your development approach with regards to starting smalls > about consensus change primitives, and I think taproot

Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs"

Hello Keagen, Most of the complexity of LN cannot be resolved with covenants. Of the things that can be simplified in my experience, you're going to need more than CTV to get significant gains. And in the end, channels can only get so simple since we have many other BOLTs to deal with. And even

Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols

>> "Can a V2 transaction replace a V3 transaction and vice versa?" > Circling back to my ACP point, this regime still allows pinning anytime you are sharing a transaction with someone else where you don't have control over *all* the inputs. So anytime you are doing a coinjoin-like transaction,

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

roduced as a TLV record itself: > https://github.com/bitcoin-inquisition/bitcoin/pull/28 > > Note this branch also implements the "only allow tlv record 0" with the > TLV format from bips #1381. > > Best, > Antoine > > Le ven. 16 juin 2023 à 14:31, Greg Sanders via

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

Hi Joost, I haven't thought a ton about the specific TLV format, but that seems like a reasonable place to start as it shouldn't unduly impact current users, and is pretty simple from an accounting perspective. It also can be further relaxed in the future if we so decide by using max tx size

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

Hi Joost, > Ignoring the argument that policy may provide a false sense of security This may take longer form arguments than I'm willing to make on this thread, but I think this only true in a shallower sense that we cannot know for sure that anything will be confirmed quickly. When crafting

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

> Regarding the potential payload extension attack, I believe that the changes proposed in the [3] to allow tx replacement by smaller witness would provide a viable solution? The only plausible case I could see moving forward is replacing the transaction to a form that has *no* annex or

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

No in this case the txid is identical. Only the wtxid is malleated, with annex data stuffed to max transaction size. Cheers, Greg On Sat, Jun 3, 2023, 8:36 AM Joost Jager wrote: > > Depending on policy to mitigate this annex malleability vector could >> mislead developers into believing their

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

> I think this avoidance of a circular reference is also why LN-Symmetry uses the annex? The annex trick specifically is used to force the publication of the missing piece of the control block corresponding to the new taproot output. This is to maintain the node's O(1) state while also keeping

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

Hello Joost, David, Thanks for the link to my ln-symmetry draft David. I'd also be curious as to the usage you have in mind Joost. It's probably helpful to cite the most recent discussions on the topic, which is probably https://github.com/bitcoin-inquisition/bitcoin/pull/22 , where

Re: [bitcoin-dev] Bitcoin Transaction Relay over Nostr

Hi Joost, David, In my mind, weak blocks' main benefit would be that it improves block relay by giving PoW-hints on what are in miner's mempools. Non-standard transactions could even be cached(even if not validated until block inclusion), which would tolerate more heterogeneity in policies

Re: [bitcoin-dev] Package Relay Proposal

Hi Tom, Yesterday a PR was opened to do just that, with caveats: https://github.com/bitcoin/bitcoin/pull/27609 For higher level tracking of the project: https://github.com/bitcoin/bitcoin/issues/27463 Cheers, Greg On Wed, May 10, 2023 at 11:39 AM Tom Trevethan via bitcoin-dev <

Re: [bitcoin-dev] BIP for OP_VAULT

Hi Luke, I think this works as with OP_FLU based construct, for the simplest single key case. e.g., single key hot wallet(or MuSig2/FROST wallet) 1 " OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG" OP_FORWARD_LEAF_UPDATE The is appended at spending time. This allows the utxo to go to $recover

Re: [bitcoin-dev] BIP for OP_VAULT

Hi Brandon, Thank you for chiming in, causing me to think a bit more deeply on the privacy issues and what seems possible. > I like that in James' current PR proposal we can explicitly batch via the implied input/output summation rules while avoiding address reuse. If we can retain some or all

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

After getting neutral to negative feedback on the choice, I have switched to OP_TRUE on the BIP and implementation. Cheers, Greg On Sat, Feb 4, 2023 at 11:03 AM Peter Todd wrote: > On Fri, Feb 03, 2023 at 09:07:29PM -0500, Greg Sanders wrote: > > I'm not particularly persuaded, but also not

Re: [bitcoin-dev] BIP for OP_VAULT

Didn't finish sentence: but in practice would end up with pretty similar usage flows imho, and as noted in PR, would take a different wallet paradigm, among other technical challenges. On Mon, Mar 13, 2023 at 10:55 AM Greg Sanders wrote: > Hi Luke, > > Can you elaborate why the current

Re: [bitcoin-dev] BIP for OP_VAULT

Hi Luke, Can you elaborate why the current idealized functionality of deposit -> trigger -> withdrawal is too complicated for everyday use but the above deposit -> withdrawal -> resolve(claim/clawback) wouldn't be? I admit at a high level it's a fine paradigm, but in practice would end Let's

Re: [bitcoin-dev] BIP for OP_VAULT

AJ, Interesting stuff! Just a couple thoughts on these proposed opcodes, at least one we discussed elsewhere: 1) OP_FORWARD_SELF is a JET of OP_FLU in the revaulting common case. Maybe obvious but I missed this initially and thought it was useful to be pointed out. 2) Using these extended

Re: [bitcoin-dev] BIP for OP_VAULT

Hi James, I think everything except the hinted "withdrawal authorization" is spot on. For withdrawal authorization, I think we'll have to go deeper into the TLUV direction as AJ suggested for at least a couple reasons: 1) You need the withdrawal authorization committed at deposit time 2) You

Re: [bitcoin-dev] BIP for OP_VAULT

Greetings AJ, Glad I could resurrect the idea! > Then instead of `idx hash delay OP_TRIGGER_FORWARD` you write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS" OP_FORWARD_LEAF_UPDATE` Interesting idea! (I'll let you be the one to scope creep the proposal :) ) To be pedantic, EXPR_TRIGGER

Re: [bitcoin-dev] BIP for OP_VAULT

Hello James, First off, thank you for crafting an interesting idea like this that is aimed at solving a serious problem. I see a lot of excitement about the use cases, and I think it's worth iterating on. Attempting to keep the idealized functionality constant, I'd like to explore a design

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

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 On Fri, Feb 3, 2023 at 5:10 PM Peter Todd wrote: > On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote: > > >

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

> 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? On Thu, Feb 2, 2023 at 3:22 PM Peter Todd wrote: > On Thu, Feb 02, 2023 at

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

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 conclusion. On Thu, Feb 2, 2023 at 10:06 AM Peter Todd wrote: > On Thu,

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

Hi Peter, For the most principled of reasons: Because I have to change test vectors everywhere! Greg On Thu, Feb 2, 2023 at 9:52 AM Peter Todd wrote: > On Fri, Jan 27, 2023 at 09:05:20AM -0500, Greg Sanders via bitcoin-dev > wrote: > > Hello again dev, > > >

Re: [bitcoin-dev] Reference example bech32m address for future segwit versions

David, I'm merely speaking in a descriptive sense. I predict that most custodians are reluctant to whitelist a witness version they know is insecure. I'm not sure what's best for not colliding with future versions, I'll let other wiser folks weigh in. Cheers, Greg On Tue, Jan 31, 2023 at 6:33

Re: [bitcoin-dev] Reference example bech32m address for future segwit versions

Hi David, >From practical experience, I think you'll find that most exchanges will not enable sends to future segwit versions, as from a risk perspective it's likely a mistake to send funds there. That said, as long as we don't change the checksum again(!), updating to new versions should be

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

ev < >>>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>>> >>>>>> Hi Greg, >>>>>> >>>>>> Thank you very much for sharing your proposal! >>>>>> >>>>>> I think there's o

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

Hi James and co, Currently there is no way to make this compatible with scripthashes of any kind, since the script interpreter has no insight into the OP_UNVAULT outputs' "execution script", and one of the arguments of OP_UNVAULT is freeform, resulting in an unpredictable output scriptpubkey. I

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

This will greatly centralize the network as well as not actually achieve the intended goal which is literally impossible. On Mon, Dec 5, 2022, 8:27 AM El_Hoy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The only option I see against the attack Peter Todd is doing to opt-in

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

ing them by incentive, so maybe it's >>> a cleanup one can punt. >>> >>> One question I have is if V3 is designed for lightning, and this is >>> designed for lightning, is there any sense in requiring these outputs for >>> v3? That might help with e.g. ano

Re: [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling

> ...and the attacker also pays out the nose if they're exploiting rule #3. I agree the attacker puts more at stake in this case. If we're assuming they pay the price and get mined, they can be booted from the protocol whenever they get mined. I was speaking about the worst case scenario where

Re: [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling

Sorry, I forgot one point which is pertinent to this conversation. *Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are still an issue in coinjoin scenarios. Each coinjoin adversary can double-spend their coin to either full package weight(101kvb), or give 24 descendants,

Re: [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling

My idea, which I hated and didn't propose, was to mark utxos specifically for this exact purpose, but this is extremely ugly from a wallet/consensus perspective. nVersion is cleaner(well, except the below issue), at the cost of forcibly marking all utxos in a transaction the same way. > On the

Re: [bitcoin-dev] Preventing/detecting pinning of jointly funded txs

Assigning blame here seems to be the paramount concern here. If we can assign blame, most coinjoin-like protocols can terminate in bounded block time, assuming fees are properly set. It's also worth noting that in coinjoin cases, they're obviously coinjoins, so pinging explorers over Tor HS seems

Re: [bitcoin-dev] On mempool policy consistency

Oct 31, 2022 at 12:25:46PM -0400, Greg Sanders via bitcoin-dev > wrote: > > For 0-conf services we have potential thieves who are willing > > to *out-bid themselves* to have funds come back to themselves. It's not a > > "legitimate" use-case, but a rational one.

Re: [bitcoin-dev] On mempool policy consistency

Thanks for your full thoughts Suhas, The idea of V3 is that we're currently leaving fees on the table by allowing use-cases to be pinned, not that we like Lightning and we think miners should stop being profit maximizing somehow to enable safer/better layer 2 systems. If someone wants to bump

Re: [bitcoin-dev] On mempool policy consistency

During off-channel discussion, Suhas made a great point that even with fullrbf, you can get stuck by bip125 rule#5 pinning if an adversary controls a number of inputs(4 with default mempool settings). Implication being, while we can mitigate rule#3 damage potentially with fullrbf, we cannot

Re: [bitcoin-dev] On mempool policy consistency

> For instance, the double-spend could be low-feerate and large, and effectively pin any attempt to replace it. Yes, this is the biggest hole left. You *could* replace it with RBF when before you simply could not, so perhaps the pinning door is slightly smaller in scenarios where going feerates

Re: [bitcoin-dev] On mempool policy consistency

To add a wrinkle, or possibly a confirmation of your long message, up to readers to decipher, there historically has been at least one more RBF related option that was included, then removed later in Core. Introduced as "permitrbf" in b768108d9c0b83330572711aef1e569543130d5e with default "true",

Re: [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction

As there has been some feedback to the same effect, I've opened a competing PR for separate evaluation here: https://github.com/bitcoin/bitcoin/pull/26398 Please give feedback if anyone has any. On Thu, Oct 20, 2022 at 8:13 PM Peter Todd wrote: > On Thu, Oct 20, 2022 at 08:07:54PM -0400, Greg

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

> Yeah, there are several policy features that are not consensus related but end up de facto setting rules for how bitcoin behaves. Yes, it's status quo so wallets "just know" not to do them. The fact that the status quo would be changing is important, in that it may degrade UX for 0-conf

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

Full-rbf is an odd duck, because while it is not a consensus issue, it does affect a large % of transactions made by wallets already, contrary to most policy changes. We have a status quo that is understandable, but unfortunately long-term incentive incompatible. It's also a UX issue, not a

Re: [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction

. Willing to change my proposal and PR if people have no strong objections. Greg On Thu, Oct 20, 2022, 7:21 PM Peter Todd wrote: > On Tue, Oct 11, 2022 at 08:50:07AM -0400, Greg Sanders via bitcoin-dev > wrote: > > Hello fellow Bitcoiners, > > > > After looking at som

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

> If it were growing in line with lightning capacity in BTC, per bitcoinvisuals.com/ln-capacity; then 15% now would have grown from perhaps 4% in May 2021, so perhaps 8% per year. With linear growth, getting from 15% to 80% would then be about 8 years. I'd caution against any metrics-based

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

of managing them by incentive, so maybe it's >> a cleanup one can punt. >> >> One question I have is if V3 is designed for lightning, and this is >> designed for lightning, is there any sense in requiring these outputs for >> v3? That might help with e.g. anonymity set, as

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

Another downside is that the sender may not opt into a non-pinnable future format like "V3 transactions", making CPFP difficult. They may spend a lot of fees to do this however, so maybe we're really reaching here. On Wed, Oct 19, 2022 at 12:07 PM Sergej Kotliar via bitcoin-dev <

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

Isn't the extreme of this that the merchant tries to lock in gains on the upswing via CPFP, and users on the downswing, both doing scorched earth, tossing the delta to fees? Seems like a MAD situation? On Wed, Oct 19, 2022 at 11:44 AM Jeremy Rubin via bitcoin-dev <

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

ending on spending requirements. > > SIGHASH_SINGLE already allows this. > > Note, with SIGHASH_GROUP, you're still allowed to aggregate in a single > bundle multiple ln-penalty commitments or eltoo settlement transactions, > with only one fee-bumping output. It's a co

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

ming the scenario of a v3 transaction with >>> three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child >>> transaction spends A and OP_TRUE, does that effectively mark output B as >>> unspendable once the child gets confirmed? If so, isn't the implication >>

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

ansaction with an ephemeral anchor, all outputs must be > spent? Thanks! > > Best, > Arik > > On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote: > > Hello Everyone, > > Following up on the "V3 Transaction" discussion here > https://lists.lin

[bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF against package limit pinning

Hello Everyone, Following up on the "V3 Transaction" discussion here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html , I would like to elaborate a bit further on some potential follow-on work that would make pinning severely constrained in many setups]. V3

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

AJ, Thanks for the latest PR and discussion, even if we know we're all (very, very, very) tired of it running almost 10 years now. I think we're close to a resolution, (2), or (3) as you note. As ariard notes in https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280071572 we seem to

Re: [bitcoin-dev] Validity Rollups on Bitcoin

Thanks for the writeup John, Is there a one page cheat sheet of "asks" for transaction introspection/OP_ZKP(?) and their uses both separately and together for different rollup architectures? On Tue, Oct 11, 2022 at 11:52 AM John Light via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>

Re: [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction

HRMH > > Get Outlook for Android <https://aka.ms/AAb9ysg> > -- > *From:* bitcoin-dev on > behalf of Greg Sanders via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> > *Sent:* Tuesday, October 11, 2022 11:50:07 PM > *To:* Bit

Re: [bitcoin-dev] Minor DoS vulnerability in BIP144 lack of tx witness data size limit

There are a number of issues with adding arbitrary size restrictions to consensus(I personally think it's additional complexity for negative gain), but most of all this may resolve in burned coins. On Tue, Oct 11, 2022 at 6:22 AM Loki Verloren via bitcoin-dev <

[bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction

Hello fellow Bitcoiners, After looking at some fairly exotic possible transaction types, I ran into the current policy limit requiring transactions to be 85 non-witness serialized bytes. This was introduced as a covert fix to policy fix for CVE-2017-12842. Later the real motivation was revealed,

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

David, Dario, The only other effort I'm aware of is https://github.com/bitcoin/bitcoin/pull/25600 , which as you can see, has no consensus yet, isn't in 24.0, so at earliest would be 25.0, even if somehow immediate resolution to the discussions were found. Cheers, Greg On Fri, Oct 7, 2022 at

Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols

ht fall out of the >> mempool if the mempool fee rate rises >> - This could cause the 0 sat output to enter the UTXO set (specifically, >> rational miners wouldn't refuse to mine such a tx) >> >> It doesn't seem like this would happen much in practice (nor is ther

Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols

> Right, good catch, this does require new logic to handle this case. As Gloria points out, this should be doable, and is definitely worth adding (those CSV 1 on every other output are really hacky, glad to find a way to get rid of them). For the record, it turns out ephemeral anchors + v3 solves

Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols

Bastien, > This may be already covered by the current package RBF logic, in that scenario we are simply replacing [ParentTx, ChildTx1] with [ParentTx, ChildTx2] that pays more fees, right? For clarification, package RBF is ParentTx*s*(plural), and ChildTx(singular), so it might be a bit more

Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols

Hello Gloria, Great work on synthesizing so much feedback into a proposal like this! Death to carve-out rule. I'd like to elaborate on some caveats and give a few incomplete thoughts. There are basically two types of pinning in my estimation today: 1) rule#3 pinning: Make it uneconomical to

Re: [bitcoin-dev] More uses for CTV

Hi James, Could you elaborate on a L2 contract where speedy settlement of the "first part" can be done, while having the rest take their time? I'm more thinking about time-out based protocols. Naturally my mind drifts to LN, where getting the proper commitment transaction confirmed in a timely

Re: [bitcoin-dev] Trying all address types in message signing verification (BIP)

Please see BIP322 https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki On Wed, Jul 20, 2022, 5:46 PM Peter (Coinkite Inc) via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Ali. > > > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My > proposal is

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

The attacker isn't guaranteed to spend *any* funds to disrupt the protocol indefinitely, that's the issue here. In this scenario, her input double spend is at an impractical feerate, and is never included in a block, sitting at the bottom of the mempool. The other users' only practical choice is

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

One key difference seems to be that properly punishing someone based on mempool behavior seems much more difficult. As we all know there is no "the mempool". On Sun, Jun 26, 2022, 8:43 PM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sun, Jun 26, 2022 at

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

> It is not possible to guarantee that a transaction will be mined within N blocks irrespective of fees. It is vulnerable if a project's security relies on it, and should fix it by changing the security assumptions. It's not possible to guarantee that any funds can be moved ever. But we still

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

> If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf? The security of LN and other related systems are something like: "given proper fees offered, can a transaction be mined within N blocks?" You're simply

Re: [bitcoin-dev] Package Relay Proposal

Hi Gloria, Thanks for working on this important proposal! Still a lot to digest, but I just had on area of comment/question: > A child-with-unconfirmed-parents package sent between nodes must abide by the rules below, otherwise the package is malformed and the sender should be disconnected. >

Re: [bitcoin-dev] Improving BIP 8 soft fork activation

I think you may be confused. Mandatory signaling is not the same thing as mandatory activation on timeout, aka Lock On Timeout aka LOT=true. These are two related but separate things. On Thu, May 12, 2022, 6:53 PM alicexbt via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi

Re: [bitcoin-dev] Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning

. On Thu, May 12, 2022, 3:17 AM David A. Harding wrote: > On 2022-05-10 08:53, Greg Sanders via bitcoin-dev wrote: > > We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to > > the proposal) to the "state" input's script. > > This is used in the

[bitcoin-dev] Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning

Hello devs, I've had this thought rattling around and thought it was worth putting to a wider audience since I haven't really seen it in other contexts. I've been working on eltoo designs for Elements and eventual inclusion into Bitcoin. With that in mind there's been a reasonable amount of

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

The proposed use case for the ANYSCRIPT part of APOAS explicitly doesn't commit to amount, so I'd also assume it not be re-added or at least be able to be opened out. On Sat, Apr 30, 2022, 4:47 AM Nadav Ivgi via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi darosior, > > It's

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

Ironically assumptions of bad faith are going to kill any proposal, resulting in the status quo. Let's keep the assumption of good faith, unless you are actually accusing people of being a NSA-adjacent asset. On Thu, Apr 21, 2022 at 10:08 AM alicexbt via bitcoin-dev <

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

> One point of discomfort I have with Eltoo that I think is not universal, but is shared by some others, is that non-punitive channels may not be good for high-value channels as you do want, especially in a congested blockspace world, punishments to incentivize correct behavior (otherwise cheating

Re: [bitcoin-dev] Thoughts on fee bumping

One quick thought to the proposal and perhaps to sponsors in general(didn't have time to go over original proposal again): Since sponsors can come from anywhere, the wallet application must have access to the mempool to know what inputs must be double spent to RBF the sponsor transaction. Seems

Re: [bitcoin-dev] Taproot Fields for PSBT

I may be misunderstanding the question, but it seems essential data for the finalizer role, which may not know such information on its own. On Wed, Nov 24, 2021 at 11:15 PM Sjors Provoost via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Andrew, > > I'm confused why

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

> Sometimes that reorg could be deeper if you would be lucky enough to get a block with more work than N following blocks combined Each block is credited for its contribution to total chainwork by the difficulty target, not the hash of the block itself. On Sun, Sep 12, 2021 at 10:42 PM vjudeu

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

Funny AJ mentions the multisig idea, because I know for a fact it's being used in certain permissioned systems in this exact way. Regulators will dream up these ideas with or without more useful covenants! On Mon, Jul 5, 2021 at 9:46 PM Matt Corallo via bitcoin-dev <

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

Transaction analysis tools do take the signal into account, but I'm unsure if retail, non-custodial wallets use this information. Historically the biggest pushback has been from services like Bitrefill which have had quite a bit of success with 0-conf payments, but perhaps LN adoption is at a

Re: [bitcoin-dev] Time to lower minrelaytxfee ?

No strong opinions but: Denial of service attacks can become 5x cheaper. If you don't thoroughly test https://github.com/bitcoin/bitcoin/issues/16499 these changes you can end up with bugs that can cause issues on p2p network. On Fri, Aug 21, 2020 at 4:00 AM Dan Bryant via bitcoin-dev <

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

Can you make it clear what the bold vs not-bold numbers mean? On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >>

Re: [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

A major point of defeating the common input heuristic and others is to make "super-clusters". A small number of users that "don't care" about possibly touching tainted coins can render many chain analysis techniques unworkable in practice for enforcement. You don't need 100% coverage to defeat the

Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

So I think the question to ask would be "why can't we just make sure it's not 64?" On Sat, May 23, 2020 at 11:24 AM Greg Sanders wrote: > AFAIU the number was picked to protect against CVE-2017-12842 covertly. > See: https://github.com/bitcoin/bitcoin/pull/16885 >

Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

AFAIU the number was picked to protect against CVE-2017-12842 covertly. See: https://github.com/bitcoin/bitcoin/pull/16885 which updated the text to explicitly mention this fact. On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev

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

For what it's worth this measure had been discussed as a lightweight way of informing offline signers if inputs were segwit or not for malleability analysis reasons. So there's at least a couple direct use-cases it seems. On Fri, May 1, 2020, 8:23 AM Russell O'Connor via bitcoin-dev <

Re: [bitcoin-dev] Statechain implementations

> Wouldn't that result in a changing pubkey at each update, and thus require an onchain move to be committed? Suggestion was in line with original proposal where no keys are changing ever, just not presupposing existence of MuSig. On Thu, Mar 26, 2020 at 1:15 PM Christian Decker via bitcoin-dev

Re: [bitcoin-dev] Taproot proposal

> I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for segwit v0 for compatibility reasons. Most wallets/exchanges/services now support sending to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) and that will be even more true if Schnorr/Taproot activate in

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

People are allowed the choice, it's a change of default only. On Mon, Jul 22, 2019 at 4:41 PM Peter via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > I believe two wallets. Andreas' Android Bitcoin wallet and BRD are > significant users of node_bloom. > > Privacy is a

Re: [bitcoin-dev] BIP 174 thoughts

>Hmm, upon further reflection, maybe it's not even worth including *any* per-output data, aside from what the original transaction contains. >The output redeem script is either: - unknown, because we have received only an address from the receiver - or it is known, because it is ours and in that

Re: [bitcoin-dev] {sign|verify}message replacement

Sorry if I missed the rationale earlier, but why not just do a transaction, with a FORKID specifically for this? Then a node can have a mempool acceptance test that returns true even if the signature is not valid as per Bitcoin consensus, but only due to the FORKID? This way basically any wallet

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

Yes. On Wed, Feb 14, 2018 at 9:08 AM, Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > >> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: >> > Surely CPFP is already

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Interesting parallels to current Elements sidechain peg-in functionality. User tweaks the watchmen(BTC holder) pubkey using P2CH, committing to a script that is used on the *sidechain side* as spending authorization for that bitcoin output rather than mainnet. I think composing the two can be

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

kup on a language >> other than English, and we constantly get requests to support new >> languages in BIP39. >> >> On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders <gsander...@gmail.com> >> wrote: >> >>> Let me re-phrase: Is it a known thing fo

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

Let me re-phrase: Is it a known thing for users to actually use it? On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia <ema...@gmail.com> wrote: > > > On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: >

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

Has anyone actually used the multilingual support in bip39? If a feature of the standard has not been(widely?) used in years, and isn't supported in any major wallet(?), it seems indicative it was a mistake to add it in the first place, since it's a footgun in the making for some poor sap who

  1   2   >