<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
<DavidBakin>
the file src/test/data/bip341_wallet_vectors doesn't have that for the "scriptPubKey" tests that test the MAST so it doesn't have enough information
2022-06-02
<laanwj>
i've been looking into BIP324, and catching up with the libbitcoin kernel stuff
<laanwj>
speaking of that i've reviewed one of the BIP324 PRs today (#20962)
<sipa>
Also, spec work on BIP324 (v2 p2p transport) with dhruv and real_or_random, hopefully public soon.
<sipa>
There is some context that explains common usage, but that's not really the full description of everything one could do with these BIPs... that'd be unbounded.
<sipa>
Oh, the BIPs don't really describe the creation. They're specifying the validation rules, not construction.
<sipa>
The rules for verifying signatures in the context of taproot key path spends are specified in BIP341. The rules for verifying signatures in the context of tapscript script path spends are in BIP342.
<sipa>
BIP340 describes a digital signature scheme, it has no notion of sighash types or even anything related to Bitcoin at all.
<sipa>
@davidbakin The annex is completely different from the tapscript extension. Annex is defined in BIP341, and is a way to add extra fields to txins generically. The tapscript extension is what is added to the common sighash computation from BIP341 in BIP342 with the tapscript-specific fields.
<DavidBakin>
P.S. for the 64-byte vs 65-byte signature I also see the hash_type in src/script/interpreter.cpp@1687 but still don't know where that shows up in the BIPs
<DavidBakin>
I'm trying to understand BIPS-341 and -342 - why is the sig sometimes 64 bytes and sometimes 65 byte? I infer from BIP-341 note 21 that the 64-byte sig is with hash_type == 0 (i.e., SIGHASH_DEFAULT) and that the 65-byte sigs are for the other hash_types which are _appended_ to the sig - but where is this actually specified (besides this note 21)?
2022-05-31
<sdaftuar>
_aj_: I'm not sure I think of that bip125 issue as a bug in the code -- I think the code does what is intended, and the BIP should just be clarified
2022-05-30
<instagibbs>
does core currently have issues with computing bip125 inherited signaling? Lost track of this
<theStack>
bip324 question about handshake: in older slides (from breaking bitcoin 2019) i saw it was proposed that only odd pubkeys (i.e. starting with 0x03) are allowed, but the current BIP states only even pubkeys (i.e. starting with 0x02) are. any specific reason for this change?
<theStack>
b10c: (RE BIP324 link) That seems to be very useful, thanks! Indeed I wasn't aware that there is a dedicated webpage for BIP324
<theStack>
are there currently any alternative concepts availabe or for discussion for BIP322? i'd like to focus more on generic signing support and wonder if there's a reason why the BIP322 PR (#24058) didn't get more traction yet
<sipa>
Both are interesting actually; the context is for BIP324 it'd be good to have an idea of how much per-message CPU cost overhead has. If most of the bandwidth on the network is due to large messages, this doesn't matter as much, for example.
2022-04-10
<cornfeedhobo>
can anyone tell me if there has been any movement on getting bip300/301 enacted?
2022-04-08
<dhruv>
laanwj: #24792 brings in secp master, but BIP324 depends on secp/#979 and scp/#982 which are still pending review. The conflict is likely because the tree changes iiuc.
<laanwj>
dhruv: #24792 bumping secp256k1 probably helps with BIP324? (i see it conflicts with about every BIP324 PR but don't know if they're the same changes)
2022-04-07
<sipa>
note that BIP324's spec is undergoing some changes still... the protocol will likely not be interoperable
<laanwj>
re: #24545, would it make sense to do a public test of BIP324 at some point? i mean it's much easier to test the PR if there's some other v2 peers to talk to
2022-04-03
<bitcoin-git>
[bitcoin] stratospher opened pull request #24748: test/BIP324: functional tests for v2 P2P encryption (master...p2p-encryption-test) https://github.com/bitcoin/bitcoin/pull/24748
2022-03-23
<cocoon>
luke-jr: BIPs are not part of core. How do you explain this to whole world including laanwj who knows this exists: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018871.html. I have tried my best to share they use an implementation they like or fork but NETWORK EFFECT is a thing you cannot go against. If you every try to do
<luke-jr>
to be clear, BIPs are not part of Core. The bitcoin github org just has multiple groups and multiple projects.
2022-03-22
<bitcoin-git>
[bitcoin] fanquake closed pull request #22698: Implement RBF inherited signaling and fix getmempoolentry returned bip125-replaceable status (master...fix_bip125_inherited_signaling) https://github.com/bitcoin/bitcoin/pull/22698
2022-03-17
<achow101>
descriptors does not preclude containing bip39 mnemonics or other methods of deriving keys as KEY expressions
<achow101>
and that people would comment on BIPs when they are proposed to the mailing list before the PR is opened
<achow101>
Ideally the "don't implement yet" stage is when it's on the mailng list prior to being PR'd to bips
2022-03-10
<bitcoin-git>
bitcoin/master b7dbc83 laanwj: qt: Remove network detection based on address in BIP21
<bitcoin-git>
[gui] hebasto merged pull request #563: qt: Remove network detection based on address in BIP21 (master...2022-03-remove-autodetect-code) https://github.com/bitcoin-core/gui/pull/563
2022-03-08
<bitcoin-git>
[gui] laanwj opened pull request #563: qt: Remove network detection based on address in BIP21 (master...2022-03-remove-autodetect-code) https://github.com/bitcoin-core/gui/pull/563
2022-03-06
<michaelfolkson>
Reminder that this channel is for Bitcoin Core development discussion. There is a #bitcoin-dev channel for discussion of mailing list, BIPs etc. prayank has been told that on multiple occasions now
2022-03-02
<prayank>
With current level of privacy in Bitcoin that we are trying to keep as is without CT because SUPPLY (no clue why range proof not possible) and things used by people in real life when you expect basics like no address reuse, nobody sharing tx/address info on social media etc. and BIP 47 is bad because creating payment code with this library can kill bitcoin: https://github.com/rust-bitcoin/rust-bip47
2022-02-25
<michaelfolkson>
Spam report: Muhammad816 created _Sidebar in the BIPs repo wiki
<roasbeef>
sipa: what do you think about this PR: https://github.com/bitcoin/bips/pull/1284 ? it's that change re checksigverify I mentioned a few days ago w/ some slight modifications
<bitcoin-git>
bitcoin/master e97e3de laanwj: doc: Update bips.md for 23.x
<bitcoin-git>
bitcoin/master 03bc08e laanwj: doc: Mention missing BIP157 in bips.md
2022-02-22
<laanwj>
BIP158 is mentioned; seems they could be grouped together?
<sipa>
Heh, bips.md does not list BIP157 which we support since 0.21.0.
<sipa>
It's for bips.md, I assume.
<michaelfolkson>
darosior: The descriptor BIPs are in that BIPs doc
<darosior>
Me neither. I thought about BIP370 (PSBT v2) but that isn't merged and the newly-written descriptor BIPs but they were already implemented previously.
<laanwj>
were any new bips implemented after 22.0?
2022-02-11
<michaelfolkson>
Secondly, this is the wrong IRC channel for these discussions. We've set up #bitcoin-dev for discussion on BIPs, mailing list posts. This is not a Core development issue
<roconnor>
soo are you saying that BIP68 crossed out two versions for little reason?
<sipa>
As far as I know, BIP68 is the only consensus rule that cares about transaction versions at all.
<roconnor>
Honestly thinking about BIP68 is what prompted my question.
<roconnor>
IIRC bip68 specficially static casts to unsigned for its work.
<sipa>
If that's literally the only change you make, I think it would be a softfork (because it'd cause the BIP68 version 2 semantics to apply to formerly-negative-version transactions).
<prayank>
e against a scammer, being postive and trying to helps devs. Then maybe I understand him and still respect for technical knowledge but nothing else. Also do not forget lot of devs from this repo who are influential had emailed about some decentralization of BIP repo, nobody appeared in meeting and CEO of BIPs decided that it will stay the same (sarcasm). Nobody should wait for anyone else to approve their ideas if they want to
2022-01-22
<laanwj>
backes: yes, 70016 is the latest in use on the network, BIP338 describes 70017
2022-01-21
<jeremyrubin>
another option would be to make precomputeddata take a lambda for BIP119LazyInit
<jeremyrubin>
make the BIP119LazyInit function defined by users of the abstract base
<fanquake>
Blocked shahinfe from the /bitcoin org. Also for spamming the /bips wiki
2022-01-20
<fanquake>
Blocked 13rAXwNNnaAuCJA3z1REfJbJNMwgK4LBTC from the bitcoin/ org, as they were spamming the wiki in the bips repo
<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.
<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...
<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
<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
<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 ...