You're running a non-git version of bitcoind. Next major version will have them for you.

WRT peer height.

The syncheight is based on what the peer has advertised to us, so if a peer is not synced up yet its syncheight will be -1. You might want to fall back to displaying the starting height there if and only if it's value is more than one less than your current height and syncheight is -1.

It's completely normal and unsurprising for the genesis block timestamp to be 'rigged'. ... I don't know about in BCN, but in Bitcoin there really is no facility to mine a genesis block, it's hard coded... so you end up building a separate tool to create one. Your tool _could_ read the current time, but thats ~2 more lines of code than just manually setting the time at some value. By itself I wouldn't find that concerning.

First, the entire privacy model for Bitcoin is predicated on users not reusing keys. Without that, bitcoin is obscenely non-private, and gravely disadvantaged compared to any other store of value or transaction system in wide use.  This alone immediately would destroy any value an 'account' system would have, and so you can basically stop at this point and think no more.

Though there are other reasons, beyond the increased difficulty of evaluating zeroconf transactions Sergio mentioned above—

Then the account model has major problems with corner cases... e.g. You have problems with determinism in conflict situations:  e.g. Alice has 2 BTC and pays Bob 0.9 BTC, then Alice pays Carol 1 BTC.  Later Bob gets angry the transaction hasn't confirmed and demands Alice reissue with a fee. Alice does but then Bob gets paid twice and Carol not at all.

Even just anti-replay you need an random access lookup to see if the nonce has been used already, and the nonce is per input if you ar eto have conflict control. You have more data (the list of nonces) is unprunable (or difficult to make prunable)... and so any space you saved by not having extra outputs is lost in abundance by having to store nonces forever— even after an account goes to zero value, since if it were funded again someone could replay a years old spend— once the spending actually does happen.

In short, account like setups _seem_ simpler and more intuitive, but they have ugly edge conditions that are difficult to get right and create overhead that wipes out the possible gains. When you consider that the privacy model precludes that kind of use in any case, there really is no upside and a lot of downside.

Beyond being unethical and stupid, closed source miners are a risk to the ecosystem. What happens when some important update is needed to these devices? Or what if they're shipping with a back door? What if they need fixes to work with p2pool or some other future mining improvement?

Not clear to me. A lot of technical work doesn't get invested in. I mean— sure you could get a few thousand dollars or something. Getting millions would be much more dicy, especially if you're thinking like I do and thinking that any serious altcoin competition with bitcoin could potentially be very bad for all cryptocurrencies (damaging network effect), plus competing with bitcoin is a long uphill battle. Perhaps it's arguably more profitable to do some splash where you've got effectively infinite supply, and feed a huge incoming speculative demand ripple/stellar style.

I'm probably out of my depth— figuring out how to extract money from speculators isn't something I really have experience with... it's just not so surprising to me. Though next I'd be worrying that if someone did all these dishonest things, what backdoors do they have in the software? :-/ In my case I only ran any of these codebases sandboxed on separated machines. Presumably altcoin exchanges have similar setups?

