1 2017-06-28 00:00:04	0|sipa|sdaftuar: is there a good reason to support that?
  2 2017-06-28 00:00:23	0|BlueMatt|i dont think its "permitted"
  3 2017-06-28 00:00:35	0|BlueMatt|there should be no way to call it except permiscuousmempoolflags
  4 2017-06-28 00:00:40	0|BlueMatt|which is a testing-only thing
  5 2017-06-28 00:00:40	0|sipa|i mean: we should have an assert for it
  6 2017-06-28 00:01:09	0|sipa|just as there is an asserts that prevents CLEANSTACK without P2SH/WITNESS
  7 2017-06-28 00:01:40	0|BlueMatt|meh? I mean its testing-only, if it doesnt crash why bother making it?
  8 2017-06-28 00:01:44	0|BlueMatt|just complicates testing of it
  9 2017-06-28 00:01:51	0|BlueMatt|it being script generally
 10 2017-06-28 00:02:30	0|sipa|i like that every script execution flag is a softfork wrt any other combinations of script execution flags
 11 2017-06-28 00:02:39	0|sipa|i think upgradable nops is the only exception
 12 2017-06-28 00:03:09	0|PRab|nm, I got it. I had to add --upgrade to the end of the existing gbuild command.
 13 2017-06-28 00:10:14	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10686: Avoid usage of uninitialized values in function call arguments (06master...06uninitialized-arguments) 02https://github.com/bitcoin/bitcoin/pull/10686
 14 2017-06-28 06:26:16	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10649: Make sure we only mine via the first wallet (06master...062017/06/wallet_generate) 02https://github.com/bitcoin/bitcoin/pull/10649
 15 2017-06-28 07:06:18	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #10688: contrib: Update laanwj key (06master...062017_06_laanwj_key) 02https://github.com/bitcoin/bitcoin/pull/10688
 16 2017-06-28 07:15:17	0|wumpus|PRab: yes, upgrades are not persistent, it happens every gbuild on the copied image
 17 2017-06-28 07:15:48	0|wumpus|there's no documented way to upgrade the base image - I tried it last time but ended up with 3 versions of gcc installed and a wrong gitian output :)
 18 2017-06-28 07:22:06	0|bitcoin-git|13bitcoin/06master 1422378ad 15Alex Morcos: Remove no longer used mempool.exists(outpoint)
 19 2017-06-28 07:22:06	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/acb11535cb84...a381f6a5bdc2
 20 2017-06-28 07:22:07	0|bitcoin-git|13bitcoin/06master 14a381f6a 15Wladimir J. van der Laan: Merge #10684: Remove no longer used mempool.exists(outpoint)...
 21 2017-06-28 07:22:36	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10684: Remove no longer used mempool.exists(outpoint) (06master...06lessHaveCoin) 02https://github.com/bitcoin/bitcoin/pull/10684
 22 2017-06-28 07:32:38	0|luke-jr|(but that's what the apt cacher is for)
 23 2017-06-28 07:33:16	0|wumpus|which caches the download, but not the install itself, which still takes some time
 24 2017-06-28 07:33:36	0|wumpus|especially when a release gets older and more updates pile up
 25 2017-06-28 11:28:45	0|bitcoin-git|[13bitcoin] 15tiagmoraismorgado opened pull request #10689: fixing a couple of typos (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/10689
 26 2017-06-28 11:29:50	0|morcos|As an RPC argument, fundrawtransaction uses optIntoRbf, bumpfee uses replaceable, my recent PR used opt_in_rbf for sendtoaddress and sendmany.  Should I instead use replaceable?  (I felt that was maybe too general a word)  Or should I change the preexisting argument names?
 27 2017-06-28 11:54:11	0|wumpus|morcos: from the developer notes, RPC interface guidelines: Argument naming: use snake case `fee_delta` (and not, e.g. camel case `feeDelta`)
 28 2017-06-28 11:54:33	0|wumpus|so opt_in_rbf or replaceable are ok
 29 2017-06-28 11:56:03	0|wumpus|it's unfortunate that there is such a zoo of different argument names for the same
 30 2017-06-28 11:59:08	0|wumpus|for API changes introduced since 0.14 there's still the possibility of normalizing them
 31 2017-06-28 12:07:25	0|morcos|wumpus: oh looks like optIntoRbf was just merged
 32 2017-06-28 12:07:40	0|morcos|so what do you think, make them all replaceable?  and not worry that it sounds a bit too generic
 33 2017-06-28 12:07:54	0|morcos|seems fine to me, the help can always clarify it means BIP-125 replaceable
 34 2017-06-28 12:07:58	0|morcos|and we don't have any other notion for now
 35 2017-06-28 12:07:59	0|wumpus|sounds good to me
 36 2017-06-28 12:08:03	0|morcos|ok will do
 37 2017-06-28 12:08:57	0|wumpus|general is good from an API viewpoint I guess - the user might not care how the replacement works, just that the transaction can be replaced
 38 2017-06-28 12:12:04	0|wumpus|(on the other hand, if different kinds of replacement would be supported, they might want to choose a certain one based on their specific properties... but meh, could always add an additional field for replacement type)
 39 2017-06-28 12:19:35	0|morcos|luke-jr: you ok with changing optIntoRbf and optintorbf that you added in #9672 to replaceable?  should i also change rbfoptin from bitcoin-tx (same PR) ?
 40 2017-06-28 12:19:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/9672 | Opt-into-RBF for RPC & bitcoin-tx by luke-jr · Pull Request #9672 · bitcoin/bitcoin · GitHub
 41 2017-06-28 13:06:32	0|bitcoin-git|13bitcoin/06master 14aa95947 15practicalswift: Use the override specifier (C++11) where we expect to be overriding the virtual function of a base class
 42 2017-06-28 13:06:32	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a381f6a5bdc2...9a941a10101d
 43 2017-06-28 13:06:33	0|bitcoin-git|13bitcoin/06master 149a941a1 15Wladimir J. van der Laan: Merge #10631: Use the override specifier (C++11) where we expect to be overriding the virtual function of a base class...
 44 2017-06-28 13:07:00	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10631: Use the override specifier (C++11) where we expect to be overriding the virtual function of a base class (06master...06overrides-ii) 02https://github.com/bitcoin/bitcoin/pull/10631
 45 2017-06-28 13:25:42	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9527: Enable RBF transactions in wallet by default (06master...06pr/walletrbf) 02https://github.com/bitcoin/bitcoin/pull/9527
 46 2017-06-28 14:01:13	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #10689: fixing a couple of typos (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/10689
 47 2017-06-28 14:03:18	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #10690: [qa] Bugfix: allow overriding extra_args in ComparisonTestFramework (06master...062017-06-comp-framework-extraargs) 02https://github.com/bitcoin/bitcoin/pull/10690
 48 2017-06-28 14:24:24	0|Chris_Stewart_5|There isn't any consensus rule that says coinbase transaction's can't spend outputs is there?
 49 2017-06-28 14:30:26	0|wumpus|coinbase tranactions's input is ignored
 50 2017-06-28 14:30:54	0|instagibbs|Chris_Stewart_5, https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f4358c5ae/src/primitives/transaction.h#L336
 51 2017-06-28 14:38:49	0|sdaftuar|sipa: i think i agree with you that it'd be nice to assert if DISCOURAGE_UPGRADABLE_NOPS is given, but CLTV/CSV are not
 52 2017-06-28 14:39:42	0|sdaftuar|also i assume (someday) DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM could have the same issue
 53 2017-06-28 14:40:34	0|sdaftuar|BlueMatt: i think testing is more complicated, not less, by allowing that combination of script flags
 54 2017-06-28 15:15:49	0|BlueMatt|sdaftuar: fair
 55 2017-06-28 15:30:25	0|sipa|sdaftuar: so, say we adopt a new OP_NOP4 at some point, and a softfork is proposed to deal with it
 56 2017-06-28 15:31:33	0|sipa|we'd make it subject to DISCOURAGE_UPGRADABLE_NOPS only when the new flag is not set
 57 2017-06-28 15:32:48	0|sipa|with an assert that requires upgradable_nops to also have the new SF active, it means you can't enforce a policy of rejecting such transactions in the mempool before the SF happens
 58 2017-06-28 15:33:01	0|sipa|i wonder if that's how we've always done softforks
 59 2017-06-28 15:33:11	0|sdaftuar|i don't think i follow --
 60 2017-06-28 15:33:28	0|sdaftuar|presumably the software that introduces the new OP_NOP4 thing will immediately enforce it in the mempool?
 61 2017-06-28 15:34:05	0|sipa|sure
 62 2017-06-28 15:34:12	0|sdaftuar|upgradable_nops doesn't require the new SF is active, it just requires that your new policy is active
 63 2017-06-28 15:34:18	0|sdaftuar|since upgradable_nops is only ever policy
 64 2017-06-28 15:34:19	0|sipa|sure
 65 2017-06-28 15:34:37	0|sdaftuar|oh!
 66 2017-06-28 15:34:39	0|sdaftuar|now i understand
 67 2017-06-28 15:34:53	0|sipa|but i mean: it seems strange to allow (valid) OP_NOP4 transactions in the mempool before the SF activates
 68 2017-06-28 15:35:03	0|sipa|they'd be mined too
 69 2017-06-28 15:35:11	0|sdaftuar|right, we had this issue with CSV i think
 70 2017-06-28 15:35:28	0|sdaftuar|where we added a special rule on version 2 transactions being rejected pre-activation
 71 2017-06-28 15:36:10	0|sdaftuar|for CLTV, i think we just allowed valid CLTV transactions in the mempool pre-activation
 72 2017-06-28 15:36:59	0|sdaftuar|well, i think what we did for CSV was the right thing.
 73 2017-06-28 15:37:24	0|sipa|for CSV it worked by keeping v2 transactions nonstandard until needed, i think
 74 2017-06-28 15:37:30	0|sdaftuar|yep
 75 2017-06-28 15:37:39	0|sipa|that won't work for every SF
 76 2017-06-28 15:37:58	0|sdaftuar|well the OP_NOP style of SF is probably not long for this world, no?
 77 2017-06-28 15:38:12	0|sdaftuar|i think the question is how do we envision it working in segwit
 78 2017-06-28 15:38:45	0|sipa|same applies to upgradable_witness_program
 79 2017-06-28 15:39:27	0|sdaftuar|so upgradable_witness_program definitely shouldn't be in the mempool pre-activation, i think.
 80 2017-06-28 15:39:33	0|sipa|right
 81 2017-06-28 15:39:54	0|sipa|but i think that requires 3 script flags
 82 2017-06-28 15:40:35	0|sipa|1) discourage_upgradable_witness_program (which does not apply anymore to v1 witness programs)
 83 2017-06-28 15:40:50	0|sipa|2) discourage v1 witness programs
 84 2017-06-28 15:41:10	0|sipa|3) enforce v1 witness program rules
 85 2017-06-28 15:42:11	0|sipa|chain uses none before activation, (3) after
 86 2017-06-28 15:42:32	0|sipa|mempool uses (1)+(2) before activation, (2)+(3) after
 87 2017-06-28 15:44:09	0|sipa|eh, (1)+(3) after
 88 2017-06-28 15:46:38	0|sdaftuar|i think that makes sense, conceptually.  it would be nice if (2) didn't need to waste a script flag bit, though.
 89 2017-06-28 15:49:09	0|sipa|(2) could be twmporary i guess
 90 2017-06-28 15:49:32	0|sipa|as logic for the pre-activation mempool case isn't needed long term
 91 2017-06-28 15:49:39	0|sdaftuar|agreed
 92 2017-06-28 15:49:41	0|sipa|though it may be of longer term use in tests
 93 2017-06-28 16:12:55	0|bitcoin-git|13bitcoin/06master 144ed3653 15Suhas Daftuar: [qa] Bugfix: allow overriding extra_args in ComparisonTestFramework
 94 2017-06-28 16:12:55	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9a941a10101d...416af3edf5b5
 95 2017-06-28 16:12:56	0|bitcoin-git|13bitcoin/06master 14416af3e 15MarcoFalke: Merge #10690: [qa] Bugfix: allow overriding extra_args in ComparisonTestFramework...
 96 2017-06-28 16:13:26	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10690: [qa] Bugfix: allow overriding extra_args in ComparisonTestFramework (06master...062017-06-comp-framework-extraargs) 02https://github.com/bitcoin/bitcoin/pull/10690
 97 2017-06-28 16:27:28	0|bitcoin-git|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/416af3edf5b5...d4e551adfec2
 98 2017-06-28 16:27:29	0|bitcoin-git|13bitcoin/06master 14013a56a 15Pieter Wuille: Non-atomic flushing using the blockchain as replay journal
 99 2017-06-28 16:27:29	0|bitcoin-git|13bitcoin/06master 14b3a279c 15Pieter Wuille: [MOVEONLY] Move LastCommonAncestor to chain
