< achow101> part of the spec is to include the bip32 derivation path for a pubkey as a vector of uint32's


< * luke-jr> wonders what HD wallets do for refund addresses (BIP70)
< larafale> Hello folks, can someone enlighten me on something concerning account discovery in bip 44. https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
< 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).
< provoostenator> Regarding yesterdays BIP70 proposal by James Hilliard: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015490.html Wouldn't this require some sort of permission system in the RPC?


< phantomcircuit> echeveria, he's talking about the two transactions before bip34
< echeveria> xiedeacc_: no you can’t due to bip34.


< echeveria> BIP34 specifies a soft fork that makes them unique by adding a nonce to the coinbase.
< sipa> xiedeacc: bip141, bip143, bip144
< 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'.


< cluelessperson> Pretty much everything uses BIP32/44 | xpriv,xpub right?
< sipa> bip32 yes
< sipa> but electrum does not follow bip44 afaik
< 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.


< maaku> I've moved some discussion regarding implementation of BIPs 98, 116, and 117 to #bitcoin-mast



< maaku> the implementation of BIPs 98, 116, 117 could use some review:


< bitcoin-git> [bitcoin] laanwj closed pull request #11740: Implement BIP159 NODE_NETWORK_LIMITED (pruned peers) *signaling only* (master...2017/11/NNL_signaling) https://github.com/bitcoin/bitcoin/pull/11740


< achow101> yes, bip174 would
< jonasschnelli> BIP174 would be a way? woudln't it?
< jonasschnelli> achow101: re your BIP174...
< jonasschnelli> kallewoof: re your BIP174,... I guess this also works perfectly fine for pure unsigned transaction...



< 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


< 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> BF would be okay if BIP150/151
< sipa> BIP37
< jonasschnelli> Provoostenator: I think an viable approach here is communicating over the p2p with SPV and BIP150/151


