< sipa> luke-jr: BIP158 helps our local wallet too
< jamesob> are any of the BIP157/158 PRs on the high prio list? if not, they should be
< gmaxwell> jonasschnelli: e.g. saved the bip157 filters locally, and scan against them.
< provoostenator> jonasschnelli: BIP44 recovery can be handled once we have descriptor support for importmulti and slightly more sane behavior (or a replacement for) the keypool.
< jonasschnelli> Sadly people expect fast BIP44 recovery (incl. history). This seems to be the most prominent real-world usecase for an address index


< sipa> jamesob: i think bip157/158 are great
< jamesob> it sounds like BIP-0157/0158 would go a long way towards the scan approach which is also something I'd like to talk about at some point... is anyone aware of any outstanding concerns with these BIPs and any reason we shouldn't be pushing forward on jimpo's related PRs?


< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI (master...bip70-disable-check) https://github.com/bitcoin/bitcoin/pull/14564
< bitcoin-git> bitcoin/master 23a1fa0 MarcoFalke: Merge #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI...
< bitcoin-git> bitcoin/master 58c5cc9 James Hilliard: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI


< provoostenator> By default we ask for a standard BIP44/49/84 path



< luke-jr> [17:57:13] <gmaxwell> We could, in the future, introduce a replacement to that rpc that does it implicitly, for example. <-- breaking all compatibility with the BIPs and existing software? :/


< gmaxwell> It just sounded vaguely related to me (new distro + bip70 + crash on start)
< BlueMatt> anyway, can I just remove bip70 now? :p



< gmaxwell> sipa: which is technically a violation of BIP125.


< provoostenator> This in the case of a wallet with no private keys. Yes, the bip32 bool at the end is true


< provoostenator> BIP157 does make sense as a faster-enough alternative to an address index for the above use case.
< sipa> with bip157 it's also much less needed


< warren> sipa: "<sipa> warren: BIP150/BIP151 just need a bit of entropy at connect time" ... but connect time is an event triggered by arbitrary network connections.