100 2017-06-28 16:27:30	0|bitcoin-git|13bitcoin/06master 140580ee0 15Pieter Wuille: Adapt memory usage estimation for flushing
101 2017-06-28 16:27:41	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10148: Use non-atomic flushing with block replay (06master...06non_atomic_flush) 02https://github.com/bitcoin/bitcoin/pull/10148
102 2017-06-28 16:28:01	0|bitcoin-git|[13bitcoin] 15wraith7 opened pull request #10691: Trivial: Properly comment about shutdown process in init.cpp file. (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10691
103 2017-06-28 16:50:05	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #10692: Make mapBlockIndex and chainActive and all CBlockIndex*es const outside of validation/CChainState (06master...062017-04-const-mapblockindex) 02https://github.com/bitcoin/bitcoin/pull/10692
104 2017-06-28 18:02:57	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10694: Remove redundant code in MutateTxSign(CMutableTransaction&, const std::string&) (06master...06remove-redundant-code-in-MutateTxSign) 02https://github.com/bitcoin/bitcoin/pull/10694
105 2017-06-28 18:11:13	0|morcos|I'm trying to clean up some of the wallet fee logic around minimums and maximums and set fees vs estimates.
106 2017-06-28 18:11:25	0|morcos|When should we obey the global maxtxfee?
107 2017-06-28 18:11:55	0|morcos|Right now we do not obey that for fundrawtransaction, but the changes I was lookign at making would refactor so that fundrawtransaction does obey that
108 2017-06-28 18:12:07	0|BlueMatt|sounds good
109 2017-06-28 18:12:11	0|BlueMatt|consistency above all, imo
110 2017-06-28 18:12:18	0|BlueMatt|actual decision isnt critical, consistency is
111 2017-06-28 18:12:32	0|morcos|But I could see how fundrawtransction is a different beast that maybe you want to be able to ignore that setting for.
112 2017-06-28 18:16:19	0|morcos|similar question for obeying minimums
113 2017-06-28 18:18:57	0|instagibbs|Consistency is my expectation as a user of that api
114 2017-06-28 18:20:49	0|instagibbs|(controls to override are totally fine ofc)
115 2017-06-28 18:22:30	0|bitcoin-git|13bitcoin/06master 14381b8fc 15Matt Corallo: Clarify CCoinsViewMemPool documentation....
116 2017-06-28 18:22:30	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d4e551adfec2...30c21306c171
117 2017-06-28 18:22:31	0|bitcoin-git|13bitcoin/06master 1430c2130 15Pieter Wuille: Merge #10685: Clarify CCoinsViewMemPool documentation....
118 2017-06-28 18:23:00	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10685: Clarify CCoinsViewMemPool documentation. (06master...062017-06-ccoinsviewmempool-doc-cleanup) 02https://github.com/bitcoin/bitcoin/pull/10685
119 2017-06-28 18:26:55	0|instagibbs|my effective feerate did the split out of the max fee check, IIRC you didn't like it at the time
120 2017-06-28 18:42:07	0|luke-jr|morcos: not really. that would break compatibility, and gives a false impression that other transactions aren't replacable.
121 2017-06-28 18:43:51	0|luke-jr|but in terms of normalising to use underscores, IIRC we support multiple names now..
122 2017-06-28 18:44:01	0|luke-jr|so we could do opt_into_rbf|optintorbf?
123 2017-06-28 18:44:10	0|luke-jr|(and the same for older params)
124 2017-06-28 18:44:58	0|bitcoin-git|[13bitcoin] 15sipa pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/30c21306c171...90a002ea647d
125 2017-06-28 18:44:59	0|bitcoin-git|13bitcoin/06master 1421d4afa 15Alex Morcos: Comment clarifications in coins.cpp
126 2017-06-28 18:44:59	0|bitcoin-git|13bitcoin/06master 143c8a9ae 15Alex Morcos: Add belt-and-suspenders in DisconnectBlock...
127 2017-06-28 18:45:00	0|bitcoin-git|13bitcoin/06master 1490a002e 15Pieter Wuille: Merge #10558: Address nits from per-utxo change...
128 2017-06-28 18:45:18	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10558: Address nits from per-utxo change (06master...0610195nits) 02https://github.com/bitcoin/bitcoin/pull/10558
129 2017-06-28 19:47:39	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #10695: [qa] Rewrite BIP65 functional tests (06master...062017-06-fix-bip65-test) 02https://github.com/bitcoin/bitcoin/pull/10695
130 2017-06-28 20:39:56	0|morcos|luke-jr: the main issue is the only argument name already in release is part of bumpfee and it's already called replaceable
131 2017-06-28 20:40:08	0|morcos|so while i agree that opt_in_rbf or similar would be even better
132 2017-06-28 20:40:24	0|morcos|i'm not sure its worth breaking existing API or having multiple names that mean the same thing
133 2017-06-28 20:40:39	0|morcos|and i think perhaps we should just go with replaceable for now?
134 2017-06-28 20:40:54	0|morcos|but i could be convinced otherwise
135 2017-06-28 21:02:12	0|luke-jr|morcos: they're all in release (Knots)
136 2017-06-28 21:03:49	0|luke-jr|but as long as the current name is retained as an alias, it doesn't really break the API
137 2017-06-28 21:10:47	0|BlueMatt|bitcoin core does not support Knots releases, so I dont think you can argue we're tied to Knots' API - Knots can apply patches if it likes
138 2017-06-28 21:14:18	0|luke-jr|Bitcoin Core doesn't NOT support Knots releases either. Knots APIs are not necessarily guaranteed, but we should try to maintain compatibility when reasonable.
139 2017-06-28 21:16:30	0|cfields|BlueMatt: I'm looking at #10652 now. Can you give a bit of context for "Turn mapBlocksInFlight into a multimap" ?
140 2017-06-28 21:16:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt · Pull Request #10652 · bitcoin/bitcoin · GitHub
141 2017-06-28 21:17:28	0|BlueMatt|cfields: sec, redoing pr
142 2017-06-28 21:17:30	0|BlueMatt|give me 30 seconds
143 2017-06-28 21:17:35	0|BlueMatt|i mean not really, just splitting
144 2017-06-28 21:17:47	0|cfields|ok. same one?
145 2017-06-28 21:18:09	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10696: Remove redundant nullptr checks before deallocation (06master...06delete-nullptr) 02https://github.com/bitcoin/bitcoin/pull/10696
146 2017-06-28 21:18:09	0|cfields|if so, please consider ^^ a request for a more thorough commit message :)
147 2017-06-28 21:19:34	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #10697: Do not hold cs_vNodes when making ForEachNode Callbacks (06master...062017-06-cnodestateaccessors-5) 02https://github.com/bitcoin/bitcoin/pull/10697
148 2017-06-28 21:19:40	0|BlueMatt|heh, naa, I was just splitting the pr
149 2017-06-28 21:20:03	0|BlueMatt|cfields: those commits are rebased from #9447
150 2017-06-28 21:20:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/9447 | Allow 2 simultaneous block downloads by morcos · Pull Request #9447 · bitcoin/bitcoin · GitHub
151 2017-06-28 21:21:44	0|cfields|ah ok, thanks
152 2017-06-28 21:22:07	0|BlueMatt|cfields: lemme take a crack at a more expansive commit message since they now lack the context of actually adding simultaneous block downloads
153 2017-06-28 21:22:43	0|cfields|BlueMatt: thanks. the PR title answers my question, though. I just wasn't sure what exactly it was setting the stage for.
154 2017-06-28 21:23:55	0|BlueMatt|yea, its setting the stage for two things - parallel block downloads but also having per-CNodeState locks
155 2017-06-28 21:24:16	0|BlueMatt|the per-CNodeState locks need that change so that you dont hold two at the same time (which would be a lockorder violation)
156 2017-06-28 21:24:47	0|BlueMatt|so you need to MarkBlockAsReceived in the background (ie via CValidationInterface callbacks) and not access the mapBlocksInFlight entries of other peers when you go to download a block
157 2017-06-28 21:28:21	0|BlueMatt|cfields: https://github.com/bitcoin/bitcoin/pull/10652#issuecomment-311797355 sufficient?
158 2017-06-28 21:28:56	0|cfields|yes, thanks
159 2017-06-28 22:00:12	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #10698: Be consistent in calling transactions "replaceable" for Opt-In RBF (06master...062017-06-replaceable-rpc-args) 02https://github.com/bitcoin/bitcoin/pull/10698
160 2017-06-28 22:44:43	0|cfields|BlueMatt: you beat me to 10697 by a day. would it irritate you if i PR'd an alternative? switches to shared/weak ptrs and drops the manual refcounting.
161 2017-06-28 22:47:08	0|BlueMatt|cfields: no, please do!
162 2017-06-28 22:47:25	0|BlueMatt|cfields: my only deadline is...uhh...long after 0.15 :p
163 2017-06-28 22:47:57	0|cfields|BlueMatt: ok. I've been trying to work out how to do it safely (stupid threading), but I think I worked out something dead-simple
164 2017-06-28 22:48:09	0|BlueMatt|cool, sounds good
165 2017-06-28 22:48:10	0|cfields|BlueMatt: well, if I don't get it pushed today/tomorrow, I'll go ahead and ACK yours.
166 2017-06-28 22:48:20	0|BlueMatt|not sure what to do with https://github.com/bitcoin/bitcoin/pull/10697/commits/e4f477b6b02b4a6778ba516edfca5b508ef5a90b though
167 2017-06-28 22:48:24	0|BlueMatt|i guess i can pr it loose
168 2017-06-28 22:49:15	0|cfields|can you explain why it's needed?
169 2017-06-28 22:49:27	0|BlueMatt|heh, see code comment :p
170 2017-06-28 22:49:47	0|BlueMatt|our deadlock detection assumes it is the case, and will otherwise give useless results
171 2017-06-28 22:50:26	0|BlueMatt|because we appear to currently never violate that requirement, better to enforce now instead of risking it breaking in the future and ending up with no working deadlock detection (without running ThreadSanitizer
172 2017-06-28 22:50:28	0|BlueMatt|)
173 2017-06-28 22:50:29	0|cfields|oh, so atm if we have 2 locked, and we invert the unlocks, it just sees that they're both unlocked and doesn't complain?
174 2017-06-28 22:51:13	0|BlueMatt|if we lock A, then lock B, then unlock A, then re-lock A, that may create a deadlock, but will not be detected
175 2017-06-28 22:51:28	0|BlueMatt|cause when we unlocked A, DEBUG_LOCKORDER just assumed that we were unlocking B cause it was the most recent lock
176 2017-06-28 22:52:17	0|cfields|ah, ok
177 2017-06-28 22:52:52	0|BlueMatt|if we ever need it we can tweak DEBUG_LOCKORDER, but we dont now, so easier to just assert correctness in our debug tool and move on
178 2017-06-28 22:53:32	0|sipa|we can easily add a test to verify that an unlock is in fact the last-locked mutex
179 2017-06-28 22:54:47	0|BlueMatt|sipa: yup, thats what I did, just added an assert...its only in debug code anyway
180 2017-06-28 23:16:17	0|gmaxwell|::sigh:: master isn't compiling for me.
181 2017-06-28 23:16:18	0|gmaxwell|qt/libbitcoinqt.a(qt_libbitcoinqt_a-paymentserver.o): In function `payments::Payment::set_merchant_data(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
182 2017-06-28 23:16:22	0|gmaxwell|/home/gmaxwell/bq/src/qt/paymentrequest.pb.h:1600: undefined reference to `google::protobuf::internal::kEmptyString[abi:cxx11]'
183 2017-06-28 23:38:11	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10699: Make all script validation flags backward compatible (06master...0620170628_softflags) 02https://github.com/bitcoin/bitcoin/pull/10699