< sipa> otherwise, several implementations exist, and several BIPs describe protocol changes (but they don't fully specify it), including 14, 31, 35, 37, 61, 111, 130, 133, 144


< bitcoin-git> [bitcoin] jonasschnelli opened pull request #11740: Implement BIP159 NODE_NETWORK_LIMITED (pruned peers) *signalling only* (master...2017/11/NNL_signaling) https://github.com/bitcoin/bitcoin/pull/11740


< 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


< 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?
< bitcoin-git> [bitcoin] laanwj closed pull request #10772: Implementation of BIP8 (master...bip8-height) https://github.com/bitcoin/bitcoin/pull/10772



< gribble> https://github.com/bitcoin/bitcoin/issues/11426 | BIP90: Make buried deployments slightly more easily extensible by jtimon · Pull Request #11426 · bitcoin/bitcoin · GitHub
< sipa> and the fact that BDB was indirectly the cause for one of the largest operational problems the system has seen in years (read BIP50)


< gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
< BertrandRussell> master supports bech32/BIP173
< BertrandRussell> master supports BIP173 addresses but 0.15.1 does not (only P2SH)
< bitcoin-git> [bitcoin] sipa closed pull request #11650: BIP148 user activated activation of segwit (master...bip-segwit-flagday) https://github.com/bitcoin/bitcoin/pull/11650
< bitcoin-git> [bitcoin] emprisupriatna opened pull request #11650: BIP148 user activated activation of segwit (master...bip-segwit-flagday) https://github.com/bitcoin/bitcoin/pull/11650


< sipa> bip159 would be nice, indeed
< jonasschnelli> I'd like to see BIP159 in 0.16... but it's already in the HP list
< bitcoin-git> bitcoin/master c0b1274 John Newbery: [tests] Remove support for bre-BIP31 ping messages...


< ghost43> https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki -- "Created: 2016-03-20" I think there is a typo and it should be 2017, as the date of the first commit here is 2017-03-20 https://github.com/sipa/bech32/commit/52b5a0fa6d3174c4150393fb7d6b58d34b4f5e0b -- I can't open an issue in the BIP repo, so I figured I would just note it here. sipa luke-jr


< bitcoin-git> [bitcoin] laanwj opened pull request #11622: build: Add --disable-bip70 configure option (master...2017_11_bip70_disable) https://github.com/bitcoin/bitcoin/pull/11622
< wumpus> as preparation for (future or far future) deprecation we could add a compile option to build without BIP70 support
< name> This is the BIP70 stuff?


< bitcoin-git> [bitcoin] jtimon closed pull request #11430: Add BIP16 to consensus params for consistency (master...b16-bip90-bip16) https://github.com/bitcoin/bitcoin/pull/11430
< gmaxwell> for some context there, new electrum shipped that has 'segwit wallet support' -- which for them is BIP173 only.
< gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
< jonasschnelli> we could remove BIP70 support... *duck* (luke-jr)
< BlueMatt> we could remove the ssl-checking part of bip70
< jonasschnelli> BIP70 without openssl is non-trivial to impossible
< jtimon> is anybody using bip70?
< jonasschnelli> Only BIP70 stuff is affected though


< spudowiar> And they decided to use SIGHASH_FORKID with non-BIP143 signatures


< gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Implement BIP159, define and signal NODE_NETWORK_LIMITED (pruned peers) by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
< jtimon> it already accepts custom bip9 params


< bitcoin-git> bitcoin/0.15 50bd3f6 practicalswift: Avoid returning a BIP9Stats object with uninitialized values...


< bitcoin-git> [bitcoin] ajtowns opened pull request #11494: Clarify BIP9 behaviour when nTimeout <= 0 (master...vb_0_timeout) https://github.com/bitcoin/bitcoin/pull/11494


< sipa> jnewbery: i was starting to respond to you, but to the last point "We already have control to make a BIP9 deployment active at a certain height in regtest using -vbparams. What advantages do you see for making a deployment buried instead of just activated at a height?" -> -vbparams doesn't permit having segwit active before block 432


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


< bitcoin-git> [bitcoin] jtimon closed pull request #11427: Optimization: Remove Consensus::Params::BIP34Hash (master...e16-bip90-bip30) https://github.com/bitcoin/bitcoin/pull/11427


< gmaxwell> luke-jr: yes for HB BIP152 we don't to validation except hashing!
< gmaxwell> I think the interaction isn't too bad, for this purpose a BIP152 CB HB block is relaying you the header of its parent.
< sdaftuar> luke-jr: even with bip152 the headers need to be valid
< gmaxwell> luke-jr: the only place that happens in the protocol is HB BIP152 messages.
< jonasschnelli> tloriato: AFAIK BIP45 is the only "standard" to create multisig addresses with a set of given pubkeys.
< tloriato> Good afternoon. I was looking into BIP45, that tries to standardize the Structure for Deterministic P2SH Multisignature Wallets, but I've read the emails discussing it and seems to have a little or disagreement between the need for this particular BIP. I'm wondering if there is another standard way to generate a Deterministic Multisig Wallet? I was inclined to generate a standard Mnemonic (BIP39) and split it using Shamir


< jonasschnelli> BlueMatt: yeah. Happy to pull-in a cleanup into bip159 PR


< cfields> sipa: what do you think about a NODE_FULL (or so) flag which indicates that the node can validate the entire chain? That way (say in a year or two from now), we can require NODE_FULL, prefer NODE_NETWORK, and tolerate NODE_NETWORK_LIMITED ? I really don't like the outbound selection policy wonkyness that bip159 gives us.


< bitcoin-git> [bitcoin] laanwj closed pull request #11399: Fix bip68-sequence rpc test (master...bip68test-1) https://github.com/bitcoin/bitcoin/pull/11399
< bitcoin-git> bitcoin/master 557aba6 Wladimir J. van der Laan: Merge #11399: Fix bip68-sequence rpc test...
< bitcoin-git> bitcoin/master 49f869f Johnson Lau: Fix bip68-sequence rpc test


< jtimon> yeah, I think leaving BIP9SoftForkDesc as it is and rewritting SoftForkMajorityDesc/SoftForkDesc as it fits as you were doing looks good
< jl2012> I'm trying to combine softforks and bip9_softforks in getblockchaininfo
< jtimon> that kind of thing should pass all the tests before moving anything from bip9 to buried
< jtimon> IIRC you were unifying SoftForkMajorityDesc and SoftForkDesc and preparing it for post-bip9 buried deployments
< jl2012> So next time when we bury a bip9 softfork, we don't need to edit validation.cpp at all
< jl2012> jtimon: I'm trying to make IsSoftForkEnabled(), so all softforks, buried or bip9, could use that
< bitcoin-git> [bitcoin] jtimon opened pull request #11430: B16 bip90 bip16 (master...b16-bip90-bip16) https://github.com/bitcoin/bitcoin/pull/11430
< bitcoin-git> [bitcoin] jtimon opened pull request #11427: Optimization: Remove Consensus::Params::BIP34Hash (master...e16-bip90-bip30) https://github.com/bitcoin/bitcoin/pull/11427
< jtimon> re https://github.com/bitcoin/bitcoin/pull/11398 I wonder if we should always leave at least the last bip9/bip8 deployment there to make sure we're using the rpc part of bip9
< bitcoin-git> [bitcoin] jtimon opened pull request #11426: BIP90: Make buried deployments slightly more easily extensible (master...e16-bip90-extensible) https://github.com/bitcoin/bitcoin/pull/11426


< gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
< ThomasV> bip173 merged :)
< bitcoin-git> [bitcoin] laanwj closed pull request #11167: Full BIP173 (Bech32) support (master...201708_bech32) https://github.com/bitcoin/bitcoin/pull/11167


< gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Implement BIP159, define and signal NODE_NETWORK_LIMITED (pruned peers) by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub


< jl2012> gmaxwell: "technically we could make mainnet activate segwit at the same time as p2sh" not easy since miners included witness commitment before segwit activation. Those blocks are invalid under BIP141


< bitcoin-git> [bitcoin] jl2012 opened pull request #11399: Fix bip68-sequence rpc test (master...bip68test-1) https://github.com/bitcoin/bitcoin/pull/11399


< ThomasV> sipa: BIP124 is not really specified, but it is trivial to read
< sipa> but i don't know bip124
< ThomasV> I thought you were saying that bip124 would be broken by these opcodes
< ThomasV> or, to put it differently, what do you expect bip124 to achieve there?
< sipa> i have no idea, i have never looked at bip124
< ThomasV> but how would that interfer with bip124?
< ThomasV> sipa: what was your point about bip124 and CLTV, CSV?
< luke-jr> jonasschnelli: https://github.com/bitcoin/bips/pull/592 fix readme?
< gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
< jonasschnelli> sipa: re #11167, is it a problem that you can send to BIP173 addresses when IsWitness is diabled? "addwitnessaddress" rejects while sendtoaddress doesn't... I guess since it's active on mainnet this doesn't matter anymore?


< achow101> sipa: oh, ok. I don't see that in the BIPs though..


< ThomasV> gmaxwell: we were also considering an import format along the lines of bip124
< gmaxwell> well sipa's bip173 patch doesn't have the error finder in it.
< gmaxwell> jonasschnelli: another thing in the GUI is that we should eventually have a BIP173 error hinter. We need a monospace text entry field that can be told to underline characters or something like that.
< gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub


< meshcollider> adiabat: that's because it was given a BIP number 174 and moved filename, it's here now: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
< sipa> i expect that for bip173 it will be less time, but i'd rather ot have that delay for every softfork
< ThomasV> sipa: what do you think of bip124?
< ThomasV> well, if we had a decent bip124 we could use it for single keys too
< ThomasV> goatpig: bip124 is not really specified
< goatpig> otherwise, id fall back on Lombrozo's BIP124 and flesh that out?
< ThomasV> goatpig: I guess you know what I think of bip44
< ThomasV> goatpig: please no bip44
< goatpig> if you stick to BIP44, p2pkh is basically implied


