Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format

Some related thoughts and suggestion for an extension that kanzure suggested I post here: Hardware Wallet attacks by input ownership omission and fix -- So a while back I realized that to have HW wallets do safe automa

Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format

reate `some_random_hash_connected_to_A` by `H(A || x) )` On Mon, Aug 21, 2017 at 2:36 PM, Jochen Hoenicke wrote: > On 21.08.2017 20:12, Greg Sanders via bitcoin-dev wrote: > > To fix this I consulted with andytoshi and got something we think works > > for both cases: > > >

Re: [bitcoin-dev] "Compressed" headers stream

Is there any reason to believe that you need Bitcoin "full security" at all for timestamping? On Mon, Aug 28, 2017 at 11:50 AM, Riccardo Casatta via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi everyone, > > the Bitcoin headers are probably the most condensed and important pie

Re: [bitcoin-dev] "Compressed" headers stream

Well, if anything my question may bolster your use-case. If there's a heavier chain that is invalid, I kind of doubt it matters for timestamping reasons. /digression On Mon, Aug 28, 2017 at 12:25 PM, Riccardo Casatta < riccardo.casa...@gmail.com> wrote: > > 2017-08-28 18:13 GMT+02:00 Greg Sander

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

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 wrote: > > > On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Has anyone act

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

% of >> Copay users have their backup 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 >> wrote: >> >>> Let me re-phrase: Is it a

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 done

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 computing the package-fee

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 c

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 c

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 matt

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 12

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

Could the softer touch of just making them non-standard apply as a future preparation for an accepted softfork? Relaxations could easily be done later if desired. On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello all, > > A while ag

Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion

OP_MESSAGEONLY would make "dumb" signers like HWW more difficult to support. They'd have to do script interpretation to make sure they're not signing something real with funds. Just FYI. On Wed, Mar 4, 2020 at 9:35 AM Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >

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] Transaction Replacement by Fee

BIP125 is the standard way to signal: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki Should explain everything you need. On Thu, Jan 12, 2017 at 9:02 AM, Police Terror via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, > > Where can I find the rules on trans

Re: [bitcoin-dev] Three hardfork-related BIPs

Note that the 4MB number comes from a single network metric. Quotes directly from the paper in question: http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf >Our results hinge on the key metric of effective throughput in the overlay network, which we define here as which blocks propagate within an aver

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

That's BIP30, he linked BIP34: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3004 On Tue, Apr 4, 2017 at 11:32 AM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Can you tell me where it is enforced? > > The only place I found was here; > https:/

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

I'd appreciate the authors chiming in, but I read the PASDA differently: 1) If a transaction is mined with a certain bit set, it reserves 700 bytes for that particular block. 2) In that space, 2 transactions may happen: a) First, a transaction penalizing the "parent" transaction for fraud by spend

Re: [bitcoin-dev] Using a storage engine without UTXO-index

Interesting work. I was wondering if you could tell us what specs for the machine being used as preliminary benchmark is here: https://bitcrust.org/results ? I'd be interested to also see comparisons with 0.14 which has some improvements for script validation with more cores. On Fri, Apr 7, 2017

Re: [bitcoin-dev] I do not support the BIP 148 UASF

> Besides that, I also just don't believe that UASF itself as a method to activate softforks is a good choice. The only two reliable signals we have for this purpose in Bitcoin are block height (flag day) and standard miner signaling, as every other metric can be falsified or gamed. UASF can be ju

Re: [bitcoin-dev] Network-layer attacks

See https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki and https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki On Tue, May 9, 2017 at 12:09 PM, Raystonn . via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > This study was released last week, detailing some att

Re: [bitcoin-dev] Block size following technological growth

What, if any, methods would be used for miners to communicate their upgrade? Greg On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello all, > > here is a proposal for long-term scalability I've been working on: > https://gist.git

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 < bitcoin-dev@

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

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 poin

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 < bitcoin-dev@lists.linuxfoundat

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 via

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 PSBT_IN_TAP

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 l

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] 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 < bitcoin-dev@lists.linuxfound

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 i

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

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

ike vault structures. 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. > > Th

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 Russ

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

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 no

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 buil

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 04:40:

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 t

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 s

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 fa

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

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 comp

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

uently, the tx that is spending the OP_TRUE might 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

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 1:2

[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, b

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@lists.linuxfoundation.or

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

S 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:

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

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 hav

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

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

> to safely spend a transaction 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

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

gt; I'm missing. Specifically, assuming 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

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

meral anchors > > to be added at spend time, depending 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 tr

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 < bitcoin-dev@lists.linuxfoundati

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 < bitcoin-dev@lists

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

>> UTXO") we add later on in lieu 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 >>

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 approac

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

at Consensus Cleanup. 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, > > > >

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 safety

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 deposits

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 S

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", l

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 ar

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 actual

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 fee

Re: [bitcoin-dev] On mempool policy consistency

> On Mon, 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,

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

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

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

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

UTXO") we add later on in lieu 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

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 RB

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 t

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

t;> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev < >>>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>>> >>>>>> Hi Greg, >>>>>> >>>>>> Thank you very much for sharing your proposal! &g

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 fairl

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 P

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

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

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 01:36:2

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

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 w

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 nee

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 primi

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 ign

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 idealized

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 wed

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 of

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 co

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 < bitcoin-dev@list

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 without

  1   2   >