Yep, I'd raised concerns about these claims before myself.  Funny, I also checked the references, but I didn't realize the whitepaper was supposed to be that old (I'd missed that the document was backdated).

It's more than just the history that is fishy, though.  The proof of work algorithm appears to be a pretty nice bit of insurance against people forking the system, since it was clearly purposefully deoptimized— and contrary to the design claims provably reasonably GPU friendly (and, likely, very friendly with larger 28nm FPGAs— a suspicion supported by the hashrates of the systems based on this pow, including monero).

Might not want to overstate the amount of cryptographic review the approach has had. I've spent some time on it but haven't personally worked through any proofs of its properties. It takes a long time to gain confidence in a cryptosystem.  (Though sure, I do think the ring signature system is very interesting— that rest? well). Oh well, honestly, I think that this sort of stuff is more ethical than the altcoin presales (Esp the ones that don't ever deliver anything).


:-/

Sure, then in a totally unrelated sequence events sought a client that could import keys and beep when it received a transaction, claiming to have thousands of faucet keys from long ago he needed monitoring.

Then, again unrelated, his bitcoin-qt was falling over because it had so many keys loaded (which in my experience doesn't even happen at 100k keys).

Then totally unrelated his next question was software to check the balances of millions of addresses (when only a couple million in total have balances, but like totally they're all his), and his examples by complete and total coincidence happened to be keys one might have copied from d.io.

Then I asked what he was actually trying to achieve, because I'm totally evil and not because I noticed his repeated failure to make yak shaving progress, and also in passing ask if he was trying to crack keys— again because I'm an abusive moderator and not because I've seen people on many occasion ask a similar sequence of questions when they were and don't care to spend my time helping people rip people off in the Bitcoin community, and totally not because I'd noticed that his posts were inconsistent.

Then when he flipped out, wisely offending me— because I am totally not someone who could just hand him his answer directly or quickly cross compile some tool for his OS—, while also managing to provide zero information to explain what he was doing, both making himself look suspicious and failing to provide the required information so that other people could help him achieve his goals... and the fact that I was able to guess the private keys for his example pubkeys (which he ranted that he couldn't possibly be trying to crack because he'd have to know the private keys for them— it's really just my own idiocy why I can't understand how an import function that requires you to have the private keys doesn't imply that he has the private keys), this was all coincidence and in no way suggested his (still unspecified) goals were actually evil.

In reality there is some totally harmless and legitimate reason that he needs a programming free solution to monitor more addresses than are currently being used for funds in the whole network, beep when they receive them, while working with insanely low value near sequential private keys, while asking questions that mislead about his ultimate goals (and getting answers that are poor fits: Bitcoin-qt is an acceptable way to monitor thousands of addresses, not millions), and he can't disclose this reason because my puny mind is totally too small to contain an understanding. So the fact that I might suspect some foul play here is entirely my own fault and I deserve a heap of abuse for it.

Yea, you're right. That must totally be what happened here.

Actually that website 'publishes' all of them.

And for all those words, you still can't seem to explain what you're doing... Or why I knew the private keys for the addresses in your example. The tantrum is not making you any more convincing.

[Edit: Incidentally, there is no point in crapping up the thread with "quoted for reference" posts, I can delete or edit every post here.]
[Though, of course, I have no reason to do so, I'm completely comfortable with what I've written, much more so than you seem to be with your own position, which you continue to leave with the not-all-that-mystifying lack of justification— I'm just pointing out the quoting is a waste of space.]

Ah, so since you weren't helpful in your response I thought I'd research some...

Looking at your past posts I see you were previously asking:


Then you complained about Bitcoin QT misbehaving with many addresses loaded (which means you have >100k loaded in it),  and here you're talking about millions.

I guess too would have a hard time explaining how being a "faucet and referral program whore" results in needing to scan 100k-1m+ addresses, and what use audible alerts were in relation to old inactive addresses of yours…

Incidentally, the private key of the first address in your list is

5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEtHwQJ6fmT7

and the second

5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsz591qCUVs

And anyone who thinks a bit about how I know that will probably share my conclusion that you're a fool and a wanna-be thief.  Buzz off.

I'd educate you on precisely why your moronic approach isn't going to net you any coins, but it's probably better for the world if you continue to remain in the dark until your moral character catches up with your typing ability.

Thats an awful lot of very defensive text without any explanation at all. I've encountered inept brainwallet crackers multiple times who had the laughable strategy of attempting a key and querying bc.i for its balance, until they rapidly find themselves banned, then they show up on the forum or chat asking a question a lot like yours— a way to query a lot of addresses.  Especially when they're asking about querying at a scale compariable to or larger than the number of addresses with spendable coins in existence in total.

In any case— I didn't say _you_ were attempting to do this,  I asked what you were doing and pointed out what my past experience is with the question (so that you might be aware of the kind of speculation your question might inspire).

Generally if you're seeking help it's advisable to describe what you're actually trying to accomplish so that people with experience can point you to the best solution— often when you've found yourself in an unsolvable rut it's because you took a wrong turn a few steps back, and are now headed down a blind ally—  and only asking complete questions can save you.

What community is this useful for? Other people I've seen asking for this are trying to crack brainwallets (ineptly).

It's a trivial change, but one that requires some testing and no one has had any chance to test it. It has previously been ~zero priority. (the second pull request isn't a separate one, it's just a rebase). It's somewhat annoying to test because you really want to test it from an IP which hasn't previously run a node so you can verify that it successfully gets connections.  If it's interesting you please test it and provide feedback.

Sure, https://github.com/gmaxwell/bitcoin/tree/extip3

If you are behind a chain of NATs inbound connectivity is not going to work with high likelihood, so discovery is irrelevant.

If you are connected to the internet directly then it gets the correct address off the interface, and again— discovery is irrelevant.

My comments were about the importance of discovery and the wisdom of your proposed solution. In cases where discovery isn't important you can disable it (via -discovery=0 or -externalip=).

Yes. It adds a _new_ dependency on centeralized servers (though more widely spread ones). This is completely unnecessary because the Bitcoin protocol already has a facility for discovering your address from the peers you're already connecting to built into it.  There is no need to add support for an additional complex (think attack surface) protocol with more hosts that could monitor users just to support figuring out what your address might be.

NTP isn't trustless. You trust your servers and if they lie to you, your time will be wrong.

And send 10 gajigga bytes of potentially min traffic around the network.  Besides unless your "distributed timestamp server" is another POW blockchain (in which case nothing has been achieved) its not obvious how to construct that in a decentralized way.

Generally if you can assume the existence of such a construct no mining is needed at all. Mining exists basically to solve that problem.

Thats a really foolish method. The Bitcoin protocol already has a facility to identify the peers address without any reliance on a trusted remote parties at all.

Ignoring that, the address discovery is also moderately unimportant: Normally the address is either the interface address (in the no nat case), or it's discovered via UPNP. If the host is behind nat but UPNP is not used the port is likely not forwarded at all. (And, of course, the users can always override if they have an unusual configuration).

Also, your post is barely on topic and you've bumped a pretty old thread. Please don't do that.

BFGminer supports TLS and can do cert validation.

Or better, just run P2Pool. This sort of thing isn't a threat when you're not blindly selling your hashrate to third parties.