< June 2025 >
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
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 29a21c9 Sjors Provoost: [rpc] set default bip32derivs to true for psbt methods
< bitcoin-git>
bitcoin/master 31c0006 Samuel Dobson: Merge #17264: rpc: set default bip32derivs to true for psbt methods
< bitcoin-git>
bitcoin/master 5bad792 Sjors Provoost: [test] PSBT RPC: check that bip32_derivs are present by default
< 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>
when I convert BIP39 mnemonics to seeds I get 128 hex characters but the key I got from Edge is only 65 chars
< 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>
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
< 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
< BlueMatt>
and mostly lets kill bip70, finally
< 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)
< 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
< 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
< instagibbs>
feature_block failing to sync, definitely not QT/bip70 related
< bitcoin-git>
[bitcoin] jameshilliard opened pull request #16858: Qt: advise users not to switch wallets when opening a BIP70 URI. (master...bip70-message) https://github.com/bitcoin/bitcoin/pull/16858
2019-09-11
< bitcoin-git>
[bitcoin] achow101 opened 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
< luke-jr>
BlueMatt: it doesn't make sense if we're disablign BIP70 too
< achow101>
it would be preferable if we could get disable bip70 in 0.19 rather than having to wait another version to let people migrate
< achow101>
if there is something that requires bip70 to decode, could you give me a code ref to it?
< achow101>
luke-jr: huh? my point was that it isn't something stored in the wallet db that requires bip70 to decode. it's a message, and afaict, it's still shown to the user, it will just look different
< luke-jr>
achow101: if you want to argue it's technically BIP70-independent since it's not on the network, okay, but the fact is that --disable-bip70 disables that code too :/
2019-09-10
< achow101>
that's not even wallet metadata, is it? It's just a display thing, nothing bip70 specific is stored in the wallet db
< luke-jr>
BlueMatt: afaik the goal is to remove BIP70 entirely - in which case, you have to turn it on BEFORE 0.20 or whatever
< BlueMatt>
(also, doesn't have to be "lost", you just have to turn on bip70 to see it)
< provoostenator>
I would say that even a false positive BIP9 activation message suggests something is going on that the user needs to look into.
< jnewbery>
achow101: almost certainly due to burying bip9 deployments
< achow101>
anyone else seeing "Warning: unknown new rules activated (versionbit 1)" in getblockchaininfo? Were we just that unlucky with asicboost miners or did burying bip9 deployments accidentally cause this?
2019-08-19
< * luke-jr>
wonders if BIP70-protocol support should be split from BIP70-parsing support, so wallets can continue to show past payments correctly once BIP70 is removed
2019-08-18
< harding>
kakobrekla: that question (and any followups you have) may be better asked in #bitcoin. The answer is that P2WPKH uses a 20-byte hash RIPEMD(SHA256()) and P2WSH uses a 32-byte hash SHA256(). For details, see https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#P2WSH
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #16490: rpc: Report reason for 'bip125-replaceable' value (master...1907-rpcMempoolWhyReplacable) https://github.com/bitcoin/bitcoin/pull/16490
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #16490: rpc: Report reason for 'bip125-replaceable' value (master...1907-rpcMempoolWhyReplacable) https://github.com/bitcoin/bitcoin/pull/16490
2019-08-10
< roasbeef>
sipa: nice! correct that afaik bip157 and segwit are more or less a pair
< sipa>
i've only added NODE_COMPACT_FILTER in combination with NODE_WITNESS, and not combined with NODE_BLOOM (no software using BIP157 is non-segwit, or needs BIP37 filters, i think)
2019-08-08
< wumpus>
I think the BIP9 bury PR is very near merge-ready
< wumpus>
dongcarl: maybe this could be part of the https://github.com/bitcoin/bips/pull/766#issuecomment-517003833 sendaddrv2 message here to notify peers of addrv2 support (which was poroposed as alternative to the protocol version bump the BIP currently documents)
2019-08-06
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16554: test: only include and use OpenSSL where it's actually needed (BIP70) (master...test_openssl_include) https://github.com/bitcoin/bitcoin/pull/16554
< bitcoin-git>
[bitcoin] fanquake opened pull request #16554: test: only include and use OpenSSL where it's actually needed (BIP70) (master...test_openssl_include) https://github.com/bitcoin/bitcoin/pull/16554
< bitcoin-git>
bitcoin/master fa8489a MarcoFalke: test: Add test for BIP30 duplicate tx
< bitcoin-git>
bitcoin/master 62117f9 MarcoFalke: Merge #16363: test: Add test for BIP30 duplicate tx
2019-08-02
< elichai2>
sipa: arghh. Is it important that every bracket will have it's own significant meaning? because using the same bracket for taproot branches and for bip32 derivations complicates stuff a bit (nothing that can't be handled with a few conditions but still) should be maybe introduce curly brackets?
< elichai2>
Is InferDescriptor *suppose* to add this fingerprint to keys(they started as regular descriptors with private/public keys, no BIP32 stuff involved)? `pkh([1fb31c4f]03462c64aa6089c6e28536c74b6ec4a8f3eaf2f5c5c36e1ae0abf39d563eeaf11e)` (it's something i'm seeing in my descriptors_tests)
< kallewoof>
So, DrahtBot added a bunch of flags to #16440 (BIP322 PR). Not sure I agree with Build system flag, though.
2019-07-31
< phantomcircuit>
hmm i was thinking we could drop the leveldb bloomfilter if the bip30 checks aren't running but actually that makes bogus transactions sent to us much more expensive to handle
< sdaftuar>
phantomcircuit: really, assumevalid has nothing to do with the optimization -- it'd be enough to check to see if a block is an ancestor of the known-bip34-activation blockhash, and if so, skip the check. i think. but this is all so complicated that i think it's best not to risk changes here...
< sdaftuar>
Anyway this would be a simple fix to your PR — just ensure that you only skip the bip30 checks if assume valid is set and the assume valid block hash builds on the known bip34 activation block hash; that would ensure that we only skip the bip30 checks on blocks we know to be safe from this issue
< sdaftuar>
it’s important to enforce bip30 on potential “alternate” chains, because if there is a utxo “overwrite” from a duplicate transaction, then the utxo set will be potentially incorrect when reorging from that chain to some other chain (eg because you’ll have removed an entry from the utxo set that should still be there, if you’d never connected the block that overwrote the transaction in
2019-07-30
< phantomcircuit>
sdaftuar, sorry im confused i dont see how removing the bip30 check would prevent a reorg to a greater pow chain
< phantomcircuit>
the BIP30 checks are literally always cache miss down to disk unless the blocks invalid
< BlueMatt>
phantomcircuit: well you at least need to fix sdaftuar's comment on the pr, but mostly I'm highly dubious of reorg conditions around the bip30 shit
< phantomcircuit>
BlueMatt, it's 10% faster to skip the bip30 checks
< jonasschnelli>
BIP324 defines short ids (single byte command) for every message.
2019-07-29
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16490: rpc: Report reason for 'bip125-replaceable' value (master...1907-rpcMempoolWhyReplacable) https://github.com/bitcoin/bitcoin/pull/16490
< phantomcircuit>
also the TODO in the BIP30 logic while not exactly immediate should be looked into
< bitcoin-git>
[bitcoin] pstratem opened 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
< phantomcircuit>
sipa, nvm i understand how, the bip30 logic guarantees at least one utxo db access for each transaction in the block until the bip34 activation block
< phantomcircuit>
oh i see bip30
< sipa>
threre is some interaction between bip34 and the utxo logic
< harding>
phantomcircuit: BIP90 agrees that 227931 was the BIP34 activationheight.
< phantomcircuit>
sipa, i think that's the block where bip34 was activated
< kallewoof>
I am considering volunteering to help out the bitcoin/bips repository. It has 108 open PRs, dating back to 2015. Who besides Luke is maintaining that?
< stevenroose>
sipa so for the bip143 sighash calculation, do I need to provide a "witness script"?
2019-07-12
< 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
< instagibbs>
cool, someone had a PR for turning on bip34 for regtest, couldn't find it
2019-06-16
< 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
< 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] 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
2019-05-11
< 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
2019-05-07
< 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
2019-04-27
< 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)
< 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.
2019-04-21
< 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 )
2019-04-19
< echeveria>
while at the tip, with bip157 enabled. restarted with actual logging.
2019-04-18
< luke-jr>
(and if it isn't, we have BIPs)
< 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
< jonasschnelli>
so we need to change BIPS.md :p
< 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
< 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
2019-04-10
< tynes>
its the same fingerprint used in bip173 right?
2019-04-09
< 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
< 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?
< 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
2019-03-23
< 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
< 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.
< 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.
< 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.
< 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
2019-03-13
< dta_>
bip16?
2019-03-12
< 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
2019-03-11
< 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.
2019-03-09
< 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
2019-03-08
< 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
2019-03-07
< 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