< 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)
< midnightmagic>
(which means almost no machines with gdb installed have it yet)
< * midnightmagic>
gripes
< sipa>
midnightmagic: i mean foo[0]
< phantomcircuit>
midnightmagic: printf
< jl2012>
luke-jr: I just chose "don't show my email address"
< jl2012>
updated
< jl2012>
luke-jr, sipa: I found it. It's not STRICTENC, it's part of IsStandardTx
< jl2012>
the SIGPUSHONLY flag is not used
< luke-jr>
jl2012: kinda ugly to affect git like that
< jl2012>
luke-jr: it's github's function
< jl2012>
i didn't pay attention to that
< midnightmagic>
:-/ printf won't give me a pretty-printed struct dump!
< sipa>
how recent is your gdb?
< 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
< NicolasDorier>
patch, it would consume no IO at all.
< 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.
< sipa>
NicolasDorier: we don't write to the utxo set frequently
< NicolasDorier>
ah so you are already doing that ? :(
< sipa>
depending on your dbcache setting you can do full validation from scratch without ever writing to the chainstate
< sipa>
yes, it's a massive speedup
< sipa>
we've been doing that since 0.8
< NicolasDorier>
I thought dbcache was only for read from chainstate
< NicolasDorier>
not writing
< sipa>
it's both
< sipa>
if a utxo entry is spent before being written to disk, it can be completely dropped, and will never even touch disk
< NicolasDorier>
interesting thanks, I thought that things were written to disk every block
< sipa>
with default settings it's maybe written every few dozen to a hundred blkcks
< midnightmagic>
sipa: 7.7.1-0ubuntu5 :-( so, a bit older I guess. Don't mind me, I'm just griping. :)
< rebroad>
I'd like to talk about Whitelisted nodes
< 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
< rebroad>
changes
< 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
< rebroad>
saving CPU for the node catching up
< rebroad>
should I create a new category of node called "trusted" node, or would it be the same thing?
< 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.
< 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.
< gmaxwell>
you should assume all the checkpoint whatever will be removed in the next couple major revisions.
< gmaxwell>
they're largely rendered pointless by prior software improvements.
< 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.
< 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)
< 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?
< rebroad>
gmaxwell, VLAN i meant to say
< 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.
< rebroad>
gmaxwell, I'm speaking of an IBD situation
< gmaxwell>
and beyond that, why even run multiple nodes when any disfunction/corruption/misconfiguration will silently spread and corrupt between them.
< rebroad>
gmaxwell, if we're talking IBD then the validation could at least be saved
< rebroad>
gmaxwell, or is that negligable compared with the hashing and database manipulation?
< rebroad>
gmaxwell, I guess for IBD specifically then you are going to suggest rsync as a better way :)
< 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.
< gmaxwell>
I suppose rsync is an option too and _much_ faster.
< rebroad>
gmaxwell, good to hear. thanks
< gmaxwell>
NP.
< gmaxwell>
(no problem)
< 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?
< gmaxwell>
The roadmap is what people will actually work on, largely.
< 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.
< 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
< rebroad>
assumption
< rebroad>
gmaxwell, I'd like to read those notes - where would I find them please?
< rebroad>
luke-jr, ah.. it only highlights me to messages that start with rebroad it would seem
< gmaxwell>
google, sorry, I can't really provide links right now. Don't have a working pointing device.
< rebroad>
gmaxwell, you have your finger but you're lacking the interface to your current working pointing devices ;)
< 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.
< luke-jr>
rebroad: I don't recall the conversation. sipa replied to you across 4 or 5 lines, which I was adding to
< gmaxwell>
luke-jr: if you could find the transcribe for rebroad that would be really helpful.
< 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..
< luke-jr>
gmaxwell: not easily unfortunately; about to board leg 2 of 3
< luke-jr>
rebroad: /topic
< rebroad>
luke-jr, /topic?
< luke-jr>
rebroad: the logs are linked in the channel "topic"
< luke-jr>
typically at the top of the window
< 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
< rebroad>
luke-jr, gmaxwell not meaning to imply I'm at your level of expertise or anything (I know I am not)
< 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.
< luke-jr>
rebroad: I do consulting for various Bitcoin stuff, but I try to minimise travel even then :p
< gmaxwell>
rebroad: Many people would love to see you in milan. Though I think it's sold out right now.
< luke-jr>
bbl
< 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
< 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
< gmaxwell>
The same is true for many of us.
< * gmaxwell>
out &
< gmaxwell>
:)
< rebroad>
lol , you backgrounded your outness
< btcdrak>
ping rebroad
< rebroad>
LOLing at this channels chat logs from March 23rd :)
< rebroad>
hi btcdrak
< btcdrak>
hi, PM
< GitHub88>
[bitcoin] MarcoFalke opened pull request #8750: [qa] Refactor RPCTestHandler to prevent TimeoutExpired (master...Mf1609-qaRefactorTimeout) https://github.com/bitcoin/bitcoin/pull/8750
< 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
< GitHub101>
[bitcoin] afk11 opened pull request #8751: RPC: Add parameter to addmultisigaddress / createmultisig to sort public keys (master...sort-multisigs) https://github.com/bitcoin/bitcoin/pull/8751