1 2016-03-31 02:53:48	0|GitHub72|[13bitcoin] 15maneotrix opened pull request #7775: 0.12 (06master...060.12) 02https://github.com/bitcoin/bitcoin/pull/7775
  2 2016-03-31 06:14:05	0|GitHub136|[13bitcoin] 15laanwj closed pull request #7775: 0.12 (06master...060.12) 02https://github.com/bitcoin/bitcoin/pull/7775
  3 2016-03-31 08:16:00	0|wumpus|<gmaxwell> We're destroying the future utility by producing false positives now.  <- exactly
  4 2016-03-31 08:16:37	0|wumpus|that's why I said "in any case let's say that if we can unequivocably decide that  7568 is an improvement that makes it worth keeping the system in the next 24 hours then we'll merge and backport that, otherwise we'll disable it in 0.12 for now" ... we should consider the utility now, even if that temporarily means disabling it
  5 2016-03-31 08:18:59	0|wumpus|anyhow let's discuss at the meeting
  6 2016-03-31 08:55:44	0|GitHub33|13bitcoin/06master 14fb8a8cf 15Wladimir J. van der Laan: rpc: Register calls where they are defined...
  7 2016-03-31 08:55:44	0|GitHub33|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e8a8f3d4b22b...16555b658f5b
  8 2016-03-31 08:55:45	0|GitHub33|13bitcoin/06master 1416555b6 15Wladimir J. van der Laan: Merge #7766: rpc: Register calls where they are defined...
  9 2016-03-31 08:55:51	0|GitHub45|[13bitcoin] 15laanwj closed pull request #7766: rpc: Register calls where they are defined (06master...062016_03_separate_rpc_registration) 02https://github.com/bitcoin/bitcoin/pull/7766
 10 2016-03-31 09:08:39	0|GitHub195|13bitcoin/06master 1440234ba 15BtcDrak: Fix comments in tests
 11 2016-03-31 09:08:39	0|GitHub195|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/16555b658f5b...7c80e720402d
 12 2016-03-31 09:08:40	0|GitHub195|13bitcoin/06master 1440234ba 15BtcDrak: Fix comments in tests
 13 2016-03-31 09:08:40	0|GitHub195|13bitcoin/06master 147c80e72 15Wladimir J. van der Laan: Merge #7773: Fix comments in tests...
 14 2016-03-31 09:08:49	0|GitHub51|[13bitcoin] 15laanwj closed pull request #7773: Fix comments in tests (06master...06csv-comments) 02https://github.com/bitcoin/bitcoin/pull/7773
 15 2016-03-31 11:25:19	0|GitHub59|13bitcoin/06master 14eff736e 15Pieter Wuille: Reformat version in UpdateTip and other messages...
 16 2016-03-31 11:25:19	0|GitHub59|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7c80e720402d...3081fb9a3105
 17 2016-03-31 11:25:20	0|GitHub59|13bitcoin/06master 143081fb9 15Wladimir J. van der Laan: Merge #7763: Put hex-encoded version in UpdateTip...
 18 2016-03-31 11:25:22	0|GitHub95|[13bitcoin] 15laanwj closed pull request #7763: Put hex-encoded version in UpdateTip (06master...06hexver) 02https://github.com/bitcoin/bitcoin/pull/7763
 19 2016-03-31 11:25:54	0|GitHub99|13bitcoin/06master 143e55b3a 15accraze: [doc] added depends cross compile info
 20 2016-03-31 11:25:54	0|GitHub99|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3081fb9a3105...209dbeb05f88
 21 2016-03-31 11:25:55	0|GitHub99|13bitcoin/06master 14209dbeb 15Wladimir J. van der Laan: Merge #7747: [docs] added depends cross compile info...
 22 2016-03-31 11:26:02	0|GitHub89|[13bitcoin] 15laanwj closed pull request #7747: [docs] added depends cross compile info (06master...06depends-build-docs) 02https://github.com/bitcoin/bitcoin/pull/7747
 23 2016-03-31 11:50:25	0|GitHub59|13bitcoin/060.12 144d035bc 15accraze: [doc] added depends cross compile info...
 24 2016-03-31 11:50:25	0|GitHub59|[13bitcoin] 15laanwj pushed 1 new commit to 060.12: 02https://github.com/bitcoin/bitcoin/commit/4d035bcc9aa3388dc7f37cf81451e55f0b6270ee
 25 2016-03-31 12:14:23	0|GitHub125|13bitcoin/06master 14ae2156f 15Pavel Janík: Clear the input line after activating autocomplete
 26 2016-03-31 12:14:23	0|GitHub125|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/209dbeb05f88...63832688939f
 27 2016-03-31 12:14:24	0|GitHub125|13bitcoin/06master 146383268 15Jonas Schnelli: Merge #7772: Clear the input line after activating autocomplete...
 28 2016-03-31 12:14:32	0|GitHub14|[13bitcoin] 15jonasschnelli closed pull request #7772: Clear the input line after activating autocomplete (06master...0620160330_completer_clean_input_line) 02https://github.com/bitcoin/bitcoin/pull/7772
 29 2016-03-31 12:29:17	0|GitHub124|13bitcoin/06master 1472fd008 15Daniel Kraft: Fix quoting of copyright holders in configure.ac....
 30 2016-03-31 12:29:17	0|GitHub124|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/63832688939f...28ad4d9fc2be
 31 2016-03-31 12:29:18	0|GitHub124|13bitcoin/06master 1428ad4d9 15Wladimir J. van der Laan: Merge #7477: Fix quoting of copyright holders in configure.ac....
 32 2016-03-31 12:29:24	0|GitHub97|[13bitcoin] 15laanwj closed pull request #7477: Fix quoting of copyright holders in configure.ac. (06master...06configure-quoting) 02https://github.com/bitcoin/bitcoin/pull/7477
 33 2016-03-31 12:45:51	0|GitHub199|[13bitcoin] 15laanwj closed pull request #7511: [WIP] New ax_pthread.m4 from upstream - draft 3 (not final), for testing on all platforms (06master...0620160211_WIP_test_new_ax_pthread) 02https://github.com/bitcoin/bitcoin/pull/7511
 34 2016-03-31 12:56:31	0|GitHub104|[13bitcoin] 15laanwj opened pull request #7776: build: Remove unnecessary executables from gitian release (06master...062016_03_gitian_release_cleanup) 02https://github.com/bitcoin/bitcoin/pull/7776
 35 2016-03-31 13:36:00	0|GitHub57|[13bitcoin] 15jtimon closed pull request #7731: Discussion: By "more precision", I don't mean using rational numbers in CFeeRate (06master...060.12.99-feerate) 02https://github.com/bitcoin/bitcoin/pull/7731
 36 2016-03-31 14:20:46	0|GitHub142|[13bitcoin] 15laanwj pushed 5 new commits to 060.11: 02https://github.com/bitcoin/bitcoin/compare/c251f46bea8f...ecaa178a235a
 37 2016-03-31 14:20:46	0|GitHub25|[13bitcoin] 15laanwj closed pull request #7743: [0.11] Important backports for 0.11.3 (updated to v0.12.0) (060.11...06backports-for-0.11.3) 02https://github.com/bitcoin/bitcoin/pull/7743
 38 2016-03-31 14:20:47	0|GitHub142|13bitcoin/060.11 145c0b357 15Cory Fields: build: Use fPIC rather than fPIE for qt objects....
 39 2016-03-31 14:20:47	0|GitHub142|13bitcoin/060.11 1490de0e1 15Cory Fields: build: Split hardening/fPIE options out...
 40 2016-03-31 14:20:48	0|GitHub142|13bitcoin/060.11 14d626faa 15Luke Dashjr: Merge commit '5c0b357' into backports-for-0.11.3
 41 2016-03-31 14:46:29	0|MarcoFalke|Anything holding back 7691?
 42 2016-03-31 16:21:56	0|sdaftuar|wumpus: can you explain the infinite loop in EncodeDecimal that #7751 addressed?
 43 2016-03-31 16:27:14	0|morcos|wumpus: in particular, encoding amounts as strings for json now make it so that current rpc tests can't be run against pre 0.12 binaries
 44 2016-03-31 16:28:03	0|morcos|we discovered this when sdaftuar couldn't reproduce the same testing of the CSV soft fork backport I and btcdrak did without removing all the calls to Decimal
 45 2016-03-31 16:28:45	0|morcos|Also it would make it hard to use our rpc tests to test against other implementations which might not handle JSON numbers as strings since thats not really proper json
 46 2016-03-31 16:29:01	0|morcos|it seems better if our rpc tests dont' encode them that way?
 47 2016-03-31 16:29:02	0|morcos|it seems better if our rpc tests dont' encode them that way?
 48 2016-03-31 16:37:20	0|GitHub136|[13bitcoin] 15MarcoFalke opened pull request #7778: [qa] Bug fixes and refactor (06master...06Mf1604-qaFixesRefactor) 02https://github.com/bitcoin/bitcoin/pull/7778
 49 2016-03-31 16:51:30	0|GitHub176|[13bitcoin] 15MarcoFalke closed pull request #7722: [qa] Refactor python2 syntax (06master...06Mf1603-qaPy2/3) 02https://github.com/bitcoin/bitcoin/pull/7722
 50 2016-03-31 16:54:39	0|GitHub32|[13bitcoin] 15jtimon opened pull request #7779: Discussion: Consensus: There's only one type of consensus flags (06master...060.12.99-consensus-unify-flags) 02https://github.com/bitcoin/bitcoin/pull/7779
 51 2016-03-31 17:10:39	0|MarcoFalke|NicolasDorier, I can still see it
 52 2016-03-31 17:10:41	0|MarcoFalke|+        if (!CheckFinalTx(tx, flags)
 53 2016-03-31 17:11:06	0|NicolasDorier|?? one second
 54 2016-03-31 17:11:41	0|NicolasDorier|https://usercontent.irccloud-cdn.com/file/R9q9fyfu/
 55 2016-03-31 17:11:47	0|NicolasDorier|I removed the flags
 56 2016-03-31 17:11:54	0|NicolasDorier|and it compiles on travis
 57 2016-03-31 17:12:49	0|NicolasDorier|MarcoFalke: you see the like with flags as "add" ?
 58 2016-03-31 17:12:58	0|NicolasDorier|the line
 59 2016-03-31 17:13:18	0|MarcoFalke|travis is all red
 60 2016-03-31 17:13:54	0|MarcoFalke|check char 25 in this line
 61 2016-03-31 17:13:56	0|NicolasDorier|nop, only two build which are red because I pushed too fast, if can again should work fine
 62 2016-03-31 17:14:10	0|NicolasDorier|hu are we on same commit ?
 63 2016-03-31 17:14:25	0|NicolasDorier|ad930cdab3b23801f8a415cc4e900a182a6f8bc6 ?
 64 2016-03-31 17:15:12	0|wumpus|sdaftuar: in python 3.4, round(Decimal) no longer converts the decimal to a float
 65 2016-03-31 17:15:26	0|MarcoFalke|git grep 'if (!CheckFinalTx(tx, flags)'
 66 2016-03-31 17:15:34	0|wumpus|sdaftuar: so EncodeDecimal returns a (rounded) Decimal, which is again passed to EncodeDecimal
 67 2016-03-31 17:15:36	0|MarcoFalke|on the commit you posted
 68 2016-03-31 17:15:42	0|MarcoFalke|what is the result?
 69 2016-03-31 17:15:43	0|MarcoFalke|what is the result?
 70 2016-03-31 17:16:13	0|NicolasDorier|ooooooh
 71 2016-03-31 17:16:16	0|wumpus|sdaftuar: (e.g. if the 'default' function returns an object that is not json encodable, it will call the function on it, just as long as necessary)
 72 2016-03-31 17:16:34	0|NicolasDorier|omg sorry, wtf did it compiled on several conf in travis and on my machine
 73 2016-03-31 17:16:40	0|sdaftuar|wumpus: ah okay
 74 2016-03-31 17:16:51	0|wumpus|sdaftuar: that shouldn't be backported to pre-0.12, no
 75 2016-03-31 17:17:08	0|MarcoFalke|I think there is an issue with travis if you push faster than it can start the build.
 76 2016-03-31 17:17:24	0|MarcoFalke|It will just compile the current ref instad of the commit you pushed
 77 2016-03-31 17:17:28	0|wumpus|MarcoFalke: yes, it will try to fetch the pull then fails
 78 2016-03-31 17:17:43	0|wumpus|oh okay
 79 2016-03-31 17:18:03	0|wumpus|sdaftuar: you can still use the old authproxy.py if yo udon't care about python 3 compat
 80 2016-03-31 17:18:22	0|sdaftuar|wumpus: right, yeah i figured out how to workaround the issue for now
 81 2016-03-31 17:18:45	0|sdaftuar|wumpus: but i do wonder if the fix in master makes sense, we're outside the JSON spec when we deliver numeric values as strings, right?
 82 2016-03-31 17:18:50	0|sdaftuar|i know bitcoind supports it
 83 2016-03-31 17:19:42	0|NicolasDorier|MarcoFalke: Just repushed, sorry for the myopa :D
 84 2016-03-31 17:20:29	0|MarcoFalke|np
 85 2016-03-31 17:24:27	0|wumpus|sdaftuar: how is passing strings 'outside the json spec'?
 86 2016-03-31 17:24:28	0|wumpus|sdaftuar: how is passing strings 'outside the json spec'?
 87 2016-03-31 17:24:44	0|sdaftuar|for numeric values i mean
 88 2016-03-31 17:24:49	0|wumpus|what it sends it 100% valid json
 89 2016-03-31 17:25:11	0|wumpus|well the underlying problem is that python has no way to send-this-string-unquoted
 90 2016-03-31 17:25:12	0|sdaftuar|hm, so i guess the rpc calls themselves now support numeric or string?  i suppose that makes sense.
 91 2016-03-31 17:25:27	0|wumpus|casting to float defeats the purpose of using decimal in the first place
 92 2016-03-31 17:25:45	0|wumpus|so I think this is better
 93 2016-03-31 17:26:20	0|wumpus|besides reimplementing the json module to support arbitrary number formats, like univalue
 94 2016-03-31 17:28:38	0|wumpus|but yes the reason we implement strings for monetary values is that this is easier to use for software that uses decimals, no need to insert another type into the json stream just wrap it as string
 95 2016-03-31 17:29:02	0|wumpus|indeed, this is implemented in AmountFromValue
 96 2016-03-31 17:29:03	0|wumpus|indeed, this is implemented in AmountFromValue
 97 2016-03-31 17:30:46	0|instagibbs|has anyone charted out the various major function calls for accepting/creating new blocks? I don't find the function call names very helpful :)
 98 2016-03-31 17:31:06	0|instagibbs|and comments tend to have lingo I don't really grok
 99 2016-03-31 17:31:08	0|wumpus|the doxygen docs have a call tree
100 2016-03-31 17:31:14	0|instagibbs|hmm ill check that
101 2016-03-31 17:32:36	0|morcos|sipa: gmaxwell: i was just trying to do a quick review of #7568 and i'm very confused
102 2016-03-31 17:32:37	0|wumpus|https://dev.visucore.com/bitcoin/doxygen/
103 2016-03-31 17:32:58	0|instagibbs|yeah found it, thanks. Just need to find the "tip" of the flow I'm looking for now :)
104 2016-03-31 17:33:16	0|morcos|isn't it doomed to have way too many false positives due to its use of GetBlockTime().  I mean that could kind of be anything.
105 2016-03-31 17:33:32	0|morcos|We have to measure when the block was actually found, not the time on the block right?
106 2016-03-31 17:33:49	0|instagibbs|wumpus, oh this is actually really useful, it has callee & caller graph
107 2016-03-31 17:34:21	0|morcos|It's not clear to me that 7568 would meaningfully reduce the number of false positives, so i might now be leaning towards removal for 0.12.1, but i'd like to make sure i'm not missing something
108 2016-03-31 17:49:03	0|NicolasDorier|morcos: for #7574 you say it is premature to remove, why ? this code is not used at all anymore, why keeping it around ?
109 2016-03-31 17:49:59	0|morcos|NicolasDorier: We don't even know if these soft forks are going to activate.  We should not lock ourselves into only using MTP for mempool acceptance until they do.
110 2016-03-31 17:50:50	0|NicolasDorier|so you mean in case we need to revert it would be easier ?
111 2016-03-31 17:50:55	0|morcos|I'd even argue that after they activate, its still better to preserve the ability to pass in different flags to the mempool.  If for instance trying to analyze something that happend on the chain before the soft fork triggered, or starting a new chain where the fork hasn't triggered yet
112 2016-03-31 17:51:07	0|wumpus|I tend to agree it may be too early to remove it
113 2016-03-31 17:51:20	0|NicolasDorier|ok I close the pr for now or keep around ?
114 2016-03-31 17:51:22	0|morcos|I like #7779 as the right approach
115 2016-03-31 17:51:22	0|wumpus|and for future softforks there may be other, new, flags to pass around
116 2016-03-31 17:51:35	0|morcos|OR a step in the right direction
117 2016-03-31 17:51:59	0|NicolasDorier|ok let's do that then, I close the PR ?
118 2016-03-31 17:52:01	0|morcos|If you see in the segwit code I actually introduce some ways to accept non-standard stuff to the mempool (At least for testnet/regtest)
119 2016-03-31 17:52:14	0|morcos|I think that its better to abstract ways to do that for better testing
120 2016-03-31 17:52:30	0|morcos|That would be my recommendation (close the PR)
121 2016-03-31 17:52:58	0|NicolasDorier|ok did it
122 2016-03-31 17:53:00	0|wumpus|NicolasDorier: yes I think so, we can always bring it back when it's time
123 2016-03-31 17:53:01	0|morcos|NicolasDorier: I actually thought until today that we shouldn't even have the LOCKTIME_VERIFY_SEQUENCE flag at all
124 2016-03-31 17:53:06	0|GitHub28|[13bitcoin] 15NicolasDorier closed pull request #7574: Remove STANDARD_LOCKTIME_VERIFY_FLAGS and mempool policy's flags (06master...06removeFlag) 02https://github.com/bitcoin/bitcoin/pull/7574
125 2016-03-31 17:53:34	0|NicolasDorier|morcos, I think there is case where we need it
126 2016-03-31 17:53:36	0|morcos|but now I think by my own argument we should have that, so that we have a way to specify for the mempool whether it should enforce that or not
127 2016-03-31 17:53:54	0|NicolasDorier|if the fork is not activated, the flag is off
128 2016-03-31 17:54:04	0|morcos|For consensus its not needed, because you can just check for the CSV soft fork activation and then not even call SequenceLocks if it isn't activated
129 2016-03-31 17:54:35	0|morcos|No reason to call it with no flag and have it just short circuit
130 2016-03-31 17:55:36	0|NicolasDorier|ah yes I see what you mean
131 2016-03-31 17:55:37	0|morcos|I think we properly abstract a set of rules and a way to determine whether they are active (and this can be consensus or standardness) its possible that just the flags bitfield is the right way to do this, i'm not sure
132 2016-03-31 17:56:58	0|morcos|It seems like what you really want is a way to do that for the mempool.  What is active now
133 2016-03-31 17:57:08	0|morcos|For blocks you recreate that set of flags each block
134 2016-03-31 17:57:20	0|morcos|but for the mempool, you want to know what was active as of the last block
135 2016-03-31 17:57:43	0|morcos|maybe thats somethign we should just save as a global from connectBlock or maybe there is a better way
136 2016-03-31 17:57:44	0|wumpus|well not exactly that, I think
137 2016-03-31 17:57:53	0|wumpus|usually we start enforcing things for the mempool first
138 2016-03-31 17:57:59	0|morcos|wumpus: well you want AT LEAST that
139 2016-03-31 17:58:10	0|wumpus|I think for the mempool you want to do *everything*
140 2016-03-31 17:58:29	0|wumpus|there's generally no point in merging a softfork and not enforcing it for the mempool
141 2016-03-31 17:58:45	0|morcos|wumpus: I don't like it that in the mempool you are separately constructing that list of rules for the mempool via the STANDARD_FLAGS
142 2016-03-31 17:59:11	0|morcos|I think somehow you should have the STANDARD_FLAGS and the currently active consensus flags
143 2016-03-31 17:59:26	0|morcos|instead we have STANDARD_FLAGS and sort of original consensus flags
144 2016-03-31 17:59:34	0|wumpus|well sure, the standard flags need to be stricter than anything that is currently active
145 2016-03-31 18:00:22	0|wumpus|I'm sure that could be implemented with more clarity, but effectively I think it's doing the right thing. Standard has alwasy been "be as strict as possible, above and beyond what consensus requires"
146 2016-03-31 18:00:51	0|wumpus|there's nothing wrong with having a mechanism that checks and makes sure that that is the case, of course
147 2016-03-31 18:01:51	0|wumpus|another thing is that the rules for the mempool should be invariant over a run, otherwise there may be old transactions in the mempool from earlier (before catching up) before some new rules were added
148 2016-03-31 18:02:41	0|morcos|yeah i keep getting concerned around mempool issues during a soft fork activation
149 2016-03-31 18:02:47	0|morcos|but i don't think there are any current problems
150 2016-03-31 18:03:22	0|morcos|wumpus: did you see my prior comment on alert chain triggering.  i'm not pro removal
151 2016-03-31 18:03:31	0|morcos|i'm NOW pro removal i mean
152 2016-03-31 18:03:51	0|morcos|bad-chain alert triggering, ugh, i can't type today
153 2016-03-31 18:04:15	0|wumpus|well as long as the mempool already enforces a rule *before* the softfork triggers, something we always make sure, there should be no problem
154 2016-03-31 18:04:35	0|wumpus|morcos: yes I saw, I think we should discuss it at the meeting but the prevailing sentiment seems to be to remove it for 0.12.1
155 2016-03-31 18:04:36	0|wumpus|morcos: yes I saw, I think we should discuss it at the meeting but the prevailing sentiment seems to be to remove it for 0.12.1
156 2016-03-31 18:06:27	0|morcos|ok, i'll be back for that
157 2016-03-31 18:12:55	0|gmaxwell|morcos: Just comining into the discussion but we prefer a behavior change be throughly non-standard on the whole network before a soft-fork activates so that unupgraded software does not get itself orphaned. Generally a soft-fork should not be invalidating any transactions honest users are actually making. (MTP is special in my view because the 'invalidation' is merely a short delay, and there w
158 2016-03-31 18:13:02	0|gmaxwell|ere very few timelocked transactions being made)
159 2016-03-31 18:13:32	0|gmaxwell|and so since we'd want to make that transistion a version or two ahead, there really isn't a reason to make sure we re-filter the mempool.
160 2016-03-31 18:19:40	0|NicolasDorier|not enforcing a sf in mempool before activation may also be an attack. For example MTP, if it was not pushed in mempool for 0.11, when it would have been enforced by miners, someone can flood the network of old nodes by making replacement transaction whci never can confirm but can still be propagated.
161 2016-03-31 18:20:04	0|zooko`|The Zcash project has an issue ticket to track "hard-fork detection", which I currently think is the same thing or
162 2016-03-31 18:20:20	0|zooko`|at least closely related to the bad-chain-alert-triggering that you're talking about
163 2016-03-31 18:20:23	0|zooko`|disabling: https://github.com/zcash/zcash/issues/131#issuecomment-204063197
164 2016-03-31 18:21:23	0|sipa|zooko: no, this is about partition detection; hard forks are much easier to detect: you see a longer but invalid chain
165 2016-03-31 18:21:37	0|zooko|sipa: oh, thanks.
166 2016-03-31 18:24:40	0|sipa|morcos: see my comments on the PR
167 2016-03-31 18:25:02	0|sipa|morcos: i don't know what the reason is for the actual false firing we frequently see now
168 2016-03-31 18:33:32	0|sipa|morcos: i actually have no idea how much block timestamps are off
169 2016-03-31 18:35:31	0|gmaxwell|I doubt it's block timestamps.
170 2016-03-31 18:36:42	0|gmaxwell|one cause of false firing is correct but uninteresting firing. E.g. not enough blocks shows up on my laptop when I leave the office and go to dinner and such on the way home, then for the next week until I restart I'm left with this stupid not enough blocks warning.
171 2016-03-31 18:37:37	0|gmaxwell|It's unfortunate that this was constructed without a clear model of the kinds of true positives it was trying to detect.
172 2016-03-31 18:37:40	0|helo|should it be bother-until-dismissed?
173 2016-03-31 18:39:43	0|helo|in -qt, that is
174 2016-03-31 18:39:54	0|gmaxwell|thats obnoxious too, what is the threat you hope to solve by telling people their network connection _used_ to be down?
175 2016-03-31 18:40:56	0|gmaxwell|without an argument, that just sounds like another kind of false positive: we commanded the users attention where no action was actually required on their part.  Creating more reason to ignore any further warnings.
176 2016-03-31 18:47:20	0|morcos|gmaxwell: i'm surprised you don't think its the block time stamps
177 2016-03-31 18:47:40	0|morcos|as soon as the current tip is over 130 mins old by its own time stamp, that'll cause an alert
178 2016-03-31 18:48:02	0|helo|potentially bad (but probably not) might warrant getting someone's attention... -paranoialevel=N
179 2016-03-31 18:48:10	0|morcos|that seems likely to happen, if say it was mined with a time an hour in the past and it was another 70 mins before the next block was found
180 2016-03-31 18:48:16	0|dgenr8|sipa: you can get a quick idea from tac debug.log | grep UpdateTip | awk '{printf("%s %s\n", $2, $10);}
181 2016-03-31 18:50:32	0|dgenr8|'
182 2016-03-31 18:50:33	0|dgenr8|'
183 2016-03-31 18:56:01	0|morcos|and even if that isn't the cause, it allows any miner to make a false alert more likely by just using an old timestamp
184 2016-03-31 18:56:34	0|sipa|in the short term i am mostly concernes with fixing the spurious alerts
185 2016-03-31 18:56:56	0|sipa|longer term, we should think hard about what the cases are to detect
186 2016-03-31 18:57:29	0|sipa|for example, if miners would intentionally keep timestamps low, isn't that something to alert about as well?
187 2016-03-31 18:58:27	0|jonasschnelli|Right? The meeting is now +1 on GMT?
188 2016-03-31 18:58:28	0|dgenr8|time warp
189 2016-03-31 18:58:36	0|wumpus|yes I think so
190 2016-03-31 18:59:04	0|wumpus|no, I mean meeting is +0 UTC, but that's now isn't it?
191 2016-03-31 18:59:05	0|Luke-Jr|?
192 2016-03-31 18:59:16	0|Luke-Jr|my calendar says it should start right now
193 2016-03-31 18:59:20	0|paveljanik|yup
194 2016-03-31 18:59:21	0|petertodd|Luke-Jr: ack
195 2016-03-31 18:59:39	0|wumpus|meeting is in Reykjavik time, they don't have DST
196 2016-03-31 18:59:45	0|lightningbot|Meeting started Thu Mar 31 18:59:45 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
197 2016-03-31 18:59:45	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
198 2016-03-31 18:59:45	0|wumpus|#startmeeting
199 2016-03-31 19:00:16	0|wumpus|action points from last meeting: ACTION: review more at https://github.com/bitcoin/bitcoin/pull/7648 (wumpus, 19:05:42)    done and merged
200 2016-03-31 19:00:27	0|jonasschnelli|topic proposal (short): p2p layer encryption
201 2016-03-31 19:00:34	0|wumpus|ACTION: hunt down miners that mine MTP violations <- don't know about this one
202 2016-03-31 19:00:49	0|wumpus|main topic is the softfork backports I think
203 2016-03-31 19:00:50	0|wumpus|main topic is the softfork backports I think
204 2016-03-31 19:01:16	0|sipa|topic: short update on segwit and segnet4
205 2016-03-31 19:01:28	0|wumpus|cool
206 2016-03-31 19:01:43	0|wumpus|#topic short update on segwit and segnet4
207 2016-03-31 19:02:00	0|cfields|topic suggestion: net-refactor update
208 2016-03-31 19:02:33	0|sipa|segwit code progressed a lot the past few days; it now passes all preexisting rpc tests and unit tests, and many bugs were fixed in the process
209 2016-03-31 19:02:48	0|jonasschnelli|Nice!
210 2016-03-31 19:02:51	0|wumpus|good to hear!
211 2016-03-31 19:02:52	0|petertodd|sipa: +1
212 2016-03-31 19:03:00	0|jonasschnelli|also had no crash on my segnet4 node.. :)
213 2016-03-31 19:03:27	0|sipa|it's also rebased on top of the bip68/112/113 backport, and a new segnet (segnet4) is up and running with bip9 activation logic
214 2016-03-31 19:03:53	0|gmaxwell|morcos: my uncertanty comes from looking at some incidents and it not being obvious what the cause was in them.
215 2016-03-31 19:04:01	0|gmaxwell|it's not well founded uncertanty.
216 2016-03-31 19:04:12	0|gmaxwell|oops. [sorry for OT]
217 2016-03-31 19:04:24	0|sipa|lastly, i have significantly reorganized the commits in the branch to 1) define segnet 2) add consensus/node logic 3) add wallet logic 4) add tests
218 2016-03-31 19:04:48	0|sipa|so that upgrade tests from pre-segwit code post fork can be tested
219 2016-03-31 19:04:58	0|sipa|and so that the consensus critical part can be reviewed separately
220 2016-03-31 19:05:16	0|morcos|sipa: i think it would be hugely beneficial if you could come up with a list of things you'd like other people to work on to move this forward
221 2016-03-31 19:05:26	0|sipa|ack, will do
222 2016-03-31 19:05:49	0|cfields|yes, that would be great
223 2016-03-31 19:06:07	0|petertodd|I should add segwit to python-bitcoinlib...
224 2016-03-31 19:06:07	0|sipa|the next thing i will do myself is write script unit tests, as we are not testing all possible witness validation failures
225 2016-03-31 19:06:50	0|gmaxwell|As far as the MTP huntdown, sdaftuar checked to see if there were violations already, and there weren't. I need to start generating mtp violating transactions, but haven't done this yet.
226 2016-03-31 19:07:07	0|petertodd|sipa: ah cool - are you going to do that with the existing script_(in)valid.json framework?
227 2016-03-31 19:07:42	0|sipa|there are some unusual things to test that are not typivally needed for softforks, such as the preferential peering (oh, that's implemented too; on top of the service bits enforcement logic), rewind testing, ...
228 2016-03-31 19:07:46	0|sipa|petertodd: yes
229 2016-03-31 19:08:18	0|btcdrak|#link https://github.com/bitcoin/bitcoin/compare/0.12...sipa:segwit
230 2016-03-31 19:08:20	0|wumpus|#action start generating mtp violating transactions (gmaxwell)
231 2016-03-31 19:08:29	0|petertodd|sipa: how are you going to add segwit support to it? (I was just updating python-bitcoinlib's script unit tests yesterday along those lines)
232 2016-03-31 19:08:51	0|sipa|petertodd: tbd, i'm sure i'll find a way
233 2016-03-31 19:09:00	0|sipa|but i haven't looked into it deeply
234 2016-03-31 19:09:56	0|sipa|EOT? (end of topic)
235 2016-03-31 19:10:20	0|sipa|btcdrak: no, use segwit-base...segwit
236 2016-03-31 19:10:33	0|sipa|(so you don't see the backports before segwit)
237 2016-03-31 19:10:57	0|wumpus|ok
238 2016-03-31 19:11:21	0|wumpus|#topic net-refactor update
239 2016-03-31 19:11:52	0|wumpus|@cfields
240 2016-03-31 19:11:56	0|cfields|ok. I've pushed an up-to-date version to my net-refactor10 branch...
241 2016-03-31 19:12:13	0|cfields|at this point, it's ready for testing and review, but i'm not entirely sure how to proceed
242 2016-03-31 19:12:29	0|wumpus|ohh I'm two branches behind
243 2016-03-31 19:12:30	0|wumpus|ohh I'm two branches behind
244 2016-03-31 19:13:01	0|wumpus|what is unclear?
245 2016-03-31 19:13:04	0|cfields|atm it's just 2 huge commits. I'm not sure how much it's worth going in and splitting into logical chunks, because it's really one big change...
246 2016-03-31 19:13:14	0|btcdrak|sipa: this then? https://github.com/sipa/bitcoin/compare/segwit-base...sipa:segwit
247 2016-03-31 19:13:20	0|sipa|btcdrak: ack
248 2016-03-31 19:13:33	0|wumpus|well if it is one big change it should be one commit
249 2016-03-31 19:13:49	0|wumpus|splitting makes sense if there are atomic changes
250 2016-03-31 19:14:13	0|wumpus|especially if they're somewhat independent
251 2016-03-31 19:14:24	0|cfields|also, it needs a bunch of unit tests, which I'm still working on a framework for. For catching stupid things like max connections, etc
252 2016-03-31 19:15:06	0|cfields|wumpus: sure. what I'm not clear on is if I should try to refactor current master to make it easier to slide in the other changes, or just plan to do it all in one go
253 2016-03-31 19:15:07	0|cfields|wumpus: sure. what I'm not clear on is if I should try to refactor current master to make it easier to slide in the other changes, or just plan to do it all in one go
254 2016-03-31 19:15:37	0|cfields|s/refactor/PR small refactoring chunks/
255 2016-03-31 19:15:50	0|wumpus|I don't know. I'd try it first in one go, if people complain about it being to much you can always decide to do it in multiple phases.
256 2016-03-31 19:16:33	0|cfields|ok. Well, next steps are adding tons of docs and tests. But at this point, I'm happy to have people test and point out any brokenness
257 2016-03-31 19:17:30	0|wumpus|congrats :)
258 2016-03-31 19:17:40	0|cfields|I suppose that's it for now
259 2016-03-31 19:18:12	0|wumpus|unfortunately this comes at a time that people are really busy, so I hope they can spare enough review cycles, to get this in for 0.13
260 2016-03-31 19:18:42	0|cfields|wumpus: understood. I'm starting to doubt whether it makes sense for .13.
261 2016-03-31 19:18:59	0|sipa|when is the feature freeze for 0.13?
262 2016-03-31 19:18:59	0|wumpus|#topic softfork backports
263 2016-03-31 19:19:00	0|jonasschnelli|I have already started reviewing it but need to read myself more into libevent first.
264 2016-03-31 19:19:14	0|petertodd|cfields: well, keep in mind that what's keeping everyone busy is stuff that'll be backported
265 2016-03-31 19:19:17	0|jtimon|NicolasDorier:
266 2016-03-31 19:19:18	0|jtimon|NicolasDorier:
267 2016-03-31 19:19:20	0|btcdrak|backports are #7543 and #7716
268 2016-03-31 19:19:24	0|cfields|jonasschnelli: for the sake of review, I'd say you can do it in 2 main chunks
269 2016-03-31 19:19:41	0|cfields|first, libbtcnet can be considered to be a black box that works as intended
270 2016-03-31 19:19:53	0|jtimon|what? it was a suggestion for extension, I think you got simplifications I missed'
271 2016-03-31 19:19:57	0|cfields|then, reviewing libbtcnet itself
272 2016-03-31 19:20:04	0|wumpus|sipa: 2016-05-15 https://github.com/bitcoin/bitcoin/issues/7679
273 2016-03-31 19:20:11	0|btcdrak|so #7543 is a straight up cherry-pick from master, easy peasy.
274 2016-03-31 19:20:30	0|btcdrak|#7716 needs a bit more review, but the tests, as per the comments make it quite easy to verify.
275 2016-03-31 19:20:40	0|sipa|i gave a command line for easy mechanical review of 7543 :)
276 2016-03-31 19:20:41	0|sipa|i gave a command line for easy mechanical review of 7543 :)
277 2016-03-31 19:20:50	0|morcos|"easy"
278 2016-03-31 19:21:13	0|btcdrak|#7543 has 5 tested ACKs so far. It should be ready for merge.
279 2016-03-31 19:21:38	0|jtimon|NicolasDorier: seriously if someone else could do it I think we could be much more objective combined (I'm probably too biased with my consensus branch)
280 2016-03-31 19:22:04	0|phantomcircuit|cfields: link to current net refactor work?
281 2016-03-31 19:22:37	0|wumpus|agree on the 0.12 backport btcdrak
282 2016-03-31 19:22:46	0|cfields|phantomcircuit: https://github.com/theuni/bitcoin/tree/net-refactor10
283 2016-03-31 19:22:52	0|wumpus|#action #7543 has 5 tested ACKs so far. It should be ready for merge
284 2016-03-31 19:23:28	0|btcdrak|wumpus: I'll go round bugging more people for review of #7716 this week.
285 2016-03-31 19:24:15	0|morcos|I know this may be controversial, but I'd argue that it is worse to provide backports for 0.11 than not
286 2016-03-31 19:24:19	0|wumpus|#link  https://github.com/theuni/bitcoin/tree/net-refactor10
287 2016-03-31 19:24:39	0|cfields|btcdrak: you bugged me last week but i didn't get to them. Will review both right after the meeting.
288 2016-03-31 19:24:40	0|cfields|btcdrak: you bugged me last week but i didn't get to them. Will review both right after the meeting.
289 2016-03-31 19:25:06	0|wumpus|what would be the effect of not backporting to 0.11?
290 2016-03-31 19:25:11	0|morcos|It's very difficult to provide sufficient enough review.  You could have backported those soft forks to 0.11 in a way that passed both the existing unit tests and was broken if you didn't know you needed to change both
291 2016-03-31 19:25:38	0|morcos|I think we are doing our "customers" a better service by not putting our stamp of approval on something we can't give as high a degree of safety to
292 2016-03-31 19:25:57	0|morcos|Just a though, given that segwit will also likely be difficult to get properly tested in 0.11
293 2016-03-31 19:26:25	0|gmaxwell|I've had this thought too. Unfortunately none of the users of these things will give us any feedback.
294 2016-03-31 19:26:26	0|petertodd|morcos: ack - and also, esp. from miners, do we have a clear request to do a backport?
295 2016-03-31 19:26:33	0|wumpus|do miners use 0.11?
296 2016-03-31 19:26:58	0|wumpus|if not, backporting softfork to 0.11 is not *that* important
297 2016-03-31 19:27:06	0|phantomcircuit|wumpus: miners use git master...
298 2016-03-31 19:27:08	0|morcos|This is an opensource project anyway, nothing stopping other people from backporting to 0.11 themselves
299 2016-03-31 19:27:21	0|wumpus|sure, but we have a PR open for 0.11
300 2016-03-31 19:27:23	0|morcos|We should concentrate our efforts where they will be most effective
301 2016-03-31 19:27:23	0|sdaftuar|hah - low probability of getting that right
302 2016-03-31 19:27:29	0|wumpus|people that want it can review it
303 2016-03-31 19:27:31	0|sdaftuar|but agree that it's difficult to review
304 2016-03-31 19:27:55	0|wumpus|if no one wants it, no one should review it
305 2016-03-31 19:28:04	0|wumpus|so the decision would be more 'backport to 0.11 should block 0.12 deployment'
306 2016-03-31 19:28:14	0|btcdrak|wumpus: I know of some miners who are still on 0.11.2 but plan to upgrade, but instead are waiting for 0.12.1 now.
307 2016-03-31 19:28:18	0|petertodd|how about we mention that we haven't done a backport in the release notes for 0.12.x, and make it clear that if people do what that they should let us know?
308 2016-03-31 19:28:21	0|morcos|wumpus: But what I'm saying is we seem to have set a requirement for ourselves that we will backport 2 major versions, and so we waste a lot of development resources doing that for a questionable quality product
309 2016-03-31 19:28:29	0|Luke-Jr|wumpus: yes, miners still use 0.11
310 2016-03-31 19:28:38	0|wumpus|morcos: well the plan was to release 0.11.3 and 0.12.1 at the same time
311 2016-03-31 19:28:48	0|Luke-Jr|wumpus: and that is likely to remain the case for some time
312 2016-03-31 19:28:52	0|wumpus|that means that 0.11.3 will block 0.12.1
313 2016-03-31 19:29:09	0|morcos|Yes thats what i'm objecting to!
314 2016-03-31 19:29:22	0|btcdrak|I disagree with morcos that 0.11 is so difficult. We do have a pretty decent set of functional tests, and the 0.11 backport passes those.
315 2016-03-31 19:29:30	0|jonasschnelli|cat dnsseed.dump | grep "  100.00% 100.00%" | grep "/Satoshi:0.11." | wc -l    ---> 1581
316 2016-03-31 19:29:34	0|jonasschnelli|cat dnsseed.dump | grep "  100.00% 100.00%" | grep "/Satoshi:0.12." | wc -l --> 1276
317 2016-03-31 19:29:35	0|jonasschnelli|cat dnsseed.dump | grep "  100.00% 100.00%" | grep "/Satoshi:0.12." | wc -l --> 1276
318 2016-03-31 19:29:47	0|jonasschnelli|I think a BP for 0.11 would be good.
319 2016-03-31 19:30:13	0|wumpus|mind that 0.12 isn't very old yet, and it's still at .0, lots of people wait for .1 releases to deploy it
320 2016-03-31 19:30:22	0|morcos|btcdrak: i think the 0.11 backport is correct.  but it would have been easy to get wrong and still could be
321 2016-03-31 19:30:24	0|btcdrak|morcos: so far 3 people have tested #7716.
322 2016-03-31 19:30:32	0|Luke-Jr|wumpus: it also has no well-tested CPFP yet ;)
323 2016-03-31 19:30:34	0|morcos|yes and 2 of them think it was a waste of time
324 2016-03-31 19:31:00	0|wumpus|so can we get people that use 0.11.x involved in testing it?
325 2016-03-31 19:31:01	0|btcdrak|For the record, I am fine not to backport to 0.11
326 2016-03-31 19:31:12	0|morcos|anyway, this is potentially off topic, but i think its more important that this project spend its resources getting segwit deployed
327 2016-03-31 19:31:15	0|wumpus|this is an open source project, so at some point it's scratch your own itch
328 2016-03-31 19:31:16	0|wumpus|this is an open source project, so at some point it's scratch your own itch
329 2016-03-31 19:31:18	0|morcos|than deploying CSV to 0.11
330 2016-03-31 19:31:22	0|jonasschnelli|morcos : +1
331 2016-03-31 19:31:29	0|morcos|wumpus: sure, so lets not delay 0.12.1
332 2016-03-31 19:31:30	0|jl2012|Anyway, I think it's unlikely to backport segwit to 0.11, so I don't think we really need to backport CSV to 0.11
333 2016-03-31 19:31:30	0|paveljanik|+1
334 2016-03-31 19:31:31	0|jl2012|Anyway, I think it's unlikely to backport segwit to 0.11, so I don't think we really need to backport CSV to 0.11
335 2016-03-31 19:31:38	0|btcdrak|+1
336 2016-03-31 19:31:39	0|morcos|jl2012: thanks
337 2016-03-31 19:31:41	0|wumpus|but what if bbackporting to 0.11.x helps segwit deployment, by making sure miners use it?
338 2016-03-31 19:31:46	0|gmaxwell|0.11 is also so low in performance relative to 0.12 that there are many reasons not to run it.
339 2016-03-31 19:31:50	0|wumpus|ok
340 2016-03-31 19:31:52	0|btcdrak|please can we merge 7543 and start the RC phase.
341 2016-03-31 19:31:57	0|jonasschnelli|Agree with wumpus: 0.12 is relatively new. The time will also works towers 0.12 adaptation.
342 2016-03-31 19:32:04	0|jonasschnelli|towards
343 2016-03-31 19:32:05	0|morcos|btcdrak: well that brings us to next topic, bad-chain alerts
344 2016-03-31 19:32:06	0|morcos|btcdrak: well that brings us to next topic, bad-chain alerts
345 2016-03-31 19:32:07	0|Luke-Jr|it may be easier to get morcos's new CPFP stuff tested well
346 2016-03-31 19:32:10	0|gmaxwell|it is premature to RC on 0.12 at this second. (maybe in a couple days)
347 2016-03-31 19:32:18	0|wumpus|it'd be better if we would have first done a bugfix release for 0.12
348 2016-03-31 19:32:20	0|morcos|Luke-Jr: heh, thanks but sdaftuar's
349 2016-03-31 19:32:24	0|Luke-Jr|oh, oops
350 2016-03-31 19:32:36	0|btcdrak|morcos: this is my answer to back chain alerts for 0.12.1 https://github.com/bitcoin/bitcoin/compare/0.12...btcdrak:spurious
351 2016-03-31 19:32:48	0|wumpus|then again I know of no *serious* bugs in 0.12
352 2016-03-31 19:32:51	0|btcdrak|disable them for 0.12.1 and if we get them fixed, we can add back to 0.12.2
353 2016-03-31 19:33:05	0|wumpus|new topic bad chain alerts?
354 2016-03-31 19:33:06	0|morcos|btcdrak: i think i mostly agree with that
355 2016-03-31 19:33:11	0|wumpus|#topic bad chain alerts
356 2016-03-31 19:33:59	0|gmaxwell|is that bad "chain alerts" or "bad chain" alerts? :)
357 2016-03-31 19:34:14	0|jonasschnelli|second.
358 2016-03-31 19:34:23	0|wumpus|hehe both
359 2016-03-31 19:34:27	0|sipa|(bad ((bad chain) alerts))
360 2016-03-31 19:34:29	0|gmaxwell|I think it's actually more the first.
361 2016-03-31 19:34:36	0|btcdrak|sipa: groan
362 2016-03-31 19:34:43	0|morcos|wumpus: i think the proper thing to do here is properly research what was causing the false positives.
363 2016-03-31 19:34:53	0|wumpus|so, disable for now, then try to fix in master, if that succeeds backport to 0.12.2?
364 2016-03-31 19:35:00	0|morcos|that would be my vote
365 2016-03-31 19:35:01	0|btcdrak|wumpus: +1
366 2016-03-31 19:35:01	0|morcos|that would be my vote
367 2016-03-31 19:35:03	0|gmaxwell|+1
368 2016-03-31 19:35:04	0|gmaxwell|+1
369 2016-03-31 19:35:05	0|sdaftuar|ack
370 2016-03-31 19:35:06	0|sdaftuar|ack
371 2016-03-31 19:35:20	0|gmaxwell|We urgently must stop the false positives or the facility becomes completely useless.
372 2016-03-31 19:35:29	0|wumpus|morcos: I agree, hurriedly backporting an improvement that isn't even merged in master yet is probably a bad idea
373 2016-03-31 19:35:32	0|morcos|wasn't MeniRosenfelds calculation that the existing code should be generating an alert once every 3 years, well i think something is off