2020-09-14

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

2020-09-11

< sipa> i wonder how much of a bandwidth savings BIP155 will be
< wumpus> phantomcircuit: that's not relevant here, we don't do DNS lookups for bitcoin nodes, and in any case, how a DNS returns is separate from how they're gossiped (which is all that BIP155 is about)
< sipa> (that was the motivation for BIP155 in the first place)
< bitcoin-git> [bitcoin] sipa opened pull request #19944: Update secp256k1 subtree (including BIP340 support) (master...202009_secp256k1_schnorr) https://github.com/bitcoin/bitcoin/pull/19944
< vasild> Which piece of BIP155 looks like (a)?
< sipa> BIP155 makes it sound like (a), at least for TORv2
< sipa> vasild: the way i see it, the P2P is just lagging behind a bit due to no BIP155, but we can easily circumvent that now ;)
< sipa> BIP155 supports up to 512 bytes addresses, but clients will ignore unknown networks/lengths

2020-09-09

< ariard> jonasschnelli: just replied on bip324, AFAICT real-or-random and I favor MACing the length a la noise, even if as Lloyd is pointing we don't a concrete exploitation of it

2020-09-08

< yanmaani> I know, but is there any research being done? Like on BIPs or stuff? I know about utreexo
< sipa> though they were an essential part of BIP37
< sipa> aj: i have a branch where it's half done, but i got preempted by bip340/taproot stuff
< jonatack> quick reminder to review the bip155 and bip324 implementation PRs
< jonasschnelli> sipa, elichai2, real_or_random: what are your thoughts on the BIP342 comment here: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#gistcomment-3345400

2020-09-03

< vasild> Maybe a) can be sneaked into BIP155 as a boolean flag to sendaddrv2 and b) done outside of BIP155 via a service bit?
< vasild> I have been wondering if those two deserve a separate BIP or should be sneaked into BIP155

2020-08-31

< gmaxwell> https://github.com/bitcoin-core/secp256k1/pull/558 looks ready-ish to merge, so if anyone wanted to review ack this updated version that reflects the latest BIP340 changes (even R), it's time!

2020-08-28

< gribble> https://github.com/bitcoin/bitcoin/issues/15845 | wallet: Fast rescan with BIP157 block filters by MarcoFalke · Pull Request #15845 · bitcoin/bitcoin · GitHub
< sipa> kallewoof: fwiw, the powLimit in the signet PR doesn't exactly match the difficulty as specified in BIP325 (the digits after 00002adc28 should be zeroes)

2020-08-27

< sipa> right, this is not about computing our onion address, but to convert between the bip155 encoding and onion addresses
< vasild> https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki#Appendix_B_Tor_v3_address_encoding -- I guess another option would be to send PUBKEY+CHECKSUM instead of just PUBKEY and never calculate the checksum, if adding sha3-256 would be undesirable

2020-08-26

2020-08-25

< vasild> sdaftuar: I like to think that BIP155 addrv2 is just an implementation at this point (no design decisions to be made). However there are two PRs that are yet to be merged into BIP155: https://github.com/bitcoin/bips/pull/907 and https://github.com/bitcoin/bips/pull/967.
< gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub
< jonatack> I think BIP155 addrv2 is a priority, according to vasild the next steps should be smaller and easier
< ariard> sipa: what was llfourn main proposal of change for bip324? He didn't propose to MAC the length field, so no BIP change
< jonatack> BIP324 v2 p2p encrypted message transport protocol: right after the last p2p meeting, jonasschnelli rebased and updated #18242 (changes only used in tests for now) and I've begun re-reviewing it along with the BIP, which has some open questions.
< 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
< jonatack> BIP325 signet: #18267 has been through a few more rounds of review and seems to be getting close, with recent review by fjahr, pinheadz, MarcoFalke, instagibbs, and myself
< jonatack> BIP155 addrv2: #19628 has been receiving review from sipa, elichai, ryanofsky, kallewoof, sipsorceryand myself, and now has 4 ACKs; vasild is deferring further (minor) changes to the PR in order to preserve existing review, but there's no reason to not review it
< jonatack> My prios were BIP155, BIP324, and BIP325 implementation PRs, and they seem to be moving forward.

2020-08-20

< theStack> https://github.com/bitcoin/bips/blob/master/bip-0152/protocol-flow.png <- it seems like the right case (C) works without the "sendcmpct(0)" as well

2020-08-19

< jonatack> review beg also for #19628 needed for BIP155 addrv2

2020-08-14

< bitcoin-git> [bitcoin] jonatack opened pull request #19720: test: bip157 p2p_blockfilters configuration options (master...bip157-blockfilters-tests) https://github.com/bitcoin/bitcoin/pull/19720
< bitcoin-git> bitcoin/master dca2863 Jon Atack: test: ensure OP_1NEGATE satisfies BIP62 minimal push rule

2020-08-12

< gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub

2020-08-11

