< gmaxwell> no, I think I'll just recommend no one use BIPs for anything. Process has failed.
< luke-jr> a number of decent BIPs have negative comments; I suggest perhaps people may wish to provide positive feedback to counter them. https://github.com/bitcoin/bips/pull/500


< bsm1175322> Hmmm since you're here in NYC...we should get together soon and have a brainstorming session about a BIP37 replacement...
< bsm1175322> Stage 2 of this project will be to redesign BIP37. I'm well aware of its flaws.


< sipa> jeremyrubin: BIP152 relay speed depends on having transactions in your mempool


< bitcoin-git> [bitcoin] laanwj closed pull request #9739: Fix BIP68 activation test (master...fixbip68testing) https://github.com/bitcoin/bitcoin/pull/9739
< bitcoin-git> bitcoin/master 9d5fcbf Wladimir J. van der Laan: Merge #9739: Fix BIP68 activation test...
< bitcoin-git> bitcoin/master f5aba8a John Newbery: Move tx version 2 standardness check to after bip68 activation
< bitcoin-git> bitcoin/master 99c0e81 John Newbery: Fix BIP68 activation test


< gmaxwell> the latest BIP152 stuff is much more policy durable than prior stuff, since it will retain transactions rejected for policy reasons and still use them to reconstruct blocks.


< jonasschnelli> I think it would be great if #9294 could get a review from on of the bip32 authors (ping sipa, gmaxwell)


< bitcoin-git> bitcoin/0.14 a48b998 Suhas Daftuar: [doc] Update doc/bips.md for BIP90 implementation...
< bitcoin-git> bitcoin/master d75e8cb Wladimir J. van der Laan: Merge #9879: [doc] Update doc/bips.md for BIP90 implementation...
< bitcoin-git> [bitcoin] laanwj closed pull request #9879: [doc] Update doc/bips.md for BIP90 implementation (master...2017-02-bips-doc-bip90) https://github.com/bitcoin/bitcoin/pull/9879
< bitcoin-git> bitcoin/master fe71661 Suhas Daftuar: [doc] Update doc/bips.md for BIP90 implementation


< sipa> bip9 activation isn't dependent on the signalling of the block itself
< rgrant> but the attacker doesn't set bip9 (though bip9 has activated)
< sipa> the block validation code passes this flag to the script execution code when it's invoked for a block that has BIP9 activation


< jeremyrubin> hmm... would be kinda nice to not have to do that, similar to how I can set BIPxxxHeight = 0.
< bitcoin-git> [bitcoin] laanwj closed pull request #9847: Extra test vector for BIP32 (master...bip32up) https://github.com/bitcoin/bitcoin/pull/9847
< bitcoin-git> bitcoin/master 6206252 Wladimir J. van der Laan: Merge #9847: Extra test vector for BIP32...
< bitcoin-git> bitcoin/master 30aedcb Pieter Wuille: BIP32 extra test vector
< gribble> https://github.com/bitcoin/bitcoin/issues/9847 | Extra test vector for BIP32 by sipa · Pull Request #9847 · bitcoin/bitcoin · GitHub


< bitcoin-git> [bitcoin] sipa opened pull request #9847: Extra test vector for BIP32 (master...bip32up) https://github.com/bitcoin/bitcoin/pull/9847


< cannon-c> I thought bip39 was just using dictionary wordlist in 2048 length list to convert 256 bit entropy to human readable words (256bit being 24 words)
< * luke-jr> observes people are actually using https://github.com/bitcoin/bips/wiki/Comments:BIP-0039
< cannon-c> If not, any objection to including bip39?
< cannon-c> Does bitcoin core have bip39 for backing up wallet? Having trouble seeming to find it.


< fanquake> Looking at my two asserts, my biplist files haven't changed between the two.
< fanquake> My cached biplist files don't even match yours or his..
< fanquake> except biplist comes from bitcucket


< bitcoin-git> bitcoin/0.14 973e345 Pieter Wuille: Move BIP70_MAX_PAYMENTREQUEST_SIZE to header...
< bitcoin-git> bitcoin/master c801c82 Pieter Wuille: Move BIP70_MAX_PAYMENTREQUEST_SIZE to header
< gmaxwell> unsigned char randData[BIP70_MAX_PAYMENTREQUEST_SIZE + 1];


