2022-01-20

<fanquake> Blocked 13rAXwNNnaAuCJA3z1REfJbJNMwgK4LBTC from the bitcoin/ org, as they were spamming the wiki in the bips repo

2022-01-13

<bitcoin-git> [bitcoin] kallewoof opened pull request #24058: BIP-322 basic support (master...202201-bip322) https://github.com/bitcoin/bitcoin/pull/24058

2022-01-12

<andytoshi> achow101: i feel bad asking, but is there any status update on bip370 test vectors?

2022-01-11

<bitcoin-git> [bitcoin] MarcoFalke opened pull request #24038: wallet: Enforce BIP68 (master...2201-lockstuff) https://github.com/bitcoin/bitcoin/pull/24038

2022-01-10

<dhruv> Is there any history of running all functional test multiple times with varying CLI arguments? Working on BIP324, I am adding in a new CLI arg: -v2transport. I'm wondering if it would be prudent to run all functional tests with -v2transport=0 and also -v2transport=1
<Kaizen_K_> perfect, the bips are excellent cause they provide the nitty gritty details of what I need to map my braad and foggy understanding of bitcoin to the implimentations of
<sipa> In BIP143 the part of the signature message that depends on the number of inputs is precomputed once for the entire transaction.

2022-01-08

<sipa> There are two pairs of BIP30 violations.

2022-01-07

<bitcoin-git> [bitcoin] glozow closed pull request #23121: [policy] check ancestor feerate in RBF, remove BIP125 Rule2 (master...ancestorscore-remove-bip1252) https://github.com/bitcoin/bitcoin/pull/23121

2022-01-05

<TallTim> Forgive me if wrong channel, but I'd like to know where/when BIP 1126 (Adds BIP52) for Optical Proof of Work (OPoW) will be discussed. The logic on this one seems deeply flawed in favor of the "Bitcoin will consume too much power" narrative. Thanks in advance.

2022-01-02

<bitcoin-git> [bitcoin] fanquake merged pull request #23882: doc: testnet3 was not reset and is doing BIP30 checks again (master...2112-docBip30Testnet3) https://github.com/bitcoin/bitcoin/pull/23882
<bitcoin-git> bitcoin/master fa1a51c MarcoFalke: doc: testnet3 was not reset and is doing BIP30 checks again
<bitcoin-git> bitcoin/master 6535772 fanquake: Merge bitcoin/bitcoin#23882: doc: testnet3 was not reset and is doing BIP3...

2021-12-29

<michaelfolkson> jeremyrubin: Don't worry, an intro is in the BIP. No comparison on how eltoo with APO compares to eltoo with CTV and CSFS though https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#eltoo-with-op_checksigfromstackverify
<michaelfolkson> Rightly imo. I don't think we need to speculate on what BIPs will be merged in future in that doc.
<michaelfolkson> prayank: Plus for Taproot the BIPs doc was updated in a standalone PR https://github.com/bitcoin/bitcoin/pull/21925
<michaelfolkson> prayank: I don't think a two line description of a BIP in a doc on BIPs will avoid a CVE but maybe I'm just being unimaginative
<prayank> michaelfolkson: If PR gets merged the doc will be updated in same PR, it it doesn't get merged it won't be updated. Other BIPs have just BIP number, link to BIP repository, one sentence about BIP and PR link. So I thought we can update the same for BIP 119. Anyway its not something very important for me but sometimes you can get CVEs for lack of documentation so I thought its good to not forget about docs.
<michaelfolkson> prayank: That is for merged and released in Core BIPs
<prayank> jeremyrubin: maybe you can add information about bip 119 and related PR in doc/bips.md in #21702

2021-12-27

<bitcoin-git> [bitcoin] MarcoFalke opened pull request #23882: doc: testnet3 was not reset and is doing BIP30 checks again (master...2112-docBip30Testnet3) https://github.com/bitcoin/bitcoin/pull/23882

2021-12-25

<prayank> jeremyrubin: Compiling #21702 branch. BIP 119 mentioned about coinjoin. I want to test this with a setup of 2-3 regtest nodes. I don't understand the code written here: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#detailed-specification however I can test things based on the description that "participants agree on a single output which pays all participants". Do you have any other suggestion to help me in this

2021-12-23