< vasild> jonatack: troygiorshev: yes, the BIP155 sendaddrv2 can come any time, but we try to do it early so that when the peer is about to advertise his own address to us, he has the option to send us addrv2 - would be important if his address is torv3 because he wouldn't be able to advertise it to us with addr(v1)
< vasild> https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki -- something like that came to my mind when doing the BIP155 sendaddrv2 message. Is every new feature going to add its own message sendfoowhatever? Not very nice.
< ariard> sdaftuar: I think that's good it was unclear between matt and I on bip339 implemn in rust-bitcoin about why 339 bumps both protocol version and wtxid-relay
< jonatack> vasild: i think it's fine to define one's own list of important PRs to review. e.g. longer term for me would be: BIP155/addrv2, BIP324, BIPs340-342, BIP325
< vasild> my priority is to get BIP155 / addrv2 https://github.com/bitcoin/bitcoin/pull/19031 merged.
< sipa> i'm also interested in helping with bip324 efforts and addrv2, though i haven't found much time for that
< gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub
< dongcarl> jonatack: do you have link to bip324 discussion?
< jonatack> i was then asked by a few devs to consider picking up bip324 implementation

2020-08-06

< 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
< 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-08-03

< sipa> warren: BIP324 will replace BIP151
< warren> jonasschnelli: hey. Curious whatever happened to BIP150 and 151. Did that end up getting rolled into a replacement BIP?

2020-07-31

< bitcoin-git> bitcoin/master d362f19 Pieter Wuille: doc: list support for BIP 339 in doc/bips.md

2020-07-29

< sipa> the only exceptions are (1) segwit, which introduced a p2p change along with a consensus change and (2) bip133 feefilter

2020-07-27