< sipa> warren: BIP150/BIP151 just need a bit of entropy at connect time
< warren> sipa: Is it fast enough to supply randomness for BIP150 and BIP151 when they happen later? (I'm not sure how demanding they are.)


< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI (master...bip70-disable-check) https://github.com/bitcoin/bitcoin/pull/14564
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI (master...bip70-disable-check) https://github.com/bitcoin/bitcoin/pull/14564


< wumpus> also it gives future BIPs that want to use that bit something to refer to, that they can reclaim it


< gmaxwell> Until BIP70 is gone we're stuck with openssl regardless. we lost urgency on discontinuing using openssl as a randomness input after bitpay started requiring BIP70 to make payments.
< gribble> https://github.com/bitcoin/bitcoin/issues/14451 | Add BIP70 deprecation warning and allow building GUI without BIP70 support by jameshilliard · Pull Request #14451 · bitcoin/bitcoin · GitHub
< warren> I am encouraged that #14451 happened, deprecating BIP70 (huge attack surface, nobody uses it etc.) This means we will eventually be able to remove the openssl dependency. Except for that part.
< warren> topic proposal: Interested in opinions regarding the risk of bringing back Fortuna. Along with deprecation of BIP70, we are on the path toward eventual removal of the openssl dependency.
< bitcoin-git> [bitcoin] jameshilliard opened pull request #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI (master...bip70-disable-check) https://github.com/bitcoin/bitcoin/pull/14564


< luke-jr> not building bitcoin-qt seems a bit extreme though; might make sense to refactor configure to just change the bip70 option
< gribble> https://github.com/bitcoin/bitcoin/issues/14451 | Add BIP70 deprecation warning and allow building GUI without BIP70 support by jameshilliard · Pull Request #14451 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj closed pull request #14451: Add BIP70 deprecation warning and allow building GUI without BIP70 support (master...deprecate-bip70) https://github.com/bitcoin/bitcoin/pull/14451
< bitcoin-git> bitcoin/master fbb643d James Hilliard: Add BIP70 deprecation warning
< bitcoin-git> bitcoin/master 9dcf6c0 Wladimir J. van der Laan: build: Add --disable-bip70 configure option...
< bitcoin-git> bitcoin/master 38b9850 Wladimir J. van der Laan: qt: cleanup: Move BIP70 functions together in paymentserver...


< wumpus> hehe yes BIP42
< gmaxwell> certantly ignorance about the GUI contributes to problems in the software already... (see my above comment that there were _developers_ that though request payment was bip70).
< gmaxwell> Re "request payment" being confusing, I had an argument with multiple people _in here_ because they believed "Request Payment" was somehow BIP70. So I think it's not disputable that its confusing. :P


< achow101> kallewoof: sipa: is it possible that pruned chainstates cannot compute bip9 status?
< sipa> kallewoof: it should be implementing bip9 exactly
< kallewoof> How does bitcoin core track bip9 activation states? I have odd cases where a copied chain state will result in all bip9 soft forks turning up as "failed" rather than "activated". If I disable the timeout, they show up as 'started', but with 'possible: false'.


< Zx3Si> bipul: achieves the output you want, but my guess is it's not what you want diff -u file1 file2 | awk "NR>3" | grep -E "Header|^-|^\+" | sed -r 's|^.||'


< TD-Linux> no I don't care about bip70, I meant plain addresses
< echeveria> TD-Linux: a good rule of thumb is that literally nothing uses, or supports BIP70 other than Bitpay. it'd be nice to show addresses in that form I suppose, generally well labeled they're usable in the transaction list but only if it was a simple transaction paying it.
< provoostenator> TD-Linux: BIP70 uses BIP21 style URI's. An app that can handle bitcoin:... may or may not support BIP70, usually not.
< TD-Linux> echeveria, it pops up a text box with a bip20 uri and an address in the same box
< echeveria> TD-Linux: it honestly doesn't even show you a BIP20 URI as anything but an options.
< TD-Linux> yeah I looked in bip70 and saw bitcoin:
< sipa> TD-Linux: you mean bip20?
< TD-Linux> oh bip20
< TD-Linux> gmaxwell, it generates bip70 bitcoin: urls
< gmaxwell> it doesn't support generating BIP70 invoices.


< sipa> jonasschnelli: i need to run, but this may fix it: https://github.com/sipa/bitcoin/tree/201810_importpubkeylol (it fails a bip174 test, need to investigate)


< gmaxwell> it's important to keep in mind that BIP-158 is not private either, it basically has the level of non-privacy bip37 was claimed/intended to have but bip37 turned out a lot worse than intended for several reasons.


< andytoshi> sipa: verification and bip32 operations all care about the EC identity
< sipa> andytoshi: my view is that compressed and uncompressed are both legal inside bip174, but it's up to each signer/updater/... to choose what they support anyway; some may only support compressed keys
< sipa> it's also not all that clear in bip32... it just only talks about serialization using compressed form
< achow101> bip32 is defined for compressed keys only though, so you should only use compressed keys in the bip32 derivs


< gribble> https://github.com/bitcoin/bitcoin/issues/11622 | build: Add --disable-bip70 configure option by laanwj · Pull Request #11622 · bitcoin/bitcoin · GitHubAsset 1Asset 1


< kallewoof> jimpo: reading https://github.com/bitcoin/bips/pull/725#pullrequestreview-154741923 it looks like you're suggesting the proof of funds should be a (fakeish) transaction, and the messsage signing should not be. Am I understanding that right? If so, it seems like you could just do transaction in both cases to simplify the spec. I.e. for signing message, craft two txs with the latter spending the former and former using


< kallewoof> Johnson Lau is suggesting reserving OP_MESSAGEONLY = 0xf0 as opcode for message signing, or alternatively "OP_RETURN msgXXX". It feels wasteful to take an opcode, but feedback would be nice: https://github.com/bitcoin/bips/pull/725#issuecomment-420421058


< EucOcVrFfr2D> The expected result in that test is equal to the input, the author @achow101 wanted to make sure bitcoind doesn't 'crash' on that scenario but it silently moves on. The scenario is when we're trying to sign a PSBT input but one of the requirement fails -> https://github.com/bitcoin/bips/blame/master/bip-0174.mediawiki#L342
< wumpus> but if you really want to take on deprecating BIP70 with bitpay against you, I'll support you, but it's not something I want to take up, I don't have the motivation nor energy
< gribble> https://github.com/bitcoin/bitcoin/issues/11622 | build: Add --disable-bip70 configure option by laanwj · Pull Request #11622 · bitcoin/bitcoin · GitHub
< fanquake> warren maybe you can write us something like BIP42 for that
< sipa> Jmabsd: the "accounts" feature as imagined by bip32/bip44 is more like what we now call multiwallet
< achow101> Jmabsd: or really bip44 is bip32 with stuff added onto it. the original description of suggested derivations paths is very similar to core: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#the-default-wallet-layout
< achow101> no, bip44 uses unhardened derivation. Core uses all hardened
< kallewoof> Several people on https://github.com/bitcoin/bips/pull/725 (Generic Signed Message Format) are suggesting I use a fake tx that the prover simply signs. I'm not sure what the benefits of doing this are, though..


< jl2012> Jmabsd: no. An input may have witness only if it is native segwit or P2SH-segwit (see BIP141)


< jonasschnelli> And I just looked up, ... there is no "clear" standard for derivation path (BIP32 doesn't mention it specific)


< kanzure> topic: i am collecting topics for coredevtech tokyo; please submit topic suggestions to me, things that you would like to speak about, or things that you would prefer others to speak about, could be anything from source code things to BIPs to mailing list stuff, or complaints about twitter.


< jonasschnelli> What sipa said with the disclaimer, that censorship-resistant is not the goal of BIP151


< waxwing> sipa, what's going on here? why would someone be adding both witness and non-witness utxo fields in the same input (bip174)? https://github.com/bitcoin/bitcoin/blob/master/src/script/sign.cpp#L256-L259


< gmaxwell> BIP151 sends a 32 byte pubkey, not a 33 byte one. Right? so a test that gives a junk value to the first byte doesn't actually test any case that could be triggered by BIP151. (though it's fine to test that too) The test I'm going for is an x value not on the curve, since failing to check that is a common implementation bug in ECDH implementations.


< Chris_Stewart_5> jimpo: These test vectors seem to be a dead link https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki#appendix-c-test-vectors
< Chris_Stewart_5> BIP157 seems to have the semantics for that
< Chris_Stewart_5> Hmm, is that only BIP158 though? I don't think that BIP158 includes any p2p networking stuff
< Chris_Stewart_5> instagibbs: So that is just a refactor PR to make it easier to implement BIP157 right?
< Chris_Stewart_5> BIP157 doesn't currently have an open PR does it?


< sipa> roasbeef: BIP157 will improve things further, i assume?
< gmaxwell> I never read that stuff, it's not normative (doesn't change the meaning of the datastructures), and expirence from other BIPs suggests tha people ignore them. (see, for example BIP32)
< sipa> (like bip157)


