2021-05-17

< wumpus> wait, does 'bips' have a publicly editable wiki
< aj> might want to ban P7-33 too -- https://github.com/bitcoin/bips/wiki/_Sidebar/_history

2021-05-13

< bitcoin-git> [bitcoin] luke-jr closed pull request #21399: Genericide BIP9 in variable/type names and comments (master...vbits_rename) https://github.com/bitcoin/bitcoin/pull/21399
< jnewbery> ariard: luke-jr doesn't own the bips repo. He's the steward of a shared resource. He's abusing that stewardship
< jnewbery> 1. I think it's probably time to merge https://github.com/bitcoin/bips/pull/1116 (adding Kalle as BIP editor). It was proposed three weeks ago, has 15 ACKs, and no substantive opposition.
< Arvidt> What is that version "v22.0" on the last line of https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md ? Is it not Bitcoin version (they all start with v0.) ? Would make sense, since V.0.22 is not released yet and there are backports to 0.20 and 0.21 ongoing.
< bitcoin-git> bitcoin/master faf30f2 MarcoFalke: doc: Update bips.md for 0.21.1
< bitcoin-git> bitcoin/master db2990d MarcoFalke: Merge bitcoin/bitcoin#21925: doc: Update bips.md for 0.21.1
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21925: doc: Update bips.md for 0.21.1 (master...2105-docBips) https://github.com/bitcoin/bitcoin/pull/21925
< luke-jr> hugohn: sorry, I'm very backlogged on bips :/ I'll try to get to it soon
< hugohn> @luke-jr can you take another look at https://github.com/bitcoin/bips/pull/1097 ? Thanks.

2021-05-12

< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21925: doc: Update bips.md for 0.21.1 (master...2105-docBips) https://github.com/bitcoin/bitcoin/pull/21925

2021-05-07

< luke-jr> conman: I was just pointing out it's been documented explicitly as *not* required since 2012 https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki

2021-05-06

< jeremyrubin> for the caching I don't want to rename it because i did it to match the bip341 style
< jeremyrubin> bip341 did this in caches?
< jeremyrubin> pyskell suggested s/bip119/ctv
< jeremyrubin> responding to https://github.com/bitcoin/bitcoin/pull/21702#discussion_r616863828 shedcolor comment, does anyone have any feelings on renaming "StandardTemplateHash" to "BIP119Hash" and renaming "BasicStandardTemplate" to "StandardBareBIP119Output"?

2021-05-05

< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21862: test: Set regtest.BIP65Height = 112 to speed up tests (master...2105-testFasterBip65) https://github.com/bitcoin/bitcoin/pull/21862

2021-05-04

< hugohn> @luke-jr the inclusion of things like NO_ENCRYPTION mode and BIP39-like PBKDF2 function parameters in the spec is to help with backward compatibility. IMO the main thing that might not be backward compatible with all vendors is the stateful nature of the Signers, which I have stated in the Compatibility section.
< michaelfolkson> hugohn: I personally think it would be overkill to give the BIPs repo its own org
< michaelfolkson> hugohn: They aren't really bundled with the Core project. It is true the BIPs repo is under the Bitcoin Core GitHub org but no Bitcoin Core maintainers merge BIP PRs afaik so I think it is fine under the Core org
< michaelfolkson> I think there will be future discussions on a revised BIP process once (hopefully) Taproot activation is completed hugohn if you'd like to engage with that https://github.com/bitcoin/bips/pull/1015
< wumpus> in any case, this discussion is kind of off-topic here, the bitcoin core project is one implementation, that the current BIPs repository is in the same orginazation is a historical artifact, it does not mean BIPs 'belong' to bitcoin core or something like that
< wumpus> you mean like BIP1 and 2?
< hugohn> right. if it's not a simple sequence generator, a BIP on BIPs probably makes more sense.
< hugohn> hi, I'm curious what else needs to be done before https://github.com/bitcoin/bips/pull/1097 can get a BIP number assigned?

2021-05-03

< rebroad> MarcoFalke this was the pull request I had assumed had been merged - https://github.com/bitcoin/bips/pull/443
< rebroad> MarcoFalke i only just realised that BIP111 didn't get updated with the changes I proposed back in 2016... so yeah, nevermind... i guess i wasn't keeping my eye on the ball back in 2016!

2021-05-01

< hsjoberg> Yeah thanks, that's what I thought as well, and AFAICT the reason why we even have such high threshold for BIP9

2021-04-28

< sipa> BIP342 specifically contains a (somewhat unrelated) improvement of introducing "key versions", specifically intended for things like that
< sipa> depends on whether you mean taproot in reference to the technology to tweak keys as a commitment scheme, or the BIP341/BIP342 proposal

2021-04-25

< luke-jr> I'm down to 8 tabs of BIPs PRs, one of which is presumably 1104; I don't know how involved the tab(s) before that are to go through
< luke-jr> if someone wants to help me get caught up on BIPs PRs, this one looks annoying to figure out if technically sound: https://github.com/bitcoin/bips/pull/1107/files

2021-04-22

