18:59:38 #startmeeting 18:59:38 Meeting started Thu Oct 8 18:59:38 2015 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:38 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:23 are we ready? 19:00:26 let's start with the action items from last time 19:00:38 I have a 'Topics to be Discussed' section in meeting minutes here: https://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv-FyneHjQellk/edit 19:00:51 and action items from last meeting are in that link too 19:00:57 yes, thanks dstadulis 19:01:19 #topic Mempool limiting 19:01:42 there seem to be some comments on the proposed reduction of chain limits 19:02:07 ok well i think we've pretty much concentrated on 6722 at this point. matt's pull. and it seems to be nice and simple. i haven't reviewed his latest changes yet though, so i don't know that we're 100% there yet 19:02:42 my mempool is 2.5G... we better get some solution! 19:02:49 We should at least mention the lowS change (and maybe small discussion on backport release schedule.) 19:02:57 gmaxwell: ack 19:03:04 gmaxwell: ack 19:03:08 have others been reviewing it? i'd like to get it merged as soon as possible after its ready 19:03:13 perhaps before next weeks meeting 19:03:23 morcos: do we have any theoretical upper limits on the iteration counts given certain chain limits? 19:03:31 morcos: I did some review of it, but not enough to say I'd ack it 19:03:37 you mean for runtime complexity sipa? 19:03:41 gmaxwell: yes, that can come later 19:03:43 morcos: yes 19:03:55 the way it works now is it just boots the first package period 19:03:56 wumpus: I just meant as a proposed agenda item. 19:04:11 morcos: because runtime performance is what drives the decision to reduce the chain limits? 19:04:19 sipa: no, not really 19:04:30 morcos: thanks on the source file tip - reading now 19:04:46 sipa: also long chains bypass fees meaning anything because the tx at the end will never go in. 19:04:49 i think run time performance is probably ok with limits as high as 100/100 19:05:25 the concern is more that with higher limits you can create degenerate sets of txs that look like high fee rate for eviction and low fee rate for mining 19:05:31 so they neither get mined or evicted 19:05:34 got it 19:05:57 to be quite honest, i'm not sure if 25/25 is safe, but perhaps this isn't the place for that discussion 19:06:02 gmaxwell: re "never go in" is that really true? 19:06:16 i think getting limits as small as we can reasonably get is important 19:06:28 petertodd: with high probablity, at least. 19:06:42 petertodd: with the current tx selection they are unlikely to go in fast, which is what matters - i think - if they don't, there's no need for them to be in the mempool yet 19:06:45 petertodd: its also important to think about what will be mined using existing code and using code that would do CPFP. CPFP would be way better, but may actually be worse at certain cases 19:07:21 sipa: right, so this is because of the current mining node, not necessarily a fundemental problem 19:07:25 we did almost all of our attack analysis assuming CPFP mining. we should probably do it again without, but i don't know what we'll be able to do about that 19:07:36 so, action item: review/test #6722? 19:07:45 yes! 19:07:46 petertodd: e.g. (CPFP example is easiest) you have a chain with 10mb of low fee transactions, and a high fee at the end. The collection has high fee rate, but no miner cares, and the tx at the end may well get doublespent first; so they never pay their fee. 19:08:01 and help try to get as low chain limits as possible pushed through 19:08:09 gmaxwell: CPFP mining would fix that, though 19:08:10 sipa: re: 'in the mempool' I'd expect most of the argument there being companies want to be "messaging" people they're sending funds too, so they see the tx immediately 19:08:27 Is the current malleability attack due to chains? Or malleability? (see http://motherboard.vice.com/read/i-broke-bitcoin) If the former, we should discuss bip62 as well. 19:08:40 *is the current mempool explosion due to malleability or chains... 19:08:41 bsm117532: yes, we will discuss that 19:08:50 gmaxwell: unless the package becomes so large that it doesn't fit in a block anymore 19:08:57 the current mempool explosion is due to a low relay rate and no mempool limiting 19:09:00 sipa: thats what I just described, 10mb. 19:09:10 gmaxwell: oh sure, but I mean, with lower limits - ie 100, 300 byte txs I'd expect to get mined reasonably fast so long as they had reasonable fees 19:09:11 gmaxwell: ugh, i need to learn to read 19:09:14 chain limited code still has very large mempools right now 19:09:16 anything else on mempool? 19:09:34 gmaxwell: total size I think matters re: "will they get mined", not # of txs, which is just a performance issue 19:10:11 petertodd: yes total size is a bigger problem than just count of txs, and there doesn't seem to be any push back on that, except to make 100 -> 101 19:10:13 bsm117532: bit62 is still fairly far off I think; low-s fixes most of the issue at least 19:10:23 yes, lows will be next topic 19:10:29 petertodd, bsm117532: anything else on mempool? 19:10:34 but count of txs is a problem on its own 19:10:36 According to the above article, the current attack is due to malleating... 19:10:44 #action review/test PR #6722 19:10:46 bsm117532: please stick to topic 19:10:47 different attack bsm 19:11:04 morcos: so I'd think a 101 size limit is fine, and then base the count of txs on measured performance with a reasonable margin (which I haven't done) 19:11:10 not just for performance reasons 19:11:24 malleating has nothing to do with mempool limiting, let's not get off topic 19:11:30 +! 19:11:36 morcos, in general i would say that the assumption should be that miners are sorting on a strict feerate basis for transactions with no dependents 19:11:44 its for the ability of the tx to look different when viewed as an ancestor package or a descendant package. the structure of the package can be more complex with more txs and thus more evil almost 19:11:45 phantomcircuit: +1 19:11:58 phantomcircuit: how hard would that be to change? 19:12:30 sipa, pretty hard to change 19:12:32 sipa: i don't think its impossible to imagine we could have CPFP mining for 0.12, but its a stretch 19:12:49 at least as a patch not long after maybe 19:12:51 phantomcircuit: if getblocktemplate would return a CPFP-aware set, isn't that enough? 19:12:58 morcos: RBF seems more likely, and it could help negate some of the cases where you want lots of txs in a row 19:13:10 sipa, you'd need to have multiple CreateBlock strategies and then decide which to use based on which has the highest total fees 19:13:20 sipa, it's significantly more effort than it initially seems 19:13:21 phantomcircuit: assume that's done 19:13:24 petertodd: it has nothing to do with RBF or using CPFP to get txs boosted in priority 19:13:32 it has to do with maximizing miners income 19:13:32 phantomcircuit: i wonder about anything outside of bitcoind 19:13:46 morcos: I mean, it helps make the argument that a smaller limit to total txchain depth is OK 19:13:55 sipa, the CPFP set aware getblocktemplate is going to have higher latency than the naive strategy for sure 19:14:31 phantomcircuit: i'm not convinced about that - i think we can do significantly better than the current GBT implementation 19:14:33 There is no reason gbt latency should have anything to do with the time CNB takes. 19:14:42 there's also the issue that mutated transaction in the chain will cause block validation and relay to take longer 19:14:52 (because the result can be precomputed and it can return an empty template if thats the best precomputation it has right now.) 19:14:54 phantomcircuit: also, CPFP indexing would happen ahead of time, so GBT would only iterate and assemble 19:14:56 anyway, improving mining is a bit far off for now. suffice it to say, i think we should consider whether there are crippling attacks with the existing mining code still possible once we have lower chain limits and 6722 merged 19:15:05 and if so, maybe we need some short term fix for them... 19:15:05 how can we make progress with mempool limiting? as sipa said, it appears to be getting quite urgent, at some point we have to make a decision about strategies 19:15:07 morcos: agree 19:15:12 morcos: +1 19:15:19 morcos: +1 19:15:35 what about those chain limits then? 19:15:39 morcos, yes 19:16:23 are there any known use cases where 25 is not enough? 19:16:31 lets work on trying to convince the people who are opposed to 25. i'd feel a lot better about 25 than 100. but can't give you a proof why its better 19:16:54 sipa, i dont believe there's any known use case for which 5 would not be enough 19:17:07 what do you think about the possiblity that some nodes have low limits and some have high 19:17:22 lets say you had a 50% chance of having 10/10 and a 50% chance of having 100/100 19:17:23 sipa: so, an interesting argument re: them, is that senders need to take into account that a receiver might respend an output, blowing up the chian limit; in short they should be able to queue txs for broadcast ontheir own 19:17:25 yeah, I think the argument was not less than 5, but that 25 is plenty. 19:17:27 as a default 19:17:42 sipa: (unless I'm completley misunderstanding this) 19:17:43 then attacks dont' cripple relay across the network if 10 nodes are immune 19:17:44 morcos: inconsistency isn't great; you waste bandwidth forwardings things that get dropped. 19:17:53 and long chains can still be relayed across the 100 nodes 19:18:13 gmaxwell: yeah, but the long chains are relatively rare 19:18:29 well rare is not an argument for not protecting against 19:18:36 ultimately you're setting yourself up for extreme vulerablity to malleability and double spend when you make long chains; so there are plenty of other factors that limit utility of long chains as well. 19:18:42 morcos: rare unless you're an attacker. 19:18:52 +1 gmaxwell 19:19:10 +1 gribble 19:19:10 A chain limit only impacts mempool, not relayed blocks, correct? (otherwise it could cause a hard fork) 19:19:11 gmaxwell: agreed 19:19:15 +1 gmaxwell 19:19:16 so, all in all, 25 ought to be enough for everyone, for now 19:19:19 bsm117532: correct 19:19:28 wumpus: ack 19:19:40 wumpus: alright, aack 19:19:40 morcos: if the driving reason for chain limits is to not make mempool selection and mining selection diverge too much... there is no real reason why the optimal value would differ between nodes 19:19:45 bsm117532: yes, see the topic "mempool behavior" 19:19:56 wumpus: i agree for sure, but maybe we should have some more ACKs on the pull then, a decent number of comments are opposed 19:20:07 If there is too much more debate on this, I'm going to begin advancing the view that we shouldn't relay transactions spending unconfirmed inputs at all. 19:20:19 sipa: diverge under attack 19:20:27 gmaxwell: long run I have a lot of symapthy for that view 19:20:29 morcos: that's the only thing that matters :) 19:20:36 morcos: do they mention an actual application? 19:20:48 i'm just saying its ok if we sacrifice half the nodes in an attack.. :) 19:20:54 lets just all take homework to go look. 19:20:58 yea with regards to long chains of unconfirmed, i'm ok to pre-split large coin chunks into small.. i feel other service operators can also mod their systems to accommodate this requirement. Kinda sucks, but whatever. it's not too difficult to mitigate 19:21:13 ok, next topic? 19:21:16 wumpus: sort of, i didn't follow exactly 19:21:19 ack 19:21:20 #topic LowS deployment 19:21:23 gmaxwell, I've yet to hear anybody articulate a strong reason for using unconfirmed inputs at all 19:21:40 phantomcircuit: it just makes using a default node "easier" for someone with high activity 19:21:42 Who is tracking the current topic? 19:21:44 that is all i can tell from personal experience 19:21:52 warren: lightningbot` 19:21:52 Minor OT notice: This issue https://github.com/feross/buffer/pull/81 has made most JS bitcoin software vulnerable to generating incorrect public keys. 19:21:57 wumpus: is there anything stopping us rolling a release almost immediately? 19:22:14 btcdrak: no, we could do a 0.10.3 and 0.11.1 now 19:22:17 Topics listed here: https://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv-FyneHjQellk/edit 19:22:28 and lightningbot` 19:22:31 LowS deployment. We've merged the change that makes lowS a standarness requirement. I believe this completely eliminates third party malleability annoyance attacks. 19:22:34 wumpus: then I think we should release it. 19:22:38 (obviously miners can still malleate) 19:22:52 wumpus: a release sounds fine to me 19:23:00 Measurements show 95% of transactions already conforming; and thats before I went and got several more things to fix themselves (including electrum). 19:23:14 a release now and then another in a couple of weeks for soft-fork 19:23:17 ? 19:23:21 right, this is about pull #6769 19:23:22 morcos: or for mempool limiting... 19:23:23 morcos: that's fine by me 19:23:24 morcos: sure, why not 19:23:26 (and its backports) 19:23:32 several people are also running https://github.com/TheBlueMatt/bitcoin/tree/seed, which malleates to low-s on mainnet 19:23:36 i think both mempool limit and malleability are very short term concerns 19:23:37 to counter the guy malleating everything 19:23:57 BlueMatt: +1 19:24:05 sipa: mempool limiting is not easily backportable 19:24:09 BlueMatt: I'll get one spun up then 19:24:22 morcos: good point - and also much more likely to need fixes post merge 19:24:28 Wumpus backported the change to older versions and we need to decide when to deploy. If we release now we stop the attacks sooner which will make people happier. Though it might be polite to slow roll somewhat due to giving the stragglers time to upgrade. At the same time upgrades take time and as matt just mentioned there is a compatiblity hack that prevents jamming. 19:24:39 BlueMatt: LOL that's hilarious :) 19:25:11 yes, mempool limiting is riskier, whereas the LowS change is straightforward (it was already in the code, it just needed to be made standard), if we want a fast release, then we should postpone that for later 19:25:28 and mempool limiting can be handled by just increasing the minimum relay fee too 19:25:30 i'm all for a release, but i think it should include CLTV 19:25:30 I'm not as concerned with low-s 19:25:45 So questions are: how comfortable are we with potentially causing blocking of up to 5% of transactions for a short window while people upgrade. 19:25:46 I don we can handle a decent % of nodes dropping offline 19:25:56 morcos: still not enough reviewers on the backports for CLTV 19:26:00 er, I don't see any reason why we can't handle a decent % of nodes dropping offline, at least temporarily 19:26:01 possibly the lows change should be backported and we do minor releases for backported versions but not a new major release? 19:26:07 If we do a backport we could increment min relay fee. 19:26:09 gmaxwell: I would be, if we had auto-malleating-to-standard nodes up all over the place 19:26:10 petertodd: wallets, not nodes... 19:26:18 phantomcircuit: it's been backported, and right thats possible. 19:26:22 sipa: I mean re: mempool limiting 19:26:23 gmaxwell: +1 19:26:27 coupling with CLTV would be possible, although the deadline for that that was scheduled together with CSV for end of this month 19:26:33 sipa: like, upping minrelay fee quicly stops the attack 19:26:38 gmaxwell: I'm not a fan at all of rolling out low-s limits today 19:26:45 we can get it on a miner or two 19:26:48 to make the attack harder 19:26:50 BlueMatt: why? 19:26:54 but rolling it out on the network....ehhhhh 19:27:10 also not sure we want to couple it with softforks, to avoid confusion between mempool policy changes and softforks 19:27:18 BlueMatt: the attack is so bad it knocked out 1000 nodes 19:27:19 wumpus: ack 19:27:22 BlueMatt: Yes, another option is to just get some miners on it... has basically optimal behavior. esp as it will allow the l[Dto-ow-S malleators to do their thing. 19:27:34 btcdrak: low-s didnt nock off nodes, mempool size did 19:27:55 fair 19:28:01 btcdrak: people on reddit are totally confused and have mixed up the lowS stuff with the mempool flooding stuff. They're unrelated technically. 19:28:02 again, let's not confuse mempool size with LowS/malleating 19:28:03 gmaxwell: yea, maybe we should be convincing miners to do low-s malleating 19:28:28 btw, its not really fair to call this mempool stuffing an attack right? 19:28:32 BlueMatt: lowS enforcement is very easy to use, as the code has been around forever and requires only a trivial patch to activate it. 19:28:33 aren't these all good txs 19:28:43 they seem to mostly reduce the utxo 100->1 19:28:56 morcos: oh? lol 19:29:10 technically this new attack was all 'legit' transactions with over 1 satoshi per byte 19:29:13 morcos: not sure in this case; I'd _assumed_ they were being created with the specific goal of knocking out nodes. 19:29:16 but there was just "so many" of them... 19:29:36 it's like ddos 19:29:45 morcos, it's clearly an attack, but yes it should shrink the utxo set 19:29:56 But it's hard to sort out people cheering about the effects vs the intent. Doesn't really matter what it "is", all that matters is what it does. :) 19:30:07 whether it's an attack or not, we need mempool limiting to protect against it (but that was last topic) 19:30:12 ^ +1 19:30:16 yup 19:30:18 In any case, is there anything more to say about lowS ? I'll go get miners to run at least lowS enforcement. 19:30:32 so, deploy new 0.10 and 0.11 release asap? 19:30:34 gmaxwell: I'd prefer they do malleation 19:30:42 wumpus: ehhhh, I'd prefer not 19:30:44 And we'll not rush a release on that, but lowS enforcement will go out with whatever goes out next? 19:30:50 yea 19:31:02 gmaxwell: miners doing just lowS enforcement doesnt help 19:31:04 BlueMatt: After you insisted to me that I don't need to review that code... ? :P 19:31:05 'whatever goes out next' will be CSV and CLTV softforks likely 19:31:07 of the wallet software that is presumed not to produce lows... does it deal well with malleation? 19:31:08 if a tx is malleated, now they just dont mine it 19:31:16 BlueMatt: it does, when coupled with other people doing lowS malleation. 19:31:17 so that will couple it to softfork minor releases 19:31:18 gmaxwell: well now I'm changing my tune since I think it may be a good solution 19:31:29 gmaxwell: but only if they're direct peers 19:31:31 sipa, no that's the only reason there's a problem to start with 19:32:04 sipa: there isnt much we can do there :( 19:32:06 well... what is worst to them? no confirmation, or malleated confrm? 19:32:09 which is ok with me, but as I said above it may confuse people to combine softfork backports with high-porfile other (non forking) changes 19:32:11 BlueMatt: Getting people to run unreleased code is a challenge, esp if its non-trivial. 19:32:37 gmaxwell: I'm aware 19:32:43 gmaxwell: they can run it on their border nodes, however 19:32:47 no need to run it on your mining node 19:32:58 wumpus: I think at least its similar in kind, in that its a standardness change. 19:33:02 but ok - no one in favor of doing releases for lows enforcements, so that's off the map 19:33:08 sipa: my point is, if miners are only enforcing lowS and not changing it themselves, it is malleated 19:33:19 BlueMatt: i don't understand? 19:33:21 assuming someone is attacking everything, then it just means delayed + malleated confirms 19:33:23 gmaxwell: consensus changes are IMO completely different from standardness changes 19:33:40 wumpus: I think we can get 95% of the benefit of a short lowS release via a mix of asking a few miners to apply local fixes. 19:34:05 sipa: if someone is attacking and malleates a tx to highS all over the network, miners who are enforcing will reject it and not hear about the lowS version 19:34:08 BlueMatt: it means people running updated software (95% of transactions) become largely protected. 19:34:09 others will take it and mine it 19:34:26 I agree with BlueMatt, miners should be fixing the transactions as well, it solves a lot of the disruption. 19:34:26 gmaxwell: nope 19:34:40 please stop. The code to go and rewrite transactions is not trivial. 19:34:43 gmaxwell: only if the miners have a peer with someone who knows the lowS version 19:35:15 that's true...ok, well at a minimum miners who are doing highS should have 1 border node that does rewriting 19:35:19 BlueMatt: sure. I don't think this is a huge assumption. Esp assuming the existance of some small amount of lowS converter nodes. 19:35:20 or should addnode my node that does it 19:35:22 or something 19:35:24 i don't think that highs->lows would be hard to add as a patch to mempool acceptance 19:35:27 Sure sure, I can suggest that. 19:35:27 gmaxwell: i have to admit i don't understand how a few miners running lowS enforcement solves the problem 19:35:41 what about the rest of the miners? 19:35:58 morcos: it doesnt solve it, but means you're proportionally less likely to suffer it 19:36:04 yeah ok 19:36:15 morcos: thats the 'largely'. A 'few miners' may mean 75% of the hashpower. 19:36:27 the attack is also not so interesting when its much less effective. 19:36:32 A better solution is not to relay highS transactions, no? 19:36:43 And even the remaining hashpower will often hear the lowS first. 19:36:44 gmaxwell: bitcoin-seednode.bluematt.me has reasonable relay/maxconnections capacity and is running it 19:36:53 bsm117532: Git master already does this. 19:37:14 gmaxwell, it would be just as or more effective to do minor releases of the backported lows change 19:37:24 bsm117532: that is the code that is currently merged in 0.10, 0.11, and master (pull #6769) 19:37:35 I was suggesting to do a release with that, but people haev other plans 19:37:42 bsm117532: As to backports that will eventually become subsiquent releases. But that alone is not sufficient because it will still block ~5% of all transactions (at this moment), and because it is not in a release version. 19:38:05 i dont see any reason to try to target miners 19:38:13 wumpus: were there objections to releasing that as is? 19:38:15 I think doing a release that just does that might be okay, but since nodes are actually going offline due to mempool stuff I feel like it's missing the forrest for the trees. 19:38:20 that's just going to confuse people when their transactions aren't mined 19:38:22 btcdrak: yes, at least from BlueMatt and gmaxwell 19:38:36 if they're rejected by a node they relay to at least maybe they'll figure it out 19:38:50 I prefer clarity too phantomcircuit 19:39:11 wumpus: I am not opposed. I do not think it is essential right now. And I am somewhat concerned about update exhaustion with what might end up being three mandatory updates in short succession. 19:39:22 phantomcircuit: yes, that is why I was saying it must be coupled with each miner who is doing it running a malleate-to-low-s node somewhere so that they dont just reject 19:39:24 but also mine them 19:39:30 phantomcircuit: in practice that isn't how much software works. 19:39:31 gmaxwell: people can decide for themselves whether to update or not 19:39:33 how about we do backports in the stable branches, but don't release, and instead ask around and look whether the highS wallets on the network goes down? 19:39:51 sipa: we can no longer measure it due to attacks. 19:39:52 oh... i guess with a ->highS malleation going on, that's harder to observe 19:39:54 right 19:39:58 it is already backported to the stable branches 19:40:11 the only thing that has to be done is stage a relase (or not) 19:40:47 gmaxwell: I dont think users are going to object to seeing more frequent security/maintenance releases. If anything it would be good PR 19:40:56 i'd vote for doing one release before 12, with lowS enforcement, increased min relay fee and CLTV soft fork 19:41:03 any other topics? 19:41:04 ### TIMECHECK 66% through the meeting 19:41:22 My preference is along the lines of what morcos suggests. 19:41:31 (actually, exactly what he suggests) 19:41:38 I dont disagree, just suggesting that we not rush into it 19:41:43 ok - target for the releases on 0.10.x and 0.11.x is end of this month then 19:41:46 and a little more delay does give more time for other things to updat.e 19:41:55 along those lines, I just rebased all the CLTV branches 19:42:01 then see whether CLTV and CSV make it in 19:42:04 wumpus: Next topics: CLTV backport reviews and CSV reviews 19:42:06 as proposed last week 19:42:18 Basically there are wallet vendors who totally missed the first generation attacks, and the bip62 discussion, and "hey you need to lowS" was news to them.. 19:42:45 well i have to say i'm a NACK on CSV for release this month. i just don't think they are settled and ready enough. 19:42:59 maaku, were you considering changing the semantics to save more bits? 19:43:07 #topic CLTV backport reviews and CSV reviews 19:43:11 morcos: I was just reviewing the code today, and it struck me that there isn't even clarity on what everything looks like when all three pull-reqs are merged 19:43:39 I also think CSV is quite risky to deploy on such short notice 19:43:47 petertodd: yeah agreed with that too. and the bug sdaftuar found was actually just an assumption of what would be a bug when the soft fork pulls were created, which don't exist yet 19:43:57 I am concerned that the CLTV sequence restriction violations are currently not quite non-standard. (unless I've missed something) 19:43:57 we can do mempool-only CSV/sequence 19:43:58 morcos: there are loads of bits free, set the MSB and remaining 31 bits are free. 19:44:07 er CSV! 19:44:09 (not CLTV) 19:44:19 (sorry, autopilot) 19:44:36 but there are not loads of bits free if you want to keep the CSV and nSequence meaning and yet use some more of the bits for another soft fork 19:44:37 sipa: sure, but there's no reason to do that in an intermediate minor release 19:44:41 it uses more than it needs to 19:44:52 gmaxwell: it requires increased tx version 19:44:53 sipa: I'm all for mempool only CSV in say, master, when it's ready to merge 19:45:04 gmaxwell: sequence restriction violations? 19:45:06 i think the semantics should change 19:45:07 we followed the same for CLTV 19:45:09 morcos: oh derp! there we go, sorry. 19:45:40 (I did know that... had just forgotten the implication) 19:45:41 afaik it's worst-case half the bits available? 19:45:41 ok - so CSV semantics are n't even finalized yet? 19:45:42 gmaxwell: OP_CLTV is itself non-standard, so any tx using that behavior at all will immediately be dropped 19:45:52 wumpus: I would say no, IMO 19:45:56 petertodd: I know, I autotyped that. :P 19:45:57 no 19:45:58 indeed, softfork deploymment aside, we can get the mempool PRs for CSV merged. 19:46:21 wumpus: i think the current proposal is final by the author... things can change if there are concerns of course 19:46:21 last i talked to maaku i believe he wanted to change the semantics 19:46:25 morcos: ? 19:46:32 morcos: afaik that's long done 19:46:44 btcdrak: well... I'm not sure that's a good thing, because it'd make changing those semantics later tricky - CLTV had the same issue, and the plan was we'd pick a new opcode if that happened 19:46:50 morcos: I'm not sure he did want to change, he was just taking on board what you were saying. 19:47:05 he and i discussed on IRC the other day, and he had thought it was a soft fork to change time resolution from 1s to 512s for instance and not the other way around 19:47:08 sorry, I need to go :( 19:47:16 btcdrak: i agree it wasn't 100% clear 19:47:25 meeting only has 15 minutes to go 19:47:28 okay, so the takeaway is that this needs to get clarified. 19:47:31 CSV can similarly use a different opcode, half the bits with nSequence? 19:48:09 CSV is a different opcode... 19:48:10 i think its really close to good, but it just seems a bit odd to me to use 25 bits for time, when we might want to save those for something else later. 19:48:11 GreenIsMyPepper: more complex than that, txver=2, msb not set, then the remaining bits are used according to bip68, otherwise all bits are free 19:48:12 GreenIsMyPepper: CSV has an additional constraint, becuase it is both the nlocktime and the checklocktime parts that we're discussing. 19:48:26 morcos: ok, let's get maaku to clarify this week 19:48:34 We cannot simply 'use another optcode' to change the nSequence interpertation. 19:48:36 also we should all chime in on what we think 19:48:40 yes, i mean the nSequence part is more restrained, but the impact w/r/t CSV is similar to CLTV 19:48:55 GreenIsMyPepper: yes, other than the sequence part, the two are almost the same. 19:49:11 if we can save 14 bits of nSequence for further soft forks regardles of time/block sequence type, that seems great 19:49:12 ok 19:49:27 I know a number of people are still making their way through the locktime PRs (3 of them), so we'll get more feedback this week. 19:49:38 GreenIsMyPepper: More review efforts from you on CSV would be super helpful. 19:49:47 for reference the PRs are as follows 19:49:52 Mempool-only sequence number constraint verification https://github.com/bitcoin/bitcoin/pull/6312 19:49:52 Mempool-only CHECKSEQUENCEVERIFY https://github.com/bitcoin/bitcoin/pull/6564 19:49:52 Mempool-only Median time-past as endpoint for lock-time calculations https://github.com/bitcoin/bitcoin/pull/6566 19:49:58 gmaxwell: ok i've been taking a look yesterday 19:50:05 btcdrak: thanks 19:50:08 GreenIsMyPepper: K. 19:50:57 Can we put my "Minor OT notice" from earlier in the notes. This is an ecosystem threat with the potential to cause millions of dollars in losses that needs higher visibility; though it's not a bitcoin core / bitcoin network issue. 19:51:05 ok, any other topics to discuss? 19:51:09 gmaxwell will do 19:51:25 we can make it the topic gmaxwell 19:51:35 jgarzik isn't here i guess 19:51:46 i'd like to make it clear who exactly are the moderators for the mailing lists 19:51:52 and then i can hound them 19:51:56 if there's more to discuss about it 19:52:01 ping warren: 19:52:12 b/c i know there is not another list yet, but there is some stuff that is inapproiate for any list happening 19:52:27 warren: has a meeting with LF today btw for the new list. 19:52:29 i'm this clsoe to unsubscribing myself 19:52:43 wumpus: I think htere is nothing more to discuss. Common, critical, JS code is broken that may cause the generation of incorrect pubkeys (among other issues). Anyone who cares for a JS implementation should read that PR. 19:52:47 Had a call with them this morning. The plan is now: 19:52:52 1) create bitcoin-discuss list 19:52:53 morcos: warren assures we'll have the new list this week. 19:53:03 morcos: +1 19:53:04 2) we need to decide who are moderators for that and bitcoin-dev list 19:53:17 #topic bitcoin-discuss mailing list 19:53:48 gmaxwell: ok, clear 19:53:57 3) They will also host a new domain name with a static web page simply listing all the lists, list policies and whatever other material we put there. We maintain it in github somewhere with pull requests and they'll auto-publish whatever is signed with certain GPG sigs. 19:54:57 Previously discussed moderators was jgarzik, elombrozo, johnathan, btcdrak, are we still good with this list? 19:55:04 thanks for letting us know warren 19:55:29 Mailman 2 has the drawback of a shared password for moderators, this will become better in ~6 months when they upgrade to Mailman 3 where each user has their own password. 19:55:54 sounds good to me 19:56:00 Should be OK to allow more moderators. We probably should agree on a moderation policy where mod actions identify who did it, otherwise there's no transparency? 19:56:08 has there been general guidelines on what will be ontopic on bitcoin-discuss? is economics-politics ontopic for instance? 19:56:25 I nominate GreenIsMyPepper as another moderator. 19:56:39 warren: it's important moderators act with one voice. If mod A bans user B, then mod C should not undo that unilaterally 19:56:56 how about we have a separate meeting to discuss the list and moderation policy 19:57:02 don't need to spend time here 19:57:13 this meeting is about to end 19:57:18 warren: agreed. 19:57:30 who else should be moderator? 19:57:50