< gmaxwell> e.g. bip32 key derrivation went unused for years.
< sipa> BIP32 derivation was in the codebase for 3 years before being used :)
< jonasschnelli> importing keys seems meh-ish for hardware-wallet. IMO the ideal use case for BIP32 pub key derivation


< MarcoFalke> you could first push the current master and then rebase the bip151 branch on that?
< MarcoFalke> hmm, might be related to some bip151 changes?
< jonasschnelli> Its all on my BIP151 branch


< jonasschnelli> I'm going to write an overhaul of BIP151 (I hope nobody complain since it initial draft has been published via the BIPS long long ago). I know Armory has a complete implementation and they may not like the fact that they need to rewrite some parts
< jonasschnelli> gmaxwell: BIP151 currently require that both peers initiate a ECDH handshake. There are two secrets (one for incomming one for outgoind encryption)
< jonasschnelli> I think the BIP151 proposed handshake requires some overhaul


< jonasschnelli> But we all want to see progress on BIP157...
< jonasschnelli> I'm implementing BIP151 message structures: https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#encrypted-messages-structure


< satwo> Hi all. BIP-141 defines 4 ways to measure the size of a transaction: weight, virtual size, base size, and total size. Bitcoin-cli decoderawtransaction returns weight, vsize ("virtual size" - obvious), and size (“total size" - not obvious). I must not be the only one to have found it nontrivial to figure out how base size, total size in BIP141 and “size” in RPC are related. Even once one figures out that “BIP 141


< bitcoin-git> [bitcoin] DrahtBot reopened pull request #12676: Show "bip125-replaceable" flag, when retrieving mempool entries (master...rpc-raw-replaceable-flag) https://github.com/bitcoin/bitcoin/pull/12676


< bitcoin-git> [bitcoin] DrahtBot closed pull request #11494: Clarify BIP9 behaviour when nTimeout <= 0 (master...vb_0_timeout) https://github.com/bitcoin/bitcoin/pull/11494


< jonasschnelli> Thinking practical: assume I haven a xpub and I'd like to find funds via scantxoutset (gap limit not possible)... would it make sense to scan for all non hardened keys (assume BIP44 has been used)?


< sipa> can anyone still access the BIP174 PR without getting a unicorn?


< bitcoin-git> [bitcoin] jnewbery closed pull request #12360: Bury bip9 deployments (master...bury_bip9_deployments) https://github.com/bitcoin/bitcoin/pull/12360



< cfields> gmaxwell: as described, bip151 would require us to send the first bytes up for parsing, then have the message handler tell the net handler to deal with encryption from that point on. If encryption could be assumed, net could just handle it transparently.
< gmaxwell> that sounds silly now, but in two years when 99% of everything has BIP151 it'll be reasonable.
< echeveria> jonasschnelli: gmaxwell: cfields: personally I'd do something a little more interesting. bind a new socket, say 8383 and *only* accept encrypted connections there. older implementations explicitly avoid non-standard ports, and it gives the option to selectively only use bip151.
< jonasschnelli> (if non BIP151 supporting peer)
< gmaxwell> but we're certantly not going to make BIP151 do that. :P
< jonasschnelli> Okay. If no one else wants to work on the implementation, I will continue then with BIP151 impl.
< jonasschnelli> cfields: I think BIP151 is almost final (there is some issues with the version handshake)... the only thing that was holding me back where possible network refactors to first wait for
< jonasschnelli> I think following BIP32 for "hot" wallets with private key export options is not ideal... Electrum does that as example
< jonasschnelli> The BIP32 based derivation scheme has that security risk
< jonasschnelli> Some people think its vanilla/native BIP32... but its not... while other do native BIP32
< jonasschnelli> It came up today in a discussion: Cores BIP32 derivation scheme is not specified in a BIP
< wumpus> #topic cores BIP32 derivation "standard"
< jonasschnelli> I have a specification draft for a new seed format similar to BIP39 with some neat properties and – before sending to the ML – would appreciate feedback.
< jonasschnelli> I have two topic requests: a) Cipherseed, b) Cores BIP32 derivation "standard"



