< 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.
2018-10-31
< 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.)
2018-10-27
< 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
2018-10-26
< wumpus>
also it gives future BIPs that want to use that bit something to refer to, that they can reclaim it
2018-10-25
< 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
2018-10-24
< 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 38b9850 Wladimir J. van der Laan: qt: cleanup: Move BIP70 functions together in paymentserver...
< bitcoin-git>
bitcoin/master 9dcf6c0 Wladimir J. van der Laan: build: Add --disable-bip70 configure option...
2018-10-18
< 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
2018-10-16
< 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'.
2018-10-12
< 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|^.||'
2018-10-11
< 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.
< 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.
2018-09-26
< 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
< 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
2018-09-11
< 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
< 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..
2018-09-08
< jl2012>
Jmabsd: no. An input may have witness only if it is native segwit or P2SH-segwit (see BIP141)
2018-09-06
< jonasschnelli>
And I just looked up, ... there is no "clear" standard for derivation path (BIP32 doesn't mention it specific)
2018-08-30
< 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.
2018-08-29
< jonasschnelli>
What sipa said with the disclaimer, that censorship-resistant is not the goal of BIP151
< 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>
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?
2018-08-24
< 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)
2018-08-23
< 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
2018-08-22
< 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
2018-08-11
< 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
2018-08-08
< jonasschnelli>
But we all want to see progress on BIP157...
< 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
2018-07-22
< 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
< 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)?
2018-07-18
< sipa>
can anyone still access the BIP174 PR without getting a unicorn?
< 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
< 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?
2018-06-19
< 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?
< 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?
2018-06-13
< sipa>
one is that it's not compatible with bip158 based rescanning where you must know the exact scriptPubKeys you're looking for)
< 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)?
2018-05-31
< 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
2018-05-30
< 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
2018-05-29
< 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 87fe292 Wladimir J. van der Laan: doc: Mention disabling BIP61 in bips.md
< bitcoin-git>
bitcoin/master fe16dd8 Wladimir J. van der Laan: net: Add option `-enablebip61` to configure sending of BIP61 notifications...
< 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...
2018-05-28
< 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>
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...)
< 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
2018-03-19
< 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
2018-03-16
< 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?
< 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
< 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>
Now that bech32 is supported, shouldn't the status of BIP173 be changed from 'Proposed' to 'Final'?
2018-02-26
< 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 :-)
< 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
< 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
< gmaxwell>
conman: yes, it has BIP173 support for sending; and if you request it, for recieving too.
2018-02-03
< 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 )
2018-02-02
< 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
2018-02-01
< 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
< BlueMatt>
i mean we use BIPs for things that are core-specific anyway, like getblocktemplate
< cfields>
luke-jr: there are several post-mortem BIPs
< 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
2018-01-31
< 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
2018-01-30
< 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
< 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?
< 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
2018-01-12
< 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.
2018-01-11
< 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?
< BlueMatt>
you can change the bip9 activation parameters option thinggy so they match
2018-01-05
< 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
2018-01-04
< 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?)
< provoostenator>
Or maybe the "simple IPC mechanism" wouldn't need the RPC, but it's not clear to me how this would work (other than the fallback to BIP21, but that's not enough).
< wumpus>
SPV wallets of any kind only have to sync from their birthday, so I don't see why '45 minutes to sync over bip37' unless it's an old wallet that hasn't been synced for a long time
< wumpus>
(which bip37-based, or even full block SPV approaches would suffer from)
< wumpus>
yes, exposing bip37 to random nodes was probably not the best idea
< echeveria>
I was busy making sure bip37 was disabled on my nodes, that's all.
< echeveria>
it takes like, 45 minutes to sync over bip37 now and it shreds the node you're connected to.
< luke-jr>
need BIPs 150 & 151 to do that reasonably safe
< echeveria>
damn, was chewing as missed my 'inb4 bip37'.
2017-12-27
< cluelessperson>
Pretty much everything uses BIP32/44 | xpriv,xpub right?