<jeremyrubin> FYI in response to some private feedback i've clarified a few points in the BIP around alternative vault designs (the original one is outdated from my latest thinking) and activation stuff https://github.com/bitcoin/bips/pull/1257

2021-12-20

<bitcoin-git> bitcoin/master 1fd49eb glozow: [doc] clarify RBF difference from BIP125

2021-12-17

<meshcollider> Also, admin perms on bitcoin/bitcoin doesn't require admin on bitcoin/BIPs
<laanwj> that the bips repository is in the same organization is somewhat questionable in any case
<michaelfolkson> I guess the elephant in the room is that some people wanted to remove Luke as a BIP editor earlier in the year. And rightly in my view laanwj didn't succumb to that pressure as there should be separation between Core and BIPs

2021-12-01

<bitcoin-git> bitcoin/master c771ee8 fanquake: doc: use BIP125-replaceable

2021-11-28

<sipa> jeremyrubin: are you aware of BIP113 ?

2021-11-20

<bitcoin-git> [bitcoin] dhruv opened pull request #23561: BIP324 handshake prerequisites (master...bip324-handshake) https://github.com/bitcoin/bitcoin/pull/23561

2021-11-18

<achow101> the PR follows the existing BIP16Exception cde
<sipa> bip30 and bip34 have exceptions

2021-11-16

<sipa> (disclaimer, i'm biased, because i'm one of the co-authors of BIPs 340,341,342)
<sipa> BIPs are just published ideas
<sipa> but again, BIPs are just ways for people to publish ideas; the procedure for creating one is in BIP2
<sipa> BIPs are usually discussed on the bitcoin-dev mailinglist, https://lists.linuxfoundation.org/pipermail/bitcoin-dev
<sipa> the BIP repo itself is https://github.com/bitcoin/bips
<sipa> here is the list of the ones implemented in Bitcoin Core: https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md
<sipa> not all BIPs are implemented by bitcoin core, and not all are intended to
<sipa> in short: BIPs are just documents people publish; they aren't approved - people choose to implement them, or not
<sipa> (and its predecessor BIP1)
<sipa> read BIP2

2021-11-15

<bitcoin-git> bitcoin/master 2478c67 Pieter Wuille: Make signing follow BIP340 exactly w.r.t. aux randomness

2021-11-12

<sipa> (similar to the BIP37 dos potential)

2021-11-08

<Chris_Stewart_5> Perhaps it would be useful to link that here for future readers? https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#test-vectors
<sipa> # == Test that BIP341 spending only applies to witness version 1, program length 32, no P2SH ==
<Chris_Stewart_5> 3. When looking at BIP341 you confirm that for future soft fork extensibility you have p2sh(witSPKV1) is trivially true
<sipa> yes, in bip341/bip342, the sighash algorithm is a function of all utxos spent by the entire transaction
<Chris_Stewart_5> I'm attempting to work through test cases for BIP341 (script_assets_test.json), what is this scriptSig? The comment next to it is "comment": "legacy/pk-wrongkey" and the output script is p2sh, here is the scriptSig: 47304402204d87b96e7f61a568c98e329d1de4e065b1a3fd79323db707dfbe41216d7316f002201882165181d5f79bdb90c3d7f19bac0d1488b2e1bb8e4d217658e7eaf102e3d28143410442f7110c668193b072c2ac20b92ef6127383c166ea8d

2021-11-04

<bitcoin-git> [bitcoin] dhruv closed pull request #23440: Bip324 ellsq buildwoes (master...bip324-ellsq-buildwoes) https://github.com/bitcoin/bitcoin/pull/23440
<bitcoin-git> [bitcoin] dhruv opened pull request #23440: Bip324 ellsq buildwoes (master...bip324-ellsq-buildwoes) https://github.com/bitcoin/bitcoin/pull/23440
<yanmaani> https://github.com/bitcoin/bips/pull/1223 what's going on with this PR

2021-11-03

<bitcoin-git> [bitcoin] dhruv opened pull request #23432: BIP324: CPubKey encode/decode to elligator-squared (master...bip324-ellsq) https://github.com/bitcoin/bitcoin/pull/23432

2021-11-02