< gmaxwell> The workflow there is that they have a payment processing front end which generates keys using BIP32 public derrivation, and then imports the addresses. Because of contingencies around multiple nodes and restarts they may need to rescan a bit. The imported keys are used to watch for payments so they can display status to the user.


< Chris_Stewart_5> Looking at BIP113, it states we take the median time stamp for the last 11 blocks, but what stops the miner from egregiously lieing about that timestamp?


< bitcoin-git> [bitcoin] jnewbery opened pull request #9739: Fix BIP68 activation test (master...fixbip68testing) https://github.com/bitcoin/bitcoin/pull/9739


< sipa> indeed, not since bip66


< gmaxwell> need to stop saying RBF and just start saying BIP125 replacable. So much more clear. :P
< gmaxwell> in any case before BIP152 spec was done, I tested prefill based on misses and it cut the rount trip rate by a ton... but it was on a dumb test network. debug=mempool logs enough to let you make the measurement with existing nodes.
< gmaxwell> I doubt its much correlated with orphan risk at all now due to Fibre and BIP152.


< sipa> luke-jr: bumpfee won't let you bump without it being bip125


< cfields> sdaftuar: for the bip68-sequence test, i'm confused about how you tried to fix. Did you also try switching back to GetTime() rather than doubling down on GetTimeMicros()?
< CodeShark> luke-jr: for BIP123, I think either CC0 or GNU-all-permissive


< sipa> (and for any other BIPs I contributed to)
< luke-jr> sipa: if you get a minute, can you give me at least a text-"verbal" ACK for some copyright license to put on BIPs 30, 32, 62, 66, and 103 please? is BSD-2-Clause okay?
< gribble> https://github.com/bitcoin/bitcoin/issues/9586 | bip68-sequence.py failing on master after recent net changes, due to mocktime interaction · Issue #9586 · bitcoin/bitcoin · GitHub
< luke-jr> sipa: Can you give me a text-"verbal" okay for some license to put on BIPs 30, 32, 62, 66, and 103?


< luke-jr> wumpus: github wiki for bips at least seems to be editable by all?
< MarcoFalke_publi> Luke seems to be using it for the bips repo.


< jtimon> instagibbs: not sure what's the norm, but you definitely can technically, I received some PRs to my PR for bip99


< jonasschnelli> Flexible keypath is nice. But we don't want to support BIP44 anyways thats why it's not urgent
< gribble> https://github.com/bitcoin/bitcoin/issues/8723 | [Wallet] Add support for flexible BIP32/HD keypath-scheme by jonasschnelli · Pull Request #8723 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/8723 | [Wallet] Add support for flexible BIP32/HD keypath-scheme by jonasschnelli · Pull Request #8723 · bitcoin/bitcoin · GitHub


< NicolasDorier> not yes thought about it. BIP9 I think the easiest at beginning is that the user does it. I plan in v1 that the user will pass the consensus flags to activate
< jtimon> what about caches? what do you plan for caches? bip9 cache, sigcache?
< jtimon> I was kind of doing that for 0.12 but I decided I would wait for bip9 and segwit instead


< warren> jonasschnelli: hmm, I'm excited to use your SPV mode in conjunction with BIP150 (authenticated connection to my own full nodes)


< bitcoin-git> bitcoin/master d29505d jonnynewbs: Fix transaction size comments. Size now refers to virtual size as defined in BIP141.


< gmaxwell> your concern is because we didn't really properly consider relaying unvalidated blocks, but we just glommed it on because it would have unfortunate to specify BIP152 another way.


< gmaxwell> and asking multiple peers is very inefficient with BIP37.. needs n-times the bandwidth.
< jonasschnelli> Right, tx withhold is also possible with BIP37.
< gmaxwell> I thought you were referring to the filter itselt and not the hash root... Unclear, multiple models are possible and _all_ are better than BIP37.
< jonasschnelli> 0-conf / spv should probably only be possible in conjunction with BIP150 and a trusted peer (at home or somewhere)
< jonasschnelli> But I think there is no solution for a non-BIP37 0-conf "filtering" without running into these privacy issues related to bip37
< jonasschnelli> In a long shot, I could imagine, BFD (filter digest / filter commitments) for filtering from untrusted peers, and BIP39 for filtering from trusted peers (once BIP150 has ben established).
< sipa> BIP39?
< jonasschnelli> Even if BIP39 is not the most efficient way.


< Chris_Stewart_5> Isn't there a chance for malleability in OP_CHECKMULTSIG scripts even with BIP146


