< jonasschnelli>
sipa: hmm.. "dig A testnet-seed.bitcoin.jonasschnelli.ch" reports different result then "dig A x1.testnet-seed.bitcoin.jonasschnelli.ch"?
< sipa>
jonasschnelli: of course
< sipa>
separate request
< sipa>
since it is not cached by dns
< jonasschnelli>
Right. But x1 gives me back 22 IP where non-filter gives me back 1 IP!
< jonasschnelli>
non-filtered should also result in a "full–response" not just a single IP
< jonasschnelli>
I'll attach gdb
< sipa>
well at least use dig @yourseedersip A testnet-seed.... then
< sipa>
so you see what your seeder responds, unfiltered by the several dns layers that may be between
< jonasschnelli>
Yes. I tested also locally against port 5353
< sipa>
i get a nice long list for both
< jonasschnelli>
hmm.. now i'm also getting a long list... strange
< sipa>
maybe you were just seeing a cached result?
< jonasschnelli>
Could be. But a cache with a single IP would be strange?!
< sipa>
unless it only found one useful ip to respond with
< jonasschnelli>
I think a single IP for NODE_NETWORK after running ~24h seems buggy,... but depends on the ISPs DNS cache TTL overrides. I keep an eye on it...
< luke-jr>
fwiw, I am intentionally delaying my DNS seed upgrade in case of unexpected issues; let me know if this is a problem.
< jonasschnelli>
luke-jr: there is no hurry with DNS seeder upgrade...
< jonasschnelli>
I guess 0.13 will support seeds with support and without support for filtering
< sipa>
jonasschnelli: oh, an x9 result!
< jonasschnelli>
sipa: Yes. A single one. :)
< jonasschnelli>
petertodd dns response 23... ^^
< jonasschnelli>
(a bug)
< GitHub116>
[bitcoin] jonasschnelli opened pull request #8205: [Wallet] add HD keypath to CKeyMetadata, report over validateaddress (master...2016/06/hd_metadata) https://github.com/bitcoin/bitcoin/pull/8205
< jonasschnelli>
hmm... importwallet of a new bip32 dumped wallet will just import the keys and not the "hdness"...
< jonasschnelli>
but I think this is okay.
< jonasschnelli>
importwallet is not a backup restore option
< GitHub29>
[bitcoin] jonasschnelli opened pull request #8206: [Wallet] add HD xpriv to dumpwallet, show masterkeyid in getwalletinfo (master...2016/06/hd_info) https://github.com/bitcoin/bitcoin/pull/8206
< GitHub170>
[bitcoin] MarcoFalke opened pull request #8207: [trivial] Add a link to the Bitcoin-Core repository to the About Dialog (master...Mf1606-LicInfo) https://github.com/bitcoin/bitcoin/pull/8207
< GitHub100>
[bitcoin] sipa opened pull request #8208: Do not set extra flags for unfiltered DNS seed results (master...simplerservices) https://github.com/bitcoin/bitcoin/pull/8208
< jouke_>
Core wallet also rebroadcasts transactions it received right?
< jouke_>
Or, hmmm.
< jouke_>
I don't think it does.
< sipa>
only its own transactions
< jouke_>
thanks
< gmaxwell>
now that we have expiration and limited mempools it might be useful for privacy to 'adopt' random addresses from the network and rebroadcast them like a local wallet.
< jouke_>
Yeah, and those block explorers probably keep those transactions longer visible as well. A lot of our customers don't keep their wallets online after they made a transaction.
< jouke_>
And use blockexplorers to keep track of those transactions
< gmaxwell>
it might make sense to only do this for addresses that send a high fee RBF flagged transaction, rebroadcasting non-rbf/low fee txn can have adverse effects, getting in the way of a higher fee doublespend post expiration.
< jouke_>
Indeed. Altough most of them don't mind if we rebroadcast them for them (it saves them the hassle).
< gmaxwell>
a lot of the needs rebroadcast activity I've seen is due to chains of unconfirmed transactions basically not propagating at all in the network.
< gmaxwell>
0.13 will help that, potentially a lot depending on if my last orphanmap PR goes in.
< gmaxwell>
Can I get some other review on #8084, by chance only people from blockstream have ACKed it (though I don't believe it's ever been mentioned inside blockstream, beyond me asking patrick to review since he originally wrote that code)
< gmaxwell>
it's a pretty trivial change.
< gmaxwell>
and I'd be glad to explain it or the general evicition logic, if anyone has questions.
< sdaftuar>
gmaxwell: i'll try to take a look today
< jouke_>
You guys are doing an awesome job :)
< sdaftuar>
gmaxwell: i just looked at the change to AcceptBlock. if i send you an old block that is just past the last checkpoint (and not on the main chain), you'll think i'm a better peer?
< sipa>
jouke_: thank you
< gmaxwell>
sdaftuar: Yes, though there are only a finite number of those. Have any suggestion on a better _simple_ test? This is a fairly small behavior and I really didn't want to go restructuring block acceptance to enable it.
< gmaxwell>
I ~think~ it's okay if it's a little approximate, but ideally it should be the least approximate that can easily be done.
< sdaftuar>
yeah i'm not sure what you're going for here
< sdaftuar>
presumably it's not hard to mine new blocks just past the last checkpoint using today's mining hardware
< sdaftuar>
if that's okay, then so be it
< sdaftuar>
i think an alternative thing to do would be to see if they're giving you a block that's on a more work chain than your tip
< gmaxwell>
Basically we reserve a couple of inbound slots to be protected from eviction based on a bunch of different hopefully orthorgonal criteria. So that its difficult for a single attacker to 'win' in all the different ways.
< sdaftuar>
fHasMoreWork is right there
< gmaxwell>
I could just move that test down to after the not requested block.
< sdaftuar>
yeah that should work
< gmaxwell>
and then it won't get set if it wasn't requested (better header) or at least has work.
< gmaxwell>
okay will do.
< sdaftuar>
cool
< gmaxwell>
I agree that would be better.
< gmaxwell>
anyone know how to fix a corrupt git repo? :( my laptop lost power while I was in the process of pushing the update. and I'm now getting:
< gmaxwell>
error: object file .git/objects/7e/990c38c0751935245fc1b370823623fd791fc8 is empty
< gmaxwell>
error: object file .git/objects/7e/990c38c0751935245fc1b370823623fd791fc8 is empty
< gmaxwell>
fatal: loose object 7e990c38c0751935245fc1b370823623fd791fc8 (stored in .git/objects/7e/990c38c0751935245fc1b370823623fd791fc8) is corrupt
< sipa>
gmaxwell: delete those files until it no longer complains
< sipa>
run git fsck
< sipa>
you may to manually change what head points to
< gmaxwell>
oh awesome I lost net.cpp too.
< gmaxwell>
weird when I wasn't even editing that file.
< sipa>
tjis is what happens to me all the time when my laptop goes out of power while compiling
< sipa>
maybe i should make 'make' an alias for 'sync; make'
< gmaxwell>
wow it wiped out most of the source files in fact, perhaps because they'd changed briefly before in my checkout.
< btcdrak>
what about your reflog?
< sipa>
reflog won't help
< sipa>
best case, it points to objects that no longer exist
< sipa>
worst case, the reflog is gone
< sipa>
gmaxwell: worktrees are nice
< gmaxwell>
damn that branch is destroyed, and I can't delete it.
< gmaxwell>
I should alias git to "sync; git"
< gmaxwell>
why doesn't git sync after making changes? :-/
< * gmaxwell>
types man git
< * gmaxwell>
reads git - the stupid content tracker
< * gmaxwell>
is enlightened
< gmaxwell>
sdaftuar: updated, thanks.
< gmaxwell>
for context, I wouldn't consider "mine a checkpoint-diff-block to get placement here" a bad outcome, less good than the simple change. But we should eventually have a hashcash category too. (and as many other categories as people can think of that we can easily measure)
< sipa>
they should also not protect a fixed number of nodes, but rather some percentages
< gmaxwell>
some might be better as percentages, some better as fixed numbers.
< sipa>
i think there should also be some generic scoring, that can be used as tie breakers
< sipa>
than you
< sipa>
1) remove protected nodes from the list
< sipa>
2) sort by the tie breaker per netgroup, and remove all but the best from each netgroup
< sipa>
3) sort the remainders again overall, and pick the worst
< sipa>
eh, remove the best from each netgroup
< gmaxwell>
I suggested before some abstract ratio of bandwidth usage to 'good activity', then rank peers by that.
< gmaxwell>
there are a lot of little improvements too, e.g. those sorts should all be heaps.
< sipa>
indeed
< sipa>
after the libevent switch we may be able to deal with many more peers
< gmaxwell>
I worry that that will undermine the utility of things like eviction, since with many peers you'll be able to be kept busy with 999 junk peers. No one is disconnected but they might be startved.
< sipa>
or maybe there can be multiple local node services, with connections sharded over them
< sipa>
that each run on one or a few threads
< sipa>
and communicate with eachother as peers
< * sipa>
dreams
< instagibbs>
is there a fast way in github to check how PRs changed
< btcdrak>
what do you mean?
< instagibbs>
someone squashes, changes a PR, whatever. Aside from locally fetching, diffing, is there an in-github way to do this if I have the two commit hashes
< btcdrak>
Github has started to send email notification for each push
< btcdrak>
instagibbs: I dont think so, except for the /compare/ url scheme
< btcdrak>
assuming you know prev hash from the notification history, or lookjing at the submitter's RSS feed