<sipa> BIP14 is about separating the protocol version from the implementation version
<satoshi> BIP 14: https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki should be followed. Changing from 0.21.x to 22.x is disruptive.
<satoshi> Bitcoin 0.1.0 : static const int VERSION = 101; Bitcoin 0.3.0 : static const int VERSION = 300; Bitcoin 0.10.0 : return strprintf("%d.%d.%d", nVersion / 1000000, (nVersion / 10000) % 100, (nVersion / 100) % 100); Additional: https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
<bitcoin-git> [bitcoin] MarcoFalke merged pull request #23410: doc: Add output script descriptors BIPs 380..386 (master...211101-bips) https://github.com/bitcoin/bitcoin/pull/23410
<bitcoin-git> bitcoin/master c02a674 Hennadii Stepanov: doc: Add output script descriptors BIPs 380..386
<bitcoin-git> bitcoin/master 76886ce MarcoFalke: Merge bitcoin/bitcoin#23410: doc: Add output script descriptors BIPs 380.....

2021-11-01

<bitcoin-git> [bitcoin] hebasto opened pull request #23410: doc: Add output script descriptors BIPs 380..386 (master...211101-bips) https://github.com/bitcoin/bitcoin/pull/23410
<hebasto> sipa: is it a time to mention BIPs 380..386 in the https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md ?

2021-10-26

<sipa> theStack: BIP341 has recommendations

2021-10-22

<gribble> https://github.com/bitcoin/bitcoin/issues/23121 | [policy] check ancestor feerate in RBF, remove BIP125 Rule2 by glozow · Pull Request #23121 · bitcoin/bitcoin · GitHub

2021-10-21

<gribble> https://github.com/bitcoin/bitcoin/issues/23121 | [policy] check ancestor feerate in RBF, remove BIP125 Rule2 by glozow · Pull Request #23121 · bitcoin/bitcoin · GitHub
<bitcoin-git> [bitcoin] MarcoFalke merged pull request #23267: test: bip125-replaceable in listsinceblock (master...2021-10-test-bip125-listsinceblock) https://github.com/bitcoin/bitcoin/pull/23267
<bitcoin-git> bitcoin/master b7884dd brunoerg: test: bip125-replaceable in listsinceblock
<bitcoin-git> bitcoin/master 88fc795 MarcoFalke: Merge bitcoin/bitcoin#23267: test: bip125-replaceable in listsinceblock

2021-10-12

<bitcoin-git> [bitcoin] brunoerg opened pull request #23267: test: bip125-replaceable in listsinceblock (master...2021-10-test-bip125-listsinceblock) https://github.com/bitcoin/bitcoin/pull/23267

2021-10-11

<bitcoin-git> [bitcoin] fanquake merged pull request #23199: refactor: use `{Read,Write}BE32` helpers for BIP32 nChild (de)serialization (master...202110-refactor-use_be32_helpers_for_bip32_nchild) https://github.com/bitcoin/bitcoin/pull/23199
<bitcoin-git> bitcoin/master 7fc487a Sebastian Falbesoner: refactor: use `{Read,Write}BE32` helpers for BIP32 nChild (de)serialization

2021-10-05

<bitcoin-git> [bitcoin] theStack opened pull request #23199: refactor: use `{Read,Write}BE32` helpers for BIP32 nChild (de)serialization (master...202110-refactor-use_be32_helpers_for_bip32_nchild) https://github.com/bitcoin/bitcoin/pull/23199
<gribble> https://github.com/bitcoin/bitcoin/issues/23121 | [policy] check ancestor feerate in RBF, remove BIP125 Rule2 by glozow · Pull Request #23121 · bitcoin/bitcoin · GitHub
<gribble> https://github.com/bitcoin/bitcoin/issues/23121 | [policy] check ancestor feerate in RBF, remove BIP125 Rule2 by glozow · Pull Request #23121 · bitcoin/bitcoin · GitHub

2021-09-30

<luke-jr> fanquake merged the BIP9 consensus change without community consensus, he shouldn't have any access at this point

2021-09-28

<bitcoin-git> [bitcoin] glozow opened pull request #23121: [policy] check ancestor feerate in RBF, remove BIP125 Rule2 (master...ancestorscore-remove-bip1252) https://github.com/bitcoin/bitcoin/pull/23121

2021-09-27