< luke-jr> achow101: is https://github.com/bitcoin/bips/pull/1100 a NACK?
< murch> Well, some wallets implemented experimental Taproot support before BIP350
< luke-jr> jeremyrubin: BIPs PRs merging slowly is not a new thing at all.
< luke-jr> harding: right now, I'm churning through dealing with the rebase of BIP8 on top of the ST stuff. I suppose that might go faster if there were people willing to review it. But frankly then it almost sounds like I'm holding the BIPs hostage, and I don't want to do that either.
< luke-jr> as a reminder, though, BIPs *are* just documentation, so there really shouldn't need to be a rush
< meshcollider> jeremyrubin: I interpret that "long winded discussion" bit to be about the BIPs themselves, not the process of adding an editor
< jnewbery> it does seem somewhat of a centralization problem. The BIPs repo is a venue for sharing proposed changes to Bitcoin, and one person decides who can update it, and also decides whether or not they should ever be replaced/supplemented?
< ariard> jeremyrubin: on the other point, I don't think bip2 recommend bitcoin-core-dev as a venue, maybe better suitted to #bitcoin or #bitcoin-wizards
< wumpus> right the role of BIP editors is to follow the BIP1/2 process, not to pass personal judgement on BIPs besides very basic style criteria
< jeremyrubin> As far as you've represented previously, you haven't had time to even look at the BIP341 changes which is why it's not merged.
< jnewbery> I suggest that we lighten his load by adding a second BIP editor. BIP2 allows multiple BIP editors and refers to plural BIP editors in several places, eg "The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and update BIP headers as appropriate."
< bitcoin-git> bitcoin/master dbc1981 Sebastian Falbesoner: test: check that _all_ invalid-CLTV txs are allowed in a block pre-BIP65

2021-04-20

< ariard> sipa: i agree, the best you can hope is an economic compatible tx-relay policy widely deployed on the network like bip125

2021-04-16

< aj> release notes and an update of bips.md ("without mainnet activation") probably should be done before rc1?

2021-04-15

< kallewoof> luke-jr: You mean like https://github.com/bitcoin/bips/pull/1015 ? I don't have a preference personally.
< luke-jr> kallewoof: maybe there should be a new BIP, also eliminating BIP Comments and adding Markdown back into the mix. certain people have decided to skip BIPs because they don't like people leaving comments, and I can only guess the Lightning BOLT stuff is because they prefer markdown…
< kallewoof> speaking of revisions of BIPs, it would be splendid if https://github.com/bitcoin/bips/pull/1016 moved forward.
< bitcoin-git> [bitcoin] luke-jr closed pull request #19573: Replace unused BIP 9 logic with draft BIP 8 (master...bip8) https://github.com/bitcoin/bitcoin/pull/19573
< luke-jr> thanks. but I'm not sure there's any point if the BIP9-pushing group is going to prevent a merge
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #19573: Replace unused BIP 9 logic with draft BIP 8 (master...bip8) https://github.com/bitcoin/bitcoin/pull/19573
< luke-jr> ultimately BIP9 uses starttime to choose a height based on difficulty-period boundaries (2 weeks long)
< luke-jr> provoostenator: after all, it had plenty of review and was RTM weeks before this BIP9 stuff, and still wasn't merged anyway
< luke-jr> provoostenator: MarcoFalke already blocked me from doing so; I have no reason to expect decent behaviour from devs strongarming BIP9 back in at this point anyway. Something is clearly going on behind the scenes.
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #19573: Replace unused BIP 9 logic with draft BIP 8 (master...bip8) https://github.com/bitcoin/bitcoin/pull/19573
< bitcoin-git> [bitcoin] fanquake merged pull request #21377: Speedy trial support for versionbits (master...202103-bip9-speedy-trial-support) https://github.com/bitcoin/bitcoin/pull/21377

2021-04-14

