1 2016-09-17 00:14:12	0|GitHub128|[13bitcoin] 15pstratem closed pull request #8585: [Wallet] Move IncOrderPosNext to CWallet::AddAccountingEntry (06master...062016-08-24-cwallet-incorderposnext) 02https://github.com/bitcoin/bitcoin/pull/8585
  2 2016-09-17 01:11:37	0|phantomcircuit|sipa: so they're not compatible with each other?
  3 2016-09-17 01:11:44	0|phantomcircuit|that's weird
  4 2016-09-17 01:16:12	0|sipa|phantomcircuit: every c++03 valid program is valid in c++11
  5 2016-09-17 01:16:33	0|sipa|because >> in templates can never be correctly interpreted as a shift
  6 2016-09-17 02:04:05	0|phantomcircuit|sipa: ok
  7 2016-09-17 02:05:04	0|phantomcircuit|sipa: can you check 8695
  8 2016-09-17 02:11:29	0|midnightmagic|lol is it my imagination or has gdb actually gotten worse for c++ over time
  9 2016-09-17 02:11:51	0|midnightmagic|what do people use these days to debug coredumps and running C++ programs?
 10 2016-09-17 02:12:57	0|sipa|gdb has gotten a lot better over timr
 11 2016-09-17 02:13:06	0|sipa|you can now inspect vector elements etc
 12 2016-09-17 02:15:03	0|sipa|phantomcircuit: yes yes, when i get back
 13 2016-09-17 02:24:08	0|midnightmagic|sort of.
 14 2016-09-17 02:24:52	0|midnightmagic|$foo.genesis.vtx._M_impl._M_start.vout._M_impl._M_start.scriptPubKey.begin() ?
 15 2016-09-17 02:24:55	0|midnightmagic|:-/
 16 2016-09-17 02:27:23	0|midnightmagic|or do you mean the pretty-printer that doesn't describe the actual data structure elements in a way that can be references without tab-completion (which only in like 2015/16 got the surprise-you-have-to-wait-for-a-global-million-member-search fix)
 17 2016-09-17 02:28:15	0|midnightmagic|(which means almost no machines with gdb installed have it yet)
 18 2016-09-17 02:35:42	0|sipa|midnightmagic: i mean foo[0]
 19 2016-09-17 02:42:17	0|phantomcircuit|midnightmagic: printf
 20 2016-09-17 03:16:39	0|jl2012|luke-jr: I just chose "don't show my email address"
 21 2016-09-17 03:16:52	0|jl2012|updated
 22 2016-09-17 03:17:20	0|jl2012|luke-jr, sipa: I found it. It's not STRICTENC, it's part of IsStandardTx
 23 2016-09-17 03:17:44	0|jl2012|the SIGPUSHONLY flag is not used
 24 2016-09-17 03:28:55	0|luke-jr|jl2012: kinda ugly to affect git like that
 25 2016-09-17 03:33:32	0|jl2012|luke-jr: it's github's function
 26 2016-09-17 03:33:48	0|jl2012|i didn't pay attention to that
 27 2016-09-17 04:05:04	0|midnightmagic|:-/ printf won't give me a pretty-printed struct dump!
 28 2016-09-17 04:10:11	0|sipa|how recent is your gdb?
 29 2016-09-17 04:36:45	0|NicolasDorier|It would also make database corruption less likely, as a corruption would be only possible if bitcoind savagely quit just when the patch is applied to the disk.
 30 2016-09-17 04:36:45	0|NicolasDorier|patch, it would consume no IO at all.
 31 2016-09-17 04:36:45	0|NicolasDorier|sipa: Have you tried to limit disk access by not writing on disk every time you validate a block ? The idea would be that we can skip lots of IO by caching in RAM an ongoing patch to the UTXO DB that we commit only once every hour during IBD or if there is memory pressure. I think we can skip some IO because if a UTXO is opened and closed during the same
 32 2016-09-17 04:37:29	0|sipa|NicolasDorier: we don't write to the utxo set frequently
 33 2016-09-17 04:37:53	0|NicolasDorier|ah so you are already doing that ? :(
 34 2016-09-17 04:37:57	0|sipa|depending on your dbcache setting you can do full validation from scratch without ever writing to the chainstate
 35 2016-09-17 04:38:04	0|sipa|yes, it's a massive speedup
 36 2016-09-17 04:38:13	0|sipa|we've been doing that since 0.8
 37 2016-09-17 04:38:31	0|NicolasDorier|I thought dbcache was only for read from chainstate
 38 2016-09-17 04:38:33	0|NicolasDorier|not writing
 39 2016-09-17 04:39:02	0|sipa|it's both
 40 2016-09-17 04:39:34	0|sipa|if a utxo entry is spent before being written to disk, it can be completely dropped, and will never even touch disk
 41 2016-09-17 04:40:46	0|NicolasDorier|interesting thanks, I thought that things were written to disk every block
 42 2016-09-17 04:45:28	0|sipa|with default settings it's maybe written every few dozen to a hundred blkcks
 43 2016-09-17 05:14:06	0|midnightmagic|sipa: 7.7.1-0ubuntu5 :-( so, a bit older I guess. Don't mind me, I'm just griping. :)
 44 2016-09-17 06:06:56	0|rebroad|I'd like to talk about Whitelisted nodes
 45 2016-09-17 06:07:22	0|rebroad|I have a bunch of changed I'd like to work on but before I can there appears there needs to be some clarity on what a whitelisted node is supposed to be
 46 2016-09-17 06:07:30	0|rebroad|changes
 47 2016-09-17 06:07:50	0|rebroad|for example, I'd like to make a change that says if a whitelisted node says a block is good then that block is treated as checkpointed
 48 2016-09-17 06:08:03	0|rebroad|saving CPU for the node catching up
 49 2016-09-17 06:08:35	0|rebroad|should I create a new category of node called "trusted" node, or would it be the same thing?
 50 2016-09-17 06:12:06	0|rebroad|luke-jr, thanks for the cc earlier (just noticed it, irc didn't highlight it for some reason)... did I miss some conversation previously? you seemed to be replying to sipa but I didn't see any talk about printf between my question and that response from you.
 51 2016-09-17 06:15:11	0|gmaxwell|rebroad: we would not accept bypassing validation. It would hardly make things faster in the common case, and it would drastically increase the risk of corruption or misconfiguration turning into contagion that casues massive outages.
 52 2016-09-17 06:15:49	0|gmaxwell|you should assume all the checkpoint whatever will be removed in the next couple major revisions.
 53 2016-09-17 06:16:13	0|gmaxwell|they're largely rendered pointless by prior software improvements.
 54 2016-09-17 06:17:59	0|gmaxwell|the whitelisting is intended to bypass resource limits, for cases where trigger happy anti-dos rules might isolate or slow down a node of your own from its gateway to the outside world.
 55 2016-09-17 06:18:39	0|gmaxwell|(the intended usage is primarily that-- nodes that act as gateways for other nodes of your own which can't directly access the outside world)
 56 2016-09-17 06:19:07	0|rebroad|gmaxwell, if someone was running multiple nodes over a VPN for example... would they not want to reduce their overall CPU usage by letting the nodes share the work of validation though?
 57 2016-09-17 06:19:44	0|rebroad|gmaxwell, VLAN i meant to say
 58 2016-09-17 06:19:56	0|gmaxwell|because it wouldn't avoid any at runtime. When a node is running almost all the transactions are verified and cached long before the block shows up. The cpu spent when the block shows up is all hashing and database manipulation which can't be avoided.
 59 2016-09-17 06:20:19	0|rebroad|gmaxwell, I'm speaking of an IBD situation
 60 2016-09-17 06:20:28	0|gmaxwell|and beyond that, why even run multiple nodes when any disfunction/corruption/misconfiguration will silently spread and corrupt between them.
 61 2016-09-17 06:21:08	0|rebroad|gmaxwell, if we're talking IBD then the validation could at least be saved
 62 2016-09-17 06:21:32	0|rebroad|gmaxwell, or is that negligable compared with the hashing and database manipulation?
 63 2016-09-17 06:22:02	0|rebroad|gmaxwell, I guess for IBD specifically then you are going to suggest rsync as a better way :)
 64 2016-09-17 06:22:19	0|gmaxwell|Not compeltely negligible, but it's not so great anymore with libsecp2561k... and even that still can get another 20% faster.. and on hosts with many cores other upcoming changes will make that part a couple times faster.
 65 2016-09-17 06:22:34	0|gmaxwell|I suppose rsync is an option too and _much_ faster.
 66 2016-09-17 06:22:36	0|rebroad|gmaxwell, good to hear. thanks
 67 2016-09-17 06:22:48	0|gmaxwell|NP.
 68 2016-09-17 06:22:51	0|gmaxwell|(no problem)
 69 2016-09-17 06:23:06	0|rebroad|gmaxwell, I am not up to speed on the overall roadmap of core.. I have seen the scaling roadmap, but is there an overall roadmap?
 70 2016-09-17 06:23:37	0|gmaxwell|The roadmap is what people will actually work on, largely.
 71 2016-09-17 06:24:11	0|gmaxwell|there are many things which people would like to, I'd suggest reading through the bitcoin core zurich meeting notes for things people are working on/planning on working on.
 72 2016-09-17 06:24:41	0|rebroad|assumption
 73 2016-09-17 06:24:41	0|rebroad|gmaxwell, also, hope my comment to your issue on BU was ok - I was thinking that perhaps they were of the mindset that SegWit might be unlikely to happen/fork, so was trying to pre-empt that possible assumption (Which might lead to them not even responding).. plus I think it's valid question - there does appear to be an assumption that SegWit will happen, but I'm not so far aware of the information behind that
 74 2016-09-17 06:25:42	0|rebroad|gmaxwell, I'd like to read those notes - where would I find them please?
 75 2016-09-17 06:26:03	0|rebroad|luke-jr, ah.. it only highlights me to messages that start with rebroad it would seem
 76 2016-09-17 06:26:06	0|gmaxwell|google, sorry, I can't really provide links right now. Don't have a working pointing device.
 77 2016-09-17 06:26:42	0|rebroad|gmaxwell, you have your finger but you're lacking the interface to your current working pointing devices ;)
 78 2016-09-17 06:27:22	0|gmaxwell|rebroad: response to me from discussion on the lists and with many users tells me that it will be activate for certian. If not, I don't much care, but I don't want anyone to be unnecessarily left behind.
 79 2016-09-17 06:27:41	0|luke-jr|rebroad: I don't recall the conversation. sipa replied to you across 4 or 5 lines, which I was adding to
 80 2016-09-17 06:28:08	0|gmaxwell|luke-jr: if you could find the transcribe for rebroad that would be really helpful.
 81 2016-09-17 06:28:33	0|rebroad|luke-jr, oh.. for some reason it's not showing up in my window (sipa's response)...  erm.. might you be able to point me towards the archive of the logs so I can try to find his reponse? weird.. my computer has been connected between my question and your reply..
 82 2016-09-17 06:28:46	0|luke-jr|gmaxwell: not easily unfortunately; about to board leg 2 of 3
 83 2016-09-17 06:29:00	0|luke-jr|rebroad: /topic
 84 2016-09-17 06:29:15	0|rebroad|luke-jr, /topic?
 85 2016-09-17 06:29:42	0|luke-jr|rebroad: the logs are linked in the channel "topic"
 86 2016-09-17 06:29:59	0|luke-jr|typically at the top of the window
 87 2016-09-17 06:30:23	0|rebroad|luke-jr, gmaxwell I am fascinated to know what you are travelling so much for... I am wondering if perhaps I might attend the meetup in Milan
 88 2016-09-17 06:31:14	0|rebroad|luke-jr, gmaxwell not meaning to imply I'm at your level of expertise or anything (I know I am not)
 89 2016-09-17 06:31:52	0|luke-jr|i think this was zurich: https://bitcoincore.org/en/meetings/2016/05/20/
 90 2016-09-17 06:32:37	0|rebroad|found the logs (https://botbot.me/freenode/bitcoin-core-dev/)
 91 2016-09-17 06:32:49	0|rebroad|luke-jr, ah, thanks
 92 2016-09-17 06:33:53	0|gmaxwell|rebroad: I didn't respond to you on the BU github before because when I tried to reply I got a red "You can't comment here at this time." box. I tried again just now and it worked.
 93 2016-09-17 06:34:04	0|luke-jr|rebroad: I do consulting for various Bitcoin stuff, but I try to minimise travel even then :p
 94 2016-09-17 06:34:35	0|gmaxwell|rebroad: Many people would love to see you in milan. Though I think it's sold out right now.
 95 2016-09-17 06:35:59	0|luke-jr|bbl
 96 2016-09-17 06:36:03	0|rebroad|gmaxwell, ok, was not expecting that response. well, there may be other opportunities. please feel free to let me know of future opportunities - I do feel I've not been communicating well, and I know from experience that I come across to people much better in person
 97 2016-09-17 06:37:01	0|rebroad|gmaxwell, also my workflow is pretty terrible and could do with some refinement - I would rather not be submitting commits that don't compile/run correctly :-s
 98 2016-09-17 06:37:11	0|gmaxwell|The same is true for many of us.
 99 2016-09-17 06:37:21	0|gmaxwell|:)
100 2016-09-17 06:37:31	0|rebroad|lol , you backgrounded your outness
101 2016-09-17 07:07:26	0|btcdrak|ping rebroad
102 2016-09-17 07:07:33	0|rebroad|LOLing at this channels chat logs from March 23rd :)
103 2016-09-17 07:07:37	0|rebroad|hi btcdrak
104 2016-09-17 07:07:44	0|btcdrak|hi, PM
105 2016-09-17 09:55:18	0|GitHub88|[13bitcoin] 15MarcoFalke opened pull request #8750: [qa] Refactor RPCTestHandler to prevent TimeoutExpired (06master...06Mf1609-qaRefactorTimeout) 02https://github.com/bitcoin/bitcoin/pull/8750
106 2016-09-17 11:04:01	0|rebroad|cfields, just heard you are working on refactoring the p2p code... may I have a look? I have various improvements I've been working on since 2012 which I think will help, primarily with IBD
107 2016-09-17 15:45:01	0|GitHub101|[13bitcoin] 15afk11 opened pull request #8751: RPC: Add parameter to addmultisigaddress / createmultisig to sort public keys (06master...06sort-multisigs) 02https://github.com/bitcoin/bitcoin/pull/8751