< sipa> bip143 has examples
< stevenroose> sipa so for the bip143 sighash calculation, do I need to provide a "witness script"?


< lightlike> sdaftuar: looks like bip37 support is on per default, but will possibly be disabled if #16152 is merged
< sdaftuar> i'm not sure whether bip37 support is currently default on or off right now in our software, but we should do something more explicit for blocksonly connections in the future, i think.
< sdaftuar> because bip37 allows for transaction relay to be re-enabled later in the connection's lifetime
< sdaftuar> it's a hack -- we use a bit added to version messages when bip37 was rolled out to communicate that we don't want to enable transaction relay


< elichai2> luke-jr: that's a different thing. for taproot we need to: 1. Have an open PR. 2. Have consensus for merging. 3. have it in 0.19. 4. have BIP9 activation by miners


< bitcoin-git> [bitcoin] MarcoFalke opened pull request #16363: test: Add test for BIP30 duplicate tx (master...1907-qaBIP30) https://github.com/bitcoin/bitcoin/pull/16363
< wumpus> "BIP148 user activated activation of segwit" huuuh that's a bit late


< bitcoin-git> [bitcoin] cajunlady78 opened pull request #16356: BIP148 user activated activation of segwit (master...bip-segwit-flagday) https://github.com/bitcoin/bitcoin/pull/16356
< bitcoin-git> [bitcoin] cajunlady78 closed pull request #16356: BIP148 user activated activation of segwit (master...bip-segwit-flagday) https://github.com/bitcoin/bitcoin/pull/16356


< pinheadmz> I have a question about RBF implementation / BIP125 rules: Just seems like these two cases are redundant:


< stevenroose> Can Core already work with BIP158 filters? F.e. serve then over RPC?
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #16333: test: Set BIP34Height = 2 for regtest (master...1906-bip34H2) https://github.com/bitcoin/bitcoin/pull/16333
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #16333: test: Set BIP34Height = 2 for regtest (master...1906-bip34H2) https://github.com/bitcoin/bitcoin/pull/16333
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #16333: test: Set BIP34Height = 2 for regtest (master...1906-bip34H2) https://github.com/bitcoin/bitcoin/pull/16333


< instagibbs> cool, someone had a PR for turning on bip34 for regtest, couldn't find it


< dongcarl> Looking thru BIP62 right now... I'm wondering if "2. Non-push operations in scriptSig" and "7. Inputs ignored by scripts" were ever addressed? I'm baffled by how one would address these two, although I do know that 7's OP_CHECKMULTISIG case is addressed by BIP147


< gribble> https://github.com/bitcoin/bitcoin/issues/16060 | Bury bip9 deployments by jnewbery · Pull Request #16060 · bitcoin/bitcoin · GitHub
< nkohen> luke-jr: I changed the link to the reference implementation of GCS which was out of date - https://github.com/bitcoin/bips/pull/788
< sipa> nkohen: from BIP158:


< Chris_Stewart_5> There is this section in BIP130, which is a little unclear to me "Upon receipt of a "sendheaders" message, the node will be permitted, but not required, to announce new blocks by sending the header of the new block (along with any other blocks that a node believes a peer might need in order for the block to connect)."


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


< bitcoin-git> [bitcoin] laanwj merged pull request #14047: Add HKDF_HMAC256_L32 and method to negate a private key (master...2018/08/bip151_key_hkdf) https://github.com/bitcoin/bitcoin/pull/14047


< gmaxwell> sipa: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016918.html in this message Sjors recommends listing alternatives in the BIP, I strongly recommend against doing that-- it would be confusing due to distracting from what the BIP also does. BIPs should give rationale where they help add clarity on whats being done, but comparisons with untaken alternatives should generally


< bitcoin-git> [bitcoin] DrahtBot closed pull request #14049: Enable libsecp256k1 ecdh module, add ECDH function to CKey (master...2018/08/bip151_ecdh) https://github.com/bitcoin/bitcoin/pull/14049
< bitcoin-git> [bitcoin] DrahtBot reopened pull request #14049: Enable libsecp256k1 ecdh module, add ECDH function to CKey (master...2018/08/bip151_ecdh) https://github.com/bitcoin/bitcoin/pull/14049
< sipa> jeremyrubin: because of a stupid mistake in bip141 that makes v0 segwit with program sizes other than 20 or 32 invalid