< luke-jr> or to be more correct, people who don't consider it a triviality, are unanimously in favour of BIP8
< luke-jr> it's not triviality except to BIP9 advocates
< emzy> fwiw I was prefering bip8 and ok with bip9 in the beginning. And I think many thought the same at that time.
< jeremyrubin> Sorry if this is line noise for this channel -- but this is the best job I could do at breaking down the claim that BIP8 has consensus (LOT=?) and ST/MTP does not
< luke-jr> jeremyrubin: BIP8 doesn't require LOT for ST any more than BIP9 does
< jeremyrubin> Overall I feel relativelty confident based on this review dismissing the notion that BIP8 has consensus and ST/MTP does not
< jeremyrubin> Further in support of BIP8's consensus being questionable earlier on, I think harding has had a very good read on the community in general. I don't beleive he would have included BIP9 in his proposal as an option if he thought the community was decisive
< jeremyrubin> In contrast, the ACKs on harding's proposal (which allows for middle space of BIP8 or BIP9) https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f is much more exhaustive and explicit
< jeremyrubin> Further, the type of consensus around BIP8 in these meeting logs (maybe it's somewhere else, figure the meetings are more relevant than twitter/reddit) is not super high quality IMO because it's mainly ACK'ing the properties of BIP8 as opposed to the specific implementation
< jeremyrubin> "but we already agreed to XXX for BIP8" doesn't hold when a keystone component of BIP8 (LOT) is what made ST a thing in the first place.
< jeremyrubin> so it seems inaccurate to me to label BIP8 as having consensus when a key parameter did not
< jeremyrubin> I can see why luke-jr and michaelfolkson think there might be consensus on BIP8, but I think they are viewing the process as "gradient descent on a continuos surface" as opposed to a discontinuous process.
< jeremyrubin> and BIP8 requires *a choice* of that
< jeremyrubin> BIPs are often descriptive
< jeremyrubin> (in fact, it's usually preferable to be descriptive otherwise we have useless BIPs clogging the numberspace)
< jeremyrubin> in fact at this point it probably has more review than any BIP8 anything has ever had
< jeremyrubin> and you've extrapolated BIP9 RIP ==> MTP cannot be used
< jeremyrubin> I see people caring about the *properties* of BIP8 vs BIP9, not excluding MTP being used in the future
< jeremyrubin> reading through http://gnusha.org/taproot-activation/2021-02-02.log, based on which michaelfolkson bases claim that BIP9 is "dead" and therefore MTP can't be used, TBH I just don't see that being the emergent agreement
< luke-jr> anyway, how things get documented in BIPs is trivial in comparison to the real issues
< jeremyrubin> luke-jr: community's consensus aroudn BIP8 WHERE
< jeremyrubin> What test is BIP8 passing that 21377 is not
< luke-jr> the community is almost unanimous in favour of BIP8
< luke-jr> ST/BIP8 had (has?) widespread support, not ST/BIP9
< luke-jr> most have never even heard of 21377, and it is opposed to the community's consensus aroudn BIP8
< jeremyrubin> Luke, what test is BIP8 passing w.r.t. consensus that ST is not?
< jeremyrubin> he's consistently failed to answer questions like "what is incompatible with ST" or "what definition of consensus are you using that passes BIP8 and not ST"
< jeremyrubin> What is BIP8 LOT=? satisfying
< jeremyrubin> Maybe remove BIP8 LOT=true?
< jeremyrubin> luke-jr can you give a definition for what consensus is? Is there a concrete and consistent definition you are applying that BIP8 LOT=true is satisfying that the current ST MTP start/stop + height of activation minimum is not meeting that can be applied here and in the future?
< jonatack> jamesob: achow101: same, i'm still reviewing. did a first pass to get the code and bips in my head, need to do another one
< luke-jr> sipa: there is agreement on BIP8, yes
< jeremyrubin> I'll reiterate here: luke-jr luke-jr can you give a definition for what consensus is? Is there a concrete and consistent definition you are applying that BIP8 LOT=true is satisfying that the current ST MTP start/stop + height of activation minimum is not meeting that can be applied here and in the future?

2021-04-12

< sipa> luke-jr: BIP68 treats it as signed, afaik

2021-04-08

< luke-jr> anyone involved in the community knows there is consensus around BIP8.
< jeremyrubin> which says: " The idea can be implemented on top of either Bitcoin Core's existing BIP9 code or its proposed BIP8 patchset.[6]"
< luke-jr> achow101: I didn't say that, but it's far fewer than the consensus around BIP8
< wumpus> #topic Attempts to use "dev muscle" to force MTP against community consensus of BIP8 (luke-jr)
< core-meetingbot> topic: Attempts to use "dev muscle" to force MTP against community consensus of BIP8 (luke-jr)
< wumpus> one proposed meeting topic: attempts to use "dev muscle" to force MTP against community consensus of BIP8 (luke-jr)
< luke-jr> #proposedmeetingtopic attempts to use "dev muscle" to force MTP against community consensus of BIP8

2021-04-07

< bitcoin-git> [bitcoin] luke-jr reopened pull request #19573: Replace unused BIP 9 logic with draft BIP 8 (master...bip8) https://github.com/bitcoin/bitcoin/pull/19573

2021-04-06

< bitcoin-git> [bitcoin] achow101 closed pull request #21507: Implement BIP8 lockinontimeout (master...bip8) https://github.com/bitcoin/bitcoin/pull/21507
< bitcoin-git> [bitcoin] achow101 closed pull request #21392: Implement BIP 8 based Speedy Trial activation (master...bip8-speedy-trial) https://github.com/bitcoin/bitcoin/pull/21392
< bitcoin-git> bitcoin/master 06030f7 W. J. van der Laan: contrib: generate-seeds.py generates output in BIP155 format

2021-03-25

< luke-jr> thought we were trying to give sipa the floor for BIP350
< jeremyrubin> Either can be compatible with a subsequent BIP8 release
< ariard> i've reviewed both, i've a preference for bip9-amendment, would review both anyway
< luke-jr> sipa: not sure why BIP350 would be eligible for backporting at all
< wumpus> #topic How far do we want to backport BIP350/bech32m support? (sipa)
< sipa> oh short topic: how far do we want to backport BIP350/bech32m support?

2021-03-23

< bitcoin-git> [bitcoin] luke-jr closed pull request #21460: BIP8: Minimal common changes (master...bip8_minimal) https://github.com/bitcoin/bitcoin/pull/21460

2021-03-22

< bitcoin-git> [bitcoin] achow101 opened pull request #21507: Implement BIP8 lockinontimeout (master...bip8) https://github.com/bitcoin/bitcoin/pull/21507

2021-03-18

< jeremyrubin> I don't think "BIP9 is dead" is useful here

2021-03-17

< bitcoin-git> [bitcoin] luke-jr opened pull request #21460: BIP8: Minimal common changes (master...bip8_minimal) https://github.com/bitcoin/bitcoin/pull/21460

2021-03-09

< sipa> amiti: i think that's fair... i also don't really know what the issue would be with a sendaddrtypes message with a bitvector of bip155 network types for example (apart from not wanting to deal with that too right now)
< sipa> aj: i think ariard is trying to point out that bip37/bip60 only talk about *announcing* transactions, not sending (possibly unannounced) transactions
< ariard> aj: right but imo current bip60 semantic isn't clear with what the sender is allowed to do
< sipa> if you're going by reading the spec by the letter... what does bip60"s fRelay flag even mean for a client that chooses not.to implement bip37?
< aj> ariard: I run a -blocksonly node. You run a bip60 compliant node. I tell you fRelay=false. You don't send me any txes. You told me fRelay=true. Therefore I can send you a tx, without violating bip60.
< ariard> aj: my point was bip37 original scope was unclear if it concerns only inv(tx) or any tx-related message, bip338 has the merit to clarify
< bitcoin-git> [bitcoin] luke-jr opened pull request #21399: Genericide BIP9 in variable/type names and comments (master...vbits_rename) https://github.com/bitcoin/bitcoin/pull/21399

2021-03-08

< bitcoin-git> [bitcoin] achow101 opened pull request #21392: Implement BIP 8 based Speedy Trial activation (master...bip8-speedy-trial) https://github.com/bitcoin/bitcoin/pull/21392

2021-03-07

< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21334: test: Additional (refactored) BIP9 tests (master...2021/03/bip9_tests) https://github.com/bitcoin/bitcoin/pull/21334
< bitcoin-git> bitcoin/master 1020b04 MarcoFalke: Merge #21334: test: Additional (refactored) BIP9 tests

2021-03-06

< bitcoin-git> [bitcoin] ajtowns opened pull request #21377: Speedy trial support for versionbits (master...202103-bip9-speedy-trial-support) https://github.com/bitcoin/bitcoin/pull/21377

2021-03-04

< achow101> andytoshi: I've pushed the updated tests to my bips pr too
< andytoshi> achow101: in BIP174, the test vector "PSBT with unknown types in the inputs" describes an input which has keytype 0x0f and key 0102030405060708. this is a valid PSBT
< sipa> so i guess we could list BIP60 as implemented, actually
< MarcoFalke> Bitcoin Core implements BIP60, but doesn't require peers to implement it. (Like any other optional BIP)
< ariard> even the original bip37 is really unclear if fRelay semantic is to disable tx-relay or just tx-announcement
< sdaftuar> sipa: but we're compatible with bip60 peers, and i think we now expect our peers to always read our fRelay flag if its' set to false, right?
< luke-jr> it doesn't require breakign non-BIP60 peers
< sipa> luke-jr: BIP60 is about predictably-sized version messages, not just the fRelay flag
< ariard> MarcoFalke: i mean here https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md, for a dev writing another bitcoin client and trying to understand core behavior
< sipa> we don't support bip60 and never have
< ariard> fwiw, core doesn't even commit to bip60 as a supported bip
< MarcoFalke> so replace BIP338 with a breaking p2p change and blocksonly meaning "feefilter=max"?
< sdaftuar> MarcoFalke: well my guess is that bip37/bip60 is more widely supported on the network. feefilter has always been optional
< jnewbery> MarcoFalke: BIP60 is version 70002. feefilter is version 70013.

2021-03-02

< bitcoin-git> [bitcoin] Sjors opened pull request #21334: Additional (refactored) BIP9 tests (master...2021/03/bip9_tests) https://github.com/bitcoin/bitcoin/pull/21334

2021-02-28

< sipa> it'd probably not be a bad idea to have bip32 derivation in the test framework

2021-02-26

< michaelfolkson> "I like a hidden option in Core which is always there from day one, which is lot=true or taproot-bip8-lot-true or something that would change lockinontimeout to true and also change the default user agent string so you can tell people are running it. That’s good because by the time 6 months comes almost everyone has upgraded anyway, they’ve just got to change their config." (From the Sydney Socratic)
< sipa> you may mean bip147
< shesek> (NULLDUMMY being validness rather than standardness as of bip62)
< sipa_> bip62 is not consensus

2021-02-22

< bitcoin-git> [gui] MarcoFalke merged pull request #206: Display fRelayTxes and bip152_highbandwidth_{to, from} in peer details (master...add-fields-to-peer-details) https://github.com/bitcoin-core/gui/pull/206

2021-02-20

< wumpus> i think what i need is a way to generate a *derived xpub* for a custom path in the wallet, i can do this with external tooling (e.g. darosior's bip32 python module), but afaik not from bitcoin core itself?

2021-02-17

< jb55> I don't even think recommending bip39 support to 'newbies' would be a good idea. ideally there would be an easy way to connect a hardware wallet and get descriptors that way vs bip39 on your computer
< sipa> there are a few things that can be worked on towards supporting that, like descriptor export, getting descriptor wallets in general less experimental, and things like bip39 support in descriptors directly
< sipa> there is an issue for BIP39 support in descriptors somewhere

2021-02-13

< bitcoin-git> bitcoin/master c943326 Luke Dashjr: doc/bips: Add BIPs 43, 44, 49, and 84
< bitcoin-git> [bitcoin] laanwj merged pull request #21028: doc/bips: Add BIPs 43, 44, 49, and 84 (master...bips_44-49-84) https://github.com/bitcoin/bitcoin/pull/21028
< bitcoin-git> bitcoin/master b08cbd0 Wladimir J. van der Laan: Merge #21028: doc/bips: Add BIPs 43, 44, 49, and 84

2021-02-12

< sipa> well, because multi doesn't exist in bip342 (no OP_CHECKMULTISIG due to not batch verifiable)

2021-02-10

< bitcoin-git> [bitcoin] danben opened pull request #21144: test: convert feature_bip_sequence.py to use MiniWallet (master...test-feature-bip68-sequence-without-wallet) https://github.com/bitcoin/bitcoin/pull/21144

2021-02-09

< bioverse> I have a nano ledger s with some bitcoin. I have the 24 words and wallet in a safe place. I went to https://iancoleman.io/bip39/ using a Ubuntu live from USB. I put the 24 mnemonic words and could not find any bitcoin address ever used. I freaked. I thought. Oh my god! I ordered a second brand new nano ledger s. Put the 24 words, using ledger live in a brand new laptop and my coins were there in the brand new ledger nano s. I am safe. But I have

2021-02-05

< bitcoin-git> bitcoin/master e1e6714 Jon Atack: doc: refer to BIPs 339/155 in feature negotiation
< bitcoin-git> [bitcoin] laanwj merged pull request #20646: doc: refer to BIPs 339/155 in feature negotiation (master...signet-keep-post-verack-sendaddrv2-peers) https://github.com/bitcoin/bitcoin/pull/20646
< bitcoin-git> bitcoin/master 3931732 Wladimir J. van der Laan: Merge #20646: doc: refer to BIPs 339/155 in feature negotiation
< bitcoin-git> [bitcoin] jonatack reopened pull request #20646: doc: refer to BIPs 339/155 in feature negotiation (master...signet-keep-post-verack-sendaddrv2-peers) https://github.com/bitcoin/bitcoin/pull/20646
< bitcoin-git> [bitcoin] jonatack closed pull request #20646: doc: refer to BIPs 339/155 in feature negotiation (master...signet-keep-post-verack-sendaddrv2-peers) https://github.com/bitcoin/bitcoin/pull/20646
< dr_orlovsky> so BIP43-type new purpose value for P2TR will be a good solution in this respect as well?
< sipa> i guess that means this whole point is moot, and we should probably have a deep look at proving security of ECDSA and Schnorr signatures of linearly related keys (as those created by P2C-tweaking or BIP32 derivation result)
< sipa> yeah, you'll probably want a separate bip32 path for P2TR outputs; but that has nothing to do with ECDSA/Schnorr; you just don't want to reuse the same keys
< sipa> i don't know if that needs a standard like BIP43 - perhaps it helps

2021-02-04

< aj> sdaftuar: maybe you should game the system and post your bips on stackoverflow?
< jonatack> jonasschnelli: ok. i thought it might be the blocker for bip324 impl

2021-02-03

< luke-jr> sdaftuar: yeah, I'll get to BIPs later today

2021-02-01

< bitcoin-git> [gui] jonatack opened pull request #206: Display fRelayTxes and bip152_highbandwidth_{to, from} in peer details (master...add-fields-to-peer-details) https://github.com/bitcoin-core/gui/pull/206

2021-01-29

< bitcoin-git> [bitcoin] luke-jr opened pull request #21028: doc/bips: Add BIPs 44, 49, and 84 (master...bips_44-49-84) https://github.com/bitcoin/bitcoin/pull/21028

2021-01-28

< sipa> luke-jr: can i have a BIP number for bip-bech32m? (there are a few other things in the bips repo that want your attention too, i think)

2021-01-25

< bitcoin-git> [bitcoin] achow101 closed pull request #16463: [BIP 174] Implement serialization support for GLOBAL_XPUB field. (master...bip174-xpub) https://github.com/bitcoin/bitcoin/pull/16463

2021-01-21

< nickler> luke-jr: what are the relevant PRs and issues? The two from aj to the BIP8 and your #19573?
< sdaftuar> sipa: whether bips are the right place or not is unclear to me, but i think communicating relay policies like this so that 3rd party wallets know what behavior to aim for is helpful. in the case of bip125, my hesitation towards amending or redrafting is that we should fix the implementation in other ways anyway
< sipa> if there really is a discrepancy between bip125 and what bitcoin core implements, it could be mentioned in doc/bips.md
< sipa> i don't think these things belong in BIPs

2021-01-20

< pinheadmz> is BIP125 (RBF) accurate with the implementation? Specifically, is it the absolute fees that are compared between replaces and replacing tx? or the fee rate?

2021-01-12

< sipa> BIP141 defines witness script
< jeremyrubin> I think where I got confused is (non-core, going to move convo to appropriate channel) https://docs.rs/bitcoin/0.25.2/bitcoin/util/bip143/struct.SigHashCache.html#method.signature_hash requires a scriptcode field
< sdaftuar> sipa: my understanding as well that there are no BIPs on it
< sipa> i don't think it's unreasonable to recommend not relaying addresses to disabletx peers; so far addr relay is completely local policy anyway with no BIPs discussing it at all afaik
< jnewbery> sdaftuar: do you have any further thoughts about what a future addr relay negotiation method would look like? I know you were pushing for something similar with BIP155
< sdaftuar> but to do all that, we need to give nodes a way to know that an inbound peer is a block-relay-only peer. currently block-relay-only peers use the fRelay flag from BIP37 to instruct their peer they don't want transactions
< sdaftuar> but BIP37 allows for transaction relay to resume with a FILTERCLEAR message

2021-01-10

< luke-jr> bips.md?
< sipa> sdaftuar_: also added a mention of BIP339 in the release notes

2021-01-04

< vasild> but I failed to verify the callers of the constructor CSubNet(CNetAddr&) which used to create one-host-subnet before and would also "work" for torv2 addresses (in the code before bip155) by matching a single address
< vasild> jonatack: when I extended CNetAddr to support longer-than-16-bytes addresses (as part of bip155) I also changed CSubNet to only handle ipv4 and ipv6 addresses - because it contains char netmask[16]; it makes no sense to apply it to e.g. 32 byte torv3 address

2020-12-29

< bitcoin-git> [bitcoin] kallewoof closed pull request #20154: BIP-322 support (master...202010-bip322) https://github.com/bitcoin/bitcoin/pull/20154

2020-12-24

< bitcoin-git> bitcoin/master cc592a8 MarcoFalke: Merge #20189: test: Switch to BIP341's suggested scheme for outputs withou...
< bitcoin-git> bitcoin/master 812baaa Pieter Wuille: Switch to BIP341's suggested scheme for outputs without script
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20189: test: Switch to BIP341's suggested scheme for outputs without script (master...202010_taproot_std_noscript) https://github.com/bitcoin/bitcoin/pull/20189

2020-12-16

< jnewbery> If you consider BIP37 and optional standard, then it's not really a violation of the protocol to send tx INVs after receiving a version with fRelay = false
< vasild> eventually, maybe we would update bip155 to mandate the i2p addr size is allowed to be either 32 or 35 bytes

2020-12-14

< bitcoin-git> bitcoin/master 4b7b58b Jon Atack: Update net_processing WTXID documentation per BIP339
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20592: doc: update wtxidrelay documentation per BIP339 (master...update-wtxid-documentation-per-BIP339) https://github.com/bitcoin/bitcoin/pull/20592
< bitcoin-git> bitcoin/master 096bd37 MarcoFalke: Merge #20592: doc: update wtxidrelay documentation per BIP339

2020-12-11

< wumpus> this is the best reference of course: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki

2020-12-10

< sipa> i missed that push too; i just found it funny due to name confusion with BIP9's versionbits
< bitcoin-git> bitcoin/master dab6583 Sebastian Falbesoner: doc: release note for new getpeerinfo fields "bip152_hb_{from,to}"

2020-12-08

< vasild> jnewbery: I am ok with you doing the announcement wrt bip155 change

2020-12-07

< bitcoin-git> [bitcoin] jonatack opened pull request #20592: p2p: update wtxidrelay documentation per BIP339 (master...update-wtxid-documentation-per-BIP339) https://github.com/bitcoin/bitcoin/pull/20592
< vasild> updated https://github.com/bitcoin/bips/pull/1043 - "send sendaddrv2 berfore sending verack"
< vasild> sipa: wumpus: wrt sending sendaddrv2 and the difference between the code and the BIP, I opened https://github.com/bitcoin/bips/pull/1043 to change the BIP.

2020-12-05

< pinheadmz> re: coordination though - BIPs are good places to pick service bits, etc at the community level - thats not really "bitcoin core deciding:
< pinheadmz> i see yeah reading up the chatter on bip155 PR as well...

2020-12-04

< wumpus> e.g. https://github.com/bitcoin/bips/pull/766 had some of the most fruitful discussion
< wumpus> ... even less interest and we might as well puglish BIPs directly into the arctic code vault
< jonasschnelli> It might lead to more reluctant testing and lesser interest to read BIPs more carefully
< jonasschnelli> <wumpus> my first public draft was apparently june 1, 2018, I posted it to the mailing list feb 18, 2019 (there we no replies at all), I created the PR for the BIPs repository on feb 27, 2019, it was merged jul 23, 2019. Vasild picked up the implementation april this year, and quite quickly had a working implementation (though some other detailed were still ironed out). [...]
< wumpus> but it's too frustrating for me personally and I don't think I'll be working on BIPs again
< wumpus> my first public draft was apparently june 1, 2018, I posted it to the mailing list feb 18, 2019 (there we no replies at all), I created the PR for the BIPs repository on feb 27, 2019, it was merged jul 23, 2019. Vasild picked up the implementation april this year, and quite quickly had a working implementation (though some other detailed were still ironed out). It was discussed in

2020-12-03

< luke-jr> until we switch to BIP324
< luke-jr> (we can just add new features only within the context of BIP324)
< luke-jr> as long as we ensure they can't continue their silliness into BIP324, at least it has an end date?
< jonasschnelli> BIP324 is probably different since we want to get disconnected when the handshake is not supported
< jonasschnelli> Its not even messages in BIP324,.. its the handshake that is headerless
< * sipa> points at BIP324
< luke-jr> IANA and BIPs aren't that different
< sdaftuar> i am not sure an updated version of bip155 was ever sent to the mailing list describing that the version bump was being dropped. so it's hard to blame them, imo, other than for a long-running misunderstanding of how we think unknown messaegs should be treated
< luke-jr> sdaftuar: we also have no authority to impose BIP155 on them anyway
< sdaftuar> what's the status of sendaddrv2/bip155, there was a report that it caused other peers to disconnect us i think?

2020-12-01

< jnewbery> vasild: your suggested change to BIP155 isn't what Bitcoin Core is doing. It sends the message after receiving a version message
< vasild> maybe bip155 should be corrected: "sendaddrv2 SHOULD be sent after receiving the verack message" s/receiving/sending/
< sipa> *bip155
< sipa> i'm happy we got bip154 in 0.21, but this isn't the time to change it anymore...
< jnewbery> in BIP 155, it says "sendaddrv2 SHOULD be sent after receiving the verack message from the peer": https://github.com/bitcoin/bips/blob/7e3284dafda168da34888977dbf4a55519b0c54d/bip-0155.mediawiki#L137

2020-11-19

< gribble> https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub

2020-11-17

< jonatack> troygiorshev: thank you, i meant BIP324 :)
< gribble> https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< troygiorshev> I'm also paying attention to BIP324 #18242

2020-11-16

< bitcoin-git> [bitcoin] mateusz-klatt closed pull request #20361: Descriptor Wallets BIP39 recovery (master...master) https://github.com/bitcoin/bitcoin/pull/20361

2020-11-12

< jonatack> michaelfolkson: when reviewing, sometimes running them for less than a minute finds things, e.g. was the case for the BIP324 implementation
< jonasschnelli> warren: BIP324
< warren> jonasschnelli: btw whatever happened to BIP150/151. Looking at BIPs now I don't see a replacement that supersedes them?

2020-11-10

< bitcoin-git> [bitcoin] mateusz-klatt opened pull request #20361: load wallets from entropy (as BIP39) (master...master) https://github.com/bitcoin/bitcoin/pull/20361

2020-11-04

< S3RK> question about fuzzing. we use regtest chain params, but in corups for src/test/fuzz/descriptor_parse.cpp I see xprv keys. As a result fuzzing don't cover code paths with valid keys for bip32 decriptors. I tried to add initial seeds with tprv, but fuzzer doesn't detect any new edges covered. What do I miss?

2020-11-03

< jonasschnelli> I haven't seen BIP324 discussion about the missing backward secrecy of the current rekeying approach.
< sipa> as long as we don't worry about secrecy in the other direction (which the current bip324 writeup doesn't, afaik), i think this is very much preferable
< jonasschnelli> I wanted to ask about BIP324's rekeying
< gribble> https://github.com/bitcoin/bitcoin/issues/20119 | BIP155 follow-ups by sipa · Pull Request #20119 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19954 | Complete the BIP155 implementation and upgrade to TORv3 by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19954 | Complete the BIP155 implementation and upgrade to TORv3 by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< S3RK> question about fuzzing. we use regtest chain params, but in corups for src/test/fuzz/descriptor_parse.cpp I see xprv keys. As a result fuzzing don't cover code paths with valid keys for bip32 decriptors. I tried to add initial seeds with tprv, but fuzzer doesn't detect any new edges covered. What do I miss?

2020-11-01

< brianddk> Why does everything in bitcoin use double hash (HASH256) except BIP141 (P2WSH): https://www.reddit.com/r/Bitcoin/comments/jm9s2z/

2020-10-27

< sipa> bip322 proves the ability to spend coins sent to a particular bitcoin address; a lightning equivalent sounds like it would need a lightning-specific solution

2020-10-19

< bitcoin-git> [bitcoin] sipa opened pull request #20189: Switch to BIP341's suggested scheme for outputs without script (master...202010_taproot_std_noscript) https://github.com/bitcoin/bitcoin/pull/20189

2020-10-16

< bitcoin-git> bitcoin/master 5669642 Pieter Wuille: docs: mention BIPs 340-342 in doc/bips.md

2020-10-15

< sipa> there is one context where we actually treat someone with a private key as an attacker in BIP340, and it's a rather unusual requirement: nobody (even those with private keys) should be able to construct a signature for which the single-sig validation and batch-validation algorithm produce a different result (with more than negligible probability)
< phantomcircuit> sipa, yeah i understand now, i was confused by the bip340 language about malleability
< sipa> phantomcircuit: to be clear, the bip340 signing algorithm is deterministic if no auxiliary randomness is used
< bitcoin-git> [bitcoin] kallewoof opened pull request #20154: BIP-322 support (master...202010-bip322) https://github.com/bitcoin/bitcoin/pull/20154

2020-10-14

< sipa> it's undergoing heavy changes right now: https://github.com/bitcoin/bips/pull/1003
< andytoshi> generic signed message format, by kalle, https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
< andytoshi> has anyone here implemented BIP322? i am working on an implementation and have some questions about the bip

2020-10-12

< bitcoin-git> [bitcoin] fanquake merged pull request #20119: BIP155 follow-ups (master...202010_bip155_followup) https://github.com/bitcoin/bitcoin/pull/20119
< bitcoin-git> bitcoin/master 79f3d9b Pieter Wuille: Mention BIP155 in doc/bips.md
< bitcoin-git> bitcoin/master af22322 fanquake: Merge #20119: BIP155 follow-ups

2020-10-11

< ja> luke-jr: when would an ack be necessary for marking 'obsolete'? i thought it would be analogous to 'final' which you seem to wait for an explicit ack for here: https://github.com/bitcoin/bips/pull/926
< ja> wooow, i got an ack from Gavin! https://github.com/bitcoin/bips/pull/1010
< sipa> Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month.
< vasild> https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki "Status: Draft" -- should the status be changed?
< gribble> https://github.com/bitcoin/bitcoin/issues/19954 | Complete the BIP155 implementation and upgrade to TORv3 by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] sipa opened pull request #20119: BIP155 follow-ups (master...202010_bip155_followup) https://github.com/bitcoin/bitcoin/pull/20119
< bitcoin-git> [bitcoin] fanquake merged pull request #19954: Complete the BIP155 implementation and upgrade to TORv3 (master...torv3) https://github.com/bitcoin/bitcoin/pull/19954

2020-10-10

< ariard> vasild: I'm still not understanding how a BIP155 node is supposed to discover the list of network IDs supported by its BIP155-peers ?

2020-10-09

< sipa> (and the usage in bip152 is restricted to 16-bit numbers, which obviously won't have any problems)

2020-10-08

< sipa> i guess we overlooked that in bip152, where it's also not used as a size, but restricted to pretty small numbers
< sipa> it is as BIP42 predicted
< jonatack> to summarize, if I may: before feature freeze in one week, please review 19953 (BIPs 340-342), 19954 (tor v3), 19988 (tx relay logic), and 19077 (sqlite wallet)

2020-10-03

< bitcoin-git> [bitcoin] robot-dreams opened pull request #20074: test: p2p_blockfilters tests for BIP157 config args (master...bip157-blockfilters-tests) https://github.com/bitcoin/bitcoin/pull/20074
< wumpus> the higher level question would be 'should AddrMan be entirely disabled in some cases', we had some related discussion wrt. that for BIP155 for making it possible for nodes to signal that they don't take part in address gossip

2020-10-02

< bitcoin-git> [bitcoin] jonatack closed pull request #19720: test: bip157 p2p_blockfilters configuration options (master...bip157-blockfilters-tests) https://github.com/bitcoin/bitcoin/pull/19720

2020-10-01

< aj> luke-jr: ping re bips PRs 978 and 1000

2020-09-29

< bitcoin-git> [bitcoin] vasild closed pull request #19031: Implement ADDRv2 support (part of BIP155) (master...addrv2) https://github.com/bitcoin/bitcoin/pull/19031

2020-09-27

< hebasto> why bip155 appendix B does not specify that H() is actually SHA3_256 ?

2020-09-23

< vasild> luke-jr: https://github.com/bitcoin/bips/pull/907 can be merged? It has 4 ACKs, including from the BIP author (wumpus).

2020-09-22

< gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub
< sdaftuar> jnewbery: thanks i was just going to say that it's not clear to me that BIPs are the right place either
< jnewbery> I don't think p2p policy belongs in BIPs. https://github.com/bitcoin-core/bitcoin-devwiki/wiki seems like a more appropriate place for it

2020-09-20

2020-09-17

< sipa> wumpus: also, ack bip155 changes, as those need to be stable before 0.21 if we want it :)
< vasild> I agree it is out of scope, but I also think "I participate in gossip" is out of scope for bip155, if we consider that its purpose is to support larger than 16 byte addresses
< wumpus> things like that were proposed before, though never in the for of a BIP afaik, but I think that's out of scope of BIP155

2020-09-16

< vasild> Wrt the next bip155/torv3 PR, assuming #19845 gets merged - #19031 has two more commits "net: CAddress & CAddrMan: (un)serialize as ADDRv2" (+193/-15) and "net: advertise support for ADDRv2 via new message" (+129/-8). Then we will have done BIP155 - will gossip torv3/i2p/cjdns addresses if we receive them (even though we may not be able to make use of them yet). After that we need one more change
< gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub
< midnight> luke-jr: After what's merged, BIP155?
< sipa> won't be useful until they can be rumoured using BIP155

2020-09-14

< bitcoin-git> bitcoin/master ba4b3fb fanquake: Merge #19944: Update secp256k1 subtree (including BIP340 support)