Depends on the hardware. On a fast desktop with a SSD, a 60+MB wallet full startup with default settings is under 20 seconds.

Pfft. If you were a miner 99% chance you've never seen a full node in your life. Any full node can call that rpc, and only full nodes can call that rpc.

You can call getblocktemplate to see if your own node is attempting to mine it in the current block.

Any other choice would be giving the copyright holders of the software an elevated level of authority over the system, which would defeat the point-- even if it would be arguably desirable. Besides, it isn't like anonymous parties have tremendous recourse available via civil complaints; plus 99% of altcoins don't care: The MIT license required basically nothing but preserving copyright notices and most altcoins actually violate the license (because they search and replace out all the attribution).

I believe that is incorrect. The only non-trivial contributions that I can think of there is jtimon (freicoin).

It's true but that data can be provided in a way thats optional-- aux data that may or may not come along with the blocks-- or even completely externally.  It's not like you can expect to grab other people's random pubkeys and do things with them and have anything but doom come of it. ("What do you mean you didn't know, I sent you a message!" "No you didn't." "Yes I did, it was right here." "Thats not my house, thats the neighbors flower bed." "Yea, so? it was accessible to you! plus it was encrypted with your key!" "and thats not my key!" "Sure it is, I took this random key you used in 1997 and added four to it, you could have decoded that"...)

The answer is yes. In two ways:  The easier but less useful way is to point out that Zero Knowledge proofs for general computation are known to be possible (and are verging on practical for non-trivial problems now).  In theory I could give you a blockchain tip, a utxo set for it, and it's total work behind it, along with a ZK proof that the chain was completely valid, and that the utxo set agrees. This meets your criteria.

The other way depends exactly on what you mean by "blockchain validation". Basically, do you ever consider signatures prunable? e.g. when they're burried deep in the chain.  We do know how to make txout scriptPubKeys "provable a hash". If signatures are pruned and all txouts are hashes then there are basically no non-trivial sidechannels left.

Take a breath. Okay. Now, lets walk through this.

Fairly few, in fact-- if you use the gitian build system there is no uncontrolled upgrade of any dependency in the system. You will build a bit identical binary to all other users, and all updates to dependence can be audited and tested before being deployed.

Boost has only ever been used in a fairly limited capacity in bitcoin, mostly importing C++ features from the future, some of which are very useful to writing safe reviewable code. (the one big exception to that is the use of boost-asio). C++11 and better have incorporated many of the features, and Bitcoin Core has been phasing out most boost usage; though a preference to retaining compatibility with older operating systems is delaying the move completely. That said, we've had fairly few issues with boost version incompatibility (presumably because so little of it is used).

Work on libsecp256k1 began something like a year ago, along with work to isolate  the consensus behavior from openssl (as part of BIP62).  In spite of your considerable knowledge of cryptography and systems programming you have not made, as far as I can tell, a single contribution to these efforts. The fact of the matter is that only a few users care, even most of the people who regularly contribute to Bitcoin Core have not contributed to these efforts. And the work must be done very carefully. The update broke consensus was detected within hours of the openssl release through code review (not user reports), and did not effect bitcoin.org binaries or other binaries built with the gitian build system, because it captures and fixes the environments.  Which certainly made it easier to move forward with a subset of BIP62, since it validated the things that those of us who care about these things have been saying for some time and got more people willing to step up and do some review.

Your complaint there seems surprising. When a distribution tarfile is created all the autofoo stuff is fixed as shell scripts and doesn't even need to be installed on the host.  The pre-autotools enviroment for Bitcoin was a catastrophe. Keep in mind that Bitcoin is not some UIless library, it's a fairly complex end user application with graphical support and several optional components.  Though even without that, the autofoo stuff makes cross compilation work well-- which is important for being able to do things like the gitian build system providing binaries for three platforms from a single host.

(And pretty much no build system is going to save you from something getting screwed up here or there and needing to "make clean" to put everything right)

Yes, C++'s opacity is annoying, but what can you say?  Bitcoin Core never had a single remote code execution bug, in a complex codebase with a lot of moving parts. Had it all been written in C it is much less likely to have been as correct as it was, it would have been harder to understand at a high level (even if the fine details were more clear); and I say this as someone who profoundly dislikes C++.  C++'s mostly only awful when code is inflicted on you by others, it offers many sins, but they're answerable by "well, don't do that."

Careful here, your "plain C" also spews data all over the place. Go look at your stack. The compiler optimizes out most efforts to clean it up, and randomly spills things into place you never though they'd be. You can achieve the same control over leaking data in C++ as exists in C (as in: not perfect), all the STL objects can use custom allocators that zeroize. This is used in Bitcoin Core.