< luke-jr> the idea being to provide a central location users can use to differentiate between inadvisable and recommended BIPs
< gmaxwell> #action read (and maybe reply) to https://github.com/jl2012/bips/blob/sighash/bip-sighash.mediawiki
< jl2012> cfields: I hope people could read this: https://github.com/jl2012/bips/blob/sighash/bip-sighash.mediawiki . Didn't receive any reply on ML
< CodeShark> I'll look into BIP152 a bit more after the meeting
< gmaxwell> Sounds good. In any case, I'm glad to help talk it through. I wouldn't want to force you to wait on the BIP37 replacement to do something, but if we can be less stopgap that would be better.
< CodeShark> extending BIP37 would be a stopgap measure at best - if we can deploy a better solution nearterm I'm all for it
< gmaxwell> (in particular I was thinking you could use BIP37 on the non-witness data, and when you need witnesses, query by index for them)
< gmaxwell> In any case, if CodeShark thinks many of the interesting usecases could be answered by a query by index... I would rather work on that first. I am realllly not eager to continue to invest in the pretty much known broken BIP37 approach.
< gmaxwell> (I'm not sure you're familar with the BIP152 getblocktxn message, -- it is a "request transactions by their index in a block")
< CodeShark> while I don't really like BIP37 at all, we currently lack another query mechanism that doesn't require full block downloads



< Chris_Stewart_5> Why is this 'FindAndDelete' section needed in BIP143? Couldn't we just use FindAndDelete just like we did previously?


< Chris_Stewart_5> sipa: That made my night. I unequivocally support BIP42 and (while were at it) make PHP great again!
< Chris_Stewart_5> ahh, BIP42, not BIP142. I was thinking there was a proposal for strange chars in segwit addresses
< sipa> BIP32 also does not affect consensus, but it's still very useful to get people to agree on it
< sipa> BIP42 suggests that the currency symbol color should be considered
< Chris_Stewart_5> What do you think about raising the dbcache defeault value along the lines of your BIP10x proposal of scaling blocksize at the rate of tech growth (.. or something like that)


< gmaxwell> he's previously posted a number of absurd things, e.g. the posts claiming that BIP152 was going to "disrupt the network" and trying to get us to abort the 0.13 release.
< luke-jr> BIPs 2 and 123 are now Active


< btcdrak> harrymm: BIP109 was marked rejected, so it's currently meaningless. You should contact them.


< instagibbs> morcos, that's too weeks of nodes not accepting fee bumps if you mess up and don't do bip125 (not sure how big an issue that is but still)


< bitcoin-git> [bitcoin] jonasschnelli closed pull request #9238: Ignore BIP35 mempool command by default (master...2016/11/dis_mempool) https://github.com/bitcoin/bitcoin/pull/9238


< jonasschnelli> a flexible would allow to use bip44 and we could still stick to m/0'/k' by default
< jonasschnelli> bip44/45 maybe. But I don't think its wise to force users to do pub key derivation.
< jcorgan> i haven't kept up recently, but are there any relevant BIPS or defacto practices from other wallets we should be paying attention to in this area?
< gmaxwell> Today, with BIP152 and fibre propagation has very little to do with blockmaxsize. And blockmaxweight is the wrong dimension for applying backpressure on fees: it's blind to demand, you'll still dumbly produce smaller blocks when there is a nice backlog and dumly produce blocks that are too big when there is none (at least the minfee stops the bleeding there)
< gmaxwell> morcos: if you have debug=1 on, and the BIP152 missed by only a few txids it will log the missing txids and you can check your logs to see if you'd previously heard them.
< gmaxwell> I'd like rejection to work differently, putting rejected things in a datastructure that works like the new sigcache open-hashtable where they're taged for eager eviction but kept around until actually evicted... and then BIP152 can use that pool, and orphan resolution can use it and so on.
< gmaxwell> morcos: well we don't have the parent now and won't request it so the orphan will not get resolved. We might want to keep it around for BIP152 but right now BIP152 makes NO use of the orphan pool..