< gmaxwell> We're removing BIP70 from bitcoin core completely, since essentially nothing uses it (except bitpay) --- we were close to removing it when they made it mandatory, then we held off, but since their implementation is hardly compatible there really isn't much reason to not remove it just for them.
< gmaxwell> Bitpay implements BIP70 incorrectly and requires their incorrect implementation (which also creates security vulnerabilities)


< luke-jr> sipa: yes, but BitPay's "BIP70" isn't actually BIP70-compatible
< sipa> luke-jr: i think bip70 is optional at compile time, but still on in release binaries (including in 0.18)
< gmaxwell> 16:14:07 < ghost43> https://github.com/spesmilo/electrum/issues/5292 "BitPay BIP70 signing x509 cert has expired. Electrum will refuse to accept it."
< gmaxwell> 16:14:07 < ghost43> https://github.com/spesmilo/electrum/issues/5292 "BitPay BIP70 signing x509 cert has expired. Electrum will refuse to accept it."


< luke-jr> (BIP9 signature is 29=1, 30=0, 31=0)
< gmaxwell> Ignoring them doesn't mean that they're magically free for asicboost use either... they're just ignored, and shouldn't be used for intentional bip9 upgrades.


< harding> filter is supposed to contain four elements: 1. the generation tx's vout0 scriptPubKey (sPK), 2. the regular tx's vin0 prevout sPK, 3. reg tx's vout0 sPK, reg tx's vout1 sPK. Does anyone know what I'm misunderstanding about BIP158? bitcoin-cli getblockfilter $( bitcoin-cli getblockhash 170 )


< echeveria> while at the tip, with bip157 enabled. restarted with actual logging.


