< sipa>
kallewoof: fwiw, the powLimit in the signet PR doesn't exactly match the difficulty as specified in BIP325 (the digits after 00002adc28 should be zeroes)
2020-08-27
< sipa>
right, this is not about computing our onion address, but to convert between the bip155 encoding and onion addresses
< jonatack>
I think BIP155 addrv2 is a priority, according to vasild the next steps should be smaller and easier
< ariard>
sipa: what was llfourn main proposal of change for bip324? He didn't propose to MAC the length field, so no BIP change
< jonatack>
BIP324 v2 p2p encrypted message transport protocol: right after the last p2p meeting, jonasschnelli rebased and updated #18242 (changes only used in tests for now) and I've begun re-reviewing it along with the BIP, which has some open questions.
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< jonatack>
BIP325 signet: #18267 has been through a few more rounds of review and seems to be getting close, with recent review by fjahr, pinheadz, MarcoFalke, instagibbs, and myself
< jonatack>
BIP155 addrv2: #19628 has been receiving review from sipa, elichai, ryanofsky, kallewoof, sipsorceryand myself, and now has 4 ACKs; vasild is deferring further (minor) changes to the PR in order to preserve existing review, but there's no reason to not review it
< jonatack>
My prios were BIP155, BIP324, and BIP325 implementation PRs, and they seem to be moving forward.
< vasild>
jonatack: troygiorshev: yes, the BIP155 sendaddrv2 can come any time, but we try to do it early so that when the peer is about to advertise his own address to us, he has the option to send us addrv2 - would be important if his address is torv3 because he wouldn't be able to advertise it to us with addr(v1)
< ariard>
sdaftuar: I think that's good it was unclear between matt and I on bip339 implemn in rust-bitcoin about why 339 bumps both protocol version and wtxid-relay
< jonatack>
vasild: i think it's fine to define one's own list of important PRs to review. e.g. longer term for me would be: BIP155/addrv2, BIP324, BIPs340-342, BIP325
< dongcarl>
jonatack: do you have link to bip324 discussion?
< jonatack>
i was then asked by a few devs to consider picking up bip324 implementation
2020-08-06
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
2020-08-03
< sipa>
warren: BIP324 will replace BIP151
< warren>
jonasschnelli: hey. Curious whatever happened to BIP150 and 151. Did that end up getting rolled into a replacement BIP?
2020-07-31
< bitcoin-git>
bitcoin/master d362f19 Pieter Wuille: doc: list support for BIP 339 in doc/bips.md
2020-07-29
< sipa>
the only exceptions are (1) segwit, which introduced a p2p change along with a consensus change and (2) bip133 feefilter
2020-07-27
< vasild>
but I gather "varint" in BIPs may be used to denote what the source code calls compactsize
< vasild>
both varint and compactsize are mentioned in some BIPs
< vasild>
jonasschnelli: luke-jr: sipa: wumpus: what do you think, (s/VARINT/CompactSize/ in BIP155)?
< vasild>
Anyway, given that compact size is used in p2p and not varint, I suggest that we change the spec to say "compactsize" instead of "varint" with some clarification like "For the purposes of this section, CompactSize refers to the variable-length integer encoding used acros..." (from bip152) and also change the code to use compactsize instead of varint (the code is in
< vasild>
and "compactsize" is mentioned in 6 BIPs
< vasild>
s/8 occurrences/mentioned in 8 BIPs/
< sipa>
for BIP152 there was initially an intention to use varint, but it was changed to compactsize to simplify specification
< vasild>
Or, well, if in other specs the word "VARINT" is used to mean "compactsize", then should the BIP155 C++ source code use compactsize?
< vasild>
Ok, so neither one of varint or compactsize is defined in BIPs, but compact size is already used in other places in the p2p protocol whereas varint is not.
< vasild>
BIP155 says:
< sipa>
vasild: not in any BIPs afaik; things that existed in the protocol before the BIPs process existed as generally just taken as gospel
< achow101>
2020-06-19.log:16:10 < bsm117532> #proposedwalletmeetingtopic descriptor specification for watch-only wallets, and repeated payments without address use via BIP32 paths
< sipa>
descriptor checksums have a range of 2^40, so somewhat better than bip32 fingerprints (which are only 2^32)
< shesek>
would it make sense to invent one? this could also use a `/` separator like bip32 key origins, though a different character might be better because this doesn't have multiple levels of nesting like key origins
< sipa>
(i kind of think that using fingerprints for bip32 was a bad idea too... they're too small to guarantee no collisions)
< shesek>
is there a customary notation for referring to the nth script of a descriptor identified by its checksum, akin to <bip32-fingerprint>/<index>?
2020-06-19
< bsm117532>
#proposedwalletmeetingtopic descriptor specification for watch-only wallets, and repeated payments without address use via BIP32 paths
2020-06-16
< wumpus>
but all new repositories are created under bitcoin-core, at some point, if enough things split off from the main codebase, at some point maybe only the consensus code (and bips) will be left under bitcoin
2020-06-12
< jamesob>
This issue of the message handling thread being potentially blocked by indexing (BIP157/158) that jnewbery raised is disconcerting, and separating out the indexing stuff seems more or less in line with the spirit of the process separation work.
< shesek>
is there a customary notation for referring to the nth script of a descriptor identified by its checksum? something like <checksum>/<index>, akin to <bip32-fingerprint>/<index>?
< real_or_random>
we (the BIPauthors) feel it's in a good state, I think otherwise sipa wouldn't bring this up
< elichai2>
I think the big "political" question in terms of merging is if anyone believes that BIP340 doesn't have a good chance of landing in bitcoin core
< nickler>
Afaik we've addressed all comments on the BIPS on the mailing list in some form of another
< elichai2>
I'd like to review the new keypair direction but I do hope that BIP340 will actually end up in bitcoin in the end so I think it's ok to move toward merging schnorr to libsecp
< sipa>
so with the prospect of having BIP340-342 one day merged, there will need to be a time to merge BIP340 support in libsecp256k1
< sipa>
shower thought: are pcap files easy? if so, maybe it's useful post-BIP324 to permit dumping the decrypted stream in pcap format
< MarcoFalke>
For logging, one could disable bip324
< jonasschnelli>
would ne no longer fun for post BIP324 connections
< troygiorshev>
i'm personally a huge fan of BIP324 and AltNet and related, so I'
2020-06-02
< sipa>
with a million keys the bip158 filter won't help
< sipa>
phantomcircuit: i think bip158 was designed for much smaller sets of keys, yes
< achow101>
i'm gonna need to brush up on bip158 first
< phantomcircuit>
"Empirical analysis also shows that was chosen as these parameters minimize the bandwidth utilized, considering both the expected number of blocks downloaded due to false positives and the size of the filters themselves." - BIP158
< sipa>
you have to explicitly enable bip37, or whitelist the peer
< aj>
yeah, i was thinking of making it so bip35 wouldn't let you see stuff that hadn't made it into the bloom filter, but seems too complicated, esp if we think bip35 is only for trusted-ish peers
< aj>
sipa: why not do bip35 via bloom as well?
< sipa>
aj: so WDYT about relay pool 2 minutes, bloom filter per peer for last (whatever can be relayed in 2 minutes) transactions, things can be requested if they're in the bloom filter OR in mempool and older than 2 minutes OR older than the last BIP35 response; BIP35 responses don't go into the bloom filter
2020-05-29
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< sipa>
it's why we think we need an upgrade mechanism in BIP342
< jonasschnelli>
sipa: do you think it could have implications for v2/BIP342?
< jonasschnelli>
despite the – eventually – altering BIP324, I think we can finalise the implementation and hide it behind an experimental runtime parameter.
< jonasschnelli>
BIP342 is still in discussion.
< dongcarl>
jonasschnelli: I see, so after #18242, we need #14049, and then BIP324 handshake + BIP324 ECDH calc + BIP324 HKDF key deriv (last few commits from 2019/08/net_v2)?
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< jonasschnelli>
So as for BIP342, just focus on #18242
< jonasschnelli>
15206/15197 are now BIP324 irrelevant
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< dongcarl>
Hey jonasschnelli, I wanted to confirm my overall understanding of the topology of the open PRs related to BIP324. Here?s my understanding:
< dongcarl>
- #15197 + #15206 seem to be additional improvements that 1. Can be merged independently of the main line of progression, 2. Can help/simplify the implementation of BIP324. Question here: Could you give concrete examples as to how they help/simplify the implementation?
2020-05-28
< jnewbery>
both for BIP324 and altnet
< jonasschnelli>
its nice. but not necessary anymore for future transport protocols (like BIP324)
< willcl_ark>
sipa: thanks for your earlier reply re BIP30/34
< PaulTroon>
thanks sipa, the commentary from bip30 makes more sense now
< PaulTroon>
I was also trying to understand that BIP30 attack scenario, snot sure if I understand it.. a coinbase_1 with an unspent txout to A, and then create a duplicate coinbase_2 that has a txout to B ?
< sipa>
BIP30 thankfully has an exception that in that case doesn't prevent creation, because otherwise we'd need to keep track of every spent utxo forever
< sipa>
the problem that BIP30 was trying to solve is txout _overwriting_
< PaulTroon>
sipa: because BIP30 allows duplicate tx's if all outputs are spent?
< sipa>
BIP141 solved that
< PaulTroon>
A pre-BIP34 coinbase with matching signature for block height 1,983,702 (approx year 2048)
< sipa>
willcl_ark: BIP30 doesn't prevent duplicate txids; it only prevents one transaction that would overwrite an earlier one
< willcl_ark>
BIP30 appears to leave some room for re-orgs, but I can't tell if "spent" transactions (in different blocks) could still be allowed to have had identical txids
< willcl_ark>
Does BIP30 / BIP34 completely prevent there from existing two transactions with same txid, or are there still edge-cases where this can happen?
2020-05-15
< jonasschnelli>
would it make sense to support BIP39 mnemonics in descriptors?
2020-05-13
< jonasschnelli>
Dont get me wrong. I’m totally pro BIP157.
< jonatack>
jonasschnelli: the conceptual discussion is ongoing (at least for me) on bip157, but the changes in that PR didn't seem dangerous on their own after reviewing them, and reversible before the next release
< jonasschnelli>
Yes. I agree. Just it looks like there is no clear conceptual ACK on serving filters after BIP157 (don't get me wrong, I'm all for serving BIP157).
2020-05-12
< phantomcircuit>
sipa, for non-legacy wallets using the existing bip158 "basic" filter (which is the entire script) is definitely preferable
< sipa>
phantomcircuit: unless you really need support for raw multisig (which i think the wallet doesn't even support anymore), you could use the bip158 filter
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #15845: wallet: Fast rescan with BIP157 block filters (master...1904-walletFastRescan) https://github.com/bitcoin/bitcoin/pull/15845
< ariard>
luke-jr: right I'm not arguing bip157-vs-bip37 here, but more broadly on light-client model in case of forks
< jonatack>
question: if bip157 is opt-in, and a full node can soon export a descriptor wallet xpub, why would a full node turn on serving cfilters?
< * luke-jr>
still hasn't heard a use case for merging BIP157 at all, aside from harming Bitcoin
< sipa>
(not BIP157 specifically, just in general - if you ask too much of us and we get overloaded, deprioritize)
< ariard>
sipa: yes but we don't do this AFAIK? and if everyone start to deprioritizie servicing bip157 clients you do have an issue
< jonasschnelli>
Yes. The only difference to blocks serving (which seems to cause much more traffic) is that blocks served to bip157 are pure consumption while blocks served to full nodes should - ideally - be served to other peers.
< ariard>
kanzure: no my concern is assuming you have the bip157 light client paradigm, how do you make it scale ecosystem-wise
< jonasschnelli>
ariard: also, one can crosscheck the CDN filters against some p2p loaded bip157 filters
< jonatack>
fwiw, i'm running a bip157 node on mainnet with -peercfilters=1 -blockfilterindex=1 to test for the first time, and /blockfilter/basic is 4 GB
< ariard>
overall, bip157 is good for experimentation, while keeping awareness there is still unsolved issues on security and scalability
< sipa>
luke-jr: bip157 has other advantages over bloom filters, such as being able to connect to two nodes and comparing the filters, permitting a "1 of 2 nodes is trusted" security model
< luke-jr>
stratum > bloom > bip157
< ariard>
jonasschenlli: yes my concern isn't bip157 specific, I do think that's the best option available today
< ariard>
jonasschenelli: okay my point was really about LN clients, for which bip157 was designed, not an application which needs to download block over and over
< jonasschnelli>
if there is the concern that there are too many BIP157 clients,... one might want to limit the bandwidth
< sipa>
with BIP157 you do it once
< sipa>
BIP157 is certainly harder on clients
< ariard>
and almost all bip157 clietns, dont't have strong addr management countermeasures
< ariard>
on the security aspect, supporting bip157 in core encourage people to connect directly to random peers
< sipa>
(but that's still better than BIP37...)
< sipa>
BIP157 support is very cheap for the server
< ariard>
and having a better idea for which bip157 support was aimed, people using their mobile wallets with their full-nodes
< jonasschnelli>
I think BIP157 support in core is a conceptual no brainer. The question is maybe more, if it should be open to non-whitelisted peers (random peers).
< luke-jr>
BIP157 isn't just "not perfect", it's harmful/backward
< ariard>
what I was worry about, is by supporting bip157 in core, all people building such nice LN wallets
< wumpus>
#topic bip157 and light clients (ariard)
< ariard>
do people have a bit of time to talk about bip157 or more broadly light clients ?
< vasild>
wumpus: While looking at the addrv2/BIP155 wip PR #16748 I realized that in CSubNet we support netmasks that have 0-bits followed by 1-bits, e.g. /255.255.0.255.
< jonasschnelli>
I could understand why the signraw commands could refuse to work for BIP44-ish descriptor wallets (due to the hardening violation),... though for manual privkey-ckd it should work
2020-04-08
< Talkless>
jonasschnelli: alternative is just to wait until Bitcoin Qt has BIP39 support and easy HW wallet support, so I could just switch to Bitcoin Qt :)
2020-04-06
< bitcoin-git>
[bitcoin] theStack opened pull request #18544: net: limit BIP37 filter lifespan (active between 'filterload'..'filterclear') (master...20200406-net-limit_bip37_filter_lifetime) https://github.com/bitcoin/bitcoin/pull/18544
2020-04-05
< bitcoin-git>
bitcoin/master 0ed2d8e Sebastian Falbesoner: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p_filter.py
< bitcoin-git>
bitcoin/master cf21293 MarcoFalke: Merge #18515: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18515: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p_filter.py (master...20200403-test-check-for-CVE20135700-vuln-in-bip37-tests) https://github.com/bitcoin/bitcoin/pull/18515
2020-04-03
< bitcoin-git>
[bitcoin] theStack opened pull request #18515: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p_filter.py (master...20200403-test-check-for-CVE20135700-vuln-in-bip37-tests) https://github.com/bitcoin/bitcoin/pull/18515
2020-03-31
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18481: test: add BIP37 'filterclear' test to p2p_filter.py (master...20200330-test-add-BIP37-filterclear-message) https://github.com/bitcoin/bitcoin/pull/18481
< bitcoin-git>
bitcoin/master 0055922 Sebastian Falbesoner: test: add BIP37 'filterclear' test to p2p_filter.py
< bitcoin-git>
bitcoin/master d52ba21 MarcoFalke: Merge #18481: test: add BIP37 'filterclear' test to p2p_filter.py
< bitcoin-git>
[bitcoin] theStack opened pull request #18481: test: add BIP37 'filterclear' test to p2p_filter.py (master...20200330-test-add-BIP37-filterclear-message) https://github.com/bitcoin/bitcoin/pull/18481
2020-03-13
< bitcoin-git>
bitcoin/master 66c2cad Andrew Chow: Rename BIP32PubkeyProvider.m_extkey to m_root_extkey
2020-03-10
< bitcoin-git>
[bitcoin] fanquake closed pull request #13972: Remove 16 bits from versionbits signalling system (BIP320) (master...reservedbits2) https://github.com/bitcoin/bitcoin/pull/13972
2020-03-09
< bitcoin-git>
[bitcoin] DrahtBot reopened pull request #13972: Remove 16 bits from versionbits signalling system (BIP320) (master...reservedbits2) https://github.com/bitcoin/bitcoin/pull/13972
< bitcoin-git>
[bitcoin] DrahtBot closed pull request #13972: Remove 16 bits from versionbits signalling system (BIP320) (master...reservedbits2) https://github.com/bitcoin/bitcoin/pull/13972
2020-03-05
< harding>
stevenroose: what do you mean "I'm sure there's no code that detects changes in that [minfeefilter] field"? Are you familar with BIP133? The whole point of that is to allow peers to detect changes to a peer's minfeefilter and avoid relaying transactions to a peer that won't accept them.
< aj>
reserve one of the bip320 miner-roll versionbits to signal "this block will get reorged out" instead maybe?
< aj>
kallewoof: so i saw signet on hi-pri and thought it'd be fun to discuss, but i see you posted about bip322/msg signing yesterday, so could do that instead?
2020-03-03
< pingwindyktator>
Im trying to think that this code is obsolete: it only applies to blocks before BIP9, which was indeed version 2, 3, 4. Now we're interpreting nVersion differently and this code is here just to be sure we're not breaking consensus. Can anyone confirm this?
< pingwindyktator>
Im trying to understand how exactly should we interpret block nVersion. Since BIP09 the 2, 3, 4 version actually refers to top bits in nVersion. So, given nVersion == dec(1073725440) == hex(0x3fffc000) == version 3 with some softfork bits set.
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #18242: Add BIP324 encrypted p2p transport de-/serializer (only used in tests) (master...2020/03/net_v2) https://github.com/bitcoin/bitcoin/pull/18242
2020-02-28
< provoostenator>
It also keeps the xpub in the expected place for BIP44/49/84 style descriptors
2020-02-25
< vasild>
I tried to rebase achow101/sign-in-spkman on top of bitcoin/master and got a conflict not related to 17577, but due to #17264 which modified src/wallet/psbtwallet.h (git show 29a21c906 -- src/wallet/psbtwallet.h) and 18115 deleted the file. To resolve, I replayed the change on wallet.h: git rebase bitcoin/master ; git rm src/wallet/psbtwallet.h ; sed -i '' 's/bip32derivs = false/bip32derivs =
< bitcoin-git>
[bitcoin] meshcollider merged pull request #17264: rpc: set default bip32derivs to true for psbt methods (master...2019/10/bip32_derivs) https://github.com/bitcoin/bitcoin/pull/17264
< bitcoin-git>
bitcoin/master 5bad792 Sjors Provoost: [test] PSBT RPC: check that bip32_derivs are present by default
< bitcoin-git>
bitcoin/master 31c0006 Samuel Dobson: Merge #17264: rpc: set default bip32derivs to true for psbt methods
< bitcoin-git>
bitcoin/master 29a21c9 Sjors Provoost: [rpc] set default bip32derivs to true for psbt methods
< hadjiszs>
sipa: MarcoFalke: is there someone working on dandelion++ implementation as for BIP156 ? I am planning to work on top of your #13947
< bitcoin-git>
[bitcoin] fanquake closed pull request #16486: [consensus] skip bip30 checks when assumevalid is set for the block (master...2019-07-29-fassumevalid-bip34) https://github.com/bitcoin/bitcoin/pull/16486
2020-02-24
< instagibbs>
since we're adhering to BIP44/49/84(throwing this out there in case someone thinks this is a bad idea)
2020-02-20
< dongcarl>
Okay, will read BIP150
< dongcarl>
jonasschnelli: Looking at BIP324... The session ID is supposed to be provided OOB?
< provoostenator>
A PSBT without bip32 info is generally useless.
< sipa>
BIP60 argued that adding optional fields to the version message was problematic, and suggested a solution; even if that solutions wasn't adopted, that does not imply that its concern (optional fields at the end of version) does not matter
< ariard>
what the rational to update protocol version number ? #16442 adds new p2p messages, but don't bump it, at the contrary protocol version has been bumped for bip37/bip152
2020-01-04
< ekkis>
I've tried converting it to the a hex buffer and the bip32.fromSeed() seems to accept it but I'm not sure it's correct as I'm generating addresses for the wallet and none of them seem to match the one I'm shown on the app
< ekkis>
when I convert BIP39 mnemonics to seeds I get 128 hex characters but the key I got from Edge is only 65 chars
< ekkis>
usually I would take a BIP39 seed phrase and convert it to a BIP32 root but in this case I don't know what format the key is in
2019-12-12
< sipa>
there could be some best effort where we remove bip32 derivation info from finalized inputs
< sipa>
luke-jr: BIP 174 updating is filling in UTXOs/prevtxs, bip32 paths, scripts used
< sipa>
the only reason why you'd want that to be explicit is because of privacy concerns (you may not want to reveal bip32 paths you know about keys used), but the sentiment in #17264 seems to be that that needs to be solved differently anyway
2019-12-11
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #17050: tests: Add fuzzing harnesses for functions parsing scripts, numbers, JSON and HD keypaths (bip32) (master...fuzzers) https://github.com/bitcoin/bitcoin/pull/17050
< pinheadmz>
I am reading the code correctly? We always enforce bip68 sequence locks (LOCKTIME_VERIFY_SEQUENCE) in the mempool -- even on a regtest chain _before_ CSV has been activated. ?
2019-11-17
< jonasschnelli>
real_or_random, sipa: time of the BIP324 protocol upgrade idea?
< bitcoin-git>
[bitcoin] Sjors opened pull request #17264: [rpc] set default bip32derivs to true for psbt methods (master...2019/10/bip32_derivs) https://github.com/bitcoin/bitcoin/pull/17264
< bitcoin-git>
bitcoin/master 3548e4a fanquake: Remove BIP70 Support
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #17026: doc: Update bips.md for default bech32 addresses in 0.20.0 (master...1909-doc0.20Rel) https://github.com/bitcoin/bitcoin/pull/17026
< bitcoin-git>
[bitcoin] Sjors opened pull request #17023: doc: warn that ranged multi() descriptors are not BIP67 compatible (master...2019/10/doc_descriptor_bip67_warning) https://github.com/bitcoin/bitcoin/pull/17023
2019-10-01
< bitcoin-git>
[bitcoin] laanwj merged pull request #16852: gui: When BIP70 is disabled, get PaymentRequest merchant using string search (master...bip70-merchant-decode) https://github.com/bitcoin/bitcoin/pull/16852
< bitcoin-git>
bitcoin/master cd6e9b3 Wladimir J. van der Laan: Merge #16852: gui: When BIP70 is disabled, get PaymentRequest merchant usi...
< bitcoin-git>
bitcoin/master 85973bc Andrew Chow: When BIP70 is disabled, get PaymentRequest merchant using string search
< provoostenator>
I suspect the overlap of Bitcoin Core users and people who use merchants that only support BIP70 isn't massive. But I don't have numbers.
< gribble>
https://github.com/bitcoin/bitcoin/issues/16852 | gui: When BIP70 is disabled, get PaymentRequest merchant using string search by achow101 · Pull Request #16852 · bitcoin/bitcoin · GitHub
< provoostenator>
In case anyone is bored this weekend and wants to learn more a BIP70: #16852 needs a test case IMO.
< wumpus>
so, anyhow, everyone in favor of disabling BIP70 by default for 0.19?
< bitcoin-git>
[bitcoin] laanwj closed pull request #15064: [PoC] GUI: Migrate BIP70 merchant info to mapValue["to"] (master...bip70_merchant_to_to) https://github.com/bitcoin/bitcoin/pull/15064
< BlueMatt>
and mostly lets kill bip70, finally
< gribble>
https://github.com/bitcoin/bitcoin/issues/16858 | Qt: advise users not to switch wallets when opening a BIP70 URI. by jameshilliard · Pull Request #16858 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/16852 | gui: When BIP70 is disabled, get PaymentRequest merchant using string search by achow101 · Pull Request #16852 · bitcoin/bitcoin · GitHub
< wumpus>
#topic disable BIP70 support by default for 0.19 (BlueMatt)