<sipa> no, because those are actually illegal per BIP141
<sipa> (you should support sending to any valid BIP350 address)
<sipa> i think that taproot scriptPubKeys to BIP341/BIP342 (for specific keys, scripts) would be useful, though
<sipa> pinheadmz: all the examples in BIP350 under "Test vectors for v0-v16 native segregated witness addresses" should be valid addresses; only a few are taproot ones though
<pinheadmz> Are there test vectors anywhere for Taproot addresses specifically? I've got the bech32m tests from BIP350 but they are abstract and some aren't actually valid BIP341 addresses (data too long etc)

2021-09-23

<bitcoin-git> bitcoin/0.21 f78570e Pieter Wuille: doc: mention bech32m/BIP350 in doc/descriptors.md

2021-09-14

<sipa> at least with the BIP340 default nonce function, k=0 will +-never be reached

2021-09-10

<bitcoin-git> bitcoin/master 7b60c02 glozow: MOVEONLY: BIP125 Rule 2 to policy/rbf

2021-09-08

<bitcoin-git> bitcoin/22.x 0640bf5 Pieter Wuille: doc: mention bech32m/BIP350 in doc/descriptors.md
<lucaferr> I'm trying to find an example TapRoot keypath transaction in the test vectors linked from bip341. Any suggestions on how to find one?

2021-09-06

<dhruv> prayank: That post is a few months old and things have changed. We have discovered good reasons to not authenticate DNS seeds for now and a re-work of BIP324 is WIP to allow for e2e encryption and authentication.
<bitcoin-git> bitcoin/0.20 2b986b3 Pieter Wuille: doc: mention bech32m/BIP350 in doc/descriptors.md

2021-09-02

<bitcoin-git> [bitcoin] mjdietzx opened pull request #22867: Extend test coverage of BIP125 and document confusing/inconsistent behavior (master...test_bip125_edge_cases) https://github.com/bitcoin/bitcoin/pull/22867
<bitcoin-git> [bitcoin] fanquake merged pull request #22809: test: Check that non-signaling BIP125 tx can be replaced via parent (master...2108-testTxReplace) https://github.com/bitcoin/bitcoin/pull/22809
<bitcoin-git> bitcoin/master fa2e9de MarcoFalke: test: Check that non-signaling BIP125 tx can be replaced via parent
<bitcoin-git> bitcoin/master b997dd2 fanquake: Merge bitcoin/bitcoin#22809: test: Check that non-signaling BIP125 tx can ...
<bitcoin-git> [bitcoin] fanquake merged pull request #22836: Stricter BIP32 decoding and test vector 5 (master...202108_bipvec5) https://github.com/bitcoin/bitcoin/pull/22836
<bitcoin-git> bitcoin/master 01fa148 fanquake: Merge bitcoin/bitcoin#22836: Stricter BIP32 decoding and test vector 5
<bitcoin-git> bitcoin/master 56a42f1 Pieter Wuille: Stricter BIP32 decoding and test vector 5
<bitcoin-git> [bitcoin] fanquake merged pull request #22837: doc: mention bech32m/BIP350 in doc/descriptors.md (master...202108_bip350descdoc) https://github.com/bitcoin/bitcoin/pull/22837
<bitcoin-git> bitcoin/master dc9ffb6 fanquake: Merge bitcoin/bitcoin#22837: doc: mention bech32m/BIP350 in doc/descriptor...
<bitcoin-git> bitcoin/master d2a09c8 Pieter Wuille: doc: mention bech32m/BIP350 in doc/descriptors.md

2021-08-31

<bitcoin-git> [bitcoin] fanquake merged pull request #22796: RBF move (1/3): extract BIP125 Rule 5 into policy/rbf (master...2021-08-rbf-1) https://github.com/bitcoin/bitcoin/pull/22796
<bitcoin-git> bitcoin/master b001b9f glozow: MOVEONLY: BIP125 max conflicts limit to policy/rbf.h

2021-08-30

<bitcoin-git> [bitcoin] sipa opened pull request #22837: doc: mention bech32m/BIP350 in doc/descriptors.md (master...202108_bip350descdoc) https://github.com/bitcoin/bitcoin/pull/22837
<bitcoin-git> [bitcoin] sipa opened pull request #22836: Stricter BIP32 decoding and test vector 5 (master...202108_bipvec5) https://github.com/bitcoin/bitcoin/pull/22836