< luke-jr> (and if it isn't, we have BIPs)
< jonasschnelli> so we need to change BIPS.md :p
< gmaxwell> The intentional and widely discussed design of BIP173 was to enable seemless use of future versions.
< luke-jr> considering BIP173, it's arguably a bug to fix in backports even ;)
< sipa> i believe this code actually predates bip173
< sipa> this is a violation of BIP173
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15845: wallet: Fast rescan with BIP157 block filters (master...1904-walletFastRescan) https://github.com/bitcoin/bitcoin/pull/15845
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #14121: Index for BIP 157 block filters (master...bip157-index) https://github.com/bitcoin/bitcoin/pull/14121


< gmaxwell> We often decide to not support bips, less often decide to remove bips.
< wumpus> BIP38 has some really goofy things, it was never really peer-reviewed just dropped out there,but I don't remember what anymore-please don't use it, though
< wumpus> it does not relate to bip38 in any way; if anything, most people involved with bitcoin dev really dislike bip38 and it's per-key encryption


< tynes> its the same fingerprint used in bip173 right?


< gwillen> and yeah, the fingerprint _is_ available and works fine (it's different from the fingerprint I thought my test key had, but I got that from bip32.org and I'm sure I was just holding it wrong.)
< bitcoin-git> bitcoin/0.18 538fef6 Pieter Wuille: Update bips.md for 0.18.0


< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15763: Update bips.md for 0.18.0 (master...201904_updatebipsmd) https://github.com/bitcoin/bitcoin/pull/15763
< bitcoin-git> bitcoin/master 65d2f5d Pieter Wuille: Update bips.md for 0.18.0
< bitcoin-git> bitcoin/master a238fcc MarcoFalke: Merge #15763: Update bips.md for 0.18.0


< bitcoin-git> [bitcoin] sipa opened pull request #15763: Update bips.md for 0.18.0 (master...201904_updatebipsmd) https://github.com/bitcoin/bitcoin/pull/15763


< gmaxwell> surplus of development resources (review, QA, design, development...), and we've also seen from the past the insecure half solutions (like BIP37) starve more secure secure approaches of resources.
< gmaxwell> achow101: still possible some broken app was using bip32 with uncompressed keys. But I agree thats a lot less likely.
< supay> i lost access to my bitcoin and scrubbed my system for any data i could find. found some bip32/44 paths. trying to import private keys into bitcoin core using importprivkey, but that isn't working. there aren't any errors either. any help?


< gmaxwell> sipa: re: https://twitter.com/Dranithix/status/1110512014000939008 you might want to point to bip152.


< bitcoin-git> [bitcoin] jonasschnelli closed pull request #14050: Add chacha20/poly1305 and chacha20poly1305_AEAD from openssh (master...2018/08/bip151_chachapoly1305) https://github.com/bitcoin/bitcoin/pull/14050
< harding> echeveria: not that I'm aware of at the moment. I was thinking about 2015-17 contention between Bitcoin Core and some of the stuff Unlimited was doing. Also XT had BIP64 support and a different protocol version.
< ghost43> to clarify, electrum used to send addresses to servers, but around the time bip173 was published, the protocol was changed to sha256(scriptPubKey), to abstract away addresses


< gmaxwell> like, if you look at bip37's other applications such as leaking lite wallet addresses, electrum does that slightly better by sending the addresses directly.
< sipa> echeveria: as opposed to bip37, which is non optimal for everything :)
< gmaxwell> large bip37 filters are very slow to evaluate in any case because there are many hash functions.
< luke-jr> if not adjusting BIP158 to BIP37, maybe some other kind of address filter that could be compatible? (it won't help BIP37 then, but might reduce CPU time implementing BIP158 searches still)
< luke-jr> could that be fixed, or would that hurt BIP158 filters somehow?
< sipa> luke-jr: to answer your question, you can't compute the intersection between a bloom filter and a bip158 filter, as they use incompatible hash functions
< luke-jr> sipa: but the current standard for this is BIP37 (and I would expect such bloom filters to be smaller than sending every address?)
< sipa> and that can definitely be optimized using bip158 filters


< gribble> https://github.com/bitcoin/bitcoin/issues/15584 | build: disable BIP70 support by default by fanquake · Pull Request #15584 · bitcoin/bitcoin · GitHub


< pierre_rochard> "I think his desire is to allow people to immediately start using LND and the LN wallet using BIP157 filters served from his node while their Bitcoin Core node syncs."
< sipa> it should be called BIP158, there is no p2p protocol support in there :)
< harding> gmaxwell: yeah, and any client that supports BIP157 must, by necessity, also support grabbing and parsing full blocks anyway, so supporting grabbing all blocks after a certain height ought to be a trivial addition.
< gmaxwell> harding: yea okay, I'd even say BIP157/158 is a pretty weak way to accomplish that particular case. ... deploying a new protocol would take a lot of time in the best case, while just fetching the blocks works now against the existing network.
< harding> I've been trying to use "BIP157" for the filters themselves and "BIP158" for the P2P parts, but it's not always that clearcut.
< gmaxwell> I'm not really aware of the twitter stuff (other than having been given that link) ... but my thought for many months is that I'm super excited about having the filters to make rescans usable again... and super concerned about them starting a new wave of bip37 like wallets that just blindly trust things.
< harding> gmaxwell: AFAIU, he just wants some way for people to start using an LN wallet in the SPV trust model while their node syncs. I'm not sure he cares how it happens. I myself don't know why BIP157/158 is entangled in this, except that he might think it's necessary to accomplish that.
< sipa> only partially related, i think there is a lot of confusion about what "bip157" means; there is (a) the spec, allowing software to implement the filters in a private protocol like wasabi does (b) support for it in bitcoin core via RPC (what the current PRs do) (c) exposing it in core and other software via P2P for trusting peers to use (d) exposing it in core via P2P for non-trusting peers (e) a
< moneyball> My understanding is that pierre_rochard is focused on onboarding new Bitcoin users via Lightning (with his Lightning Powered Users), and he would like as many of them as possible to run full nodes, but he wants them to be able to use Bitcoin immediately so wants to support BIP157 style light clients. He's also saying if Core doesn't merge support for BIP157, he'd maintain a version of Core with it merged, and run
< harding> gmaxwell: pierre_rochard maintains an installer that installs Bitcoin Core, LND, and a LN wallet that's capable of using BIP157/158. I think his desire is to allow people to immediately start using LND and the LN wallet using BIP157 filters served from his node while their Bitcoin Core node syncs. That is, I don't think he's talking about hybrid SPV in Bitcoin Core by hybrid SPV via LND/Neutrino/some other wallet.
< gmaxwell> Can someone explain this tweet people were passing around? https://twitter.com/pierre_rochard/status/1104785795523719169 I don't understand how fullblock spv mode and the BIP157 related PRs are at all compariable/substutiable for each other.
< gribble> https://github.com/bitcoin/bitcoin/issues/13134 | net: Add option `-enablebip61` to configure sending of BIP61 notifications by laanwj · Pull Request #13134 · bitcoin/bitcoin · GitHub


