--- Day changed Tue Oct 25 2016
00:00 < wumpus> bleh. So usually it's advised to do pointer arithmethic using [u]char*. But this runs into the issue with comparing ranges.
00:00 < wumpus> This makes me sick
00:03 < sipa> and you get aliasing rules too
00:03 < wumpus> C: "between Scylla and Charybdis"
00:03 < wumpus> I don't want to do this anymore
00:03 < sipa> :)     
00:03 < sipa> i don't think any of this matters
00:08 < sipa> btw: i believe char* pointers are always allowed to alias anything
00:08 < sipa> so if that's the reason for wanting to avoid them, no worries
00:12 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
00:15 < wumpus> will try to change uses of uintptr_t to char* and see if it still makes sense. I'd like to keep the interface as void* though so will need static_casts there (but maybe that's better than reinterpret_cast)
00:19 < phantomcircuit> cccccceegehfceddehkuieubrvvrejvvbbnlrclrighk
00:20 < jonasschnelli> your new private key?
00:21 < wumpus> "this is your brain on C"
00:21 < tulip> phantomcircuit: try not spilling soda on your keyboard next time.
00:22 < sipa> wumpus: where c is the speed of light, so you're saying he's on speed?
00:22 < sipa> i'll see myself out
00:23 < tulip> I've been trying to work out where the regression that allows bitcoin core to attempt connections on port 0 is.
00:23 < wumpus> I had imagined it more like some kind of hallucogenic substance, twisting time and space in arbitrary and disjointed ways, but sure, speed will do too :)
00:24  * wumpus still wonders if cfields_ got caught by macosx' digest function, he's strangely silent
00:24 < tulip> also sort of interested why my addrman has lots of invalid IPv6 addresses. feels like a fingerprinting attack of some description, as they're unique. 
00:25 < tulip> 2016-10-25 03:04:55.029570 connect() to [376f:ff56:100::]:0 failed: Host is down (64) <- like this 
00:25 < gmaxwell> tulip: the attempts to port 0 may be a side effect of the witness preference.
00:25 < wumpus> tulip: did it ever had an explicit check to not try port 0? I think it has a prefernce for its own port, but there it stops
00:26 < tulip> gmaxwell: my thinking was that they were always there, just never chosen before because we never reached the fall back. 
00:26 < gmaxwell> bingo.
00:26 < wumpus> it'd make sense to discard records with port 0 as invalid though
00:27 < gmaxwell> It doesn't try non-default ports until after 50 tries... but now it's much more likely to make 50 tries due to the witness stuff.
00:27 -!- whphhg [whphhg@gateway/vpn/mullvad/x-oezagxmxbgtvphke] has quit [Quit: Leaving]     
00:27 < tulip> oh, so choosing not to connect to a node counts as a try? 
00:27 < gmaxwell> we should probably prevent port 0 from ending up in addrman at all.
00:27 < gmaxwell> tulip: yes sir. read the loop in CConman:ThreadOpenConnections()
00:28 < wumpus> yes, like invalid addresses, invalid ports probably shouldn't end up in addrman at all
00:29 < wumpus> may makesense to add a generic blacklist of ports. 22, 25, etc
00:29 < tulip> the only invalid IP address I've seen in my logs is 255.255.0.0, the IPV6 ones are valid but unroutable 
00:30 < gmaxwell> I do wonder if there is much purpose to automatic connections to non-standard ports at all.  In the far past it arguably could have helped the network heal across firewalling, but w/ things like tor there is much less reason for it, and I would expect there are few to no hosts to connect to.
00:30 < gmaxwell> tulip: addrman already filters several broad families of invalid IPs.
00:30 < gmaxwell> s/invalid/non-routable/ really
00:30 < wumpus> meh, I'd prefer not to hardcode the port even further
00:31 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Ping timeout: 245 seconds]     
00:33 < wumpus> I agree that tor or vpns are a better way to avoid more persistent firewalling, but ideally bitcoin core would get around the simple case of 'port 8333 firewalled'
00:33 < gmaxwell> ya, but does it? requires there be enough non-8333 hosts to actually find a working one. :P
00:33 < wumpus> otherwise it may suddenly become a really attractive measure
00:34 < wumpus> there are some non-8333 hosts to connect to
00:34 < gmaxwell> fair enough. 
00:34 < tulip> there's 1990 peers ever to have been crawled by this seed node which have a non standard port. 
00:36 < tulip> port frequencies http://pastebin.com/raw/wZSSDYW6
00:36 < wumpus> may make sense to listen on 8333 as well as arandom non-standard port
00:36 < wumpus> 8333 to make sure people connect to you, and the non-standard port to help people behind weird firewalls
00:37 < gmaxwell> wumpus: I was just thinking that too. 
00:38 < wumpus> and for the built-in seed node selection there should probably be some non-standard ports too
00:38 < gmaxwell> well also something we could deploy on relatively short notice if there were a widespread reason.
00:38 < gmaxwell> seed nodes make sense.
00:39 < gmaxwell> my general expirence with firewalls that block random ports is that they block all of them, so really the only way to get through them is to use :443 or :80
00:39 < wumpus> sure, I agree, but it just seems stupid to have so-called robust P2P software be blocked by filtering out one port :)
00:40 < wumpus> it also means you can make a selection "no bitcoin here, but we allow dogecoin and litecoin through!"
00:41 < sipa> we should make the port depend on the (routable) IP
00:42 < sipa> 1024 + H("bitcoin port" || ip) % (32768 - 1024)
00:43 < luke-jr> can we not at least not require uint256 math support? :x
00:43 < sipa> sure
00:43 < gmaxwell> yea, but sadly we don't really know our IP at the relevant time.
00:44 < sipa> we need to implement IP over reddit.
00:44 < wumpus> "spread spectrum TCP" hehe
00:44 < gmaxwell> it's harmless to just save a port to peers.dat and try to use it.
00:45 < luke-jr> sipa: can we make an encoding that looks like r/BTC posters? :p
00:45 < sipa> luke-jr: working on software for that!
00:45 < tulip> https://www.reddit.com/r/blockchainheaders/
00:46 < sipa> tulip: last post 1 week ago :(
00:47 < rabidus_> maybe blockchain is dead
00:48 < luke-jr> :x     
00:49 < sipa> ok, it's over guys
00:49 < sipa> let's go do dollar instead
00:49 < wumpus> yep, we've reached the end
00:50 < gmaxwell> I am trying to send my dollar over the internet but it will not send.
00:50 < sipa> how do we get more people to use dollar?
00:50 < gmaxwell> My transaction is stuck in the cup holder and it will not open anymore.
00:53 < wumpus> gmaxwell: for some reason no one accepts scanned dollar bills as payment
00:54 < wumpus> possibly there is a double-spending problem
00:55 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
00:56 < gmaxwell> Really? But I heard Microsoft was migrating to dollar.
00:57 < tulip> sipa: the reddit api implementation decided to do an incompatible re-write and drop it as a replacement under the same name in pypi. I can't really be bothered fixing what amounts to a joke. 
01:02 < tulip> it should ideally be possible for people to do block data downloads over other transports, but reddit is a particularly ridiculous one. 
01:03 -!- laurentmt [~Thunderbi@80.215.138.218] has joined #bitcoin-core-dev     
01:03 -!- laurentmt [~Thunderbi@80.215.138.218] has quit [Client Quit]     
01:04 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:05 < luke-jr> tulip: but we all know reddit is censorship-proof
01:06 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
01:08 < gmaxwell> any guesses what happened here? this is the second or maybe third time I've seen this: http://0bin.net/paste/TlJ+g8dEsUb7JJpa#4B0Izyd57LaA9MxAvgB7A0pa+HwtwXY8i90So-WYat9  (others not with the noconnect stuff, I believe, doubt thats related)
01:08 < phantomcircuit> tulip: oh nose now someone can login to yubico as me
01:09 < luke-jr> gmaxwell: my guess is bitcoind didn't stop before you tried to start it again
01:09 < luke-jr> although I would expect a debug.log to be generated in that case
01:09 < gmaxwell> then why didn't the startup throw a lockfile error.
01:10 < phantomcircuit> gmaxwell: disk space?
01:10 < phantomcircuit> nfs or something weird?
01:10 < phantomcircuit> debug.log being trimmed?
01:10 < gmaxwell> no actually .. damn, its not throwing an error anymore!
01:10 < gmaxwell> just always says "Bitcoin server starting" :P
01:10 < phantomcircuit> ptrace
01:11 < gmaxwell> so I think it's throwing that error after daemonizing so I never see it.
01:11 < gmaxwell> yea, with daemon=0, I get the expected cannot obtain a lock.
01:11 < gmaxwell> well one mystery solved and a new one created...
01:11 < luke-jr> heh, I assumed daemon was 0 because you didn't specify it on the commandline XD
01:12 < luke-jr> wait nm
01:12  * luke-jr must be getting tired
01:16  * gmaxwell opens issue
01:16 < btcdrak> making the dollar bill larger will increase adoption
01:17 < wumpus> btcdrak: haha I had the same thought
01:17 -!- thokon00 [~thokon00@unaffiliated/thokon00] has joined #bitcoin-core-dev     
01:17 < gmaxwell> well I heard that all it took was changing a 1 to a 2, but I also heard someone who tried that and got harassed by the secret service!
01:18 < wumpus> btcdrak: but but but you'll need larger wallets to handle the awkward bills, prompting people to store them centrally!
01:19 < luke-jr> wumpus: it's okay, I will use visa.info
01:20 < luke-jr> man, the analogy there is surprising.
01:21 < wumpus> gmaxwell: yeah it's sort of a known issue https://github.com/bitcoin/bitcoin/pull/8278#issuecomment-242706794  , though opening an issue to track it wouldn't hurt
01:21 < wumpus> all the messages printed to stdout/stderr also need to go to the log
01:24 -!- whphhg [whphhg@gateway/vpn/mullvad/x-lxokzibzsmrcthkr] has joined #bitcoin-core-dev     
01:29 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Read error: Connection reset by peer]     
01:45 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
02:22 -!- laurentmt [~Thunderbi@80.215.138.218] has joined #bitcoin-core-dev     
02:24 -!- laurentmt [~Thunderbi@80.215.138.218] has quit [Client Quit]     
02:34 -!- face_ [~face@mail.hmel.org] has joined #bitcoin-core-dev     
02:36 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
02:38 -!- face_ is now known as face     
02:39 -!- Samdney [~Samdney@pD95181BA.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
02:39 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Client Quit]     
02:41 -!- cdecker [~quassel@2a02:aa16:1105:4a80:2df5:2764:457c:288] has joined #bitcoin-core-dev     
02:42 -!- cryptapus [~cryptapus@87.254.202.141] has joined #bitcoin-core-dev     
02:42 -!- cryptapus [~cryptapus@87.254.202.141] has quit [Changing host]     
02:42 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
02:43 -!- murch [~murch@p4FE3AAFE.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
02:55 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
02:56 < luke-jr> rebased multiwallet stuff on latest master including jonasschnelli's suggestions. hopefully unaffected by half-asleepness. :x
02:57 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
03:05 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:06 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]     
03:06 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
03:06 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host]     
03:06 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:11 -!- Samdney [~Samdney@pD95181BA.dip0.t-ipconnect.de] has quit [Read error: Connection timed out]     
03:12 -!- Samdney [~Samdney@pD95181BA.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
03:18 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Read error: Connection reset by peer]     
03:21 < GitHub194> [bitcoin] laanwj opened pull request #9010: Split up AppInit2 into multiple phases, daemonize after datadir lock errors (master...2016_10_init_split_daemon) https://github.com/bitcoin/bitcoin/pull/9010
03:24 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
03:27 < GitHub59> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/67728a389ccf...e1d1f57b56b2
03:27 < GitHub59> bitcoin/master 515e264 Gregory Maxwell: Make connect=0 disable automatic outbound connections....
03:27 < GitHub59> bitcoin/master e1d1f57 Wladimir J. van der Laan: Merge #9002: Make connect=0 disable automatic outbound connections....
03:28 < GitHub130> [bitcoin] laanwj closed pull request #9002: Make connect=0 disable automatic outbound connections. (master...connect0) https://github.com/bitcoin/bitcoin/pull/9002
03:31 -!- Samdney [~Samdney@pD95181BA.dip0.t-ipconnect.de] has quit [Quit: Verlassend]     
03:34 < btcdrak> luke-jr: #8694? I was meaning to test that out.
03:34 < luke-jr> btcdrak: yeah.
03:37 < GitHub103> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e1d1f57b56b2...f14f07cb94eb
03:37 < GitHub103> bitcoin/master fa1c3c2 MarcoFalke: [net] Remove assert(nMaxInbound > 0)...
03:37 < GitHub103> bitcoin/master f14f07c Wladimir J. van der Laan: Merge #9008: [net] Remove assert(nMaxInbound > 0)...
03:37 < GitHub161> [bitcoin] laanwj closed pull request #9008: [net] Remove assert(nMaxInbound > 0) (master...Mf1610-netAssert) https://github.com/bitcoin/bitcoin/pull/9008
03:40 < GitHub138> [bitcoin] laanwj opened pull request #9011: 0.13.1 backports conditional on rc3 (0.13...2016_10_backports_conditional_rc3) https://github.com/bitcoin/bitcoin/pull/9011
03:45 < luke-jr> wumpus: 8784 should be harmless regardless of rc3
03:46 < luke-jr> wumpus: will you be merging release notes in from the blog post, or would it help if I make a PR to do that?
03:55 < wumpus> yes that'd be helpful I'll likely not be moerging release notes from anywhere but github pulls
04:25 < GitHub186> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f14f07cb94eb...e077e0030384
04:25 < GitHub186> bitcoin/master 3f7581d Micha: [TRIVIAL] reorder Windows gitian build order to match Linux...
04:25 < GitHub186> bitcoin/master e077e00 Wladimir J. van der Laan: Merge #8948: [TRIVIAL] reorder Windows gitian build order to match Linux...
04:25 < GitHub175> [bitcoin] laanwj closed pull request #8948: [TRIVIAL] reorder Windows gitian build order to match Linux (master...master) https://github.com/bitcoin/bitcoin/pull/8948
04:26 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
04:32 < GitHub43> [bitcoin] luke-jr opened pull request #9012: release-notes: Update from blog draft (0.13...0.13.1_relnotes_update) https://github.com/bitcoin/bitcoin/pull/9012
04:37 < luke-jr> and with that, I'm heading to bed, night
04:43 -!- cdecker [~quassel@2a02:aa16:1105:4a80:2df5:2764:457c:288] has quit [Ping timeout: 260 seconds]     
04:45 -!- cjcj [d4555899@gateway/web/freenode/ip.212.85.88.153] has quit [Quit: Page closed]     
04:50 < wumpus> jonasschnelli: re: https://github.com/bitcoin/bitcoin/pull/9010, any idea why not all parameter interaction was moved to InitParameterInteraction?
04:57 < wumpus> it's a bit silly after that, with both a InitParameterInteraction and AppInitParameterInteraction :)
04:59 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Read error: Connection reset by peer]     
05:03 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
05:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:12 < GitHub65> [bitcoin] laanwj closed pull request #9012: release-notes: Update from blog draft (0.13...0.13.1_relnotes_update) https://github.com/bitcoin/bitcoin/pull/9012
05:12 < GitHub37> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/c9a5baddeef3...cb699885728f
05:12 < GitHub37> bitcoin/0.13 99f5cf1 Luke Dashjr: release-notes: Update from blog draft
05:12 < GitHub37> bitcoin/0.13 cb69988 Wladimir J. van der Laan: Merge #9012: release-notes: Update from blog draft...
05:16 -!- murch [~murch@p4FE3AAFE.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
05:22 < GitHub99> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/e077e0030384...9bdf5269f886
05:22 < GitHub99> bitcoin/master f48211b Pieter Wuille: Bypass removeRecursive in removeForReorg
05:22 < GitHub99> bitcoin/master 51f2783 Pieter Wuille: Make removed and conflicted arguments optional to remove
05:22 < GitHub99> bitcoin/master 4100499 Pieter Wuille: Return shared_ptr<CTransaction> from mempool removes
05:22 < GitHub126> [bitcoin] laanwj closed pull request #8515: A few mempool removal optimizations (master...moresharedmem) https://github.com/bitcoin/bitcoin/pull/8515
05:40 -!- laurentmt [~Thunderbi@80.215.138.218] has joined #bitcoin-core-dev     
05:41 < achow101> will there be an rc3?
05:41 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Ping timeout: 245 seconds]     
05:46 < wumpus> not at this point, but that's never sure, a critical issue could up any time
05:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]     
05:49 -!- laurentmt [~Thunderbi@80.215.138.218] has quit [Ping timeout: 250 seconds]     
05:54 -!- laurentmt [~Thunderbi@80.215.138.218] has joined #bitcoin-core-dev     
05:57 -!- laurentmt [~Thunderbi@80.215.138.218] has quit [Client Quit]     
06:03 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
06:20 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer]     
06:21 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev     
06:24 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
06:32 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
06:34 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds]     
06:34 -!- LeMiner2 is now known as LeMiner     
06:36 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
06:51 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
07:07 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
07:12 < instagibbs> I've been doing some work on preparation for switching to p2sh-p2wpkh for default addresses in Core, and was wondering what the actual roll out might look like as far as rpc calls go. Has anyone thought about this much?
07:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
07:12 < instagibbs> ie, will getnewaddress return those new address types, will there be a new call for that instead, etc
07:18 < sipa> instagibbs: i would think there is a cmdline option that sets the default, which is introduced after activation
07:19 < sipa> instagibbs: and maybe at some point the default for that flag is changed
07:19 < instagibbs> Ah, ok that might make sense
07:19 < instagibbs> fixing tests may only mean a single line per test
07:19 < instagibbs> at least in immediate term, even if one flips the default
07:21 < instagibbs> I'm switching to segwit addresses by default, seeing what breaks. Some are just how tests are written, and would be a huge pain to change manually.
07:21 -!- roconnor [~roconnor@host-45-78-195-208.dyn.295.ca] has joined #bitcoin-core-dev     
07:22 -!- LeMiner [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 260 seconds]     
07:22 < wumpus> there should be a flag to getnewaddress what kind of address to return, I suppose
07:23 < wumpus> the default of that could depend on a command-line option
07:23 < instagibbs> that's what I tried first, but number of flags is quite long :) might be complementary of course
07:24 < instagibbs> (also you don't want to have to change every instance of getnewaddress in the test codebase)
07:24 < wumpus> have you seen my named-rpc-arguments pull? it would make coping with lots of flags easier
07:24 < wumpus> sure, but still want to test old addresses in the test codebase I suppose, so you don't get around some changing there
07:25 < instagibbs> yes, and test transition from non-segwit to segwit, etc
07:25 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 256 seconds]     
07:25 < instagibbs> link to pr?
07:25 < wumpus> https://github.com/bitcoin/bitcoin/pull/8811
07:26 < sipa> wumpus: oh, so a named argument to getnewaddress, which defaults to the cmdline value, whose value defaults to a constant, and we'll change that constant sometime later.
07:26 < sipa> double indirections yay
07:26 < wumpus> sipa: well it should be possible to override it through the RPC call at least
07:27 < wumpus> I don't think the behavior should only depend on an ambient setting that can only be changed with a command-line argument at starting time
07:27 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
07:28 < wumpus> seems bad both for testing and actual usage
07:28 -!- owowo [ovovo@gateway/vpn/mullvad/x-ilfadhhwzpaybxtz] has quit [Ping timeout: 244 seconds]     
07:29 < wumpus> and there may be other types of addresses to return in the future
07:29 < wumpus> so an address ttpe argument to getnewaddress would make sense
07:29 < instagibbs> I'll think on this while I'm working on it. Stuff like "verifymessage requires you to know the uint160(pubkey)"
07:29 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev     
07:30 -!- tulip [uid192128@gateway/web/irccloud.com/x-yixvcbjnvzvdknir] has quit [Quit: Connection closed for inactivity]     
07:45 < BlueMatt> hum...are any of the fixes currently proposed as backports for rc3 regressions since 13.0?
07:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:47 < sipa> BlueMatt: the blocktxn lock is
07:47 < GitHub198> [bitcoin] gtsui opened pull request #9013: Trivial: Explicitly pass const CChainParams& to LoadBlockIndexDB() (master...global-params-cleanup) https://github.com/bitcoin/bitcoin/pull/9013
07:47 < BlueMatt> sipa: it is?!
07:47 < wumpus> the assert too
07:48 < BlueMatt> oh, i was mostly asking about the assert
07:48 < BlueMatt> damn :(
07:48 < sipa> BlueMatt: compact blocks and feelers are in 0.13.0
07:48 < wumpus> this ws introduced in the 'feelers' commit which IIRC was introduced after 0.13.0
07:48 < BlueMatt> sipa: i said regressions since 13
07:49 < wumpus> but I'm not 100% sure
07:49 < sipa> oh, you mean regressions introduced strictly after 0.13.0?
07:49 < BlueMatt> wumpus: thats what i thought about the asserts, which sucks
07:49 < BlueMatt> sipa: yes
07:49 < sipa> ah     
07:49 < sipa> "since" is ambiguous, i guess :)
07:49 < BlueMatt> sipa: ie if they are regressions /since/ 0.13.0 then we should do rc3, otherwise i was gonna propose 0.13.2 with them
07:49 < wumpus> the license ones and relayrpriority error are just nice to include but low risk and very low priority
07:50 < wumpus> I'm not sure the assert one warrants a rc3 yet
07:51 < wumpus> it's a problem that is not remote triggerable and easy to work around by increasing maxconnections
07:51 < wumpus> note that it asserts the maximum, not the current value
07:51 < sipa> i'm surprised it took us so long to find
07:51 < sipa> especially since it is 0.13.0
07:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
07:51 < sipa> and nobody reported it
07:52 < BlueMatt> sipa: thats the point of rcs
07:52 < BlueMatt> wumpus: yea, I'm trying to decide how i feel about rc3, hence the questions
07:52 < sipa> BlueMatt: well, yes, but it wasn't found in the 0.13.0 rc
07:52 < wumpus> feeler connections was not in 0.13.0
07:52 < BlueMatt> sipa: oh, the assert was in 0.13.0?
07:52 < BlueMatt> yea, thats what i thought
07:53 < wumpus> no, it was added in 2611ad7 (part of #8679), which are post-0.13.0 backports
07:53 < wumpus> I don't know anymore why it was flagged for backport in the first place
07:54 < BlueMatt> feelers? folks wanted feelers to reinforce the preferential-peering stuff
07:54 < BlueMatt> to ensure we find out service bits
07:54 < wumpus> ok     
07:55 < BlueMatt> at least afaiu
07:55 < wumpus> (apparantly I added the backport label to #8282, but didn't add any rationale, and there's no discussion there. But your reasoning makes sense)
07:55 < instagibbs> yes that was the reasoning
07:56 < sipa> indeed, i think it was discussed in a meeting
08:05 < wumpus> in any case if people agree that the assert issue warrants an rc we should roll it immediately, to delay the release as little as possible
08:06 < wumpus> right now it'd set earliest-possible-final date to next week, which'd be oct 1
08:06 < wumpus> NOV 1
08:07 < sipa> we all know that 31 OCT == 25 DEC.
08:09 < BlueMatt> *facepalm*
08:10 < BlueMatt> wumpus: I'd vote no
08:10 < BlueMatt> its a local assert against a very strange configuration and a missing lock that seems nearly impossible to cause problems with, including a requirement that you be doing something stragely locally
08:13 < sipa> maxconnections set to 8 or lower is very common , i think
08:16 < sipa> though, given that it took so long to find, perhaps less common than i thought
08:16 < BlueMatt> so its maxconnections < 8 and then you get an incoming connectiotn?
08:16 < BlueMatt> I mean i think maxconnections < 8 with incoming connections is maybe strange?
08:18 < wumpus> I don't think it is *very* common
08:20 < BlueMatt> I'm ok with an 0.13.2 for this, delaying 0.13.1 for this seems overkill
08:20 < sipa> ok     
08:22 < btcdrak> ack     
08:30 < BlueMatt> so pending no other bugs 0.13.0-final would be tagaged on thurs?
08:33 < GitHub26> [bitcoin] TheBlueMatt opened pull request #9014: Fix block-connection performance regression (master...2016-10-fix-tx-regression) https://github.com/bitcoin/bitcoin/pull/9014
08:34 < BlueMatt> ehh, 13.1-final
08:39 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
08:52 < wumpus> yes     
09:14 < gmaxwell> I asked for the backport and the issue is that without feelers addrman learns about witness peers VERY slowly.
09:19 < gmaxwell> Sorry that it caused problems, though I still feel it was a good decision. I'm happier about a 0.13.1 that can't run with maxconnections<10 than one that doesn't learn update its addrman for peer info.
09:21 < gmaxwell> wumpus: the downside of that maxconnections assert is this: there are people running max connections cut down to smaller numbers (we've recommended it in the past, I've encountered users with it, etc).  I don't know how many but they exist.  And the assert only happens when an inbound connection happens.
09:21 < gmaxwell> So you'll start the node, think it's all happy, then then boom, it crashes.
09:24 < gmaxwell> I don't think that there is a ~need~ to delay, but I do think it would more or less immediately require a 0.13.2.
09:34 < btcdrak> easily documented in the release notes under known issues
09:35 < gmaxwell> yes, well it _will_ cause surprise crashes for some users. As not everyone reads the release notes.
09:36 < btcdrak> maybe, but if people dont RTM there isnt much you can do.
09:37 < gmaxwell> 'crashes'-- not really a crash in the kind of uncontrolled failure that could be truly bad that a crash usually is, but the user can't see te difference.
09:47 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
09:47 < BlueMatt> gmaxwell: yea, I agree its really not good, but i also dont think its worth delaying 0.13.1 for it
09:48 < gmaxwell> Is that really the question?  Are we otherwise going to do the final today?
09:54 < gmaxwell> grepping my logs,
09:54 < gmaxwell> 05:57 < gijensen> I run my tn node with maxconnections=8
09:54 < gmaxwell> 08:54 < KipIngram> I'm running with maxconnections=5 and dbcache=768.
09:55 < gmaxwell> 02:06 < epscy> pancake: setting maxconnections to 4 (or 3) helped me
09:56 < gmaxwell> 11:01 < geir> Tried bitcoind -dbcache=50 -nolisten -maxconnections=8
09:56 < BlueMatt> so which is worse: shipping segwit with only 13/14 days (incl weekends) before first possible lock-in or shipping with a known assert and following up with a 0.13.2 very quickly
09:56 < gmaxwell> 10:13 < osmosis> i was able to get what I wanted by using, -maxconnections=0  for testing
09:56 < gmaxwell> 08:11 < m0gliE> -maxconnections=6
09:57 < gmaxwell> 01:15 < Krellan> As it is now, when I lower maxconnections below 8, my node becomes 100% outbound, no inbound.
09:57 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
09:58 < gmaxwell> 13:16 < HM2> maxconnections=8, server=0
09:59 < gmaxwell> there are a lot more with the figure being >=10.  And it was more common further in the past to see people mention it.
09:59 < BlueMatt> <BlueMatt> so which is worse: shipping segwit with only 13/14 days (incl weekends) before first possible lock-in or shipping with a known assert and following up with a 0.13.2 very quickly
10:00 < gmaxwell> I think that if it's going to ship with an exposed assert we're not likely to fix anyting else except something truely network breaking, and we should ship now.
10:00 < gmaxwell> ten we should do an RC for 0.13.2 pretty much immediately.
10:01 < BlueMatt> that i agree with
10:02 < BlueMatt> though at this point we've fixed enough random stuff in 0.13.1 that we probably also want a 0.13.0.1 for those who wish to not switch to segwit
10:02 < gmaxwell> I think sticking to a rigid schedule is harmful to users. I also don't see why we couldn't merge the assert fix now, and have a developer only RC (tag but no binaries) and final a day later.
10:02 < gmaxwell> BlueMatt: sure, but that can be done after the 0.13.1 release.
10:02 < BlueMatt> gmaxwell: indeed, and should be
10:03 -!- neha [~narula@18.26.5.3] has quit [Ping timeout: 245 seconds]     
10:04 < BlueMatt> I'm not a fan of making a code change and tagging final a day later
10:06 < gmaxwell> that seems like formulaic thinking, -- it's the removal of an assert which was just recently added, that does a >0 test on a variable where the only other use is a <= test... 
10:07 < gmaxwell> watcha worrying about? that someone could run with an unusual configuration and find their node crashes on a later connect? :)
10:11 < BlueMatt> i mean i assume the assert was added by someone who used the assumption in their thinking about the code logic, as well as reviewers of the original pr
10:12 < gmaxwell> if so thats only an argument to not release.
10:13 < BlueMatt> well the reviewers/original author wrote code under those assumptions, and while they can be violated, they are rarely violated, which was the argument for not backporting
10:13 < gmaxwell> there is no local effect of removing it, but if you were reasoning about far away code by "this case can't happen because there is an assert over there" -- well you were wrong.
10:14 < gmaxwell> BlueMatt: to e clear anytime you run with maxconnections below ten that assert is violated the whole time... it only gets around to actually shutting down when an inbound comes in, but the condition was still violated.
10:14 < BlueMatt> I'm aware
10:17 < MarcoFalke> If anything, the assert should be checking >= 0
10:17 < MarcoFalke> and not >0
10:17 < gmaxwell> it's still pointlss in any case.
10:17 < MarcoFalke> I somehow feel uncomfortable shipping code which crashes after some time, unexpectedly.
10:17 < gmaxwell> consider, it depends on no dynamic state. It could be in init.cpp.
10:17 < BlueMatt> i dont think we disagree on whether the fix (removing it) is probably correct
10:18 < MarcoFalke> Hmm, generally I like asserts to verify assumptions about the code.
10:18 < gmaxwell> MarcoFalke: yes, thats my concern. If it did immediately on start, I'd say fine! release note it and be done.
10:19 < BlueMatt> hum, thats true
10:19 < sipa> BlueMatt: i think there may be a larger change optimally, but not for 0.13.x
10:20 < MarcoFalke> I think we are missing documentation on how feelers should behave when maxconnections is given
10:20 < MarcoFalke> The current behavior makes sense
10:20 < MarcoFalke> Even though it was never meant to work this way
10:21 < wumpus> gmaxwell: so your proposal would be to do an rc3 with only the assert removed, release no binaries, and don't move final for it?
10:21 < gmaxwell> BlueMatt: how come you weren't swayed when I said that above, "So you'll start the node, think it's all happy, then then boom, it crashes." ? :)
10:21 < gmaxwell> wumpus: yes, that is my proposal.
10:22 < wumpus> so should we then do.. a vote or something? :/
10:22 < MarcoFalke> Was there a date when to tag final?
10:22 < BlueMatt> gmaxwell: no, the fact that this would be better if it crashed right away
10:22 < wumpus> yes, tomorrow
10:23 < BlueMatt> alternatively, just throwing this out there, we could make it crash on startup by adding code there instead :p
10:23 < MarcoFalke> Ok, so today rc3 with no gitian builds and tomorrow final?
10:23 < wumpus> I guess, I'm fine with doing that if there is common agreement to do that
10:23 < sipa> sounds good to me
10:24 < BlueMatt> I'm really not a fan...
10:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:25 < GitHub191> [bitcoin] laanwj closed pull request #9011: 0.13.1 backports conditional on rc3 (0.13...2016_10_backports_conditional_rc3) https://github.com/bitcoin/bitcoin/pull/9011
10:25 < sipa> the only difference from removing an assert is that some behaviour caused a crash before, now crashes in a different way
10:25 < BlueMatt> I mean realistically when are we gonna have binaries out for 0.13.1? not till monday probably anyway
10:25 < MarcoFalke> It does not crash in a different way, now.
10:25 < wumpus> I think multiple people verified that the code doesn't crash if that value becomes 0 or negative
10:26 < MarcoFalke> The value is only used in the local scope of the function once
10:26 < wumpus> right
10:26 < gmaxwell> I've been running a public node negative number there for ~two days now.
10:26 < gmaxwell> (running with maxconnections 8)
10:27 < BlueMatt> well if we're not gonna get binaries out for 0.13.1 till sunday/weekend anyway, why not push tag by a day?
10:28 < wumpus> who knows? gitian building goes really fast these days
10:28 < BlueMatt> we can tag thurs instead of tomorrow with a no-binary rc (but announcements for it) and then tag on thurs and give fri/sat to do gitian builds
10:28 < wumpus> if we're going to do rc3 with just the assert removed I'm going to tag *now*
10:28 < gmaxwell> what does that change?
10:28 < gmaxwell> that was a reply to BlueMatt 
10:28 < wumpus> we know exactly what we want to do so no need to delay one second
10:29 < BlueMatt> gmaxwell: a) doing an announce so that we feel marginally more comfortable doing a fast turnaround without getting more testing, and b) give a day to actually do that testing
10:30 < gmaxwell> BlueMatt: if, in the astronomically unlikely event that removing the assert introduces a serious bug, in the next couple days before the announce and binaries are out, then we pull it. 
10:30 < GitHub136> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/58d4fa7da30cb57e5fc3dca62f49a64e126c76cd
10:30 < GitHub136> bitcoin/0.13 58d4fa7 MarcoFalke: [net] Remove assert(nMaxInbound > 0)...
10:30 < MarcoFalke> BlueMatt: In which case it does still make sense to tag rc3 sooner than later
10:30 < BlueMatt> MarcoFalke: yes
10:31 < BlueMatt> gmaxwell: yes, I'm suggesting a) we get testing on that by doing an announce for rc3, and b) we push release bins to sunday so that we have time before needing to pull it
10:31 < BlueMatt> gmaxwell: and we still get binaries out before monday morning
10:32 < wumpus> I'm not normally a fan of this either, but this is so trivial
10:32 < BlueMatt> wumpus: agreed, hence why I'm suggesting we be willing to amend the process, but going all the way to tagging quicker in the hope that we give people one more weekday of release seems overkill to me
10:32 < wumpus> I mean the only reason that this is any issue at all is that we force building with asserts, if not, people building with NDEBUG wouldn't even notice
10:33 < wumpus>  * [new tag]         v0.13.1rc3 -> v0.13.1rc3
10:35 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
10:35 < BlueMatt> wumpus: wait, why did we not include the cs_main missing lock fix in rc3?
10:36 < wumpus> because that is more impact / risk than just removing an assert
10:37 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
10:37 < wumpus> a locking change would need more testing
10:37 < morcos> wumpus: ok i don't have a strong opinion, but i think that if we were going to bother doing another rc, then it might have been worth including that so we didn't need to issue another bug fix release for 0.13.1 later
10:38 < achow101> what about the other stuff listed in 9011?
10:38 < gmaxwell> I'm of a similar view with wumpus.
10:38 < wumpus> morcos: we'll have to, anyway I' m sure there will be plenty of bugs
10:38 < wumpus> the idea would be to do a rc3 with only the assert removed, which is atrivial change, o we don't have to delay the release by another week for testing
10:39 < wumpus> the other option would be doing a rc3, including more, but delaying -final until next week
10:39 < morcos> wumpus: ok.. sufficiently convinced
10:39 < achow101> wouldn't doing rc3 knock the release back to nov 1? Or am I missing something?
10:39 < BlueMatt> achow101: it did not
10:39 < morcos> its rc2.01
10:39 < wumpus> achow101: it would have, if we included actual serious changes
10:39 < wumpus> removing this assert is so trivial
10:40 < BlueMatt> however, I'd still like to push tagging to thursday and release on sunday instead of tagging tomorrow and release either friday or saturday (or sunday)
10:40 < gmaxwell> morcos: at least in my thinking, I'd consider the issue seperately.
10:40 < wumpus> and no, I don't feel like discussing that further or backstepping now, that was just a project decision
10:40 < gmaxwell> I wouldn't be included to do a short cycle RC for the lock, like I am for the trivial assert.
10:40 < achow101> so when is final planned for?
10:40 < wumpus> tomorrow
10:40 < wumpus> eh, no, thursday
10:41 < BlueMatt> oh, it was already thursday
10:41 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
10:41 < wumpus> yes it was already thursday
10:41 < BlueMatt> wumpus: can we do an announce for the rc3 to the ml?
10:41 < BlueMatt> even without bins?
10:41 < wumpus> the point was not to change that
10:41 < achow101> do we still need to gitian build it?
10:41 < wumpus> BlueMatt: sure ,feel free to do so, I"m going to bed
10:41 < BlueMatt> indeed, I'm aware
10:42 < BlueMatt> achow101: we are not doing gitian builds of rc3
10:42 < wumpus> achow101: nope
10:42 < achow101> ok     
10:42 < sipa> wumpus: good night!
10:42 < wumpus> you can gitian-build it for yourself ofcourse, or if you want to compare against someone else
10:45 < cfields_> I'll build either way so we can have something to point to if anyone wants it
10:46 < gmaxwell> assuming final is the same would the gitian binaries actually be the same?
10:46 < wumpus> unfortunately, no, because the build embeds the tag from git :(
10:47 < wumpus> if not for that the binary for -final would be exactly the same as -rc<last>
10:48 < wumpus> assuming no commits in between either
10:48 < BlueMatt> cfields_: whats the status of the osx change? are we gonna change the plist for final?
10:48 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
10:49 < wumpus> as the commit id# is also in the executable
10:49 < cfields_> BlueMatt: i think we should, yes. There should be ~zero practical impact.
10:49 < gmaxwell> wumpus: perhaps we should have the build system mask that out in the future. (e.g. strip rcN from the tag it extracts)
10:49 < BlueMatt> cfields_: yes, fine with that being merged w/o rc, just asking if its gonna happen
10:50 < wumpus> gmaxwell: strictly it doesn't need to extract a tag at all, the version should be in configure.ac/clientversion.h. But some poeple (I think mostly gavin) regarded it as a feature that a build could tell it is -rc sometnhing
10:50 < wumpus> gmaxwell: that's why that was never removed
10:50 < cfields_> wumpus: you ok with https://github.com/bitcoin/bitcoin/issues/8577#issuecomment-255947269 with no additional testing?
10:50 < cfields_> sorry that took so long, I chased it all day yesterday
10:51 < gmaxwell> an alternative to achieve I think the same end would be for the places we display that tag to also display a hash of the actual binary that you're running.
10:52 < wumpus> cfields_: does that affect anything?
10:53 < cfields_> wumpus: practically, no. Bitcoin-qt is busted on 10.7. This would just make it refuse to run there, rather than mysteriously crashing.
10:54 < wumpus> gmaxwell: indeed, for gitian builds the hash of the executable would be deterministic and possible to look up to a version / commit hash
10:54 < MarcoFalke> "The OS will then present the user with an error message if they try to run the application on an older version of the system."
10:54 < wumpus> cfields_: sounds good to me
10:55 < cfields_> wumpus: ok, doing now. I have a 10.7 vm, so i can verify that it works as intended on 10.7 and >10.7.
10:55 < wumpus> cfields_: I was wondering if it also changed e.g. APIs that are exposed to the executable, but if it's just a silly check that doesn't affect anything else then there is no risk changing it
10:55 < gmaxwell> wumpus: alernatively, it could embed some hash of the source code that wouldn't be changed by updating tags.
10:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:56 < cfields_> wumpus: that would require bumping the minversion to 10.8. Which we should do for master, but yes, not here.
10:56 < cfields_> -mmacosx-version-min, that is
10:59 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
10:59 < wumpus> BlueMatt: you sent the rc announcement to bitcoin-dev instead of bitcoin-core-dev :)
11:00 < BlueMatt> they're different? oops
11:00 < wumpus> BlueMatt: otherwise, thanks!
11:00 < BlueMatt> ehh, see, this is why i dont do release process :p
11:00 < btcdrak> please send to bitcoin-core-dev also
11:00 < wumpus> no problem, just send a copy to bitcoin-core-dev too
11:01 < BlueMatt> ok, done
11:06 < jonasschnelli> <*highlight>	[13:50:51] <wumpus:#bitcoin-core-dev> jonasschnelli: re: https://github.com/bitcoin/bitcoin/pull/9010, any idea why not all parameter interaction was moved to InitParameterInteraction?
11:06 < jonasschnelli> IIRC, I did only move the SoftSetBoolArg() in https://github.com/bitcoin/bitcoin/pull/6780
11:06 < jonasschnelli> But I can't remember the exact reason why not every interaction was moved.
11:07 < instagibbs> is there any reason why the wallet's CommitTransaction reject message is so bland? Should be trivial to pass the failure state up from AcceptToMemoryPool
11:08 < wumpus> instagibbs: patches welcome
11:09 < instagibbs> roger
11:09 < cfields_> instagibbs: i have a PR that changes that behavior and creates better error messages. sec.
11:09 < instagibbs> I've literally implemented it before, for elements, but then forgot about it
11:09 < wumpus> I'm sure that the reason is that no one ever bothered to make that message better, and also the detailed state return message is something relatively new. I think we have an ancient issue from ~2010 open about some weird message in the wallet that never was fixed :-)
11:09 < instagibbs> and now running into it again working on Core, d'oh
11:10 < instagibbs> cfields_, I'd appreciate a patch if you have it. IIRC it's only a few lines so I can do it too
11:10 < wumpus> we have tons of pulls open about log messages and comments, but surprisingly few people work on user-facing messages
11:10 < cfields_> grr, I need to clean that up and resubmit. Trying to fix up my PRs today.
11:11 < instagibbs> wumpus, well right now any error in wallet's transaction gives you a super broad message about money missing
11:11 < cfields_> instagibbs: see the comments in https://github.com/bitcoin/bitcoin/pull/8888
11:11 < cfields_> instagibbs: specifically: https://github.com/theuni/bitcoin/commit/349edab789557db615b29a5869118b4b08c50dab
11:12 < cfields_> instagibbs: with the caller responsible for ATMP and broadcasting, the errors can be much more specific. IIRC I basically just copied them as-is there though.
11:14 < instagibbs> Yeah that looks better, but it could still stand to pass back why it failed mempool entry
11:16 < cfields_> instagibbs: for sure.
11:21 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
11:22 < wumpus> the ancient wallet message I was talking about still exists, but apparently I closed the issue: https://github.com/bitcoin/bitcoin/issues/211 "Error: This transaction requires a transaction fee of at least %s because of its amount, complexity, or use of recently received funds!"
11:25 < cfields_> heh     
11:25 < wumpus> thinking of it, neither amount, complexity or use of recently received funds counts towards the fee
11:25 < jl2012> has anyone proposed to have an RPC command like "checkrawtransaction", which does everything of "sendrawtransaction" but not adding it to mempool?
11:25 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
11:25 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host]     
11:25 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
11:25 < gmaxwell> "because of the required resources"
11:25 < wumpus> jl2012: yes, I had a pull for that once
11:25 < cfields_> jl2012: decoderawtransaction ?
11:26 < jl2012> decode won't test for validity
11:26 < jl2012> wumpus: why isn't it merged?
11:27 < gmaxwell> jl2012: the way I've recommended doing that before is with a block proposal.
11:27 < wumpus> lack of testing
11:27 < gmaxwell> jl2012: which lets you also have a chain of unconfirmed transactions.
11:27 < wumpus> mine could do that too
11:27 < gmaxwell> wumpus: that sounds good.
11:27 < wumpus> jl2012: https://github.com/bitcoin/bitcoin/pull/7552
11:28 < wumpus> too much arguing and too little actual interest so I eventually gave up, but feel free to resurrect it (in some form)
11:31 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
11:32 < jl2012> i'm thinking of a CSV timelocked vault. You send money to a 2-of-2 which you have both key. Then you create a tx, sending this 2-of-2 to this : IF 1-of-2 , locktime CSV ELSE 2-of-2 ENDIF. Then you store the 2 keys separately, with this unconfirmed tx. If one of the keys was stolen, you could still recover the fund before the thief got it. If you lost one
11:32 < jl2012> access to one key, you could still get the money back with another key after the locktime
11:32 < jl2012> But I need the ability to verify the unconfirmed tx is actually valid
11:33 < GitHub115> [bitcoin] theuni opened pull request #9015: release: bump required osx version to 10.8. Credit jonasschnelli. (master...osx-disable107) https://github.com/bitcoin/bitcoin/pull/9015
11:33 < GitHub139> [bitcoin] instagibbs opened pull request #9016: Return useful error message on ATMP failure (master...atmperror) https://github.com/bitcoin/bitcoin/pull/9016
11:33 < gmaxwell> you can make the spend smaller if the 1 of 2  is just a 1 of 1 with one of the two keys.
11:34 < jl2012> yes, the 1/2 for the number of sigs could be pushed with IF/ELSE
11:35 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]     
11:37 < instagibbs> wumpus, too bad, I think rpc's checking for validity without committing them are useful
11:38 < gmaxwell> instagibbs: go pick up his PR.
11:38 < gmaxwell> no one was opposed to the idea.
11:39 < instagibbs> I remember it being contentious regarding the devilish details, but I'll take another look
11:39 < wumpus> indeed, it was just that the way some people wanted to do it involved changing code and refactoring all over the place
11:41 < wumpus> and as this localized change was already hard enough to get review and testing for, I feared for anything that would touch main more. BUt maybe changes since have made it easier, I don't know.
11:42 < wumpus> I tend to lose interest in projects after a while, that doesn't mean they're not worth doing
11:43 < achow101> i'm thinking of doing a verifyrawtx with it doing exactly the same thing as sendrawtx except the actual send and placing in mempool parts
11:44 < wumpus> that's easier said than done, especially if you want to be able to handle chains of transactions depending on each other
11:44 < wumpus> without actually putting the dependencies in the mempool
11:45 < instagibbs> achow101, read the PR thread, it's all debated there I think
11:45 < wumpus> yes     
11:45 < instagibbs> subtle issues mean it's harder to push through
11:46 < gmaxwell> well the PR might not make it clear that being able to handle chains is pretty useful.
11:46 < wumpus> it's all been debated before, I don't feel like getting involved again, thanksfor the reminder
11:47 < achow101> well my idea is to just modify accepttomempool 
11:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
11:48 < wumpus> but would you want changes there for an RPC call whose goal is to *not* touch the mempool?
11:48 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
11:48 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
11:49 < wumpus> accepttomempool(bla,bla,dontAcceptToMempoolFlag) would be wrong. So you'd end up splitting up functions and refactoring. Maybe that needs to happen anyway, I don't know.
11:49 < sipa> at risk of bringing up older discussions again: just checking for consensus is easy if we don't want to touch the mempool for chains of transactions, but testing all policy is much harder (especially if it includes replacement, rbf, eviction, timelocking, fee rates, ...)
11:50 < sipa> but if it includes policy it's also much less meaningful to affect the mempool
11:50 < achow101> why would adding a flag to acceptomempool be wrong?
11:50 < wumpus> because the function is called accepttomempool
11:50 < sipa> let's rename it to AcceptableToMempool
11:50 < sipa> *ducks*
11:51 < wumpus> yes, if you split up functions into a 'acceptable policy' part and 'add to mempool', it makes more sense
11:51 < wumpus> I'm repeating myself
11:51 < wumpus> agree that checking for consensus is fairly easy
11:52 < wumpus> the difficult part was all the different policies
11:52 < wumpus> if that's not necessary then indeed it'd just be a 'block proposal'
11:52 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
11:52 < wumpus> although you probably still want to be able to pass in things such as height, and time, for -final checks
11:53 < wumpus> 'is this valid at height X time Y' instead of necessarily now
12:02 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev     
12:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:12 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
12:19 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 252 seconds]     
12:21 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev     
12:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]     
12:45 < GitHub111> [bitcoin] instagibbs opened pull request #9017: Enable various p2sh-p2wpkh functionality (master...p2shp2wpkhstuff) https://github.com/bitcoin/bitcoin/pull/9017
12:46 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
12:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:54 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 252 seconds]     
12:54 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev     
13:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
13:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
13:16 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
13:18 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Client Quit]     
13:19 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
13:20 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
13:21 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
13:22 < Victorsueca> wuuuuuut?
13:22 < Victorsueca> rc3?
13:22 < Victorsueca> I thought rc2 was the choosen one
13:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
13:24 < BlueMatt> Victorsueca: see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013262.html
13:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
13:26 < Victorsueca> BlueMatt: thanks
13:26 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
13:29 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
13:41 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
13:47 -!- ill [~ill@32.210.34.9] has joined #bitcoin-core-dev     
14:02 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
14:05 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
14:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]     
14:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
14:39 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
14:49 < GitHub85> [bitcoin] ryanofsky opened pull request #9018: testing pr (please ignore) (master...loop) https://github.com/bitcoin/bitcoin/pull/9018
15:33 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Read error: Connection reset by peer]     
15:37 < gmaxwell> 40 node_witness peers
15:38 < gmaxwell> 5 outbound.
15:50 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
15:53 < luke-jr> looks like he's abusing that PR to run Travis :/
15:53 < luke-jr> guess he doesn't realise it emails everyone
15:54 < gmaxwell> 40 node_witness peers If you're a miner or mining pool operator, please see the versionbits FAQ for information about signaling support for a soft fork.  ...
15:55 < gmaxwell> ignore te first part of that line..
15:55 < gmaxwell> so thats (If you're..) is all we say about mining & segwit in the release notes right now.
15:55 < gmaxwell> which is a little anemic. Like, there should be some mention that all mining software needs to be updated for segwit support.
15:56 < gmaxwell> And a list of supporting mining software.
15:56 < luke-jr> gmaxwell: that's slated for the blog post, I think. although I do get a sense that the blog post really should just be the same as release notes..
15:56 < gmaxwell> hm.     
15:57 < luke-jr> or perhaps turning the blog post into a segwit deployment FAQ and linking that
15:57 < luke-jr> (so we can update it as needed later)
15:59 < GitHub177> [bitcoin] sipa closed pull request #9018: testing pr (please ignore) (master...loop) https://github.com/bitcoin/bitcoin/pull/9018
16:12 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
16:42 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 256 seconds]     
17:47 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
17:50 -!- roconnor [~roconnor@host-45-78-195-208.dyn.295.ca] has quit [Ping timeout: 265 seconds]     
18:16 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ymyqlgugyrbfgtmb] has quit [Ping timeout: 250 seconds]     
18:16 -!- Ylbam_ [uid99779@gateway/web/irccloud.com/x-usupwntpxplxiews] has joined #bitcoin-core-dev     
18:17 -!- pindarhk [sid105966@gateway/web/irccloud.com/x-ccpwuiskxkhstoyp] has quit [Ping timeout: 250 seconds]     
18:17 -!- Ylbam_ [uid99779@gateway/web/irccloud.com/x-usupwntpxplxiews] has quit [Client Quit]     
18:19 -!- pindarhk [sid105966@gateway/web/irccloud.com/x-rmeqmricmdqylwuv] has joined #bitcoin-core-dev     
18:19 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
18:21 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
18:22 -!- roconnor [~roconnor@host-45-78-195-208.dyn.295.ca] has joined #bitcoin-core-dev     
18:23 -!- Taek [~quassel@2001:41d0:1:472e::] has quit [Ping timeout: 250 seconds]     
18:25 -!- Taek [~quassel@2001:41d0:1:472e::] has joined #bitcoin-core-dev     
18:26 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
18:28 -!- nsh [~lol@wikipedia/nsh] has quit [Ping timeout: 250 seconds]     
18:42 -!- nsh [~lol@wikipedia/nsh] has joined #bitcoin-core-dev     
18:42 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]     
18:55 -!- roconnor [~roconnor@host-45-78-195-208.dyn.295.ca] has quit [Ping timeout: 260 seconds]     
19:03 -!- aj_ is now known as aj     
19:23 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
19:23 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev     
19:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
19:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:29 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 260 seconds]     
19:50 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
19:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
20:20 < luke-jr> jonasschnelli: are you sure we can get a corrupt db from kill? that would be a pretty serious bug..
20:21 < luke-jr> I mean, a non-trivial part of the *purpose* of a db engine is to prevent corruption
20:21 < luke-jr> I know we have had some issues with literal power failures, but it seems absurd for kill to corrupt things
20:24 < gmaxwell> we shouldn't be, it would be a serious bug.  During IBD unclean poweroffs will pretty reliable corrupt things because we skip syncing, but otherwise it shouldn't.
20:24 < BlueMatt> sipa: i think i got all your nits on #9014, though some of your comments (from 15 minutes ago) were on outdated code (how did you do that? I pushed many hours ago)
20:27 < sipa> BlueMatt: i was reviewing commit by commit
20:27 < BlueMatt> oh, you missed some SQUASHME commits :/
20:28 < sipa> no, i just wasn't looking at them at the time
20:28 < BlueMatt> sipa: when you get to a stopping point, i can just squash and force-push...jeremy was happy with where it was and i assume only you and jeremy have looked at it
20:28 < sipa> BlueMatt: i'm fine with you squashing now
20:28 < BlueMatt> ok     
20:29 < luke-jr> gmaxwell: context https://github.com/bitcoin/bitcoin/issues/9001 fwiw
20:29 < luke-jr> inclined to ask him if he can provide remote access for debugging, but not sure there's a need if jonasschnelli has a way to reproduce something similar already
20:30 < jeremyrubin> I'm happy! A+ BlueMatt!
20:32 < BlueMatt> ok, force-pushed
20:33 < BlueMatt> sipa: see https://github.com/bitcoin/bitcoin/pull/9014#discussion_r85034371
20:33 < BlueMatt> anyway, bedtime for me
20:35 -!- roconnor [~roconnor@host-45-78-195-208.dyn.295.ca] has joined #bitcoin-core-dev     
20:37 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Ping timeout: 260 seconds]     
20:45 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev     
21:08 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:10 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds]     
21:17 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Quit: DigiByteDev]     
22:26 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
22:29 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]     
22:33 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
23:03 -!- Dizzle [~Dizzle@2605:6000:1019:4099:5d9f:dd74:18a9:41d8] has joined #bitcoin-core-dev     
23:03 -!- vakano [b58fdfc2@gateway/web/freenode/ip.181.143.223.194] has joined #bitcoin-core-dev     
23:14 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
23:19 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
23:21 -!- baldur [~baldur@pool-72-69-25-42.nycmny.fios.verizon.net] has quit [Ping timeout: 252 seconds]     
23:26 -!- vakano [b58fdfc2@gateway/web/freenode/ip.181.143.223.194] has quit [Quit: i get the irc client now]     
23:31 -!- VaKaNO [~VaKaNO@181.143.223.194] has joined #bitcoin-core-dev     
23:33 -!- VaKaNO [~VaKaNO@181.143.223.194] has quit [Read error: Connection reset by peer]     
23:33 -!- Ylbam_ [uid99779@gateway/web/irccloud.com/x-dpqlohylptisptyo] has joined #bitcoin-core-dev     
23:34 -!- VaKaNO [~VaKaNO@181.143.223.194] has joined #bitcoin-core-dev     
23:40 -!- VaKaNO [~VaKaNO@181.143.223.194] has quit [Read error: Connection reset by peer]     
23:41 < gmaxwell> interesting, slushpool just failed to take a pretty attractive CFPF transaction set that my node would have mined.
23:41 -!- VaKaNO [~VaKaNO@181.143.223.194] has joined #bitcoin-core-dev     
23:45 -!- Ylbam_ [uid99779@gateway/web/irccloud.com/x-dpqlohylptisptyo] has quit [Ping timeout: 260 seconds]     
23:48 -!- Ylbam_ [uid99779@gateway/web/irccloud.com/x-vhkxnygizvcjjeir] has joined #bitcoin-core-dev     
23:51 -!- VaKaNO [~VaKaNO@181.143.223.194] has quit [Read error: Connection reset by peer]     
23:52 -!- VaKaNO [~VaKaNO@181.143.223.194] has joined #bitcoin-core-dev     
23:54 -!- VaKaNO is now known as VaKaN0     
23:55 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
23:56 -!- VaKaN0 [~VaKaNO@181.143.223.194] has quit [Read error: Connection reset by peer]     
23:57 -!- VaKaN0 [~VaKaNO@181.143.223.194] has joined #bitcoin-core-dev     
23:58 -!- VaKaN0 [~VaKaNO@181.143.223.194] has quit [Read error: Connection reset by peer]     
23:59 -!- VaKaN0 [~VaKaNO@181.143.223.194] has joined #bitcoin-core-dev