1 2016-10-21 00:38:05	0|achow101|michagogo: interesting. My script (the on that is in contrib/) doesn't work. But yours does. Now I need to find what the difference is, because mine does a whole lot more stuff
  2 2016-10-21 01:34:08	0|luke-jr|sigs pushed for rc2
  3 2016-10-21 01:44:40	0|achow101|michagogo: I got it to work with my script (had to make a few tweaks). Thanks for making the vm image. Maybe part of the issue I have with setting up lxc on my computer is that I use Ubuntu 16.04 instead of 14.04
  4 2016-10-21 03:25:56	0|luke-jr|https://lwn.net/Articles/704078/ local exploit in all released Linux kernels
  5 2016-10-21 03:27:21	0|luke-jr|"An exploit using this technique has been found in the wild."
  6 2016-10-21 04:02:33	0|jl2012|is there any way to generate the same block hash every time running regtest?
  7 2016-10-21 04:05:53	0|luke-jr|jl2012: by giving it the same blocks?
  8 2016-10-21 04:08:01	0|jl2012|so i can't generate blocks with the RPC generate command?
  9 2016-10-21 04:09:53	0|luke-jr|nothing stopping you, but there's no reason to expect that to be deterministic
 10 2016-10-21 04:10:11	0|luke-jr|might work if you set a mock time.. maybe
 11 2016-10-21 04:10:30	0|jl2012|it'd be nice if it has a detministicgenerate command. Given the same condition, it always returns the same block hash
 12 2016-10-21 04:10:43	0|luke-jr|but the conditions are never the same (timestamp)
 13 2016-10-21 04:11:18	0|luke-jr|it's not like compiling where it's just a random timestamp being added, the timestamp actually has a role in the blockchain :p
 14 2016-10-21 04:12:16	0|jl2012|that could be deterministic too, e.g. just make it always 600s apart
 15 2016-10-21 04:12:31	0|luke-jr|seems like it'd defeat the purpose
 16 2016-10-21 04:13:17	0|jl2012|sometimes, you want to faithfually repeat the process
 17 2016-10-21 04:13:45	0|luke-jr|so try setting a mock time..
 18 2016-10-21 04:14:26	0|jl2012|also setting the same pubkey for reward, I guess?
 19 2016-10-21 04:14:49	0|luke-jr|or just load a set deterministic wallet ;)
 20 2016-10-21 04:26:23	0|jl2012|thanks
 21 2016-10-21 08:31:06	0|Victorsueca|morning
 22 2016-10-21 08:34:40	0|wumpus|morning
 23 2016-10-21 08:35:02	0|jonasschnelli|Would it be problematic to throw CoinControl into the wallet logic in cases where CoinControl is disabled? https://github.com/bitcoin/bitcoin/blob/master/src/qt/sendcoinsdialog.cpp#L233
 24 2016-10-21 08:35:39	0|jonasschnelli|I guess CoinControls default should result in the exact same transaction like if it was not thrown into the CreateTransaction logic
 25 2016-10-21 08:36:07	0|wumpus|youd' have to be really sure of that
 26 2016-10-21 08:36:24	0|wumpus|also there's the possibility that the user disabled coincontrol and the settings are no longer at default
 27 2016-10-21 08:36:27	0|wumpus|be careful
 28 2016-10-21 08:36:38	0|jonasschnelli|hm...
 29 2016-10-21 08:36:59	0|jonasschnelli|I'd like to use it for the confirmation target (instead of miss-using the default)
 30 2016-10-21 08:37:06	0|Victorsueca|In theory the logic should be the same except maybe for some edge cases
 31 2016-10-21 08:37:10	0|jonasschnelli|Instead of adding a parameter to CreateTransaction
 32 2016-10-21 08:37:17	0|wumpus|I don't think passing in a defaults-only coincontrol structure if no coin control is desired is a bad idea per ce, it would simplify some checks
 33 2016-10-21 08:37:37	0|wumpus|Victorsueca: "in theory" is not good enough for these kind of changes
 34 2016-10-21 08:37:58	0|jonasschnelli|The problem is, CoinControl has bad test coverage. Mostly GUI only
 35 2016-10-21 08:38:05	0|Victorsueca|wumpus: yeah, either is "maybe" for the edge cases
 36 2016-10-21 08:38:06	0|wumpus|yes, that has to change
 37 2016-10-21 08:38:45	0|Victorsueca|this would have to go through some extensive checks to be sure the logic is the same
 38 2016-10-21 08:39:09	0|wumpus|requiring a coincontrol object would at least unify the coin control and non-coin control code paths for a bit
 39 2016-10-21 08:40:42	0|wumpus|good idea to use it for the confirmation target. THat would change meaning of the the structure from "coin control" to "sending preferences" but that's OK
 40 2016-10-21 08:41:30	0|wumpus|that's more general, I've always thought it was a bit strange to have an argument for what is basically a specific UI feature
 41 2016-10-21 08:41:47	0|jonasschnelli|Yes. We could rename it soon.
 42 2016-10-21 08:41:56	0|jonasschnelli|We aleady use it over RPC for fundraw
 43 2016-10-21 08:42:04	0|wumpus|well no need to rename it immediately, just add a comment to the documentation or so
 44 2016-10-21 08:42:20	0|wumpus|e.g. at the top of the class
 45 2016-10-21 08:42:30	0|wumpus|right, it's alredy used for other things
 46 2016-10-21 08:43:02	0|jonasschnelli|Currently, if you play with the smartfee-slider and use RPC or console (send*) it will affect your RPC/consoles send* confirmation target. :)
 47 2016-10-21 08:43:24	0|wumpus|yes changing the default in the background is really ugly
 48 2016-10-21 08:43:55	0|wumpus|that always bothered me, all the side effects and uncontained input in the wallet logic
 49 2016-10-21 08:45:13	0|Victorsueca|it's also ugly how it uses different fee systems for the GUI and the RPC
 50 2016-10-21 08:45:17	0|jonasschnelli|Yeah. We need to untangle the "CoinControls" layer violation. It should always respect the WalletModel
 51 2016-10-21 08:46:17	0|Victorsueca|lots of people have made mistakes believing the GUI setting would affect the RPC backend (which is logic to think)
 52 2016-10-21 08:49:14	0|jonasschnelli|Oh. So users may use the GUI to set the RPC parameters? So it's a features instead a bug?!
 53 2016-10-21 08:52:09	0|tulip|Lightsword: testnet seems to be at least mostly working today. some of the testnet explorers are jammed, but blockr.io and blocktrail.com are keeping up.
 54 2016-10-21 08:52:18	0|Victorsueca|jonasschnelli: AFAIK the GUI slider doesn't affect the RPC, and that's exactly the problem, some people tries it and ends sending a transaction with the RPC fee setting
 55 2016-10-21 08:57:21	0|GitHub24|[13bitcoin] 15jonasschnelli opened pull request #8989: [Qt] overhaul smart-fee slider, adjust default confirmation target (06master...062016/10/qt_slider) 02https://github.com/bitcoin/bitcoin/pull/8989
 56 2016-10-21 08:58:10	0|wumpus|nonono the GUI should *not* affect the RPC
 57 2016-10-21 08:58:30	0|wumpus|that's completely clueless
 58 2016-10-21 08:59:11	0|wumpus|e.g. third-party software using the RPC should not be affected by what the user happens to be currently doing in the GUI
 59 2016-10-21 08:59:27	0|wumpus|of course this is different from clearly global scope changes like the 'settings' dialog
 60 2016-10-21 08:59:34	0|wumpus|which should affect the whole process
 61 2016-10-21 08:59:44	0|wumpus|but per-send options should definitely not affect RPC
 62 2016-10-21 08:59:48	0|Victorsueca|wumpus: yeah, but maybe we should add a warning message to avoid confusion, some people actually tries to use the GUI to set the RPC fee
 63 2016-10-21 08:59:59	0|luke-jr|wumpus: the slider isn't clearly per-send
 64 2016-10-21 09:00:10	0|wumpus|it should be.
 65 2016-10-21 09:00:17	0|luke-jr|wumpus: it's outside the entry-container, and remains set after you send
 66 2016-10-21 09:00:24	0|luke-jr|this suggests to me that it's global
 67 2016-10-21 09:00:28	0|luke-jr|even though I know it isn't
 68 2016-10-21 09:00:59	0|jonasschnelli|It's per send.. but the value will be stored and persisted in QSettings
 69 2016-10-21 09:01:16	0|luke-jr|jonasschnelli: how is that per send? :P
 70 2016-10-21 09:01:40	0|wumpus|it can be a convenience to remember the setting
 71 2016-10-21 09:01:43	0|jonasschnelli|With per-send I mean that its value should not be spread global and effect the CWallet structure and RPC
 72 2016-10-21 09:01:51	0|wumpus|but if that puts people on wrong footing, it should probably just reset every time
 73 2016-10-21 09:02:04	0|jonasschnelli|It's per-send in the software-design but persisted between multiple sends. :)
 74 2016-10-21 09:02:10	0|luke-jr|Maybe a "set as default" button
 75 2016-10-21 09:02:20	0|wumpus|but that default still shouldn't affect RPC
 76 2016-10-21 09:02:27	0|jonasschnelli|I think it could be useful to keep the confirmation target between sends
 77 2016-10-21 09:02:38	0|jonasschnelli|Yes. The default is GUI only
 78 2016-10-21 09:02:38	0|luke-jr|wumpus: why?
 79 2016-10-21 09:02:49	0|wumpus|there isn't even such a a setting in RPC, and QSettings should never affect core settings anyway
 80 2016-10-21 09:02:59	0|jonasschnelli|Indeed
 81 2016-10-21 09:03:03	0|wumpus|because RPC should be as stateless aspossible
 82 2016-10-21 09:03:24	0|jonasschnelli|We could think of adding a conf-target feature to fundraw
 83 2016-10-21 09:03:24	0|luke-jr|it's a command-line option from the user's perspective
 84 2016-10-21 09:03:24	0|wumpus|and certainly not 'inhereit' from the GUI
 85 2016-10-21 09:03:37	0|wumpus|this creates even more confusing differences between running bitcoind and running the GUI
 86 2016-10-21 09:04:00	0|luke-jr|"Set as GUI default" :P
 87 2016-10-21 09:04:05	0|wumpus|yes
 88 2016-10-21 09:04:15	0|luke-jr|inb4 users ask what a GUI is <.<
 89 2016-10-21 09:04:39	0|wumpus|the people that use RPC will know
 90 2016-10-21 09:04:42	0|Victorsueca|think of it as a browser storing your login email for a web page, the web page only receives the email once per-login, even tho the browser can remember it and prefill the field the next time you visit the web page
 91 2016-10-21 09:05:02	0|wumpus|people that only use the GUI don't need to know the distinction
 92 2016-10-21 09:07:00	0|wumpus|but anyhow for the interface to be well-defined it needs to be entirely transparent which parameters affect RPC calls, there can't be any 'magic' side-input depending on whether a GUI is running
 93 2016-10-21 09:07:35	0|wumpus|remember the goal is to decouple the GUI, not couple it further
 94 2016-10-21 09:09:56	0|Victorsueca|what about putting a RPC-specific fee setting on the GUI? Maybe on Settings > Options...
 95 2016-10-21 09:10:09	0|wumpus|no, let people set RPC settings through RPC
 96 2016-10-21 09:11:02	0|wumpus|or preferably, pass necessary all input to the call itself so the message is self-contained
 97 2016-10-21 09:16:28	0|wumpus|but yes, in the settings dialog there could be settings that affect both GUI and RPC, there are some like 'dbcache' which necessarily need to affect everything
 98 2016-10-21 09:16:39	0|wumpus|there it is not confusing
 99 2016-10-21 09:18:50	0|wumpus|those settings will have associated command line arguments, and should also be able to be changed through RPC if possible to change them during runtime
