<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.
<darosior>
About the BIP37 issue i was stunt too so i've asked on Twitter yesterday why do those node-in-a-box set `peerbloomfilters` and a Raspiblitz contributor said it was indeed for Bisq support (as glozow suggested). https://twitter.com/darosior/status/1653037196704727046
<sipa>
BIP37 (or BIP111 now...) support should really be enabled just for peers trusted not to DoS.
<sipa>
If we do want to keep support for that, I think it's reasonable to indeed exclude non-yet-announced transactions from the BIP35 response.
<bitcoin-git>
[bitcoin] jonatack opened pull request #27385: net: extract Network and BIP155Network logic to node/network (master...2023-04-extract-network) https://github.com/bitcoin/bitcoin/pull/27385
2023-03-25
<andytoshi>
i see, i think i'd misunderstood bip32 ... we always specify paths as <xpub>/1/2/3 or m/1/2/3 where the m is literally 'm' and the seed is off to the side somewhere
<andytoshi>
achow101: is it true that with descriptor wallets, there is no way to provide your own bip32 seed?
2023-03-15
<sipa>
@PaperSword A bech32 encoding can have more than one "1" in it, under the conditions you state. But a BIP173 address cannot, as it has HRP "bc" or "tb".
2023-03-13
<bitcoin-git>
bitcoin/24.x 787affb fanquake: doc: update version in bips.md to v24.1
2023-03-08
<MacroFake>
kalle: GitHub Actions requests write access as the CI, last time we checked. Which seems inappropriate. Not sure if this is relevant for the BIPs repo, but for Bitcoin Core we'd also want to be able to easily switch providers or run locally, so there is a single entry point script to be maximally flexible.
<kalle>
As a sidenote, I was able to enable Cirrus CI on the bips repo on my own, but now that I chose not to use it, only an org owner is able to undo that. Someone should probably do that at some point. No rush though. :/
<kalle>
Someone pointed out Github Actions may be a better choice over Cirrus CI, so I tried that and it ultimately felt more intuitive. Anyway, would be nice ifs omeone gave https://github.com/bitcoin/bips/pull/1432 a quick look.
<kalle>
Can someone enable cirrus CI on the bitcoin/bips repo plox?
2023-02-28
<bitcoin-git>
[bitcoin] brunoerg opened pull request #27177: test: fix intermittent issue in `feature_bip68_sequence` (master...2023-02-fix-feature-bip68-test) https://github.com/bitcoin/bitcoin/pull/27177
2023-02-21
<bitcoin-git>
[bitcoin] achow101 merged pull request #27122: script: BIP341 txdata cannot be precomputed without spent outputs (master...202302_tap_ready_needs_prevouts) https://github.com/bitcoin/bitcoin/pull/27122
<bitcoin-git>
bitcoin/master 95f12de Pieter Wuille: BIP341 txdata cannot be precomputed without spent outputs
<bitcoin-git>
bitcoin/master ad46141 Andrew Chow: Merge bitcoin/bitcoin#27122: script: BIP341 txdata cannot be precomputed w...
2023-02-17
<bitcoin-git>
[bitcoin] sipa opened pull request #27122: BIP341 txdata cannot be precomputed without spent outputs (master...202302_tap_ready_needs_prevouts) https://github.com/bitcoin/bitcoin/pull/27122
<instagibbs>
as well as other rules ala bip125 rule#3
2023-02-05
<phantomcircuit>
for the bip157/158 filters there's an optimal size, since there's a single thing you're optimizing for, bandwidth, but with filters on disk it's definitely harder to choose a filter size as it's a time/disk space trade off
2023-02-01
<instagibbs>
It would mean TrimToFee step might do 2500 trims vs 100(bip125 direct conflict limit)
2023-01-27
<cbdc-core-dev>
luke-jr was asked to leave bitcoin bips editor permissions, why dont you leave it as well?
2023-01-19
<scg>
gm! why does bitcoind creates a PSBTv0 if I specify locktime ?? I can see that it set PSBT_GLOBAL_FALLBACK_LOCKTIME on psbt but kept version of psbt 0. In BIP174 I read that v0 psbts require exclusion of PSBT_GLOBAL_FALLBACK_LOCKTIME. What am I missing ?
<_aj_>
sipa: any thoughts on the bip324 shortid negotitation? having net_processing do the shortid/command mapping seems like it makes sense, and just requires a bit of tweaking of the CNetMsgMaker api so that it can choose a shortid instead of the lower level Serializer
<phantomcircuit>
sipa: personally i think it's pretty reasonable for this not to detect n-of-n multisig where we have all the keys, but i absolutely could make the filter work more like bip37 and include each data push to make that possibl
2023-01-15
<sipa>
bip158's point is being able to provide bip157 filters over the network, which must be deterministic... and once you have those, you might as well use them for rescanning
<sipa>
theStack: phantomcircuit is suggesting not using bip158 filters for rescanning, but another filter type, where instead of the deterministic bip158 per-block-salted one, a static per-host one is used.
<gribble>
https://github.com/bitcoin/bitcoin/issues/25957 | wallet: fast rescan with BIP157 block filters for descriptor wallets by theStack · Pull Request #25957 · bitcoin/bitcoin · GitHub
2023-01-13
<Murch1>
BIP47 is terrible
2023-01-11
<PaperSword>
@sipa: On a side note thanks so much for creating BIP30 did a lesson on twitter and the consequences of duplicate TXIDs was amazing to think about.
2023-01-05
<lisper29>
Ah I see, it's low probability, got it. I did see the 2^-126 probability for another section of BIP32. This section didn't mention it. And anyway its specified algorithm says that if invalid then try the next. So not being cryptographer or mathematician, I figured I must follow prescribed algorithm.
<lisper29>
they have a bug in that they'll never get past that invalid index? (pubkey.cpp CPubKey::Derive is what I assume performs the BIP32 4.3.2 validation.)
<lisper29>
I'm learning to use BIP32 derived addresses in bitcoind. BIP32 4.3.2 (pub->pub) ends by specifying that when a derivation at index i is invalid "one should proceed with the next value for i". So if the deriveaddresses RPC returns an error, I'll try the next index. But I don't see the getnewaddress RPC or the Qt "create new receiving address" button's code trying the next index for this type of failed derivation. Do
<ariard>
jamesob: iirc, descendant junk where the adversary attaches a chain of transactions with low-feerate, high-fee from a new bip143 input/ouptut pair. Under BIP125 rule 3, your replacement candidate will be rejected
<bytes1440000>
its a basic thing thats lacking and nobody likes bip47
2022-11-02
<bitcoin-git>
bitcoin/22.x 3343ec5 fanquake: doc: update version number in bips.md to v22.1
2022-11-01
<bitcoin-git>
[bitcoin] theStack opened pull request #26443: doc: mention BIP86 in doc/bips.md (master...202201-doc-add_bip86_to_bipsmd) https://github.com/bitcoin/bitcoin/pull/26443
2022-10-27
<luke-jr>
FWIW, lack of bitcoin org ownership prevented me from adding Kalle to the bips repo a while back, but I'm not sure I want that kind of access (in terms of becoming a possible target)
2022-10-26
<bitcoin-git>
[bitcoin] achow101 merged pull request #26341: test: add BIP158 false-positive element check in rpc_scanblocks.py (master...202210-test-check_for_false_positives_in_scanblocks) https://github.com/bitcoin/bitcoin/pull/26341
<bitcoin-git>
[bitcoin] achow101 merged pull request #25957: wallet: fast rescan with BIP157 block filters for descriptor wallets (master...202208-speedup_descriptor_wallet_rescan_with_block_filters) https://github.com/bitcoin/bitcoin/pull/25957
2022-10-23
<sipa>
ping was part of the original codebase, pong was added in bip31
2022-10-20
<ariard>
achow101: tbh, few contributors have already to live in a multi repo world, in the sense monitoring libsecp256k1, the bips repo, the bolts repo, maybe a lightning implem, maybe bitcoin-inquisition, sounds more a question of personal time-management
2022-10-19
<bitcoin-git>
[bitcoin] theStack opened pull request #26341: test: add BIP158 false-positive element check in rpc_scanblocks.py (master...202210-test-check_for_false_positives_in_scanblocks) https://github.com/bitcoin/bitcoin/pull/26341
2022-10-13
<bitcoin-git>
bitcoin/master e899d4c Chris Geihsler: init: limit bip30 exceptions to coinbase txs
<bitcoin-git>
bitcoin/24.x da6fba6 Andrew Chow: docs: Add 371 to bips.md
2022-10-03
<bitcoin-git>
[bitcoin] fanquake merged pull request #26231: doc: bump bips.md up-to-date version to v24.0 (master...202210-doc-update_bips_for_24x) https://github.com/bitcoin/bitcoin/pull/26231
<bitcoin-git>
bitcoin/master 25742aa fanquake: Merge bitcoin/bitcoin#26231: doc: bump bips.md up-to-date version to v24.0
<bitcoin-git>
bitcoin/master a9d20ee Sebastian Falbesoner: doc: bump bips.md up-to-date version to v24.0
2022-10-02
<bitcoin-git>
[bitcoin] theStack opened pull request #26231: doc: bump bips.md up-to-date version to v24.0 (master...202210-doc-update_bips_for_24x) https://github.com/bitcoin/bitcoin/pull/26231
2022-09-29
<sipa>
Yes, of course you are - BIP350 specifies that taproot addresses use bech32m.
2022-09-26
<bitcoin-git>
[bitcoin] glozow closed pull request #22867: test: Extend test coverage of BIP125 and document confusing/inconsistent behavior (master...test_bip125_edge_cases) https://github.com/bitcoin/bitcoin/pull/22867
2022-09-22
<jonatack>
(idem for git cloning the bips repository locally)
<amovfx>
I've seen a few videos, Ill read over the BIPS today thanks
<sipa>
amovfx: Have you read the BIPs (341 and 342 mostly)? There are more high-level explainers on various online media too. I've done one or two talks about it too.
<sipa>
the interaction with bip324 i'd say is an implementation detail; the spec doesn't care about what port it runs on, and bip324 capable listeners can accept both on the same port
<bitcoin-git>
[bitcoin] theStack opened pull request #25957: wallet: fast rescan with BIP157 block filters for descriptor wallets (master...202208-speedup_descriptor_wallet_rescan_with_block_filters) https://github.com/bitcoin/bitcoin/pull/25957
<xnf0k>
Hey just wanted to let you folks know that https://github.com/bitcoin/bips/wiki had some unrelated content. I reverted it, but maybe the page(s) should be locked since this isn't the first time it has happened.
2022-08-24
<jeremyrubin>
btw people might be interested to see that https://bipbounty.org/ is "all set up" now, as a 501c3 for setting up BIP oriented bounties. If anyone doing work that they think would benefit from having such a program set up, please be in touch.
2022-08-22
<bitcoin-git>
bitcoin/master 375ebad glozow: fixups for BIP125 doc cleanup
<bitcoin-git>
bitcoin/master fa0404d MacroFake: scripted-diff: [test] Rename BIP125_SEQUENCE_NUMBER to MAX_BIP125_RBF_SEQU...
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #25602: wallet, RPC: Default BIP125 signal to -mempoolfullrbf (master...2207-rpc-wallet-replace-🌡) https://github.com/bitcoin/bitcoin/pull/25602
2022-07-12
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #25596: scripted-diff: [test] Rename BIP125_SEQUENCE_NUMBER to MAX_BIP125_RBF_SEQUENCE (master...2207-test-scrpt-rbf-🐴) https://github.com/bitcoin/bitcoin/pull/25596
2022-07-07
<sipa>
kanzure: Yes, definitely - nothing changes there. Though lately the projects I work on are more research-oriented, like miniscript, bip324, and various other things. I plan to keep writing code and reviewing.
2022-06-30
<laanwj>
well, bips is the thing that can be argued to belong under bitcoin itself