<sipa>
informed by the BIP50 fiasco (bdb/leveldb locking fork)
2025-05-16
<_aj_>
(reading meeting backlog) perhaps one thing we could consider is publishing better docs, in particular design docs? for some things, that's handled by BIPs already, but, eg if you want to know about the chainstate database, utxo set, pruning, etc, you're either looking at code/PR history, third party articles, stack exchange q&a, and maybe optech articles. adding our own docs that answer
2025-05-09
<achow101>
I usually just use bip32.org
2025-05-08
<Murch[m]>
It would fix that bans by Bitcoin Core affect BIPs, but it would not fix the org split that Bitcoin Core has currently, nor disclaim that Bitcoin Core is Bitcoin
<fjahr>
why not move the bips then?
<laanwj>
in a way moving bips is more controversial than moving bitcoin core, as bips does belong with the global network/blockchain and is shared between implementations
<furszy>
yeah.. I just don't see any value in jumping straight into another public debate right now. There's risk involved in moving the main repo, but no risk in moving only the BIPs repo. Maybe we could start with that for now?
<jonatack>
"may indeed be a good idea" -> bips migration to bitcoin-bips
<jonatack>
i don't have a strong opinion about moving the bips repo
<_aj_>
if bips is going to auto-ban everyone bitcoin-core does, what's the point?
<pinheadmz>
isnt the whole point to separate bans between bips and bitcoin core ?
<kanzure>
not urgent at the moment but is there a way i could subscribe to bitcoin-core/ gh bans to auto-ban on the bips org to not duplicate that work
<fjahr>
The danger of moving the repo seems extremely limited but I guess since we discussed them at length last time I am leaning to just moving the bips because that's the safest option. But not a strong opinion.
<jonatack>
I think the BIPs case is separate from the bitcoin core one.
<Murch[m]>
There was a little bit of a debate about the bans in the past days affecting the BIPs repo as well, but I don’t think any of the affected parties were actively contributing to the BIPs repo at the time and the bans were short…
<achow101>
yes, just saying that there have been bans issued for obvious spam in the bips repo, without the bips editors asking
<achow101>
jonatack: I've definitely banned several spammers from the bips repo over the past year
<jonatack>
in the BIPs
<achow101>
moving the bips repo is up to the bip editors decide
<Murch[m]>
Some BIP Editors appear to think that the bitcoin org is the correct place for BIPs while Bitcoin Core should move out. Others seem fine with the move.
<stickies-v>
if the bips ban issue is fixed, there's no real urgency here?
<furszy>
+1 on moving the bips repo only - if that's needed due to the recent temp bans
<achow101>
one thing I want to point out is that the recent temp bans being issued do affect the bips repo too
<stickies-v>
not necessarily opposed but doesn't feel important pushing this through atm, let's just move bips and move on for now?
<vasild>
did anything happen with the bip repo in the meantime, e.g. did bip people decide to move it away from bitcoin/bips?
2025-04-29
<bitcoin-git>
bitcoin/master a679040 Anthony Towns: consensus/params: Move version bits period/threshold to bip9 param
2025-04-24
<sr_gi[m]>
I personally think that the risk of github breaking redirects is higher than someone in the bitcoin org creating a bips repo, and what the implications may be
<vasild>
so the only solution seems to be to move bitcoin/bips to another org and leave the rest as it is?
<sipa>
not that i have any reason to distrust the current bips editors with that, to be clear
<darosior>
(if keeping bips repo)
<sr_gi[m]>
As opposed to keeping either bitcoin or bips on it
<fjahr>
faking activity is also easy but not sure worth the effort and better than moving bips
<glozow>
sipa: I think the cleaner solution to that is to have bips move though. Because assuming we're retaining ownership of the bitcoin org, we're still the ones pressing the ban button for bips
<sipa>
willcl-ark: i think the fact that it's not possible to ban someone from the Bitcoin Core org without also banning them from the BIPs org (whatever those orgs are) is a good motivation. It's not the reason on itself, but it demonstrates there is a mismatch in organisational structure. There is absolutely no reason why people maintaining a piece of software should have the ability to ban someone from
<vasild>
another possibility is to keep bitcoin/bitcoin as it is and move bitcoin-core/* into bitcoin/; move bitcoin/bips into another org
<achow101>
moving our repo can be done before they decide what to do with bips though
<sipa>
fanquake: i think *our* decision here is whether to move bitcoin/bitcoin to bitcoin-core/bitcoin; the question whether bitcoin/bips moved elsewhere is up to the BIP editors
<fanquake>
why wouldn't bips exist there
<laanwj>
sipa: no i don't think so, if they want an org they can have bitcoin-bips
<achow101>
sipa: I guess so? I'd still prefer to also move bips out and we can sunset bitcoin/
<sipa>
Would the bitcoin org ownership be handed to the BIPs editors then?
<darosior>
Leaving bips in bitcoin/ and having Core in bitcoin-core/ does make sense to me, although i haven't thought about drawbacks.
<cfields>
hmm, looking at what would be left in bitcoin/, it'd just be bips/libblkmaker/libbase58. There's been discussion about moving/deprecating the latter 2 for years. So that'd just leave bips in bitcoin/.
<willcl-ark>
What are the advantages of vacating bitcoin/bitcoin? My natural instinct would be to retain that and move bips/ out from bitcoin/?
<sipa>
Ignoring history, I think having bitcoin/bips and bitcoin-core/bitcoin makes most sense, in that BIPs are actually aiming to be a whole-Bitcoin-ecosystem wide thing.
<laanwj>
yes could move the bips repo as well, empty out "bitcoin" completely eventually
<glozow>
Another solution is to move the bips repo somewhere else? iirc laanwj mentioned having an org already?
<achow101>
The solution to this issue is to not have both Bitcoin Core and BIPs under the same organization. We already have the bitcoin-core organization where all of our new repos go anyways, it would entirely make sense to move bitcoin/bitcoin to bitcoin-core/bitcoin-core, or something like that. There's also a bitcoin-bips organization that was created a couple of years ago for this, so bips could be moved there. But I think that's for the bip editors
<achow101>
This past week, the topic of moving the repo to bitcoin-core has come up again due to possible issues with conflicting moderation between bitcoin/bitcoin and bitcoin/bips. The main point is that bans are issued at the organization level, but Bitcoin Core and BIPs are really two separate projects. It is therefore conceivable that Bitcoin Core would want to ban someone, but BIPs would not, and vice versa. Under the current setup, any ban from one
2025-04-21
<bitcoin-git>
bitcoin/master 6268bde Ava Chow: descriptor: Remove unused parent_info from BIP32PUbKeyProvider::GetPubKey
<achow101>
I finally got around to writing test vectors for BIP 373. The test vectors are added to the bip in bips#1764, and I've updated #31247 with them as well.
2025-02-06
<Murch[m]>
<achow101> "i rarely see anyone use request..." <- I think it’s used frequently in the BIPs repo
<Murch[m]>
We have had a lot of spam in the BIPs repository
2025-02-05
<bitcoin-git>
[bitcoin] jonatack opened pull request #31805: doc: improve NODE_NETWORK_LIMITED documentation per BIP159 (master...2025-02-NODE_NETWORK_LIMITED-documentation) https://github.com/bitcoin/bitcoin/pull/31805
2025-02-04
<lightlike>
so they would reject all blocks-only connections they have as inbounds quickly?! is this dependent on v2 transport (BIP324) being used?
2025-02-03
<sipa>
my thinking is that the first time you start up with BIP66-enforcing software, you'd have a chainstate whose tip points to a block whose headers chain is invalid, in this setting
<sipa>
i'm now somewhat curious what would have happened if you upgraded to BIP66 while you were on the forked chain that it caused
<sipa>
hmm, perhaps the header-impacting aspects for BIP34, BIP65, and BIP66 (the fact that after 950 out of the past 1000 blocks signal, all blocks are required to signal) could be considered a re-validation aspect
<darosior>
People who were around then, how did BIP113 deal with the upgrade issues mentioned in ConnectBlock? (It only check if a bad block wasn't let in using CheckBlock, not CtxCheckBlock[Header].) It seems the PR that implemented it only had a check in CtxCheckBlock() and none in ConnectBlock() so in theory an invalid block post-activation could have been
<corebot>
https://github.com/bitcoin/bips/issues/1695 | BIP373: Clarify where keys in MuSig fields may appear in the Taproot output by achow101 · Pull Request #1695 · bitcoin/bips · GitHub
<josie>
personally, i think there should be an important distinction between BIPs (broader bitcoin ecosystem) and bitcoin core (implementation). if you are interested in running a bips irc channel / or a wg, id be happy to join tho, as im interested in both
<jonatack>
by dint of the bips work, am spending a fair amount of time on keeping up with the new opcodes / covenants / (centralized) MEV discussions
2024-10-30
<bitcoin-git>
[bitcoin] achow101 merged pull request #31156: test: Don't enforce BIP94 on regtest unless specified by arg (master...202410_bip94_arg) https://github.com/bitcoin/bitcoin/pull/31156
<bitcoin-git>
bitcoin/master fc7dfb3 Martin Zumsande: test: Don't enforce BIP94 on regtest unless specified by arg
<bitcoin-git>
bitcoin/master 4a31f8c Ava Chow: Merge bitcoin/bitcoin#31156: test: Don't enforce BIP94 on regtest unless s...
2024-10-25
<bitcoin-git>
[bitcoin] mzumsande opened pull request #31156: test: Don't enforce BIP94 on regtest unless specified by arg (master...202410_bip94_arg) https://github.com/bitcoin/bitcoin/pull/31156
2024-10-24
<sipa>
reorgs and bip30 shenanigans complicate this further
2024-10-23
<glozow>
I think we may have changed what "lexicographical order" means from BIP331, or maybe I updated that as well, but I can't remember
<gmaxwell>
It's withdrawn as a consensus rule, but it's the rational behind the standardness rules we've been discussing. Normally BIPs aren't written for standardness rules, though they probably should be for ones that aren't just subjective, e.g. ones that prevent attacks.
<portlandhodl>
I had never read BIP62 due to the withdrawn status.
<portlandhodl>
Thank you, revised policy will be implemented around OP_SUCCESSx. I had spent a lot of time creating logic around the ScriptPubKey and rules around hooks, but didn't enforce it in Tapscript because of BIP342.
<jonatack>
and Murch[m] tweets about merges of new bips
<jonatack>
@bitcoinmerges account in https://x0f.org (fediverse) currently toots all core, gui and bips merges
<achow101>
bips are separate from bitcoin core
<achow101>
jonatack: I think bips should have it's own channel
<jonatack>
Question, would people like to see BIPs merges in this channel?
2024-07-03
<bitcoin-git>
bitcoincore.org/master 4b564d3 Antoine Poinsot: posts: disclose historical DoS vulnerability (BIP70)
2024-06-29
<jonatack>
github profile @5twelve has been spamming the bips and bitcoincore repos with review approvals, generating a bunch of noisy notifications
2024-06-26
<bitcoin-git>
[bitcoin] willcl-ark opened pull request #30341: WIP: Permit Combiner to strip bip32_deriv information (master...psbt-strip-derivs-combine) https://github.com/bitcoin/bitcoin/pull/30341
2024-06-20
<bitcoin-git>
bitcoin/master 5120ab1 Pieter Wuille: net_processing: drop 8 headers threshold for incoming BIP130
2024-06-04
<josie>
sipa: cool! regarding partial descriptors, is the expectation that partial descriptors will be specified in their own bips, similar to how new descriptors are added? novo has been working on an implementation for rawleaf and rawnode partial descriptors and ive been helping out a bit, so mainly asking out of curiosity
2024-05-23
<glozow>
Things moving with TRUCs/BIP431/v3. #29873 looks really close. Just working on some comments on the BIP (which now has a number!) as well.
2024-05-16
<achow101>
but not so much brigading currently, although the taproot assets and ordinals bips prs have attracted that in the past
<jonatack>
thankfully on the bips repo it's been limited so far
2024-04-25
<bitcoin-git>
[bitcoin] achow101 merged pull request #29615: test: fix accurate multisig sigop count (BIP16), add unit test (master...202403-test-fix_GetSigOpCount_accurate_counting_bip16) https://github.com/bitcoin/bitcoin/pull/29615
<bitcoin-git>
bitcoin/master 50b09e8 Ava Chow: Merge bitcoin/bitcoin#29615: test: fix accurate multisig sigop count (BIP1...
<bitcoin-git>
bitcoin/master 3e9c736 Sebastian Falbesoner: test: fix accurate multisig sigop count (BIP16), add unit test
<sipa>
in theory, it is legal to have 33-byte public keys in BIP342, but that's just a future extension mechanism, it has no semantics associated with it
<sipa>
but _all_ of them are in the emitted script expanded to the corresponding 32-byte xonly key, because that's the only thing that has meaning as of BIP342
<sipa>
i guess this can be clearer in BIP386, it's a bit ambiguous in "Modified Key Expression" section which phrasings are about the descriptor notation, and which about the emitted keys in scripts
<Chris_Stewart_5>
sipa: I do suspect that this test vector is still wrong, but I don't see an easy way to implement it in bitcoin core. The reason I suspect its wrong is because if I omit the parity byte i get the "correct" script (according to BIP386). If I add the parity byte I get something else ('5120756a5aace335408f938e4e032d56e3bbdfb9833520e3041a3518c89b3f21949b').
<Chris_Stewart_5>
achow101: sipa I was working on BIP386 and was getting hung up on this descriptor:
<bitcoin-git>
[bitcoin] theStack opened pull request #29615: test: fix accurate multisig sigop count (BIP16), add unit test (master...202403-test-fix_GetSigOpCount_accurate_counting_bip16) https://github.com/bitcoin/bitcoin/pull/29615
<bitcoin-git>
[bitcoin] glozow merged pull request #29452: doc: document that BIP324 on by default for v27.0 (master...bip324_on_default) https://github.com/bitcoin/bitcoin/pull/29452
<bitcoin-git>
bitcoin/master ddf1d72 glozow: Merge bitcoin/bitcoin#29452: doc: document that BIP324 on by default for v...
<bitcoin-git>
bitcoin/master 0d3e18b fanquake: doc: document that BIP324 on by default for v27.0
<bitcoin-git>
[bitcoin] fanquake opened pull request #29452: doc: document that BIP324 on by default for v27.0 (master...bip324_on_default) https://github.com/bitcoin/bitcoin/pull/29452
2024-02-14
<bitcoin-git>
[bitcoin] stratospher opened pull request #29431: test/BIP324: disconnection scenarios during v2 handshake (master...more-v2-tests) https://github.com/bitcoin/bitcoin/pull/29431
2024-02-11
<bitcoin-git>
[gui] hebasto merged pull request #752: Modify command line help to show support for BIP21 URIs (master...update-help-BIP21-URI) https://github.com/bitcoin-core/gui/pull/752
<bitcoin-git>
bitcoin/master ede5014 Hernan Marino: Modify command line help to show support for BIP21 URIs
<bitcoin-git>
[bitcoin] theStack opened pull request #29390: test: speedup bip324_crypto.py unit test (master...202402-speedup_bip324_cipher_python_tests) https://github.com/bitcoin/bitcoin/pull/29390
<josie>
sipa: which is good for other implementations as well! if we had a high level, hard to abuse api, it de-risks wallets outside of core implementing bip352
<jonasschnelli>
Might be a dead end, but now that v2 p2p is here, I though it would be not overly dumb to use BIP39 via an authenticated p2p connection to a self-run/trusted node.
<sipa>
there is a link to a writeup in bip324
<jonasschnelli>
I was wondering if it would make sense to revive BIP150 (p2p authentication) now that V2 p2p is available. Authenticating designated p2p connections could be a useful feature.
<sipa>
achow101: for automatic connections, if both sides run with `-v2transport`, and the service flag propagated ahead of time, a bip324 connection will be used
<sipa>
which i consider the one blocker to enabling bip324 b
<instagibbs>
re:bip324, did all the open testing PRs get merged? it seems t obe getting reasonable runtime as I've seen both incoming and outgoing v3 connections
<achow101>
The 27.0 feature freeze is in a month, so what defaults should we try to get for bip324 in before then?
<achow101>
#topic bip324 defaults for 27.0 (achow101)
<sipa>
BlueMatt[m]: no, BIP144 is P2P protocol; though fair enough, RPC isn't P2P either
<BlueMatt[m]>
yes, but BIP144 is about consensus, and these are not consensus :p
<sipa>
BlueMatt[m]: BIP144 says you cannot use the extended encoding if there are no witnesses
<bitcoin-git>
[bitcoin] fanquake merged pull request #28951: fuzz: BIP324: damage ciphertext/aad in full byte range (master...202311-fuzz-bip324-damage_in_full_byte_range) https://github.com/bitcoin/bitcoin/pull/28951
<bitcoin-git>
bitcoin/master 05d3f8e fanquake: Merge bitcoin/bitcoin#28951: fuzz: BIP324: damage ciphertext/aad in full b...
<bitcoin-git>
bitcoin/master e67634e Sebastian Falbesoner: fuzz: BIP324: damage ciphertext/aad in full byte range
<RubenSomsen>
A change we're considering in outpoint hashing (to make things simpler for hardware wallets) has an issue with forced collisions (worst case is address reuse), a possible fix is being discussed at https://github.com/bitcoin/bips/pull/1458#discussion_r1395934177
<RubenSomsen>
Still actively taking review on BIP352, responding to feedback, and wanting review on #25273.
2023-11-28
<bitcoin-git>
[bitcoin] theStack opened pull request #28951: fuzz: BIP324: damage ciphertext/aad in full byte range (master...202311-fuzz-bip324-damage_in_full_byte_range) https://github.com/bitcoin/bitcoin/pull/28951
2023-11-16
<RubenSomsen>
No major changes. Still actively taking review on BIP352, responding to feedback and wanting review on #25273.
<RubenSomsen>
Actively taking review on BIP352 and responding to feedback. Biggest recent change is how labels are calculated. Every label is a completely independent 32-byte value now, could use more eyes on that change.
2023-11-02
<maxedw>
so are we thinking: BIP324, Submit package, MacOS packaging, TapMiniscript
<fjahr>
IMO BIP324 should definitely be included, there are a lot of people excited about turning it on in mainnet. For assumeutxo I would really like it if there would still be some encouragement still to test it. Bonus section sounds good to me.
<lightlike>
I think that bip324 has sufficient "hype" in the wider community that many users will turn it on on mainnet - so it should be included in the testing.
<sipa>
i think there's a difference between BIP324 and assumeutxo still; the former will probably end up being enabled by some, on mainnet, following 26.0 release, while assumeutxo is actually not usable on mainnet
<RubenSomsen>
Actively taking review on BIP352 and responding to feedback. Currently reworking how the outpoints are hashed.
2023-10-26
<sipa>
i've added some mentions of BIP324 support (because while it's off by default, it can be enabled on mainnet)
<luke-jr>
I think non-adjusted is only relevant because BIP141 specified it
2023-08-24
<sipa>
but bip173 has tighter range requirements than just the bech32 ones
<PaperSword>
If you are inclined to answer this one as well, I have looked at BIP173 which you authored. You state that "string is at most 90 characters long..." then detail the spec of at min 1 hrp char, 1 separator, and 6 data chars. As such is the minimum length implied from the spec as 8 base32 chars?
<furszy>
so the node connects to bip324 peers because of a change in the desirable services flags?
<sipa>
so i think 28331 will probably be my last big PR relating to bip324
<sipa>
which i plan to leave out of 28331, but my plan is to work now on adding unit and functional tests (which don't require bip324 in python) to 28331
<sipa>
there is also stratospher's bip324 implementation in test framework, and tests using it
<sipa>
achow101: possibly - i'm happy to continue with bip324 stuff without 28100 so it's not a blocker
<sipa>
28165 is i think mostly independently-useful improvements (though inspired by the needs of bip324)
2023-08-15
<achow101>
sipa: what's the next bip324 pr?
<hdbbdh>
I have a question with transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192633166 on bitcoin mainnet. It's the transaction given in BIP16 for P2SH, but I can't find the signature for the redeem script. Why isn't there a signature?
2023-08-11
<sipa>
hi! back online; will address feedback on bip324-related PRs next week
2023-08-10
<b10c>
currently bitcoin/bitcoin, bitcoin/bips, bitcoin-core/secp256k1, bitcoin-core/gui, but will consider other repos with important comments if there are requests
2023-08-03
<sipa>
Interesting; that must mean either some other people are running it with *, or are running the old bip324 branch.
<sipa>
@Sjors What did you set for -bip324= ?
<sipa>
After that, I'll probably drop the test-only -bip324 option from the v2 transport stuf, and implement actual service bit based decisions, maybe in a separate PR.
<sipa>
bitcoin.sipa.be runs this code, if you need a remote to connect to (-addnode=NAME -bip324=NAME should suffice).
<sipa>
With the last one, you can experiment with bip324 connections, though in a test-only form only (using -bip324=ip).
2023-08-01
<pinheadmz>
hm i saw bip324 PR open message on matrix but not IRC
<sipa>
If anyone wants to experiment with bip324 connections: ^
2023-07-27
<sipa>
I'm working on a follow-up that will depend on both of these, that adds the actual v2 transport code, which may offer a way to force (with a test-only option) actual BIP324 connections to test with.
<sipa>
I've opened two preparatory ones as they're kind of stand-alone improvements (27985 and 27993), but the next big I plan to open today (the bip324 stream ciphers FSChaCha20 and FSChaCha20Poly1305).
<bitcoin-git>
[bitcoin] kiminuo opened pull request #27928: Add more tests for the BIP21 implementation (master...feature/2023-BIP21-URI-tests) https://github.com/bitcoin/bitcoin/pull/27928
<josie>
is there a reason we use bcrt for regtest in bitcoin core? its not defined in BIP173 or BIP350 and it seems easier to use the same HRP for all test networks
2023-06-08
<achow101>
josie: open to the bips repo and you'll get a number
<sipa>
no BIP324 updates, i expect there'll be progress on ellswift secp next week
<jamesob>
For what it's worth, I've created ##bitcoin-assumeutxo and ##bitcoin-bip345 for discussion on those topics. I'm going to try to post more in there as opposed to DMing, so if you've been active on those projects, please join!
<glozow>
luke-jr: I think I know what you are talking about and will follow up offline. For the sake of saying things in the open, I had a couple in-person conversations about bip35+37 usage in miami. Was open about what I think the disadvantages are but did not intend/realize it to be seen as "pressuring." Will follow up to try to clear things up.
<furszy>
yeah. There are two modes: manual and automatic. The manual mode moves the sync responsibility to any external software (RPC commands to request filters, get the wallet needle set, check if filter matches, request the block, etc). And a automatic mode that follows bip157 client side specs.
<furszy>
so.. will try to get in-touch with Bisq and see what they have planned. Even if this doesn’t get into core soon (or never if there is no consensus), it’s a good use case for them and for us to get rid-off bip35 and bip37 net support.