1 2016-12-15 02:14:27	0|bitcoin-git|[13bitcoin] 15sipa pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b68685a16a81...b83264d9c7a8
  2 2016-12-15 02:14:28	0|bitcoin-git|13bitcoin/06master 1467dac4e 15Jeremy Rubin: Add unit tests for the CuckooCache...
  3 2016-12-15 02:14:28	0|bitcoin-git|13bitcoin/06master 14c9e69fb 15Jeremy Rubin: Add CuckooCache implementation and replace the sigcache map_type with it...
  4 2016-12-15 02:14:29	0|bitcoin-git|13bitcoin/06master 14b83264d 15Pieter Wuille: Merge #8895: Better SigCache Implementation...
  5 2016-12-15 04:08:22	0|bitcoin-git|[13bitcoin] 15rebroad closed pull request #9338: [wip] Stripe downloads to reduce stallers occuring (06master...06ReduceStalling) 02https://github.com/bitcoin/bitcoin/pull/9338
  6 2016-12-15 04:29:51	0|luke-jr|BIPs 2 and 123 are now Active
  7 2016-12-15 07:59:04	0|jonasschnelli|<gmaxwell:#bitcoin-core-dev> jonasschnelli: want to go comment on http://bitcoin.stackexchange.com/questions/50125/failing-to-build-bitcoin-core-v0-13-1-on-debian-stretch and point out its fixed in master
  8 2016-12-15 07:59:06	0|jonasschnelli|^ done
  9 2016-12-15 09:51:44	0|gmaxwell|I triggered some kind of hang or deadlock today on master by running bitcoin-cli stop shortly after starting bitcoind but before it had come up.  Was in a rush to fix something else so I didn't attach a debugger before killing it.   Mentioning so that if someone else encounteres it, you're not imagining it.
 10 2016-12-15 09:51:59	0|gmaxwell|will try to reproduce tomorrow.
 11 2016-12-15 10:05:31	0|gmaxwell|[OT] I was really impressed by the technical accuracy of today's SMBC, then I saw it had a co-author.
 12 2016-12-15 15:58:59	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b83264d9c7a8...5bc209c73fb6
 13 2016-12-15 15:59:00	0|bitcoin-git|13bitcoin/06master 148b15434 15Wladimir J. van der Laan: doc: Add bare-bones documentation for fuzzing
 14 2016-12-15 15:59:00	0|bitcoin-git|13bitcoin/06master 14a4153e2 15Patrick Strateman: Simple fuzzing framework
 15 2016-12-15 15:59:01	0|bitcoin-git|13bitcoin/06master 145bc209c 15Wladimir J. van der Laan: Merge #9172: Resurrect pstratem's "Simple fuzzing framework"...
 16 2016-12-15 16:01:23	0|btcdrak|wumpus: #7562 is ready for merge.
 17 2016-12-15 16:01:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/7562 | Bump transaction version default to 2 by btcdrak · Pull Request #7562 · bitcoin/bitcoin · GitHub
 18 2016-12-15 16:01:52	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9340: [0.13] Update secp256k1 subtree (060.13...06Mf1612-013subtree) 02https://github.com/bitcoin/bitcoin/pull/9340
 19 2016-12-15 16:01:54	0|wumpus|btcdrak: thanks
 20 2016-12-15 16:03:52	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5bc209c73fb6...1eef038b1bcf
 21 2016-12-15 16:03:53	0|bitcoin-git|13bitcoin/06master 141f0ca1a 15BtcDrak: Bump default transaction version to 2
 22 2016-12-15 16:03:53	0|bitcoin-git|13bitcoin/06master 14c5d746a 15Alex Morcos: tiny test fix for mempool_tests
 23 2016-12-15 16:03:54	0|bitcoin-git|13bitcoin/06master 14dab207e 15BtcDrak: Preserve tx version=1 for certain tests...
 24 2016-12-15 16:07:19	0|bitcoin-git|13bitcoin/06master 14d8c0b9f 15Russell Yanofsky: [qa] Add test for rescan feature of wallet key import RPCs...
 25 2016-12-15 16:07:19	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1eef038b1bcf...c6fd923886a3
 26 2016-12-15 16:07:20	0|bitcoin-git|13bitcoin/06master 14c6fd923 15Wladimir J. van der Laan: Merge #9331: [qa] Add test for rescan feature of wallet key import RPCs...
 27 2016-12-15 16:07:34	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9331: [qa] Add test for rescan feature of wallet key import RPCs (06master...06pr/test-import-rescan) 02https://github.com/bitcoin/bitcoin/pull/9331
 28 2016-12-15 16:47:35	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9353: Add data() method to CDataStream (06master...062016_12_cdatastream_data) 02https://github.com/bitcoin/bitcoin/pull/9353
 29 2016-12-15 17:19:28	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #9354: Make fuzzer actually test CTxOutCompressor (06master...06fixfuzz) 02https://github.com/bitcoin/bitcoin/pull/9354
 30 2016-12-15 17:32:21	0|bitcoin-git|[13bitcoin] 15hoffmabc opened pull request #9355: Add welcome script to Bitcoin Ocho (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9355
 31 2016-12-15 17:33:01	0|bitcoin-git|[13bitcoin] 15hoffmabc closed pull request #9355: Add welcome script to Bitcoin Ocho (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9355
 32 2016-12-15 17:51:03	0|wumpus|and another user banned. Fuck off with the Ocho trolling.
 33 2016-12-15 17:53:48	0|Lauda|Calm down wumpus :/
 34 2016-12-15 18:19:19	0|gmaxwell|wumpus: I believe 9313 may be ready for merge.
 35 2016-12-15 18:50:34	0|bitcoin-git|13bitcoin/06master 1401fea7a 15Alex Morcos: If we don't allow free txs, always send a fee filter
 36 2016-12-15 18:50:34	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c6fd923886a3...756374c522c4
 37 2016-12-15 18:50:35	0|bitcoin-git|13bitcoin/06master 14756374c 15Wladimir J. van der Laan: Merge #9313: If we don't allow free txs, always send a fee filter...
 38 2016-12-15 18:50:53	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9313: If we don't allow free txs, always send a fee filter (06master...06minminfee) 02https://github.com/bitcoin/bitcoin/pull/9313
 39 2016-12-15 19:00:25	0|achow101|meeting?
 40 2016-12-15 19:00:43	0|lightningbot|Meeting started Thu Dec 15 19:00:42 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 41 2016-12-15 19:00:43	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 42 2016-12-15 19:00:43	0|wumpus|#startmeeting
 43 2016-12-15 19:00:48	0|jonasschnelli|here
 44 2016-12-15 19:00:52	0|wumpus|proposed topics?
 45 2016-12-15 19:01:04	0|gmaxwell|#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
 46 2016-12-15 19:01:09	0|sdaftuar|hi
 47 2016-12-15 19:01:15	0|wumpus|+ jl2012
 48 2016-12-15 19:01:25	0|gmaxwell|I was going to talk about some backlog but almost all of it got merged.
 49 2016-12-15 19:01:29	0|instagibbs|oh right
 50 2016-12-15 19:01:45	0|cfields|sick and useless, but here
 51 2016-12-15 19:02:29	0|BlueMatt|cfields: ouch you got it now, too?
 52 2016-12-15 19:02:44	0|cfields|BlueMatt: mine was nice enough to wait until the flight home :\
 53 2016-12-15 19:02:48	0|wumpus|#9322 seems to need discussion
 54 2016-12-15 19:02:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/9322 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
 55 2016-12-15 19:02:58	0|phantomcircuit|hi
 56 2016-12-15 19:03:01	0|instagibbs|interesting issue
 57 2016-12-15 19:03:05	0|wumpus|"Don't set unknown rpcserialversion"
 58 2016-12-15 19:03:13	0|gmaxwell|#9322
 59 2016-12-15 19:03:15	0|gribble|https://github.com/bitcoin/bitcoin/issues/9322 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
 60 2016-12-15 19:03:17	0|BlueMatt|#9352 needs to move forward quickly for fibre/some current network issues
 61 2016-12-15 19:03:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/9352 | Attempt reconstruction from all compact block announcements by sdaftuar · Pull Request #9352 · bitcoin/bitcoin · GitHub
 62 2016-12-15 19:03:34	0|wumpus|looks like there is disagreement about whether it should be done at all
 63 2016-12-15 19:04:04	0|BlueMatt|wumpus: on which?
 64 2016-12-15 19:04:09	0|wumpus|the one I just mentioned
 65 2016-12-15 19:05:11	0|gmaxwell|I don't see the disagreement on 9332?
 66 2016-12-15 19:05:32	0|instagibbs|luke-jr seemingly does
 67 2016-12-15 19:05:34	0|wumpus|#9352 is 21 hours old, that could hardly be called backlog
 68 2016-12-15 19:05:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/9352 | Attempt reconstruction from all compact block announcements by sdaftuar · Pull Request #9352 · bitcoin/bitcoin · GitHub
 69 2016-12-15 19:05:42	0|gmaxwell|The purpose of the change is to return an error if you ask for seralization version 9 on software that supports 0/1.
 70 2016-12-15 19:05:52	0|BlueMatt|wumpus: didnt say backlog, said critical to address current ongoing network issues
 71 2016-12-15 19:05:55	0|instagibbs|yes I think that's well understood
 72 2016-12-15 19:06:01	0|gmaxwell|we can talk about that next.
 73 2016-12-15 19:06:19	0|wumpus|would have been useful if luke-jr was here
 74 2016-12-15 19:06:33	0|kanzure|hi. late.
 75 2016-12-15 19:06:38	0|gmaxwell|oh missed his comment.
 76 2016-12-15 19:06:42	0|phantomcircuit|#9332
 77 2016-12-15 19:06:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/9332 | Let wallet importmulti RPC accept labels for standard scriptPubKeys (on top of #9331) by ryanofsky · Pull Request #9332 · bitcoin/bitcoin · GitHub
 78 2016-12-15 19:07:10	0|gmaxwell|I read luke's comment as saying he wanted a "max you support" version.
 79 2016-12-15 19:07:13	0|phantomcircuit|you mean 9322?
 80 2016-12-15 19:07:43	0|gmaxwell|and the response was that this was expected to be the default. Or at least thats my understanding.
 81 2016-12-15 19:07:47	0|jtimon|is luke's comment related to https://github.com/bitcoin/bitcoin/pull/9322/files#r92147938 ?
 82 2016-12-15 19:08:20	0|gmaxwell|I agree that being able to ask for a max possible is fine. (though 9999 isn't an especially good number for it. :P)
 83 2016-12-15 19:08:26	0|instagibbs|I think #9262 is ready, but some disagreement over default value?
 84 2016-12-15 19:08:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/9262 | Prefer coins that have fewer ancestors, sanity check txn before ATMP by instagibbs · Pull Request #9262 · bitcoin/bitcoin · GitHub
 85 2016-12-15 19:08:40	0|jtimon|do we have a topic?
 86 2016-12-15 19:08:47	0|gmaxwell|jtimon: pr backlog
 87 2016-12-15 19:09:03	0|wumpus|gmaxwell: in any case that doesn't have to be done in that pull, so we can just go ahead and merge it
 88 2016-12-15 19:09:17	0|gmaxwell|ACK
 89 2016-12-15 19:10:02	0|gmaxwell|in 9262 I don't believe this should default to on, for the same reason that spending unconfirmed coins is enabled by default.
 90 2016-12-15 19:10:28	0|gmaxwell|The transactions will be queued in the wallet and periodically rebroadcast (due to other fixes) and go out once they're no longer overlimit.
 91 2016-12-15 19:10:44	0|gmaxwell|the meat of the change was avoiding those cases (sometimes) when it could.
 92 2016-12-15 19:10:55	0|cfields|#9289 is holding up the next round of changes, and I believe the linked issue is unrelated
 93 2016-12-15 19:10:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub
 94 2016-12-15 19:10:59	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/756374c522c4...c9e00591cd3f
 95 2016-12-15 19:10:59	0|instagibbs|with other fixes I'm completely comfortable with it off by default.
 96 2016-12-15 19:11:00	0|bitcoin-git|13bitcoin/06master 1480d073c 15Pieter Wuille: Complain when unknown rpcserialversion is specified
 97 2016-12-15 19:11:00	0|bitcoin-git|13bitcoin/06master 14fa615d3 15MarcoFalke: [qa] Don't set unknown rpcserialversion
 98 2016-12-15 19:11:01	0|bitcoin-git|13bitcoin/06master 14c9e0059 15Wladimir J. van der Laan: Merge #9322: [qa] Don't set unknown rpcserialversion...
 99 2016-12-15 19:11:06	0|cfields|(though maybe #9212 deserves a topic of its own)
100 2016-12-15 19:11:08	0|gribble|https://github.com/bitcoin/bitcoin/issues/9212 | Assertion failed: (nSendVersion != 0), function GetSendVersion, file ./net.h, line 775. · Issue #9212 · bitcoin/bitcoin · GitHub
101 2016-12-15 19:11:12	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9292: Complain when unknown rpcserialversion is specified (06master...06nofutureserial) 02https://github.com/bitcoin/bitcoin/pull/9292
102 2016-12-15 19:11:54	0|wumpus|cfields: agreed
103 2016-12-15 19:12:59	0|wumpus|ok, so #9262 off by default? should it still be backported then?
104 2016-12-15 19:13:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/9262 | Prefer coins that have fewer ancestors, sanity check txn before ATMP by instagibbs · Pull Request #9262 · bitcoin/bitcoin · GitHub
105 2016-12-15 19:13:15	0|BlueMatt|cfields/wumpus: I think there is a fix commit for 9212 on the issue page at the bottom (I havent pr'ed yet because testing, but I think it'd work)
106 2016-12-15 19:13:29	0|gmaxwell|wumpus: yes, it should, the main thing in the change is that it avoids creating those poorly propagating transactions when it's possible.
107 2016-12-15 19:13:42	0|gmaxwell|(My opinion)
108 2016-12-15 19:13:45	0|sipa|wumpus: 9262 does 2 things 1) avoid long chains 2) pre-reject created wallet transactions that would exceed limits
109 2016-12-15 19:13:51	0|wumpus|gmaxwell: so it still does something even if it's disabled? okay
110 2016-12-15 19:13:53	0|sipa|wumpus: only 2 is optional
111 2016-12-15 19:14:00	0|wumpus|okay, right, that wasn't clear to me
112 2016-12-15 19:14:19	0|wumpus|BlueMatt: ok, will test that too
113 2016-12-15 19:14:38	0|instagibbs|yes so with default off it will simply try harder to pick coins that have shorter chain length
114 2016-12-15 19:14:45	0|instagibbs|rather than blindly
115 2016-12-15 19:15:06	0|sipa|which won't have an effect if you're always sending your full change
116 2016-12-15 19:15:10	0|sipa|but better is better
117 2016-12-15 19:15:32	0|cfields|BlueMatt: the reason I didn't do that is that it hides the previous behavior. The current asserts point out issues that need to be backported to 0.13
118 2016-12-15 19:15:43	0|cfields|(which admittedly should've been loud errors rather than asserts)
119 2016-12-15 19:15:47	0|gmaxwell|The original suggestion to create that change was (1) based on me actually encountering users that could have avoided the long chains.
120 2016-12-15 19:16:12	0|btcdrak|here
121 2016-12-15 19:16:40	0|wumpus|cfields: critical issues? or nothing that needs to hold up 0.13.2?
122 2016-12-15 19:16:52	0|gmaxwell|cfields: I had a node go down with-- we think-- that assert.. but can't tell where it was triggered from.
123 2016-12-15 19:17:00	0|sipa|cfields: do they really need backporting?
124 2016-12-15 19:17:04	0|cfields|wumpus: likely nothing critical, just possible data leaks
125 2016-12-15 19:17:20	0|wumpus|so if I get this right there are now two remaining unmerged pulls that need backport to 0.13.2 https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.2
126 2016-12-15 19:17:26	0|BlueMatt|cfields: why are those data leaks? anyway, I think we previously discussed not using nVersion != 0 for this check
127 2016-12-15 19:17:38	0|wumpus|just one I mean, the other *is* a a backport
128 2016-12-15 19:17:42	0|sipa|cfields: i'd say that such issues are things where we're certainly violating some of our own assumptions about how the p2p implementation works, but unlikely things that cause issues in interaction with other nodes
129 2016-12-15 19:18:14	0|cfields|any assert represents some case where we should be disconnected, but instead are still sending/responding.
130 2016-12-15 19:18:25	0|jtimon|#8855 could need rebase if there's new uses of Params(std::string), but if there are, they won't necessarily cause git conflicts
131 2016-12-15 19:18:36	0|BlueMatt|cfields: no, in this case it means we are sending, but havent yet sent version message
132 2016-12-15 19:19:01	0|gmaxwell|wumpus: I believe #9352 will be tagged for backport-- but it's too green to comment on it for the moment.
133 2016-12-15 19:19:26	0|wumpus|gmaxwell: that's too bad, I hoped we could finally get this over with this week
134 2016-12-15 19:19:42	0|cfields|BlueMatt: right, which specifically here means that we've refused the connection due to missing connection flags, but we're still sending/responding
135 2016-12-15 19:19:48	0|wumpus|gmaxwell: can't it wait for 0.13.3?
136 2016-12-15 19:19:49	0|sdaftuar|gmaxwell: should i go ahead and open the backport version of #9352?
137 2016-12-15 19:19:59	0|BlueMatt|wumpus: its a relatively simple patch, I'm hopeful we still can :)
138 2016-12-15 19:20:10	0|instagibbs|I will review asap
139 2016-12-15 19:20:59	0|cfields|BlueMatt: let's take it up after the meeting
140 2016-12-15 19:21:03	0|BlueMatt|cfields: sure
141 2016-12-15 19:23:22	0|wumpus|okay, any other topics to discuss?
142 2016-12-15 19:23:33	0|gmaxwell|sdaftuar: I think that would be useful.
143 2016-12-15 19:23:49	0|gmaxwell|wumpus: I really want 0.13.2 in RC ASAP. just have some specific conerns about needing that. We'll work through it.
144 2016-12-15 19:24:12	0|MarcoFalke|Could 9262 delay the rc?
145 2016-12-15 19:24:20	0|jtimon|#8498 has been in the backlog for a while too (before that, #6445 was waiting for #6526/#6625/#6557 and friends, which were merged or closed long ago)
146 2016-12-15 19:24:20	0|MarcoFalke|Is it well tested?
147 2016-12-15 19:24:36	0|gmaxwell|MarcoFalke: I've tested the heck out of it. dunno about others.
148 2016-12-15 19:24:36	0|MarcoFalke|(Note that it was not yet merged into master)
149 2016-12-15 19:24:49	0|MarcoFalke|(I haven't really looked at it)
150 2016-12-15 19:24:56	0|cfields|wumpus: regarding the assertion backports, nothing would be a regression from 0.13, so no need to delay, only a bonus if we get fixes in.
151 2016-12-15 19:25:08	0|btcdrak|sdaftuar: ack on backport #9352
152 2016-12-15 19:25:28	0|gmaxwell|MarcoFalke: it's the oldest of thes long-chain wallet fixes, just last to merge. as it had lots of oppturnities for shed painting and resulted in deciding to fix the other issues. :)
153 2016-12-15 19:25:39	0|wumpus|MarcoFalke: there was at least the discussion to disable the setting by default, but after that change I don't know why it should hold up anything
154 2016-12-15 19:25:57	0|wumpus|MarcoFalke: I don't think there's any critical concerns with it left
155 2016-12-15 19:26:06	0|gmaxwell|with the default off it only changes 'non-determinstic' behavior.
156 2016-12-15 19:26:19	0|gmaxwell|(selectcoins)
157 2016-12-15 19:26:27	0|sipa|the patch always had the setting off by default - i was the one arguing that it should be on by default instead (and it seems few people agree, fine)
158 2016-12-15 19:26:37	0|instagibbs|Hm? it was on before
159 2016-12-15 19:26:43	0|instagibbs|but this is pre other 2 changes
160 2016-12-15 19:26:46	0|sipa|oh? maybe before i looked at it :)
161 2016-12-15 19:27:22	0|wumpus|let's just settle on having it disabled by default in the initial merge and the backport, it can always be set to be enabled by default later...
162 2016-12-15 19:27:25	0|gmaxwell|sipa: you could argue for that in 0.14 later.
163 2016-12-15 19:27:31	0|gmaxwell|that.
164 2016-12-15 19:27:32	0|MarcoFalke|Agree wumpus
165 2016-12-15 19:28:06	0|wumpus|there's no need to fix everything in one pull, or one version for that matter, sometimes things are held up too long on minor discussion points
166 2016-12-15 19:28:19	0|instagibbs|better is better
167 2016-12-15 19:28:23	0|wumpus|right.
168 2016-12-15 19:28:27	0|MarcoFalke|morcos: gmaxwell: Do you have a strong opinion about the fLimitFree flag in the #9290
169 2016-12-15 19:28:29	0|MarcoFalke|backport?
170 2016-12-15 19:28:33	0|gmaxwell|sometimes better is worse, there is totally like an essay on this. :P
171 2016-12-15 19:28:47	0|jtimon|sipa: just said fine on not having it on by default, didn't he?
172 2016-12-15 19:29:15	0|wumpus|yes he did, I meant in general
173 2016-12-15 19:29:18	0|sipa|jtimon: yes, i'm fine with it being off
174 2016-12-15 19:29:55	0|wumpus|MarcoFalke: ah yes that's an important point
175 2016-12-15 19:29:56	0|gmaxwell|MarcoFalke: Didn't see your question until now. will evaluate.
176 2016-12-15 19:30:13	0|wumpus|so this is about this comment: https://github.com/bitcoin/bitcoin/pull/9347#discussion_r92503011
177 2016-12-15 19:30:22	0|MarcoFalke|Imo it should not matter too much, but I'd rather have a second opinion
178 2016-12-15 19:30:26	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #9357: [0.13 backport] Attempt reconstruction from all compact block announcements (060.13...06backport-optimistic-cb) 02https://github.com/bitcoin/bitcoin/pull/9357
179 2016-12-15 19:32:06	0|MarcoFalke|I haven't checked if it caused issues with txes evicted from the pool due to low fee.
180 2016-12-15 19:32:53	0|gmaxwell|I need to look into it carefully to make a decision on my view, not going to manage it during the meeting.
181 2016-12-15 19:33:10	0|MarcoFalke|ok, other topics?
182 2016-12-15 19:34:03	0|morcos|MarcoFalke: I hadn't seen the flimitFree thing before now, I'll take a look and get back to you after...  (same as gmaxwell)
183 2016-12-15 19:34:19	0|MarcoFalke|great, thx
184 2016-12-15 19:34:32	0|gmaxwell|We could talk about the compact block announcement stuff not the backports but the change; just so people know what the change is about.
185 2016-12-15 19:34:55	0|wumpus|#topic compact block announcement stuff
186 2016-12-15 19:35:14	0|gmaxwell|Right now, if someone sends us a header, we request a block and mark the block in flight. If a compact block (e.g. from a HB mode sender that sends unsolicited ones) shows up while we're waiting.. we just ignore it, instead of trying to reconstruct the block.
187 2016-12-15 19:35:56	0|gmaxwell|This means that if a peer is broken and slowly transmits or fails to reply, the HB mode will fail to work around it.
188 2016-12-15 19:36:45	0|gmaxwell|There is a deep rabbit hole we can go down towards optimal behavior, but what is proposed right now is a super minimal change where even if a block is in flight, we'll still see if we can recover the whole block from just the compact block. And if we can, we take it, and mark the block as complete.
189 2016-12-15 19:37:17	0|wumpus|sounds sensible
190 2016-12-15 19:37:43	0|gmaxwell|greater than 2/3rs of all blocks can be recovered from just the compact block (varries a lot based on miner/network behavior) so even this small improvement should be a pretty big help.
191 2016-12-15 19:37:45	0|wumpus|there seems some potential for race conditions though
192 2016-12-15 19:37:46	0|BlueMatt|this is especially important with prefill, where, if your peer upgrades to prefill txn in the announcement you can recover the block somtimes and recover from stalling without yourself upgrading
193 2016-12-15 19:38:26	0|wumpus|what if the compact block is reconstructed, and then the inflight block comes in?
194 2016-12-15 19:38:40	0|gmaxwell|wumpus: yes, though we don't count on the in-flight to protect against that, and if a full block shows up right now we'll accept it.
195 2016-12-15 19:38:55	0|sdaftuar|wumpus: should not be a problem.  there's generally no downside to receiving a block you already have.
196 2016-12-15 19:38:59	0|gmaxwell|wumpus: then its just like someone sending us an unsolicited full block, which we'll process if it's not best already.
197 2016-12-15 19:40:03	0|wumpus|sdaftuar: in general there's no downside, just thought it'd be a potential edge case, but if that's handled that's ok
198 2016-12-15 19:40:44	0|gmaxwell|In any case, I think that summarizes where that is, I have several nodes testing live right now.. obviously will need review and testing.. but I just wanted everyone to know what was going on there.
199 2016-12-15 19:44:01	0|jtimon|thanks, I assume more questions about this or other topics?
200 2016-12-15 19:46:15	0|achow101|when are we planning to start rc'ing for 0.13.2
201 2016-12-15 19:47:22	0|wumpus|dunno, yesterday if it was up to me :p
202 2016-12-15 19:48:04	0|wumpus|in any case there's still a few things open and you can help by testing and reviewing: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.2
203 2016-12-15 19:49:40	0|wumpus|bah looks like the build is broken
204 2016-12-15 19:50:52	0|wumpus|any other topics? if not we'll close the meeting early
205 2016-12-15 19:51:15	0|sipa|very short report: gmaxwell and i have been experimenting with a per-txout utxo cache approach
206 2016-12-15 19:51:16	0|gmaxwell|Close meeting early and make 0.13.2 great again ACK.
207 2016-12-15 19:51:25	0|sipa|so far results don't look too promising
208 2016-12-15 19:51:28	0|wumpus|heh
209 2016-12-15 19:51:42	0|morcos|sipa: yeah i haven't looked at that yet
210 2016-12-15 19:51:47	0|morcos|i'm surprised!
211 2016-12-15 19:51:57	0|morcos|i was super optimistic
212 2016-12-15 19:52:01	0|sipa|me too
213 2016-12-15 19:52:06	0|wumpus|sipa: so grouping the utxos per transaction turns out to have been a good optimization? I'm surprised too
214 2016-12-15 19:52:13	0|gmaxwell|Well when it's operating totally in memory it's 15% faster even though sipa has not exploited the new structure for better cache intelligence (so its still doing the same dumb flush thing). But when leveldb came into the picture it ate dirt.
215 2016-12-15 19:52:22	0|morcos|15% is for babies
216 2016-12-15 19:52:35	0|instagibbs|what level are you on morcos :)
217 2016-12-15 19:52:53	0|sdaftuar|i'm going to give a cheers for the sigcache cuckoocache merge now!
218 2016-12-15 19:53:05	0|jtimon|mhm, haven't looked at the branch, are the utxo's catched per txout but stored per-tx?
219 2016-12-15 19:53:23	0|sipa|jtimon: both per txout
220 2016-12-15 19:53:24	0|BlueMatt|gmaxwell: seems like something where you can per-utxo in memory and per-tx on disk?
221 2016-12-15 19:53:24	0|gmaxwell|Assuming the issue isn't extra debugging sipa added, the downside is perhaps that it is just much harder on leveldb and writes a lot more traffic to the leveldb log.
222 2016-12-15 19:53:47	0|wumpus|BlueMatt: yes I was about to suggest that too
223 2016-12-15 19:53:52	0|BlueMatt|i mean might lose all the performance on the boundary, but its worth a shot
224 2016-12-15 19:53:52	0|gmaxwell|The real gains from the change would come from making the cache smarter, so I thought 15% was great news.. since that likely came from reduced malloc traffic.
225 2016-12-15 19:54:02	0|jtimon|sipa: thanks. mhmm, yeah, this is surprising then
226 2016-12-15 19:54:05	0|sipa|BlueMatt: that doesn't solve the O(n^2) issue with large transactions
227 2016-12-15 19:54:10	0|gmaxwell|BlueMatt: yes, I made that observation too.... but it means that read modify write cycles would be needed.
228 2016-12-15 19:54:29	0|wumpus|gmaxwell: yeah that would be bad...
229 2016-12-15 19:54:49	0|wumpus|lookups are slow, if you need read-modify-write cycles it's not going to help performance
230 2016-12-15 19:54:56	0|sipa|the O(n^2) issue is that a tx with many outputs on every spend needs to write n-i outputs to the database
231 2016-12-15 19:55:19	0|gmaxwell|wumpus: yes, though it might pay for itself by the cache being much more effective. I guess we won't know until after more testing.
232 2016-12-15 19:55:20	0|cfields|sdaftuar: +1. Still catching up, didn't see that got merged. Great to see :)
233 2016-12-15 19:56:08	0|gmaxwell|the other negative is that it looks like this change will require a chainstate reindex. making it compatible with undo files seems really hard.
234 2016-12-15 19:56:44	0|sipa|basically my reason for wanting per-txout cache is that the current behaviour may be good on average, but it's terrible for big transactions
235 2016-12-15 19:56:48	0|jtimon|maybe somehow writting txouts in batches could help? (thinking out loud, may be a stupid thought)
236 2016-12-15 19:57:00	0|wumpus|requiring everyone to do a chainstate reindex would be bad too :/
237 2016-12-15 19:57:05	0|sipa|jtimon: we're already batching _all_ writes from many blocks
238 2016-12-15 19:57:38	0|jtimon|sipa: I see, it was a stupid thought
239 2016-12-15 19:57:48	0|sipa|anyway, just reporting on an experiment - nothing more at this point
240 2016-12-15 19:57:51	0|morcos|gmaxwell: i'm not sure what you mean about making the cache smarter
241 2016-12-15 19:58:02	0|gmaxwell|wumpus: right now everyone's chainstate is corrupted... to at some point we'll need to do something about that.  (TXversions)
242 2016-12-15 19:58:09	0|wumpus|writes are pretty fast with leveldb, it's lookups/reads are slow, especially on slow disks
243 2016-12-15 19:58:10	0|sipa|morcos: not wiping the cache after a write
244 2016-12-15 19:58:14	0|morcos|in my view once its only keeping utxos that were actually accessed and not the rest that tagged along with the tx, then thats as smart as it gets
245 2016-12-15 19:58:30	0|Chris_Stewart_5|Are we thinking txs are going to become larger in terms of inputs/outputs as Bitcoin grows? UTXO size is constantly growing right?
246 2016-12-15 19:58:34	0|morcos|sipa: sure but you still have to do something when you hit memory limits
247 2016-12-15 19:58:43	0|sipa|Chris_Stewart_5: i wish it were not growing at all
248 2016-12-15 19:59:02	0|wumpus|batching writes more is not going to help, and batches are already huge in memory
249 2016-12-15 19:59:03	0|morcos|you can save the things that are in blocks from the top of your mempool, but thats really small... small enough that it can be done pretty effectively with the existing model
250 2016-12-15 19:59:03	0|sipa|Chris_Stewart_5: http://bitcoin.sipa.be/utxo_size.png
251 2016-12-15 19:59:06	0|gmaxwell|morcos: yes the right thing to do is to expire only the oldest entrties at that point. Which is much cleaner when there is no such thing as entry mutation.
252 2016-12-15 19:59:13	0|Chris_Stewart_5|I guess it is just interesting to hear the tidbit about terrible performance of large txs.
253 2016-12-15 19:59:14	0|wumpus|gmaxwell: requiring everyone to reindex at the same time is not an acceptable solution though :)
254 2016-12-15 19:59:26	0|morcos|ah, oldest, yes ok, but that requires extra state
255 2016-12-15 19:59:31	0|wumpus|gmaxwell: maybe it could support two database versions for a while
256 2016-12-15 19:59:42	0|sipa|Chris_Stewart_5: in general, we need to optimize worst-case performance, not average performance
257 2016-12-15 19:59:44	0|wumpus|gmaxwell: new reindexes/syncs would use the new format
258 2016-12-15 20:00:02	0|wumpus|in any acsae, thanks for trying this experiment
259 2016-12-15 20:00:08	0|sipa|Chris_Stewart_5: as a large difference between worst-case and average means we could be missing DoS opportunities where an attacker can force us into the worsr
260 2016-12-15 20:00:11	0|gmaxwell|wumpus: if it made it N fold faster, than reindex on a new version... might be something we could have happen. I think perhaps we'd want to finish your snapshooting work and other things at the same time. ... in any case it's just an expirement now.
261 2016-12-15 20:00:17	0|wumpus|even if it turns out it's not better it's good to know this for sure
262 2016-12-15 20:00:37	0|gmaxwell|it also has resulted in some other optimizations, e.g. the flushing optimization PR that we have right now.
263 2016-12-15 20:00:42	0|sipa|Chris_Stewart_5: but it's really sad when you need to decrease your average performance in order to improve the worst case... because people don't observe the worst case
264 2016-12-15 20:00:52	0|wumpus|gmaxwell: if it was possible to convert the old database to the new database without a reindex (e.g. just rewriting) then an upgrade process would be acceptable. But a full reindex? no
265 2016-12-15 20:01:02	0|gmaxwell|Good, the meeting has run over, so all is well with the world. :)
266 2016-12-15 20:01:08	0|wumpus|#endmeeting
267 2016-12-15 20:01:09	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.log.html
268 2016-12-15 20:01:09	0|lightningbot|Meeting ended Thu Dec 15 20:01:08 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
269 2016-12-15 20:01:09	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.html
270 2016-12-15 20:01:09	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.txt
271 2016-12-15 20:01:12	0|sipa|wumpus: i believe it is convertible, but it's nontrivial
272 2016-12-15 20:01:16	0|gmaxwell|wumpus: that would be possible, though perhaps a lot of code.
273 2016-12-15 20:01:34	0|Chris_Stewart_5|sipa: Thanks for the food for thought. I appreciate the extra explanation :-)
274 2016-12-15 20:01:52	0|wumpus|gmaxwell: ah yes thanks for reminding me of the snapshotting
275 2016-12-15 20:02:02	0|sipa|the tx height/coinbase is currently only stored in the undo data for the last spend from one tx's outputs, and needs to be stored in all
276 2016-12-15 20:02:46	0|sipa|but that can be done by walking the undo data backwards (which is always possible, even in pruned mode), and building a temporary database with tx->metadata maps, and using that to rebuild the undo data in the new format
277 2016-12-15 20:03:12	0|jtimon|wumpus: what snapshotting?
278 2016-12-15 20:03:35	0|wumpus|jtimon: automatic utxo database backups
279 2016-12-15 20:05:08	0|gmaxwell|morcos: my thought was that with the per-utxo model we could simply have a list of keys as they're read into the cache... and then when the cach is full, pop from the beginning of the list and flush those entries... to take it back to 90% or something (whatever is big enough to have a reasonable batch size for leveldb).
280 2016-12-15 20:05:13	0|wumpus|sipa: btw I still get no results from "host seed.bitcoin.sipa.be"
281 2016-12-15 20:05:40	0|gmaxwell|Sipa noticed that right now we end up using somewhat less than twice our memory limit; the flush process copies the data being flushed.
282 2016-12-15 20:05:59	0|morcos|gmaxwell: wow, really... i didn't realize that
283 2016-12-15 20:06:48	0|morcos|sdaftuar also points out that just deleting spent entries will help
284 2016-12-15 20:07:08	0|gmaxwell|morcos: well their deletion needs to hit the disk if their creation ever did.
285 2016-12-15 20:07:13	0|morcos|i had observed that it wasn't THAT helpful, but that was with requiring the whole TX to be spent... should be a much bigger effect
286 2016-12-15 20:07:34	0|gmaxwell|oh yea, thats one of the benefits of the per txout model.
287 2016-12-15 20:07:35	0|morcos|yes, so on flush, you can keep everything that isn't spent and your memory usage may reduce non-trivially
288 2016-12-15 20:09:09	0|gmaxwell|in any case, because of that memory usage we should be limiting our leveldb batch sizes. I'm guessing there probably is no real performance benefit to a batch of 200MB (or 2000mb) over 20MB.
289 2016-12-15 20:09:37	0|sipa|the size of batches is determined by how much has changed
290 2016-12-15 20:09:49	0|morcos|yeah, thats what i was thinking a bit annoying to have to track that too
291 2016-12-15 20:10:03	0|sipa|unless we maintain multiple checkpoints in-memory, to know which entries combined form a consistent state, that's very hard to reduce
292 2016-12-15 20:10:31	0|sipa|multiple in-memory checkpoints also implies we can't do the fresh optimization until an entry is in no snapshot
293 2016-12-15 20:10:33	0|wumpus|that sounds overly complicated
294 2016-12-15 20:10:36	0|sipa|yes.
295 2016-12-15 20:11:10	0|morcos|gmaxwell: one advnatage of bigger batch sizes is the ability to delete fresh pruned entries...  you lose all your freshness after a flush
296 2016-12-15 20:12:38	0|gmaxwell|well, the alternative for memory usage is that we start making changes to the leveldb api so that it can do some kind of gather callback or something for the batch.
297 2016-12-15 20:13:16	0|sipa|yes.
298 2016-12-15 20:13:26	0|gmaxwell|(I'm not even sure if thats possible, but it looked like it with a quick glance at the leveldb code)
299 2016-12-15 20:13:26	0|sipa|we discovered that a leveldb write batch is a wrapped std::string
300 2016-12-15 20:13:47	0|sipa|which just gets writes and erased appended to in a binary format
301 2016-12-15 20:14:09	0|wumpus|optimizing leveldb's batch representation/scheduling would certainly be possible, yes
302 2016-12-15 20:15:48	0|wumpus|but in my experience it's reads / lookups that take lots of time, especially on slow disks, not so much writing, writing with leveldb is much faster than comparable databases such as lmdb
303 2016-12-15 20:16:26	0|sipa|well writing 2GB of modified utxo entries required 90s in gmaxwell's benchmarks
304 2016-12-15 20:16:55	0|gmaxwell|well it was 40s with master, 90s with the per-utxo.
305 2016-12-15 20:17:04	0|wumpus|but that's hardly realistic for normal usage
306 2016-12-15 20:17:22	0|wumpus|if you have a dbcache of gigabytes you hardly really need a database at all
307 2016-12-15 20:18:51	0|gmaxwell|wumpus: so right now our initial sync performance is really poor with the default cache. it takes 21076 seconds to chainstate reindex even with all signature checking disabled on a fast machine.  We often tell people to crank their dbcache to big numbers to make ibd take more acceptable time.
308 2016-12-15 20:19:43	0|wumpus|gmaxwell: but is that due to writing? as said, in my experience, it spends almost all the time connecting inputs - e.g. fetching and random lookups
309 2016-12-15 20:19:55	0|wumpus|it could be I just have very strange hardware of course
310 2016-12-15 20:20:39	0|gmaxwell|sorry, I thought you were saying that it wasn't realistic for people to run with a big dbcache; and I was just countering that running with a big dbcache is the only way to get ibd to run in a sane-ish amount of time. I guess I was on a tangent from your point.
311 2016-12-15 20:24:46	0|wumpus|right - maybe the best solution for small memory usage and large memory usage is completely different
312 2016-12-15 20:26:48	0|wumpus|another thing with writes is that things can be pipelined, as soon as the batch buffers have been filled it could be shipped off to a background thread doing the writing, there's no need to wait for it to continue
313 2016-12-15 20:31:20	0|gmaxwell|wumpus: yes. Indeed. perhaps a little tricky with consistency between the chainstate and the blockindex.
314 2016-12-15 20:40:31	0|gmaxwell|ohh sipa's per utxo code had debugging code that was trashing performance, rebenchmarking is looking much more promising!
315 2016-12-15 20:43:10	0|sdaftuar|yay!
316 2016-12-15 20:43:23	0|sipa|(with large dbcache)
317 2016-12-15 20:44:27	0|gmaxwell|Man.  Thomas Zander wrote some article attacking segwit today that says up front "Once a user gets a SegWit transaction, she will only be able to move that money forward in a SegWit wallet. So if a person doesn't upgrade they will eventually not be able to accept money from anyone." -- will there be no consequence in this ecosystem for this kind of incompetence or dishonesty?  damn.  It also rep
318 2016-12-15 20:44:33	0|gmaxwell|eats Jeff Garzik's two buckets lie.
319 2016-12-15 20:44:36	0|gmaxwell|https://bitcoinclassic.com/devel/FlexTrans-vs-SegWit.html
320 2016-12-15 20:46:22	0|gmaxwell|Also deceptively claims to make transactions smaller (actually-- it increases the amount of information in a transaction-- because it makes the field ordering non-normative--, making the smallest possible representation larger...)
321 2016-12-15 20:51:41	0|juscamarena|Just saw that. Was the site hacked? He can't really believe that?
322 2016-12-15 20:52:14	0|sipa|i'm sure he believes it
323 2016-12-15 20:53:41	0|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.
324 2016-12-15 20:59:57	0|btcdrak|gmaxwell: what the heck? that's just ...
325 2016-12-15 21:02:06	0|juscamarena|Sigh. He might have gotten confused here: "When spending your bitcoins after the upgrade to segwit, you will still be able to pay the original type of Bitcoin addresses that start with a ‘1’ (a P2PKH address) as well as being able to pay other users of P2SH addresses."
326 2016-12-15 21:02:28	0|juscamarena|Thinking upgrade meant upgrading the wallet.
327 2016-12-15 21:03:28	0|gmaxwell|I'm having a really hard time believing that he is actually this confused.
328 2016-12-15 21:36:14	0|morcos|gmaxwell: just skimmed what he wrote.. i don't think hes confused.. (except about the 2 buckets crap, but you know "math is hard")
329 2016-12-15 21:37:16	0|morcos|i think he was just trying to make a point that i don't think really makes any sense, that people with segwit wallets would prefer to send to other segwit addresses
330 2016-12-15 21:37:31	0|morcos|well yes i guess maybe thats what you meant by confused, since there is no reason they would prefer that?
331 2016-12-15 21:38:14	0|gmaxwell|there is no reason they would prefer that.
332 2016-12-15 21:38:23	0|gmaxwell|Doesn't cost them any more or less.
333 2016-12-15 21:38:34	0|gmaxwell|it's indistinguishable to them.
334 2016-12-15 21:39:09	0|morcos|it seems maybe the text changed if yours was an actual quote
335 2016-12-15 21:39:11	0|gmaxwell|actually, since the only kind of address type right now used for segwit is p2sh-p2w* it is cryptographically indistinguishable.
336 2016-12-15 21:39:22	0|gmaxwell|morcos: my test was an actual quote.
337 2016-12-15 21:39:25	0|gmaxwell|er text.
338 2016-12-15 21:39:34	0|morcos|it still says this which is at best badly misleading
339 2016-12-15 21:39:36	0|morcos|"receiving a SegWit transaction requires a SegWit wallet which then will generate SegWit transactions forcing everyone around you to get one too."
340 2016-12-15 21:40:07	0|gmaxwell|that is absurdly untrue too.
341 2016-12-15 21:41:15	0|gmaxwell|amusingly one of the big reasons we didn't move foward with a new address type was specifically to avoid this class of misunderstanding.  (the other being that several people wanted time to establish a new base-32 based encoding with proper error detection)
342 2016-12-15 21:44:07	0|MarcoFalke|morcos: Motivated from the rpc test failure: Should the feefilter rounder not return a fee that is less (or equal to) the target fee?
343 2016-12-15 21:44:29	0|MarcoFalke|otherwise you might miss some tx if you "round up"
344 2016-12-15 21:44:42	0|morcos|MarcoFalke: which test failure?
345 2016-12-15 21:44:51	0|MarcoFalke|fundrawtx
346 2016-12-15 21:45:02	0|MarcoFalke|Just a sync mempool issue due to feefilter, I guess
347 2016-12-15 21:45:12	0|morcos|i mean is there a link to what you are talking about
348 2016-12-15 21:45:16	0|MarcoFalke|#9313
349 2016-12-15 21:45:17	0|gribble|https://github.com/bitcoin/bitcoin/issues/9313 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
350 2016-12-15 21:45:52	0|MarcoFalke|If you run fundrawtransaciton on master it will fail randomly
351 2016-12-15 21:46:01	0|morcos|i'm not following... ok, thats what i was wondering
352 2016-12-15 21:46:04	0|morcos|really?
353 2016-12-15 21:46:14	0|MarcoFalke|Likely due to current choice of the feefilter
354 2016-12-15 21:46:30	0|MarcoFalke|It becomes visible when the transaction pays a fee close to the minrelayfee
355 2016-12-15 21:46:50	0|MarcoFalke|your feefilter will be maybe minrelaytxfee+x, so you never see the tx
356 2016-12-15 21:47:00	0|morcos|yeah i guess if you tried to pay exactly the minrelayfee it might not work
357 2016-12-15 21:47:52	0|MarcoFalke|Would it make sense to always send feefilters that are less than the currentFeeFilter?
358 2016-12-15 21:47:58	0|morcos|the variance was put in there to slightly obscure the exact state of your mempool..  but ehh, i'm not sure its worth the effort
359 2016-12-15 21:48:30	0|MarcoFalke|You can keep the variance
360 2016-12-15 21:48:35	0|morcos|realistically i doubt it would be a problem except in tests..
361 2016-12-15 21:48:54	0|MarcoFalke|Sure, on current main net
362 2016-12-15 21:49:10	0|MarcoFalke|with default minrelaytxfee
363 2016-12-15 21:49:26	0|morcos|i mean its been like that since it came out, the only difference is it happens now before your mempool gets full
364 2016-12-15 21:49:34	0|MarcoFalke|Right
365 2016-12-15 21:50:24	0|morcos|i don't feel strongly...
366 2016-12-15 21:52:00	0|MarcoFalke|As we send a feefilter now by default for all connections, it might not be too much wasted bandwith if we received some minrelaytxfee-dust txs
367 2016-12-15 21:52:01	0|gmaxwell|I think it's okay to leak that you're at the floor. e.g. apply the max after the variance.
368 2016-12-15 21:55:24	0|MarcoFalke|In which case your node is identifiable if you set a non-default value for the relay fee, no?
369 2016-12-15 21:56:54	0|gmaxwell|it's identifyable by behavior in that case, regardless.
370 2016-12-15 22:13:07	0|morcos|MarcoFalke: yeah the floor is a separate issue.  we already send under the floor all the time anyway... i think that could be a special case perhaps.
371 2016-12-15 22:13:56	0|morcos|i'm just not sure how much any of this is worth it.  to make sure the tests work at exactly minrelaytxfee, need to check all the < vs <='s as well
372 2016-12-15 23:07:06	0|luke-jr|instagibbs: more of a suggestion than disagreement re 9322