< cornfeedhobo> before i open an issue, could someone look at the french bip39 wordlist and tell me if they see the weird first byte artifact?


< achow101> no. there can be multiple bip32 derivation paths, each corresponding to a different key
< jonasschnelli> achow101: again for my clarification (sorry if I'm bothering you): using the 0x03 type (BIP32 derivation path) would mean, that each Co-Signer (in case of a multisig) would require to use the same masterkey (if we assume they have no capabilities to derive keys based on just the pubkey)?
< achow101> the pubkey is the key of the KV pair for bip32 derivation paths. so I just worded it to refer to that pubkey
< achow101> jonasschnelli: not having a bip32 derivation path entry is completely fine. The signers just need to parse the redeemscript for that input to figure out what keys are required and check whether they have them
< jonasschnelli> achow101: I was just playing an example in my head where cosigner would not share xpubs (not BIP45) since sharing the xpub is a security and privacy risk...
< jonasschnelli> Would that make sense to have a such field? or allow BIP32 keypath without fingerprint/master key reference?
< jonasschnelli> Though, we assume now, they are using BIP45 or another deterministic MS address generation scheme...
< jonasschnelli> achow101: would she just not provide the BIP32 derivation key/value?
< jonasschnelli> achow101: Can we go through the BIP 2-of-3 usecase: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#2-of-3-multisig-workflow?
< achow101> a) in the bip45 case, the path would be sufficient. but bip45 is not guaranteed
< jonasschnelli> By taking the global BIP32 keypath but not looking at the fingerprint/masterkey?
< jonasschnelli> achow101: so in multisig accoding to Bip45 or similar, this information (BIP32 derivation path) would be of no value to the signers, right?
< jonasschnelli> Regarding BIP174 (PSBT), the BIP32 derivation path is global, does that mean that each Co-Signer must use the same master key? Or is that global value per PSBT file which is per co-signer different?


< sipa> one is that it's not compatible with bip158 based rescanning where you must know the exact scriptPubKeys you're looking for)


< gribble> https://github.com/bitcoin/bitcoin/issues/11622 | build: Add --disable-bip70 configure option by laanwj · Pull Request #11622 · bitcoin/bitcoin · GitHub


< BlueMatt> oh, quick comment: if you have had ideas about things you want to fork into the protocol in the future, *please* read https://github.com/TheBlueMatt/bips/blob/betterhash/bip-XXXX.mediawiki and make sure that your ideas can be added without protocol modifications so that miners dont need firmware updates



< jonasschnelli> My core i7 can do 31’775 operations per seconds where an operation is bech32-decode->bip32-ckd->hash160->base58check
< jonasschnelli> sipa, gmaxwell: guess how long it takes to compute m/0 for possible 4 invalid chars (bech32 decode & bip32 pckd, hash160 base58check)?


< sipa> echeveria: you mean BIP34 i assume; yes, except for the first few blocks
< echeveria> sipa isn't it more than 2 now with BIP30?
<@wumpus> Chris_Stewart_5: there's no requirement on the coinbase data except for BIP34 afaik


< achow101> gmaxwell: a few people have been looking at it and have sent me comments. I have made some changes to the spec since the original was added to the bips repo


