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.
so are we thinking: BIP324, Submit package, MacOS packaging, TapMiniscript
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.
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.
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
Actively taking review on BIP352 and responding to feedback. Currently reworking how the outpoints are hashed.
i've added some mentions of BIP324 support (because while it's off by default, it can be enabled on mainnet)
I think non-adjusted is only relevant because BIP141 specified it
but bip173 has tighter range requirements than just the bech32 ones
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?
achow101: possibly - i'm happy to continue with bip324 stuff without 28100 so it's not a blocker
28165 is i think mostly independently-useful improvements (though inspired by the needs of bip324)
sipa: what's the next bip324 pr?
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?
hi! back online; will address feedback on bip324-related PRs next week
currently bitcoin/bitcoin, bitcoin/bips, bitcoin-core/secp256k1, bitcoin-core/gui, but will consider other repos with important comments if there are requests
Interesting; that must mean either some other people are running it with *, or are running the old bip324 branch.
@Sjors What did you set for -bip324= ?
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.
bitcoin.sipa.be runs this code, if you need a remote to connect to (-addnode=NAME -bip324=NAME should suffice).
With the last one, you can experiment with bip324 connections, though in a test-only form only (using -bip324=ip).
hm i saw bip324 PR open message on matrix but not IRC
If anyone wants to experiment with bip324 connections: ^
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.
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).
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!
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.
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.
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.
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
BIP37 (or BIP111 now...) support should really be enabled just for peers trusted not to DoS.
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.
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.
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
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.)
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