--- Day changed Thu Jun 02 2016
00:03 < gmaxwell> I think it's fine to implement before auth is done, so long as whomever is implementing doesn't mind taking some small risk of disruption if changes to the auth design change the encryption.
00:05 < midnightmagic> gmaxwell: any thought to using proof-of-storage as ephemeral key ratchets? :-)
00:05 < midnightmagic> er. that was meant generally, not just to gmax. :)
00:06 < midnightmagic> and, would a group sig in log or constant space be possible for client group-membership proof non-interactively?
00:06 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
00:09 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
00:10 < gmaxwell> I don't think group sigs fit well in this context, unfortunately.  The server can tell if you are peer X by basically giving you a dummy keyring where all the keys are junk except yours. 
00:11 < gmaxwell> you can't tell that it did this to you if it was successful in deanoning you
00:11 < gmaxwell> (the log size group sigs also take linear time to sign/verify... we're not actually super bandwidth constrained in this application-- so I think a log sized one doesn't buy us much)
00:12 < gmaxwell> The constant sized ones use pairing crypto, so then there is a bunch of extra crypto to bring in.
00:12 < midnightmagic> thank you
00:14 < gmaxwell> the chaumtoken auth was the best private auth I could come up with so far.
00:19 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pjolyyjrydqzyuok] has joined #bitcoin-core-dev
00:30 < jouke> I'm running a node on ipv4 and onion. I have a lot of peers that have the same "addr" IP, and my addresslocal says: "127.0.0.1". Are those connected trough TOR but are advertising that IP? The subver of those peers are different as well.
00:30 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 260 seconds]
00:35 < gmaxwell> if someone connects into you via onion, their addr will be 127.0.0.1:<something>  and the addrlocal should be your onion address.
00:35 < gmaxwell> though they can send whatever they want in addrlocal.
00:38 < jouke> Does the addrlocal in the gepeerinfo field specify on which IP address that node is connected to
00:38 < gmaxwell> No it is whatever address the remote party claims they think is your address.
00:38 < jouke> Oh right
00:38 < jouke> Thanks.
00:39 < jouke> And the addr field is the address where my nodes comunicates to?
00:40 < gmaxwell> yes, which is 127.0.0.1 for inbound onion peers.
00:41 < jouke> I have 57 peers with the same addr IP :-/
00:42 < gmaxwell> presumably 52.51.something.
00:42 < jouke> No
00:42 < jouke> Those I have as well
00:42 < jouke> On other nodes
00:42 < jouke> It is is actualy a /32 IP
00:43 < midnightmagic> that sounds super annoying.
00:43 < gmaxwell> What do you mean by a "/32 IP"  ... all IPs are /32... because they're hosts not networks. :P
00:43 < jouke> The bytessent/bytesrecv ratio isn't as skewed as with those 52.51
00:43 < jouke> gmaxwell: just one and the same IP, not multiple IP's from the same subnet.
00:44 < gmaxwell> I strongly recommend reporting abusive hosts to their providers, fwiw.
00:44 < jouke> Hetzner...
00:44 < midnightmagic> maybe it's a tor exit node or something
00:45 < gmaxwell> midnightmagic: well thats easily checked. :) (indeed, don't report tor exits)
00:46 < jouke> It's not in here: https://check.torproject.org/exit-addresses
00:46 < midnightmagic> Ah. Hetzner. Why am I not surprised. :-/
00:49 < jouke> I was thinking of having a script that would look at the upload/download ratio and ban nodes with a bad ratio. But wouldn't have worked in this case.
00:50 < gmaxwell> you can do varrious adhoc things personally, but most don't work broader than that.. too easily avoided. the 52.x sybils could start sending junk traffic... and just waste more of your bandwidth.
00:51 < gmaxwell> They case no harm except privacy loss, and the solution to that is to fix things so they can't hurt privacy.
00:52 < gmaxwell> though if they're irritating you, http://0bin.net/paste/EH8fTyfotJSU3Udw#TCHJfA7qDt5odgG+gW4dG9aUEYkJQo6oOTmsuXBAJke  works.
00:53 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 258 seconds]
00:55 < gmaxwell> ah seems that misses 52.51.180.197 and 52.51.204.60
00:56 < GitHub50> [bitcoin] jonasschnelli opened pull request #8135: [OSX] fix make deploy when compiling on OSX (master...2016/06/makedeploy) https://github.com/bitcoin/bitcoin/pull/8135
01:05 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
01:06 < jouke> gmaxwell: heh, thanks :)
01:10 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
01:29 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:31 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
01:32 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
01:35 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
01:38 -!- jyap [~jyap@unaffiliated/jyap] has quit [Ping timeout: 260 seconds]
01:39 -!- jyap [~jyap@2604:180:1:7f5::b59a] has joined #bitcoin-core-dev
01:39 -!- jyap [~jyap@2604:180:1:7f5::b59a] has quit [Changing host]
01:39 -!- jyap [~jyap@unaffiliated/jyap] has joined #bitcoin-core-dev
01:45 < GitHub104> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/715e9fd7454f...58725ba89dfc
01:45 < GitHub104> bitcoin/master 2692e1b fanquake: [Doc] Simplify OS X build notes...
01:45 < GitHub104> bitcoin/master 58725ba Jonas Schnelli: Merge #8029: [Doc] Simplify OS X build notes...
01:45 < GitHub56> [bitcoin] jonasschnelli closed pull request #8029: [Doc] Simplify OS X build notes (master...osx-build-notes) https://github.com/bitcoin/bitcoin/pull/8029
02:11 < GitHub85> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/58725ba89dfc...ee1533e262e7
02:11 < GitHub85> bitcoin/master 16698cb UdjinM6: PR #7772 is not enough to fix the issue with QCompleter, use event filter instead of `connect`
02:12 < GitHub85> bitcoin/master ee1533e Jonas Schnelli: Merge #8129: Fix RPC console auto completer...
02:12 < GitHub132> [bitcoin] jonasschnelli closed pull request #8129: Fix RPC console auto completer (master...fixRPCAutoCompleter_bitcoin) https://github.com/bitcoin/bitcoin/pull/8129
02:13 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
02:19 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
02:19 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
02:19 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
02:19 < iniana> What can I do to debug the painfully slow sync of my core node on a linux machine? Currently at height 410k and it progresses around 1 block every 3 seconds on average.
02:27 < jonasschnelli> iniana: what processor? how many RAM? disk stype?
02:28 < jonasschnelli> 1 block every 3 seconds is very likely disk speed or CPU.
02:28 < jonasschnelli> If you have enough memory, you should try to pass -dbache=4000 (4GB)
02:28 < jonasschnelli> Even passing -dbcache=2000 can help
02:28 < jonasschnelli> (default is 300)
02:33 < iniana> jonasschnelli: blockchain is stored on hdd, dbcache was set to 2000. I have a feeling it is because it is run within a Qubes VM. Is there anyway to measure disk I/O?
02:34 < jonasschnelli> iniana: I guess you can use iostat on linux
02:34 < jonasschnelli> iniana: did you enable multicore on your VM? But yes,.. running in a VM can slow down the whole thing.
02:35 < jonasschnelli> Best fix: don't stress it and wait a couple of days. :)
02:36 < iniana> jonasschnelli: yes, set to 8 VCPUs, 8GB max memory, 4GB initial memory. Am at height 410k, so should only have to wait a couple of hours :)
02:36 < jonasschnelli> iniana: yes. What CPU?
02:37 < jonasschnelli> On my Xeon/SSD I could sync a node in a VirtualBox VM within 3-4h.
02:37 < iniana> core i7, 2yo, not sure on exact specs
02:38 < jonasschnelli> iniana: try run Core with --debug=bench
02:38 < jonasschnelli> You will see if its the disk latency or the ecdsa
02:39 < iniana> I managed to sync a pruned node on a whonix VM (tor-only) a lot faster than what I am experiencing now. Only difference is that was on SSD. But I have used the same HDD before and it was a lot faster then. Some combo of VM and HDD doesn't mix I guess.
02:39 < iniana> Ah great! Will try that debug flag
02:42 < phantomcircuit> iniana, does qubes pass the cpu flags?
02:42 < phantomcircuit> also what version are you running?
02:43 < iniana> phantomcircuit: What are the cpu flags? Am running Qubes 3.1, Core 0.12.1
02:47 < iniana> The following line seems to be the one that takes longest to generate: - Connect 647 transactions: 597.49ms (0.923ms/tx, 0.509ms/txin) [102.29s]
02:48 < iniana> also - Verify 4484 txins: 2407.61ms (0.537ms/txin) [104.76s]
02:48 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
03:01 < wumpus> looks like most time is spent on verification
03:01 < wumpus> how many cores are allocated to that VM?
03:02 < wumpus> bitcoin core makes heavy use of paralellism for verification
03:04 < wumpus> ok 8 VCPUs should be fine
03:05 < sipa> u
03:07 < iniana> Hmm.. There was a sequence of a couple of hundred blocks which were processed very quickly (10/s maybe) after which it resumed with 1 block per 3s again.
03:13 < sipa> are you reindexing or downloading?
03:13 < iniana> downloading
03:14 < sipa> that will explain the speed differences
03:14 < sipa> we download multiple blocks at once
03:14 < sipa> but they don't arrivs in the right order
03:17 < iniana> Are transactions that can't be verified yet during sync added to the mempool or someplace else?
03:17 < sipa> so validation only progresses when the first missing one arrices
03:17 < sipa> you mean transactions in blocks we download? no
03:18 < sipa> the mempool only contains validated transactions
03:18 < iniana> ah ok
03:18 -!- tErik_mc [~tErik@unaffiliated/terik] has joined #bitcoin-core-dev
03:18 < sipa> say you're synced up to block 10000
03:19 < sipa> and you downloading the 100 blocks that follow
03:19 < sipa> and 10001 though 10099 have arrived
03:19 < sipa> but 10000 has not
03:19 < sipa> then 10000 arrvives
03:20 < sipa> and suddenly you can validate 100 blocks at once
03:25 < iniana> Still weird that it is progressing this slowly though. I mean, it was the same speed when reindexing a previously synced data directory I had copied over. It had all the data and did no downloading. How come there was that sequence of blocks that could be progressed so quickly? 
03:27 < iniana> When I restarted bitcoin core recently the verification of the previous 288 blocks was also that slow.
03:29 < sipa> during reindex you also saw some sequence of blocks that wete fast?
03:30 < sipa> not all blocks have the same number of transactions
03:30 < sipa> the initial 288 being slow is due to the cache mot being warmed up
03:31 < sipa> the database entries still have to be loaded from disk
03:31 < iniana> no, during reindex I never saw a fast sequence, though I could have missed it. 
03:32 < phantomcircuit> sipa, the p2p block fetching logic needs to be hardened against people being annoying
03:32 < phantomcircuit> there's some very very very slow nodes
03:32 < iniana> Sure, not all blocks are the same size, but from a couple of hundred blocks at height 411k, I bet most of them had a lot of transactions.
03:32 < phantomcircuit> but worse there's some that are ridiculously bursty
03:32 < phantomcircuit> they'll be fast for some blocks and then take 10 seconds to respond to another
03:55 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
03:56 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
03:56 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Client Quit]
03:57 -!- Thireus1 [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
04:02 < sipa> iniana: you have high dbcache set in both?
04:03 < iniana> sipa: yes, 2000
04:05 -!- calibre720 [~calibre72@182.57.113.28] has quit [Ping timeout: 244 seconds]
04:05 < sipa> whenever the dbcache fills up, it needs tp be written to disk, and afterwards processing is slower for a while
04:06 < sipa> you can see when this happens when the cache size in the UodateTip lines falls back to 0
04:06 < sipa> but that causes sudden slowness, not sudden fastness
04:08 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
04:10 < iniana> Cache currently at 1258MiB, and it is consistently slow. 
04:11 < sipa> are you running with debug=bench ?
04:11 < iniana> yes
04:14 -!- xiangfu [~xiangfu@58.135.95.136] has quit [Remote host closed the connection]
04:14 -!- calibre720 [~calibre72@182.57.71.21] has joined #bitcoin-core-dev
04:14 < iniana> sipa: Here is a snippet from my log http://pastebin.com/6jWv29uj
04:16 < sipa> all your time is lost on loading database entries
04:17 < sipa> either those are blocks that spend a lot of very old inouts that are not cached
04:17 < sipa> or your disk is very slow
04:17 < sipa> *old inputs
04:20 < iniana> iostat reports 7.8M read and 2.1M write for that particular block deivce. Doesn't feel like it is the bottleneck.
04:22 < sipa> they're all very small reads
04:23 < sipa> what kind of disk?
04:23 < iniana> sipa: ok. I guess this is the performance I have to live with until I upgrade to an SSD?
04:24 < sipa> i have a spinning disk, and numbers are far better than what you're seeing
04:24 < sipa> 18s to load all the inputs is crazy
04:24 < iniana> yes, I have used the same disk on a non-virtual machine with much better results. 
04:25 < sipa> ah, maybe it's due to the VM setup
04:25 < wumpus> yes VM can make some difference
04:25 < wumpus> there are some curious interactions between fdatasync and VMs for example
04:26 < wumpus> probably because the VM 'disk' is one file in the host OS
04:26 < sipa> wumpus: this is slowness in reads, not writes
04:26 < sipa> so sync is not the issue
04:26 < wumpus> reads shouldn't be affected by VM
04:26 < wumpus> not much, at least
04:27 < wumpus> unless it is some weird compressed image format
04:27 < iniana> I'm using Qubes (xen) if that helps
04:29 < wumpus> what can make a difference in i/o speed is to make sure that you're using a paravirtualized disk, and not e.g. emulating IDE
04:30 < phantomcircuit> iniana, 200+ms to load a block from disk is terrrible
04:32 < iniana> Could be the way I attach the block device to my VM (qvm-block), will explore this further.
04:34 < wumpus> yes qemu allows configuring a lot of things related to emulated devices
04:35 < wumpus> I'd say it is only worth it if you intend to do a lot of syncing, I mean once your node syncs the i/o and CPU usage drops by lots and this all matters very little
04:36 -!- airmace312 [~airmace31@103-224-130-8.flip.co.nz] has joined #bitcoin-core-dev
04:36  * airmace312 is selling coins if you are intrested in buying please private msg me and we can negotiate the rate so if intrested please msg me for a good deal thanks
04:36 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ
04:36 -!- mode/#bitcoin-core-dev [+b *!*@103-224-130-8.flip.co.nz] by wumpus
04:37 -!- airmace312 was kicked from #bitcoin-core-dev by wumpus [no selling/buying here]
04:37 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ
04:37 < iniana> wumpus: I guess, but it would be annoying if when I have to turn off the machine only to have to wait for hours until it is synced up again when I turn it on. Plus its fun getting to know how stuff works :)
04:38 < wumpus> sure, as a learning experience it makes sense
04:48 < sipa> iniana: at your sync speed, it takes around 1-2 hours to sync a week of blockchain data
04:48 < sipa> that's terrible
04:48 < sipa> some people sync the whole chain in 4 hours
04:48 < iniana> sipa: yes, its very frustrating
04:48 < sipa> but i don't have any advice but checking your vm disk setup
04:49 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
04:55 < phantomcircuit> iniana, it's xen based
04:57 < iniana> phantomcircuit: yes
04:57 < phantomcircuit> i would say
04:57 < phantomcircuit> "good luck" fixing that issue
04:57 < phantomcircuit> :/
04:57 < iniana> You say I shouldn't waste my time?
04:58 < phantomcircuit> i'd say go ask the qubes people
04:58 < GitHub8> [bitcoin] jonasschnelli opened pull request #8136: Log/report in 10% steps during VerifyDB (master...2016/06/init_checkblocks) https://github.com/bitcoin/bitcoin/pull/8136
05:00 < iniana> How would attaching the disk as a samba or nfs share instead of via xen work out? Has anyone tried loading blockchain data from a remote server that way?
05:02 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
05:03 < sipa> iniana: no, you need mmap support
05:03 < sipa> network filesystems don't offer that
05:04 < phantomcircuit> sipa, do we still require mmap?
05:04 < sipa> leveldb does
05:04 < phantomcircuit> hmm
05:04 < sipa> i think
05:05 < kinlo> isn't requiring mmap a good thing from a performance point of view?
05:05 < sipa> yes
05:05 < phantomcircuit> "meh"
05:05 < sipa> i think you can disable it
05:05 < sipa> i think we may not use mmap on 32-bit
05:07 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
05:07 < wumpus> loading the blockchain data from a network filesystem should work, just not having the database directories there (if it doesn't support mmap)
05:07 < wumpus> I've succesfully used a network block device to store both though
05:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:08 < wumpus> haven't tried samba nor nfs
05:09 < jonasschnelli> wumpus: is there a startup argument to set the blockfiles directory?
05:09 < wumpus> I've also shared synced node data between windows and linux locally, linux' ntfs implementation surprisingly does work good enough for leveldb
05:10 < jonasschnelli> Or do you need some ln -s?
05:10 < wumpus> no, but you can put stuff all over the place with symbolic linnks
05:10 < jonasschnelli> Right...
05:11 < wumpus> being able to specify different directories as arguments would be mildly useful, although for people that don't know what they're doing it's a foot shooting cannon
05:13 < wumpus> (e.g. we only aquire a lock on the data directory, not on the subdirectories individually, so if you can specify them elsewhere someone may do crazy things like point two bitcoinds at the same place)
05:21 -!- cryptapus_ [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:21 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds]
05:22 -!- cryptapus_ is now known as cryptapus
05:28 -!- MrHodl [~fuc@190.112.223.117] has joined #bitcoin-core-dev
05:32 < jonasschnelli> hmm.. travis is strange today:
05:32 < jonasschnelli> W: Failed to fetch https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages  Hash Sum mismatch
05:34 < wumpus> scary
05:36 < wumpus> happens every time?
05:43 < sipa> try pressing more buttond
05:46 < wumpus> these are not even our own downloads, but travis pre-installing packages that fails
05:46 < wumpus> so less scary, probably just something with the repository that is misconfigured
05:48 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
05:48 < wumpus> docketprojects's package repository that is, not our repository
05:49 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
05:57 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 250 seconds]
06:03 < GitHub10> [bitcoin] pstratem opened pull request #8137: Improve CWallet API with new AccountMove function. (master...2016-06-02-cwallet-accountmove) https://github.com/bitcoin/bitcoin/pull/8137
06:03 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
06:06 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
06:08 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
06:12 < wumpus> pushing more buttons doesn't seem to help
06:28 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
06:36 -!- cryptapus_ [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
06:38 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 264 seconds]
06:40 -!- cryptapus_ [~cyptapus@unaffiliated/cryptapus] has quit [Client Quit]
06:43 -!- cryptapus_ [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
06:46 -!- jannes [~jannes@178.132.211.90] has quit [Ping timeout: 240 seconds]
06:46 -!- jannes_ [~jannes@178.132.211.90] has joined #bitcoin-core-dev
06:49 -!- zooko [~user@172.56.6.81] has joined #bitcoin-core-dev
06:58 < MarcoFalke> sipa, but this would cause an include main.h in wallet.h?
06:59 < sipa> MarcoFalke: why in wallet.h?
06:59 < sipa> the constant would just disappear from the .h fr
06:59 < sipa> wallet.cpp would call main to query the current relay fee
07:00 < MarcoFalke> Oh, you mean current relay fee and not minimum relay fee.
07:01 < sipa> even the minimum relay fee is configurable, so indeed :)
07:01 < sipa> or even the minimum confirmable feerate
07:01 < sipa> as we should never create outputs that are uneconomical to spend
07:01 < sipa> and the fee estimate is the best guess for that
07:04 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
07:05 -!- robs [uid165609@gateway/web/irccloud.com/x-nrkkjrnzxbhalorv] has quit [Quit: Connection closed for inactivity]
07:05 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
07:06 -!- Thireus1 [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
07:10 < phantomcircuit> sipa, im seeing pull tester failures on master
07:10 < phantomcircuit> can you (or someone else) check?
07:10 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
07:10 < phantomcircuit> wumpus, ^
07:11 < wumpus> still the apt-get issue?
07:11 < wumpus> nothing we can do there
07:12 < wumpus> docker needs to wake up on this https://github.com/docker/docker/issues/23203
07:13 < sipa> MarcoFalke: also, unrelated... i don't think we should care much about header file dependencies (apart from making compilation time and memory larger, they don't hurt modularity)... what matters is dependencies between (.h,.c) pairs on eachother, and wallet.cpp already depends on main.cpp
07:13 < phantomcircuit> wumpus, no im testing locally
07:13 < MarcoFalke> ok
07:14 < sipa> the reasoning being: you already can't use the functionality from wallet.{cpp,h} without having main.{cpp,h} available, so there already is a dependency
07:16 -!- Thireus1 [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
07:16 -!- Thireus1 [~Thireus@icy.thireus.fr] has quit [Client Quit]
07:21 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
07:22 < jonasschnelli> MarcoFalke: sipa: what about introducing a nodemodel.{cpp/h} that could act as a wallet/node API?
07:22 < sipa> how is that different from clientmodel?
07:23 < jonasschnelli> clientmodel is GUI
07:23 < jonasschnelli> nodemodel would be core/wallet
07:23 < sipa> i don't understand
07:23 < sipa> clientmodel is the abstraction of the client/node that the GUI uses to communicate with core
07:23 < jonasschnelli> Main reason for this could be to have all node interaction in a single file (better readability, better source for later decoupling)
07:23 < jonasschnelli> Yes. It could also be clientmodel... 
07:23 < sipa> ah, you mean a lower level
07:23 < jonasschnelli> yes.
07:24 < sipa> what sort of code would move there?
07:24 < jonasschnelli> Fee estimation, relay fee, etc.
07:24 < jonasschnelli> broadcast
07:25 < sipa> i wouldn't put wallet-related things there (as those shouldn't be lumped together long term)
07:26 < sipa> but if there are pieces of code shared between gui and rpc, it makes sense to move them to a common abstraction layer below
07:28 < wumpus> wallet.cpp can depend on main.cpp, but not the other way around
07:30 < wumpus> I'm not sure adding all node interaction in a single file is a step forward; we'tre trying to modularize things beyond that, e.g. net is different from blockchain handling
07:31 < jonasschnelli> Yes. I agree, move it to a single file would only increase code readability, ... and not sure if this is worth a PR.
07:32 < sipa> wumpus: agree
07:33 < sipa> i think we're perhaps better off spending time to move code from RPC calls (especially the complicated code inside RPCs that grabs cs_main) to somewhere in the core code instead, so that the RPC is just a single call
07:33 < wumpus> clientmodel has way too many responsibilities
07:34 < wumpus> (but it's fine for the GUI, and was a big step forward from satoshi's stuff)
07:34 < wumpus> yes, that makes sense, ideally only main functions would lock cs_main
07:34 < wumpus> on the other hand at this point I'd not like moving things into main
07:34 < wumpus> main has the same issue
07:35 < wumpus> but after net refactors etc, sure
07:36 < wumpus> I don't think RPC functions necessarily need to be just a single call, what matters is that operations that need to happen under cs_main lock and act on main data structures would be better off in main, but these could be the minimal possible encapsulated operations
07:36 < sipa> wumpus: +1
07:37 < sipa> anything that grabs a lock should be moved to the module that manages that lock
07:37 < sipa> (in practice, that often means introducing callback functions etc... though)
07:37 -!- cryptapus_ is now known as cryptapus
07:37 < wumpus> aren't we happy with c++11 lambdas then
07:38 < sipa> i should learn to use those :)
07:38 < sipa> but yes
07:38 < wumpus> cfields taught me how to use them in Zurich
07:39 < wumpus> I'm impressed, the functionality is so flexible it seems almost un-c++
07:40 < wumpus> (e.g. how code in a lambda can use variables from the enclosing function is more remniscent of dynamic languages)
07:41 < wumpus> phantomcircuit: if you run it locally you should have an error message?
07:41 < gmaxwell> GCC nested functions can do that too.
07:44 < phantomcircuit> wumpus, i have lots of error messages
07:44 < wumpus> didn't know that! there's not really precedent, c++ nested classes cannot access members from enclosing classes, like in java static inner classes
07:44 < phantomcircuit> im checking again after a git clean -fdx
07:44 < wumpus> phantomcircuit: so the autotests fails? 
07:44 < wumpus> or the qa tests?
07:44 < phantomcircuit> wumpus, rpc pull tests fail
07:44 < phantomcircuit> make check tests pass
07:45 < MarcoFalke> which rpc-test?
07:45 < phantomcircuit> a bunch of the wallet related ones
07:45 < phantomcircuit> i'll clarify in a minute when im done recompiling
07:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:52 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:54 < phantomcircuit> and now everything passes
07:54 < phantomcircuit> >.>
07:54 < phantomcircuit> nvm
07:58 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:01 < GitHub38> [bitcoin] jonasschnelli opened pull request #8138: Add maximal amount-of-transactions limit to checkblock/CVerifyDB (master...2016/06/verify_db) https://github.com/bitcoin/bitcoin/pull/8138
08:01 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
08:05 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-ecwuluqyiuwaduog] has quit [Ping timeout: 264 seconds]
08:06 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-izdgswuchwrrbabq] has joined #bitcoin-core-dev
08:06 -!- zooko [~user@172.56.6.81] has quit [Ping timeout: 260 seconds]
08:07 -!- eragmus [sid136308@gateway/web/irccloud.com/x-kacggwuxkjcpjqzg] has quit [Ping timeout: 264 seconds]
08:07 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
08:09 -!- eragmus [sid136308@gateway/web/irccloud.com/x-uoanbfeasmaacjrb] has joined #bitcoin-core-dev
08:12 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
08:15 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection]
08:15 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev
08:19 < sipa> ping for review: https://github.com/bitcoin/bitcoin/pull/7948 (RPC: augment getblockchaininfo bip9_softforks data)
08:20 < sipa> ping for review: https://github.com/bitcoin/bitcoin/pull/7967 ([RPC] add feerate option to fundrawtransaction)
08:23 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Quit: Conversation terminated!]
08:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
08:50 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
08:51 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
08:56 < sipa> phantomcircuit: are you seeing this:
08:56 < sipa> https://www.zerobin.net/?340fa0188dd35804#2Hkj8AQ8nQtI3LWQpGNrAHGnmRVeCiqVvm9BkG2+HpM=
09:00 < sipa> MarcoFalke: ^
09:04 < MarcoFalke> sipa: any zombie bitcoinds? ps -A |grep bitcoind
09:04 < sipa> nope
09:04 < MarcoFalke> reproducible?
09:04 < sipa> retried the test walletbackup.py itself and got a different error
09:05 < sipa> now trying rpc-tests.py again, and it seems to run ok
09:05 < sipa> at least it doesn't instantly fail like before
09:05 < MarcoFalke> Have you been running ./rpc-tests.py in parallel?
09:06 < MarcoFalke> (This doesn't work)
09:06 < sipa> no
09:06 < sipa> if you mean multiple instances of rpc-tests.py simultaneously, no
09:06 < MarcoFalke> jup
09:07 -!- erasmospunk [~erasmospu@78-221-26.adsl.cyta.gr] has joined #bitcoin-core-dev
09:08 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
09:13 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
09:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
09:37 -!- erasmospunk [~erasmospu@78-221-26.adsl.cyta.gr] has quit [Remote host closed the connection]
09:37 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
09:45 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
09:53 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
09:57 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:04 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
10:06 -!- erasmospunk [~erasmospu@46.198.179.187] has joined #bitcoin-core-dev
10:10 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
10:14 < GitHub121> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/ee1533e262e7...ec45cc5e2766
10:14 < GitHub121> bitcoin/master 84c13e7 Wladimir J. van der Laan: chain: Add assertion in case of missing records in index db
10:14 < GitHub121> bitcoin/master 6030625 Wladimir J. van der Laan: test: Add more thorough test for dbwrapper iterators...
10:14 < GitHub121> bitcoin/master 269a440 Matt Corallo: Add test for dbwrapper iterators with same-prefix keys.
10:15 < GitHub78> [bitcoin] sipa closed pull request #7992: Extend #7956 with one more test. (master...16-5-7956-update) https://github.com/bitcoin/bitcoin/pull/7992
10:15 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
10:15 < GitHub30> [bitcoin] sipa closed pull request #8051: Seemingly fix walletbackup.py failure (master...fixwalletbackup) https://github.com/bitcoin/bitcoin/pull/8051
10:17 < GitHub20> [bitcoin] sipa opened pull request #8139: Fix interrupted HTTP RPC connection workaround for Python 3.5+ (master...fixwalletbackup) https://github.com/bitcoin/bitcoin/pull/8139
10:25 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
10:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
10:31 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
10:34 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
10:41 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
10:42 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:57 -!- calibre720 [~calibre72@182.57.71.21] has quit [Ping timeout: 260 seconds]
11:11 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
11:16 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
11:32 -!- erasmospunk [~erasmospu@46.198.179.187] has quit [Remote host closed the connection]
11:39 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
11:42 -!- frankenmint [~frankenmi@97-122-24-225.hlrn.qwest.net] has joined #bitcoin-core-dev
11:43 -!- frankenm_ [~frankenmi@97-122-24-225.hlrn.qwest.net] has joined #bitcoin-core-dev
11:44 -!- frankenm_ is now known as frankenmint_
11:45 -!- frankenm_ [~frankenmi@97-122-24-225.hlrn.qwest.net] has joined #bitcoin-core-dev
11:46 -!- erasmospunk [~erasmospu@46.198.179.187] has joined #bitcoin-core-dev
11:46 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection]
11:46 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev
11:47 -!- franken__ [~frankenmi@97-122-24-225.hlrn.qwest.net] has joined #bitcoin-core-dev
11:47 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev
11:47 -!- frankenmint [~frankenmi@97-122-24-225.hlrn.qwest.net] has quit [Ping timeout: 250 seconds]
11:47 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
11:48 -!- frankenmint_ [~frankenmi@97-122-24-225.hlrn.qwest.net] has quit [Ping timeout: 250 seconds]
11:49 -!- TheFactory7 [uid164731@gateway/web/irccloud.com/x-pshvyzagcuybrmju] has joined #bitcoin-core-dev
11:50 -!- frankenm_ [~frankenmi@97-122-24-225.hlrn.qwest.net] has quit [Ping timeout: 258 seconds]
11:50 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
11:50 -!- frankenm_ [~frankenmi@75-175-110-137.ptld.qwest.net] has joined #bitcoin-core-dev
11:51 -!- frankenm_ is now known as frankenmint_
11:51 -!- franken__ [~frankenmi@97-122-24-225.hlrn.qwest.net] has quit [Ping timeout: 250 seconds]
11:55 < GitHub100> [bitcoin] mrbandrews opened pull request #8141: Continuing port of java comparison tool (master...ba-comptool) https://github.com/bitcoin/bitcoin/pull/8141
11:56 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:56 -!- jannes_ [~jannes@178.132.211.90] has quit [Quit: Leaving]
11:57 -!- Hoshea [50876d2d@gateway/web/freenode/ip.80.135.109.45] has joined #bitcoin-core-dev
11:58 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
11:58 -!- BakSAj [59b1487b@gateway/web/freenode/ip.89.177.72.123] has joined #bitcoin-core-dev
11:58 < BakSAj> hi
11:59 < wumpus> hi
11:59 < BakSAj> bitcoin core live meeting now?
11:59 < wumpus> yes
12:00 < BakSAj> good :-)
12:00 < sipa> yes
12:00 < BakSAj> any outlook on merging segwit to master?
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Jun  2 19:00:23 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < luke-jr> aww, too fast
12:00 < luke-jr> I was going to propose a topic very unseriously explicitly outside the meeting. :P now it's time to be serious
12:01 < petertodd> hi
12:01 < wumpus> I guess segwit is the recurring topic, any other topic proposals?
12:01 < gmaxwell> jtimon: Cory: morcos: sdaftuar: btcdrak: phantomcircuit: jonasschnelli:
12:01 < jonasschnelli> Here!
12:01 < sipa> cfields_!
12:02 < gmaxwell> I can give some updates on compactblock testing, since it seems that Matt isn't around (or if he shows up, I expect he can)
12:02 < wumpus> great
12:03 < wumpus> #topic segwit review
12:03 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
12:03 < wumpus> let's start with that then
12:04 < sipa> My plan right now is making the BIP9/GBT changes, removing segnet, removing the positive witness flag, and then creating a parallel rebase 
12:04 < sipa> with has a clean history but leads to the same tree
12:04 < sipa> if that is something wanted at this point
12:04 < wumpus> 111 comments on PR #7910, that must be a record
12:04 < luke-jr> "positive witness flag"?
12:05 < sipa> luke-jr: originally, there was a flag to the serialize code to say "serialize witnesses!"; at some point we realized that the opposite was better, as almost always you want to serialize witnesses, and there are just a few exceptions
12:05 < sipa> so i introduced both temporarily, and required that exactly one of both was set
12:05 < luke-jr> oh, I thought having it explicit was a good idea
12:06 < sipa> luke-jr: one reason for the opposite is that a failure where you miss the positive flag will not be detected usually, but failure to set a negative flag will
12:06 < sipa> luke-jr: i thought the same thing initially
12:06 < instagibbs> sipa, are you removing new wallet functionality as well?
12:07 < sipa> instagibbs: ?
12:07 < luke-jr> sipa: what downsides are there to the current explicit flag?
12:07 < sipa> 21:06:22 < sipa> luke-jr: one reason for the opposite is that a failure where you miss the positive flag will not be detected usually, but failure to set a negative flag will
12:07 < instagibbs> I assume you don't want users to have segwit addresses pre-rollout
12:07 < petertodd> luke-jr: indeed, I might have very well written it with a separate CWitnessTx class :)
12:07 < luke-jr> sipa: I don't understand that answer. :<
12:07 < instagibbs> (unless that would still be a testing branch)
12:08 < sipa> luke-jr: if we use a positive flag only, and we miss setting that flag somewhere, it won't easily be detected, as wherever that data goes, it will likely also accept tx without witness
12:08 < luke-jr> right, I'm talking about where we have both positive and negative flags..
12:08 < sipa> ah, that is also an option
12:08 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
12:09 < sipa> it's just more code changes shattered all over the place
12:09 < luke-jr> less likely to have it accidentally wrong, though
12:09 < gmaxwell> With segwit in place there really isn't much further concern about getting the wrong flags, it should only have been an issue with the migration where support had to be added in many places (like RPCs) that might have less test coverage.
12:10 < gmaxwell> If you get it wrong in the future, the thing you changed simply won't work right. And hopefully you'll be testing the thing you just changed.
12:10 < gmaxwell> I don't have a strong or strongly held opinion however.
12:10 < luke-jr> we have a lot of outstanding PRs that may need to be updated that might not conflict
12:10 < jtimon> ack on cleaning history while removing the testnet
12:11 < wumpus> instagibbs: well in principle, master is attesting branch
12:11 < sipa> there are a few things we need in first, though
12:11 < petertodd> jtimon: you mean segnet?
12:11 < wumpus> jtimon: you mean removing the segnet? don't make him remove testnet too :)
12:11 < instagibbs> oh a testing, not attesting
12:12 < jtimon> petertodd: I believe sipa meant removing segwit's testnet
12:12 < gmaxwell> sipa: in any case, what do you think will let you get the code merged sooner?
12:12 < sipa> #7749 and #8083
12:12 < wumpus> but yes ACK on cleaning up the history before merge 
12:12 < gmaxwell> I like cleaning history for sure.
12:12 < gmaxwell> Future me thanks you.
12:12 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
12:13 < sipa> well it definitely has to happen before merge
12:13 < jonasschnelli> As said, we can ACK the sha256sum of the diff (if someone cares about integrity of an ACK)
12:13 < sipa> the question whether the time is now for that
12:13 < luke-jr> (GBT VB as well)
12:13 < sipa> jonasschnelli: git internally has tree hashes
12:13 < jonasschnelli> sipa: Nice. That should work.
12:14 < sipa> So please review #7749 and #8083
12:14 < luke-jr> did we get anywhere with the fundrawtransaction issue?
12:14 < sipa> luke-jr: i can't remember the conclusion there
12:14 < wumpus> q: is everything in the segwit PR meant to go in at once, or will it be split up in to, say, a pull with consensus/network changes, following up with wallet, and GUI changes
12:14 < jonasschnelli> Re 8083: im finalizing the seeder part (nits and filterbitmap-whitelist)
12:15 < wumpus> #action review #7749 and #8083
12:15 < luke-jr> sipa: IIRC, 1) it's a problem; 2) we won't change consensus code to fix it
12:15 < luke-jr> I don't know of any actual resolution to the problem :/
12:15 < gmaxwell> wumpus: If sipa does the "rewrite history to result in the same code thing" then if it is is PR split they will need to go in one right after another to preserve the "same code" property.
12:15 < gmaxwell> (I think)
12:16 < sipa> wumpus: that's a good question; the history is broken into sections already
12:16 < sipa> so we can decide later
12:16 < sipa> though... maybe not
12:16 < gmaxwell> I suppose sipa should show "same code" at one point, then split, and the remaining parts could then change.
12:16 < sipa> the unit/rpc/p2p tests rely on the wallet code
12:16 < wumpus> gmaxwell: I don't have a strong opinion either way, if this change is sufficiently atomic it makes sense to do it at once, but see e.g. instagibbs's comment about wallet addresses
12:17 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Ping timeout: 240 seconds]
12:17 < wumpus> maybe hide it behind an option in the beginning?
12:17 < gmaxwell> My recommendation for the wallet parts was to just hide the changed functionality there behind a hidden configuration option that the tests could use.
12:17 < jtimon> well, the wallet code can be maybe be introduced disabled for users with a constant to be removed later or something?
12:17 < sipa> maybe we can disable addwitnessaddress before the softfork
12:17 < wumpus> gmaxwell: right
12:17 < sipa> that would make sense
12:17 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
12:17 < wumpus> jtimon: hey we're all saying the same :)
12:17 < jtimon> wumpus: yes
12:17 < sipa> yay, agreement
12:17 < sipa> i have another question
12:18 < gmaxwell> sipa: what is the meaning of life?
12:18 < sipa> 42
12:18 < jonasschnelli> :)
12:18 < gmaxwell> thats an answer, not a question!
12:18 < luke-jr> he has both the answer and a question
12:18 < gmaxwell> We're going to need to build a bigger computer...
12:18 < sipa> jl2012 brought up the issue that our witness program definition is limited to 16 versions, and that is not easy to extend without introducing a new witness storage
12:18 < sipa> there is an easy solution, by allowing witness programs to be slightly larger
12:19 < sipa> but this is a hard forking change
12:19 < luke-jr> sipa: it is? I thought the version could be any length?
12:19 < sipa> which, if done unconditionally, could hardfork testnet
12:19 < sipa> luke-jr: nope, has to be OP_0 through OP_16
12:19 < luke-jr> :/
12:19 < luke-jr> why limit it?
12:19 < jtimon> then would be something to move to the later hardfork, no?
12:20 < sipa> jtimon: i don't like relying on that
12:20 < gmaxwell> Oh ... how'd that happen? in any case, you can simply use 0..16 and then use another byte after that one.
12:20 < luke-jr> jtimon: we cannot assume there will ever be a hardfork.
12:20 < sipa> gmaxwell: max 32 bytes can follow
12:20 < gmaxwell> okay thats broken.
12:20  * luke-jr doesn't see the purpose of restricting the witness-triggering sPK like that
12:20 < jtimon> well, the plan was to deploy segwit as a softfork
12:21 < sipa> jtimon: changing it is a HF with respect to the current SW code
12:21 < gmaxwell> My assumption was that it would be arbritary and extended by just adding more bytes when the space ran out.
12:21 < sipa> jtimon: not with respect to bitcoin
12:21 < sipa> jtimon: so we can change it before merge while leaving SW a SF
12:21 < jtimon> sipa: oh, I see, it would still be a SF to bitcoin. ok
12:21 < sipa> gmaxwell, luke-jr: the reason was that constant size utxos are nice
12:21 < gmaxwell> sipa: testnet segwit rules can be changed so activiation doesn't begin until later.
12:22 < gmaxwell> So at worst that would be a reindex for testnet nodes, no?
12:22 < sipa> gmaxwell: ... segwit is already activated on testnet
12:22 < gmaxwell> yes, so?
12:22 < luke-jr> sipa: they're already non-constant size.
12:22 < sipa> luke-jr: ?
12:22 < gmaxwell> sipa: move it forward, reindex.
12:22 < jtimon> testnet4 ?
12:22 < gmaxwell> luke-jr: he means in the future.
12:22 < gmaxwell> sipa: in any case, 16 is unacceptably too few.
12:22 < sipa> agree
12:23 < sipa> gmaxwell: hmm, ok
12:23 < instagibbs> The bip doesn't read like it would be a HF, but maybe I'm being obtuse
12:23 < gmaxwell> I don't think constant size is as interesting as constant bound. so if you wanted to say that the version was limited to N bytes for some small N that would be fine. 4294967296 versions should be enough for anyone.
12:23 < luke-jr> gmaxwell: in the future, if we softfork out the current long sPKs, we can softfork a limit on witness sPK length as well
12:23 -!- frankenmint_ is now known as frankenmint
12:23 < sipa> fair enough, will do
12:24 < sipa> limit to 36 or 40 bytes or so
12:24 < jtimon> instagibbs: it would be a HF only for testnet3 which has already deployed "old segwit"
12:24 < instagibbs> jtimon, no I mean, anything where version is 1+ has no consensus meaning yet
12:24 < gmaxwell> sipa: cool (also, testnet behavior has never been in a merged much less released version, I don't mind breaking it)
12:24 < instagibbs> when it's not simply 0
12:25 < sipa> instagibbs: the problem is that something of the form "1 + 33 bytes" is not treated as a witness program, and is not allowed to have any witness data
12:25 < sipa> we can extend the definition of a witness program, but it would require a new witness structure
12:25 < sipa> as old nodes won't relay witness data with something they don't treat as a witness output
12:25 < sipa> (and that rule is necessary to prevent spam)
12:26 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev
12:26 < sipa> anyway, ok, will just change the rule
12:26 < sipa> other topics?
12:26 < wumpus> yes
12:26 < luke-jr> old nodes won't relay anything with witness data they can't verify anyway..
12:26 < sipa> (or more segwit review related points)
12:26 < wumpus> #topic compactblock testing
12:27 < sipa> luke-jr: old nodes in this case being witness v0 nodes
12:27 < instagibbs> luke-jr, I'm not convinced, but I think fixing now is better anyways so whatever
12:27 < luke-jr> sipa: yes, I also mean these
12:27 < wumpus> @gmaxwell
12:27 < luke-jr> IMO make any length limit a relay policy only.
12:27 < sipa> we'll discuss further in #segwit-dev
12:27 < luke-jr> k
12:27 < instagibbs> ack
12:28 < jtimon> compackblock
12:28 < gmaxwell> Okay. So matt has built a parallel relay network that uses compact blocks and the UDP network block coding stuff.
12:28 < sipa> i rebased BlueMatt's compactblock patch on top of the shared_ptr mempool change, and gmaxwell and i have been succesfully running it across the internet
12:28 < sipa> ^ and that's more interesting
12:28 < gmaxwell> ^ a number of people-- including some large miners-- are running both Sipa's rebase,  and Matt's PR without the rebase on public nodes.
12:29 < gmaxwell> Which are also connecting to matt's nodes. 
12:29 < wumpus> good to hear
12:29 < gmaxwell> (I got bored with the simulated topology lab testing, this is potentially more interesting)
12:29 < sipa> 2016-06-02 18:36:13.412286 Successfully reconstructed block 0000000000000000014a6a924544dd097d538314281bebd95c89e50726e7d2ef with 1 txn prefilled, 2708 txn from mempool and 0 txn requested
12:29 < sipa> 2016-06-02 18:37:46.728092 Successfully reconstructed block 000000000000000001943282946e9579fd84def95df577ebb8bcda3b8d9f4d06 with 1 txn prefilled, 1529 txn from mempool and 0 txn requested
12:29 < sipa> 2016-06-02 18:43:32.713909 Successfully reconstructed block 000000000000000000499e1485726cd87003e7a6400118f8c061171748665612 with 1 txn prefilled, 1102 txn from mempool and 3 txn requested
12:29 < wumpus> yes, always good to test with real world data as well
12:29 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
12:30 < gmaxwell> I don't know that there is much to report, it's working as expected.  :)   Sipa's rebase on the sharedptr is pretty nice.
12:30 < instagibbs> gmaxwell, the rebase includes the predicted transactions?
12:30 < BakSAj> nice
12:30 < gmaxwell> As it also eliminates transaction duplication from the relay pool, and eliminates a fair bit of transaction copying.
12:30 < wumpus> is this branch available somewhere?
12:30 < sipa> instagibbs: it only sends the coinbase directly
12:30 < instagibbs> sipa, ah k
12:30 < gmaxwell> instagibbs: no, right now I don't believe anyone is running something with fancy prediction.  I think we'll leave that out in the initial PR. Easily added later.
12:30 < sipa> wumpus: https://github.com/sipa/bitcoin/commits/compactblocks
12:31 < wumpus> #link sipa's rebase of compactblocks on top of PR #8126: https://github.com/sipa/bitcoin/commits/compactblocks
12:31 < wumpus> #action review PR #8126
12:32 < gmaxwell> if other developers here are interested in running nodes connected to these nodes, lemme know and I'll give you addresses to connect to.
12:32 < wumpus> I'm interested
12:32 < gmaxwell> I should take an action to setup a couple on published addresses too, for people to connect to without asking. :)
12:32 < wumpus> yes, that always works best :)
12:33 < wumpus> any other topics?
12:33 < luke-jr> is sipa's rebase different enough that we ought to switch to reviewing that instead?
12:33 < gmaxwell> Yes, though they may get DDOS attacked, which is harmless but would waste time sorting out the issue. :)
12:33 < sipa> luke-jr: it's less code than the original :)
12:33 < wumpus> gmaxwell: you mean thoroughly stress-tested :)
12:34  * gmaxwell stabs
12:34 < gmaxwell> Does anyone know the current CFPF status?
12:34 < wumpus> #topic current CPFP status
12:34 < sipa> gmaxwell: review #7598
12:34 < luke-jr> afaik no show-stoppers found, but more review needed; there's a dep PR to get in first though
12:34 < wumpus> #action  review #7598
12:35 < sipa> it's a blocker/dependency for CPFP (#7600)
12:36 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
12:37 < gmaxwell> I've been struggling a bit with too many PRs outstanding at once that I want to test.
12:37 < wumpus> #link CPFP is that like 'strong AI should be here in less than 20 years'
12:37 < wumpus> EH
12:37 < luke-jr> :<
12:37 < wumpus> #link https://github.com/bitcoin/bitcoin/pull/7600
12:38 < wumpus> (sorry, copy paste messup)
12:38 < gmaxwell> Merging them is a pain.  (thanks to sipa for merging a lot of things recently!)
12:38 < sipa> i've been going through all PRs... there are so many decent-but-not-quite-finished ones in the queue...
12:38 < wumpus> I've lost overview a bit
12:38 < wumpus> any PRs that should be close to be able to be merged?
12:39 < wumpus> sipa: yes, I've noticed
12:39 < jonasschnelli> IMO https://github.com/bitcoin/bitcoin/pull/7957 can be merged (save, tool only)
12:39 < gmaxwell> Mostly my minor difficulty there just comes from many things touching the same parts, and a lot of that was actually my fault. (e.g. opening three PRs at once that all conflicted with each other. :) )
12:39 < luke-jr> I'd like to see key generation type merged so there's no risk of other wallet upgrades conflicting it since these wallets are in the wild
12:39 < sipa> 17:19:13 < sipa> ping for review: https://github.com/bitcoin/bitcoin/pull/7948 (RPC: augment getblockchaininfo bip9_softforks data)
12:39 < sipa> 17:20:03 < sipa> ping for review: https://github.com/bitcoin/bitcoin/pull/7967 ([RPC] add feerate option to fundrawtransaction)
12:40 < wumpus> jonasschnelli: agree, but that one is probably not blocking anything
12:40 < sipa> also 7997
12:41 < jonasschnelli> I'm requesting permission to merge [docs] and [tools] PRs
12:41 < wumpus> jonasschnelli: sure
12:42 < gmaxwell> sounds fine, I know we sometimes don't get enough review on those, esp docs. Please feel empowered to nag people to review things.
12:42 < jonasschnelli> Okay. Will try to focus on trivial docs PRs, so wumpus and sipa can take care about the corish ones.
12:42 < luke-jr> https://github.com/bitcoin/bitcoin/pull/7935 is ready IMO
12:42 < wumpus> the problem with doc pulls is usually that they get review comments but the author disappears for large spans of time
12:42 < sipa> luke-jr: agree
12:43 < sipa> luke-jr: will do final review and reack
12:43 < cfields_> luke-jr: that looked good to me last time I checked. I'll re-review as well.
12:44 < sipa> also #7825 is good
12:45 < sipa> and #7942
12:46 < jonasschnelli> Also have a look at https://github.com/bitcoin/bitcoin/pull/7946 (could speed up things a little bit)
12:46 < wumpus> #7942 has an unaddressed comment by sipa
12:46 < sipa> tiny nit :)
12:47 -!- skang404 [~skang404@122.170.137.19] has joined #bitcoin-core-dev
12:47 < jonasschnelli> nit is nit!
12:47 < wumpus> that's not always clear to me whether it should block merging
12:47 < wumpus> (I usually at least wait for the author to respond)
12:48 < sipa> the author is active, he probably just missed it
12:48 < sipa> jonasschnelli just pinged
12:48 < wumpus> ok good
12:48 < luke-jr> oh, topic: 0.11.next
12:49 < jonasschnelli> luke-jr, I guess we already discussed the 0.11 maintenance?
12:49 < wumpus> ok
12:49 < wumpus> #topic 0.11.next
12:49 < luke-jr> jonasschnelli: ?
12:50 < sipa> 0.11 goes to critical fixes only when 0.13 is released, right?
12:50 < jtimon> luke-jr: 0.11.next is supposed to include csv but not segwit, right?
12:50 < jonasschnelli> I had in mind we we BP to 0.12, 0.13 and only security stuff to 0.11?
12:50 < luke-jr> jtimon: unless it gets delayed until segwit is merged, I guess
12:50 < wumpus> is there any urgent reason to do a 0.11 release?
12:50 < luke-jr> sipa: unless someone decides to maintain it longer
12:51 < luke-jr> wumpus: CSV support, at least
12:51 < wumpus> right
12:51 < jtimon> wumpus: is there any reason not to do it while things are backported and tested?
12:51 < gmaxwell> looking at the network I'm not seeing any evidence of need to maintain 0.11 extensively, also we called for people running older versions in operations and got crickets in response, AFAIK.
12:51 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
12:51  * jonasschnelli checking the seeder
12:51 < wumpus> jtimon: developer overhead
12:51 < sipa> jtimon: is it tested?
12:51 < jtimon> wumpus: well, that's luke-jr's problem, isn't it?
12:52 < luke-jr> gmaxwell: we did? I don't recall seeing the "call for", and I know for a fact that Eligius relies on 0.11 for now
12:52 < jonasschnelli> 88  0.11  nodes 
12:53 < jtimon> sipa: I don't know, I'm not reviewing or testing myself, but if luke-jr gets review and testing...
12:53 < sipa> luke-jr: perhaps the time is better spent in upgrading eligius then :)
12:53 < luke-jr> jtimon: which is unlikely, hence the history of git/rc only stable stuff :P
12:53 < luke-jr> sipa: probably.
12:53 < gmaxwell> esp since master will hopefully have CPFP soon.
12:53 < luke-jr> jonasschnelli: what?
12:53 < wumpus> yes, interest in older major versions is extrememly low
12:54 < btcdrak> there is a backport PR for 0.11 for CSV etc. but we sort of semi decided back then it was not urgent and much more risky.
12:54 < luke-jr> I see 1768 0.11 nodes.
12:54 < btcdrak> the BIP68 backport in particular is complex
12:54 < jtimon> my only point is that we shouldn't use the "we only promise to maintain the last 2 versions" as an artificial limitation beyond review and testing. If people are interested in working on that...
12:54 < gmaxwell> well in particular, interest in _updates_ for old versions is low...
12:54 < wumpus> gmaxwell: yes that's what I mean...
12:54 < luke-jr> we should remove the promise if we're not going to uphold it.
12:55 < wumpus> jtimon: the problem is that people are not interested
12:55 < gmaxwell> what promise?
12:55 < jtimon> well "promise"
12:55 < gmaxwell> also, not "not going"-- not able.. without people to test you really can't provide good releases.
12:55 < jtimon> wumpus: by people you mean users or reviewers/testers?
12:55 < gmaxwell> not doing someone a service to put out a barely tested update.
12:55 < wumpus> I mean if luke-jr really wants to handle a release by himself I'm not going to protest
12:56 < gmaxwell> ^ agreed.
12:56 < luke-jr> https://bitcoincore.org/en/lifecycle/ mentions something; whether promise or able or not, it should be updated if we can't do it
12:56 < btcdrak> the CSV backport PR was https://github.com/bitcoin/bitcoin/pull/7716
12:56 < btcdrak> we did pretty much decide not to merge it.
12:56 < luke-jr> wumpus: I can't get testing/reviews by myself.
12:56 < jonasschnelli> luke-jr: sorry,.. wrong file: we have 743 0.11x nodes and 1786 0.12.x nodes... so yes. CSV for 0.11 makes sense.
12:56 < luke-jr> I can maintain stable branches, but releases seem unlikely to work out at this point
12:56 < wumpus> but there's so much happening on master right now, and 0.13 release is near, I can't promise I will be able to spend any time on it (except gitian building / uploading executables)
12:57 < jonasschnelli> Yes. 0.11 is certainly not something for wumpus (would be a waste of his time)
12:57 < gmaxwell> Without people interested in using it, we can't get much platform qualification which is a lot of the difference between a branch and a release.
12:57 < wumpus> so if you want to do this: please create your own 0.11 branch, tag, do the release notes etc
12:58 < sipa> jtimon: i have 1093 'good' 0.11 nodes
12:58 < sipa> eh, jonasschnelli:
12:58 < jonasschnelli> good is not good enough...
12:58 < jonasschnelli> cat dnsseed.dump | grep " 100.00% 100.00% 100.00% " | grep "Satoshi:0.11." | wc -l
12:59 < sipa> anyway, besided the point
12:59 < sipa> we can't do releases without people interested in running and testing
12:59 < wumpus> yes, meeting time over
12:59 < sipa> oh, that too
12:59 < wumpus> #endmeeting
12:59 < lightningbot> Meeting ended Thu Jun  2 19:59:24 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:59 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-02-19.00.html
12:59 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-02-19.00.txt
12:59 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-02-19.00.log.html
12:59 < jtimon> maybe we can merge it into the 0.11 branch without doing a release?
13:00 < wumpus> jtimon: sure. luke-jr can run his own 0.11 branch, I could just take that over
13:00 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
13:00 < gmaxwell> could be done, I suppose. But thing is: soft forks are more or less safe to run without, but a broken update may be less safe.
13:00 < gmaxwell> not that I think there is a lot of risk there.
13:00 < jtimon> and if it ever gets tested, release, otherwise there's never a 0.11.next
13:00 < wumpus> well if no one runs it, it doesn't create much risk either :)
13:00 < gmaxwell> Good point.
13:01 < luke-jr> wumpus: should I continue to maintain stable branches in a separate repo (the old one was on Gitorious which is dead, so a new location needs deciding if so), or would it make sense to do it on the main repo now (would require push access for me, at least in the stable branches)?
13:01 < luke-jr> [20:00:18] <gmaxwell> could be done, I suppose. But thing is: soft forks are more or less safe to run without, but a broken update may be less safe. <-- my main concern with backporting of the recent softforks
13:02 < wumpus> luke-jr: well you don't strictly need push access; I could just pull the 0.11 branch from your repo when you say so
13:02 < jtimon> can't we just merge PRs in the 0.11 branch in the main repo?
13:02 < btcdrak> luke-jr: morcos specific concern was the safety of BIP68 backport
13:02 < luke-jr> wumpus: that'd work too I guess
13:02 < btcdrak> the backports were done in #7716
13:03 < jtimon> or that, I'll shut up, you people coordinate
13:03 < btcdrak> The codebase is significantly different between 0.11 and 0.12 with regards to BIP68
13:03 < luke-jr> it probably would make sense to have a separate repo for stable in general, though, so we can't accidentally confuse PRs against the wrong branch
13:05 < wumpus> at least the github merge script now automatically gets the branch to merge against from github
13:05 < gmaxwell> luke-jr: is there any thing I could help do to get eligius off of 0.11 and to 0.12.1  (and maybe master with CPFP?)
13:07 < luke-jr> gmaxwell: my current target is Knots 0.12.1 including CPFP there, so the big step is backporting CPFP in a way that can be turned on/off (which AIUI, the CPFP dep makes easier); I don't think there's a good way to divide this work, however
13:08 < gmaxwell> luke-jr: ugh. 
13:08 < gmaxwell> I don't see what benefit you get from 0.12.1 with such a large and invasive backport.
13:09 < luke-jr> as opposed to everything else in master? :x
13:10 < gmaxwell> which has a lot more eyes on it, and in the mining relevant codepaths, the changes for CPFP are probably the bulk of the changes.
13:11 < gmaxwell> also, look ahead a bit, and you'd have to forward port that backport onto segwit.
13:13 < luke-jr> hmm
13:14 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
13:15 < BakSAj> i understand the need for backporting in enterprise software, where upgrades might get messy, but what is the exact point in btc where process is quite simple...?
13:15 < luke-jr> not sure it'd be less work to forward-port Knots to master either, though
13:15 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Quit: laurentmt]
13:15 < luke-jr> BakSAj: consensus systems carry even more risk in upgrades, than enterprise
13:16 < gmaxwell> BakSAj: there are many large businesses that use Bitcoin too, and some that have complex customizations.
13:16 < sipa> luke-jr: what other kinds of changes does Knots have?
13:16 < gmaxwell> BakSAj: unfortunately, though we know these deployments exist-- we seldom hear from people involved with them.
13:18 < luke-jr> sipa: http://bitcoinknots.org/ has the full list, but relevant to Eligius.. *skims over list* #7149, #7533, and spamfilter; so maybe easier than backporting CPFP
13:18 < BakSAj> i wonder if they do patching
13:19 < BakSAj> otherwise its just a waste of dev that can go to master version
13:19 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
13:19 < luke-jr> would be nice to get #7149 reviewed and merged finally.
13:20 < btcdrak> This was the summary regarding the backports, for the record https://bitcoincore.org/en/meetings/2016/03/31/#softfork-backports
13:28 < BakSAj> ok, thanks for clarification
13:29 < BakSAj> i hope 0.12.1 will activate soon, so you guys can move on with segwit and get lightning finally
13:29 < BakSAj> anybody happen to know when e.g. f2pool moves to 0.12.1 ?
13:34 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Remote host closed the connection]
13:35 -!- face [~face@mail.hmel.org] has quit [Ping timeout: 260 seconds]
13:36 -!- erasmospunk [~erasmospu@46.198.179.187] has quit [Remote host closed the connection]
13:37 -!- skang404 [~skang404@122.170.137.19] has quit [Read error: Connection reset by peer]
13:37 -!- skang404 [~skang404@122.170.137.19] has joined #bitcoin-core-dev
13:41 -!- Hoshea [50876d2d@gateway/web/freenode/ip.80.135.109.45] has quit [Ping timeout: 250 seconds]
13:43 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
13:45 -!- BakSAj [59b1487b@gateway/web/freenode/ip.89.177.72.123] has quit [Quit: Page closed]
14:15 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
14:20 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
14:40 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:10 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
15:17 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
15:21 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
15:45 < GitHub51> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ec45cc5e2766...f972b04d63eb
15:45 < GitHub51> bitcoin/master 0bf6f30 Pedro Branco: Prevent multiple calls to ExtractDestination
15:45 < GitHub51> bitcoin/master f972b04 Pieter Wuille: Merge #7825: Prevent multiple calls to ExtractDestination...
15:45 < GitHub30> [bitcoin] sipa closed pull request #7825: Prevent multiple calls to ExtractDestination (master...enhancement/prevent-multiple-calls-extractdestination) https://github.com/bitcoin/bitcoin/pull/7825
15:53 -!- spudowiar is now known as spudowiar-banned
15:54 -!- spudowiar-banned [~spudowiar@unaffiliated/spudowiar] has quit [Quit: WeeChat 0.4.3]
15:58 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
16:01 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
16:06 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Ping timeout: 260 seconds]
16:18 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
16:18 -!- spudowiar is now known as spudowiar-ban
16:18 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
16:20 -!- spudowiar-ban is now known as spudowiar
16:21 -!- kadoban is now known as kadoban_1ufYVpS
16:23 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
16:27 < GitHub138> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f972b04d63eb...a82f03393a32
16:27 < GitHub138> bitcoin/master 9805f4a Kaz Wesley: mapNextTx: use pointer as key, simplify value...
16:27 < GitHub138> bitcoin/master a82f033 Pieter Wuille: Merge #7997: replace mapNextTx with slimmer setSpends...
16:27 < GitHub69> [bitcoin] sipa closed pull request #7997: replace mapNextTx with slimmer setSpends (master...setSpends) https://github.com/bitcoin/bitcoin/pull/7997
16:36 -!- kadoban_1ufYVpS is now known as kadoban
16:39 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
16:54 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
17:11 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
17:11 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
17:13 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
17:20 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
17:24 -!- fengling [~fengling@58.135.95.134] has quit [Ping timeout: 240 seconds]
17:44 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 258 seconds]
17:54 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 258 seconds]
17:58 -!- fengling [~fengling@58.135.95.134] has joined #bitcoin-core-dev
18:05 -!- dermoth [~thomas@dial-216-221-43-121.mtl.aei.ca] has quit [Read error: Connection reset by peer]
18:05 -!- dermoth [~thomas@dial-216-221-43-121.mtl.aei.ca] has joined #bitcoin-core-dev
18:08 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
18:11 -!- grassass [grass@gateway/vpn/mullvad/x-ionnizabzptbwfus] has quit [Ping timeout: 264 seconds]
18:22 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
18:35 -!- dermoth [~thomas@dial-216-221-43-121.mtl.aei.ca] has quit [Read error: Connection reset by peer]
18:38 -!- dermoth [~thomas@dial-216-221-43-121.mtl.aei.ca] has joined #bitcoin-core-dev
18:40 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
19:00 -!- grassass [grass@gateway/vpn/mullvad/x-rtpppbhgbxtrqiio] has joined #bitcoin-core-dev
19:01 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pjolyyjrydqzyuok] has quit [Quit: Connection closed for inactivity]
19:08 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds]
19:09 -!- skang404 [~skang404@122.170.137.19] has quit [Read error: Connection reset by peer]
19:20 -!- calibre720 [~calibre72@182.57.71.21] has joined #bitcoin-core-dev
19:58 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
20:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
20:24 -!- TheFactory7 [uid164731@gateway/web/irccloud.com/x-pshvyzagcuybrmju] has quit [Quit: Connection closed for inactivity]
20:26 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 244 seconds]
20:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:33 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:59 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Quit: Leaving]
21:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:34 -!- moli [~molly@unaffiliated/molly] has quit [Quit: Leaving]
21:35 -!- xiangfu [~xiangfu@58.135.95.136] has joined #bitcoin-core-dev
21:42 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
22:03 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
22:05 -!- grassass [grass@gateway/vpn/mullvad/x-rtpppbhgbxtrqiio] has quit [Read error: Connection reset by peer]
22:05 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 244 seconds]
22:07 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
22:18 -!- gevs [~greg@ip-83-134-150-61.dsl.scarlet.be] has joined #bitcoin-core-dev
22:18 -!- gevs [~greg@ip-83-134-150-61.dsl.scarlet.be] has quit [Changing host]
22:18 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
22:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:39 -!- grassass [grass@gateway/vpn/mullvad/x-dkhldxjjnzeqnfbi] has joined #bitcoin-core-dev
22:41 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:42 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:18 < GitHub68> [bitcoin] pstratem opened pull request #8142: Improve CWallet API  with new GetAccountPubkey function. (master...2016-06-02-cwallet-getaccountpubkey) https://github.com/bitcoin/bitcoin/pull/8142
23:36 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kngbhmmevrlyjejz] has joined #bitcoin-core-dev
23:42 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
23:54 < GitHub160> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a82f03393a32...ae5575ba41c8
23:54 < GitHub160> bitcoin/master f45f51e Pieter Wuille: Fix interrupted HTTP RPC connection workaround for Python 3.5+
23:54 < GitHub160> bitcoin/master ae5575b MarcoFalke: Merge #8139: Fix interrupted HTTP RPC connection workaround for Python 3.5+...
23:54 < GitHub177> [bitcoin] MarcoFalke closed pull request #8139: Fix interrupted HTTP RPC connection workaround for Python 3.5+ (master...fixwalletbackup) https://github.com/bitcoin/bitcoin/pull/8139