< bitcoin-git> [bitcoin] laanwj closed pull request #13134: net: Add option `-enablebip61` to configure sending of BIP61 notifications (master...2018_05_optional_bip61) https://github.com/bitcoin/bitcoin/pull/13134
< bitcoin-git> bitcoin/master fe16dd8 Wladimir J. van der Laan: net: Add option `-enablebip61` to configure sending of BIP61 notifications...
< bitcoin-git> bitcoin/master 87fe292 Wladimir J. van der Laan: doc: Mention disabling BIP61 in bips.md
< bitcoin-git> bitcoin/master 70d3541 Wladimir J. van der Laan: Merge #13134: net: Add option `-enablebip61` to configure sending of BIP61 notifications...
< * sipa> hopes bip174 will help
< jonasschnelli> BIP174 is a great basepoint...


< gmaxwell> with the BIP39 thing someone could also keep demanding your other passphrase while you protest that there isn't one.
< jonasschnelli> if you have two macs, an attacker could ask for both passphrases,.. while the current BIP39 approach, there are "infinite" possibilities
< gmaxwell> the BIP39 problem but somewhat less dumb.
< roasbeef> yes atm it's 128-bits, the current params allow everything to be encoded in 24 words, as to still be familiar w/ users of bip39
< sipa> jonasschnelli: bip173 addresses are at most 74 characters


< jonasschnelli> sipa: Do you think it makes sense to introduce a bip32 equivalent for xpriv in bech32 with seed birthday?


< sipa> BIP173 even contains an example: bc1zw508d6qejxtdg4y5r3zarvaryvg6kdaj
< sipa> because BIP173 defines an address type for future segwit versions, we need a way to parse and represent those


< wumpus> yes, or a 'bips' organization
< BlueMatt> well except bips, which will probably always stay in bitcoin


< bitcoin-git> [bitcoin] laanwj opened pull request #13134: net: Add option `-peersendreject` to configure sending of BIP61 notifications (master...2018_05_optional_bip61) https://github.com/bitcoin/bitcoin/pull/13134


< drexl> luke-jr I probably missed a lot of rules because I can't read c++ and got all my info from the bips and the wiki


< instagibbs> BIP125 constraints are the PITA I think


< sipa> the same issue came up around bip152
< bitcoin-git> [bitcoin] laanwj closed pull request #13064: List support for BIP173 in bips.md (master...201804_docbip173) https://github.com/bitcoin/bitcoin/pull/13064
< bitcoin-git> bitcoin/master 569e381 Wladimir J. van der Laan: Merge #13064: List support for BIP173 in bips.md...
< bitcoin-git> bitcoin/master 4d33039 Pieter Wuille: List support for BIP173 in bips.md


< bitcoin-git> [bitcoin] sipa opened pull request #13064: List support for BIP173 in bips.md (master...201804_docbip173) https://github.com/bitcoin/bitcoin/pull/13064


< jonasschnelli> bip151 does not protect from MITM
< sipa> yes, BIP150 can continue independently
< sipa> eh, BIP151
< jonasschnelli> If not, I can continue on BIP150
<@wumpus> it'd be good as a future successor to BIP150 - though I guess this research shouldn't discourage anyone from implementing BIP150 and having something working on more short term
< jonasschnelli> Implementing BIP151/150 is still hold back due to the network refactor, right?
< jonasschnelli> I guess this protocol would require more cryptoanalysis then the exiting BIP150
< sipa> so, as some know gmaxwell and i have been thinking about authentication protocols that have better privacy than bip150
< jonasschnelli> jnewbery: it needs BIP158 light client mode (or fullblock), fee and mempool checks. Done
< jonasschnelli> instagibbs: but not before we have BIP150/151
< jonasschnelli> I know the use-cases with 10794 are limited, but a stepping stone towards hybrid and BIP158 light validation
<@wumpus> not bip44, you can find the implemented bips in doc/bips.md
<@wumpus> bip32 hierarchical deterministic wallet
< bedotech> Hi all, currently bitcoin-core what kind of wallet derivation implement? (for example BIP44 and so on...)


< gribble> https://github.com/bitcoin/bitcoin/issues/12360 | Bury bip9 deployments by jnewbery · Pull Request #12360 · bitcoin/bitcoin · GitHub


< echeveria> bitpay uses bip70 exclusively.
< jtimon> do people use bip70 ?
< luke-jr> we don't act as BIP70 server ever though
< sipa> BIP70, technically :)
< sipa> stevenroose: bip30
< sipa> and bip34
< kallewoof> Does anyone have any objections to extending the WIF format with types, so that wallet software can know what kind of key it corresponds to (P2WPKH, P2WPKH-P2SH, etc)? BIP proposal here: https://github.com/kallewoof/bips/blob/bip-typed-wif/bip-extended-privkey.mediawiki


