18:59:48 #startmeeting 18:59:48 Meeting started Thu Sep 22 18:59:48 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:48 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:54 #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier 18:59:55 Here 18:59:58 here 19:00:04 jl2012 ping 19:00:11 hello 19:00:15 pyng 19:00:17 hi. 19:00:21 hi 19:00:22 jl2012 probably won't be here this meeting 19:00:22 peng 19:00:53 May show up in a bit - at dinner with my grandmother atm 19:00:54 01110000 01101001 01101110 01100111 19:01:06 our meeting is at an unfriendly time for our contributors in asia/au/nz/etc. Alas. 19:01:10 I may not join the meeting today but I suggest not to do https://github.com/bitcoin/bitcoin/pull/8654 in 0.13.1 19:01:10 It seems the risks is too much comparing with the benefit 19:01:52 yes what ever time you pick it's always unfriendly to someone 19:01:54 I was discussing this with him yesterday. I also think it should be dropped. 19:02:38 wumpus: we should find a time that is unfriendly to everyone :) 19:02:56 #topic Drop reuse sighash computations across evaluation #8654 from 0.13.1? 19:02:58 wumpus: wasn't a complaint, just reminding people of it. :) (and we can all make an effort to stand in for people who can't make it) 19:03:26 gmaxwell: something else we could do is have e.g. alternating times every week 19:03:48 yes, i'm in favor of dropping it. i believed the advantages were larger first 19:03:49 but given that people already have a hard time being there intime for a meeting with a fixed time... :-) 19:04:03 but it seems we'll need more changes anyway than we can tolerate for 0.13.1 19:04:07 So re: that PR. We can do it later. We've survived thus far without it. 19:04:13 yes. 19:04:16 ok 19:04:38 removing 0.13.1 milestone from it 19:04:55 how much worse is the maximum O(n^2) time for segwit? my understanding is that w/o segwit in theory even dozens of minutes are possible anyway 19:05:19 petertodd: the same 19:05:43 sipa: but can't you get more checksig ops w/ segwit? 19:05:45 petertodd: as segwit inputs only hash the entire transaction at most once 19:05:57 see bip143 19:06:02 petertodd: IIRC. this change is primarily fixing the non-segwit case. The plain hashcache in segwit already optimizes segwit so its basically solved under segwit. 19:06:23 hi 19:06:57 petertodd: the worst case for a pure segwit-inputs transaction is around 6 ms per block 19:07:04 so the non-segwit cases are the worst case, but we have determined that exploiting some additional caching oppturnities radically reduces that worst case when coupled with a few inconsequential additional limits. 19:07:06 gmaxwell: ah right, because of how we changed SIGHASH_SINGLE behavior 19:07:22 petertodd: all sighashing is changed in segwit 19:07:24 alright, I'm ACK to remove that for 0.13.1 19:07:33 great 19:07:39 sipa: well sure, but SIGHASH_SINGLE is changed in substance significantly :) 19:08:09 petertodd: right but the reason segwit doesn't have the n^2 blowup anymore is the general change so that the hashing work across inputs can be shared. 19:08:14 petertodd: hmm? they're all changed in a very similar way, with the whole-transaction parts precomputed rather than inlined 19:09:15 are #8634 and #8499 and #8526 ready for merge? 19:09:34 that's a new topic proposal achow101? 19:09:58 just a question 19:10:00 related topic at least. 19:10:28 well they were part of last week's homework 19:10:34 Add policy: null signature for failed CHECK(MULTI)SIG https://github.com/bitcoin/bitcoin/pull/8634 19:10:54 Check bad witness and implement several policy limits for segwit scripts https://github.com/bitcoin/bitcoin/pull/8499 19:11:19 Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH https://github.com/bitcoin/bitcoin/pull/8526 19:11:43 The first and last commits for 8634 should be squashed together, have only done limited testing, but the code changes look good 19:12:20 Still reviewing 8499 19:13:28 ok, anyone else with opinion about those pulls? 19:14:47 8634 needs a squash. LGTM. 19:14:56 8499 is a blocker for 0.13.1 for sure 19:15:02 wasn't it decided that 8393 was ready, or just about ready 19:15:04 fyi i'm just starting my review of 8499 now 19:15:06 looks like #8634 has quite a lot of (u)tACKs 19:15:30 (but don't let me hold thigns up!) 19:16:19 #action merge #8634 after squashing 19:16:35 8499 is still very much in progress 19:17:18 8393 isn't that hard to review but only a couple people have given acks 19:17:44 reminder on milestone 22, https://github.com/bitcoin/bitcoin/milestone/22 (and if there are 0.13 things in that, which aren't tagged, make sure they get tagged) 19:19:56 i'll address the latest nits in 8393 19:20:00 so anything between those that is ready for merge? 19:20:43 We need a few more acks on 8526 but it looks harmless enough as is. 19:21:23 there seems to be disagreement on the RPC behavior change in Fix issue with conflicted mempool tx in listsinceblock https://github.com/bitcoin/bitcoin/pull/8757 19:21:35 this probably means it should be untagged for 0.13.1 19:21:38 sipa: I think there are a couple of niggles on the BIP also https://github.com/bitcoin/bips/pull/423 19:21:47 Yes. No need for 0.13.1 19:21:57 btcdrak: yes, i'm aware 19:22:17 jonasschnelli: right, if we do that it should be something documented in the release notes of a major release 19:22:23 ack 19:22:41 People probably built apps on the "strange" listsinceblock behavior. 19:22:48 exactly 19:23:12 remved the 0.13.1 ms from 8757 19:23:17 okay that leaves four to go 19:23:27 wumpus: wait, we're unmarking compact blocks for 0.13.1? 19:23:32 (you just did) 19:23:32 re the listsince blocks The complaint is that conflicts are always shown and the proposed change made them never shown? 19:23:34 regarding segwitcb, roasbeef's scripts are running spamming testnet. If there are any miners pointing hash at testnet, can they set "-blockmaxweight=4000000", leaving off any other related params so we get more bigger blocks. 19:23:43 BlueMatt: uh 19:23:47 BlueMatt: wat? 19:23:54 @laanwj laanwj removed this from the 0.13.1 milestone a minute ago 19:23:55 er did someone remove the segwit cb? 19:23:56 that was a mistake 19:23:57 I assume that was accidental 19:24:00 please readd 19:24:05 #8393 19:24:15 unclick 19:24:27 ok, so 5 to go 19:24:32 readded 19:24:47 4 PRs, one related issue 19:24:52 you take one down, pass it around, 5 PR to g 19:25:19 * BlueMatt is not sure how to feel about #8526...it'll surely end up merged onto master before segwit activates...agree its nice to have things "clean from the start", but do we define clean as policy in 0.13.1 or policy on master/0.14? 19:25:20 exponential PR blow up 19:25:22 There is also this nice project https://github.com/bitcoin/bitcoin/projects/5 19:25:26 if you just want the percentage to go up, feel free to add tags to closed prs that got backported but were never tagged 0.13.1... There are many. :P 19:26:13 yes good point btcdrak PSA: I've started using the new feature of github projects for tracking a few longer-running projects: https://github.com/bitcoin/bitcoin/projects 19:26:14 same with 8634 19:26:55 wumpus, nice! 19:27:08 or, really, what about ignoring #8634 and #8526 and going to solicit feedback for segwit dates after the other ones are in, and then if they make it in before we get date consensus, then they go in, otherwise no 19:27:13 minor meta aside, is there any facility for backing up and retaining all this new github stuff? 19:27:33 gmaxwell: havent looked, but the github api has historically been very, very complete 19:27:39 so i ass-u-me so? 19:27:42 gmaxwell: that's iwilcox's department (but he's not here) 19:28:17 but yes I guess it's available on the API if you know where to look, or it will become available, as BlueMatt says 19:28:21 BlueMatt: 8526 when it goes SF could plausably conficate coins, so it's more important to have it non-standard from the getgo. 19:28:53 and 8634 is done but for a squash as far as I can tell. 19:29:24 already created an action for #8634, we're repeating ourselves 19:29:26 gmaxwell: I'm not sold on it needing to be in anything but master before release, but, ok, in any case, i'd propose we start looking for date-consensus after #8279 and #8499 are in 19:29:26 gmaxwell: the github API supports all this new stuff https://developer.github.com/v3/repos/projects/ 19:29:45 (ie lets start looking for date consensus like...soon) 19:29:55 like.. now? 19:30:01 no, not now 19:30:05 achow101: no, after critical updates are merged 19:30:11 first know when we can possibly have a release 19:30:14 like...in a few days after the non-critical ones are merged 19:30:14 BlueMatt: well we need #8393 merged too before we can be sure to set dates 19:30:37 btcdrak: sure, fine, #8393, #8279, and #8499, then dates? 19:30:50 ack 19:30:55 i believe 8279 is sufficiently resolved for 0.13.1 19:31:11 let's try to finish those pulls this week then we can talk about the release next meeting 19:31:11 BlueMatt: do we know what the status of btcd's SW support is? 19:31:22 gmaxwell: thats part of soliciting consensus on dates :p 19:31:24 ping roasbeef 19:31:30 (ie reaching out to non-bitcoin core people) 19:31:46 BlueMatt: well I've been doing that for a while. that doesn't have any binding on pending PRs. 19:31:46 wumpus: ack 19:32:02 sdaftuar: ok, so let's remove that issue from the 0.13.1 milestone, but not close it 19:32:12 wumpus: sounds good to me 19:32:28 wumpus: sounds good 19:32:55 btcd is the only active alt implementation that I'm aware of that didn't respond to my "when do you think you'll work on this" with a "only after it's locked in on the network". 19:34:59 BlueMatt: in any case, out of meeting lets try to work on a list of required actions for the activation. 19:35:13 makes sense to reach out to them then 19:35:21 well in terms of wallet code and supporting libraries, there are many which are SW ready, or have it almost ready to go. 19:35:33 yes. 19:35:34 python-bitcoinlib has a fairly good pull-req for segwit 19:35:45 awesome 19:36:08 mining software was in a sad state last time I checked, but I know things have improved a lot. 19:37:03 in any case, many things to discuss there that don't need everyone. :) 19:37:07 will be starting to finalize my segwit stuff for btcd starting tomorrow, have been busy with lightning stuff and getting btcd up-to-date with past recent soft-forks (CSV, etc) 19:37:32 roasbeef: +1 19:37:34 primarily need to improve the test coverage, and make changes like cost->weight and the nulldummy stuff 19:37:36 roasbeef: fantastic. 19:38:00 i keep meaning to return to patching miners but getting distracted. Feel free to ponk me if there's some mining software that actually gets used that needs to be updated. 19:39:15 armory is.. getting there. We're aiming for the release after the next to have full segwit support 19:39:44 achow101: thanks! 19:39:47 achow101: thats a good timeframe, really no one should be using it the instant it activates, except for testing. 19:40:03 oh I didnt know you work on Armory achow101 +1 19:40:22 my stuff is almost 100% segwit ready, just need merkle proofs for witnesses in filtered blocks or some better SPV solution 19:40:47 gmaxwell: I'll probably switch opentimestamps to use segwit, but that's a maximum loss of something like $20 :) 19:40:57 It's just good to hear that more things are almost read, as it's another angle of testing. 19:41:25 CodeShark: What BIP is that related to? 19:41:50 We don't have a BIP yet, I don't think 19:41:52 Chris_St1: that will need a new bip 19:42:26 it's trivial (just combine bip37 with bip141 wtxids) 19:42:32 ok, gotcha. 19:42:34 Chris_St1: he wants something like the filtered block messages that provide witnesses too. (the opposite of what most SPV wallets do, but codeshark extracts participant data from witnesses) 19:42:49 but it needs to be fleshed out... and i don't know how keen people are on extending bip37 further 19:43:12 I'd prefer a replacement to bip37, but that's more involved 19:43:14 BIP37 is definitely a monster in terms of implementation... or atleast it was for me 19:43:14 We could probably do better. 19:43:55 at least we could propose to drop some of the auto-inserting that causes false positive rate blowup 19:43:56 note that it's reasonable to ask for a full block even if you are a lite-client in many cases 19:44:28 CodeShark: uhhhhhhhhh, that sounds like a blocker 19:44:32 petertodd: Satoshi's vision. 19:44:34 petertodd: such as? 19:44:49 I guess he means as a way to get more privacy? 19:44:53 BlueMatt: how so? 19:45:05 it seems to me it is impossible to use the bloom-filtered connection stuff in segwit....I mean we can decide to not support it because its bad, but we need to actively decide that 19:45:06 no, I just mean that the data increase is relatively low 19:45:07 BlueMatt: wut? hell no. I am aware of no other SPV client than codeshark's that does _anything_ with the witness data right now. 19:45:07 no tevealing which txs you care about? just thinking out loud... 19:45:22 BlueMatt: spv wallets shouldn't care about the witness data 19:45:55 hell, it's an advantage that their bandwidth will drop 19:45:57 sipa: indeed, they can't verify that the witness is valid 19:46:09 BlueMatt: it works fine, you just don't get witnesses, which is an intentional and desirable outcome thats actually listed on the segwit advantage sheets. For the most part they can't do anything with the data. 19:46:09 wallets that don't tell you who signed a multisig are incomplete ;) 19:46:34 There should be some option for those who want it, sure. Though they can also fetch the whole block, so its not a big deal even there. 19:46:37 CodeShark: well, that's an example where you can request a full block - not many wallets need to actually know that 19:46:53 CodeShark: as an example, I don't think GreenAddress will tell you who actually signed txs in a GA wallet 19:47:12 it's critical for enterprise applications 19:47:20 Accountability is important 19:47:22 CodeShark: enterprise can afford some extra bandwidth I'm sure :) 19:47:29 I think we're getting OT 19:47:32 CodeShark: this isn't a blocker is all I'm saying 19:47:45 we can revisit this after 0.13.1 19:47:48 It's also not news or an accident. 19:48:00 no one is considering it is a blocker except for BlueMatt 19:48:03 CodeShark: ack 19:48:28 gmaxwell: sure, I'm saying that you cant use segwit as an spv client 19:48:36 BlueMatt: of course you can? 19:48:38 BlueMatt: thats not true. 19:49:00 BlueMatt: note how with segwit, your txids aren't malleable, therefore you can add the txids of outputs in your wallet to your bloom filter and be sure you'll know if they get spent 19:49:05 gmaxwell: however, in cases like a scripthash, you previously are able to see things that were to your public, or partially to your pubkey 19:49:08 which you might want to 19:49:21 petertodd: you already do that, the malleability doesnt help 19:49:31 May be a stupid question, but are we refering to 'blocker' in the context of blocking 0.13.1 or downloading a full block? 19:49:36 * BlueMatt isnt recalling exactly what the use-case was for scriptSig matching, but you now can no longer do that 19:49:38 BlueMatt: true, once confirmed 19:49:52 Chris_St1: I think it would be really ill-advices to add a blocker for 0.13.1 19:49:52 Chris_St1: the former 19:49:53 BlueMatt: I take back that comment 19:50:21 anyway, we can agree that anything fixing this is non-consensus, right? therefore it's not relevant for 0.13.1 19:50:24 BlueMatt: I carefully went through the code base of some three different wallets to confirm there were no complications there. Of course, it also does nothing to _existing_ software. 19:50:48 gmaxwell: i take back my comment, i no longer recall why we needed to match scriptSigs...maybe we didnt need to 19:51:03 i think there was no reason for that, indeed 19:51:07 but it is the case that you lose this property of matching pubkeys which were used 19:51:10 and if there is, we can still add it back 19:51:17 sipa: well, you might want it, but not a ton 19:51:19 which all works fine. And so even where there are things that want that data (which appear to be almost none of them), they can be accomidated later. The most common case (of not needing it) is already accomidated. And all existing things are unchanged as well. 19:51:21 I can imagine silly embedded consensus applications where it'd be useful... but supporting that is definitely not a priority 19:51:23 at this point we should be careful to only let critical problems block 0.13.1, not everything that would be nice for some applications 19:51:36 BlueMatt: Matching scriptSig constants in BIP37 right? 19:52:00 wumpus: well, if it were the case that you couldnt match properly in segwit it would be bad, but it seems that you're fine 19:52:01 BIP37 can be extended, sure 19:52:17 Chris_St1: bip37 only ever matches constants 19:52:17 but that's not yet another reason to move forward the release 19:52:28 agreed 19:52:33 topic proposal: alert system retirement 19:52:43 AFAICT the only 'utility' of that matching was degrading privacy by tainting the filter with FPs on extrainous data. :P 19:52:44 8 minutes left 19:52:47 we might fix this by throwing out bip37 and doing something not-batshit-insane, but thats an aside from the meeting 19:53:00 gmaxwell: yup 19:53:00 BlueMatt: yup. 19:53:12 I want a good fairly secure quick sync solution. BIP37 sucks :p 19:53:25 second on achow101's topic. 19:53:28 CodeShark: sure, fiber-to-the-home :) 19:53:33 But we'll do that after 0.13.1 19:53:33 #topic alert system retirement 19:53:34 gmaxwell: ack 19:54:11 Okay I sent out an email on this. Mostly well recieved (at least in public). I went and bludgenoned alt implementations into removing the alert key and only got mildly bloodied in the process. 19:54:39 gmaxwell: sounds like it's time to set dates 19:54:41 My view on the next steps: 19:54:54 (1) Create a bitcoincore.org or bitcoin.org announcement message. 19:55:16 (2) send a penulitmate alert with more polite text than the COMPROMISED message that directs people to it. 19:55:26 (3) much later, send final alert. 19:55:46 I'd say we send the final alert with the 0.14 release 19:55:57 (4) hardcode nodes to send the final alert to peers to overcome the lack of propagation. (just using the one or two lines of code needed to send a static message, not pulling back any alert code) 19:56:09 then include code in there to send it to old peers that connect, as gmaxwell says 19:56:28 gmaxwell: ACK 19:56:35 wumpus: ACK final alert with 0.14 19:56:48 ack 19:56:49 ack 19:56:51 gmaxwell: and release the privkey for the alert key w/ the final alert? 19:56:54 ack 19:57:03 I think we can do 1/2 in the next week. I'm not aware of any reason to delay, and there are propagation advantages to doing it earlier rather than later. 19:57:08 i'd release the key later even 19:57:09 gmaxwell: ack 19:57:16 make sure to sweep the funds people have sent to the key :P 19:57:26 instagibbs: ha 19:57:28 btcd still has the code in place to parse the alert messages, but we simply drop-it-like-its-hot once recv of the message without any further processing (and have since early last year) 19:57:36 sipa: ack 19:57:52 there may be alternate codebases that use the key who want to do something similar to (3) and (4) 19:58:10 oh, wait 19:58:16 they need the key for that 19:58:24 2 min 19:58:31 any pressing topics 19:58:36 well after the final alert is sent, the key is only historical curiosity 19:58:42 okay, I'll send a message to the list. 19:58:47 can the final alert match all clients? 19:59:05 luke-jr: you mean the pre-final alert, and yes 19:59:07 wumpus: yeah, once that final alert is sent, I doubt releasing the key will do any harm 19:59:14 It cann't not match all clients. 19:59:30 gmaxwell: I think he means the penultimate alert 19:59:44 obviously the final alert matches all clients, at least those that still parse alerts 20:00:00 petertodd: if I can parition your network I can make your client show "Your bitcoin is outdated and vulnerable. You MUST download an update to continue. http://bitcoinscam.eu/" 20:00:22 gmaxwell: wasn't that the point in adding it to the client? 20:00:29 I was thinking of limiting the applicability of the penultimate alert to users of Bitcoin Core, open to suggestions. 20:00:40 gmaxwell: sure, but that'll have been after months of alert - I'm not worried there 20:00:51 it applies to everyone using the key, not just users of bitcoin core 20:00:53 in any case, can continue after, we should wrap the meeting. :) 20:00:58 gmaxwell: I'd be inclined to provide it to everyone - it's a warning that everyone will soon have a final alert 20:00:59 ding ding 20:01:01 ding ding ding 20:01:02 yes it's time 20:01:03 #endmeeting