< sipa> there is work on a bumpfee command which will use bip125 to increase a txn's fee, and replace it with another one
< jtimon> sipa: thanks, I'm not so familiar with the bip32 wallet
< gmaxwell> jtimon: see bip32.. internal vs external.
< jonasschnelli> jcorgan: bip32 internal and external chains
< gribble> https://github.com/bitcoin/bitcoin/issues/8723 | [Wallet] Add support for flexible BIP32/HD keypath-scheme by jonasschnelli · Pull Request #8723 · bitcoin/bitcoin · GitHub
< jonasschnelli> sipa: In case you once start with BIP150 (I know you'll wait until the net refactor has been completed), here is the extracted ChaCha20Poly1305AEAD code from openssh: https://github.com/jonasschnelli/chacha20poly1305


< bitcoin-git> [bitcoin] jonasschnelli opened pull request #9238: Ignore BIP35 mempool command by default (master...2016/11/dis_mempool) https://github.com/bitcoin/bitcoin/pull/9238


< gmaxwell> If in my efforts to contact users of the system or the mailing list thread had indicated that it wasn't universally (or nearly so) wanted, I would have opposed including it. The assumption is that it's wanted. Purpose of BIP9 is so that it will only happen once miners would actually enforce it.
< sipa> dcousens: we don't want BIP9 to trigger if isn't actually enforced...
< dcousens> if you signal though, it would still trigged BIP9 though?
< BashCo_> I'm seeing people just look into the benefits for themselves instead of listening to bad info. Most people just want more tx capacity and they don't care about the details. Segwit will increase tx volume more than BIP109 and is backward compatible.


< layman01> bluematt, im looking while on here. but got interupted due to bip70 that didnt answer my question
< gmaxwell> layman01: you've misunderstood BIP70.
< layman01> ok so bip70 is still using the [output] part of a tx as the messaging tool (from my quick brief read of it) not adding data after [sig][nlocktime]


< sipa> bip151 changes the pipe, but the things being sent over it are still the same messages
< sipa> i see bip151 simply as a change to the pipe, not to the messages in it
< cfields> BlueMatt: i have a proposal for bip151 that would make it so that encryption isn't reliant on the messaging processing layer, but i haven't written it up yet
< gmaxwell> for example, some peers might use compacted transactions some might not. But is that the correct layer for it? I don't think we'd propose implementing BIP152 block compaction inside CConnman.


< instagibbs> too-many-bips problem :P
< sipa> Chris_Stewart_5: see bip144 for that
< Chris_Stewart_5> Is the serialization format described in BIP141 only used when calculating a wtxid, or is this serialization format also used when propogating a tx across the p2p network?


< sipa> gmaxwell: well if they don't support bip145, they will just ignore default_witness_commitment
< sipa> cfields: maybe in bip151 the checksum should be at the end


< jtimon> BlueMatt: I guess if we can maintain the printing of the error without much disruption that would be nice, but I don't really know how important this is for bip22, maybe luke-jr has an opinion on this?
< Chris_Stewart_5> jcorgan: I misinterpreted wumpus comment about 'not using' BIP37 in core as 'removing' it and apparently that triggered everyone ;). Thanks for the support though, some one has to ask the dumb questions :-)
< gmaxwell> Maybe someday BIP37 goes away, but only if it were replaced with something better for the things that use it now. There are proposals but at the moment no one is actively working on them.
< bsm1175321> I'm interested in making an update to BIP37 to improve light wallet security...
< jonasschnelli> Chris_Stewart_5: </panic mode> you can use BIP37 with plenty of other wallets, but when using Core, we don't want scarifies privacy over because of some GB bandwidth
< wumpus> we're just nopt using BIP37 for the light wallet mode in bitcoin core. If you want to use it in your wallet go ahead.
< wumpus> no one is *removing* BIP37
< Chris_Stewart_5> jonasschnelli: If we are removing BIP37 there isn't a choice.
< jonasschnelli> I think it could have it's reason when connected to a BIP150 authed trusted peer. But only then.
< wumpus> yes, BIP37 is a bad idea, we're not going to use it in core
< gmaxwell> (BIP37 is also vulnerable to txn being hidden from you)
< jonasschnelli> Chris_Stewart_5: its a safer solution then BIP37...
< Chris_Stewart_5> This is alt solution to BIP37 then, or complementary?
< gmaxwell> Chris_Stewart_5: bip37 _utterly_ destroys privacy, and would waste bandwidth if you're later going to need the block for verification anyways.
< Chris_Stewart_5> I guess my real question is could 'F' in the examples be a LOW_S sig https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki#examples
< Chris_Stewart_5> sipa: "any BIP66-compliant non-empty byte array but not a valid signature" - this means that it is not a valid signature wrt to the public key in the script, right?
< Chris_Stewart_5> The way I read BIP146, it's almost saying that you cannot place a OP_FALSE onto the stack unless OP_CHECKSIG had as input an empty byte array as a signature, but of course that doesn't make sense
< bitcoin-git> [bitcoin] Christewart closed pull request #9174: Modifying incorrect comments from BIP66 -> BIP62 (master...master) https://github.com/bitcoin/bitcoin/pull/9174
< bitcoin-git> [bitcoin] Christewart opened pull request #9174: Modifying incorrect comments from BIP66 -> BIP62 (master...master) https://github.com/bitcoin/bitcoin/pull/9174


