< 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 fe16dd8 Wladimir J. van der Laan: net: Add option `-enablebip61` to configure sending of BIP61 notifications...
< bitcoin-git>
bitcoin/master 87fe292 Wladimir J. van der Laan: doc: Mention disabling BIP61 in bips.md
< bitcoin-git>
bitcoin/master 70d3541 Wladimir J. van der Laan: Merge #13134: net: Add option `-enablebip61` to configure sending of BIP61 notifications...
< * sipa>
hopes bip174 will help
< jonasschnelli>
BIP174 is a great basepoint...
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>
bip32 hierarchical deterministic wallet
<@wumpus>
not bip44, you can find the implemented bips in doc/bips.md
< 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?
2018-03-14
< bitcoin-git>
bitcoin/master c4219ff Wladimir J. van der Laan: Merge #12625: depends: biplist 1.0.3...
< sipa>
BIP173 only specifies bc and tb, so anything else is invalid
< arubi>
bip173 lists tc1qw508d6qejxtdg4y5r3zarvary0c5xw7kg3g4ty as being invalid due to "invalid human-readable part", is it just that "tc" is not one of "bc", "tb", or "bcrt" or is there anything else to it? seems that apart from that it does encode a valid p2wpkh
< 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
< cfields>
luke-jr: there are several post-mortem BIPs
< BlueMatt>
i mean we use BIPs for things that are core-specific anyway, like getblocktemplate
< luke-jr>
BIPs are for cross-software standards, which doesn't really include implementation details
< sdaftuar>
i personally think that it's helpful to put it in a BIP, because it affects the implementation of existing BIPs
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
< sipa>
but electrum does not follow bip44 afaik
< cluelessperson>
Pretty much everything uses BIP32/44 | xpriv,xpub right?
< sipa>
bip32 yes
< cluelessperson>
gmaxwell: Another idea comes to mind. Suppose I should focus on writing up a list of reasons *why* I felt I'd want to change the wallet.dat structure. Part of it was to make it portable, modifiable, and allow users to just insert new keys at whim, from Electrum, BIP39, xpriv, xpub, WIF, mini, etc.
2017-12-20
< maaku>
I've moved some discussion regarding implementation of BIPs 98, 116, and 117 to #bitcoin-mast
< bitcoin-git>
[bitcoin] jnewbery opened pull request #11817: [tests] Change bip68-112-113-p2p to use BitcoinTestFramework (master...refactor_bip68-112-113-p2p) https://github.com/bitcoin/bitcoin/pull/11817
2017-11-23
< jonasschnelli>
The "just works" approach is very important and a reason why I try to kick BIP150/151 forward even with the fact that it's already sort of possible with stunnel, VPN, TOR
< jonasschnelli>
BIP150/151 would work towards trustworthy direct connections
< jonasschnelli>
a) you use BIP150 (or other enc/auth) via p2p and use SPV BF on your phone/remove client
< Provoostenator>
(assuming BIP150/151 for the sake of argument)
< jonasschnelli>
sipa: is that scheme: (k1+H(k2,R1))*G = k1*G+H(k2,R1)*G = R1+H(k2,R1)*G compatible with BIP32?
< gmaxwell>
jonasschnelli: the other thing is this KDF scheme. Basically, I want to address the problem that you want to enter a password protected seed on a hardware wallet and not expose the password or seed to an untrusted host... but the hardware wallet does not have enough CPU power to do a meaningful KDF (the 2000 rounds in BIP39 is basically pointless)
< jcorgan>
physical damage aside, i'm still not sure if any proper bip32 hd-wallet seed/hierarchy designs have emerged
2017-11-16
< jonasschnelli>
I'm not sure if a plain text seed dump (or BIP39) is something you want in a bank tresor
< jonasschnelli>
Somethine we (HWW company) do discuss regularly is how we can make the backup situation better.. a lot of things are involved. Bip39, sdcard, shamir's secret, notary services, etc.
< jonasschnelli>
PBKDF2 with 2048 rounds seems not ideal (BIP39)
< jonasschnelli>
gmaxwell: I'm happy to hear your bip39 successor HWW KDF idea...
< gmaxwell>
achow101: unless I'm confused (always likely) it's just a minor fixup of BIP39.
< gmaxwell>
achow101: ugg electrum itself. can't encode arbritary data, so it can't work with existing wallets. at least it's better than bip39.
< gmaxwell>
achow101: not bip39 as it's a brainwallet scheme that can't encode arbritary data, but yes.
< achow101>
gmaxwell: recovery code as in something like bip39?