< bitcoin-git> bitcoin/master e80c640 John Newbery: [tests] Remove bip9-softforks.py...


< provoostenator> https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki "3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."


< wumpus> not sure if having the help conform to BIP22 or to our current implementation of it is better
< bitcoin-git> [bitcoin] jtimon closed pull request #11426: BIP90: Make buried deployments slightly more easily extensible (master...e16-bip90-extensible) https://github.com/bitcoin/bitcoin/pull/11426


< bitcoin-git> [bitcoin] laanwj closed pull request #12723: Qt5: Warning users about invalid-BIP21 URI bitcoin:// (master...qt5-uri-error-message) https://github.com/bitcoin/bitcoin/pull/12723
< bitcoin-git> bitcoin/master 310dc61 Wladimir J. van der Laan: Merge #12723: Qt5: Warning users about invalid-BIP21 URI bitcoin://...
< bitcoin-git> bitcoin/master b7fbcc5 Alexey Ivanov: Qt: Warn users about invalid-BIP21 URI bitcoin://
< gribble> https://github.com/bitcoin/bitcoin/issues/12723 | Qt5: Warning users about invalid-BIP21 URI bitcoin:// by krab · Pull Request #12723 · bitcoin/bitcoin · GitHub


< luke-jr> (presumably at some point, it would help to build the optional-BIP70 branch)
< luke-jr> cfields: FYI, I suspect there is a problem with moc stuff and clean/rebuild; even with a full `make clean` (which shouldn't be needed), I often still end up with an obsolete src/qt/moc_paymentserver.cpp when switching between code that makes BIP70 optional and not


< sipa> they are in the extended BIP118 filters though
< sipa> so they're not included in BIP37
< echeveria> sipa: bip37 also separately hashes every single script element
< bitcoin-git> [bitcoin] krab opened pull request #12723: Qt5: Warning users about invalid-BIP21 URI bitcoin:// (master...qt5-uri-error-message) https://github.com/bitcoin/bitcoin/pull/12723


< jimpo> Thx for taking a look at the BIPs
< sipa> jimpo: i just had a look at bip157/158; do you think it's really necessary that the extended filter is mandatory for the p2p protocol?


< bitcoin-git> [bitcoin] laanwj closed pull request #12625: depends: biplist 1.0.3 (master...biplist-1-0-3) https://github.com/bitcoin/bitcoin/pull/12625
< bitcoin-git> bitcoin/master c4219ff Wladimir J. van der Laan: Merge #12625: depends: biplist 1.0.3...
< bitcoin-git> bitcoin/master 4ef82f1 fanquake: depends: biplist 1.0.3


< sipa> BIP173 only specifies bc and tb, so anything else is invalid
< arubi> bip173 lists tc1qw508d6qejxtdg4y5r3zarvary0c5xw7kg3g4ty as being invalid due to "invalid human-readable part", is it just that "tc" is not one of "bc", "tb", or "bcrt" or is there anything else to it? seems that apart from that it does encode a valid p2wpkh


< bitcoin-git> [bitcoin] laanwj closed pull request #12204: Fix overly eager BIP30 bypass (master...bip30bypassfix) https://github.com/bitcoin/bitcoin/pull/12204
< bitcoin-git> bitcoin/master 3fa24bb Wladimir J. van der Laan: Merge #12204: Fix overly eager BIP30 bypass...
< bitcoin-git> bitcoin/master 5b8b387 Alex Morcos: Fix overly eager BIP30 bypass
< gribble> https://github.com/bitcoin/bitcoin/issues/12204 | Fix overly eager BIP30 bypass by morcos · Pull Request #12204 · bitcoin/bitcoin · GitHub


< bitcoin-git> [bitcoin] fanquake opened pull request #12625: depends: biplist 1.0.3 (master...biplist-1-0-3) https://github.com/bitcoin/bitcoin/pull/12625


< mmgen> From BIP141: However, a scriptPubKey with OP_0 followed by a 41-byte non-zero data push will pass, since it is not considered to be a witness program
< mmgen> https://bitcoincore.org/en/segwit_wallet_dev/ still shows BIP173 as having 'Draft' status
< mmgen> Now that bech32 is supported, shouldn't the status of BIP173 be changed from 'Proposed' to 'Final'?


< sipa> as far as i can see in the code, it just uses the exact script requested in the BIP70 payment request - regardless of what type of output it is
< sipa> tr4vis220202: are you sure the BIP70 request didn't contain a regular output?
< wumpus> both the BIP50 fork and satoshi's counting mistake :-)
< booyah> I was reading about the bitcoin db locks exploit, https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki - but I don't see there information when it was introduced exactly and "who is responsible" for it
< wumpus> and yes the forced adoption of the payment protocol by bitpay etc has been a letdown, many wallets don't have a BIP70 implementation, some don't work properly, there's problems with cloudflare and tor when fetching the requests
< sipa> ah, bip72


< jojeyh> BIP141 only says segwit prevents involuntary malleability


< bitcoin-git> bitcoin/master 23481fa MarcoFalke: Merge #12455: Fix bip68 sequence test to reflect updated rpc error message...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12455: Fix bip68 sequence test to reflect updated rpc error message (master...fix-bip68-test) https://github.com/bitcoin/bitcoin/pull/12455
< bitcoin-git> bitcoin/master e710387 Ben Woosley: test: Fix bip68 sequence test to reflect updated rpc error message...
< bitcoin-git> [bitcoin] Empact opened pull request #12455: Fix bip68 sequence test to reflect updated rpc error message (master...fix-bip68-test) https://github.com/bitcoin/bitcoin/pull/12455


< sipa> bip34


< sipa> between compatible clients, getblocks isn't used anymore as BIP152 (compact blocks) is much more efficient
< sipa> BIP152


< sipa> conman: BIP173 (https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) under "The following list gives valid segwit addresses and the scriptPubKey that they translate to in hex" gives you what you need


< jnewbery> jtimon: feature_bip9_softforks only tests CSV. it was never extended to test other bip9 deployments. It's also written using the comparison test framework, so i think it should just be removed
< gribble> https://github.com/bitcoin/bitcoin/issues/12360 | Bury bip9 deployments by jnewbery · Pull Request #12360 · bitcoin/bitcoin · GitHub
< jtimon> so jnewbery, regarding #12360, do we want to remove bip9? don't we want to reuse that code for bip8 ?
< bitcoin-git> [bitcoin] jnewbery opened pull request #12360: Bury bip9 deployments (master...bury_bip9_deployments) https://github.com/bitcoin/bitcoin/pull/12360
< gmaxwell> conman: yes, it has BIP173 support for sending; and if you request it, for recieving too.


< rhavar> I need to fully document it, but it supports some stuff that I don't think have been implemented before. Like mandatory conflict sets (for instance if you want to bip125 transactions) and the concept of optional outputs (e.g. if you're a service and have a bunch of queued withdrawals, you don't necessarily need to send them all )


< meshcollider> brb, changing my twitter name to something like [NO BIP176][MIKES]
< gmaxwell> do mention 'bc1' when talking about BIP173 addresses, since thats how users will identify them.
< wumpus> the only mention of validateaddress is in BIP173 support
< aj> yeah, it's BIP123 in src/qt/locale/* in particular.
< aj> BIP123 seems most common in the code
< wumpus> but BIP123 style seems most common
< wumpus> sometimes it says BIP 173, then BIP173, there is even a BIP-125
< wumpus> another word consistency issue (sorry) is it BIP 123 or BIP123?
< sipa> also, validateaddress has new functionality related to P2SH-P2WPKH, so that doesn't fit under BIP173 support


< gmaxwell> and then you're gonna add (hardfork) to the segwit bips and collect your cheque from Ver? :P
< luke-jr> sipa: there was discussion of how to handle Segwit-back-to-the-start type stuff, and I thought perhaps it would be better as an annex to the Segwit BIP(s) rather than an entirely new BIP (making 2 BIPs for each fork); would you be okay with that, as an author of the BIP in question?
< luke-jr> maybe we can put it in an annex for the BIPs it affects or something? just seems like it will get old to have two BIPs for every fork
< cfields> luke-jr: there are several post-mortem BIPs
< BlueMatt> i mean we use BIPs for things that are core-specific anyway, like getblocktemplate
< sdaftuar> i personally think that it's helpful to put it in a BIP, because it affects the implementation of existing BIPs
< luke-jr> BIPs are for cross-software standards, which doesn't really include implementation details


< mryandao> to deprecate bip37 bloom filter service?
< arubi> I'm using jl2012's latest bip114 client (vault branch)
< jtimon> btw, iirc libbitcoin implemented bip90 as an option despite the complains


< jtimon> was bip39 whatever-wallet-implemented-it-first-specific?
< jtimon> luke-jr: it's not core specific, everybody is welcomed to do bip90 too
< luke-jr> if we're looking at BIP90-like changes as implementation details, then it should probably go in a Core-specific doc repo rather than BIPs since it isn't a coordinated thing
< jtimon> luke-jr: of course it's good to make bip90 or sdaftuar's pr whether they're hfs, sfs or none of that. I honestly don't care if bip90 is a hf or not, it's still a good thing and should be documented in a bip. I don't think it's good to edit bips without the author's permission unless it's for typos or tiny things
< contrapumpkin> (a BIP on the need for the layer header in BIPs?)
< gmaxwell> I think I agree with that, which we also never have BIPed.
< gmaxwell> esp since bips can pretty much say whatever nonsense they want already.
< gmaxwell> luke-jr: BIP90 can't fork off nodes in any plausable situation; thats not even grey: it's not a hardfork in any meaningful sense.
< gmaxwell> luke-jr: Things aren't so black and white, most of BIP90 had been done for something like a year before the BIP was written. But it's better to communicate more instead of less.
< gmaxwell> BIP32 ... totally hardfork there.
< sdaftuar> luke-jr: it seems to me that BIP123's activation should have required agreement from the BIP-authors that it was applied to
< luke-jr> sdaftuar: I don't understand this question: https://github.com/bitcoin/bips/pull/639#issuecomment-361642505


< jtimon> sdaftuar: perhaps mention in your bip that this is similar to the way bip30 was activated ?
< Chris_Stewart_5> MarcoFalke: I was thinking about it the way that BIP9 provides process for deploying soft forks -- not a *specific* soft fork
< MarcoFalke> You can't really change BIPs retroactively
< jnewbery> 11739 would remove segwit bip9 activation
< instagibbs> i think BIPs are a good idea if we're changing consensus rules


< wumpus> there are some exceptions which have to do with specific BIPs (getblocktemplate etc)
< bitcoin-git> [bitcoin] fanquake closed pull request #10437: [WIP] Implement BIP135 (generalized versionbits) (master...bip135-core-dev-clean1) https://github.com/bitcoin/bitcoin/pull/10437


< Pritty_Kitty> Will i use the "hash" field to create my witness hash tree and put a commit in my coinbase value? Do i put this commit value AFTER the BIP34 blockheight value?


< bitcoin-git> [bitcoin] morcos opened pull request #12204: Fix overly eager BIP30 bypass (master...bip30bypassfix) https://github.com/bitcoin/bitcoin/pull/12204


< luke-jr> reckon it'd work to add the few BIP17 stuffs watch-only scripts?
< * luke-jr> ponders how to fix his wallet; IsMine isn't returning true for BIP17 stuff way back when :x


< gmaxwell> So you could just as well say that the pr12119 is "use BIP142" ... I wouldn't bother clarifying it, but the fact that there is not a 1:1 relationship between scripts and addresses is pretty important for cases like sipa points out.


< gmaxwell> There are also other address encodings for that same script, e.g. BIP142 (though hopefully no one uses them)
< jonasschnelli> 10387 is independent from the BIP159 signalling.... connecting would be nice though, but includes some risks.. so no hurry with that
< SopaXorzTaker> Why does "satoshi" appear in the BIP39 wordlist?
< sdaftuar> gmaxwell: re #11739 -- thoughts on next steps there? i was thinking i need to document the change somehow, perhaps an update to the relevant bips and an email to the -dev list?
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #12143: [Doc] Fix link for BIP-159 pull request (master...fix-bip159-link) https://github.com/bitcoin/bitcoin/pull/12143
< bitcoin-git> [bitcoin] azuchi opened pull request #12143: [Doc] Fix link for BIP-159 pull request (master...fix-bip159-link) https://github.com/bitcoin/bitcoin/pull/12143


< BlueMatt> you can change the bip9 activation parameters option thinggy so they match


< jimpo> Yeah, I'm pretty close with the drafts of the revised BIPs (I'm thinking 2 instead of 1, though it might end up just being one huge one). Need to run the changes by roasbeef.
< BlueMatt> echeveria: yea, well bip37 should be killed off entirely at this point anyway
< echeveria> BlueMatt: I'd have to check, not when I last looked. there's also like, 2 BIP37 wallets in use today.
< echeveria> luke-jr: blocksonly is pretty much a DOS on bad bip37 peers expecting unconfirmed transactions.
< BlueMatt> also, my point stands - bip37 nodes *also* receive filtered blocks, it may be that they're ok with just that
< phantomcircuit> it sets the flag in the version message which was part of the bip37 changes originally


< sdaftuar> if so i feel like next step would be for me to email the dev list and figure out a way to document this (maybe update one of the existing bips?)