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
achow101: is it true that with descriptor wallets, there is no way to provide your own bip32 seed?
@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".
bitcoin/24.x 787affb fanquake: doc: update version in bips.md to v24.1
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.
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. :/
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.
Can someone enable cirrus CI on the bitcoin/bips repo plox?
as well as other rules ala bip125 rule#3
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
It would mean TrimToFee step might do 2500 trims vs 100(bip125 direct conflict limit)
luke-jr was asked to leave bitcoin bips editor permissions, why dont you leave it as well?
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 ?
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
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
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
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.
@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.
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.
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.)
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
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
[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
ping was part of the original codebase, pong was added in bip31
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
[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
bitcoin/master e899d4c Chris Geihsler: init: limit bip30 exceptions to coinbase txs
bitcoin/24.x da6fba6 Andrew Chow: docs: Add 371 to bips.md
[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
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.
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.
bitcoin/master 375ebad glozow: fixups for BIP125 doc cleanup
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.
well, bips is the thing that can be argued to belong under bitcoin itself
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.
BIP340 describes a digital signature scheme, it has no notion of sighash types or even anything related to Bitcoin at all.
@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.
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
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)?
_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
does core currently have issues with computing bip125 inherited signaling? Lost track of this
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?
b10c: (RE BIP324 link) That seems to be very useful, thanks! Indeed I wasn't aware that there is a dedicated webpage for BIP324
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
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.
can anyone tell me if there has been any movement on getting bip300/301 enacted?
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.
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)
note that BIP324's spec is undergoing some changes still... the protocol will likely not be interoperable
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
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
Spam report: Muhammad816 created _Sidebar in the BIPs repo wiki
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
backes: yes, 70016 is the latest in use on the network, BIP338 describes 70017
another option would be to make precomputeddata take a lambda for BIP119LazyInit
make the BIP119LazyInit function defined by users of the abstract base
Blocked shahinfe from the /bitcoin org. Also for spamming the /bips wiki
Blocked 13rAXwNNnaAuCJA3z1REfJbJNMwgK4LBTC from the bitcoin/ org, as they were spamming the wiki in the bips repo
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
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
In BIP143 the part of the signature message that depends on the number of inputs is precomputed once for the entire transaction.
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.
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
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.
prayank: That is for merged and released in Core BIPs
jeremyrubin: maybe you can add information about bip 119 and related PR in doc/bips.md in #21702
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
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
bitcoin/master 1fd49eb glozow: [doc] clarify RBF difference from BIP125
Also, admin perms on bitcoin/bitcoin doesn't require admin on bitcoin/BIPs
that the bips repository is in the same organization is somewhat questionable in any case
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
bitcoin/master c771ee8 fanquake: doc: use BIP125-replaceable
# == Test that BIP341 spending only applies to witness version 1, program length 32, no P2SH ==
3. When looking at BIP341 you confirm that for future soft fork extensibility you have p2sh(witSPKV1) is trivially true
yes, in bip341/bip342, the sighash algorithm is a function of all utxos spent by the entire transaction
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
no, because those are actually illegal per BIP141
(you should support sending to any valid BIP350 address)
i think that taproot scriptPubKeys to BIP341/BIP342 (for specific keys, scripts) would be useful, though
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
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)
bitcoin/0.21 f78570e Pieter Wuille: doc: mention bech32m/BIP350 in doc/descriptors.md
at least with the BIP340 default nonce function, k=0 will +-never be reached
bitcoin/master 7b60c02 glozow: MOVEONLY: BIP125 Rule 2 to policy/rbf
bitcoin/22.x 0640bf5 Pieter Wuille: doc: mention bech32m/BIP350 in doc/descriptors.md
I'm trying to find an example TapRoot keypath transaction in the test vectors linked from bip341. Any suggestions on how to find one?
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/0.20 2b986b3 Pieter Wuille: doc: mention bech32m/BIP350 in doc/descriptors.md