< vasild> but I gather "varint" in BIPs may be used to denote what the source code calls compactsize
< vasild> both varint and compactsize are mentioned in some BIPs
< vasild> jonasschnelli: luke-jr: sipa: wumpus: what do you think, (s/VARINT/CompactSize/ in BIP155)?
< vasild> Anyway, given that compact size is used in p2p and not varint, I suggest that we change the spec to say "compactsize" instead of "varint" with some clarification like "For the purposes of this section, CompactSize refers to the variable-length integer encoding used acros..." (from bip152) and also change the code to use compactsize instead of varint (the code is in
< vasild> and "compactsize" is mentioned in 6 BIPs
< vasild> s/8 occurrences/mentioned in 8 BIPs/
< sipa> for BIP152 there was initially an intention to use varint, but it was changed to compactsize to simplify specification
< vasild> Or, well, if in other specs the word "VARINT" is used to mean "compactsize", then should the BIP155 C++ source code use compactsize?
< vasild> Ok, so neither one of varint or compactsize is defined in BIPs, but compact size is already used in other places in the p2p protocol whereas varint is not.
< vasild> BIP155 says:
< sipa> vasild: not in any BIPs afaik; things that existed in the protocol before the BIPs process existed as generally just taken as gospel
< vasild> sipa: I need varint in order to be able to create and parse addrv2 messages: https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki "time" and "services" use VARINT

2020-07-23

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

2020-07-17

< achow101> 2020-06-19.log:16:10 < bsm117532> #proposedwalletmeetingtopic descriptor specification for watch-only wallets, and repeated payments without address use via BIP32 paths

2020-07-12

< bitcoin-git> [bitcoin] jonatack closed pull request #19436: test: ensure `OP_1NEGATE` satisfies BIP62 (master...test-OP_1NEGATE-and-use-OP_RIGHT) https://github.com/bitcoin/bitcoin/pull/19436

2020-07-01

< bitcoin-git> [bitcoin] laanwj merged pull request #19257: build: remove BIP70 configure option (master...remove_bip70_configure) https://github.com/bitcoin/bitcoin/pull/19257
< bitcoin-git> bitcoin/master c4ffcf0 fanquake: build: remove BIP70 configure option
< bitcoin-git> bitcoin/master 9d92ee1 Wladimir J. van der Laan: Merge #19257: build: remove BIP70 configure option

2020-06-25

2020-06-24

< sipa> descriptor checksums have a range of 2^40, so somewhat better than bip32 fingerprints (which are only 2^32)
< shesek> would it make sense to invent one? this could also use a `/` separator like bip32 key origins, though a different character might be better because this doesn't have multiple levels of nesting like key origins
< sipa> (i kind of think that using fingerprints for bip32 was a bad idea too... they're too small to guarantee no collisions)
< shesek> is there a customary notation for referring to the nth script of a descriptor identified by its checksum, akin to <bip32-fingerprint>/<index>?

2020-06-19

< bsm117532> #proposedwalletmeetingtopic descriptor specification for watch-only wallets, and repeated payments without address use via BIP32 paths

2020-06-16

< wumpus> but all new repositories are created under bitcoin-core, at some point, if enough things split off from the main codebase, at some point maybe only the consensus code (and bips) will be left under bitcoin

2020-06-12

< jamesob> This issue of the message handling thread being potentially blocked by indexing (BIP157/158) that jnewbery raised is disconcerting, and separating out the indexing stuff seems more or less in line with the spirit of the process separation work.
< bitcoin-git> [bitcoin] fanquake opened pull request #19257: build: remove BIP70 configure option (master...remove_bip70_configure) https://github.com/bitcoin/bitcoin/pull/19257

2020-06-10

< shesek> is there a customary notation for referring to the nth script of a descriptor identified by its checksum? something like <checksum>/<index>, akin to <bip32-fingerprint>/<index>?

2020-06-04

< sipa> it's fixed (and referenced) in BIP341
< real_or_random> we (the BIPauthors) feel it's in a good state, I think otherwise sipa wouldn't bring this up
< elichai2> I think the big "political" question in terms of merging is if anyone believes that BIP340 doesn't have a good chance of landing in bitcoin core
< nickler> Afaik we've addressed all comments on the BIPS on the mailing list in some form of another
< elichai2> I'd like to review the new keypair direction but I do hope that BIP340 will actually end up in bitcoin in the end so I think it's ok to move toward merging schnorr to libsecp
< sipa> so with the prospect of having BIP340-342 one day merged, there will need to be a time to merge BIP340 support in libsecp256k1
< sipa> shower thought: are pcap files easy? if so, maybe it's useful post-BIP324 to permit dumping the decrypted stream in pcap format
< MarcoFalke> For logging, one could disable bip324
< jonasschnelli> would ne no longer fun for post BIP324 connections
< troygiorshev> i'm personally a huge fan of BIP324 and AltNet and related, so I'

2020-06-02

< sipa> with a million keys the bip158 filter won't help
< sipa> phantomcircuit: i think bip158 was designed for much smaller sets of keys, yes
< achow101> i'm gonna need to brush up on bip158 first
< phantomcircuit> "Empirical analysis also shows that was chosen as these parameters minimize the bandwidth utilized, considering both the expected number of blocks downloaded due to false positives and the size of the filters themselves." - BIP158
< gribble> https://github.com/bitcoin/bitcoin/issues/15845 | wallet: Fast rescan with BIP157 block filters by MarcoFalke · Pull Request #15845 · bitcoin/bitcoin · GitHub
< sipa> you have to explicitly enable bip37, or whitelist the peer
< aj> yeah, i was thinking of making it so bip35 wouldn't let you see stuff that hadn't made it into the bloom filter, but seems too complicated, esp if we think bip35 is only for trusted-ish peers
< aj> sipa: why not do bip35 via bloom as well?
< sipa> aj: so WDYT about relay pool 2 minutes, bloom filter per peer for last (whatever can be relayed in 2 minutes) transactions, things can be requested if they're in the bloom filter OR in mempool and older than 2 minutes OR older than the last BIP35 response; BIP35 responses don't go into the bloom filter

2020-05-29

< 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
< sipa> it's why we think we need an upgrade mechanism in BIP342
< jonasschnelli> sipa: do you think it could have implications for v2/BIP342?
< jonasschnelli> despite the – eventually – altering BIP324, I think we can finalise the implementation and hide it behind an experimental runtime parameter.
< jonasschnelli> BIP342 is still in discussion.
< 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
< dongcarl> jonasschnelli: I see, so after #18242, we need #14049, and then BIP324 handshake + BIP324 ECDH calc + BIP324 HKDF key deriv (last few commits from 2019/08/net_v2)?
< jonasschnelli> So as for BIP342, just focus on #18242
< 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
< jonasschnelli> 15206/15197 are now BIP324 irrelevant
< dongcarl> - #15197 + #15206 seem to be additional improvements that 1. Can be merged independently of the main line of progression, 2. Can help/simplify the implementation of BIP324. Question here: Could you give concrete examples as to how they help/simplify the implementation?
< dongcarl> Hey jonasschnelli, I wanted to confirm my overall understanding of the topology of the open PRs related to BIP324. Here?s my understanding:
< 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-05-28

< jnewbery> both for BIP324 and altnet
< jonasschnelli> its nice. but not necessary anymore for future transport protocols (like BIP324)

2020-05-21

< gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub

2020-05-20

< bitcoin-git> [bitcoin] dongcarl closed pull request #16748: [WIP] Add support for addrv2 (BIP155) (master...2019-07-addrv2v4) https://github.com/bitcoin/bitcoin/pull/16748
< bitcoin-git> [bitcoin] vasild opened pull request #19031: Implement ADDRv2 support (part of BIP155) (master...addrv2) https://github.com/bitcoin/bitcoin/pull/19031
< willcl_ark> sipa: thanks for your earlier reply re BIP30/34
< PaulTroon> thanks sipa, the commentary from bip30 makes more sense now
< PaulTroon> I was also trying to understand that BIP30 attack scenario, snot sure if I understand it.. a coinbase_1 with an unspent txout to A, and then create a duplicate coinbase_2 that has a txout to B ?
< sipa> BIP30 thankfully has an exception that in that case doesn't prevent creation, because otherwise we'd need to keep track of every spent utxo forever
< sipa> the problem that BIP30 was trying to solve is txout _overwriting_
< PaulTroon> sipa: because BIP30 allows duplicate tx's if all outputs are spent?
< sipa> BIP141 solved that
< PaulTroon> A pre-BIP34 coinbase with matching signature for block height 1,983,702 (approx year 2048)
< PaulTroon> BIP34 was an interesting historic read - is Gavin's speculation about a duplicate coinbase in 2048 technically impossible for a malicous miner? https://github.com/bitcoin/bitcoin/pull/1526#issuecomment-6796145
< sipa> BIP34 prevents duplicate txids (assuming collision resistance of double-SHA256...)
< sipa> willcl_ark: BIP30 doesn't prevent duplicate txids; it only prevents one transaction that would overwrite an earlier one
< willcl_ark> BIP30 appears to leave some room for re-orgs, but I can't tell if "spent" transactions (in different blocks) could still be allowed to have had identical txids
< willcl_ark> Does BIP30 / BIP34 completely prevent there from existing two transactions with same txid, or are there still edge-cases where this can happen?

2020-05-15

< jonasschnelli> would it make sense to support BIP39 mnemonics in descriptors?

2020-05-13

< jonasschnelli> Dont get me wrong. I’m totally pro BIP157.
< jonatack> jonasschnelli: the conceptual discussion is ongoing (at least for me) on bip157, but the changes in that PR didn't seem dangerous on their own after reviewing them, and reversible before the next release
< jonasschnelli> Yes. I agree. Just it looks like there is no clear conceptual ACK on serving filters after BIP157 (don't get me wrong, I'm all for serving BIP157).

2020-05-12

< phantomcircuit> sipa, for non-legacy wallets using the existing bip158 "basic" filter (which is the entire script) is definitely preferable
< sipa> phantomcircuit: unless you really need support for raw multisig (which i think the wallet doesn't even support anymore), you could use the bip158 filter

2020-05-08

< jonasschnelli> sipa: do you think it is a problem to not MAC the length in the V2 BIP324 protocol? See comment: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#gistcomment-3295536

2020-05-07

< bitcoin-git> [bitcoin] MarcoFalke closed pull request #15845: wallet: Fast rescan with BIP157 block filters (master...1904-walletFastRescan) https://github.com/bitcoin/bitcoin/pull/15845
< ariard> luke-jr: right I'm not arguing bip157-vs-bip37 here, but more broadly on light-client model in case of forks
< jonatack> question: if bip157 is opt-in, and a full node can soon export a descriptor wallet xpub, why would a full node turn on serving cfilters?
< * luke-jr> still hasn't heard a use case for merging BIP157 at all, aside from harming Bitcoin
< sipa> (not BIP157 specifically, just in general - if you ask too much of us and we get overloaded, deprioritize)
< ariard> sipa: yes but we don't do this AFAIK? and if everyone start to deprioritizie servicing bip157 clients you do have an issue
< jonasschnelli> Yes. The only difference to blocks serving (which seems to cause much more traffic) is that blocks served to bip157 are pure consumption while blocks served to full nodes should - ideally - be served to other peers.
< ariard> kanzure: no my concern is assuming you have the bip157 light client paradigm, how do you make it scale ecosystem-wise
< jonasschnelli> ariard: also, one can crosscheck the CDN filters against some p2p loaded bip157 filters
< jonatack> fwiw, i'm running a bip157 node on mainnet with -peercfilters=1 -blockfilterindex=1 to test for the first time, and /blockfilter/basic is 4 GB
< ariard> overall, bip157 is good for experimentation, while keeping awareness there is still unsolved issues on security and scalability
< sipa> luke-jr: bip157 has other advantages over bloom filters, such as being able to connect to two nodes and comparing the filters, permitting a "1 of 2 nodes is trusted" security model
< luke-jr> stratum > bloom > bip157
< ariard> jonasschenlli: yes my concern isn't bip157 specific, I do think that's the best option available today
< ariard> jonasschenelli: okay my point was really about LN clients, for which bip157 was designed, not an application which needs to download block over and over
< jonasschnelli> if there is the concern that there are too many BIP157 clients,... one might want to limit the bandwidth
< sipa> with BIP157 you do it once
< sipa> BIP157 is certainly harder on clients
< ariard> and almost all bip157 clietns, dont't have strong addr management countermeasures
< ariard> on the security aspect, supporting bip157 in core encourage people to connect directly to random peers
< sipa> (but that's still better than BIP37...)
< sipa> BIP157 support is very cheap for the server
< ariard> and having a better idea for which bip157 support was aimed, people using their mobile wallets with their full-nodes
< jonasschnelli> I think BIP157 support in core is a conceptual no brainer. The question is maybe more, if it should be open to non-whitelisted peers (random peers).
< luke-jr> BIP157 isn't just "not perfect", it's harmful/backward
< ariard> what I was worry about, is by supporting bip157 in core, all people building such nice LN wallets
< wumpus> #topic bip157 and light clients (ariard)
< ariard> do people have a bit of time to talk about bip157 or more broadly light clients ?
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #14046: net: Refactor message parsing (CNetMessage), adds flexibility (master...2018/08/bip151_pre_refactor) https://github.com/bitcoin/bitcoin/pull/14046

2020-05-06

< ariard> hey going to withdraw my NACK on bip157 impl but I would be glad to have this on a subject for meeting tmrw

2020-05-05

< bitcoin-git> [bitcoin] fanquake closed pull request #16442: Serve BIP 157 compact filters (master...bip157-net) https://github.com/bitcoin/bitcoin/pull/16442

2020-05-03

< 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-04-30

< ariard> wumpus: you may use BIP157 or any other light client protocols, even a custom one
< luke-jr> any ideas why Travis isn't reporting running/results to BIPs PRs? It seems to actually be running, just not reporting to GitHub :/

2020-04-29

< vasild> wumpus: dongcarl: anyway, I plan to spend full time on BIP155/addrv2/torv3/i2p/cjdns, modulo distractions :)
< gribble> https://github.com/bitcoin/bitcoin/issues/16748 | [WIP] Add support for addrv2 (BIP155) by dongcarl · Pull Request #16748 · bitcoin/bitcoin · GitHub
< vasild> wumpus: While looking at the addrv2/BIP155 wip PR #16748 I realized that in CSubNet we support netmasks that have 0-bits followed by 1-bits, e.g. /255.255.0.255.

2020-04-24

2020-04-21

< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18672: test: add further BIP37 size limit checks to p2p_filter.py (master...20200416-test-add-further-bloom-filter-size-limit-checks) https://github.com/bitcoin/bitcoin/pull/18672
< bitcoin-git> bitcoin/master c743718 Sebastian Falbesoner: test: add further BIP37 size limit checks to p2p_filter.py
< bitcoin-git> bitcoin/master 4ad6144 MarcoFalke: Merge #18672: test: add further BIP37 size limit checks to p2p_filter.py
< gribble> https://github.com/bitcoin/bitcoin/issues/18544 | net: limit BIP37 filter lifespan (active between filterload..filterclear) by theStack · Pull Request #18544 · bitcoin/bitcoin · GitHub

2020-04-20

< gribble> https://github.com/bitcoin/bitcoin/issues/18672 | test: add further BIP37 size limit checks to p2p_filter.py by theStack · Pull Request #18672 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/18544 | net: limit BIP37 filter lifespan (active between filterload..filterclear) by theStack · Pull Request #18544 · bitcoin/bitcoin · GitHub
< bitcoin-git> bitcoin/master da4cbb7 MarcoFalke: Merge #18544: net: limit BIP37 filter lifespan (active between 'filterload...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18544: net: limit BIP37 filter lifespan (active between 'filterload'..'filterclear') (master...20200406-net-limit_bip37_filter_lifetime) https://github.com/bitcoin/bitcoin/pull/18544
< bitcoin-git> bitcoin/master 5eae034 Sebastian Falbesoner: net: limit BIP37 filter lifespan (active between 'filterload' and 'filterc...

2020-04-17

< yevaud> I've seen a few people argue based on BIP50 that if the locks are set to the value described, it is safe.
< yevaud> for a rare one, BIP50 is a report, not a change.
< sipa> proofofkeags: BIPs == things that require cross-application standards
< proofofkeags> but I'm not sure what heuristic is used for bips

2020-04-16

< 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
< bitcoin-git> [bitcoin] theStack opened pull request #18672: test: add further BIP37 size limit checks to p2p_filter.py (master...20200416-test-add-further-bloom-filter-size-limit-checks) https://github.com/bitcoin/bitcoin/pull/18672

2020-04-15

2020-04-10

< vasild> MarcoFalke: https://github.com/bitcoin/bips/pull/907#issuecomment-611997913 -- I have just started looking into this, digesting the BIP for now.

2020-04-09

< jonasschnelli> I could understand why the signraw commands could refuse to work for BIP44-ish descriptor wallets (due to the hardening violation),... though for manual privkey-ckd it should work

2020-04-08

< Talkless> jonasschnelli: alternative is just to wait until Bitcoin Qt has BIP39 support and easy HW wallet support, so I could just switch to Bitcoin Qt :)

2020-04-06

< bitcoin-git> [bitcoin] theStack opened pull request #18544: net: limit BIP37 filter lifespan (active between 'filterload'..'filterclear') (master...20200406-net-limit_bip37_filter_lifetime) https://github.com/bitcoin/bitcoin/pull/18544

2020-04-05

< bitcoin-git> bitcoin/master cf21293 MarcoFalke: Merge #18515: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18515: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p_filter.py (master...20200403-test-check-for-CVE20135700-vuln-in-bip37-tests) https://github.com/bitcoin/bitcoin/pull/18515
< bitcoin-git> bitcoin/master 0ed2d8e Sebastian Falbesoner: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p_filter.py

2020-04-03

< bitcoin-git> [bitcoin] theStack opened pull request #18515: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p_filter.py (master...20200403-test-check-for-CVE20135700-vuln-in-bip37-tests) https://github.com/bitcoin/bitcoin/pull/18515

2020-03-31

< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18481: test: add BIP37 'filterclear' test to p2p_filter.py (master...20200330-test-add-BIP37-filterclear-message) https://github.com/bitcoin/bitcoin/pull/18481
< bitcoin-git> bitcoin/master 0055922 Sebastian Falbesoner: test: add BIP37 'filterclear' test to p2p_filter.py
< bitcoin-git> bitcoin/master d52ba21 MarcoFalke: Merge #18481: test: add BIP37 'filterclear' test to p2p_filter.py
< bitcoin-git> [bitcoin] theStack opened pull request #18481: test: add BIP37 'filterclear' test to p2p_filter.py (master...20200330-test-add-BIP37-filterclear-message) https://github.com/bitcoin/bitcoin/pull/18481

2020-03-13

< bitcoin-git> bitcoin/master 66c2cad Andrew Chow: Rename BIP32PubkeyProvider.m_extkey to m_root_extkey

2020-03-10

< bitcoin-git> [bitcoin] fanquake closed pull request #13972: Remove 16 bits from versionbits signalling system (BIP320) (master...reservedbits2) https://github.com/bitcoin/bitcoin/pull/13972

2020-03-09

< bitcoin-git> [bitcoin] DrahtBot closed pull request #13972: Remove 16 bits from versionbits signalling system (BIP320) (master...reservedbits2) https://github.com/bitcoin/bitcoin/pull/13972
< bitcoin-git> [bitcoin] DrahtBot reopened pull request #13972: Remove 16 bits from versionbits signalling system (BIP320) (master...reservedbits2) https://github.com/bitcoin/bitcoin/pull/13972

2020-03-05

< harding> stevenroose: what do you mean "I'm sure there's no code that detects changes in that [minfeefilter] field"? Are you familar with BIP133? The whole point of that is to allow peers to detect changes to a peer's minfeefilter and avoid relaying transactions to a peer that won't accept them.
< kallewoof> I made a PR to the signet BIP, describing the genesis block and message start: https://github.com/bitcoin/bips/pull/900
< aj> reserve one of the bip320 miner-roll versionbits to signal "this block will get reorged out" instead maybe?
< aj> kallewoof: so i saw signet on hi-pri and thought it'd be fun to discuss, but i see you posted about bip322/msg signing yesterday, so could do that instead?

2020-03-03

< pingwindyktator> Im trying to think that this code is obsolete: it only applies to blocks before BIP9, which was indeed version 2, 3, 4. Now we're interpreting nVersion differently and this code is here just to be sure we're not breaking consensus. Can anyone confirm this?
< pingwindyktator> Im trying to understand how exactly should we interpret block nVersion. Since BIP09 the 2, 3, 4 version actually refers to top bits in nVersion. So, given nVersion == dec(1073725440) == hex(0x3fffc000) == version 3 with some softfork bits set.
< hadjiszs> sipa: MarcoFalke: what about Dandelion Lite for BIP156 ? eg. this implementation: https://github.com/dtr-org/unit-e/pull/302/

2020-03-02

< bitcoin-git> [bitcoin] jonasschnelli opened pull request #18242: Add BIP324 encrypted p2p transport de-/serializer (only used in tests) (master...2020/03/net_v2) https://github.com/bitcoin/bitcoin/pull/18242

2020-02-28

< provoostenator> It also keeps the xpub in the expected place for BIP44/49/84 style descriptors

2020-02-25

< vasild> I tried to rebase achow101/sign-in-spkman on top of bitcoin/master and got a conflict not related to 17577, but due to #17264 which modified src/wallet/psbtwallet.h (git show 29a21c906 -- src/wallet/psbtwallet.h) and 18115 deleted the file. To resolve, I replayed the change on wallet.h: git rebase bitcoin/master ; git rm src/wallet/psbtwallet.h ; sed -i '' 's/bip32derivs = false/bip32derivs =
< gribble> https://github.com/bitcoin/bitcoin/issues/17264 | rpc: set default bip32derivs to true for psbt methods by Sjors · Pull Request #17264 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] meshcollider merged pull request #17264: rpc: set default bip32derivs to true for psbt methods (master...2019/10/bip32_derivs) https://github.com/bitcoin/bitcoin/pull/17264
< bitcoin-git> bitcoin/master 29a21c9 Sjors Provoost: [rpc] set default bip32derivs to true for psbt methods
< bitcoin-git> bitcoin/master 31c0006 Samuel Dobson: Merge #17264: rpc: set default bip32derivs to true for psbt methods
< bitcoin-git> bitcoin/master 5bad792 Sjors Provoost: [test] PSBT RPC: check that bip32_derivs are present by default
< hadjiszs> sipa: MarcoFalke: is there someone working on dandelion++ implementation as for BIP156 ? I am planning to work on top of your #13947
< bitcoin-git> [bitcoin] fanquake closed pull request #16486: [consensus] skip bip30 checks when assumevalid is set for the block (master...2019-07-29-fassumevalid-bip34) https://github.com/bitcoin/bitcoin/pull/16486

2020-02-24

< instagibbs> since we're adhering to BIP44/49/84(throwing this out there in case someone thinks this is a bad idea)

2020-02-20

< dongcarl> Okay, will read BIP150
< dongcarl> jonasschnelli: Looking at BIP324... The session ID is supposed to be provided OOB?
< provoostenator> A PSBT without bip32 info is generally useless.
< gribble> https://github.com/bitcoin/bitcoin/issues/17264 | rpc: set default bip32derivs to true for psbt methods by Sjors · Pull Request #17264 · bitcoin/bitcoin · GitHub

2020-02-06

< jonasschnelli> wumpus: you mean adding BIP39 support?

2020-02-05

< sipa> BIP60 argued that adding optional fields to the version message was problematic, and suggested a solution; even if that solutions wasn't adopted, that does not imply that its concern (optional fields at the end of version) does not matter
< sipa> some libbitcoin people complained about BIP37 adding an optional field to version

2020-01-31

< provoostenator> If we were to add BIP39 support, then descriptors could contain the mnemonic.
< provoostenator> Though without BIP39 mnemonic export that's still not practical
< provoostenator> Reasonably strong BIP44/49/84 adoption
< provoostenator> One thing I brought up in the review is if we really want to switch to BIP44/49/84 or stick to our hardened derivation thing.

2020-01-30

< sipa> jeremyrubin: bip62 rule 6 is implemented as a standardness rule

2020-01-08

< gribble> https://github.com/bitcoin/bitcoin/issues/16748 | [WIP] Add support for addrv2 (BIP155) by dongcarl . Pull Request #16748 . bitcoin/bitcoin . GitHub

2020-01-06

< ariard> what the rational to update protocol version number ? #16442 adds new p2p messages, but don't bump it, at the contrary protocol version has been bumped for bip37/bip152

2020-01-04

< ekkis> when I convert BIP39 mnemonics to seeds I get 128 hex characters but the key I got from Edge is only 65 chars
< ekkis> I've tried converting it to the a hex buffer and the bip32.fromSeed() seems to accept it but I'm not sure it's correct as I'm generating addresses for the wallet and none of them seem to match the one I'm shown on the app
< ekkis> usually I would take a BIP39 seed phrase and convert it to a BIP32 root but in this case I don't know what format the key is in

2019-12-12

< sipa> there could be some best effort where we remove bip32 derivation info from finalized inputs
< sipa> luke-jr: BIP 174 updating is filling in UTXOs/prevtxs, bip32 paths, scripts used
< gribble> https://github.com/bitcoin/bitcoin/issues/17264 | rpc: set default bip32derivs to true for psbt methods by Sjors . Pull Request #17264 . bitcoin/bitcoin . GitHub
< sipa> the only reason why you'd want that to be explicit is because of privacy concerns (you may not want to reveal bip32 paths you know about keys used), but the sentiment in #17264 seems to be that that needs to be solved differently anyway

2019-12-11

< bitcoin-git> [bitcoin] MarcoFalke merged pull request #17050: tests: Add fuzzing harnesses for functions parsing scripts, numbers, JSON and HD keypaths (bip32) (master...fuzzers) https://github.com/bitcoin/bitcoin/pull/17050
< bitcoin-git> bitcoin/master 074cb64 practicalswift: tests: Add ParseHDKeypath(...) (bip32) fuzzing harness

2019-12-03

< pinheadmz> I am reading the code correctly? We always enforce bip68 sequence locks (LOCKTIME_VERIFY_SEQUENCE) in the mempool -- even on a regtest chain _before_ CSV has been activated. ?

2019-11-17

< jonasschnelli> real_or_random, sipa: time of the BIP324 protocol upgrade idea?

2019-11-14

2019-11-12

< bitcoin-git> [bitcoin] TheBlueMatt closed pull request #15482: Implement BIPXXX's new softfork rules (The Great Consensus Cleanup) (master...2019-02-great-consensus-cleanup) https://github.com/bitcoin/bitcoin/pull/15482

2019-11-06

< bitcoin-git> [bitcoin] fanquake merged pull request #17370: doc: Update doc/bips.md with recent changes in master (master...1911-docBips) https://github.com/bitcoin/bitcoin/pull/17370
< bitcoin-git> bitcoin/master 4e21f72 fanquake: Merge #17370: doc: Update doc/bips.md with recent changes in master
< bitcoin-git> bitcoin/master fa7f5a4 MarcoFalke: doc: Update doc/bips.md with recent changes in master

2019-11-05

2019-11-04

< bitcoin-git> [bitcoin] MarcoFalke opened pull request #17370: doc: Update doc/bips.md with recent changes in master (master...1911-docBips) https://github.com/bitcoin/bitcoin/pull/17370

2019-11-02

< bitcoin-git> [bitcoin] laanwj merged pull request #17285: doc: Bip70 removal follow-up (master...bip70_followup) https://github.com/bitcoin/bitcoin/pull/17285
< bitcoin-git> bitcoin/master 463eab5 Wladimir J. van der Laan: Merge #17285: doc: Bip70 removal follow-up
< bitcoin-git> bitcoin/master d6e493f Fabian Jahr: wallet: Remove left-over BIP70 comment

2019-10-30

< luke-jr> eg, BIP70-workalike + time locked tx

2019-10-28

< bitcoin-git> [bitcoin] fjahr opened pull request #17285: doc: Bip70 removal follow-up (master...bip70_followup) https://github.com/bitcoin/bitcoin/pull/17285

2019-10-26

< bitcoin-git> [bitcoin] Sjors opened pull request #17264: [rpc] set default bip32derivs to true for psbt methods (master...2019/10/bip32_derivs) https://github.com/bitcoin/bitcoin/pull/17264
< bitcoin-git> [bitcoin] laanwj merged pull request #17165: Remove BIP70 support (master...remove_bip70) https://github.com/bitcoin/bitcoin/pull/17165
< bitcoin-git> bitcoin/master 3548e4a fanquake: Remove BIP70 Support

2019-10-25

< gribble> https://github.com/bitcoin/bitcoin/issues/17165 | Remove BIP70 support by fanquake . Pull Request #17165 . bitcoin/bitcoin . GitHub

2019-10-24

< sipa> BIP157 doesn't have the same problem as the I/O required is proportional to what is sent over the network
< wumpus> #topic BIP157 (provoostenator)
< provoostenator> Suggested topic BIP157 if we have time...
< gribble> https://github.com/bitcoin/bitcoin/issues/17165 | Remove BIP70 support by fanquake . Pull Request #17165 . bitcoin/bitcoin . GitHub

2019-10-22

< MarcoFalke> See the TODOs and comments in https://github.com/bitcoin/bips/pull/766
< gleb> I'm looking at the BIP-155 in bips repo and it has only 1 new type of message which contains addresses. No signalling for support.

2019-10-21

< bitcoin-git> bitcoin/0.19 6a45766 MarcoFalke: doc: update bips.md with buried BIP9 deployments

2019-10-18

< sipa> BlueMatt: pre-BIP66, many
< kallewoof> wumpus: not all BIPs have PRs though. (and not all BIPs have PRs to bitcoin core)

2019-10-16

< bitcoin-git> [bitcoin] fanquake opened pull request #17165: [WIP] Remove BIP70 support (master...remove_bip70) https://github.com/bitcoin/bitcoin/pull/17165

2019-10-15

< bitcoin-git> [bitcoin] laanwj merged pull request #17111: doc: update bips.md with buried BIP9 deployments (master...1910-docBip9Buried) https://github.com/bitcoin/bitcoin/pull/17111
< bitcoin-git> bitcoin/master a4a4964 Wladimir J. van der Laan: Merge #17111: doc: update bips.md with buried BIP9 deployments
< bitcoin-git> bitcoin/master fa6ed82 MarcoFalke: doc: update bips.md with buried BIP9 deployments

2019-10-04

< bitcoin-git> bitcoin/master fa8d052 MarcoFalke: doc: Update bips.md for default bech32 addresses in 0.20.0
< bitcoin-git> [bitcoin] fanquake merged pull request #17026: doc: Update bips.md for default bech32 addresses in 0.20.0 (master...1909-doc0.20Rel) https://github.com/bitcoin/bitcoin/pull/17026

2019-10-03

< bitcoin-git> [bitcoin] achow101 opened pull request #17034: Bip174 extensions (master...bip174-extensions) https://github.com/bitcoin/bitcoin/pull/17034

2019-10-02

< bitcoin-git> [bitcoin] MarcoFalke opened pull request #17026: doc: Update bips.md for default bech32 addresses in 0.20.0 (master...1909-doc0.20Rel) https://github.com/bitcoin/bitcoin/pull/17026
< bitcoin-git> [bitcoin] Sjors opened pull request #17023: doc: warn that ranged multi() descriptors are not BIP67 compatible (master...2019/10/doc_descriptor_bip67_warning) https://github.com/bitcoin/bitcoin/pull/17023

2019-10-01

< bitcoin-git> [bitcoin] laanwj merged pull request #16852: gui: When BIP70 is disabled, get PaymentRequest merchant using string search (master...bip70-merchant-decode) https://github.com/bitcoin/bitcoin/pull/16852
< bitcoin-git> bitcoin/master cd6e9b3 Wladimir J. van der Laan: Merge #16852: gui: When BIP70 is disabled, get PaymentRequest merchant usi...
< bitcoin-git> bitcoin/master 85973bc Andrew Chow: When BIP70 is disabled, get PaymentRequest merchant using string search
< bitcoin-git> [bitcoin] laanwj merged pull request #16997: doc: Update bips.md for 0.19 (master...2019_09_bips_v19) https://github.com/bitcoin/bitcoin/pull/16997
< bitcoin-git> bitcoin/master 82c1177 Wladimir J. van der Laan: doc: Add mention of BIP158 indexing since v0.19.0
< bitcoin-git> bitcoin/master 2267006 Wladimir J. van der Laan: doc: Add mention of BIP125 used by wallet GUI by default since v0.18.1
< bitcoin-git> bitcoin/master b11514d Wladimir J. van der Laan: doc: Add mention of BIP70 disabling by default in bips.md

2019-09-30

< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #15482: Implement BIPXXX's new softfork rules (The Great Consensus Cleanup) (master...2019-02-great-consensus-cleanup) https://github.com/bitcoin/bitcoin/pull/15482
< bitcoin-git> [bitcoin] laanwj opened pull request #16997: doc: Update bips.md for 0.19 (master...2019_09_bips_v19) https://github.com/bitcoin/bitcoin/pull/16997
< bitcoin-git> [bitcoin] DrahtBot closed pull request #15482: Implement BIPXXX's new softfork rules (The Great Consensus Cleanup) (master...2019-02-great-consensus-cleanup) https://github.com/bitcoin/bitcoin/pull/15482