< sipa> though i'm not sure it supports bip9


< achow101> bip9 bits graph


< gmaxwell> yea, that 'feature' really contributes to the lack of privacy and utiliy of BIP37.
< bsm1175321> Woah I had no idea the BIP37 filters are applied to *any* data element in your script.
< tulip> bsm1175321: similarly BIP37 hashes items in the scriptpubkey individually and adds them to the filter.
< jonasschnelli> Once we have 150/151, we could add bloomfiltering options against bip150 authed peers.
< jonasschnelli> sipa: BIP151 has varlen command codes
< jonasschnelli> Bip151 encrypted message packaging (https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#encrypted-messages-structure) allows that. Because from the protocol perspective, combining them seems to have no downside
< jonasschnelli> would it make sense to use a 1byte command code instead of the 12byte char in the new bip151 message structure?


< Chris_Stewart_5> Is the CHECKSIG operation missing in BIP141 for P2WPKH & P2WPKH nested inside of P2SH? https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wpkh
< cfields> jonasschnelli and i just discussed a bit, i'm making sure that the current refactors at least make bip151 not harder, but hopefully easier too
< sipa> jonasschnelli: i was planning to work on bip151, but i'm not going to touch anything before the ongoing net refactors are done :)
< jonasschnelli> I have started with the BIP151 implementation and are trying to split it into different PRs, though, not sure how easy that is.


< jtimon> wumpus: instagibbs I added the reindex rpc tests to #8994, to test #9102 (well, and #8994 in general), if you think of other rpc tests that would be interesting to duplicate for this or default values for the custom chain (ie maybe consensus.BIP34Height = 0 or whatever ) please let me know


< instagibbs> So I noticed that AcceptBlock attempts to validate various amounts of the genesisblock upon reindexing. Is this desired behavior? For example, it checks for height in coinbase if bip34height is set to <= 0
< btcdrak> luke-jr: I think Andreas has a point https://github.com/bitcoin/bips/pull/472#issuecomment-258794458


< murch> Nevermind, reading BIP0009 now. :p
< murch> Does signaling start with the epoch time listed in the Deployment on BIP141 or with the first difficulty retarget after the epoch time listed in deployment?


< luke-jr> gmaxwell: I *think* we've fixed such issues in Final BIPs already
< gmaxwell> If no one of consequence actually implemented BIP30 as specified in the doc, what use does keeping the old doc around (except in the git history) serve?
< gmaxwell> morcos: so interesting point, say we discovered that BIP30 was implemented differently from the BIP tomorrow. What should we do? IETF way would be to attach an erratum to the document right away. But I find that this often confuses people who manage to read the document without an erratum. Then later a new document is published that reflects reality. Though this has a problem that people reme
< luke-jr> sipa: sure, we still make clarifications to Final BIPs even now I think
< BlueMatt> luke-jr: after https://github.com/bitcoin/bips/pull/469, yea, probably
< gmaxwell> and BIP152 already explained how versions were to be handled in a compatible way.
< gmaxwell> luke-jr: for the specifics here, 0.13.1 is compatible with BIP152 because it implements a new version number that the original bip152 was just silent on.
< gmaxwell> But I think what luke was referring to is that BIP152 didn't originally document version 2 compact blocks that use the wtxid instead.
< sipa> so i believe 0.13.1 is compliant with the updated bip152
< sipa> so the issue is only when potential other bip152 implementations are oresent on the network
< luke-jr> (suggested topic: when to halt changes to BIPs; 0.13.1 is no longer BIP 152-compatible I think)


< sipa> oh, with bip68 we do
< morcos> bip68?
< jonasschnelli> BIP152 doesn't helps in the SPV mode (UTXO set not ready)
< gmaxwell> the timeout is 10 minutes. (at the tip, normally we expect things to be transfered via BIP152 high bandwidth mode, which can't stall)


< sipa> and the bip151 hasher should be a few times faster
< gmaxwell> was it related to bip30?


< goatpig> wait so BIP142 isn't approved?
< goatpig> what's the status on BIP142?


< arubi> at least that's what I gathered from bip141


< gmaxwell> tulip: I've encountered a number of other nodes doing that, wastes a lot of bandwidth. now that we have BIP152 deployed, we should look to banning peers that send unsolicited full blocks.


< Chris_Stewart_5> Not sure if this this is a good question or not, but is this something deployed with BIP9?
< jtimon> like really imposing the 21 M limit, that was a softfork too, but no need to use bip9 to deploy I guess
< sipa> only before bip34 activation
< NicolasDorier> sipa: the thing that slow down is BIP30
< NicolasDorier> while playing doing my node in C#, I tried a way to speedup IBD by 50%: Basically I prefetch the UTXO and tx id's (for BIP30) of block N+1 while validating block N. Still a bit early to call victory, but might be a piste to explore for core


< michagogo> btcdrak: I see that for the BIPs


< wumpus> well a new testnet would need a new bip70 identifier I guess so that can be fixed then... but it's a minor inconsequential thing
< jtimon> I particularly hate the fact that in bip70 testnet3 is called "test" instead of "testnet3" but that's a tiny detail
< jtimon> well, maybe if you want to make some values more similar to the mainnet to make them constants again, but I really don't know, I've thought more about testnet4, particularly in the context of bip70 which maybe gets replaced or something


< jl2012> i think the main argument for BIP16 was the output is not anyone-can-spend until it is actually spent. But the difference is very limited
< wumpus> segwit got *tons* of review compared to BIP16 I'm sure


< sipa> jtimon: my fear is that it's very hard to create a stable API for storage of headers... things like BIP9 cache and the skiplist for example are things that would break the API, but such changes may be needed in the future
< jtimon> to hide the bip9 and previous developments stuff
< jtimon> wumpus: like bip113 ? or more like bip30 ?
< Victorsueca> maybe it would be better if we named bip147 something other than nulldummy
< sipa> Victorsueca: bip147
< GitHub86> [bitcoin] jonasschnelli reopened pull request #8723: [Wallet] Add support for flexible BIP32/HD keypath-scheme (master...2016/09/hd_flex) https://github.com/bitcoin/bitcoin/pull/8723
< GitHub145> [bitcoin] jonasschnelli closed pull request #8723: [Wallet] Add support for flexible BIP32/HD keypath-scheme (master...2016/09/hd_flex) https://github.com/bitcoin/bitcoin/pull/8723


< GitHub129> bitcoin/master 5d2c8e5 Wladimir J. van der Laan: Merge #7948: RPC: augment getblockchaininfo bip9_softforks data...
< GitHub154> [bitcoin] laanwj closed pull request #7948: RPC: augment getblockchaininfo bip9_softforks data (master...version_bits_locked_in_block) https://github.com/bitcoin/bitcoin/pull/7948
< GitHub129> bitcoin/master fc14609 mruddy: RPC: augment getblockchaininfo bip9_softforks data
< jl2012> aj: re SIGHASH_SINGLE: yes, BIP143 sort of fixed the bug


< sipa> or always treat the outgoing connections as using a connection slot, unless the peer knows you specifically (whitelist/bip150/...)
< GitHub22> bitcoin/0.13 06d15fb Pieter Wuille: Update implemented bips for 0.13.1...
< GitHub44> [bitcoin] laanwj closed pull request #8939: Update implemented bips for 0.13.1 (master...bips131) https://github.com/bitcoin/bitcoin/pull/8939
< GitHub61> bitcoin/master ef3402d Wladimir J. van der Laan: Merge #8939: Update implemented bips for 0.13.1...
< GitHub61> bitcoin/master 0941f55 Pieter Wuille: Update implemented bips for 0.13.1
< instagibbs> achow101, NODE_WITNESS is only advertised once bip9 parameters have been defined for a chain
< GitHub16> [bitcoin] sipa opened pull request #8939: Update implemented bips for 0.13.1 (master...bips131) https://github.com/bitcoin/bitcoin/pull/8939
< GitHub74> [bitcoin] laanwj closed pull request #8937: Define start and end time for segwit deployment (master...bip141start) https://github.com/bitcoin/bitcoin/pull/8937
< btcdrak> sipa: you need to update your BIP PR to amend this as well https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
< btcdrak> We can save more bytes on the BIPs by aggregating like Schnorr: BIP141+143+147 = BIP431
< instagibbs> just to make sure what about bip109
< GitHub8> [bitcoin] sipa opened pull request #8937: Define start and end time for segwit deployment (master...bip141start) https://github.com/bitcoin/bitcoin/pull/8937


< instagibbs> bip9 even
< wallet42> also congrats on sipa's proposal for a BIP9 activation date. very excited. :-) i d'ont want to be a party pooper


< kanzure> or, what's your strongest argument for not editing bip1


< BlueMatt> luke-jr: care to press merge on https://github.com/bitcoin/bips/pull/462


< btcdrak> yes, the fact BIP9 requires 4-6 weeks to kick in realistically, makes it less of an issue
< gmaxwell> Keep in mind, in prior softforks the starting time was infinitely far in the past. And BIP9 made its way through 95% of its development with no starting time.
< wumpus> #topic BIP9 parameters
< sdaftuar> i don't think we can just change bip9 params during the rc process
< jtimon> wumpus: bip9 parameters?
< gmaxwell> BIP9 recommends it be set roughly a month after software release. I don't currently see a reason to deviate from that.


< jl2012> examples of witness serialization could be found in https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Native_P2WPKH


< dcousens> (assuming a transaction is to be encoded per BIP141), is witnesses length always == to inputs length? Just reading: "A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a 0x00."


< GitHub112> [bitcoin] MarcoFalke closed pull request #8891: [Doc] Update bips.md for Segregated Witness (master...segwit-bips-md) https://github.com/bitcoin/bitcoin/pull/8891
< GitHub190> bitcoin/master ef28d8a fanquake: [Doc] Update bips.md for Segregated Witness
< GitHub190> bitcoin/master 072116f MarcoFalke: Merge #8891: [Doc] Update bips.md for Segregated Witness...


< gmaxwell> well BIP152 allows you to send the block before its verified.


< GitHub50> [bitcoin] fanquake opened pull request #8891: [Doc] Update bips.md for Segregated Witness (master...segwit-bips-md) https://github.com/bitcoin/bitcoin/pull/8891
< luke-jr> indeed, node policy isn't something BIPs should cover, except in the case of it being preparation for a softfork
< gmaxwell> Well we can do like we did with CSV, we had three BIPs triggered on one bit.
< sipa> wumpus: i guess MSG_FILTERED_WITNESS_BLOCK is what we'd need for a bip37 extension with segwit data
< achow101> the values for MSG_WITNESS_BLOCK and MSG_WITNESS_TX should probably be defined in BIP144...
< wumpus> MSG_FILTERED_WITNESS_BLOCK defined in protocol.h is neither used in our source code nor defined in any BIP, should be in BIP144 I guess?


< gmaxwell> no, bips are for interoperability. the internal encoding is purely internal and could change freely from version to version.


< luke-jr> BIPs can't do both. maybe not relevant, dunno
< gmaxwell> luke-jr: I had no idea about BIP2 until I wigged out about you assigning a BIP number to a restrictively licensed specification. :)
< MarcoFalke> As I said, the BIP process does not make sense to be applied to BIP1 itself.
< luke-jr> btcdrak: so you'd insist libbitcoin code cannot be used in any BIPs?
< luke-jr> MarcoFalke: BIPs are amended by replacing them. That's how the process works right now. <.<
< MarcoFalke> And then ping people: "Please read BIP2, BIP3, ... but don't read BIP1"...
< luke-jr> so we can discourage people from adopting crappy BIPs
< MarcoFalke> We should not forcefully keep us in this awkward situation of BIP1
< MarcoFalke> I am looking forward to see the BIP2 changes merged, but there may be some people not approve all changes.
< MarcoFalke> Sure, but for BIP1 it seems particularly weird. (Given that the (Github)user is not active in any other bitcoin related project)
< MarcoFalke> I know BIP2 solves this, but we should use common sense to see that BIP1 mostly applies to other bips
< MarcoFalke> luke-jr: It seems odd to place our whole bip process into the hands of a single github user. No one verified who owned this account right now. They could just do anything if they are required to ACK every change to BIP1.


< achow101_> so if anyone wants to help armory with segwit support, bip32, compressed keys, we accept PRs. All our work happens in the dev branch, not master
< achow101> the plan is to have a new wallet structure with bip32 that supports segwit and compressed keys
< waxwing> right, which i guess might be of particular import in your case (/me hasn't read bip151 tho)
< sipa> implementing bip151 in wireshark will be fu
< wumpus> a more practical way to go at this, post-bip151, would be add functionality to dump packets to disk after decryption on receive and before encryption on send, it's for debugging anyhow not snooping
< sipa> damn. i believe this is a blocker for bip151.


< sipa> dinao: bip68 uses it


< GitHub85> [bitcoin] laanwj closed pull request #8796: [trivial] fix mempool comment (outdated by BIP125) (master...trivial_comment) https://github.com/bitcoin/bitcoin/pull/8796
< GitHub103> bitcoin/master c14ffd5 jonnynewbs: [trivial] fix mempool comment (outdated by BIP125)
< GitHub103> bitcoin/master 8f1fbf3 Wladimir J. van der Laan: Merge #8796: [trivial] fix mempool comment (outdated by BIP125)...
< gmaxwell> "X operators according to BIP10 not BIP11"
< btcdrak> luke-jr: saying BIP1 is deprecated and now use BIP2 is the same as changing the text of BIP1, but more confusing. Let's just change BIP1


< MarcoFalke> If it says somewhere in BIP1 that it is not allowed to amend, just remove that line :P. Chicken-egg problem solved
< MarcoFalke> In the text of BIP1 it says it is never meant to be completed, so you can always change it
< wumpus> I think it does, BIP1 doesn't have final status


< CodeShark> I run multiple bitcoin core instances and reluctantly use bip37
< gmaxwell> the commited maps thing would let us do several non-commited revisions the only thing you lose without the commitment is security against censorship, which BIP37 has none of already.
< gmaxwell> the commited filter thing can also be done without the commitment and still have the same security as BIP37 but without the consensus change.
< Chris_Stewart_5> CodeShark: Did you have any concrete ideas for improving on BIP37?
< CodeShark> I want a good fairly secure quick sync solution. BIP37 sucks :p
< BlueMatt> we might fix this by throwing out bip37 and doing something not-batshit-insane, but thats an aside from the meeting
< wumpus> BIP37 can be extended, sure
< BlueMatt> Chris_St1: bip37 only ever matches constants
< Chris_St1> BlueMatt: Matching scriptSig constants in BIP37 right?
< Chris_St1> BIP37 is definitely a monster in terms of implementation... or atleast it was for me
< CodeShark> I'd prefer a replacement to bip37, but that's more involved
< sipa> it's trivial (just combine bip37 with bip141 wtxids)
< sipa> but it needs to be fleshed out... and i don't know how keen people are on extending bip37 further
< btcdrak> sipa: I think there are a couple of niggles on the BIP also https://github.com/bitcoin/bips/pull/423
< sipa> see bip143
< GitHub197> [bitcoin] jonnynewbs opened pull request #8796: [trivial] fix mempool comment (outdated by BIP125) (master...trivial_comment) https://github.com/bitcoin/bitcoin/pull/8796
< GitHub156> [bitcoin] laanwj closed pull request #8636: Implement NULLDUMMY softfork (BIP147) (master...nulldummy) https://github.com/bitcoin/bitcoin/pull/8636
< GitHub84> bitcoin/master 26b370a Wladimir J. van der Laan: Merge #8636: Implement NULLDUMMY softfork (BIP147)...
< GitHub28> [bitcoin] laanwj closed pull request #8186: [0.12.2] backport: getblockchaininfo: make bip9_softforks an object, not an array. (0.12...Mf1606-rpcBip9Backport) https://github.com/bitcoin/bitcoin/pull/8186


< luke-jr> for better or worse, it's not really feasible to implement GBT from less than the BIPs
< luke-jr> it has a link to the BIPs ☺
< gmaxwell> BlueMatt: you want the relevant BIP9 rules, it's described in BIP 145 and BIP 9.


< GitHub10> [bitcoin] jonasschnelli opened pull request #8723: [Wallet] Add support for flexible BIP32/HD keypath-scheme (master...2016/09/hd_flex) https://github.com/bitcoin/bitcoin/pull/8723
< jonasschnelli> Is there a reason why the last key in out HD scheme (and in BIP32) is non-hardened? Its m/0'/0'/0 for the first key and not m/0'/0'/0'


< GitHub171> bitcoin/master 05fa823 Wladimir J. van der Laan: wallet: Add BIP125 comment for MAXINT-1/-2 behavior