< bitcoin-git> [bitcoin] danra opened pull request #11340: Trivial: Fix validation.cpp comment, BIP113 already deployed (master...patch-12) https://github.com/bitcoin/bitcoin/pull/11340


< tloriato> Hello! I was looking for how I could import a BIP32 Extended Key into the Bitcoin Core wallet? I've tried the RPC Documentation but got no luck there.
< gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub


< gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
< gmaxwell> (my motivator is primarily mining off blocksat, but this could eventually make a BIP152 HB mode like transmission smaller and faster too)
< BashCo> I understand Core was in a tight spot re BIP148. People said it had to come from the users, and it did. Thankfully it was a great success.
< sontol> had you kept mum about ASICBOOST and propose BIP149-like activation proposal animosity towards Bitmain won't go through the roof
< sontol> Even if that will result in something that you don't plan for (e.g BIP148)
< OdaNobunaga> I think it would be great to have a way of following core devs's discussions regarding protocol changes, like the table that listed devs' opinions regarding BIP148, 149, segwit2x etc.
< gmaxwell> Says one thing, does another-- which will drive the headline; rather than the message of the complete arc which is user empowering. It'll just be "core backs down and does BIP9 anyways".
< CodeShark> perhaps BIP9 will be used again - but for now, BIP9 feels very demoralizing to many users
< OdaNobunaga> Regarding the "will Core use BIP9 again" thing, I agree there's a huge disconnect between what the community (on slack and to a lesser extent reddit) thinks of what core will do (never do it again) vs. your idea of using BIP9 with BIP8 as fallback
< gmaxwell> Again, a direct response to BIP148 (they even said so in the announcement! :) )
< gmaxwell> For example, one of your top contributors (who sent me some very nasty remarks) told me that Bitcoin Core was _never_ going to force a segwit activation and so BIP148 was the _only_ option.
< gmaxwell> NYA was specifically created to take BIP148's success and turn it into something else.
< gmaxwell> NYA wouldn't have even existed if not for BIP149.
< CodeShark> bip8 would have allowed the nya to dominate headlines
< gmaxwell> In doing it furthered a conflicting message. BIP9 was never 'miners choose'. It's just an activiation mechenism.
< gmaxwell> CodeShark: I think people on slack echochambered themself into a corner about that. The obvious thing to do after BIP9 was BIP8, just as part of the process.
< CodeShark> I think we all agree that BIP9 for segwit caused some serious problems
< CodeShark> but if the situation changes, perhaps bip9 becomes viable again
< CodeShark> things can always change. I think the overarching goal here is to convey that users choose consensus rules, not miners. and bip9 sends conflicting messages
< gmaxwell> absolutely, but saying that we would not use BIP9 again is an error. I expect we would with an explicit stated outright plan to BIP8 after if user adoption was very strong but miners did not activate. These are technical details, sure. But unfortunately what got quoted was that BIP9 wouldn't be used again.
< CodeShark> whether we use BIP8 or BIP9 or something else isn't nearly as important - although I do think it's important that users feel empowered to resist hostile miners
< gmaxwell> CodeShark: that most of the slack people are effectively not involved in the project itself in any serious ongoing capacity, including not hanging out here. It has serious negative results, like you carrying around a we'd never use BIP9 message again, which is entirely not what I'm thinking and I doubt its what other people are thinking.


< meshcollider> morcos: by tripling, do you mean one P2PKH, one P2SH and one BIP173?


< kanzure> if a bip125-replaceable transaction's replacement does not have sufficient fee as defined by bip125, does the replacement become a valid replacement if the replacement gets a descendant that pays sufficient fee (child pays for parent)?


< meshcollider> I was only thinking about the security of importing the seed, not about bip44 itself hence my confusion
< gmaxwell> BIP44 basically violates bip32 by applying public derrivation to all cases, it should only be used in cases where export is not permitted; which is plausable for hardware wallets.
< meshcollider> as long as they support the same seed -> master key in bip32 and tree structure in bip44
< gmaxwell> meshcollider: bip39 is a bad spec, disavowed by some of its authors even. Among other issues it has no facilities for versioning, which is a critical flaw.


