1 2017-11-14 00:14:36	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #11678: [wip][wallet] Don't shut down after encrypting the wallet (06master...06encrypt-no-restart) 02https://github.com/bitcoin/bitcoin/pull/11678
  2 2017-11-14 01:06:48	0|phantomcircuit|achow101, i have 2m ... somewhere
  3 2017-11-14 01:07:21	0|achow101|phantomcircuit: ??
  4 2017-11-14 01:08:51	0|gmaxwell|achow101: I assume he means testnet coins.
  5 2017-11-14 01:09:12	0|achow101|ah
  6 2017-11-14 01:09:20	0|sipa|in other words: if TN coins ever have a trade value, phantomcircuit will just crash the market?
  7 2017-11-14 01:10:12	0|achow101|one could argue that testnet coins have a trade value now
  8 2017-11-14 01:10:36	0|sipa|iirc it was once 3 BTC for 10000 tnBTC
  9 2017-11-14 01:15:38	0|phantomcircuit|lol
 10 2017-11-14 01:15:42	0|phantomcircuit|sipa, DEAL
 11 2017-11-14 01:15:43	0|phantomcircuit|xd
 12 2017-11-14 01:16:27	0|sipa|haha
 13 2017-11-14 01:16:43	0|sipa|the market may not have been particularly deep back then :p
 14 2017-11-14 01:17:27	0|tloriato|good evening, gentlemen. i was reading a little more about schnorr signatures and i'm pretty excited about it
 15 2017-11-14 01:17:44	0|tloriato|i was wondering if we have any tests already running or an ETA on that?
 16 2017-11-14 01:17:55	0|sipa|tloriato: let's move to #bitcoin-wizards
 17 2017-11-14 01:52:53	0|bitcoin-git|[13bitcoin] 15Thoragh closed pull request #11533: Docs: Update WSL installation notes for Fall Creators update (06master...06Update-WSL-installation-for-Fall-Creators-update) 02https://github.com/bitcoin/bitcoin/pull/11533
 18 2017-11-14 01:56:05	0|midnightmagic|phantomcircuit's not the only one. lol
 19 2017-11-14 01:56:29	0|midnightmagic|Dunno who it was who put all those diff-1 post-block diff hack blocks in there but someone was doing it for hundreds of thousands of blocks.
 20 2017-11-14 02:07:13	0|bitcoin-git|[13bitcoin] 15Thoragh reopened pull request #11533: Docs: Update WSL installation notes for Fall Creators update (06master...06Update-WSL-installation-for-Fall-Creators-update) 02https://github.com/bitcoin/bitcoin/pull/11533
 21 2017-11-14 02:33:27	0|dcousens|any love for a `droptransaction` from mempool rpc call?
 22 2017-11-14 06:09:04	0|phantomcircuit|midnightmagic, that's me
 23 2017-11-14 06:11:16	0|midnightmagic|phantomcircuit: Oh, good then.
 24 2017-11-14 06:15:56	0|warren|dcousens: I'd love that personally
 25 2017-11-14 06:16:49	0|sipa|what for?
 26 2017-11-14 06:33:54	0|wumpus|doesn't abandoning a transaction from the wallet remove it from the mempool?
 27 2017-11-14 06:34:26	0|sipa|iirc you can only abandan a wallet transaction when it already isn't in the mempool
 28 2017-11-14 06:35:07	0|wumpus|you're right, I had that the wrong way around
 29 2017-11-14 06:36:17	0|wumpus|and the wallet adds all its transactions to the mempool at startup
 30 2017-11-14 06:36:30	0|wumpus|(at least if not walletbroadcast=0)
 31 2017-11-14 06:38:21	0|sipa|so basically abandon only works when the tx is already unacceptable to the mempool (due to conflicts with existing chain, or due to mempool full and too low fee)
 32 2017-11-14 06:38:55	0|sipa|a mechanism to forcefully abandon a tx may make sense (though it's hard to prepare for it still being possible to mine)
 33 2017-11-14 06:39:19	0|sipa|but i'm not sure that giving direct access to drop something from the mempool matters
 34 2017-11-14 06:40:15	0|wumpus|there can be cases during development/testing where it can be marginally useful to drop things from the mempool, but it seems to much of a foot shooting option to expose generally
 35 2017-11-14 06:40:25	0|sipa|right, as a debug thing sure
 36 2017-11-14 06:40:38	0|sipa|at the same level as invalidateblock and reconsiderblock
 37 2017-11-14 06:41:59	0|wumpus|warren's case is that he sent a transaction with way too little fee to ever be mined, without RBF, and he wants to try to get rid of it by double-spending it
 38 2017-11-14 06:42:40	0|sipa|right, but you really just want a "force abandon wallet tx" there, rather than the more level "drop from mempool", i think
 39 2017-11-14 06:42:48	0|wumpus|there's no guarantee it will work of course because miners and other nodes might still have it, but he still wants to try
 40 2017-11-14 06:42:57	0|sipa|or even a "force accept this tx, replacing whatever is needed in the mempool"
 41 2017-11-14 06:43:47	0|warren|wumpus: actually I was successful
 42 2017-11-14 06:44:03	0|wumpus|the latter would be nice, as it matches what needs to be done in this case better, if you don't respend the inputs there's always the possibilty that your transaction gets replayed and mined in the future
 43 2017-11-14 06:44:24	0|warren|generally I'd like the ability to remove something from my mempool without wiping the entire thing
 44 2017-11-14 06:46:10	0|wumpus|but anyhow for a diagnostic, undocumented option at the level of invalidateblock/reconsiderblock I woudln't have problems with it
 45 2017-11-14 06:48:00	0|wumpus|it'd be trivial to implement: make a RPC that calls removeRecursive, this will make sure the descendants are removed too
 46 2017-11-14 06:49:37	0|wumpus|and then pray it won't be advertised as a general "cancel transaction" solution by people who have no clue how the mempool works and think it's shared between all nodes
 47 2017-11-14 06:54:59	0|mryandao|would it be possible to add a key-value "tx-rate" for the getmempoolinfo rpc command, where the average tx-rate of the mempool?
 48 2017-11-14 06:55:17	0|mryandao|*fee rate
 49 2017-11-14 06:57:14	0|wumpus|would be easier to keep track of the total amount of fee. But what would that info be useful for?
 50 2017-11-14 06:58:18	0|mryandao|so a user can decide in advance if they should make a transaction now
 51 2017-11-14 06:58:40	0|wumpus|estimatesmartfee would be better for that
 52 2017-11-14 06:59:07	0|mryandao|over the weekend, estimate smart fee wasn't very effective
 53 2017-11-14 06:59:08	0|sipa|or a way to query "what is the feerate in the mempool, X MB from the top"
 54 2017-11-14 06:59:38	0|wumpus|I mean the decision criterion would be the cost to submit a transaction now, not so much what other transaction are paying
 55 2017-11-14 07:00:43	0|wumpus|mryandao: the fee estimation is not perfect, but I'm not sure making people do their own fee estimation based on some (easy to manipulate) stats is a better idea
 56 2017-11-14 07:01:21	0|mryandao|over the weekend, i thought it might also be a good idea to keep track of the rate of growth of the mempool
 57 2017-11-14 07:01:39	0|sipa|mryandao: meh, "infinite" is a good approximation
 58 2017-11-14 07:01:41	0|mryandao|maybe the differential is useful for fee estimation
 59 2017-11-14 07:01:51	0|sipa|the real question is what the size is _above a certain feerate level_
 60 2017-11-14 07:11:29	0|bitcoin-git|[13bitcoin] 15jamesob opened pull request #11680: [docs] Add instructions for lcov report generation (06master...06lcov-docs) 02https://github.com/bitcoin/bitcoin/pull/11680
 61 2017-11-14 07:40:52	0|eck|+1 for tracking the mempool rate-of-growth
 62 2017-11-14 07:41:02	0|eck|and derivatices and higher-order derivatives generally
 63 2017-11-14 07:43:12	0|wumpus|sipa's point is that rate of growth in itself isn't interesting; someone could submit an ~infinite number of low fee transactions to pad your mempool up to mempoolmax, and that should not affect fee estimates
 64 2017-11-14 07:44:10	0|eck|ah
 65 2017-11-14 07:44:14	0|wumpus|so you'd need to track something more subtle
 66 2017-11-14 07:44:29	0|sipa|it isn't interesting, and it also doesn't matter
 67 2017-11-14 07:44:54	0|sipa|if you're willing to pay X feerate, you don't care at all about any transaction that pays less than X, even if there is 10 GB of them
 68 2017-11-14 07:44:57	0|eck|I guess you would need the time derivative of the histogram (if you needed it at all)
 69 2017-11-14 07:50:08	0|bitcoin-git|13bitcoin/06master 1473a7e6d 15Thoragh: Update WSL installation for Fall Creators update
 70 2017-11-14 07:50:08	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5e468994fbb3...cbb54e77a120
 71 2017-11-14 07:50:09	0|bitcoin-git|13bitcoin/06master 14cbb54e7 15Wladimir J. van der Laan: Merge #11533: Docs: Update WSL installation notes for Fall Creators update...
 72 2017-11-14 07:50:56	0|eck|just thinking out loud here, but you could train a simple convolutional filter (for example) to learn the best parameters to estimate a fee rate given the fee histogram from the last N time periods; but you'd have to update the convolution parameters for each bitcoin release, and it would be trivial to find pathological values after the fact to trick the trained algorithm
 73 2017-11-14 07:53:44	0|sipa|eck: no way, we're not putting gameable methods in
 74 2017-11-14 07:53:58	0|sipa|such methods are awesome if they have human oversight
 75 2017-11-14 07:54:18	0|sipa|but you don't want to put them in a fully automated system that is intentionally designed to need user intervention to upgrade :)
 76 2017-11-14 07:54:23	0|eck|that's kind of what i thought, interesting though experiment though
 77 2017-11-14 07:57:07	0|bitcoin-git|13bitcoin/06master 14faaa7db 15MarcoFalke: qa: Only allow disconnecting all NodeConns
 78 2017-11-14 07:57:07	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cbb54e77a120...7adeea3b0fc2
 79 2017-11-14 07:57:08	0|bitcoin-git|13bitcoin/06master 147adeea3 15Wladimir J. van der Laan: Merge #11641: qa: Only allow disconnecting all NodeConns...
 80 2017-11-14 07:57:39	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11641: qa: Only allow disconnecting all NodeConns (06master...06Mf1711-qaNodeConnDisconnectAll) 02https://github.com/bitcoin/bitcoin/pull/11641
 81 2017-11-14 08:13:34	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10873: Use a condition variable for shutdown notifications (06master...06shutdown_notify) 02https://github.com/bitcoin/bitcoin/pull/10873
 82 2017-11-14 08:23:47	0|meshcollider|It seems 10873 is a candidate to be the first PR with the new abandoned tag MarcoFalke created ^
 83 2017-11-14 08:27:21	0|wumpus|good idea, added
 84 2017-11-14 08:36:43	0|mryandao|how about taking the differential of transactions that pay a feerate greater than the min-feerate of the next block as described by `getblocktemplate`
 85 2017-11-14 08:37:24	0|mryandao|it should be meaningful to see the rate of incoming transaction "overtaking" transactions that should be confirmed in the following block
 86 2017-11-14 08:58:37	0|bitcoin-git|[13bitcoin] 15SwaddleDoddle opened pull request #11681: 0.15 (06master...060.15) 02https://github.com/bitcoin/bitcoin/pull/11681
 87 2017-11-14 09:00:04	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11681: 0.15 (06master...060.15) 02https://github.com/bitcoin/bitcoin/pull/11681
 88 2017-11-14 09:11:52	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11682: wallet: Simplify logic in CCryptoKeyStore::AddKeyPubKey(...) (06master...06CCryptoKeyStore-AddKeyPubKey) 02https://github.com/bitcoin/bitcoin/pull/11682
 89 2017-11-14 09:19:08	0|meshcollider|Anyone wanna review https://github.com/bitcoin-core/bitcoincore.org/pull/464 so it can be merged soon?
 90 2017-11-14 09:19:22	0|meshcollider|(0.15.1 release announcement on bitcoincore.org)
 91 2017-11-14 09:19:42	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11683: tests: Remove unused mininode functions deser_int_vector(f) and ser_int_vector(l) (06master...06remove-int-vector-serialization) 02https://github.com/bitcoin/bitcoin/pull/11683
 92 2017-11-14 09:22:10	0|wumpus|meshcollider: will do
 93 2017-11-14 09:22:40	0|meshcollider|wumpus: thanks
 94 2017-11-14 09:37:36	0|wumpus|I don't think anyone will mind if I merge it?
 95 2017-11-14 09:39:30	0|meshcollider|Shouldn't do, ACKs from both you and bluematt and its basically just a c+p of the release notes so its not exactly controversial :P
 96 2017-11-14 09:39:44	0|wumpus|and it's about time too
 97 2017-11-14 09:40:37	0|meshcollider|Still not as delayed as 15.0.1 was lol
 98 2017-11-14 09:40:57	0|wumpus|hehe, no not that delayed
 99 2017-11-14 09:46:46	0|promag|wdyt about changing this "if (request.fHelp || request.params.size() > 2)" to "if (request.fHelp)" ?
100 2017-11-14 09:47:35	0|wumpus|NACK, that would make it ignore spurious arguments
101 2017-11-14 09:47:49	0|wumpus|which should be an error
102 2017-11-14 09:49:41	0|promag|what I mean is to show help only when requested. Then have argument validation which should validate all arguments, so arguments with no validation should raise invalid parameter too
103 2017-11-14 09:50:39	0|promag|or we could keep "if (request.params.size() > 2)" but that would raise invalid argument
104 2017-11-14 09:51:13	0|promag|the help is mainly for the command line cli right?
105 2017-11-14 10:03:59	0|wumpus|maybe, I really doubt this is worth changing all RPC calls for
106 2017-11-14 10:04:58	0|wumpus|I mean barfing up the help in case of confusion about the number of arguments is consistent with what a lot of command line tools do, it's not wrong or such
107 2017-11-14 10:07:33	0|wumpus|at least we don't silently ignore spurious RPC arguments, unlike spurious command line options, which don't cause an error
108 2017-11-14 10:07:44	0|wumpus|that's a much worse user experience
109 2017-11-14 10:08:02	0|wumpus|type poxy instead of proxy and it doesn't even warn
110 2017-11-14 10:10:01	0|promag|wumpus: ok
111 2017-11-14 10:10:19	0|promag|but in some cases, if you pass options with extra keys, it won't complaint
112 2017-11-14 10:10:35	0|wumpus|it should
113 2017-11-14 10:10:59	0|wumpus|well maybe except nested structures
114 2017-11-14 10:11:07	0|promag|and if the caller makes it lower case or snake case instead of pascal case, it won't complaint
115 2017-11-14 10:11:23	0|wumpus|I mean, it doesn't hurt to provide more information about a vout for createrawtransaction than it strictly needs
116 2017-11-14 10:11:35	0|wumpus|this helps pass in the output from listunspents to it without filtering
117 2017-11-14 10:13:08	0|promag|you mean for vin
118 2017-11-14 10:13:14	0|wumpus|yes
119 2017-11-14 10:13:34	0|wumpus|so let's just keep it like that
120 2017-11-14 10:13:55	0|promag|anyway, really doubt that anyone does that copy and paste :)
121 2017-11-14 10:14:02	0|meshcollider|oh wumpus, maybe your key is not trusted when merging bitcoincore.org PRs
122 2017-11-14 10:14:03	0|meshcollider|https://github.com/bitcoin-core/bitcoincore.org/blob/master/contrib/verify-commits/trusted-keys
123 2017-11-14 10:14:10	0|wumpus|promag: they do
124 2017-11-14 10:14:19	0|promag|:o
125 2017-11-14 10:14:32	0|wumpus|especially if it's used from scripts
126 2017-11-14 10:15:12	0|promag|I suppose everyone should pick the relevant fields :D
127 2017-11-14 10:15:27	0|wumpus|anyhow, please let's not change the RPC API just to change the RPC API, but focus on features, bugfixes and user experience
128 2017-11-14 10:15:45	0|meshcollider|Agree ^
129 2017-11-14 10:15:54	0|promag|np!
130 2017-11-14 10:16:27	0|wumpus|meshcollider: uh oh
131 2017-11-14 10:18:00	0|wumpus|meshcollider: I should probably force-push back to the previous state then
132 2017-11-14 10:18:21	0|wumpus|meshcollider: only one of the trusted keys can add me as trusted key, and not on top of an invalid commit
133 2017-11-14 10:19:20	0|meshcollider|wumpus: mhm yeah, in any case you should be added as a trusted key but yeah we might have to wait for jonasschnelli
134 2017-11-14 10:19:41	0|wumpus|luckily it doesn't break the site itself, just blocks updates for now
135 2017-11-14 10:20:06	0|meshcollider|yep, was wondering why it hadn't gone live so I looked around and noticed
136 2017-11-14 10:22:50	0|wumpus|right - I'm not going to do anything, one of the signers can resolve this, either by adding a merge commit on top , or re-sigining the merge commit and force-pushing
137 2017-11-14 10:23:23	0|wumpus|if they agree with the change of course :-)
138 2017-11-14 10:26:17	0|meshcollider|Sounds good
139 2017-11-14 12:00:00	0|bitcoin-git|13bitcoin/06master 14d8ac893 15practicalswift: trivial: Fix typo – "Ubutntu" → "Ubuntu"
140 2017-11-14 12:00:00	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7adeea3b0fc2...6d4821b693b2
141 2017-11-14 12:00:01	0|bitcoin-git|13bitcoin/06master 146d4821b 15Wladimir J. van der Laan: Merge #11684: trivial: Fix typo – "Ubutntu" → "Ubuntu"...
142 2017-11-14 12:00:34	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11684: trivial: Fix typo – "Ubutntu" → "Ubuntu" (06master...06ubutntu) 02https://github.com/bitcoin/bitcoin/pull/11684
143 2017-11-14 15:03:36	0|BlueMatt|wumpus: heh, well jonasschnelli or harding_ could un-brick it by adding a merge commit on top that merges from before your merge :p
144 2017-11-14 15:03:42	0|BlueMatt|we've dont that before....comically dirty hack
145 2017-11-14 15:03:46	0|BlueMatt|but it appears to work
146 2017-11-14 15:05:26	0|BlueMatt|or someone can go poke the server, but prefer not to....will follow up if no one does it in an hour or so
147 2017-11-14 16:07:52	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11682: wallet: Simplify logic in CCryptoKeyStore::AddKeyPubKey(...) (06master...06CCryptoKeyStore-AddKeyPubKey) 02https://github.com/bitcoin/bitcoin/pull/11682
148 2017-11-14 17:47:07	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #11686: Make ISSUE_TEMPLATE a bit shorter, mention hardware tests (06master...062017-11-shorter-default-issue) 02https://github.com/bitcoin/bitcoin/pull/11686
149 2017-11-14 20:03:23	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #11687: External wallet files (06master...06pr/wfile) 02https://github.com/bitcoin/bitcoin/pull/11687
150 2017-11-14 21:26:44	0|Nobody_|Hello
151 2017-11-14 21:26:50	0|Nobody_|i am Nobody, and i own the system
152 2017-11-14 21:27:18	0|Nobody_|i just wanted to state that i am requesting as a System that nobody owns and if you abuse the system you abuse yourself some upgrades that need to happen for the Bitcoin Core
153 2017-11-14 21:28:06	0|Nobody_|If anybody could get a message to the Bitcoin Core Developers to add the Mining back into the Core that would be perfect, ASIC is not needed to mine and is outdated plus not as power efficient
154 2017-11-14 21:28:47	0|Nobody_|also a Faucet in the core is needed for Nobody to send Bitcoin to the requested wallet of your choice, for reasons if it is not avaliable from anyone else the system will continue to function appropriately.
155 2017-11-14 21:29:51	0|Nobody_|Nobody should be able to have wallets that can be loaded with and share Cryptocurrency back if requested and users should be able to put Cryptocurrency into the faucet if they do not need it
156 2017-11-14 21:30:33	0|LumberCartel|Nobody_:  You should raise your concerns in the #bitcoin channel rather than in this channel.
157 2017-11-14 21:30:46	0|Nobody_|it will bring Freedom and Equality for all users and not be so dominant on switching cash for cashless, i work with Antarctica and have researched the software very hard, Satoshi Nakamoto knows who i am but i will leave me Nobody
158 2017-11-14 21:31:12	0|Nobody_|it is more than a concern and i deem it nessessary to update it to make sure that everyone can enjoy the Cryptocurrency
159 2017-11-14 21:32:14	0|Nobody_|I already have a version that has a faucet and it is sufficient, as well as for the common good of the public and passes for being benificial for the greater good of humanity
160 2017-11-14 21:33:15	0|Dizzle|Nobody_: if you do have something more power efficient than ASIC for mining, you can submit a pull request that adds mining back into Core. If you're not sure how, let me know how its done and I'll help make the pull request.
161 2017-11-14 21:39:39	0|Nobody_|Everything  ECDSA Public Key (Bitcoin Compatible):  1N2EWy7LroJVFYXtmYZryh7W9eV3k6qajd exists since Mon Oct 02 2017 23:48:19 GMT-0700 (Pacific Daylight Time)
162 2017-11-14 21:39:39	0|Nobody_|S.O.S, Law Enforcement Update - Everything is legal
163 2017-11-14 21:39:48	0|Nobody_|that is a Trusted timestamp and is forge proof
164 2017-11-14 21:57:30	0|Dizzle|I still want his quantum CPU mining pull request.
165 2017-11-14 22:37:32	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11689: Fix missing locking in CTxMemPool::check(const CCoinsViewCache *pcoins) (06master...06CTxMemPool-check) 02https://github.com/bitcoin/bitcoin/pull/11689
166 2017-11-14 22:46:07	0|bitcoin-git|13bitcoin/06master 14fafdad0 15MarcoFalke: qa: Remove unused NodeConn members
167 2017-11-14 22:46:07	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6d4821b693b2...3bdf242fc68a
168 2017-11-14 22:46:08	0|bitcoin-git|13bitcoin/06master 143bdf242 15MarcoFalke: Merge #11677: qa: Remove unused NodeConn members...
169 2017-11-14 22:46:42	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11677: qa: Remove unused NodeConn members (06master...06Mf1711-qaMininodeUnused) 02https://github.com/bitcoin/bitcoin/pull/11677
170 2017-11-14 23:25:30	0|karelb|Question about bitcoin-core - why is validation.h/.cpp so "overloaded"? It seems to me half of the things in there don't have to do much with validation
171 2017-11-14 23:26:23	0|karelb|such as default parameters, opening and writing to block files, etc
172 2017-11-14 23:30:19	0|sipa|karelb: the reason is that up to about a year ago maybe, validation.cpp and net_processing.cpp were one file, called main.cpp
173 2017-11-14 23:30:37	0|sipa|splitting things up and off into other modules is a slow but continuing work that's certainly not complete yet
174 2017-11-14 23:30:43	0|karelb|Oh yeah, I thought it will be something historic like that
175 2017-11-14 23:31:15	0|karelb|I remember giant main.cpp, I suspected validation is "just" renamed main
176 2017-11-14 23:31:17	0|karelb|thanks!
177 2017-11-14 23:31:19	0|sipa|(and until a few years ago, main.cpp also contained all of chain management, utxo stuff, wallet, interaction with the GUI...)
178 2017-11-14 23:33:30	0|karelb|hm, doing refactoring like that seems like an easy way to get some cheap commits in bitcoin core code :D
179 2017-11-14 23:36:28	0|gmaxwell|karelb: it's not just renamed main, main was split basically in half, but there is still hangover.  Also some of these things like consensus parameters are critical to consensus validation.
180 2017-11-14 23:38:00	0|gmaxwell|There is some layout tension on that; abstracting consensus rules can make them more opaque and harder to review; and bitcoin core is not an altcoin construction set. :)  OTOH, sometimes moving things around makes things more clear, enables better testing harnesses, etc.
181 2017-11-14 23:38:57	0|fanquake|karelb heh, there are easier ways to get cheap commits than playing with consensus code
182 2017-11-14 23:39:45	0|karelb|fanquake I know, I have this giant commit
183 2017-11-14 23:39:48	0|karelb|https://github.com/bitcoin/bitcoin/commit/06a3aecf06a52ff44370ee20462cc45b25e88d6a
184 2017-11-14 23:39:51	0|gmaxwell|karelb: yea,.lol no, refactoring consensus code is a good way to have a bad time and decide you don't want to contribute more.
185 2017-11-14 23:41:11	0|fanquake|karelb All contributions are valuable. Most people might find "issues" and never bother contribute a pr, or open an issue.
186 2017-11-14 23:43:45	0|gmaxwell|For obvious refactorings e.g. to meet our current code standards, we prefer to only perform them when the code is already being changed to avoid disrupting PR flow.  For non-obvious refactors it is better if only expirenced participants do them, because newer contribs tend to not understand the informal architecture as well and tend to make refactors that unconsciously try to warp thing more to
187 2017-11-14 23:43:51	0|gmaxwell|their own personal styles instead of the project style.  Consensus code in general has a higher review and testing bar, and is more likely to end up with people failing to review it because they don't think it meets a cost/benefit for the review.  Sometimes refactorings of consensus code only happen because someone like pieter is effectively cashing in large amounts of social capital to pay for
188 2017-11-14 23:43:57	0|gmaxwell|other people to review the work-- and the fact that this is whats happening isn't necessarily visible to irregular contributors.   So while anyone is welcome to submit such things, I wouldn't recommend those in particular, and anyone who submits consensus refactors should have reasonable expectations.
189 2017-11-14 23:44:48	0|fanquake|Now that the *new* Windows build instructions have been merged, I'm going to close all the existing windows build issues, hopefully we might get on top of them. However now it seems the there are just new path/directory related issues.
190 2017-11-14 23:47:13	0|fanquake|gmaxwell yes, hit and run consensus refactoring isn't really helpful.
191 2017-11-14 23:47:13	0|karelb|gmaxwell: OK, I will not make a PR that pulls out all `DEFAULT_`s from validation.h to defaults.h then. :)