2021-08-27

<gribble> https://github.com/bitcoin/bitcoin/issues/22698 | Implement RBF inherited signaling and fix getmempoolentry returned bip125-replaceable status by mjdietzx · Pull Request #22698 · bitcoin/bitcoin · GitHub
<michaelfolkson> laanwj: I agree at least a comment/addendum on BIP125 saying that Core doesn't implement it in full is a good idea
<laanwj> then consider if we want to really implement BIP125 instead
<michaelfolkson> If the code and the Core documentation don't match you would just update the documentation. But presumably BIPs have got buy in from alternative implementations and today Lightning implementations etc
<gribble> https://github.com/bitcoin/bitcoin/issues/22698 | Implement RBF inherited signaling and fix getmempoolentry returned bip125-replaceable status by mjdietzx · Pull Request #22698 · bitcoin/bitcoin · GitHub
<bitcoin-git> [bitcoin] fanquake closed pull request #21144: test: convert feature_bip68_sequence.py to use MiniWallet (master...test-feature-bip68-sequence-without-wallet) https://github.com/bitcoin/bitcoin/pull/21144

2021-08-26

<bitcoin-git> [bitcoin] fanquake merged pull request #21862: test: Set regtest.BIP65Height = 111 to speed up tests (master...2105-testFasterBip65) https://github.com/bitcoin/bitcoin/pull/21862
<bitcoin-git> bitcoin/master faf7e48 MarcoFalke: Set regtest.BIP65Height = 111 to speed up tests
<bitcoin-git> bitcoin/master adccbb3 fanquake: Merge bitcoin/bitcoin#21862: test: Set regtest.BIP65Height = 111 to speed ...
<harding> Differing mempool policies was actually anticipated, BIP125 says: "A Bitcoin Wiki page has been created to help wallet authors track deployed mempool policies relating to transaction replacement." which links to https://en.bitcoin.it/wiki/Transaction_replacement
<harding> (I don't really care, but I'm slightly against changing old BIPs, though I wouldn't mind adding a note to the bottom about the issue.)
<sipa> FWIW, i disagree with changing the BIP - the number refers to the idea as it's written down, and changing it would only add confusion ("do you mean the old BIP125 approach or the new one?"); if we feel that this deserves a BIP in the first place, i think it'd need to be a new one
<harding> michaelfolkson: of course what's in an implementation should overrule what's in a BIP. BIPs are not laws, they're documentation.
<harding> michaelfolkson: to nitpick a little, LN was first described several months before BIP125 was written, and there were two different types of payment channels available for use at that time (BlueMatt wrote the implementation of one; I was on the team that wrote a different implementation which had just gone into light production use). Certainly second layer protocols are much more important today than they were back then, but it's not like
<michaelfolkson> I guess if there are no policy BIPs ever again then it is less relevant. But I kinda think there should be. But the attitude of "the BIP gets overruled by whatever ended up in Core" shouldn't cut it in today's environment
<harding> I don't even know what "take the BIPs more seriously" means.
<harding> michaelfolkson: I don't think anyone took BIP125 less than seriously when it was written.
<michaelfolkson> Going forward I think we need to take the BIPs more seriously. Different world when the BIP was originally written
<ariard__> michaelfolkson: re bip125, well i'm still aiming to propose full-rbf for 0.24, though there is no guarantee it will land, still have to reach out to more historical opponents to have them express an opinion
<bitcoin-git> [bitcoin] MarcoFalke opened pull request #22809: test: Check that non-signaling BIP125 tx can be replaced via parent (master...2108-testTxReplace) https://github.com/bitcoin/bitcoin/pull/22809
<sipa> as BIP125/opt-in RBF in general are just gentlemen's agreements that are probably untenable in a rational market long-term
<kalle> midnight: I don't think there was a bips channel, and I feel like a non-core-focused dev channel would be nice to have, at least. Whoever the genie is, I propose we try restoring #bitcoin-dev. :)
<midnight> In the prior network I believe -bips- discussion had its own channels.

2021-08-25

<bitcoin-git> [bitcoin] glozow opened pull request #22796: RBF move (1/n): extract BIP125 Rule 5 into policy/rbf (master...2021-08-rbf-1) https://github.com/bitcoin/bitcoin/pull/22796

2021-08-18

<bitcoin-git> [bitcoin] fanquake closed pull request #14032: Add p2p layer encryption with ECDH/ChaCha20Poly1305 (master...2018/08/bip151) https://github.com/bitcoin/bitcoin/pull/14032
<bitcoin-git> [bitcoin] fanquake closed pull request #14049: Enable libsecp256k1 ecdh module, add ECDH function to CKey (master...2018/08/bip151_ecdh) https://github.com/bitcoin/bitcoin/pull/14049
<bitcoin-git> [bitcoin] fanquake closed 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

2021-08-16

<harding> I know someone reading about the merge of disabling BIP37 by default ended up in the discussion that got it continued for an extra release, so that kind of communication works at least some times.

2021-08-13

<bitcoin-git> [bitcoin] mjdietzx opened pull request #22698: Fix CVE-2021-31876 RBF inherited signaling and fixes getmempoolentry returned bip125-replaceable status (master...fix_bip125_inherited_signaling) https://github.com/bitcoin/bitcoin/pull/22698

2021-08-10

<bitcoin-git> [bitcoin] laanwj merged pull request #22632: test: Set regtest.BIP66Height = 102 to speed up tests (master...2108-regtestFasterBip66) https://github.com/bitcoin/bitcoin/pull/22632
<bitcoin-git> bitcoin/master 0b5344b W. J. van der Laan: Merge bitcoin/bitcoin#22632: test: Set regtest.BIP66Height = 102 to speed ...
<bitcoin-git> bitcoin/master fafe896 MarcoFalke: test: Set regtest.BIP66Height = 102 to speed up tests

2021-08-03

< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16333: test: Set BIP34Height = 2 for regtest (master...1906-bip34H2) https://github.com/bitcoin/bitcoin/pull/16333
< bitcoin-git> bitcoin/master 222290f MarcoFalke: test: Set BIP34Height = 2 for regtest
< bitcoin-git> bitcoin/master ad0fc45 MarcoFalke: Merge bitcoin/bitcoin#16333: test: Set BIP34Height = 2 for regtest

2021-07-31

< sipa> it seems it doesn't know that type 5 is MSG_WTX (defined in BIP339)

2021-07-30

< michaelfolkson> And ideally not 10 BIPs for Miniscript :)
< achow101> gene: that exists already, see BIPs 44/49/84/86