< jonasschnelli> with a dummy key/address generated in bip32.org or so


< kanzure> also jonasschnelli gave a talk on bip150 and bip151 the other day http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-09-04-jonas-schenlli-bip150-bip151/
< esotericnonsense> from BIP141 i interpret 'base tx size' as tx.serialize() (because it is equivalent to tx.serialize_without_witness()), and tx.serialize_with_witness() as being total transaction size BIP141


< meshcollider> Encrypted communication is proposed by jonasschnelli in BIP 151 (https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki)


< gmaxwell> Esp for BIP173; the transition can't really be done abruptly unless its seriously delayed.
< instagibbs> morcos, most are doing bip49 I think, which only is about nested
< gmaxwell> sipa: we should have specified this as part of the segwit bips then. :( but okay, it could be done.
< gmaxwell> why are we expanding scope to recieve BIP173 addresses. I think we should not make this scope expansion now.


< instagibbs> bip49, minus the bip44 part?


< instagibbs> ok, not knowledgeable enough to really dive into improvements, was having a discussion that revolved around bip125/Core design of replacement


< luke-jr> sipa: any particular reason you left off BIP 143 on https://github.com/bitcoin/bips/pull/579 ?


< bitcoin-git> [bitcoin] sipa opened pull request #11167: Full BIP173 (Bech32) support (master...201708_bech32) https://github.com/bitcoin/bitcoin/pull/11167


< sipa> not bip91
< Lightsword> luke-jr, warn about what in regards to BIP91?
< luke-jr> hm, do we still warn about BIP91?


< sipa> meshcollider: bip152 is completely unrelated
< clarkmoody> gmaxwell sipa Can you guys look at https://github.com/bitcoin/bips/pull/553 ?
< sipa> luke-jr: with BIP152, the size hardly matters, except if you're ridiculously bandwidth constraint to the point you'd be unable to keep a node synced in the first place


< rubensayshi> yea Proposed sounds like the right status for BIP173 and for people to starting deploying (wallet support for) it
< sipa> bip173 was written with many reference implementations at the time of publishing already, in the hope of not needing any significant change afterwards
< sipa> rubensayshi: oh, BIP2 has a "proposed" status
< rubensayshi> yea which BIP2 addresses to prevent that from happening once they reach Final
< sipa> rubensayshi: i think there have been too many cases of bips fundamentally changing after initial publishing
< sipa> rubensayshi: i personally have no intention of changing bip173 anymore
< rubensayshi> but lets say BIP39 (*hint hint that actually did change under my feet while it was Final, but lets not side step too much*)
< rubensayshi> hmm, when will BIP173 move from Draft to Final?


< gmaxwell> as any whitepeer would still be able to request anythign we have. (in your BIP150 world that phone would be authenticated, presumably)
< jonasschnelli> (in an ideal BIP150 world)
< sipa> so, i'd like to suggest that bip159 only defines 1 bit, corresponding to 144/288 blocks
< jonasschnelli> last updates on BIP159: threat bits independently, fingerprinting protection
<@wumpus> #topic bip159: (NODE_NETWORK_LIMITED service bits)
< sipa> do we want to discuss bip159 more?
< gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Implement BIP159, define and signal NODE_NETWORK_LIMITED (pruned peers) by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
< * jonasschnelli> puts Implement BIP159 / #10387 on the list
< praxeology> Is it just BIP143 + SIGHASH_FORKID = 0x40 ?
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10957: Avoid returning a BIP9Stats object with uninitialized values (master...bip9status) https://github.com/bitcoin/bitcoin/pull/10957
< bitcoin-git> bitcoin/master 3eb53b8 practicalswift: Avoid returning a BIP9Stats object with uninitialized values...
< bitcoin-git> bitcoin/master a46a671 MarcoFalke: Merge #10957: Avoid returning a BIP9Stats object with uninitialized values...


< bitcoin-git> [bitcoin] achow101 closed pull request #10875: BIP 91 deployment parameters (master...bip91-dep-params) https://github.com/bitcoin/bitcoin/pull/10875


< jonasschnelli> not bip37
< CodeShark> lol, BIP37 needs to eventually die
< luke-jr> I assumed jonasschnelli meant implement BIP37 client-side
< gmaxwell> yea, if we had BIP150 I wouldn't mind random extensions there even without bips. if you're only using it between trusted adjcencies the criteria is different.
< wumpus> if not you'd have to wait for BIP150 (authentication)
< wumpus> then again BIP37 works now, that's a point, step-by-step evolution usually means that things keep moving instead of being blocked by big moves
< jonasschnelli> I guess there are still usecases for BIP37 once BIP150 is life (trusted peers)
< wumpus> if only to be able to refer to it in bips.md and such
< jonasschnelli> CodeShark: why would it get deprecated (you mean dep. bip37 in favor of client side filtering)?
< gmaxwell> (not due to it itself, but due to increasing the scope of BIP37)
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10532: -bip148 option (master...bip148) https://github.com/bitcoin/bitcoin/pull/10532
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10442: add a -bip148 option (master...master) https://github.com/bitcoin/bitcoin/pull/10442
< jonasschnelli> BIP151 encryption question: the current definition says, that encryption negotiation has to be done before the version handshake (I guess it makes sense to have the enc.negotiation first). But how should a peer know if the other peer supports BIP151. Try and reconnect? Service bit fetch-able via relay, seeds (meh!)?
< venzen> My bad for not comprehending this sooner - I was somehow understanding "effective" block size limit increase from BIP141 and related explanations


< bitcoin-git> [bitcoin] achow101 closed pull request #10900: [0.14] Enforce segsignal activation height and rules (0.14...early-uasf-bip91) https://github.com/bitcoin/bitcoin/pull/10900
< bitcoin-git> [bitcoin] jameshilliard closed pull request #10444: Implement BIP91 Reduced threshold Segwit MASF (0.14...segsignal-v0.14.1) https://github.com/bitcoin/bitcoin/pull/10444
< kallewoof> sipa: since it kind of overlapped with BIP154 (anti-DoS via POW) I am interested in the work in replacing the misbehaving stuff with how useful a node has been that you mentioned before. Is there any work being done on this currently?
< kallewoof> Will re-read BIPs though, while at it.
< sipa> it's similar to BIP37's MSG_FILTERED_BLOCK btw


< bitcoin-git> bitcoin/master d4f0d87 Suhas Daftuar: [qa] Rewrite BIP65 functional tests...
< bitcoin-git> bitcoin/master 4ccc12a Suhas Daftuar: [qa] Rewrite BIP66 functional tests...
< bitcoin-git> bitcoin/master 929fd72 MarcoFalke: Merge #10695: [qa] Rewrite BIP65/BIP66 functional tests...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10695: [qa] Rewrite BIP65/BIP66 functional tests (master...2017-06-fix-bip65-test) https://github.com/bitcoin/bitcoin/pull/10695
< gribble> https://github.com/bitcoin/bitcoin/issues/10695 | [qa] Rewrite BIP65/BIP66 functional tests by sdaftuar · Pull Request #10695 · bitcoin/bitcoin · GitHub


< jonasschnelli> Anyone willing to review NODE_NETWORK_LIMITED BIP before opening a PR? https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT


< gmaxwell> we might end up inadvertantly rescuing them with a more rapid adoption of BIP173 though then there is the same idiocy that may happen four months from now. :( and maybe we should hold back posting the BIP173 integration from core so that it's distinct from the next of these dumb forks.


< gmaxwell> It also suggests that BIP173 support's test plan should include testing it with other witness version numbers. :)
< sipa> so, bip173 specifies how to translate address strings to witness version/program, and defers to bip141 for encoding that to scriptPubKeys
< wumpus> #topic bip173 unit tests issue
< sipa> short topic: bip173 unit tests issue
< sipa> BlueMatt: bip32? :p
< wumpus> do we need any updates to bips.md for 0.15?



< luke-jr> where are we at with a 0.14.3 with BIP148? I'm going to miss next meeting most likely again :/


< bitcoin-git> [bitcoin] practicalswift opened pull request #10957: Do not return a BIP9Stats object with uninitialized values (master...bip9status) https://github.com/bitcoin/bitcoin/pull/10957
< gmaxwell> intcat: sure, in the specs, that one is in BIP 144 https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki


< sipa> the fix for #10924 is easy: we need to add P2WSH/P2WPKH to CTxDestination, which is needed anyway for bip173 support
< gmaxwell> BIP173 is worse becuase it's just not implemented at all... I wouldn't even suggest it except for the nice property of being able to say "any segwit version can send to BC addresses".
< jtimon> so what about 0.15.1 -> segwit wallet, 0.15.2 - > send to bip173, optionally receive ?
< wumpus> creating bip173 receiving addresses should be optional, to not confuse too much, especially as long as vrutally no other wallets have support for it
< gmaxwell> jonasschnelli: BIP173 is native segwit, we have tests for native segwit... what BIP173 adds is just an address encoding for it, so that it can be made user accessible.
< gmaxwell> jonasschnelli: we can recieve BIP173 payments with some hidden options. (I believe the code is still there-- we have tests for that already)
< wumpus> sending obvs is optional in itself, you don't *need* tos send to BIP173 addresses, and if you do you know what you're doing. I mean about receiving.
< jonasschnelli> BIP173 sending only is kinda hard(er) to test without the rec. part
< gmaxwell> So there are two things I think are potential for scope, SW wallet (getnewaddress returns p2sh embedded SW), and BIP173 sending. We don't have to do them at the same time but it would be nice to be able to say that any SW enabled wallet can send to 173 style addresses.
< gmaxwell> There are two questions: segwit wallet, and sending to BIP173. I consider the second less important, it's also more work (because it isn't already dormant in the codebase).
< gmaxwell> BlueMatt: if we do BIP173 support it would just be sending to.
< gmaxwell> to BIP173 style addresses. Maybe we could consider short cycling 0.16


< morcos> My general view is that the more we think the miners are going to properly enforce BIP91, the more we want to make a patch/release that does so
< praxeology> BIP91 rules are not/never were my rules. I only heard about it yesterday when I was checking up on BIP 148 status
< btcdrak> I agree this situation is ideal. If BIP91 had the same activation date as BIP148 it could have piggypacked and there would be significant node enforcement. But in 24 hours, I dont see how we can make this better at all. Asking exchanges et al to run a quick untested patch (by Core's standards) for what doesnt seem like an emergency (at least to me), seems irresponsible.
< btcdrak> I've asked several pools and based on what they say at least, much more than 51% of the hashrate is running BIP91 enforcement code either btc1 or segsignal. They understand they must enforce the rule.
< luke-jr> too many people disagree with the adjusted-BIP148 it seems, to reduce to a binary choice there
< luke-jr> at least if it's simply BIP148 or non-BIP148, *users* will be on one or the other
< luke-jr> gmaxwell: less likely than if 30% run BIP148-adapted-to-BIP91, 30% run BIP148-as-is, and 40% run non-BIP148
< luke-jr> given the short time period and risk of splitting up enforcement too much, I currently favour just deployment of BIP148 as-is. not perfect, but I think it's the least-risky all things considered
< luke-jr> gmaxwell: BIP148's patch is only larger for safety and unit tests. it's much smaller than BIP91 without those.


< bitcoin-git> [bitcoin] achow101 opened pull request #10900: [0.14] Enforce segsignal activation height and rules (0.14...early-uasf-bip91) https://github.com/bitcoin/bitcoin/pull/10900
< Murch> praxeology: BIP91 requires every block to signal bit1.
< [\\\]> just as long as there is an info tip or link to what bip91 is
< praxeology> Emergency BIP91 Release
< sipa> but the reason for having bip91 enforcement in the client is not to make a minority chain win
< sipa> praxeology: a significant amount of hashrate may be spy mining, the amount actually enforcing bip91, even if they intend to, may be low and/or unmeasurable
< Murch> Providing a patch to Core that includes enforcement of BIP91 would give many users the option to support a defacto activated softfork that they currently can only enforce by running third party software.
< sipa> praxeology: which may mean that when bip91 activates, many forks are seen on the network, even if everyone totally intends the 91 chain to win
< Murch> While in sentiment large parts of the community support segwit activation and a majority of that would probably be willing to go along with BIP91, the node count doesn't yet reflect that.
< Murch> praxeology: That's not correct. It looks likely that BIP91 will have a majority in mining support, however due to the quick rollout it has hardly any node infrastructure.
< sturles> Re reorgs related to BIP91, will -walletnotify trigger if a transacttion changes status from confirmed to unconfirmed due to a reorg?
< gmaxwell> I would prefer to do the BIP148 based approach, but its a larger patch, unfortunately.
< Murch> morcos: Yeah, I agree that a release would be good. Another option would be to update BIP148 to start at the activation height of BIP91 activation instead of August 1st.
< Murch> morcos: Right now we're looking at an activation of BIP91 at Sunday morning at ~2am PDT (5am EDT). Likely if any reorgs happen then right at the start.
< gribble> https://github.com/bitcoin/bitcoin/issues/10444 | Implement BIP91 Reduced threshold Segwit MASF by jameshilliard · Pull Request #10444 · bitcoin/bitcoin · GitHub
< lejitz> gmaxwell: Clearly, having everyone enforce BIP91 is the way to go if it can be done in time. But if you can't get the econ nodes enforcing BIP91 before enforcement begins, then it is difficult to get people to begin enforcing at all, because they won't want to be the one to go first in the event that the a fork occurs right after they patch/upgrade. If upgrading must occur after BIP91 activates, then the
< sipa> lejitz: the worst forking will likely be right when bip91 activates...
< morcos> but why don't we decide to release a BIP148 patch then
< sipa> morcos: lejitz is arguing (i think?) for starting bip91 enforcement at another time
< morcos> gmaxwell: I think the point is that we as a community could decide that BIP91 is the new rules of Bitcoin
< morcos> in which case running a BIP91 node makes it safe to accept payments
< sipa> lejitz: it is a realistic chance that the eventual chain will not have bip91 enforcement, and won't have segwit activated
< lejitz> @sipa @achow101 Not enforced, complied with, meaning signaled bit 1. If every block since BIP91's activation (from a post activation perspective) signaled bit 1, then it's been complied with. The enforcement from the patch could be conditioned on that observation.
< lejitz> achow101: No, the patches enforcement is conditioned on BIP91 being enforced until the chosen enforcement time of the patch.
< sipa> lejitz: we can't observe whether bip91 is being enforced
< achow101> lejitz: that assumes that bip91 will be enforced from activation, but that is an assumption we cannot make
< lejitz> achow101: If most of the econ nodes can upgrade before BIP91 activation, then it is not a problem. But if it is afterwards, I can't see any of them wanting to risk being forked off the network while waiting for others to upgrade (who wants to go first?). As long as no fork has already occurred, then it is not a problem to join in enforcement later, but nobody knows what happens in the meantime while
< lejitz> everyone tries to coordinate. To solve this problem (assuming most econ nodes can't quickly upgrade before 91 activation), the patch can pick an arbitrary time/block height to start enforcing, so long as every block between BIP91 activation and the patches enforcement time has signaled bit 1. Everyone can take a few days to upgrade, knowing they will remain in consensus if there is a fork in the meantime.
< Murch> sipa: Well. We're currently running vanilla Core, and we're worried about customer funds getting entangled in reorgs that would supposedly be impossible if BIP91 were actually properly enforced.
< achow101> enforcing at the bip 148 activation time means that we would be enforcing with the bip148 clients.
< Murch> In order to protect ourselves from reorgs, wouldn't we want to enforce BIP91 starting with BIP91 activation?