Yes, BDB is lame. Though its only new major releases which break the format. Old releases have still received fixes (especially important since the latest releases have changed software licenses).  It's not a security concern not because of encrypted data but because it's a local database for the wallet, it's not exposed to the outside world. Several abortive attempts have been made to replace it, it's a big project. (not in terms of lines of code, but in terms of cost of mistakes.)

I generally prefer C too. But I would have a hard time arguing for it for the vast majority of Bitcoin Core's code. The automatic safety possible in modern C++ has served it very well.  There are some parts, like the nitty gritty cryptographic consensus parts which already need to be so simplified, so analyzed, so straightforward in their operation, and are so important to expose to strong analysis tools (that don't generally work on C++ owing to its awful undecidable grammar) that the balance likely tilts back the other way, but we'll see how that plays out as those parts are factored out of the main codebase.

It may be absurd that there is reason to be concerned about such things, but there is reason to be concerned none the less.  Sometimes the world is absurd.

Your understanding is incorrect. There is no hashtable involved anywhere, and Bitcoin addresses have 160 bits of data.

In practice it did, because it required an unprunable copy of the whole blockchain to do anything with it. So everyone used it with various services and eventually the services returned inconsistent results (due to differently mishandling reorgs).

There are lots of things that can be done which are merely decentralization theater, sometimes because the design obfuscates the hidden decentralization, in other times because they're  not practical without it.  I'd say that was true for firstbits in practice, its true for the scheme here too though I believe it could be improved to be SPV-ish; but that still leaves the other downsides.

The random RPC blocking you're describing sounds somewhat like what happens when you have a RPC client that leaks keepalives. With the default settings Bitcoin core has only 4 threads for handling rpc queries (as additional threads consume a fair amount of memory and people would like to run this stuff on 500 mb VPSes) and once it has that many keepalive connections open further ones will block. Many RPC client libraries leak connections, leaving open old keepalives for a long time with no intent to use them again. If this is your issue, you can forstall it (at some memory cost) by increasing the rpc thread count, or avoid it by disabling keepalive (-rpckeepalive=0)... (or better, fix your client to not leak keepalives).

If that isn't your issue, you could try actually reporting your problem (especially with a reproduction), since no one has done so.  In particular, I keep a testing wallet running with tens of thousands of addresses and many thousands of transactions haven't observed what you're describing; so I cannot tell if your comment on block updating is a red herring or not (accepting a new block really must block most RPCs, but should also only take a second).  Not sure why people are going on about software being "unsuitable" when they can't even be bothered to report issues they've had. It certainly isn't going to magically adapt to your use-case if you snark in threads burred on forums instead of reporting issues (much less contributing to improvements).

With respect the thread here, I benchmarked a node here processing over 5500 tx/s in aggregate during IBD, including the signature validation and all.  Considering that the network as a whole is limited to <10, I think this is pretty good. If there is an actual performance issue you'll need to setup a reproduction in isolation from your application in order to figure out where it is. Just saying it's slow for you is very much not helpful; we need to know what RPCs, called in what pattern, are taking what amount of time-- and ideally have just some script to reproduce it, otherwise there is just an endless loop of "seems fast to me".

You probably don't. Read your debug.log.

2011 called, looking for its concern troll-posts back.

Back in 2011 this kind of thing was a reasonable concern. It's much less so today.

There is a whole host of separate problems there, including needing to witness the whole blockchain to scan for payments (it breaks SPV and/or makes you again depend on a central server)

The usecase you're describing is addressed by the payment protocol.  You give people a payment uri.

You cannot generally. Look alikes can be ground. There is a nice example of this for openssl picture fingprints that I'm having trouble finding.

There are plenty of lookalke/soundalike/mean-alike words in it e.g. [choice, choose], [drip, script, trip], [risk, brisk], [load, road] (just picked single words at random and found the first obvious matches; what-- no one ever confuses "r" and "l" sounds?).

That would, in fact, be an improvement over firstbits.

The process you described fundamentally requires registration. Before I can give you a short address I must have registered one in the blockchain.

Basically this idea existed more or less before in the form of the ill fated 'firstbits'; I consider this proposal to be ill-advised for the same reasons.

