--- Day changed Tue Dec 06 2016 00:01 -!- abpa [~abpa@2602:306:b837:dbf0:7413:23eb:93f:5fe1] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 00:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pmthawfmenyzvpzn] has joined #bitcoin-core-dev 00:13 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:19 -!- warren [~warren@fedora/wombat/warren] has quit [Quit: QUIT] 00:19 -!- adam3us_ [~adam3us@unaffiliated/adam3us] has quit [Quit: QUIT] 00:22 -!- adam3us [~adam3us@unaffiliated/adam3us] has joined #bitcoin-core-dev 00:23 -!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev 00:44 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 00:54 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has joined #bitcoin-core-dev 00:57 < bitcoin-git> [bitcoin] gmaxwell opened pull request #9293: [0.13 Backport] IBD using chainwork instead of height and not using header timestamp (#9053) (0.13...9053_backport) https://github.com/bitcoin/bitcoin/pull/9293 00:58 -!- larrysalibra [~larry@058176109066.ctinets.com] has joined #bitcoin-core-dev 00:58 < gmaxwell> based on the prior discussion ^, if we decide we don't want to-- I won't be offened. But I figured I wouldn't ask about it then fail to do the work. 00:59 < gmaxwell> (it wasn't any work, however) 00:59 -!- larrysalibra [~larry@058176109066.ctinets.com] has quit [Client Quit] 01:00 < wumpus> great 01:13 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 01:33 -!- _biO_ [~biO_@80.156.183.43] has quit [Ping timeout: 256 seconds] 01:50 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev 02:06 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [] 02:08 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9294: Use internal HD chain for change outputs (hd split) (master...2016/12/hd_split) https://github.com/bitcoin/bitcoin/pull/9294 02:13 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #9238: Ignore BIP35 mempool command by default (master...2016/11/dis_mempool) https://github.com/bitcoin/bitcoin/pull/9238 02:15 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #8182: [Qt] Add simple opt-in-RBF support (master...2016/04/qt_rbf_set_new) https://github.com/bitcoin/bitcoin/pull/8182 02:15 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #7685: Add bloom filter usage statistics (master...2016/03/bf_stats) https://github.com/bitcoin/bitcoin/pull/7685 02:16 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 02:21 -!- _biO_ [~biO_@80.156.183.43] has joined #bitcoin-core-dev 02:28 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 02:28 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Client Quit] 02:37 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 02:41 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev 02:41 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host] 02:41 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:48 < MarcoFalke> wumpus: Can you add instagibbs to our team? 02:48 < MarcoFalke> https://github.com/orgs/bitcoin/people 02:48 < timothy> MarcoFalke: core developers? 02:49 < MarcoFalke> Just as a member, so I can select pull requests by name :) 02:50 < MarcoFalke> I think it is some read-only group 02:50 < wumpus> sure 02:53 < jonasschnelli> wumpus: Yes. The fundrawtx exception is strange. Currently checking... 02:54 < wumpus> MarcoFalke: I've invited him to bitcoin and bitcoin-core (as read-only member), team page should still be updated 02:56 < MarcoFalke> ok, thx. Often I know who opened a pull request and to check it I use the dropdown on the pull request page. 02:58 < jonasschnelli> Interesting, can you call fundrawtx on a locked wallet?! 02:58 < wumpus> jonasschnelli: yes you should be able to, only signing requires unlocking 02:59 < wumpus> funding requires the wallet's utxo set which is not encrypted 02:59 < jonasschnelli> Not only, also retrieving a change output key 02:59 < jonasschnelli> Keypool can be empty, needs unlocking. 03:00 < wumpus> oh sure - if the keypool is empty it needs new keys, and for that the wallet needs to be unlocked 03:01 < jonasschnelli> But there is nothing that prevents that. Only an assertion 03:01 < wumpus> then can you either generate new keys and re-lock the wallet or call the RPC with wallet unlocked - there's more RPCs which work like that 03:01 < wumpus> it should just raise an exception in that case 03:02 < wumpus> which IIRC trying to get a new key with empty keypool (and locked wallet) does 03:02 < jonasschnelli> https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L2392 03:02 < jonasschnelli> If no key is available, the app crashes. :) 03:02 < jonasschnelli> (over the assertion) 03:03 < jonasschnelli> And I can't find a code block that ensures we check if the wallet is unlocked first. 03:05 * jonasschnelli afk 03:09 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ed8d693c71b0...919db037f1f5 03:09 < bitcoin-git> bitcoin/master fa2ecc4 MarcoFalke: [qa] pruning: Use cached utxo set to run faster 03:09 < bitcoin-git> bitcoin/master fab1af3 MarcoFalke: [qa] maxuploadtarget: Use cached utxo set 03:09 < bitcoin-git> bitcoin/master 919db03 MarcoFalke: Merge #9274: [qa] Use cached utxo set to fix performance regression... 03:09 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9274: [qa] Use cached utxo set to fix performance regression (master...Mf1612-qaPruningCacheUtxos) https://github.com/bitcoin/bitcoin/pull/9274 03:37 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 260 seconds] 03:37 < wumpus> jonasschnelli: yeah that comment is definitely wrong 03:38 < wumpus> jonasschnelli: it should raise an exception, not crash the application 03:39 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 03:46 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 03:46 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 03:46 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 03:48 < jonasschnelli> wumpus: Yes. Will fix that soon, 03:51 * wumpus has built a riscv64 toolchain, then a riscv64 bitcoind and is running it in qemu-riscv64 (linux userspace), now syncing the chain with it. This was surprisingly easy with the depends system, bar 1 line I had to add for openssl configuration and -lpthreads in the LDFLAGS it just worked! 03:55 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 03:55 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 03:55 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 03:55 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 04:03 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/919db037f1f5...e15660c16f75 04:03 < bitcoin-git> bitcoin/master 89a3723 Jonas Schnelli: [Qt] Show ModalOverlay by pressing the progress bar, disabled show() in sync mode 04:03 < bitcoin-git> bitcoin/master e15660c Jonas Schnelli: Merge #9280: [Qt] Show ModalOverlay by pressing the progress bar, allow hiding... 04:04 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #9280: [Qt] Show ModalOverlay by pressing the progress bar, allow hiding (master...2016/12/qt_modal) https://github.com/bitcoin/bitcoin/pull/9280 04:06 -!- e4xit [~e4xit@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Read error: Connection reset by peer] 04:06 -!- e4xit_ [~e4xit@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev 04:21 -!- laurentmt [~Thunderbi@80.215.138.113] has joined #bitcoin-core-dev 04:25 -!- laurentmt [~Thunderbi@80.215.138.113] has quit [Client Quit] 04:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pmthawfmenyzvpzn] has quit [] 04:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hrtfvqbyuzvtouxw] has joined #bitcoin-core-dev 04:50 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-qdxvfcivbdpxyrew] has joined #bitcoin-core-dev 04:51 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9295: [Wallet] Bugfix: Fundrawtransaction: don't terminate when keypool is empty (master...2016/12/fix_frt) https://github.com/bitcoin/bitcoin/pull/9295 04:51 < MarcoFalke> jonasschnelli: Does this fix the segfault on master? 04:52 < jonasschnelli> Which Segfault? 04:52 < jonasschnelli> It should fix an assert terminiation 04:52 < jonasschnelli> not sure if this can lead to a segfault. 04:53 < MarcoFalke> oh, maybe unrelated. 04:53 < MarcoFalke> I can't send any coins: bitcoin-qt: ./primitives/transaction.h:331: void SerializeTransaction(const TxType&, Stream&) [with Stream = CDataStream; TxType = CTransaction]: Assertion `tx.wit.vtxinwit.size() <= tx.vin.size()' failed. 04:53 < jonasschnelli> Hmm... that one probably needs further investigation. 04:57 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-qdxvfcivbdpxyrew] has quit [] 04:58 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-tjgylluggmgtgpco] has joined #bitcoin-core-dev 05:00 < paveljanik> MarcoFalke, I can confirm the same problem here. 05:05 < jonasschnelli> paveljanik MarcoFalke: do we have steps to reproduce? 05:06 < jonasschnelli> Or a failing rpc test snipped? 05:06 < MarcoFalke> Interestingly the rpc tests do not fail, it seems 05:06 < paveljanik> jonasschnelli, only in GUI. 05:06 < MarcoFalke> only the gui, really odd 05:06 < paveljanik> Just Send something somewhere. 05:06 < paveljanik> after waiting for Yes(2) ... Yes. Click on Yes, BUMP 05:10 < afk11> there are some others that wind up exposed through bitcoinconsensus.h.. anyone wish to advise if we should have those functions check if an impossible situation is about to arise before calling VerifyScript? 05:10 < afk11> or consumers of bitcoinconsensus.h? 05:10 < afk11> sorry, others = assertions 05:10 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: leaving] 05:11 < jonasschnelli> paveljanik MarcoFalke: wait, it happens >always< on any tx in the GUI? 05:12 < paveljanik> both two my tries finished with SEIGSEGV 05:13 < jonasschnelli> I can send to myself.. but not directly on master (some commits behind) 05:13 < jonasschnelli> compiling now 05:13 < paveljanik> testnet e.g... 05:14 < paveljanik> it is #8580 05:14 < gribble> https://github.com/bitcoin/bitcoin/issues/8580 | Make CTransaction actually immutable by sipa · Pull Request #8580 · bitcoin/bitcoin · GitHub 05:15 < jonasschnelli> Ah. I'm regtesting.. 05:16 < jonasschnelli> paveljanik, MarcoFalke: has someone opened an issue for that? 05:17 < paveljanik> not yet IIRC. 05:17 < paveljanik> I can't right now, about to leave.. 05:17 < jonasschnelli> Okay. Sure. 05:18 < paveljanik> https://github.com/bitcoin/bitcoin/pull/8580#pullrequestreview-11582301 05:18 < paveljanik> but leaving now, sorry 05:23 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 05:25 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 05:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:39 < morcos> jonasschnelli: paveljanik: found the bug. walletmodel.cpp:338 05:40 < morcos> i'm just going to do a quick scan for other occurences and then PR a fix 06:02 < jonasschnelli> morcos: great! Thanks. 06:03 < bitcoin-git> [bitcoin] morcos opened pull request #9296: Fix missed change to WalletTx structure (master...fixwallettx) https://github.com/bitcoin/bitcoin/pull/9296 06:04 < morcos> wumpus: we should get a quick review of 9296 and merge that or whatever the correct fix is 06:04 < morcos> Since anyone using master will have transactions committed and then crash, it could inadverntantly lead to multiple payments or something 06:05 < jonasschnelli> MarcoFalke: Oops, I think i change the tags you made on https://github.com/bitcoin/bitcoin/pull/9295 06:06 < MarcoFalke> The milestone says what is the lowest version the patch should go to. 06:06 < jonasschnelli> morcos: we haven't really discussed #8501... 06:06 < gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub 06:06 < morcos> I panicked a little because I thought it was potentially corrupting the wallet at first, but what is getting committed to the wallet is fine, it was just serialization for the GUI that was messed up.. 06:06 < MarcoFalke> So "needs backport" and "0.14.0" does not make sense :) 06:06 -!- laurentmt [~Thunderbi@80.215.138.113] has joined #bitcoin-core-dev 06:07 < morcos> jonasschnelli: yes, i left a few comments on irc yesterday re: 8501. 06:07 -!- laurentmt [~Thunderbi@80.215.138.113] has quit [Client Quit] 06:07 < jonasschnelli> morcos: I think there can be a problem with storing to many timestamp... is that what you thought? 06:08 < morcos> it just seemed to me that the idea of storing 1000 seconds, 1000 minutes, 1000 hours and 1000 days (with no time stamps) is perfectly adequate for any stat, but maybe not? (or 2000) 06:08 < jonasschnelli> Yes. But that would required fix frequency and active lock occupy. Not? 06:08 < morcos> i think the question would be what to do if some number of seconds go by before you record a new data point... i would argue that you want to differentiate between recording a repeated data point and not updating the stat 06:09 < morcos> jonasschnelli: not the way i'm imagining it 06:09 < morcos> lets say you had a way to indicate no value recorded. 06:10 < jonasschnelli> morcos: Yes. But I guess you still blow memory up to the size of the samples structure?... 06:10 < morcos> and look for a moment and the 1000 seconds data points... you have a circular buffer of 1000 entries 06:10 < morcos> and every time you call it, say you call it 17 seconds later.. you put in 16 NA's and then the latest data point 06:10 < morcos> so then graphing can be smart about interpolating 06:10 < jonasschnelli> hm... 06:11 < morcos> but if you call it every second with the same data point, it would put it in , you would distinguish between a step function and slow increase 06:11 < jonasschnelli> So you would not care if the 17second samples was done at 17.5s? 06:11 < morcos> yes, it would use constant memory 06:11 < morcos> but not that much 06:11 < morcos> a few MB 06:12 < jonasschnelli> I think the possible time offset could matter at the 1000 hours circular buffer. 06:12 < morcos> right, so you'd have to figure out how to cover that.. but i think thats doable.. suppose the data point for 12:14:16 means the latest data point that you have before 12:14:16.00000000 06:12 < jonasschnelli> Assume sample 1 was done at 0h, sample 2 and 0.6h (=1h sample), sample three at 1.4. 06:13 < jonasschnelli> What speaks against storing a sample with a delta timestamp (1byte) to the last sample? 06:13 < jonasschnelli> Could be something like a linked list with NA's 06:13 < jonasschnelli> *linked list 06:13 < morcos> then if you call it at 14.93 (that goes in the 12:14:15 data point) then you save just the latest call every time if you call it at 15.03, 15.37, 15.87, and then when you call it at 16.05, you put the 15.87 data point in for 12:14:16 06:14 < morcos> i think you could also do linked lists with delta time stamps, but i think the delta time stamps don't add much 06:15 < morcos> i guess i'm envisioning that for things with 1h samplign or 1day sampling you'll be calling it much more frequently anyway 06:15 < jonasschnelli> Maybe the advantage of delta timestamps is: more accurate (no interpolation in the recorded data), flexible memory cap- 06:15 < morcos> so you'll get a data point pretty close to the cut off 06:16 < jonasschnelli> sipa once had the idea to remove in-between samples once they are old and stats-memory gets drained. 06:16 < morcos> but are you envisioning that the part of the program thats making the call to record the sample is doing it separately for each timescale? 06:17 < morcos> well the design i'm trying to describe would never even keep "in-between" samples 06:17 < jonasschnelli> morcos: IMO the stats infrastructure should not actively record stuff. It should offer an interface to store records based 06:17 < morcos> yes, i understand 06:17 < jonasschnelli> "in-between" samples is probably the wrong term. Sorry. 06:17 < morcos> so in your mempool code, you call stats.record(SomeStats) 06:17 < jonasschnelli> Let's assume you record samples in a 1s frequency... 06:17 < jonasschnelli> then you reserved stats memory gets low 06:17 < morcos> but i'm saying that you can then record those however often you want from the mempool 06:17 < jonasschnelli> You could remove some of the old 1s samples... 06:18 < morcos> and the stats class will save the last 1000 seconds, 1000 mins, 1000 hrs and 1000 days of data poitns for you 06:18 < morcos> it removes the old 1s samples b/c its a circular buffer 06:18 < jonasschnelli> Yes. But maybe someone once to keep 1s stats longer.. in 8501 I introduces a -statsmaxmemory 06:19 < morcos> ok, well that was my argument, is that no one would care about keeping 1s stats for longer than say 1000 or 2000 secs 06:19 < morcos> if they wanted to look at a longer time period, they would look at minutes 06:19 < jonasschnelli> Thats a point. Right 06:19 < morcos> if that is false, then i agree 06:20 < jonasschnelli> My experience tells me, record as much as possible, :-) 06:20 < jonasschnelli> I would even say a stats to disk dumper would be great 06:20 < jonasschnelli> Especially stuff that can't be reconstructred 06:20 < jonasschnelli> (freerates, etc.) 06:21 < morcos> the concern i had about your design was that if we are recording lots of stats 06:21 < morcos> then we lose the ability to look over a long time period without using tons of memory 06:21 < morcos> i don't really care how we do it 06:21 < jonasschnelli> Yes. That is not done well in 8501 06:21 < morcos> but i think the stats class should automatically keep less fine-grained data for a longer time in order to keep the memory limited 06:21 < morcos> i was just presenting one way to do that 06:22 < jonasschnelli> The idea was to slowly stretch the frequency over time, depending on the available stats ram. 06:22 < jonasschnelli> Not just cut the back 06:22 < morcos> but don't you think you might want to look at both? 06:22 < jonasschnelli> Yes. 06:22 < morcos> high frequency recent and low frequency long time horizon 06:22 < morcos> ok... so thats my goal... 06:22 < jonasschnelli> I think you convinced me to do the 1000s 1000m 1000h 1000d approach. 06:23 < jonasschnelli> maybe the 1000 is configurable. 06:23 < morcos> doesn't matter to me how we do it... i think a delta version coudl be just as good 06:23 < morcos> and you could just be smart about trimming the delta list or something 06:23 < morcos> yes, 1000 should be configurable i thik... actually maybe isn't enough for a default 06:23 < jonasschnelli> also, I liked the configurability of the buffer in MB. 06:23 < jonasschnelli> That's what you probably care about. 06:23 < jonasschnelli> Not the 1000 06:24 < morcos> 1000 secs is just 16 minutes... you would not want to have to only have 16 data points 06:24 < jonasschnelli> You would say, I reserve 300MB for stats. 06:24 < jonasschnelli> Right... just en 06:24 < jonasschnelli> just as an example 06:25 < jonasschnelli> So,.. you convinced me for high frequency recent and low frequency long time horizon,... 06:25 < morcos> ok cool... any approach that automatically keeps both recent fine-grained and long time horizon bigger step, is fine with me 06:25 < jonasschnelli> And I think the delta timeoffset thing could work. 06:25 < morcos> thanks 06:25 < jonasschnelli> It can be tricky if you cut sample not at the back 06:25 < jonasschnelli> You need to re-adjust the delta. 06:26 < jonasschnelli> Losing a sample will corrupt the timestream 06:26 < morcos> i'll let you worry about that. :) 06:26 < jonasschnelli> heh. 06:27 < jonasschnelli> Yes. I try to overhaul 8501 06:27 < jonasschnelli> But lets first fix Bitcoin 06:42 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e15660c16f75...fde7d99c4d7d 06:42 < bitcoin-git> bitcoin/master 28f8ae8 Alex Morcos: Fix missed change to WalletTx structure 06:42 < bitcoin-git> bitcoin/master fde7d99 Wladimir J. van der Laan: Merge #9296: Fix missed change to WalletTx structure... 06:42 < bitcoin-git> [bitcoin] laanwj closed pull request #9296: Fix missed change to WalletTx structure (master...fixwallettx) https://github.com/bitcoin/bitcoin/pull/9296 06:46 -!- laurentmt [~Thunderbi@80.215.138.113] has joined #bitcoin-core-dev 06:46 -!- laurentmt [~Thunderbi@80.215.138.113] has quit [Client Quit] 06:54 < kanzure> reproducible builds for windows https://github.com/jasonwhite/ducible 07:02 < timothy> kanzure: you can still build using mingw32 on linux :P 07:03 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 07:41 -!- protomar [~protomar@91.214.169.69] has quit [Quit: Leaving] 07:45 -!- JackH [~laptop@79-73-189-171.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 07:52 -!- abpa [~abpa@2602:306:b837:dbf0:d8d9:65fd:3bcc:8671] has joined #bitcoin-core-dev 07:54 -!- abpa [~abpa@2602:306:b837:dbf0:d8d9:65fd:3bcc:8671] has quit [Client Quit] 07:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hrtfvqbyuzvtouxw] has quit [Quit: Connection closed for inactivity] 07:58 -!- laurentmt [~Thunderbi@80.215.138.113] has joined #bitcoin-core-dev 08:05 -!- laurentmt [~Thunderbi@80.215.138.113] has quit [Quit: laurentmt] 08:09 < instagibbs> is there a written down explanation of the lock macros anywhere 08:10 -!- limpkin [sid20909@gateway/web/irccloud.com/x-frukujvobiddjahi] has quit [] 08:11 -!- limpkin [sid20909@gateway/web/irccloud.com/x-xqsryradyxysstov] has joined #bitcoin-core-dev 08:25 -!- echonaut8 [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 08:25 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 08:31 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 08:32 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer] 08:33 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 08:39 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 08:42 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 248 seconds] 08:42 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:48 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:55 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 09:32 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer] 09:33 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 09:40 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:40 < Chris_Stewart_5> sipa: re: yesterdays convo about syncing, seems like another guy had a similar experience that I did in #bitcoin, not sure if this is a concern or not 09:45 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 09:50 < sipa> Chris_Stewart_5: that sync is slow? of course it is a concern 09:50 < sipa> but we can't just go double our memory requirements 09:54 < gmaxwell> the speeds Chris_Stewart_5 were reporting sounded reasonably slow, but yes-- the processing is slowing down as the chain grows and will continue to do so. 09:54 < gmaxwell> We have been fighting that effect for years and will continue to do so, but nothing changes the fact that more state means more work. 09:54 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 10:02 < Chris_Stewart_5> gmaxwell: Yes, I was wondering if this was average or extremely slow. I thought I read something about it being on the order of magnitude of 12 hours -- everything you read online is accurate right? :P 10:05 -!- atroxes_ [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 10:08 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer] 10:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 10:08 < owowo> I synced today, was about 4k block behind, but it was quite fast. 10:09 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Quit: bye] 10:09 -!- atroxes_ is now known as atroxes 10:25 -!- protomar [~protomar@91.214.169.69] has joined #bitcoin-core-dev 10:32 -!- protomar [~protomar@91.214.169.69] has quit [Quit: Leaving] 10:38 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vycnrhpbkmicpgiw] has joined #bitcoin-core-dev 10:40 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 260 seconds] 11:04 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 11:12 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 250 seconds] 11:15 -!- TomMc [~tom@unaffiliated/tommc] has quit [Quit: WeeChat 1.4] 11:19 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:20 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 11:33 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev 11:34 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds] 11:42 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has quit [Remote host closed the connection] 11:47 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 250 seconds] 11:52 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Read error: Connection reset by peer] 11:52 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 11:53 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev 11:57 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Ping timeout: 260 seconds] 11:59 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 12:03 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 12:15 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Quit: bye] 12:16 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 12:55 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye] 12:58 < morcos> gmaxwell: can we duel about SelectCoinsMinConf(.., #ancestors, ..)? 12:58 < morcos> both sdaftuar and i think that the most important thing for your goal is to try low values for number of ancestors 12:59 < morcos> and lets for the moment just worry abou tthe devault limit of 25... then you are suggesting 1,6,13,25 13:01 < morcos> sorry 0,6,13,25 (eh, 0 or 1 doesn't mean anything anyway though b/c you skip anything >= n and everything has at least 1 , it counts itself) 13:02 < morcos> so i think emphasizing more tries in the low limits helps keep any individual chain small and therefore helps avoid polluting small chains by combining them with big ones 13:03 < morcos> so trying 2,3,4,25 might even be better than 2,6,13,25 13:03 < morcos> anyway thats the tradeoff sdaftuar and i were trying to suggest, emphasize trying the low numbers 13:04 < gmaxwell> morcos: I agree with you, I didn't perform that bit of shed painting myself because I didn't think it mattered _that_ much. The only reason I commented there was because instagibbs changed it in a way that was clearly wrong for some values. :) 13:04 < morcos> yeah but all it is is a bit inefficient for not default limits 13:04 < morcos> no one has non-default limits 13:04 < morcos> who cares 13:05 < morcos> its not broken 13:05 < gmaxwell> I don't care about inefficient, but when he changed the patch he harcoded one to 3 which could be higher than your limit. 13:05 < morcos> but that doesn't hurt anything 13:06 -!- ville-- [~ville@xollo.net] has quit [Quit: Reconnecting] 13:06 < gmaxwell> say you've set your limit to two, it will cause you to go past it. 13:06 -!- ville-- [~ville@xollo.net] has joined #bitcoin-core-dev 13:06 < morcos> it just lets you potentially pick coins which will let you create a tx which will fail the final test.. thats already a possibility anyway.. 13:07 -!- ville-- [~ville@xollo.net] has quit [Client Quit] 13:07 -!- ville- [~ville@xollo.net] has joined #bitcoin-core-dev 13:07 < morcos> the actual test is way more restrictive, none of your ancestors can have more than the descendant limit 13:08 < gmaxwell> Personally, if I wrote it, I would have done 1,2,3,max-2,max-1,max or something like that. 13:08 < morcos> we're nto checking that in this quick heuristic anyway 13:08 < morcos> so you always might be picking coins with which you have no chance , you just don't know 13:08 < morcos> but better to have multiple tries with things which have a good heuristic 13:08 < gmaxwell> you might be, but that isn't the pratical case people are encountering. 13:09 < gmaxwell> I don't know where we disagree. 13:09 < morcos> mostly i think its fine as is, and your suggestion is a slight downgrade.. but i agree its mostly bikeshedding i suppose 13:10 < gmaxwell> hm. if the limit is set to 2.. why should it check 3? would you agree that min(3,limit) wouldn't be better? 13:11 < morcos> sure 13:11 < gmaxwell> I think it absolutely should spend more tries on low numbers, because say it runs with limit/4, then it combines two inputs a depth 2 and a depth limit/2 .. great, now you've just trashed a short chain. 13:12 < morcos> exactly 13:13 < gmaxwell> but for that e.g. spacing my a multiplicave factor at least won't screw you by more than that factor. 13:13 < morcos> i'm fine adding a min, i just think making it work well for a limit of 25 is fine, as long as its not horribly broken for other limits, which it wont' be b/c it'll still try 2 first 13:13 < gmaxwell> okay we agree then. 13:14 < morcos> 2, min(4,limit), something in between, limit 13:14 < morcos> :) 13:18 < gmaxwell> I posted min(2,limit/4), min(4, limit/3), limit/2 13:18 < gmaxwell> , limit 13:18 < instagibbs> is it safe to come out of my bikeshelter :) 13:18 < sipa> cfields: i've been playing with -flto lately, and you can use -flto=jobserver at link time to make gcc itself perform the linking step in multiple processes... the problem is that this requires prefixing the compiler invocation in make with a '+' so make knows to expose its jobserver interface to it 13:18 < gmaxwell> instagibbs: haha 13:18 < sipa> cfields: any idea how to accomplish that in automake. it doesn't seem that CXX="+g++" works 13:19 < gmaxwell> morcos: I really try to not bikeshed this stuff too much, because it's just a hop-skip-and-jump away from arguing that we should be linking GLPK. 13:20 < morcos> heh 13:20 < morcos> well sdaftuar and i played around with testing the PR, and it kind of performed poorly 13:20 < morcos> if you started with two inputs 13:21 < morcos> instead of getting 50 txs, you only got 30 (whereas before you got 25) 13:21 < morcos> this was because we were sending to ourselves so the outputs were being combined quickly and we were trashing chains, so led us to prefer this small change approach.. obviously as sdaftuar reported, it works much better when the test doesn't pay yourself 13:22 < morcos> s/small change approach/emphasis on small limits approach/ 13:23 < gmaxwell> I'm glad you tested it-- I anticipated that result but I was trying to resist bikesheding it and making it not go into 0.13.2. 13:24 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 13:24 < morcos> i thik with a large set of coins though , it'll really shine as it'll stop you from just being stupid 13:25 < morcos> btw, it would be helpful for me if more people went through and tagged things for 0.14, i could review some more things, and would like to know where to concentrate... 13:25 < morcos> i think i've done what i can on the existing milestones 13:26 < instagibbs> ok, putting final touches on the selection, thanks for all the feedback 13:26 < instagibbs> (also am I the only one getting spammed to hell by phising PMs?) 13:27 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Quit: Ex-Chat] 13:27 < gmaxwell> instagibbs: yes.. you can /mode instagibbs +R to turn off pms from unregistered users. 13:28 < instagibbs> ah thx 13:28 < gmaxwell> remember to turn it back off again later, if you want j-random-people to pm you later. 13:28 < sipa> what about j-invariant-people? 13:30 < gmaxwell> sipa: thats complex. 13:33 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fde7d99c4d7d...09c4fd157c5b 13:33 < bitcoin-git> bitcoin/master 9b9324e Matt Corallo: Fix rounding privacy leak introduced in #9260 13:33 < bitcoin-git> bitcoin/master 09c4fd1 Pieter Wuille: Merge #9268: Fix rounding privacy leak introduced in #9260... 13:33 < bitcoin-git> [bitcoin] sipa closed pull request #9268: Fix rounding privacy leak introduced in #9260 (master...2016-12-feefilterrounder) https://github.com/bitcoin/bitcoin/pull/9268 13:55 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 13:58 -!- grubles_ [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 13:58 -!- grubles_ [~grubles@unaffiliated/grubles] has quit [Remote host closed the connection] 14:18 -!- wvr [~wvr@0.red-88-15-41.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 14:19 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Quit: conversation terminated!] 14:35 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- The alternative IRC client] 14:40 -!- LeMiner [~LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev 15:00 -!- tmkexpress [~tmkexpres@199.195.192.130] has joined #bitcoin-core-dev 15:11 -!- MarcoFalke [~marco@5.199.182.203] has left #bitcoin-core-dev [] 15:26 < bitcoin-git> [bitcoin] Mirobit opened pull request #9297: Various RPC help outputs updated (master...rpchelp12/16) https://github.com/bitcoin/bitcoin/pull/9297 15:54 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 16:26 -!- JackH [~laptop@79-73-189-171.dynamic.dsl.as9105.com] has quit [Remote host closed the connection] 16:36 -!- tmkexpress [~tmkexpres@199.195.192.130] has quit [Quit: Leaving] 16:37 -!- wvr [~wvr@0.red-88-15-41.dynamicip.rima-tde.net] has quit [] 16:51 -!- AdrianG [~User@unaffiliated/amphetamine] has quit [Quit: leaving] 16:51 -!- AdrianG [~User@unaffiliated/amphetamine] has joined #bitcoin-core-dev 16:52 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 16:53 -!- AdrianG is now known as Aleph0 17:07 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 265 seconds] 17:15 -!- shaiguit1r [~rosenfs@shairosenfeld.com] has joined #bitcoin-core-dev 17:17 -!- jeremias [~jeremias@kangasbros.fi] has quit [Ping timeout: 256 seconds] 17:17 -!- jeremias [~jeremias@kangasbros.fi] has joined #bitcoin-core-dev 17:17 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has quit [Ping timeout: 256 seconds] 17:17 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has joined #bitcoin-core-dev 17:18 -!- shaiguitar [~rosenfs@shairosenfeld.com] has quit [Ping timeout: 256 seconds] 17:22 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 17:22 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 17:22 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 17:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 17:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 17:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vycnrhpbkmicpgiw] has quit [Quit: Connection closed for inactivity] 17:30 -!- echonaut8 [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 17:30 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 17:33 -!- e4xit_ [~e4xit@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Ping timeout: 256 seconds] 17:42 -!- e4xit [~e4xit@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev 17:53 -!- Atomicat [~Atomicat@unaffiliated/atomicat] has quit [Ping timeout: 250 seconds] 17:58 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 18:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 19:08 -!- abpa [~abpa@107-131-125-191.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 19:10 < bitcoin-git> [bitcoin] gmaxwell closed pull request #9286: Time-based expiration in LimitOrphanTxSize only when map is full. (master...defer_orphan_exp) https://github.com/bitcoin/bitcoin/pull/9286 19:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 19:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 19:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 19:59 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 20:05 -!- shaiguit1r [~rosenfs@shairosenfeld.com] has quit [Remote host closed the connection] 20:05 -!- shaiguitar [~rosenfs@shairosenfeld.com] has joined #bitcoin-core-dev 20:42 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.5] 20:43 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 20:50 -!- abpa [~abpa@107-131-125-191.lightspeed.sntcca.sbcglobal.net] has quit [Read error: Connection reset by peer] 21:14 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 260 seconds] 21:15 -!- ensign [~ensign@2001:41d0:8:d711::1] has quit [Ping timeout: 260 seconds] 21:15 -!- nOgAnOo [sid146237@gateway/web/irccloud.com/x-qzaxushlbdelzugi] has quit [Ping timeout: 260 seconds] 21:15 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-ejmuztsevtenzywj] has quit [Ping timeout: 260 seconds] 21:15 -!- Taek42 [~quassel@2001:41d0:1:472e::] has joined #bitcoin-core-dev 21:15 -!- nsh [~lol@wikipedia/nsh] has quit [Ping timeout: 260 seconds] 21:16 -!- cfields [~quassel@unaffiliated/cfields] has quit [Ping timeout: 260 seconds] 21:16 -!- Taek [~quassel@2001:41d0:1:472e::] has quit [Ping timeout: 260 seconds] 21:16 -!- lesderid [~lesderid@anna.lesderid.net] has quit [Ping timeout: 260 seconds] 21:16 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-zebjclicuxzslxwa] has joined #bitcoin-core-dev 21:18 -!- cfields [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev 21:19 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 21:19 -!- harrymm [~wayne@104.237.91.137] has joined #bitcoin-core-dev 21:20 -!- nOgAnOo [sid146237@gateway/web/irccloud.com/x-bdekthemjvlvcjsu] has joined #bitcoin-core-dev 21:21 -!- lesderid [~lesderid@anna.lesderid.net] has joined #bitcoin-core-dev 21:38 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds] 22:20 -!- cheese_ [~x@unaffiliated/cheeseo] has quit [Ping timeout: 268 seconds] 22:21 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 250 seconds] 22:27 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 22:31 -!- paracyst [paracyst@unaffiliated/paracyst] has quit [Ping timeout: 244 seconds] 22:32 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 244 seconds] 22:33 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 22:36 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 244 seconds] 22:36 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 22:36 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 22:36 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 22:55 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev 23:04 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 23:04 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has quit [Changing host] 23:04 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 23:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tlwezsootaphqfli] has joined #bitcoin-core-dev 23:09 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 245 seconds] 23:09 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 23:13 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 268 seconds] 23:13 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 23:13 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 23:13 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 23:15 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 23:42 -!- gurwinder [4c440984@gateway/web/freenode/ip.76.68.9.132] has joined #bitcoin-core-dev 23:44 -!- wvr [~wvr@0.red-88-15-41.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 23:47 -!- gurwinder [4c440984@gateway/web/freenode/ip.76.68.9.132] has quit [Ping timeout: 260 seconds] 23:53 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]