18:59:59 #startmeeting 18:59:59 Meeting started Thu Mar 10 18:59:59 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:03 topics? 19:00:23 here 19:01:05 we have a list of remaining segwit items that were written on whiteboard at MIT... should we assign those? 19:01:16 sure 19:01:18 * sipa hides 19:01:25 * btcdrak locked the door 19:01:44 #topic remaining segwit items 19:01:56 I'm happy to help,... probably in the wallet section. 19:02:05 seems to me it would nice to buckle down and prioritize BIP 9, BIPs 68,112,113 , segwit. i mean i think we are all working on those things, but there is still more to do on all of them 19:02:06 my plan was to rebase segwit on top of bip9, add the rewind logic to continie after post-softfork uograde, and do a new testnet 19:02:10 eh, new segnet 19:02:21 great 19:02:33 when do you think to deploy the new testnet? 19:02:40 we also need to discuss standardness rules 19:02:50 (or rather, propose and discuss) 19:02:55 What was decided for safety on the edge of the rule change in case of reorg? 19:03:45 I think my suggestion would be to push that problem to wallet users 19:03:49 warren: i believe we decided to advise wallet authors to wait some time after segwit activates before using 19:03:51 one possibility is not enabling relay/mempool logic for segwit transactions until 2 period after activatation 19:03:56 yes authors i meant 19:04:04 warren: I don't understand the context of your question. Generall new soft fork rules should not be used immediately. 19:04:14 another is to just be cautious and nit enable the functionality in wallets until a post segwit release 19:04:15 gmaxwell: this one is more dangerous than usual though 19:04:24 sdaftuar: it's just like p2sh. 19:04:29 OK, that seems adequate enough. 19:04:42 I'm not that concerned about edge case reorg situations 19:04:55 gmaxwell: its a bit riskier than p2sh... don't need a preimage 19:04:55 it's not situation*s* 19:05:08 in core I would recommend that we would switch to using segwit as default in a subsiquent release after the SF activates. 19:05:40 so have it ready and auto-use it whiteout creating another release? 19:06:00 so in any case, i think we just advise wallet authors to wait some minimum amount of time after activation to send segwit txs.. they are already going to have to put in some code to wait until it activates 19:06:00 *without 19:06:01 either wait until next release - or wait a few blocks after activation before enabling it in wallet 19:06:11 ok 19:06:43 auto-enable in in the wallet after 95%? 19:06:47 no. 19:06:57 I think better to wait a release code afterwards 19:06:58 not even at 100% 19:07:19 Okay. Then do it over the release-cycle.. 19:07:31 I recommend using a release. Automatic behavior is not needed here. Also-- it's a pretty big behavioral change to use it, e.g. you'd be issuing other address styles in response. 19:07:43 Agree. 19:07:48 also we haven't written that code yet anyway 19:07:52 that is an open question 19:07:53 I just think there is a hight incentive to use it (fees) 19:07:54 this is something that can be decided once segwit has already been deployed and is awaiting activation 19:07:56 having that triggered by invisible-to-the-user network behavior isn't reat. 19:08:16 great* 19:08:31 i wish we had an address style for segwit part of the standard :( 19:09:10 sipa: no you don't. Deploying a new address style takes forever. :P what you wish for is a magic wand. 19:09:15 sipa I thought we did? BIP142? 19:09:37 btcdrak: we haven't been pushing it because of concerns regarding scary "new addresses" 19:09:41 P2WPKH? 19:09:53 i think we have more buy-in from wallet authors about segwit now, than p2sh had at the timr 19:09:54 i think we should do that though, otherwise everyone is going to embed them in p2sh which is kind of silly 19:10:22 p2sh was almost entirely under the radar as far as the community at large 19:10:24 also, continued use of base58 is awful. I am going to refuse to discuss address encodings with anyone who hasn't read an address to me over the phone. :) 19:10:48 CodeShark: I would suggest brining it back. There's no problem. 19:10:57 CodeShark: thats not the case; besides there is a material difference in the sheer mass of code that must be updated. Besides why is this being discussed there. 19:11:02 btcdrak: there sort of is a problem still... 19:11:06 btcdrak: I oppose it in the strongest possible terms. 19:11:08 both internal and external 19:11:22 CodeShark: you can change you mind :) 19:11:33 internally some people hate base58, externally some people are still grandstanding with the "segwit is too hard" crap 19:11:56 gmaxwell: there is certain value in user expectations of things that look like base58 19:12:13 I think it's a battle not worth fighting right now 19:12:18 +1 19:12:22 +1 19:12:24 gmaxwell: whats your number 19:12:29 haha 19:12:31 BlueMatt: You are on subject-matter-ignore until you call me and successfully read me a base58 address. :) 19:13:04 i would really like to have some psegwit afdressddress as part of the "package" 19:13:10 morcos: PM :P 19:13:40 gmaxwell: I'm not suggesting I'm necessarily in support of base58 addresses, but my point is that it is not up to us here to figure out addressing for segwit...that is something WALLETS need to be involved in...people who actually have some ux experience, which does not exist here 19:14:16 gmaxwell: BlueMatt says "..." 19:14:17 yes indeed. but thats also why taking on a new address type at the same time is not a good idea, it would get in the way of that kind of collaboration. 19:14:22 hahha 19:14:30 agreed 19:14:30 do you think so? 19:14:37 i think it's the opposite 19:14:46 I think the idea of pushing off address types for segwit for broader feedback is a good thing 19:14:47 sipa: that was a lot of backspaces. 19:15:07 good UI design wouldn't even burden users with having to deal with copy/pasting cryptographic keys 19:15:20 but that's an entirely separate discussion 19:15:28 FWIW, I've been thinking of implementing the payment protocol better in Core 19:15:37 including the new BIP 75 stuff 19:15:39 We are far away from designing the UX... this is a topic we can talk about in 2-3 years. 19:16:33 :) 19:16:42 ok, let's postpone that address discussion 19:16:42 But sipa: is the P2WPKH address type not okay?,.. addresses like "p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm"? 19:16:53 jonasschnelli: you mean bip142? 19:17:08 Yes. Easy to handle by existing wallets? 19:17:17 jonasschnelli: ACK 19:17:24 sipa was raising the concern that if something weren't done sooner we'd be left stuck with 80 bit security forever, I reminded him in PM that we have an upcoming checksig improvement to reduce transaction sizes by 30% which would be a nice time to do a new address type too. :) 19:17:42 would be good to have concrete proposals for address formats ,say as BIPs 19:17:50 we'll have plenty of opportunities to introduce new stuff in the future 19:18:00 right now we should focus on the path of least resistance 19:18:14 the reason against incorporating bip142 is people yelling "see! sehwit needs new address types! everyone has to upgrade! not backward compatible!" 19:18:17 The amount going on right now is too great to be able to afford forced seralization. 19:18:27 eventually my hope is we'll actually have a competent ecosystem that can actually do tech 19:18:36 but for now we must deal with what we have 19:18:40 Yeah I think it would make a lot of sense to release just the P2WPKH address 19:18:44 sipa: we could add sending support, and discourage anyone from using it to receive for now 19:18:45 sipa: You could still uses it over P2SH... but we don't live for the critics. 19:18:56 sipa: don't you think everyone is going to say that even more if we don't have address types 19:19:12 i don't know 19:19:20 i'm an engineer, not a marketer 19:19:31 +1 for P2WPKH bip142 19:19:43 shouldn't be expected from you to act as marketeer sipa 19:19:47 you have enough on your plate 19:19:51 next topic? 19:19:59 yes please 19:20:07 suggestions? 19:20:23 (I don't see value in p2wpkh, but let's move on) 19:21:14 ok, if not, that was a quick meeting 19:21:28 there were many things last week that got cut off. 19:21:29 (I'm still too tired and jetlaggy to contribute much now) 19:21:38 If no one has something important... what do you think about my approach of IBD with a pregenerated signed UTXOset? 19:21:57 Can I ask people to review the backport PRs for BIP68 and 112? They were straight cherry-picks into 0.12 but they do need a couple eyes on them. 19:22:10 jonasschnelli: i think thats a bad idea 19:22:11 jonasschnelli: sounds like a waste of time at best, to be frank. :x 19:22:23 #action review backport PRs for BIP68 and 112 19:22:33 jonasschnelli: core devs (or anybody for that matter) should not be authorizing the state of the ledger at any time 19:22:40 #topic IBD with a pregenerated signed UTXOse 19:22:52 it's risky, it brings trust into the system 19:22:56 much prefer to see SPV mode until IBD completes 19:23:15 Luke-Jr: Yes. Agree. 19:23:19 who would you trust to sign something like that? 19:23:30 Bob. 19:23:32 Just thought we might want to reduce the amount of block-serving even more. 19:23:36 yes, definitely Bob 19:23:38 XD 19:23:52 wumpus: could be signed by the same users/devs who are signing the gitian builds. 19:24:00 jonasschnelli: that's not reducing block serving; it's changing the trust model instead 19:24:22 I agree. It does change the trust model. 19:24:24 jonasschnelli: hmm don't put too much on their shoulders 19:24:27 without TXO commitments it's unfixable 19:24:31 :p 19:24:35 if we go back to the backport question, we also need to backport all these SF's to 0.11 is that correct? 19:24:55 Okay... so. Then let me not implement it. :) 19:25:01 yea, UTXO commitments would make this somewhat more realistic, although it'd still reduce the overall trust model to SPV 19:25:21 jonasschnelli: yes, better not for now I think 19:25:28 #topic backports to 0.11 19:25:33 morcos: I was thinking about this this morning. The normal release cadance would have us do so, I believe. 19:25:42 SPV during IBD and a throttled(CPU) IBD is the better approach. 19:26:03 jonasschnelli: yes, definitely those would be good to have 19:26:07 how practical is it to backport to 0.10? 19:26:14 why 0.10? 19:26:20 topic is backport to 0.11 Luke-Jr :p 19:26:20 0.10 and 0.11 are close 19:26:22 0.10? i'd hoped you guys would be willing to skip 0.11 19:26:29 but agree; just 0.11 19:26:32 morcos: I would skip 0.11 19:26:38 we have a published release schedule, no? 19:26:51 I think backporting to 0.11 is fairly necessary, that's only one release back 19:26:51 sipa: of guaranteed support, not limited-to 19:27:07 0.11 is necessary; 0.10 would be ideal 19:27:09 wumpus: i suppose, i'm worried about how well tested these major changes will be 19:27:20 master, 0.12, 0.11 19:27:21 but I'll deal with 0.10 later I guess 19:27:24 0.10 is not necessary... we once agree in supporting only two major versions. 19:27:28 sipa: our lifecycle doc is at https://bitcoincore.org/en/lifecycle/ 19:28:00 jonasschnelli: it was never agreed to drop support for older ones, only to not promise support for them; but that's on me for 0.10 I think 19:28:05 morcos: it's a challenge, but I think you can't get around it, some people won't be ready yet to upgrade to 0.12 19:28:06 the backports to 0.12 are trivial, but 0.11 will be a little more annoying, especially for BIP68 I believe 19:29:03 btcdrak: we should just backport them kind of altogether right? 19:29:10 btw the backports for BIP68,112 are #7543 and #7544, I forgot to mention the numbers earlier 19:29:14 i suppose they don't overlap that much 19:29:31 i think i can make sure BIP68 for 0.11 backports properly 19:30:02 morcos: you'd be the best person to backport BIP68 to 0.11. 19:30:10 i will take the approach of not keeping the mempool consistent and checking sequence values in the mining code, which will probably not make much of an effect on the already absurdly slow mining code 19:30:30 thats why 7187 was separate, that won't be backported to 0.11 19:30:42 morcos: plenty miners have upgraded to 0.12 fwiw 19:30:51 well pools* 19:31:26 ok. i'll work on that 19:31:33 the other path would be to wait for 0.13, then only backport to 0.12, but then you'll have to wait 6 months :p 19:31:50 >_< 19:31:55 wumpus: nice joke there :-P 19:31:58 well not exactly 6 anymore but ok... 19:32:14 I don't think it's realistic no 19:32:39 i think we can do 9/68/112/113 soon 19:32:49 aim for 0.13 would be july 19:33:04 sipa: agreed! 19:33:14 sipa: I hope so! 19:33:16 sipa: I also believe so. 68/112/113 are done from my side, morcos wants to add more RPC tests which is fine. 19:33:22 did you ever reply to my comment on block version = 4 19:33:29 btcdrak: there are NONE! 19:33:43 any plans to remove the default version crap out of primitives? 19:33:50 morcos: yes there are. same standard as for BIP65 19:33:54 CodeShark: yes, see bip9 19:34:12 morcos: it was needed in combination with the warning logic 19:34:18 morcos: see #7648 19:34:20 it may not be needed anymore with imoroved logic 19:34:36 btcdrak: i saw, and i agree, BIP65 made it out withotu adequate tests 19:35:05 sipa: right now #7575 will revert back to version 4 blocks after the first soft fork activates, if no other soft forks are in the queue 19:35:06 bip65 had rpc tests from petertodd?! 19:35:13 i assume that is unintentional? 19:35:18 morcos: I would disagree they were not adaquet, you can always have more sure. 19:35:26 bip65 had RPC tests. 19:35:29 sdaftuar: that seems correct to mr 19:35:39 oh, i didn't realize that! 19:35:50 sipa: huh? correct as in you wanted that? 19:36:03 the old version is used to indicate "no versionbits" 19:36:04 bip68/112/113 have the p2p RPC tests in #7648 19:36:30 morcos: yes, otherwise the version is ambiguous based on what software miners use, ignoring deploymemts 19:36:37 which the warning logic can't deal with 19:36:55 it must be absolute "these deployments -> this nVersion" 19:37:05 sipa: all prior soft forks required minors to upgrade 19:37:14 miners :p 19:37:19 lol 19:37:25 minors can always get a fake ID 19:37:27 sipa: what i would like to do is with this first soft fork, require nVersion > 4 19:37:44 why? 19:37:50 morcos: why? 19:37:51 then we can warn on anything that is not 001... unless it is <=4 which we know are invalid 19:38:00 that seems consistent with how we've done other soft forks 19:38:10 there is an expected version number, unknown differences are warned on 19:38:24 so old software versions warn. 19:38:34 and continue warning. 19:38:50 gmaxwell: yes, old software versions are incapable of noticing transient changes 19:39:06 thats why we need to rework alerts/warning to correctly identify them now 19:39:25 in fact if you turned off a 0.12 node for a couple months 19:39:34 and then turned it back on after all these SF's activated 19:39:36 you would have no idea 19:39:43 even if you looked at your debug logs 19:39:49 b/c the warning logic doesn't run in IBD 19:40:08 i feel like that makes it a requirement that we permanently increase the version number 19:40:24 agreed 19:40:51 wth are you talking about? 19:40:56 who? 19:41:01 I don't follow 19:41:03 me? which part? 19:41:09 versionbits is deterministic based on the chain histotu 19:41:18 yes 0.12 doesn't have version bits 19:41:20 0.12.0 19:41:25 after versionbits deployment, all block versions would be > 4 19:41:26 ah 19:41:28 sipa: he's talking about software which doesn't have versionbits. 19:41:32 oh, now i get it 19:41:37 sorry 19:41:43 CodeShark: thats what i'm trying to say, thats not how its written 19:42:17 so increase to 5 after the first vb deployment? 19:42:23 no no no 19:42:23 why not increase to 001...? 19:42:24 not 5 19:42:33 consensus rule is >= 5 i guess 19:42:39 just > 4, but you expect to see 001 19:43:03 consensus >=4, but by default set 001...000....? 19:43:16 >4 19:43:18 yes 19:43:57 morcos: but you should see it in the debug log? https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2464 19:44:13 Agree that we should also warn in IDB (but low prio IMO). 19:44:14 jonasschnelli: that code doesn't run during initialblockdownload 19:44:35 the assumption is if you see something that starts with 001 you think you know whats happening and you're unknown activation detector can alert you with specific information 19:44:51 Then lets improve that and BP. 19:44:55 and if you see soemthing that doesn't start with 001 such as a 5 or a 110... 19:45:07 jonasschnelli: thats what we're doing , but we can't retroactively change old code 19:45:29 110... would be treated as negative, no? because for some reason signed types were used 19:45:31 then you assume that someone is doing something you really don't understand 19:45:38 Yes. Sure... we might not be capable of warning for the next SF. 19:45:41 CodeShark: sure i mean 010 19:45:54 morcos: there is already 011 on the network too 19:46:24 btcdrak: exactly, and we should be warning about that (and we are now) b/c its changes our software doesn't understand 19:46:35 right 19:46:38 and if > 50/100 blocks then we turn that warning into an alert 19:47:55 Agree. But that raises also the question how to deploy an alert... debug.log? Yes. No. 19:48:08 jonasschnelli: see scroll back before meeting 19:48:29 * jonasschnelli has only a 500 lines scrollback >_< 19:48:53 sipa: so agreed that we should increase version number? should i make a new BIP for that? and we'll just soft fork it in at same time, or add to existing BIP 19:49:25 morcos: consensus or not? 19:49:53 sipa: consensus rule that nVersion must be >= 5. 19:50:25 morcos: why consensus? 19:50:31 morcos: confused 19:51:00 before or after versionbits activation? 19:51:02 still don't follow 19:51:03 sipa: well i suppose it doesn't have to be a consensus rule... 19:51:11 CodeShark: with the first SF that activates 19:51:30 sipa: but i think its more clear to me that it doesn't have problems if it is a consensus rule 19:51:36 b/c thats how the other ones worked 19:51:44 making it consensus would cause gratitious orphaning, which we were generally trying to avoid in the design of segwit. 19:51:54 gmaxwell: this will be before segwit 19:52:04 i prefer not introducing new consensus logic, especially when the only argument for it is better guarantees for warnings 19:52:33 sipa: yes thats the only difference i see. is that now we somehow can't warn on version = 4 blocks 19:52:58 and if it's not consnesus, we can say bip9 miners without active rollouts use 001000... 19:53:38 I like 001000 in that it would encourage visualization tools to parse the bitfield instead of just displaying an integer. 19:53:43 yes 19:53:50 sipa: if its not a consensus rule, you can't be SURE that old nodes will be warned that the rules have changed... perhaps thats not worth worrying about 19:54:27 miners can already cause total network forks 19:54:28 That was my initial understanding that the new version would be 00100..0 when no sfs are being deployed 19:54:28 its just cleaner to me 19:54:38 are we worried that they can bypass a warning mechanism? 19:54:50 sipa: no 19:56:51 sipa: ok i guess. i'm ok with not making it a consensus rule.. but just seems weird to me... i feel like we're transitioning from an old system to a new system, and the transition should conform to the old system 19:57:09 Lets wrap the metting now and talk more about warning after. Unless there are any other subject to squeek in at the end? 19:57:10 meeting: 3 minutes to go 19:57:17 but as long as we make the default 00100 then i think its just theoretical concerns 19:57:21 yeah 19:58:17 #endmeeting