Firstly, IANAL, but I have a number of good friends who are lawyers.

It seems like Mr. MagicalTux doesn't have a good legal representation in the EU.

EU laws are all rooted in the Roman law. Roman law has already regulated bitcoin as a form of "depositum irregulare". The Roman law was actually about storing grains and other similar commodities. Meaning if you give a bushel of rye for safekeeping the holder of the deposit: (1) can use the deposited rye and (2) will return to you not the exact rye seeds that you deposited, but a bushel of rye seeds of the same kind. I believe the closest legal term in the Anglo-Saxon jurisprudence is "fungible".

This is still a subject worth of discussion. But you have to be aware of the history. In Europe the "depositum irregulate" laws were used to tax Jews for their bogus transaction during jubilee years.

My professional opinion is as follows: (1) for the short-term do a recompilation and any small modifications to the Satoshi client to let it inter-operate correctly with the rest of your infrastructure; (2) for the long-term keep your fingers crossed that the libbitcoin team (bitcoinconsultancy?) delivers on their promises.

BerkeleyDB isn't that difficult to master and the documentation is top-notch superb. I'm actually quite positively surprised with what had happened to it under Oracle's wing. The new release even has the SQL built in. But you'll have to at least recompile and possibly make number of small modifications.

And herein lies the problem. Switching from BerkeleyDB to any relational DBMS is a quite nontrivial tasks. Many people undertook it and nobody delivered a working code yet. Thankfully Gavin isn't accepting patches that modify the basic behavior of the Bitcoin with respect to block chain reorganizations.

As for those who modify the underlying database without understanding the code: this was probably the story of MyBitcoin if one takes Ted Williams' posts on the face value. Some programmers completely cannot grasp the concept of chain reorganization and write code that is subject to an abuse that the unmodified Satoshi client is completely invulnerable.

Not "bitcoin address" but "bitcoin account". Please read carefully the output from "bitcoind help" and the original post.

You seem to be missing two things:
1) RPC move between the accounts instantly
2) wallet.dat can be modified live with correctly compiled BerkeleyDB program that uses the same DBENV. wallet.db is a database and BerkDB is a quite powerful DBMS, its just that most programmers (including the 'core development group') are unfamiliar with it and don't understand its features.

Bitcoin is actually quite good. But it had bad fortune of attracting shysters from all walks of life. Bitcoin is the project about which its main architect Gavin Andresen wrote: we don't much care if you don't approve of the software we write.

http://www.youtube.com/watch?v=koIq58UoNfE

and about 1:25 into the clip.

As a corollary to this it would be nice to require the moderators to post the disclosures about their personal investments in Bitcoin and similar currencies they are hyping/bashing.

I'm not mtbitcoin, but I can give you an answer to this: the current code is horribly complex and doesn't obey any rules demanded by any legitimate accounting methods. For example it routinely re-dates the transactions and can disappear them upon block-chain reorganization.

The whole idea of stochastically-solve-the-inverted-one-dimensional-knapsack-problem before you can compute the transaction fee is hair raising to any legitimate accountant. On the other hand it is music to the ears of people planning to pull some sort of a fraud.

It still may be a good subject of some dissertation. In fact I hope it will not pass into obscurity, but it will stay an active subject of research and academic writing.

In addition I consider "short term irreparable HARM" a good thing: it is an excellent and fresh source for an examples of wide variety of scams. Sometimes it is hard to keep explaining to young people how scams work using the cases from 19 and early 20 centuries. Now we have really neat 21 century scam: all digital, all new-genaration, all Internet. No need to keep invoking tired, old references to "dog and ponny show" & "snake oil salesmen".

Most importantly, it doesn't appear to have been designed from the start to be a scam. It evolved into it.

This is true. In case of bitcoin it was particularly compounded by the fact that the various side projects are/were building wrappers around horribly bad central engine.

But the central idea still seems interesting. Even if it isn't completely innovative, it is/was an innovative combination of earlier ideas.

And no matter what will happen to Bitcoin itself, the education in scam detection and avoidance will have a lasting positive effect on many people. I would never expect that such a variety of emotions could be stirred by a piece of badly written C++ code.

All right. I have to admit that I have been successfully trolled by ruski. Props to him.

Server wouldn't have a problem. The network will have a problem and in particular IRC server that distributes the initial peer addresses.

Besides, 500 instances would mean 500 bitcoin customers for a single hoster. This is somewhere between science fiction and fantasy for now.

The only real hope to get out of this predicament is with libbitcoin crew. I sincerely hope they won't hoist themselves on their own petard.

This isn't enough. The communication between wallet-handler and block-chain&network handler will require two-way communications. Obviously wallet-handler submits various queries to the block-chain handler. But the block-chain handler needs to be able to make callbacks to all interested wallet-handlers. The callbacks can be distilled to one: the blockchain was externded by a positive or negative number of blocks. Positive extension indicates normal operation. Negative extension indicates chain reorganization. The callback could pass an array of relevant Merkle roots or some such.

The main thing about the above requirement is that JSON-RPC is not a good tool for a two way communication. Neither is XML-RPC, SOAP or some other popular candidates. This is a serious question of software architecture.

If you manage your own hosting and can obtain the help of a skilled C++ programmer, there is reasonably simple solution by running a bitcoind modified to share the block chain database. Take a look at my previous post:

https://bitcointalk.org/index.php?topic=34769.msg464460#msg464460

Modifying bitcoind to share the blockchain copy is at least an order of magnitude less work than modifying it to use or share multiple wallets.

Yes, it does. I'm glad to hear that you haven't made any extraordinary claims and are upfront about the initial paucity of the training data for the neural network. I will now assume that the unfortunate quote from Pixelon's marketing material was truly accidental.

Thanks again and good luck.

Hi Gareth!

I'm sorry I wasn't clear. I'd like to see a reference to a peer-reviewed publication (in the quantitative finance or artificial intelligence fields) that describes the research upon which your R&D team is working.

The Jared Kenna's words I quoted are almost exactly from Pixelon's prospectus, except they had "fractal geometry" thrown in for the good measure.

Would you be so kind as to ask your R&D team for the actual bibliographical references and post them tomorrow or later this week?

Thank you again.

I'd like to have a reference about those "dynamic models derived from AI". Is this Pixelon 2.0 or something real?

Thanks in advance.

I wouldn't call it slow, but it is perceptibly slower. I was wondering one thing: would it be acceptable to you to change the configuration from "https://bitcointalk.org" to "" (empty string)? This way those who aren't that security concerned could use "http://bitcointalk.org" to browse this site. The way it works right now is: one can get into the forum via HTTP, but then any use of the internal forum links make it switch to HTTPS.

Obviously this has security implications, it trades off the better local cache hit ratio for less security.

I'm fine with less security, but many other readers may be surprised and unhappy with it.

What do you think?

Not on the testnet. On the realnet there are checkpoints that cannot be rolled back in the chain reorganization. Look for "rejected by checkpoint lockin" in the source code.

I think you have it backward. What is required is a wallet-less bitcoind: a program that takes care of participating in the P2P WAN network and maintains a local copy of blockchain that is quickly accessible. On the LAN side it should accept requests to inject transactions and make callbacks upon seeing interesting public keys mentioned over the WAN.

Anything else is just an job security for the C++/boost/wxWidgets programmers and prolonging the opportunities to the hackers who endeavor to exploit the weaknesses of the current organically-grown client (because it would be a mistake to call it "designed").