< dta_> bip16?


< bitcoin-git> [bitcoin] fanquake opened pull request #15584: build: disable BIP70 support by default (master...disable-bip70-by-default) https://github.com/bitcoin/bitcoin/pull/15584


< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15566: cli: replace testnet with chain and return network name as per BIP70. (master...cli-testnet-to-network) https://github.com/bitcoin/bitcoin/pull/15566
< bitcoin-git> bitcoin/master 890396c fanquake: cli: replace testnet with chain and return network name as per BIP70.


< bitcoin-git> [bitcoin] fanquake opened pull request #15566: cli: replace testnet with chain and return network name as per BIP70. (master...cli-testnet-to-network) https://github.com/bitcoin/bitcoin/pull/15566


< pinheadmz> thanks guys, going to get the team on BIP130
< sipa> bip130 is a step being headers-first sync
< sipa> and with BIP130, new blocks are also announced using headers instead of invs
< pinheadmz> looking into it now... is the deprecation of getblocks documented? I was about to start work on BIP159 (NETWORK_LIMITED) but maybe I should checkout the existing networkprotocol behavior first. bcoin does send `sendcmpct` and then `getblocks` which will retrieve compact blocks from the peer.
< gmaxwell> it would be like sticking a warning on BIP69 txn. They're a minority of transactions so in that sense they hurt the user's privacy.
< gmaxwell> bip69 also just didn't add anything in and of itself, it's not like there was a "this is much better but its inconsistent so don't do it"
< shesek> re "(esp if everyone isn't suicide packed into never improving)" - for a wallet that wants to maximize its anonymity set, it makes sense to use characteristics that are as common as possible, even if its less ideal for other reasons. for example, payjoin are intentionally trying to avoid uih-2 to enjoy a bigger anonymity set. and some of the arguments against bip69 lexicographical ordering were on a similar basis, that wallets that do