Addresses should generally not be reused. Reusing addresses harms the your security and privacy as well as the privacy of all Bitcoin users. Extensive address reuse contributes to systemic risks which endangers the system (what happens when RPG wielding ninjas show up at mining farms with demands to not mine transactions belonging to their enemies?  If regular transactions are conducted so that they are indistinguishable to their author's enemies we never need to find out). While the community may not go so far as to prohibit reuse, building infrastructure that rewards it is not a good plan.

These short addresses are immediately subject to lookalike attacks-- a popular address is "wolf larceny tape butter" ... great, I go and create "golf larceny tape butter", "wolf larceny ape butter", "wolf larceny tape butler" and so on... I spam these clones out in various places or just trust human error to guide things along, and now I'm receiving funds from other people. We don't even need an attacker here, all outputs are constantly being assigned addresses, the space of working addresses dense-- instead of the very intentionally sparse case which we have with addresses today where its nearly impossible to send to an incorrectly entered address.

As you note, the security here is totally undermined by a reorg. So beyond chance reorgs breaking things for people and causing their funds to go off to be lost in space, now there is a great incentive to reorg that didn't exist before. (there also is some fun nuisance perversion like miners selling high value vanity positions in blocks with this particular scheme; spamming up the chain to make sure to register the really goods one, sometimes requiring large indexes.).

One could not resolve these addresses without a copy of the entire blockchain or at least a forever growing unprunable database (as with firstbits) which would need to be accessable to each and every wallet. In practice most people would depend on centralized services to resolve these (as  they did with firstbits), and in practice the services will eventually return wrong results, even without intentional fraud (as with firstbits).  Of course, any of these services would be prime targets for compromise; a well timed replacement could redirect huge flows of funds.

This also requires a separate registration step, which reduces the scalability of the system due to additional overhead, and makes the system less instant gratification. You end up with something where you have to pay fees to establish an 'identity' just to receive funds to pay the fees with. Necessitating multiple use modes.

Less critically the use of a particular fixed wordlist is culture/language laden and has seemed to be somewhat problematic for BIP39; though I mention this only in passing.

Yes, and I explained why (the fact that 32 bit systems needs a lower limit was also well known in advance; Bitcoin imposes a hard cap of 1024 on 32bit systems... but it sounds like from your report that this is not low enough). Large cache settings (e.g. 4096MB) are extensively tested on 64 -bit hosts.

Getting corrupted is a separate issue, that shouldn't happen. Any issues causing that should be fixed. FWIW, if you end up corrupted a reindex will work which tends to be faster and less IO intensive because it leaves the blocks in place (doesn't have to write the blocks again)... not a reason to not fix the corruption on unclean shutdown, but perhaps it's a helpful bit of advice for you.

Can you try restating this? What does "in a mixture of wallets" mean?  I've personally tested Bitcoin core with wallets with tens of thousands of transactions without issue, but I'm not sure precisely what you're doing, or what you mean by crash.

Doof, impressive that you managed a response even less useful than mine.

Well, you've given no information there. I'm afraid you may be mistaking the human participants on the forum for a search engine or mechanical turk. We don't generally answer questions in a vacuum.

You can insult people on the forum and provide inadequate information but that isn't likely to get your questions answers. Congrats on the self-defeat there.

You can set all the design goals you want, but no matter how many insults you hurl that isn't going to change the design of the Bitcoin system and so if it happens that what you're trying to accomplish turns out to be at odds with it, it's not going to work well, or will result in funds loss, etc.  It sounds like your understanding is currently pretty limited (e.g. not knowing how the size of a transaction works), you might want to attempt to understand the system a bit better before setting immutable design constraints and defending them with insults.  Just a thought.

You're running out of address space.  A 32 bit program only has access to 4GB of address space. At least 1GB of that is used by the kernel.  Usually another GB is lost to libraries, stack, and other userspace overheads.  Leaving you with maybe 2GB of process address space. It then loses more from running multiple threads, each with their own stacks and heap arenas which use address space even if they're not using actual memory yet.  Then you get the process's own memory usage, and there just isn't much space left for huge caches.

We should probably cap the dbcache maximum on 32 bit hosts so that you don't get the surprises crashes at runtime... but sadly, I don't think it will be possible to accommodate your desire for a super large cache.   Have some patience though, the default cache is way more than adequate for a running node-- cranking it up only makes a real difference on the initial block download, which is a one time event.

There hasn't been any real interest or discussion in it in technical-development-- This isn't meant as an affront on your efforts: You don't see similar noise about related (and I think more relevant) projects being worked on by multiple people on the Bitcoin Core team (moxiebox), simply because they're also not mature, and not yet interesting to a wider audience.

The last updates I saw on it were repeated duplicate threads announcing a really large bounty for creating an altcoin based on it.

With the lack of interest and constant bumping (along with post deletion), I was considering moving it between project development and altcoin subforum; the huge create-an-altcoin bounty made me think the latter were more suitable (or at least, would get you the attention you want).

Usually if there is anything I'm on the fence about I wait until someone else does a report-to-mod on it before taking action-- I'm not sure if I did in this case (if I had to guess I'd say I hadn't waited), or not, but I'm just speaking to the usual process. (Thanks Shorena for all your great button mashing.)

This thread is only 10 hours old. I work on Bitcoin things nearly every waking hour of nearly every day.  I am, however, obligated by certain biological limitations to sleep at some times. In the future, you should have PMed first: For one, I might not have seen this thread for a couple days if not for dogie PMing me, but also I would have gladly answered your questions... and there wouldn't be a need for me to wake up to pages of antagonistic complaints because I had the gall to take a few hours off Bitcoin in order to sleep.