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.

Please keep it on topic folks.

Bitcoin core has never exposed SSL to the internet in any sane configuration. So no, that wasn't generally possible. For the vast majority of users the fix wrt that was precautionary.

I just grabbed your USD bank account balance balance while grabbing your message.  

Don't also miss https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding

See also the PGP SKS keyserver, which uses efficient set reconciliation.


I'm a fan of fancy schemes to increase efficiency (see link) but that is a bit over the top.

The impact is much more modest than you're thinking, especially compared to the kind of forwarding that p2pool and bluematt's relay network already do (send blocks without repeating transactions that the far end already knows you have). The transactions still must be sent and validated. It does avoid the 2x bandwidth overhead of sending it again with the block, and the marginal latency that implies— but so do simpler tools e.g. matt's relay for me has a hitrate of "In total, skipped 140004 of 142773 (0.9806055766846673%)" since last restart.

Unlike some other technologies like fraud proofs these doesn't change the decentralization/scale tradeoff or the bandwidth usage (It's still O(n) with the number of transactions, they're just happening earlier). It's all awesome sauce and all and should be a great thing to have, but that I love this stuff makes it hurt all the more to see it exaggerated.

You may find this some interest http://www.reddit.com/r/Bitcoin/comments/2bp3vk/the_miniblockchain_scheme/cj86zhj

Without an articulatable/articulated security model it's not especially interesting to me at least.  We already have a reduced security model available and widely used in Bitcoin which is highly scalable.

Beyond having many unpaid debts, this class of idea has been proposed many times before. They don't appear to be good ideas for many reasons that other snazzy POW algorithms fail— no reason to believe them to be optimization free or approximation free, see Andy's asic/pow whitepaper for some more background: https://download.wpsoftware.net/bitcoin/asic-faq.pdf.  Regardless, considering this class of idea has been proposed before— why would anyone who had the technical chops to work on it (much less the breakthrough required to make it not fail-sauce) work for someone else and not just for themselves?

You can speak the P2P protocol just to fetch blocks— right now this is the fastest way... Note that I'm not suggesting you implement a full node (you are wise to avoid that), but instead use bitcoind as a filter and fetch blocks over the p2p protocol.

RPC getblock"s" would likely not be a lot faster due to the fact that much of the time is spent on the JSON handling.