--- Day changed Fri Oct 21 2016
00:29 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
00:33 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
00:37 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
00:39 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]     
00:43 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Ping timeout: 260 seconds]     
00:43 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
01:06 -!- cdecker [~quassel@2a02:aa16:1105:4a80:1094:c296:7cba:3eb5] has joined #bitcoin-core-dev     
01:13 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]     
01:25 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
01:28 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
01:31 < Victorsueca> morning
01:34 < wumpus> morning
01:35 < 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
01:35 < jonasschnelli> I guess CoinControls default should result in the exact same transaction like if it was not thrown into the CreateTransaction logic
01:36 < wumpus> youd' have to be really sure of that
01:36 < wumpus> also there's the possibility that the user disabled coincontrol and the settings are no longer at default
01:36 < wumpus> be careful
01:36 < jonasschnelli> hm...
01:36 < jonasschnelli> I'd like to use it for the confirmation target (instead of miss-using the default)
01:37 < Victorsueca> In theory the logic should be the same except maybe for some edge cases
01:37 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Ping timeout: 245 seconds]     
01:37 < jonasschnelli> Instead of adding a parameter to CreateTransaction
01:37 < 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
01:37 < wumpus> Victorsueca: "in theory" is not good enough for these kind of changes
01:37 < jonasschnelli> The problem is, CoinControl has bad test coverage. Mostly GUI only
01:38 < Victorsueca> wumpus: yeah, either is "maybe" for the edge cases
01:38 < wumpus> yes, that has to change
01:38 < Victorsueca> this would have to go through some extensive checks to be sure the logic is the same
01:39 < wumpus> requiring a coincontrol object would at least unify the coin control and non-coin control code paths for a bit
01:39 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
01:40 < 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
01:41 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Quit: Leaving]     
01:41 < 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
01:41 < jonasschnelli> Yes. We could rename it soon.
01:41 < jonasschnelli> We aleady use it over RPC for fundraw
01:42 < wumpus> well no need to rename it immediately, just add a comment to the documentation or so
01:42 < wumpus> e.g. at the top of the class
01:42 < wumpus> right, it's alredy used for other things
01:42 -!- laurentmt [~Thunderbi@80.215.178.165] has joined #bitcoin-core-dev     
01:43 < jonasschnelli> Currently, if you play with the smartfee-slider and use RPC or console (send*) it will affect your RPC/consoles send* confirmation target. :)
01:43 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
01:43 < wumpus> yes changing the default in the background is really ugly
01:43 < wumpus> that always bothered me, all the side effects and uncontained input in the wallet logic
01:45 < Victorsueca> it's also ugly how it uses different fee systems for the GUI and the RPC
01:45 < jonasschnelli> Yeah. We need to untangle the "CoinControls" layer violation. It should always respect the WalletModel 
01:46 < Victorsueca> lots of people have made mistakes believing the GUI setting would affect the RPC backend (which is logic to think)
01:48 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
01:49 < jonasschnelli> Oh. So users may use the GUI to set the RPC parameters? So it's a features instead a bug?!
01:52 < 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. 
01:52 < 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
01:57 < GitHub24> [bitcoin] jonasschnelli opened pull request #8989: [Qt] overhaul smart-fee slider, adjust default confirmation target (master...2016/10/qt_slider) https://github.com/bitcoin/bitcoin/pull/8989
01:58 < wumpus> nonono the GUI should *not* affect the RPC
01:58 < wumpus> that's completely clueless
01:59 < 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
01:59 < wumpus> of course this is different from clearly global scope changes like the 'settings' dialog
01:59 < wumpus> which should affect the whole process
01:59 < wumpus> but per-send options should definitely not affect RPC
01:59 < 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
01:59 < luke-jr> wumpus: the slider isn't clearly per-send
02:00 < wumpus> it should be.
02:00 < luke-jr> wumpus: it's outside the entry-container, and remains set after you send
02:00 < luke-jr> this suggests to me that it's global
02:00 < luke-jr> even though I know it isn't
02:00 < jonasschnelli> It's per send.. but the value will be stored and persisted in QSettings
02:01 < luke-jr> jonasschnelli: how is that per send? :P
02:01 < wumpus> it can be a convenience to remember the setting
02:01 < jonasschnelli> With per-send I mean that its value should not be spread global and effect the CWallet structure and RPC
02:01 < wumpus> but if that puts people on wrong footing, it should probably just reset every time
02:02 < jonasschnelli> It's per-send in the software-design but persisted between multiple sends. :)
02:02 < luke-jr> Maybe a "set as default" button
02:02 < wumpus> but that default still shouldn't affect RPC
02:02 < jonasschnelli> I think it could be useful to keep the confirmation target between sends
02:02 < jonasschnelli> Yes. The default is GUI only
02:02 < luke-jr> wumpus: why?
02:02 < wumpus> there isn't even such a a setting in RPC, and QSettings should never affect core settings anyway
02:02 < jonasschnelli> Indeed
02:03 < wumpus> because RPC should be as stateless aspossible
02:03 < luke-jr> it's a command-line option from the user's perspective
02:03 < jonasschnelli> We could think of adding a conf-target feature to fundraw
02:03 < wumpus> and certainly not 'inhereit' from the GUI
02:03 < wumpus> this creates even more confusing differences between running bitcoind and running the GUI
02:03  * jonasschnelli needs to fo afk
02:04 < luke-jr> "Set as GUI default" :P
02:04 < wumpus> yes     
02:04 < luke-jr> inb4 users ask what a GUI is <.<
02:04 < wumpus> the people that use RPC will know
02:04 < 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
02:05 < wumpus> people that only use the GUI don't need to know the distinction
02:06 < 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
02:07 < wumpus> remember the goal is to decouple the GUI, not couple it further
02:09 < Victorsueca> what about putting a RPC-specific fee setting on the GUI? Maybe on Settings > Options...
02:10 < wumpus> no, let people set RPC settings through RPC
02:11 < wumpus> or preferably, pass necessary all input to the call itself so the message is self-contained
02:16 < 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
02:16 < wumpus> there it is not confusing
02:16 -!- laurentmt [~Thunderbi@80.215.178.165] has quit [Quit: laurentmt]     
02:16 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]     
02:18 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
02:18 < 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
02:20 < 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
02:24 -!- aalex [~aalex@64.187.177.58] has quit [Max SendQ exceeded]     
02:24 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
02:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
02:28 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
02:31 < wumpus> hey, coincontrol.h needs to be in src/wallet
02:33 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
02:33 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Disconnected by services]     
02:33 -!- Victor_sueca is now known as Victorsueca     
02:36 < jl2012> is there any RPC command to clear the mempool or clear a txid from mempool?
02:36 < jl2012> for regtest
02:36 < wumpus> I don't think so
02:38 < jl2012> any reason not to have this? I think it's useful for testing
02:38 < wumpus> feel free to add it
02:38 < jl2012> ok, i'll try
02:39 < 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
02:40 < wumpus> but if you have a specific test inmind that would improve, sure
02:41 < 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
02:44 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-pjghnshcdopvykib] has joined #bitcoin-core-dev     
02:45 < 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
02:45 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has quit [Quit: Leaving]     
02:48 < jl2012> shangzhou: that's not accidental. The limit was there long before that
02:50 < michagogo> achow101: yeah, I'm pretty sure The Xenial Xerus was known to be problematic
02:50 < GitHub196> [bitcoin] laanwj opened pull request #8990: moveonly: move `coincontrol` to `src/wallet` (master...2016_10_coincontrol_wallet) https://github.com/bitcoin/bitcoin/pull/8990
02:51 < luke-jr> jl2012: it was accidental that it affected P2SH
02:52 < jl2012> no one realized that when P2SH was deployed?
02:53 < luke-jr> nope
02:53 < luke-jr> it wasn't until much later that we realised 20-of-20 multisig wouldn't work :p
02:54 < luke-jr> (or even 1-of-20 IIRC)
02:54 < jl2012> well......I can't believe everyone overlooked this
02:54 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 256 seconds]     
02:55 < Victorsueca> now that max script size is set on stone, fixing it would be a hard-fork
02:55 < jl2012> max script size is still 10000
02:55 < michagogo> jl2012: people overlook obvious things all the time
02:55 < wumpus> back then, getting a lot of good review for proposals was a problem, even more than it was now
02:55 < wumpus> segwit got *tons* of review compared to BIP16 I'm sure
02:56 < michagogo> It's just that overlooking things _here_ has a much bigger potential impact
02:56 < michagogo> Victorsueca: did you see my gitian appliance?
02:56 < luke-jr> BIP 16 was merged with exactly zero ACKs: https://github.com/bitcoin/bitcoin/pull/748
02:57 < wumpus> yes, way different times
02:57 < Victorsueca> michagogo: not yet
02:57 < michagogo> Victorsueca: you can download it at https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq
02:57 < michagogo> There's an .ova there, and a video showing the process of making it
02:57 < 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!
02:58 < michagogo> About one hour, from the first boot all the way through shutting it down to export
02:58 < Victorsueca> I guess nobody thought some years back that a block size increase could be implemented as a soft-fork
02:58 < michagogo> Including all the trial-and-error and pauses while I looked stuff up outside the VM
02:59 < michagogo> Victorsueca: "some years back" nobody was thinking about the block size and the need to increase it yet
02:59 < 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
03:00 < Victorsueca> michagogo: want me to torrent the .ova up? I could seed it for a while until it spreads
03:00 < michagogo> Ah, if you've got a seedbox I can make one
03:00 < michagogo> One sec
03:00 < Victorsueca> no need, i'll do everything
03:02 < Victorsueca> I will send you the magnet link when it's done
03:02 < luke-jr> jl2012: the main argument was the implementation didn't touch the script interpreter
03:02 < luke-jr> jl2012: which was at the time considered by some to be essentially beyond anyone's competency to modify
03:03 < luke-jr> in hindsight, that argument seems ridiculous to me. it may have seemed ridiculous to me at the time, I forget.
03:05 < wumpus> it wasn't ridiculous at the time
03:06 < wumpus> no one was competent to change that code at the time, least of all Gavin :)
03:06 < luke-jr> well, I was the one changing it with BIP 17 ;)
03:06  * luke-jr ponders if he went back and re-reviewed BIP 17's code, if he'd find any bugs
03:06 < 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
03:06 < michagogo> Victorsueca: ^
03:07 < wumpus> and we still need to be extremely careful with changes to the script interpreter
03:07 < wumpus> but there are a few more people clueful in that regard now
03:08 < Victorsueca> michagogo: I prefer to create my own if you don't care
03:08 < Victorsueca> michagogo: I can use that one tho if you want
03:09 < michagogo> Victorsueca: how come?
03:10 < 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
03:11 < Victorsueca> michagogo: currently downloading from 1drv
03:11 < Victorsueca> michagogo: i'll start seeding it as soon as it's done
03:12 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev     
03:12 < michagogo> molz: did you manage to get it from onedrive in the end?
03:23 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
03:34 < tulip> > now that max script size is set on stone, fixing it would be a hard-fork
03:34 < tulip> Victorsueca: not exactly. it can be done as a soft fork quite easily, same as segwit :)
03:34 < luke-jr> segwit2 can just change the magic bytes! :P
03:34 < luke-jr> actually, I guess that'd require retaining the old commitment too. hmm
03:34 < 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. 
03:35 < luke-jr> tulip: go too far and it becomes a soft-hardfork
03:35 < tulip> luke-jr: you should implement mohs scale for soft forks, otherwise you're going to increasing make less and less sense. 
03:37 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
03:37 < luke-jr> ?     
03:37 < tulip> https://en.wikipedia.org/wiki/Mohs_scale_of_mineral_hardness
03:37 < 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
03:43 < aj> tulip: does that mean a bilateral hard-fork might be said to be diamond tipped?
03:47 < michagogo> Victorsueca: nuking the old chain how?
03:47 < michagogo> Merged mining implies continuing to mine this chain
03:48 < luke-jr> michagogo: see https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki
03:48 < Victorsueca> michagogo: you merge-mine both the old and the new chain
03:48 < Victorsueca> and you nuke it by soft-forking it to 0 MB blocks
03:49 < luke-jr> Victorsueca: 100B
03:54 < 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
03:55 < luke-jr> Victorsueca: nothing can prevent incompetent people from writing bad software, nor is it intended to
03:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pfofsoayllhncbwn] has joined #bitcoin-core-dev     
04:00 < 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
04:00 < Victorsueca> 2 ways*
04:03 < Victorsueca> would be really appreciated by everybody if someone knew another way to make it reasonable safe to ensure the old chain will die
04:05 < 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) ...
04:05 < Victorsueca> ahh right
04:06 < Victorsueca> 3 ways then, sidechains would be the third way
04:11 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has quit [Quit: Leaving]     
04:11 < wumpus> please move this to #bitcoin
04:11 < wumpus> it is not related to current bitcoin core development
04:12 < Victorsueca> wumpus: thanks, will keep that in mind for the next time, I think we're done now
04:12 < wumpus> this channel is for discussing code changes
04:12 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
04:13 < Victorsueca> so, what is libconsensus exactly for?
04:14 < Victorsueca> is it like a way to detach consensus rules from the main software?
04:14 < 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
04:15 < wumpus> here: https://github.com/bitcoin/bitcoin/blob/master/doc/shared-libraries.md#bitcoinconsensus
04:18 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
04:20 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
04:39 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
04:46 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [K-Lined]     
05:00 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
05:01 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-pjghnshcdopvykib] has quit [Quit: Connection closed for inactivity]     
05:02 < jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/8989/files#r84448026
05:02 < jonasschnelli> I think the idea with a local instance would work as well...
05:03 < jonasschnelli> But the extra mapping from UI to the new coincontrol instance is a little bit nasty
05:03 < jonasschnelli> I would prefer per-send-wide coin-control... but I agree, there are some risks.
05:03 -!- owowo [ovovo@gateway/vpn/mullvad/x-ilfadhhwzpaybxtz] has joined #bitcoin-core-dev     
05:03 -!- owowo [ovovo@gateway/vpn/mullvad/x-ilfadhhwzpaybxtz] has quit [Changing host]     
05:03 -!- owowo [ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
05:03 -!- owowo [ovovo@unaffiliated/ovovo] has quit [Changing host]     
05:03 -!- owowo [ovovo@gateway/vpn/mullvad/x-ilfadhhwzpaybxtz] has joined #bitcoin-core-dev     
05:04 < 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
05:04 < 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
05:05 < wumpus> which is exactly what we want if coin control is only to be used to pass that parameter
05:06 < jonasschnelli> Okay. Yes. Your right. Let me change it
05:06 < jonasschnelli> I also revert the slider direction inversion.
05:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:16 -!- laurentmt [~Thunderbi@80.215.178.165] has joined #bitcoin-core-dev     
05:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
05:24 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
05:28 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
05:29 < jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/8989/files, in case you want to review it again
05:32 < wumpus> yes, that looks good to me now
05:32 -!- laurentmt [~Thunderbi@80.215.178.165] has quit [Quit: laurentmt]     
05:37 -!- laurentmt [~Thunderbi@80.215.178.165] has joined #bitcoin-core-dev     
05:42 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
05:42 -!- laurentmt [~Thunderbi@80.215.178.165] has quit [Quit: laurentmt]     
05:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
05:44 < Victorsueca> michagogo: here's your torrent https://softnet.homenet.org/tokenid_3qsqxgu5wkhopt4k2daqbuxc/
05:45 < Victorsueca> username is bitcoin and password is mdtj4g5w5bppajnpmt2ow2dx
05:45 < Victorsueca> I password protected it so google doesn't bother me with malware removal warnings
05:46 < michagogo> Victorsueca: what's wrong with the other one?
05:47 < michagogo> Also, I'm not at my computer now
05:48 < michagogo> Don't know when I'll be able to get it
05:48 < michagogo> (And why not just a magnet link?)
05:49 < Victorsueca> michagogo: I make my torrents in a way they go sooper-fast :P
05:50 < Victorsueca> I tried it, but the way I do it magnet links are too long for any clipboard
05:51 < Victorsueca> also no need to hurry, take your time until you get to your computer
05:51 < Victorsueca> :)     
05:52 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
05:53 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
05:55 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
05:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:59 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 256 seconds]     
06:00 -!- niska [~niska@68.ip-149-56-14.net] has quit [Remote host closed the connection]     
06:04 < wumpus> github is so slow here...
06:04 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]     
06:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pfofsoayllhncbwn] has quit [Quit: Connection closed for inactivity]     
06:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
06:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
06:12 < jonasschnelli> wumpus: yes. extra-slow at my end as well
06:13 < 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.
06:14 < 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.
06:14 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]     
06:14 < jonasschnelli> I think 6 would be resonable... but we would need to change RPC and GUI
06:14 < jonasschnelli> I don't expect to much bikeshedding
06:15 < GitHub78> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/0e228557f239...7b1bfa3a8786
06:15 < GitHub78> bitcoin/master 0a261b6 Jonas Schnelli: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip()
06:15 < GitHub78> bitcoin/master 3154d6e Jonas Schnelli: [Qt] use NotifyHeaderTip's height and date for the progress update
06:15 < GitHub78> bitcoin/master 7b1bfa3 Jonas Schnelli: Merge #8985: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip()...
06:15 < 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
06:16 < GitHub79> [bitcoin] jonasschnelli closed pull request #8985: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip() (master...2016/10/fix_gui_overlay) https://github.com/bitcoin/bitcoin/pull/8985
06:16 < jonasschnelli> Okay. I see your point.
06:16 < wumpus> yes, I like 6 too
06:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:18 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
06:18 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
06:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]     
06:23 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev     
06:23 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
06:26 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 256 seconds]     
06:55 -!- cryptapus_afk is now known as cryptapus     
06:58 < GitHub53> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7b1bfa3a8786...3fb3fade3c02
06:58 < GitHub53> bitcoin/master 1ae5839 Wladimir J. van der Laan: moveonly: move `coincontrol` to `src/wallet`
06:58 < GitHub53> bitcoin/master 3fb3fad Wladimir J. van der Laan: Merge #8990: moveonly: move `coincontrol` to `src/wallet`...
06:58 < GitHub155> [bitcoin] laanwj closed pull request #8990: moveonly: move `coincontrol` to `src/wallet` (master...2016_10_coincontrol_wallet) https://github.com/bitcoin/bitcoin/pull/8990
07:05  * Victorsueca starts building that
07:08 < jonasschnelli> Hmm... rc2 does not run on OSX 10.7
07:09 < michagogo> Victorsueca: hm, what is it that you do?
07:09 < michagogo> I would have thought a torrent is a torrent…
07:10 -!- murch [~murch@p4FE3A8C9.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
07:10 < 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
07:11 < michagogo> Victorsueca: which settings?
07:11 < Victorsueca> michagogo: the ones when creating a new torrent file
07:11 < michagogo> I'm asking, what settings did you use!
07:11 < michagogo> use?*
07:12 < Victorsueca> not sure if any of them made actually some effect or it's just my connection
07:12 < Victorsueca> let me check...
07:12 < jonasschnelli> ping cfields_ : https://github.com/bitcoin/bitcoin/issues/8577
07:32 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 260 seconds]     
07:39 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Max SendQ exceeded]     
07:40 < Victorsueca> michagogo: set chunk size to 2 MiB and added a lot of trackers (200 or so)
07:40 < Victorsueca> those are the settings
07:41 < michagogo> Victorsueca: pretty sure the chunk size was 2 on mine too
07:41 < michagogo> Or maybe it was 4
07:41 < michagogo> And you can just add trackers...
07:41 < michagogo> Not that it really matters, since DHT+Peer Exchange mean that you don't really need trackers
07:41 < Victorsueca> I guess it's my connection then...
07:42 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev     
07:42 < michagogo> With pex, you really just need 1 other peer
07:42 < michagogo> Like Bitcoin, sort of
07:43 < Victorsueca> well, doesn't really matter, I already started seeding the one I made
07:43 < Victorsueca> I can seed yours tho if you really want
07:44 -!- Alina-malina [~Alina-mal@37.157.216.159] has quit [Changing host]     
07:44 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
07:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:52 < instagibbs_> so why do we make outbound connections to nodes that can't serve us the data we want at all?
07:53 < sipa> instagibbs_: because they may give us addresses of peers that do
07:53 < instagibbs_> currently we don't do churn of those peers though right
07:54 < instagibbs_> like, every X minutes, cycle peers that don't offer services you require
07:54 < instagibbs_> (good point though)
07:54 < sipa> interesting
07:54 < sipa> we do have oneshot connections, which just request an addr and disconnect
07:54 < instagibbs_> yeah, feelers
07:54 < sipa> no, that's something else still :)
07:54 < instagibbs_> oh, doh
07:55 < sipa> those don't even get addresses, but just test whether the address is reachable
07:55 < instagibbs_> oh of course, i misread
07:55 < 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
07:55 < sipa> oneshot connections are used when you're on tor and nedd to use a dns seed for example
07:55 < sipa> Victorsueca: we know whether the service is available before we connect
07:56 < instagibbs_> via service bits
07:56 < instagibbs_> ?     
07:56 < sipa> yes     
07:56 < Victorsueca> but you still need to connect to request addresses tho
07:56 < sipa> yes     
07:56 < sipa> and to generally not worsen partitioning of the network
07:57 < sipa> even if no peers are available that we like, it's still better to keep the network whole
07:57 < instagibbs_> what is it called to talk to a peer for service bits but not connect?
07:57 < sipa> ?     
07:57 < instagibbs_> "we know whether the service is available before we connect" yet we know service bits
07:57 < sipa> yes, because the service bits are in addrdb
07:58 < GitHub36> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3fb3fade3c02...5af9a7117cff
07:58 < GitHub36> bitcoin/master 6f2f639 Jorge Timón: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/
07:58 < GitHub36> bitcoin/master 5af9a71 Wladimir J. van der Laan: Merge #8975: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/...
07:58 < GitHub164> [bitcoin] laanwj closed pull request #8975: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/ (master...0.13-chainparams-init) https://github.com/bitcoin/bitcoin/pull/8975
07:58 < 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
07:59 < GitHub86> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5af9a7117cff...3cf496d102d2
07:59 < GitHub86> bitcoin/master 72ca7d9 Matt Corallo: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock
07:59 < 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
07:59 < GitHub86> bitcoin/master 3cf496d Wladimir J. van der Laan: Merge #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock...
07:59 < Victorsueca> which are stored in the addrdb
07:59 < sipa> Victorsueca: exactly
07:59 < GitHub170> [bitcoin] laanwj closed pull request #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock (master...cmpctblock) https://github.com/bitcoin/bitcoin/pull/8968
07:59 < wumpus> although the services in the addrdb could be wrong, e.g. the peer may have changed services in the mean time
08:00 < instagibbs_> err when do we store them in the addrdb
08:00  * instagibbs_ looking at code
08:00 < sipa> right, but if the services in addrdb are wrong, we treat it as we accidentally connected to the wrong peer
08:00 < BlueMatt> wumpus: wait, when did we decide 8968 was for 0.13.1?
08:00 < BlueMatt> I thoguht we said no in milan?
08:00 < wumpus> oh it isn't?
08:00 < wumpus> removing tag
08:00 < Victorsueca> lel     
08:00 < BlueMatt> yes, I think it is uneccessary for 0.13.1
08:01 < 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
08:01 < BlueMatt> sipa: you're the one who pointed out that cs_main should always be the top lock
08:01 < BlueMatt> so adding a cs_main should be just fine
08:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
08:02 < wumpus> yes, at most you'll be holding it unnecessarily
08:02 < sipa> ah     
08:02 < sipa> well, "should" :)
08:03  * sipa breakfast
08:04 < 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
08:04 < Victorsueca> and I don't know coding at all
08:05 < wumpus> please...
08:05 < sipa> Victorsueca: then perhaps you shouldn't comment in this channel
08:06 < Victorsueca> sorry, hope not to have jinxed you :S
08:07 < BlueMatt> so, thus far, rc2 is final - doc changes?
08:08 < sipa> want me to test whether "cs_main is always the topmost lock" is true?
08:10 < BlueMatt> sipa: please do
08:21 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
08:21 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev     
08:24 -!- roconnor [~roconnor@host-104-157-130-130.dyn.295.ca] has joined #bitcoin-core-dev     
08:33 < BlueMatt> last block: propagated entire fibre network within 4ms of the speed of light between my servers
08:34 < BlueMatt> ok, thats a lie, 10
08:34 < BlueMatt> but whatever, thats pretty good
08:35 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Max SendQ exceeded]     
08:36 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev     
08:37 -!- newrooT [~dingDong@197.237.227.161] has joined #bitcoin-core-dev     
08:37 -!- newrooT [~dingDong@197.237.227.161] has left #bitcoin-core-dev ["Leaving"]     
08:38 < sipa> your technology sucks. you could get the block a full 3000 km further in the same time!
08:39 < BlueMatt> not in glass!
08:40 < BlueMatt> (closer to 1750km)
08:44 -!- Alina-malina [~Alina-mal@37.157.216.159] has quit [Changing host]     
08:44 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
08:51 < sipa> better get working on that vacuum-tube-fiber
08:54 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
08:54 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]     
09:17 < Victorsueca> someone said github was slow before?
09:17 < Victorsueca> I think I found why
09:19 < Victorsueca> someone has been DDoSing Dyn nameservers at US east coast
09:20 < Victorsueca> basically _half_ internet is down
09:20 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
09:22 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
09:24 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]     
09:27 -!- fengling [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
09:28 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
09:35 < rabidus_> Victorsueca: github down for me, also netflix
09:35 < rabidus_> that's all i've found
09:35 < Victorsueca> yeah, it's mostly huge and important services
09:35 < Victorsueca> twitter, amazon, netflix, spotify...
09:36 < jtimon> github, soundcloud, twitter (not from the android app)...
09:36 < jtimon> seems this is it http://arstechnica.com/security/2016/10/dos-attack-on-major-dns-provider-brings-internet-to-morning-crawl/
09:38 < 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.
09:38 < BlueMatt> you want 192.30.253.113
09:38 < rabidus_> amazon.com works
09:38 < BlueMatt> cfields_: it works in most places
09:39 < BlueMatt> google dns appears to be working around it appropriately
09:41 < cfields_> BlueMatt: thanks. my dns setup is a bit weird, i'll wait a bit before changing stuff around
09:41 < BlueMatt> cfields_: hardcode to the above ip, then
09:41 < BlueMatt> (that is github)
09:41 < BlueMatt>  /etc/hosts :)
09:42 < cfields_> BlueMatt: ah perfect, thanks
09:43 -!- fengling [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
09:43 < rabidus_> this was funny: http://www.vox.com/new-money/2016/10/21/13357332/internet-outage-explained
09:43 < rabidus_> because it doesn't work for me
09:44 < sipa> everything seems fine here
09:45 < BlueMatt> sipa: yea, west coast seems mostly fine, as in apac
09:48 < jtimon> alright, setting manual DNS to one in the spanish list here did the trick: http://public-dns.info/
09:50 < rabidus_> it think i'm going with big brother dns
09:50 < rabidus_> good old 8.8.8.8
09:52 < 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
09:53 < jtimon> this kind of thing wouldn't happen if all domains were in a blockchain
09:53  * jtimon hides
09:54  * sipa forks jtimon
09:55 < 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?
09:55 < instagibbs_> this line "if (pfrom->nServicesExpected & ~pfrom->nServices)"
09:56 < sipa> that check is always false if nServicesExpected is 0
09:56 < instagibbs_> I was thinking xor... lol. sorry.
09:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:01 < instagibbs_> Confused myself into thinking logic was "any difference in bits" vs "any expected but missing services"
10:06 -!- cbit [~Camar@198.188.128.33] has joined #bitcoin-core-dev     
10:06 < cbit> yeah, done for me too
10:06 < cbit> down*
10:07 < cbit> west coast here..
10:11 < rabidus_> just started working here in finland
10:11 < rabidus_> at least netflix :P
10:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
10:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:20 -!- cbit [~Camar@198.188.128.33] has quit [Ping timeout: 265 seconds]     
10:28 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
10:38 -!- fengling [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
10:39 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
10:40 < GitHub174> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3cf496d102d2...f08222e882b1
10:40 < GitHub174> bitcoin/master 3a286ab S. Matthew English: Eliminating Inconsistencies in Textual Output...
10:40 < GitHub174> bitcoin/master f08222e MarcoFalke: Merge #8982: Eliminating Inconsistencies in Textual Output...
10:40 < GitHub104> [bitcoin] MarcoFalke closed pull request #8982: Eliminating Inconsistencies in Textual Output (master...patch-6) https://github.com/bitcoin/bitcoin/pull/8982
10:43 -!- cbit [~Camar@198.188.128.33] has joined #bitcoin-core-dev     
10:43 -!- fengling [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
10:49 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
10:50 < BlueMatt> cat /etc/hosts
10:50 < BlueMatt> 192.30.253.113	github.com
10:50 < BlueMatt> 151.101.100.133 assets-cdn.github.com
10:50 < BlueMatt> for those who are missing the cdn entry, though that one might very well be geoip, so have fun on the HKG one
10:51 < rabidus_> or 8.8.8.8,8.8.4.4
10:51 < BlueMatt> github isnt resolving on 8.8.8.8 for me atm
10:51 < rabidus_> wtf, it is for me
10:51 < BlueMatt> 8.8.8.8 isnt just one server :p
10:51 < rabidus_> or then my main dns started working
10:51 < rabidus_> oh, yeah :P
10:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
10:56 < BlueMatt> cfields_: ok, #8969 is ready for review since the cs_main fix was merged :)
10:58 -!- laurentmt [~Thunderbi@80.215.210.162] has joined #bitcoin-core-dev     
10:58 -!- laurentmt [~Thunderbi@80.215.210.162] has quit [Client Quit]     
10:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
11:07 < btcdrak> There are also level3 DNS servers at 4.2.2.1, 4.2.2.2
11:08 < BlueMatt> those dont work from all networks
11:08 < BlueMatt> (also, level3 hates it when you publish those - they're supposed to be for l3 customers)
11:09 -!- cbit [~Camar@198.188.128.33] has quit [Ping timeout: 244 seconds]     
11:23  * btcdrak shrugs
11:28 -!- niska` [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev     
11:29 -!- niska [~niska@68.ip-149-56-14.net] has quit [Ping timeout: 245 seconds]     
11:48 -!- fengling [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
11:52 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kevqghvruvtonmtr] has joined #bitcoin-core-dev     
12:02 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 256 seconds]     
12:08 < jeremyrubin> Annoyingly, Dyn ddos also seems to break travis.
12:09 < jeremyrubin> Because travis doesn't have a pinned ip or something for github, so they can't find any of the repos
12:11 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
12:12 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
12:15 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
12:16 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 260 seconds]     
12:19 < midnightmagic> :-/  What the hell. Why would my GnuPG key require a matching email in order to show as verified in github.
12:20 < midnightmagic> "Sign this message acknowledging you authorize this github user to own your commits."
12:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]     
12:35 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
12:51 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
12:54 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
13:04 < GitHub149> [bitcoin] instagibbs opened pull request #8992: Enable pubkey lookup for p2sh-p2wpkh in validateaddress (master...validatep2pkh) https://github.com/bitcoin/bitcoin/pull/8992
13:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
13:13 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
13:17 -!- cbit [~Camar@198.188.128.33] has joined #bitcoin-core-dev     
13:22 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 250 seconds]     
13:27 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
13:38 -!- cbit [~Camar@198.188.128.33] has quit [Ping timeout: 260 seconds]     
13:49 -!- cryptapus is now known as cryptapus_afk     
13:54 -!- cbit [~Camar@198.188.128.33] has joined #bitcoin-core-dev     
14:03 -!- paveljanik [~paveljani@ip-94-112-170-241.net.upcbroadband.cz] has joined #bitcoin-core-dev     
14:03 -!- paveljanik [~paveljani@ip-94-112-170-241.net.upcbroadband.cz] has quit [Changing host]     
14:03 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
14:14 -!- cbit [~Camar@198.188.128.33] has quit [Ping timeout: 244 seconds]     
14:16 -!- sanada` [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Read error: Connection reset by peer]     
14:19 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
14:26 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 260 seconds]     
14:46 < GitHub91> [bitcoin] paveljanik opened pull request #8993: Trivial: Fix doxygen comment: the transaction is returned in txOut (master...20161021_fix_GetTransaction_comment) https://github.com/bitcoin/bitcoin/pull/8993
14:53 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
14:55 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
15:19 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 252 seconds]     
15:23 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
15:30 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 256 seconds]     
15:36 -!- cdecker [~quassel@2a02:aa16:1105:4a80:1094:c296:7cba:3eb5] has quit [Ping timeout: 250 seconds]     
15:42 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: Leaving]     
15:48 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
15:48 -!- roconnor [~roconnor@host-104-157-130-130.dyn.295.ca] has quit [Ping timeout: 260 seconds]     
15:49 -!- cdecker [~quassel@2a02:aa16:1105:4a80:1094:c296:7cba:3eb5] has joined #bitcoin-core-dev     
15:59 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
16:01 -!- Netsplit *.net <-> *.split quits: Giszmo, berndj, neha, morcos, gijensen, warren, waxwing, Cheeseo
16:01 -!- Netsplit over, joins: warren
16:01 -!- Netsplit *.net <-> *.split quits: harrymm, shaiguitar, aalex, Alina-malina, cfields_, Taek, binns, mkarrer, jouke_, roasbeef,  (+40 more, use /NETSPLIT to show all of them)
16:01 -!- Netsplit *.net <-> *.split quits: echonaut, Arnavion, ghtdak, trippysalmon, aj, Cory, ratoder, PatBoy, Evel-Knievel, Chris_Stewart_5,  (+39 more, use /NETSPLIT to show all of them)
16:01 -!- Netsplit over, joins: Giszmo
16:02 -!- Netsplit over, joins: waxwing
16:03 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev     
16:04 -!- Netsplit over, joins: gluytium
16:06 -!- Netsplit over, joins: gijensen, molz, Eliel, nickler, Alopex, timothy, Evel-Knievel, AtashiCon
16:07 -!- Netsplit over, joins: aspect_, jonasschnelli, cdecker, aalex, sipa, GAit, blkdb, dermoth, whphhg, Lauda
16:07 -!- Netsplit over, joins: Cory, BonyM1, aj, trippysalmon, Guest13412, haakonn, harding, berndj, afk11, achow101 (+3 more)
16:07 -!- Netsplit over, joins: justanotheruser, niska`, jtimon, wasi, sdaftuar, murch, baldur
16:07 -!- Netsplit over, joins: GreenIsMyPepper
16:07 -!- Netsplit over, joins: luke-jr, gmaxwell, Anduck, arubi, ghtdak, AaronvanW, rabidus_, asoltys_, davec
16:08 -!- Netsplit over, joins: echonaut, morcos, adiabat, Chris_Stewart_5, kinlo, shaiguitar, cryptapus_afk
16:08 -!- Netsplit over, joins: cjcj, instagibbs_
16:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
16:08 -!- Netsplit over, joins: btcdrak, Taek, Ylbam, nsh, d_t, Lightsword, pindarhk, binns, jouke_, roasbeef (+18 more)
16:08 -!- Alina-malina [~Alina-mal@37.157.216.159] has quit [Max SendQ exceeded]     
16:08 -!- neha [~narula@18.26.5.3] has joined #bitcoin-core-dev     
16:08 -!- Netsplit over, joins: alpalp, BashCo_, instagibbs, [b__b], kadoban, BCBot, tulip
16:08 -!- Alopex1 [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
16:10 -!- eragmus [sid136308@gateway/web/irccloud.com/x-amxzsavemqefgacl] has quit [Ping timeout: 255 seconds]     
16:10 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev     
16:11 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 250 seconds]     
16:11 -!- binns [sid105317@21/bitcoin/binns] has quit [Ping timeout: 250 seconds]     
16:12 -!- PatBoy [xyz@192.99.249.194] has joined #bitcoin-core-dev     
16:12 -!- wumpus [~wumpus@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev     
16:13 -!- berndj is now known as Guest27486     
16:13 -!- CodeShark [sid126576@gateway/web/irccloud.com/session] has joined #bitcoin-core-dev     
16:14 -!- murch [~murch@p4FE3A8C9.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
16:14 -!- murch [~murch@p4FE3A8C9.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
16:16 -!- ibrightly [sid113387@gateway/web/irccloud.com/session] has joined #bitcoin-core-dev     
16:16 -!- CodeShark [sid126576@gateway/web/irccloud.com/session] has quit [Changing host]     
16:16 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-dfdssawwndcelzuu] has joined #bitcoin-core-dev     
16:16 -!- ibrightly [sid113387@gateway/web/irccloud.com/session] has quit [Changing host]     
16:16 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-jvyqvfgkfxtnuxqk] has joined #bitcoin-core-dev     
16:17 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-gyndjovkttvjkawj] has joined #bitcoin-core-dev     
16:24 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
16:26 -!- zmanian____ [sid113594@gateway/web/irccloud.com/x-qqujesaelcdtohed] has joined #bitcoin-core-dev     
16:27 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
16:28 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
16:29 -!- mappum [sid43795@gateway/web/irccloud.com/x-pvbatempfqkljggs] has joined #bitcoin-core-dev     
16:30 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 245 seconds]     
16:31 -!- binns [sid105317@21/bitcoin/binns] has joined #bitcoin-core-dev     
16:32 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 256 seconds]     
16:36 -!- eragmus [sid136308@gateway/web/irccloud.com/x-ryomcompfzoohwlo] has joined #bitcoin-core-dev     
16:37 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev     
16:39 -!- alpalp [~allen@2605:6000:f4d6:d600::3] has joined #bitcoin-core-dev     
16:39 -!- alpalp [~allen@2605:6000:f4d6:d600::3] has quit [Changing host]     
16:39 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
16:43 -!- murch [~murch@p4FE3A8C9.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
16:49 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:ad83:a085:bae0:8c66] has quit [Quit: .]     
16:52 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:29c6:6db4:5113:159] has joined #bitcoin-core-dev     
16:59 -!- Alina-malina [~Alina-mal@37.157.216.159] has quit [Max SendQ exceeded]     
17:00 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev     
17:02 -!- Alina-malina [~Alina-mal@37.157.216.159] has quit [Changing host]     
17:02 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
17:03 -!- cbit [~Camar@4.35.154.115] has joined #bitcoin-core-dev     
17:13 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 256 seconds]     
17:14 -!- roconnor [~roconnor@host-104-157-130-130.dyn.295.ca] has joined #bitcoin-core-dev     
17:17 -!- cbit [~Camar@4.35.154.115] has quit [Ping timeout: 250 seconds]     
17:29 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
17:34 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
17:35 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 265 seconds]     
17:42 -!- cbit [~Camar@2602:306:bdb9:adf0:2cb1:17ad:6662:4f35] has joined #bitcoin-core-dev     
17:49 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
17:57 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:29c6:6db4:5113:159] has quit [Quit: .]     
18:05 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:d2c:1473:4cac:761e] has joined #bitcoin-core-dev     
18:19 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
18:21 -!- cbit [~Camar@2602:306:bdb9:adf0:2cb1:17ad:6662:4f35] has quit [Ping timeout: 245 seconds]     
18:24 -!- Guest27486 is now known as berndj     
18:28 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
18:31 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
18:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
18:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
18:37 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 245 seconds]     
18:38 -!- Alopex1 [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
18:39 -!- cbit [~Camar@2607:fb90:2202:4405:7414:2129:6283:a7cc] has joined #bitcoin-core-dev     
18:39 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
18:44 -!- cbit [~Camar@2607:fb90:2202:4405:7414:2129:6283:a7cc] has quit [Ping timeout: 245 seconds]     
18:51 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:d2c:1473:4cac:761e] has quit [Quit: .]     
18:53 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:7170:5354:1132:b152] has joined #bitcoin-core-dev     
19:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]     
19:04 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
19:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
19:12 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
19:22 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
19:23 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
19:25 < GitHub101> [bitcoin] jtimon opened pull request #8994: Testchains: Introduce custom chain whose constructor...  (master...0.13-new-testchain) https://github.com/bitcoin/bitcoin/pull/8994
19:27 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 260 seconds]     
19:33 < gmaxwell> jtimon: regarding your comment in lightning-dev, it's kind of rude to the community here to go around to our end users to advocate a pull request that has been open for 7 minutes.
19:35 < jtimon> gmaxwell: thanks, noted. I'm poor in netiquette I think
19:36 < jtimon> I was thinking about them while wrting the btanch though, in my defense
19:36 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
19:37 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-nbgrzgpbqrokfpzj] has quit [Quit: Connection closed for inactivity]     
19:39 < gmaxwell> Sure, and in this case I don't think it answers what they were asking about. Their concern was that they want a globally shared public testnet, but without having a 2000 block reorg every couple months that breaks their stuff. :)
19:39 < gmaxwell> and having chainparames in a file doesn't really change that.
19:46 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
19:53 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
19:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kevqghvruvtonmtr] has quit [Quit: Connection closed for inactivity]     
20:00 -!- xinxi [~xinxi@116.87.187.139] has quit [Quit: Leaving...]     
20:02 < GitHub9> [bitcoin] TheBlueMatt opened pull request #8995: Add missing cs_main lock to ::GETBLOCKTXN processing (master...2016-10-fix-getblocktxn-locks) https://github.com/bitcoin/bitcoin/pull/8995
20:23 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 245 seconds]     
20:38 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
20:43 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
20:44 -!- cbit [~Camar@172.56.31.125] has joined #bitcoin-core-dev     
20:45 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds]     
21:02 -!- cbit [~Camar@172.56.31.125] has quit [Ping timeout: 260 seconds]     
21:04 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
21:07 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
21:08 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
21:11 -!- cbit [~Camar@2605:e000:ae0a:aa00:5cf6:d717:5837:622a] has joined #bitcoin-core-dev     
21:27 -!- fengling [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
21:29 -!- Camar_ [~Camar@2605:e000:ae0a:aa00:43b:7cb5:3aee:4510] has joined #bitcoin-core-dev     
21:29 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]     
21:30 -!- cbit [~Camar@2605:e000:ae0a:aa00:5cf6:d717:5837:622a] has quit [Ping timeout: 256 seconds]     
21:33 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
21:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
21:48 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
21:51 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
21:55 -!- Camar_ [~Camar@2605:e000:ae0a:aa00:43b:7cb5:3aee:4510] has quit [Read error: Connection reset by peer]     
21:58 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Max SendQ exceeded]     
21:58 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev     
21:58 -!- aalex [~aalex@64.187.177.58] has quit [Max SendQ exceeded]     
21:59 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
22:14 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
22:15 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:16 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:23 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
22:29 -!- aalex [~aalex@64.187.177.58] has quit [Max SendQ exceeded]     
22:29 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
22:34 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
22:38 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
22:39 -!- roconnor_ [~roconnor@host-104-157-130-130.dyn.295.ca] has joined #bitcoin-core-dev     
22:41 -!- roconnor [~roconnor@host-104-157-130-130.dyn.295.ca] has quit [Ping timeout: 265 seconds]     
22:45 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]     
22:48 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
22:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:50 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-rciknzszcjtggjyd] has joined #bitcoin-core-dev     
22:59 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 245 seconds]     
23:00 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
23:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
23:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
23:19 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
23:33 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
23:56 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 256 seconds]     
23:56 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev     
23:58 < wumpus> < gmaxwell> and having chainparames in a file doesn't really change that <- well it could. There's no rule that people can't share chainparams file
23:59 < wumpus> with chainparams files they could have arbitrarily defined shared testsnets, sharable by just copying a file
23:59 < wumpus> that's 100% better than having to go through our review process every time whether some network is really worth defining