100 2016-10-21 09:20:35	0|wumpus|settings that affect RPC usage, but can't be set either through command line arguments or through RPC, but only through the GUI should be avoided at all costs
101 2016-10-21 09:31:52	0|wumpus|hey, coincontrol.h needs to be in src/wallet
102 2016-10-21 09:36:08	0|jl2012|is there any RPC command to clear the mempool or clear a txid from mempool?
103 2016-10-21 09:36:20	0|jl2012|for regtest
104 2016-10-21 09:36:36	0|wumpus|I don't think so
105 2016-10-21 09:38:01	0|jl2012|any reason not to have this? I think it's useful for testing
106 2016-10-21 09:38:07	0|wumpus|feel free to add it
107 2016-10-21 09:38:19	0|jl2012|ok, i'll try
108 2016-10-21 09:39:37	0|wumpus|though I'm not sure how useful it is for RPC testing, removing transactions manually seems a thing to exercise in mempool unit tests
109 2016-10-21 09:40:02	0|wumpus|but if you have a specific test inmind that would improve, sure
110 2016-10-21 09:41:39	0|jl2012|e.g. I submitted a tx, then I malleate the tx and resubmit, and want to see if the new version would be accepted
111 2016-10-21 09:45:22	0|shangzhou|i think one thing was BIP 16 has an accidental stack limit of 520 bytes for the script.  you'd have to ask wumpus, gmaxwell, pwuille etc. https://bitcoincore.slack.com/archives/welcome/p1477041640021165
112 2016-10-21 09:48:49	0|jl2012|shangzhou: that's not accidental. The limit was there long before that
113 2016-10-21 09:50:26	0|michagogo|achow101: yeah, I'm pretty sure The Xenial Xerus was known to be problematic
114 2016-10-21 09:50:29	0|GitHub196|[13bitcoin] 15laanwj opened pull request #8990: moveonly: move `coincontrol` to `src/wallet` (06master...062016_10_coincontrol_wallet) 02https://github.com/bitcoin/bitcoin/pull/8990
115 2016-10-21 09:51:56	0|luke-jr|jl2012: it was accidental that it affected P2SH
116 2016-10-21 09:52:27	0|jl2012|no one realized that when P2SH was deployed?
117 2016-10-21 09:53:34	0|luke-jr|nope
118 2016-10-21 09:53:50	0|luke-jr|it wasn't until much later that we realised 20-of-20 multisig wouldn't work :p
119 2016-10-21 09:54:18	0|luke-jr|(or even 1-of-20 IIRC)
120 2016-10-21 09:54:33	0|jl2012|well......I can't believe everyone overlooked this
121 2016-10-21 09:55:12	0|Victorsueca|now that max script size is set on stone, fixing it would be a hard-fork
122 2016-10-21 09:55:28	0|jl2012|max script size is still 10000
123 2016-10-21 09:55:34	0|michagogo|jl2012: people overlook obvious things all the time
124 2016-10-21 09:55:34	0|wumpus|back then, getting a lot of good review for proposals was a problem, even more than it was now
125 2016-10-21 09:55:53	0|wumpus|segwit got *tons* of review compared to BIP16 I'm sure
126 2016-10-21 09:56:35	0|michagogo|It's just that overlooking things _here_ has a much bigger potential impact
127 2016-10-21 09:56:55	0|michagogo|Victorsueca: did you see my gitian appliance?
128 2016-10-21 09:56:59	0|luke-jr|BIP 16 was merged with exactly zero ACKs: https://github.com/bitcoin/bitcoin/pull/748
129 2016-10-21 09:57:06	0|wumpus|yes, way different times
130 2016-10-21 09:57:16	0|Victorsueca|michagogo: not yet
131 2016-10-21 09:57:37	0|michagogo|Victorsueca: you can download it at https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq
132 2016-10-21 09:57:53	0|michagogo|There's an .ova there, and a video showing the process of making it
133 2016-10-21 09:57:55	0|Victorsueca|wumpus: it's probably getting lots of reviews because everybody loves a well deployed hard-forks, so well deployed that it's even a soft-fork!
134 2016-10-21 09:58:09	0|michagogo|About one hour, from the first boot all the way through shutting it down to export
135 2016-10-21 09:58:28	0|Victorsueca|I guess nobody thought some years back that a block size increase could be implemented as a soft-fork
136 2016-10-21 09:58:33	0|michagogo|Including all the trial-and-error and pauses while I looked stuff up outside the VM
137 2016-10-21 09:59:24	0|michagogo|Victorsueca: "some years back" nobody was thinking about the block size and the need to increase it yet
138 2016-10-21 09:59:34	0|jl2012|i think the main argument for BIP16 was the output is not anyone-can-spend until it is actually spent. But the difference is very limited
139 2016-10-21 10:00:20	0|Victorsueca|michagogo: want me to torrent the .ova up? I could seed it for a while until it spreads
140 2016-10-21 10:00:45	0|michagogo|Ah, if you've got a seedbox I can make one
141 2016-10-21 10:00:47	0|michagogo|One sec
142 2016-10-21 10:01:00	0|Victorsueca|no need, i'll do everything
143 2016-10-21 10:02:13	0|Victorsueca|I will send you the magnet link when it's done
144 2016-10-21 10:02:15	0|luke-jr|jl2012: the main argument was the implementation didn't touch the script interpreter
145 2016-10-21 10:02:36	0|luke-jr|jl2012: which was at the time considered by some to be essentially beyond anyone's competency to modify
146 2016-10-21 10:03:13	0|luke-jr|in hindsight, that argument seems ridiculous to me. it may have seemed ridiculous to me at the time, I forget.
147 2016-10-21 10:05:25	0|wumpus|it wasn't ridiculous at the time
148 2016-10-21 10:06:01	0|wumpus|no one was competent to change that code at the time, least of all Gavin :)
149 2016-10-21 10:06:29	0|luke-jr|well, I was the one changing it with BIP 17 ;)
150 2016-10-21 10:06:49	0|michagogo|magnet:?xt=urn:btih:DA7ED2875C26C736B607719549894458E8283407&dn=Gitian%20builder.7z&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.publicbt.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.ccc.de%3a80%2fannounce&tr=udp%3a%2f%2ftracker.coppersurfer.tk%3a6969&tr=udp%3a%2f%2ftracker.torrent.eu.org%3a451
151 2016-10-21 10:06:58	0|michagogo|Victorsueca: ^
152 2016-10-21 10:07:07	0|wumpus|and we still need to be extremely careful with changes to the script interpreter
153 2016-10-21 10:07:46	0|wumpus|but there are a few more people clueful in that regard now
154 2016-10-21 10:08:21	0|Victorsueca|michagogo: I prefer to create my own if you don't care
155 2016-10-21 10:08:39	0|Victorsueca|michagogo: I can use that one tho if you want
156 2016-10-21 10:09:53	0|michagogo|Victorsueca: how come?
157 2016-10-21 10:10:33	0|luke-jr|glancing at the 1 page of consensus-critical code for BIP 17, I think I'm pretty certain it wouldn't cause consensus failure at least :P
158 2016-10-21 10:11:00	0|Victorsueca|michagogo: currently downloading from 1drv
159 2016-10-21 10:11:10	0|Victorsueca|michagogo: i'll start seeding it as soon as it's done
160 2016-10-21 10:12:59	0|michagogo|molz: did you manage to get it from onedrive in the end?
161 2016-10-21 10:34:01	0|tulip|> now that max script size is set on stone, fixing it would be a hard-fork
162 2016-10-21 10:34:01	0|tulip|Victorsueca: not exactly. it can be done as a soft fork quite easily, same as segwit :)
163 2016-10-21 10:34:23	0|luke-jr|segwit2 can just change the magic bytes! :P
164 2016-10-21 10:34:40	0|luke-jr|actually, I guess that'd require retaining the old commitment too. hmm
165 2016-10-21 10:34:53	0|tulip|when you think about it, there's actually very little which can't be done with a soft fork. it just depends how far you're willing to go with it. the limit is changing the proof of work, and even that is mutable to a certain extent if you'd like to.
166 2016-10-21 10:35:11	0|luke-jr|tulip: go too far and it becomes a soft-hardfork
167 2016-10-21 10:35:51	0|tulip|luke-jr: you should implement mohs scale for soft forks, otherwise you're going to increasing make less and less sense.
168 2016-10-21 10:37:09	0|luke-jr|?
169 2016-10-21 10:37:17	0|tulip|https://en.wikipedia.org/wiki/Mohs_scale_of_mineral_hardness
170 2016-10-21 10:37:23	0|Victorsueca|and if you ever needed to make a hard-fork for whatever reason it could be well deployed if the hashrate majority merge-mines it while nuking the old chain
171 2016-10-21 10:43:41	0|aj|tulip: does that mean a bilateral hard-fork might be said to be diamond tipped?
172 2016-10-21 10:47:30	0|michagogo|Victorsueca: nuking the old chain how?
173 2016-10-21 10:47:48	0|michagogo|Merged mining implies continuing to mine this chain
174 2016-10-21 10:48:15	0|luke-jr|michagogo: see https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki
175 2016-10-21 10:48:29	0|Victorsueca|michagogo: you merge-mine both the old and the new chain
176 2016-10-21 10:48:46	0|Victorsueca|and you nuke it by soft-forking it to 0 MB blocks
177 2016-10-21 10:49:20	0|luke-jr|Victorsueca: 100B
178 2016-10-21 10:54:23	0|Victorsueca|luke-jr: your BIP still has a high potential to hard-fork in a bad way if people chooses to build and distribute software that bypasses the Hardfork deployment bitfields, ignores the fact that there are unknown rules activated out there and keeps mining on that chain
179 2016-10-21 10:55:26	0|luke-jr|Victorsueca: nothing can prevent incompetent people from writing bad software, nor is it intended to
180 2016-10-21 11:00:35	0|Victorsueca|AFAIK the only ways to make a safe hard-fork are either tricking old nodes to think everything is ok and make it a soft-fork (segwit) or soft-fork the old chain in a way that makes it unusable AKA nuking it
181 2016-10-21 11:00:43	0|Victorsueca|2 ways*
182 2016-10-21 11:03:09	0|Victorsueca|would be really appreciated by everybody if someone knew another way to make it reasonable safe to ensure the old chain will die
183 2016-10-21 11:05:27	0|aj|Victorsueca: you can let old nodes continue to see all the transactions but maybe not understand everything about them (soft-fork), you can let old nodes see none of the transactions (nuke the chain, evil/soft-hard-fork), or you can let old nodes see some but not all of the transactions (sidechains, layer two networks) ...
184 2016-10-21 11:05:56	0|Victorsueca|ahh right
185 2016-10-21 11:06:11	0|Victorsueca|3 ways then, sidechains would be the third way
186 2016-10-21 11:11:37	0|wumpus|please move this to #bitcoin
187 2016-10-21 11:11:48	0|wumpus|it is not related to current bitcoin core development
188 2016-10-21 11:12:37	0|Victorsueca|wumpus: thanks, will keep that in mind for the next time, I think we're done now
189 2016-10-21 11:12:51	0|wumpus|this channel is for discussing code changes
190 2016-10-21 11:13:21	0|Victorsueca|so, what is libconsensus exactly for?
191 2016-10-21 11:14:09	0|Victorsueca|is it like a way to detach consensus rules from the main software?
192 2016-10-21 11:14:43	0|wumpus|a) so that third-party applications can make use of the consensus code b) to cordon off consensus code from the rest of the software
193 2016-10-21 11:15:17	0|wumpus|here: https://github.com/bitcoin/bitcoin/blob/master/doc/shared-libraries.md#bitcoinconsensus
194 2016-10-21 12:02:37	0|jonasschnelli|wumpus: https://github.com/bitcoin/bitcoin/pull/8989/files#r84448026
195 2016-10-21 12:02:48	0|jonasschnelli|I think the idea with a local instance would work as well...
196 2016-10-21 12:03:04	0|jonasschnelli|But the extra mapping from UI to the new coincontrol instance is a little bit nasty
197 2016-10-21 12:03:30	0|jonasschnelli|I would prefer per-send-wide coin-control... but I agree, there are some risks.
198 2016-10-21 12:04:02	0|jonasschnelli|In general, the CoinControl objects gets "nulled()" when the user disable the CC features in the settings: https://github.com/bitcoin/bitcoin/pull/8989/files#diff-76b18bd21ccf64e256f029a8198ecdd7L702
199 2016-10-21 12:04:59	0|wumpus|I understand, but I don't think we should be passing the CoinControlDialog's coincontrol instance in case coincontrol is disables. My code makes sure it gets a fresh instance with default values and just the confirmations overridden
200 2016-10-21 12:05:17	0|wumpus|which is exactly what we want if coin control is only to be used to pass that parameter
201 2016-10-21 12:06:05	0|jonasschnelli|Okay. Yes. Your right. Let me change it
202 2016-10-21 12:06:17	0|jonasschnelli|I also revert the slider direction inversion.
203 2016-10-21 12:29:02	0|jonasschnelli|wumpus: https://github.com/bitcoin/bitcoin/pull/8989/files, in case you want to review it again
204 2016-10-21 12:32:44	0|wumpus|yes, that looks good to me now
205 2016-10-21 12:44:40	0|Victorsueca|michagogo: here's your torrent https://softnet.homenet.org/tokenid_3qsqxgu5wkhopt4k2daqbuxc/
206 2016-10-21 12:45:05	0|Victorsueca|username is bitcoin and password is mdtj4g5w5bppajnpmt2ow2dx
207 2016-10-21 12:45:21	0|Victorsueca|I password protected it so google doesn't bother me with malware removal warnings
208 2016-10-21 12:46:55	0|michagogo|Victorsueca: what's wrong with the other one?
209 2016-10-21 12:47:11	0|michagogo|Also, I'm not at my computer now
210 2016-10-21 12:48:03	0|michagogo|Don't know when I'll be able to get it
211 2016-10-21 12:48:52	0|michagogo|(And why not just a magnet link?)
212 2016-10-21 12:49:34	0|Victorsueca|michagogo: I make my torrents in a way they go sooper-fast :P
213 2016-10-21 12:50:12	0|Victorsueca|I tried it, but the way I do it magnet links are too long for any clipboard
214 2016-10-21 12:51:01	0|Victorsueca|also no need to hurry, take your time until you get to your computer
215 2016-10-21 12:51:07	0|Victorsueca|:)
216 2016-10-21 13:04:01	0|wumpus|github is so slow here...
217 2016-10-21 13:12:48	0|jonasschnelli|wumpus: yes. extra-slow at my end as well
218 2016-10-21 13:13:47	0|morcos|jonasschnelli: wumpus:  i understand the logic of why the GUI fee estimation PR just changes 25 -> 2, but I don't want to risk that we end up with a GUI defaulting to 2.  I worry that a separate PR to change the overall default from 2 -> 6 will get bikeshedded to death.
219 2016-10-21 13:14:31	0|morcos|And without that I think we're creating a worse user experience.  Essentially even more people will be paying too much in fee.  25 is a better choice than 2 IMO.
220 2016-10-21 13:14:46	0|jonasschnelli|I think 6 would be resonable... but we would need to change RPC and GUI
221 2016-10-21 13:14:58	0|jonasschnelli|I don't expect to much bikeshedding
222 2016-10-21 13:15:11	0|GitHub78|[13bitcoin] 15jonasschnelli pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0e228557f239...7b1bfa3a8786
223 2016-10-21 13:15:12	0|GitHub78|13bitcoin/06master 140a261b6 15Jonas Schnelli: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip()
224 2016-10-21 13:15:12	0|GitHub78|13bitcoin/06master 143154d6e 15Jonas Schnelli: [Qt] use NotifyHeaderTip's height and date for the progress update
225 2016-10-21 13:15:13	0|GitHub78|13bitcoin/06master 147b1bfa3 15Jonas Schnelli: Merge #8985: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip()...
226 2016-10-21 13:15:33	0|morcos|ok, well i'm just nervous becuase I tried to change it to 6 when it got changed to 2 and I met resistance
227 2016-10-21 13:16:03	0|GitHub79|[13bitcoin] 15jonasschnelli closed pull request #8985: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip() (06master...062016/10/fix_gui_overlay) 02https://github.com/bitcoin/bitcoin/pull/8985
228 2016-10-21 13:16:05	0|jonasschnelli|Okay. I see your point.
229 2016-10-21 13:16:43	0|wumpus|yes, I like 6 too
230 2016-10-21 13:58:40	0|GitHub53|13bitcoin/06master 141ae5839 15Wladimir J. van der Laan: moveonly: move `coincontrol` to `src/wallet`
231 2016-10-21 13:58:40	0|GitHub53|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7b1bfa3a8786...3fb3fade3c02
232 2016-10-21 13:58:41	0|GitHub53|13bitcoin/06master 143fb3fad 15Wladimir J. van der Laan: Merge #8990: moveonly: move `coincontrol` to `src/wallet`...
233 2016-10-21 13:58:57	0|GitHub155|[13bitcoin] 15laanwj closed pull request #8990: moveonly: move `coincontrol` to `src/wallet` (06master...062016_10_coincontrol_wallet) 02https://github.com/bitcoin/bitcoin/pull/8990
234 2016-10-21 14:08:37	0|jonasschnelli|Hmm... rc2 does not run on OSX 10.7
235 2016-10-21 14:09:16	0|michagogo|Victorsueca: hm, what is it that you do?
236 2016-10-21 14:09:38	0|michagogo|I would have thought a torrent is a torrent…
237 2016-10-21 14:11:00	0|Victorsueca|michagogo: not sure, I just touched a lot of settings to a option that sounded right to me and then it my torrent files started downloading things faster wherever I run them
238 2016-10-21 14:11:21	0|michagogo|Victorsueca: which settings?
239 2016-10-21 14:11:35	0|Victorsueca|michagogo: the ones when creating a new torrent file
240 2016-10-21 14:11:54	0|michagogo|I'm asking, what settings did you use!
241 2016-10-21 14:11:59	0|michagogo|use?*
242 2016-10-21 14:12:09	0|Victorsueca|not sure if any of them made actually some effect or it's just my connection
243 2016-10-21 14:12:14	0|Victorsueca|let me check...
244 2016-10-21 14:12:43	0|jonasschnelli|ping cfields_ : https://github.com/bitcoin/bitcoin/issues/8577
245 2016-10-21 14:40:28	0|Victorsueca|michagogo: set chunk size to 2 MiB and added a lot of trackers (200 or so)
246 2016-10-21 14:40:35	0|Victorsueca|those are the settings
247 2016-10-21 14:41:13	0|michagogo|Victorsueca: pretty sure the chunk size was 2 on mine too
248 2016-10-21 14:41:16	0|michagogo|Or maybe it was 4
249 2016-10-21 14:41:26	0|michagogo|And you can just add trackers...
250 2016-10-21 14:41:54	0|michagogo|Not that it really matters, since DHT+Peer Exchange mean that you don't really need trackers
251 2016-10-21 14:41:55	0|Victorsueca|I guess it's my connection then...
252 2016-10-21 14:42:07	0|michagogo|With pex, you really just need 1 other peer
253 2016-10-21 14:42:21	0|michagogo|Like Bitcoin, sort of
254 2016-10-21 14:43:01	0|Victorsueca|well, doesn't really matter, I already started seeding the one I made
255 2016-10-21 14:43:42	0|Victorsueca|I can seed yours tho if you really want
256 2016-10-21 14:52:55	0|instagibbs_|so why do we make outbound connections to nodes that can't serve us the data we want at all?
257 2016-10-21 14:53:23	0|sipa|instagibbs_: because they may give us addresses of peers that do
258 2016-10-21 14:53:42	0|instagibbs_|currently we don't do churn of those peers though right
259 2016-10-21 14:54:03	0|instagibbs_|like, every X minutes, cycle peers that don't offer services you require
260 2016-10-21 14:54:09	0|instagibbs_|(good point though)
261 2016-10-21 14:54:15	0|sipa|interesting
262 2016-10-21 14:54:30	0|sipa|we do have oneshot connections, which just request an addr and disconnect
263 2016-10-21 14:54:38	0|instagibbs_|yeah, feelers
264 2016-10-21 14:54:47	0|sipa|no, that's something else still :)
265 2016-10-21 14:54:52	0|instagibbs_|oh, doh
266 2016-10-21 14:55:05	0|sipa|those don't even get addresses, but just test whether the address is reachable
267 2016-10-21 14:55:17	0|instagibbs_|oh of course, i misread
268 2016-10-21 14:55:29	0|Victorsueca|we could make it connect, ask for addresses, check if any equiered service is available, if yes then keep alive, if no then drop
269 2016-10-21 14:55:31	0|sipa|oneshot connections are used when you're on tor and nedd to use a dns seed for example
270 2016-10-21 14:55:53	0|sipa|Victorsueca: we know whether the service is available before we connect
271 2016-10-21 14:56:03	0|instagibbs_|via service bits
272 2016-10-21 14:56:15	0|instagibbs_|?
273 2016-10-21 14:56:18	0|sipa|yes
274 2016-10-21 14:56:18	0|Victorsueca|but you still need to connect to request addresses tho
275 2016-10-21 14:56:23	0|sipa|yes
276 2016-10-21 14:56:43	0|sipa|and to generally not worsen partitioning of the network
277 2016-10-21 14:57:11	0|sipa|even if no peers are available that we like, it's still better to keep the network whole
278 2016-10-21 14:57:18	0|instagibbs_|what is it called to talk to a peer for service bits but not connect?
279 2016-10-21 14:57:29	0|sipa|?
280 2016-10-21 14:57:46	0|instagibbs_|"we know whether the service is available before we connect" yet we know service bits
281 2016-10-21 14:57:55	0|sipa|yes, because the service bits are in addrdb
282 2016-10-21 14:58:27	0|GitHub36|13bitcoin/06master 146f2f639 15Jorge Timón: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/
283 2016-10-21 14:58:27	0|GitHub36|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3fb3fade3c02...5af9a7117cff
284 2016-10-21 14:58:28	0|GitHub36|13bitcoin/06master 145af9a71 15Wladimir J. van der Laan: Merge #8975: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/...
285 2016-10-21 14:58:31	0|GitHub164|[13bitcoin] 15laanwj closed pull request #8975: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/ (06master...060.13-chainparams-init) 02https://github.com/bitcoin/bitcoin/pull/8975
286 2016-10-21 14:58:41	0|sipa|i'm just responding to Victorsueca that the idea of not disconnecting if they do offer the right setvices isn't meaningful... we know that beforehand
287 2016-10-21 14:59:23	0|GitHub86|13bitcoin/06master 1472ca7d9 15Matt Corallo: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock
288 2016-10-21 14:59:23	0|GitHub86|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5af9a7117cff...3cf496d102d2
289 2016-10-21 14:59:23	0|Victorsueca|yeah, I understand, if we know the IP to connect to it is because some node told us, and when it did it also told us the available services
290 2016-10-21 14:59:24	0|GitHub86|13bitcoin/06master 143cf496d 15Wladimir J. van der Laan: Merge #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock...
291 2016-10-21 14:59:34	0|Victorsueca|which are stored in the addrdb
292 2016-10-21 14:59:39	0|sipa|Victorsueca: exactly
293 2016-10-21 14:59:40	0|GitHub170|[13bitcoin] 15laanwj closed pull request #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock (06master...06cmpctblock) 02https://github.com/bitcoin/bitcoin/pull/8968
294 2016-10-21 14:59:43	0|wumpus|although the services in the addrdb could be wrong, e.g. the peer may have changed services in the mean time
295 2016-10-21 15:00:08	0|instagibbs_|err when do we store them in the addrdb
296 2016-10-21 15:00:16	0|sipa|right, but if the services in addrdb are wrong, we treat it as we accidentally connected to the wrong peer
297 2016-10-21 15:00:22	0|BlueMatt|wumpus: wait, when did we decide 8968 was for 0.13.1?
298 2016-10-21 15:00:26	0|BlueMatt|I thoguht we said no in milan?
299 2016-10-21 15:00:35	0|wumpus|oh it isn't?
300 2016-10-21 15:00:36	0|wumpus|removing tag
301 2016-10-21 15:00:43	0|Victorsueca|lel
302 2016-10-21 15:00:46	0|BlueMatt|yes, I think it is uneccessary for 0.13.1
303 2016-10-21 15:01:19	0|sipa|BlueMatt: i can't actually remember having a good reasoning why it isn't necessary... but ibagree with the assessment that without clear sign of problems it's just ugly
304 2016-10-21 15:01:46	0|BlueMatt|sipa: you're the one who pointed out that cs_main should always be the top lock
305 2016-10-21 15:01:54	0|BlueMatt|so adding a cs_main should be just fine
306 2016-10-21 15:02:09	0|wumpus|yes, at most you'll be holding it unnecessarily
307 2016-10-21 15:02:20	0|sipa|ah
308 2016-10-21 15:02:29	0|sipa|well, "should" :)
309 2016-10-21 15:04:35	0|Victorsueca|don't know why but "cs_main" and "lock" in the same sentence sounds to me like you're going to fuck the databases and hard-fork something :P
310 2016-10-21 15:04:47	0|Victorsueca|and I don't know coding at all
311 2016-10-21 15:05:03	0|wumpus|please...
312 2016-10-21 15:05:18	0|sipa|Victorsueca: then perhaps you shouldn't comment in this channel
313 2016-10-21 15:06:46	0|Victorsueca|sorry, hope not to have jinxed you :S
314 2016-10-21 15:07:17	0|BlueMatt|so, thus far, rc2 is final - doc changes?
315 2016-10-21 15:08:40	0|sipa|want me to test whether "cs_main is always the topmost lock" is true?
316 2016-10-21 15:10:18	0|BlueMatt|sipa: please do
317 2016-10-21 15:33:57	0|BlueMatt|last block: propagated entire fibre network within 4ms of the speed of light between my servers
318 2016-10-21 15:34:45	0|BlueMatt|ok, thats a lie, 10
319 2016-10-21 15:34:52	0|BlueMatt|but whatever, thats pretty good
320 2016-10-21 15:38:01	0|sipa|your technology sucks. you could get the block a full 3000 km further in the same time!
321 2016-10-21 15:39:52	0|BlueMatt|not in glass!
322 2016-10-21 15:40:04	0|BlueMatt|(closer to 1750km)
323 2016-10-21 15:51:42	0|sipa|better get working on that vacuum-tube-fiber
324 2016-10-21 16:17:28	0|Victorsueca|someone said github was slow before?
325 2016-10-21 16:17:38	0|Victorsueca|I think I found why
326 2016-10-21 16:19:49	0|Victorsueca|someone has been DDoSing Dyn nameservers at US east coast
327 2016-10-21 16:20:01	0|Victorsueca|basically _half_ internet is down
328 2016-10-21 16:35:00	0|rabidus_|Victorsueca: github down for me, also netflix
329 2016-10-21 16:35:06	0|rabidus_|that's all i've found
330 2016-10-21 16:35:34	0|Victorsueca|yeah, it's mostly huge and important services
331 2016-10-21 16:36:00	0|Victorsueca|twitter, amazon, netflix, spotify...
332 2016-10-21 16:36:27	0|jtimon|github, soundcloud, twitter (not from the android app)...
333 2016-10-21 16:36:51	0|jtimon|seems this is it http://arstechnica.com/security/2016/10/dos-attack-on-major-dns-provider-brings-internet-to-morning-crawl/
334 2016-10-21 16:38:25	0|cfields_|wtf, i just came here to ask if half of the net was down for everyone else. I assumed it was a stupid question.
335 2016-10-21 16:38:37	0|BlueMatt|you want 192.30.253.113
336 2016-10-21 16:38:42	0|rabidus_|amazon.com works
337 2016-10-21 16:38:46	0|BlueMatt|cfields_: it works in most places
338 2016-10-21 16:39:00	0|BlueMatt|google dns appears to be working around it appropriately
339 2016-10-21 16:41:06	0|cfields_|BlueMatt: thanks. my dns setup is a bit weird, i'll wait a bit before changing stuff around
340 2016-10-21 16:41:37	0|BlueMatt|cfields_: hardcode to the above ip, then
341 2016-10-21 16:41:39	0|BlueMatt|(that is github)
342 2016-10-21 16:41:45	0|BlueMatt|/etc/hosts :)
343 2016-10-21 16:42:33	0|cfields_|BlueMatt: ah perfect, thanks
344 2016-10-21 16:43:45	0|rabidus_|this was funny: http://www.vox.com/new-money/2016/10/21/13357332/internet-outage-explained
345 2016-10-21 16:43:48	0|rabidus_|because it doesn't work for me
346 2016-10-21 16:44:33	0|sipa|everything seems fine here
347 2016-10-21 16:45:39	0|BlueMatt|sipa: yea, west coast seems mostly fine, as in apac
348 2016-10-21 16:48:28	0|jtimon|alright, setting manual DNS to one in the spanish list here did the trick: http://public-dns.info/
349 2016-10-21 16:50:07	0|rabidus_|it think i'm going with big brother dns
350 2016-10-21 16:50:13	0|rabidus_|good old 8.8.8.8
351 2016-10-21 16:52:16	0|jtimon|oh, I tried 8.8.8.8, 8.8.4.4 first but it didn't worked because I forgot the coma, stupid me
352 2016-10-21 16:53:20	0|jtimon|this kind of thing wouldn't happen if all domains were in a blockchain
353 2016-10-21 16:55:19	0|instagibbs_|stupid pill q: for inbound connections, how does the nServicesExpected vs offered check pass? It looks to me that expected services is only set for outgoing?
354 2016-10-21 16:55:54	0|instagibbs_|this line "if (pfrom->nServicesExpected & ~pfrom->nServices)"
355 2016-10-21 16:56:23	0|sipa|that check is always false if nServicesExpected is 0
356 2016-10-21 16:56:55	0|instagibbs_|I was thinking xor... lol. sorry.
357 2016-10-21 17:01:25	0|instagibbs_|Confused myself into thinking logic was "any difference in bits" vs "any expected but missing services"
358 2016-10-21 17:06:42	0|cbit|yeah, done for me too
359 2016-10-21 17:06:44	0|cbit|down*
360 2016-10-21 17:07:35	0|cbit|west coast here..
361 2016-10-21 17:11:37	0|rabidus_|just started working here in finland
362 2016-10-21 17:11:51	0|rabidus_|at least netflix :P
363 2016-10-21 17:40:30	0|GitHub174|13bitcoin/06master 143a286ab 15S. Matthew English: Eliminating Inconsistencies in Textual Output...
364 2016-10-21 17:40:30	0|GitHub174|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3cf496d102d2...f08222e882b1
365 2016-10-21 17:40:31	0|GitHub174|13bitcoin/06master 14f08222e 15MarcoFalke: Merge #8982: Eliminating Inconsistencies in Textual Output...
366 2016-10-21 17:40:42	0|GitHub104|[13bitcoin] 15MarcoFalke closed pull request #8982: Eliminating Inconsistencies in Textual Output (06master...06patch-6) 02https://github.com/bitcoin/bitcoin/pull/8982
367 2016-10-21 17:50:25	0|BlueMatt|151.101.100.133 assets-cdn.github.com
368 2016-10-21 17:50:25	0|BlueMatt|192.30.253.113	github.com
369 2016-10-21 17:50:25	0|BlueMatt|cat /etc/hosts
370 2016-10-21 17:50:45	0|BlueMatt|for those who are missing the cdn entry, though that one might very well be geoip, so have fun on the HKG one
371 2016-10-21 17:51:05	0|rabidus_|or 8.8.8.8,8.8.4.4
372 2016-10-21 17:51:15	0|BlueMatt|github isnt resolving on 8.8.8.8 for me atm
373 2016-10-21 17:51:27	0|rabidus_|wtf, it is for me
374 2016-10-21 17:51:38	0|BlueMatt|8.8.8.8 isnt just one server :p
375 2016-10-21 17:51:39	0|rabidus_|or then my main dns started working
376 2016-10-21 17:51:45	0|rabidus_|oh, yeah :P
377 2016-10-21 17:56:44	0|BlueMatt|cfields_: ok, #8969 is ready for review since the cs_main fix was merged :)
378 2016-10-21 18:07:42	0|btcdrak|There are also level3 DNS servers at 4.2.2.1, 4.2.2.2
379 2016-10-21 18:08:19	0|BlueMatt|those dont work from all networks
380 2016-10-21 18:09:00	0|BlueMatt|(also, level3 hates it when you publish those - they're supposed to be for l3 customers)
381 2016-10-21 19:08:43	0|jeremyrubin|Annoyingly, Dyn ddos also seems to break travis.
382 2016-10-21 19:09:25	0|jeremyrubin|Because travis doesn't have a pinned ip or something for github, so they can't find any of the repos
383 2016-10-21 19:19:43	0|midnightmagic|:-/  What the hell. Why would my GnuPG key require a matching email in order to show as verified in github.
384 2016-10-21 19:20:15	0|midnightmagic|"Sign this message acknowledging you authorize this github user to own your commits."
385 2016-10-21 20:04:32	0|GitHub149|[13bitcoin] 15instagibbs opened pull request #8992: Enable pubkey lookup for p2sh-p2wpkh in validateaddress (06master...06validatep2pkh) 02https://github.com/bitcoin/bitcoin/pull/8992
386 2016-10-21 21:46:17	0|GitHub91|[13bitcoin] 15paveljanik opened pull request #8993: Trivial: Fix doxygen comment: the transaction is returned in txOut (06master...0620161021_fix_GetTransaction_comment) 02https://github.com/bitcoin/bitcoin/pull/8993