2021-07-16

< achow101> There are proposed taproot fields for psbt PR'd to the bips repo: https://github.com/bitcoin/bips/pull/1139

2021-07-12

< sipa> you know i co-authored the taproot bips right?

2021-07-02

< michaelfolkson> I'm assuming you'd like some feedback on your two BIPs achow101?

2021-07-01

< ariard> bip90
< ariard> bip90
< vasild> sdaftuar: "to what extent it makes sense for nodes that don't understand, say, i2p addresses to be participating in i2p address relay at all" -- https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki contains this sentence: "Clients are RECOMMENDED to gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and
< vasild> sdaftuar: "to what extent it makes sense for nodes that don't understand, say, i2p addresses to be participating in i2p address relay at all" -- https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki contains this sentence: "Clients are RECOMMENDED to gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and

2021-06-22

< dhruv> BIP324 question: Does the 3-byte encrypted length in the proposed AEAD construct include the 3 bytes of the length itself? The test vector here seems to imply so but it would be nice to confirm: https://github.com/bitcoin/bitcoin/blob/327e2691f6e0498aa868af965bb4a951c5be17c5/src/test/crypto_tests.cpp#L710

2021-06-18

< bitcoin-git> [bitcoin] MarcoFalke opened pull request #22277: test: Properly set BIP34 height in CreateNewBlock_validity unit test (master...2106-test34) https://github.com/bitcoin/bitcoin/pull/22277

2021-06-17

2021-06-16