< wumpus> I... don't understand why such a high-level discussion of the desirability of those things comes now, while BIP150/151 have existed for ages
< jonasschnelli> Auth. is BIP150 which is still in discussion
< jonasschnelli> BIP151 (or the new #) is opportunistic encryption
< jonasschnelli> Also, there is a BIP150 weakness if used with plain (old) BIP151
< sipa> jonasschnelli: it looks like you plan to overwrite BIP151... given that it already has a bip number, and you're substantially changing the design, maybe it should be a separate one
< sipa> (and abandon bip151)
< jonasschnelli> Though we must discourage to use BIP151
< wumpus> #topic BIP151
< jonasschnelli> In case anyone wants to review the new v2 protocol (BIP151), including the new special ChaCha20Poly1305@bitcoin AEAD,... its here -> https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52
< wumpus> gmaxwell: I tend to agree at this point, years ago it was differnt but makes sense to prioritize BIP150/151 now


< andytoshi> i'd like to start a wiki page or github issue or something to collect a wishlist for a bip174/psbt extension BIP draft. where is the best place to do that?


< gmaxwell> mmgen: hardend bip32 is a hash derrived private key, you are spreading disinformation claiming that it has any different security properties.
< mmgen> gwillen: my concern with bip32 is that is uses ecc, which could be a problem after the advent of quantum computing
<@gwillen> FWIW I think your tool looks cool, although I am skeptical that your alternative to BIP32 is an improvement but I'd be interested to hear about the motivation behind it (but not in this channel, perhaps #bitcoin-dev would accept such a conversation)
< jonasschnelli> Which shows a tendency that something like BIP151 may speed up processing performance on ARM... especially small packets
< luke-jr> rafalcpp: this is not a BIPable topic


< jonasschnelli> The current BIP151 way is ECDH_SECRET->HKDF->k1 for AAD encryption, ECDH->HKDF->k2 for the payload encryption


< provoostenator> Although it would be safer when combined with native-descriptor wallets, because the behavior of getnewaddress doesn't jive well with BIP44/49/84 that wallets use.


< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13972: Remove 16 bits from versionbits signalling system (BIP320) (master...reservedbits2) https://github.com/bitcoin/bitcoin/pull/13972
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #13972: Remove 16 bits from versionbits signalling system (BIP320) (master...reservedbits2) https://github.com/bitcoin/bitcoin/pull/13972
< gribble> https://github.com/bitcoin/bitcoin/issues/15482 | Implement BIPXXXs new softfork rules (The Great Consensus Cleanup) by TheBlueMatt · Pull Request #15482 · bitcoin/bitcoin · GitHub


< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #15482: Implement BIPXXX's new softfork rules (The Great Consensus Cleanup) (master...2019-02-great-consensus-cleanup) https://github.com/bitcoin/bitcoin/pull/15482
< sipa> bip32 derived keys are always compressed
< sipa> but xpub serializations always uses compressed... so integrating bip32 with uncompressed keys seems hard in any case
< sipa> and bip32 only supports compressed keys, iirc
< dongcarl> For BIP32, is the identifier the Hash160 of the compressed or uncompressed serialization of the ECDSA public key?
< MarcoFalke> BIP320 could make sense to make it explicit, but that can be done for 0.19 or not at all
< wumpus> I also wonder how much it matters, it's not that BIP9 is reliable anymore for those bits
< MarcoFalke> Is there any chance that there will be a softfork deployed not via BIP9?
< provoostenator> The nUpgraded warning says "It's possible unknown rules are in effect", but that's only possible if a lower threshold or some other upgrade mechanism than BIP9 is introduced.
< provoostenator> If we change that to tracking each bit individually, then there wouuld have been no alerts expect for SegWit and BIP91.


< provoostenator> In addition I think the same or a similar dialog can be used to recover wallets. Could be loading a wallet dump file, entering some descriptors or even bip39 phrases.


< palfun> luke-jr: right, so importing "used" bip32 wallets will be slow to detect all previous usage. does that still get done automatically, do I kick that off, or do it manually?
< palfun> so for the bip32 case, you'd just feed it your first 20 addresses, see what turns up, and then proceed as appropriate
< luke-jr> you mean server-side for BIP37, right?
< sipa> bip37 is server side filtering
< sipa> bip37 allows client-side filtering (it has severe privacy concerns, and is not advised), or client-side filtering (bip157, which is still new)
< palfun> wait, but, then how do bip32 wallet clients work? they need to scan large amounts of addresses for outputs/transaction history right?
< jarthur> bitcoinEnthusias: the BIPs are designed to be readable and reviewable, and Python tends to work well for that.
< jarthur> bitcoinEnthusias: on the protocol side, sipa has been organizing a BIP for Schnorr signatures. It hasn't officially been proposed yet, and typically an implementation would follow a proposal. https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki if you want to see the current state. bitcoin-dev mailing list a fine place to discuss the proposal
< luke-jr> wumpus: BIP150/151 solve authentication when they're finally done, but I don't see any better solution for dynamic IPs and NAT traversal (when UPnP/NAT-PMP are unavailable).. at the end of the day, I'm not sure it makes sense to reinvent what already exists
< provoostenator> Agreed, the combination of PMP/UPNP and ~BIP150 seems a more precise tool for this job.
< gmaxwell> technically BIP150 (or whatever replaces it... sipa and I really need to finish that)
< wumpus> also I've always believed the way forward would be to improve the bitcoin protocol itself; BIP150/151, Dandelion, as well as lightning onion routing


< gmaxwell> jb55: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32 no, look at the table there. Visually similar characters like q/g or q/p are arranged so that their value differes only by 1 bit.


< bitcoin-git> bitcoin/master e7652d3 Andrew Chow: Add WriteHDKeypath function and move *HDKeypath to util/bip32.{h,cpp}
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15411: travis: Combine --disable-bip70 into existing job (master...Mf1902-travisBIP70) https://github.com/bitcoin/bitcoin/pull/15411
< bitcoin-git> bitcoin/master 642bd7b MarcoFalke: Merge #15411: travis: Combine --disable-bip70 into existing job
< bitcoin-git> bitcoin/master eeeee58 MarcoFalke: travis: Combine --disable-bip70 into existing job
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15411: travis: Combine --disable-bip70 into existing job (master...Mf1902-travisBIP70) https://github.com/bitcoin/bitcoin/pull/15411
< bitcoin-git> [bitcoin] jonasschnelli merged pull request #15063: GUI: If BIP70 is disabled, attempt to fall back to BIP21 parsing (master...bip70_fallback_to_bip21) https://github.com/bitcoin/bitcoin/pull/15063
< bitcoin-git> bitcoin/master 84f5315 Luke Dashjr: Travis: Add test without BIP70 (but still full wallet + tests)
< bitcoin-git> bitcoin/master 113f000 Luke Dashjr: GUI: If BIP70 is disabled, give a proper error when trying to open a payme...
< bitcoin-git> bitcoin/master 9975282 Luke Dashjr: GUI: If BIP70 is disabled, attempt to fall back to BIP21 parsing


< sipa> it's testing that pushing a script hash using the OP_PUSHDATA opcodes doesn't cause it to be detected as P2SH (because BIP16 gives the exact encoding)
< sipa> but something like bip32 is already somewhat harder to do for ed25519


< jl2012> in BIP143, out-of-bound SINGLE is treated like NONE


< stevenroose> I'm leaning towards network magic (uint32) or BIP44 coin type ids: https://github.com/satoshilabs/slips/blob/master/slip-0044.md
< stevenroose> luke-jr: people don't like BIP70, though :)


< luke-jr> stevenroose: BIP70 had chain ids as strings
< stevenroose> I could do network magic bytes, psbt prefix, BIP44 coin type id, base58check address prefix byte (f.e. fixed at p2pkh), ... Address-specific ones are probably very bad.
< stevenroose> I think magic bytes are quite solid. More available in implementations than BIP44 coin type ids, f.e..


< gmaxwell> talk of multiwallet gui makes me wonder if anyone is working on using BIP157 filters for rescan? Personally I found multiwallet not super useful, due to the need to rescan wallets that were left unloaded, and it taking 8 hours to do so...


< sipa> so you can use hardened bip32 keys as descriptor; they need access to the private key to derive, but not to otherwise use


< gribble> https://github.com/bitcoin/bitcoin/issues/15063 | GUI: If BIP70 is disabled, attempt to fall back to BIP21 parsing by luke-jr · Pull Request #15063 · bitcoin/bitcoin · GitHub


< sipa> bip16


< gmaxwell> They are but they need to be part of any BIP70 alternative that doesn't immediately broadcast txn.
< gmaxwell> At the time BIP70 was written, the only 'used' metric bitcoin core really had was "spent by the mempool"
< gmaxwell> BIP70 could have been defined that way, varrious people advocated for it.


< gmaxwell> roasbeef: their bip70 violates the spec and can't be used with bitcoin core regardless.
< roasbeef> luke-jr: orly? iirc they enforce it and there's no other way to pay them other than via bip70
< luke-jr> phantomcircuit: BitPay isn't even BIP70-compatible
< phantomcircuit> gmaxwell, as far as i know literally only bitpay uses bip70
< gmaxwell> yea, I think bip70 as an external program would be nice, except no one cares about it...
< echeveria> if this was my software I'd be putting a bounty in the bip70 payment window to see if anybody notices it. you found the secret bit! send a letter to this address and we'll mail you a prize!
< echeveria> gmaxwell: sipa: bip70 could kinda be a different binary at this point, but I don't think it's level of use justifies any sort of investment in development.
< gmaxwell> Also BIP70s implementation inherently had to be run from a wallet.
< provoostenator> BIP70 is depreacted so depending on when disaster happens, we could then just ship a new binary with OpenSSL removed.
< gmaxwell> via bip 70 though it could actually introduce vulnerabilities, though thats really a question about getting rid of bip70, not openssl.
< gmaxwell> [ignoring BIP70] Now we're just stuck issuing new binaries the next time there is some zomg panic about openssl because we statically link to it.


< jamesob> oops I'm sorry -- that jimpo PR isn't critical path for BIP157; I meant #14085
< jamesob> can I nominate jimpo's BIP157/8-related PRs that've been hanging out for a while? maybe starting with #14111?


< bitcoin-git> [bitcoin] luke-jr opened pull request #15064: [PoC] GUI: Migrate BIP70 merchant info to mapValue["to"] (master...bip70_merchant_to_to) https://github.com/bitcoin/bitcoin/pull/15064
< bitcoin-git> [bitcoin] luke-jr opened pull request #15063: GUI: If BIP70 is disabled, attempt to fall back to BIP21 parsing (master...bip70_fallback_to_bip21) https://github.com/bitcoin/bitcoin/pull/15063


< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15059: test: Add basic test for BIP34 (master...Mf1812-testBip34) https://github.com/bitcoin/bitcoin/pull/15059


< gmaxwell> Perhaps because they realized if they kept it up BIP37 was just going to end up removed and then they'd lose their toy. Who knows.
< gmaxwell> roasbeef: quite a few nodes just disable BIP37 completely (which seemed to stop the BIP37 based attacks)
< roasbeef> it's a win for full nodes at least, serving the filters is much less intensive (and also stateless) compared to serving bip37, you also can't trigger worst case matching behavior over the entire chain
< gmaxwell> One should also consider the effect of incentiving varrious kinds of trouble making. (like generally we've found that when we added vulnerablities like BIP37 attackers emerged that didn't exist previously, and then made more trouble even for people that didn't care about using BIP37)
< gmaxwell> I'm very glad, e.g. that nothing about BIP37 ended up softforked in... that protocol turned out to be a lemon in a number of ways, but it took a couple years of use to realize that.
< sipa> it's pretty trivial to do, but mucb easier to get agreement on once bip157 itself is deployed and used


< jonasschnelli> I think the initial design came from the two step BIP151 handshare where v1 protocol was required for the initial messages
< jonasschnelli> So there could be two serialization instance (legacy p2p and BIP151 p2p) where each node would hold a shared pointer to that instance?


< jnewbery> luke-jr: https://github.com/bitcoin/bips/pull/745 is ready for merge


< gmaxwell> phantomcircuit: indeed. But for that case, you'd still probably be just as well off with bip157 filters on disk, and sequential scanning those.
< sipa> provoostenator: yes, i think BIP157 may be useful for a new class of clients that may become popular
< gmaxwell> (it's worse because it takes a client more time to scan the chain than with BIP37, as it has to get quite a bit more data)
< gmaxwell> and that doesn't really have anything to do with bip158 vs bip37.
< gmaxwell> (in fact BIP158 is somewhat worse, but slightly less of a privacy disaster)
< jamesob> good point - but I guess if existing light wallets switched to bip157 it'd at least ease load on existing full nodes
< provoostenator> gmawell is that _because_ of bip158 or just because there aren't that many developers working on light (non web, non electrum) wallets? That could change over time.
< gmaxwell> jamesob: history has shown otherwise, bip158 doesn't make lite wallets fundimentally more usable than they are now. They're still massively worse than server driven wallets like electrum or web wallets.
< 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 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...
< bitcoin-git> bitcoin/master fbb643d James Hilliard: Add BIP70 deprecation warning


< 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