< Booxie>
Hello I'm on the developing repository on github username booxie , profile hidden cuz some1 flagged me on github. I need food please donate money to me at www.paypal.me/Bukoski
< bitcoin-git>
[bitcoin] jl2012 closed pull request #8593: Verify all incoming txs unless too big or too much hashing (master...verifyalltx) https://github.com/bitcoin/bitcoin/pull/8593
< pompa>
Good day vise people :) please help. how to transfer my bictoin core valet to new computer?
< pompa>
i need to download bitcoin core program to new computer yes? and how to trasnfer my bitcoins??? :)
< pompa>
trouble with old computer is that not working anymore, but i can reach my bitcoin files in it.
< sipa>
pompa: #bitcoin
< samm_>
Hello, it might not be the right place, but I would like to say I think it would be great to be able to monitor bandwidth within the client, since it is usually very slow to synchronize with the network due to the lack of nodes probably
< luke-jr>
samm_: it's already in the debug window..
< samm_>
Also being able to look at the processed blocks without hovering with the mouse
< samm_>
Oh? My bad, thank you
< luke-jr>
and block count is shown on the sync overlay..
< samm_>
I guess I'm bad, but I don't see any other way to check the processed block, the overlay is displayed by hovering the mouse, no? Well anyway thank you very much for your answer about the bandwidth monitor, it's helpful, sorry I didn't notice it before
< esotericnonsense>
the block count is also shown in the debug window
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #11458: Don't process unrequested, low-work blocks (master...2017-10-blocks-before-minwork) https://github.com/bitcoin/bitcoin/pull/11458
< cfields>
sipa: with your dns seeder, if i query "x3.dnsseed.foo", do i get results for 1 || 2 or 1 && 2 ?
< BlueMatt>
should be 1&&2
< BlueMatt>
is how I understand the spec
< cfields>
damn
< cfields>
then we need a new subdomain syntax, or 2 queries :(
< cfields>
(for NETWORK_LIMITED)
< sipa>
cfields: my seeder only supports querying for x1, x5, x9, x13
< sipa>
(as presently configured)
< cfields>
sipa: yes, whitelist updates as well
< BlueMatt>
for NODE_NETWORK and NODE_NETWORK_LIMITED? I was thinking we'd just keep dnsseed'ing for NODE_NETWORK and then maybe change it a long time in the future
< sipa>
right, dns seeds are mostly a way to find a few active and maintained network nodes
< sipa>
not directly to find the nodes you'll be syncing from
< BlueMatt>
but more importantly you'll probably only use dnsseeds pre-out-of-ibd
< BlueMatt>
so you really only want NETWORK at that point anyway
< cfields>
heh, you guys have conflicting reasonable points
< BlueMatt>
heh, true
< sipa>
i think for now just quering for NODE_NETWORK is fine
< cfields>
if you're just looking to bootstrap and find a few nodes that you can ADDR, flags == 0 seems enough. But because you're most likely in first-run or ibd, NODE_NETWORK seems reasonable.
< sipa>
and if need be, we can add a xAxB syntax or something, to query for A or B
< cfields>
yea, ok
< BlueMatt>
cfields: if you're using them to query addr you should use MayHaveRelevantAddressDB() :p
< cfields>
BlueMatt: yea, that's what i was reasoning through.
< gmaxwell>
keeping it node network is fine for now, esp since you mostly need DNS seeds when you're also in IBD.
< gmaxwell>
actually we should probably also have seeds only returning witness peers now-ish.
< cfields>
gmaxwell: i believe that's the case atm.