< ariard> notwithstanding making the discussion far less heated for the sake of everyone, i agree that's a sender-only change and i don't see how it would restrain a future bip155 client to probe addrv2 support with its selected v22.0+ peers
< laanwj> by itself (without other context) it seemed like a misinterpretation of BIP155 as i had intended it
< laanwj> vasild: yes, likely instead of your proposed BIP155 change
< jnewbery> a pre-bip155 bitcoin core node will send a getaddr, which implies that it wants to receive addresses
< jnewbery> laanwj: A BIP cannot specify that not sending something implies some meaning. BIPs are opt-in. I can't say in my BIP "not sending this message implies thing".
< vasild> anyway, if sendaddrv2 signalled preference to receive unrequested address messages, then bitcoin core-pre-bip155 do not want to receive unrequested address messages?
< laanwj> well it is how I intended BIP155, I don't really agree with the new interpretation
< laanwj> there could have been a third option in BIP155 but there wasn't
< laanwj> https://github.com/bitcoin/bips/pull/1134 clears it up for me
< jnewbery> but this isn't misinterpreting BIP155. BIP155 is totally irrelevant for links that don't support address relay
< laanwj> no, I'm arguing against misinterpreting BIP155
< laanwj> I did think a signal whether a peer is interested in address messages or not is orthogonal to what messages it supports or not, there was discussion to include this in BIP155 at some point but it wasnm't
< vasild> I opened https://github.com/bitcoin/bips/pull/1134 to clarify BIP155
< jonatack> those do seem like separate concerns / flags / BIPs etc
< jonatack> in the BIP155 discussions nearly a year ago, it was decided that disable addr was a separate concern from BIP155-capable, thus the current implementation
< laanwj> vasild: yes i remember during the bip155 discussion there were some ideas to also incorporate 'do not send me addresses at all', but this was not done, i had to think of this with #22245

2021-06-15

< sipa> someone who doesn't care about addrv2 isn't going to implement BIP155, and thus isn't going to send sendaddrv2 either?
< sipa> in order to implement BIP339 you must send wtxidrelay
< sipa> but you're free not to implement BIP339
< ariard> sounds more an oddity of bip339
< amiti> and then there was a question about BIP155 on #22245, I've posted my thoughts on the PR, but want to give anyone the chance to raise questions / any remaining concerns
< sipa> i saw some discussion with laanwj about bip155 changes, so maybe it's useful

2021-06-03

< sipa> it means backporting bip155

2021-06-01

< bitcoin-git> [bitcoin] adamjonas closed pull request #20074: test: p2p_blockfilters tests for BIP157 config args (master...bip157-blockfilters-tests) https://github.com/bitcoin/bitcoin/pull/20074

2021-05-31

< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22095: test: Additional BIP32 test vector for hardened derivation with leading zeros (master...bip32-test) https://github.com/bitcoin/bitcoin/pull/22095
< bitcoin-git> bitcoin/master 8c6df2b MarcoFalke: Merge bitcoin/bitcoin#22095: test: Additional BIP32 test vector for harden...

2021-05-28

< bitcoin-git> [bitcoin] kristapsk opened pull request #22095: test: Additional BIP32 test vector for hardened derivation with leading zeros (master...bip32-test) https://github.com/bitcoin/bitcoin/pull/22095

2021-05-17

< luke-jr> sipa: can you take a look at https://github.com/bitcoin/bips/pull/935 ? there's 2 other BIPs affected with ACKs already; thanks
< wumpus> oh and completely unrelated quips like https://github.com/bitcoin/bips/pull/1096#issuecomment-827356885
< aj> wumpus: i think that was the idea, but don't think it's worked very well; cf "Drop BIP comments" at https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist
< wumpus> yes i don't know, if the idea is that outsiders can add their own comments to BIPs, then closing it to say org members only wouldn't be great
< 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] MarcoFalke merged pull request #21925: doc: Update bips.md for 0.21.1 (master...2105-docBips) https://github.com/bitcoin/bitcoin/pull/21925
< 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
< 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> and BIP8 requires *a choice* of that
< 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> 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> ST/BIP8 had (has?) widespread support, not ST/BIP9
< luke-jr> the community is almost unanimous in favour of BIP8
< 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> Maybe remove BIP8 LOT=true?
< jeremyrubin> What is BIP8 LOT=? satisfying
< 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
< core-meetingbot> topic: Attempts to use "dev muscle" to force MTP against community consensus of BIP8 (luke-jr)
< wumpus> #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
< wumpus> #topic How far do we want to backport BIP350/bech32m support? (sipa)
< luke-jr> sipa: not sure why BIP350 would be eligible for backporting at all
< 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