Well, do something different than all the previous "enterprise" programmers. There was a common thread in all the "enterprise" patches submitted to the core team: they interfered with or completely destroyed the blockchain reorganization behavior. I'm on the record disagreeing with various technical issues regarding Bitcoin Core client, but I fully support the Bitcoin Core developers in their insistence on preserving the fundamental properties of the Bitcoin protocol: the global consensus is achieved through a somewhat random convergence that could involve orphaning some blocks.

The list of things you seem to be missing is actually longer:

1) The coin-selection is a non-trivial problem that is NP-complete in a general case (I've already mentioned that the current solution is a stochastic approximation, which is non-monotonic and therefore breaks the code like yours)

2) Bitcoin wallet isn't static while your code snippets are running, new blocks can appear randomly and change the coin selection both by adding and removing coins from it. (This is the most common mistake in the various "enterprise" patches that I've seen: mishandling of orphan blocks)

3) After you correctly solve the first two problems there is an issue of repeated greedy local optimization leaving wallet full of near-dust coins, so the optimization needs to be upgraded to some non-local, near-global or at least allow for optimizing coin selection for a set of transactions.

4) After you correctly solve problem (3) you need to provide a solution for the common operational requirement of keeping 2 wallets: hot and cold, and manage the coin transfers between the two of them that fulfill the non-scalar optimization goal of maximizing security and minimizing fees.

I hope that the above list helps you understand the true "enterprise" requirements and why your proposal is nothing more than a short-sighted temporary hack.

From myself I'll add that any true "enterprise" solution would obey http://en.wikipedia.org/wiki/Two-phase_commit_protocol and will easily integrate with any of the available http://en.wikipedia.org/wiki/Transaction_processing_system . From your insistence on using unstructured RPC calls I surmise that you have neither "enterprise" coding experience nor even plain multi-threaded development.
The technical reason is called "inversion of control" (i.e. server calling client to make a decision). Again this was discussed on this forum many times, at least since the wx->Qt UI transition. Use the search function.

If it is really such a "sharp pain point" then you are better off basing your work on a different code that Bitcoin Core and submit raw transactions to be reference implementation.

Thanks, I checked the Wikipedia http://en.wikipedia.org/wiki/Defense_Language_Institute  and this institution grands AA degrees, which is far away from the psy-ops educational requirements.

This type of teaching establishment have their own occupational risks, which I think Churchill summed the best: ability to squeeze the maximum of words into the minimum of meaning.

This would also completely explain Inaba's dialectical habits. Given the sentence "two plus two equal five", he would correct it to "two plus two equals five" or complain that it isn't a well-formed sentence but just a clause.

In my opinion that has more in common with "verbal tic" than a highly skilled social technique. I've met unquestionably highly educated people who to the end of their life couldn't get rid of similar language habits learned in a mediocre language schools (religious, not military). This ELIZA technique is frequently used to quickly approximate a fluent speech.

You seem to be missing the crucial fact: the coin selector in the "send" is a stochastic knapsack solver. For any non-trivial wallet it pseudo-randomly selects different coins resulting in a different size of the transaction and thus requiring a different minimal fee. This has been discussed many times on this forum, please use search.

Another personal message spammer:

How do you know that? Can you give us a link to his post?

As a person who also runs Win XP SP1 (for reasons unrelated to Bitcoin), I'm curious. Is there a real way to exploit such a machine (by a scriptkiddie or a real hacker) when the only Internet-visible port is tcp/8333 and the respective outgoing connections? Or is shorena spouting a standard pseudo-security paranoia? Please don't talk about social engineering attacks or other attacks involving physical access to the hardware.

Edit: Like Kelp! I also don't run antivirus on it, although I monitor it with a Tripwire-equivalent.

Maybe Inaba is just a new implementation of http://en.wikipedia.org/wiki/ELIZA ? His keyword-oriented response generation is effective in emulating the http://en.wikipedia.org/wiki/ELIZA_effect to generate voluminous discussion threads.

You have a classic setup to get bitten by http://en.wikipedia.org/wiki/Dead_key issue. This is especially easy on Windows which keeps the keyboard layout state per thread/window. So many people are unaware that when the new window pops up the keyboard layout may have been temporarily changed for the duration of this new window being open. In all cases like this that I've personally assisted it was always caused by careless change in keyboard layout, keyboard driver, physical keyboard or the way the key presses are transmitted through the various "remote desktop" tools.

Like, are you positive that nobody in your household had recently started learning e.g. Spanish or stopped learning German?

The "most accurate kind of simulation" is all-analog simulation using BSIM or equivalent. I doubt that they did that. As someone mentioned earlier their J/GH numbers are in the "standard cell" range, thus points to a design flow that is intentionally approximate.

AFAIK proof-of-burn is an one-way blockchain hop. I'm more interested in hopping without burning the bridges to return back. Kind of like people talk about side-chains and tree-chains; I'm thinking of DAG-chains or directed-acyclic-graph-chains.

Yes. The only defense is a sheer expense of doing that attack. Also note that attacking time over a significant period would also attack the difficulty, so the stupid attacker (speeding up the time) will actually attack itself through the difficulty increase.

The "current time" on the Bitcoin network is a median of the time of last 11 blocks.

Note the cute duality: median of 11 is a 6th element in a sorted array, so "time hasn't moved forward until median time of 11 last blocks has increased " and "money transfer not confirmed until 6 confirmations are seen" are mathematically dual.

It isn't impossible, it's just that it would require very advanced programming expertise and some changes to the Bitcoin protocol to be able to explicitly track sub-variants of Bitcoin again double-networking (currently Bitcoin guards agains double-spends, it would need to safely guard against transferring same bitcoins to more than one sub-network).

If you want you can take a look at my old proposal from my signature:

https://bitcointalk.org/index.php?topic=54382.0

But I have to warn you that advanced programming knowledge is required to understand it.

Currently there's absolutely no consensus on how to change the Bitcoin's network protocol.

The one thing I don't like is the title of this thread: it should be "Competing and cooperating Bitcoin networks". They are competing in serving of customers but simultaneously cooperating against fraud and counterfeiting.

Edit: Without that last caveat the purely "Competing Bitcoin Newtorks" would be just Alternative Cryptocoin Networks".

No, I'm not suggesting that they are insolvent. I however think that they aren't competitive and don't have much value as a going concern that will continue to release products for many years into the future. In particular I don't think that BFL can be sold to a 3rd party or subject to a management buyout.

If not Ch.7 then trusteeship followed by a regular liquidation. If they really sit on a boatload of cash then that surplus may forfeited or used to compensate past customers.

In any case I don't think all employees will be immediately laid-off and the premises cleaned by hazardous waste disposal contractors.

Theoretically speaking BFL could be forced through Chapter 7, and that would mean retaining some (or even most) employees through the initial liquidation stage.

Apparently fees are competitive enough when compared with maintaining a physical retail location in a large European city. I heard about the plans of expanding it to the sending side, where the courier will witness and photograph the shipment before the box is closed and taped-up. Thus far the "sending side" is typically a phone/mail/web-order operation that does volume shipments and there's not much chance of fraud but more of miscommunication; overselling or general buyer's remorse.

Some smaller courier services in Europe provide this type of service, not for bitcoin though. The courier stays with the customer for a limited time during opening of the shipping box and has the camera to document any discrepancies on the spot.

Neither FedEx nor UPS are in the position to offer it because:

1) legal complexities involving international shipping
2) employee time/productivity management that is uniform worldwide

Check out the archived GPU-mining threads. There were posts from some Finnish guy who had his mining farm on a balcony and described how he kept the snow out and dealt with the moisture.

One more argument for the Bitcoin ASIC designers that building a dedicated on-chip testing functionality is a waste of resources. Perhaps BISC (Built-In Self-Calibration) would be a productive use of silicon?

What can I say? You are just an ignorant idiot. I even provided the links describing the differences between UK and US electrical wiring.

I'm all for capitalism and transfer of capital from stupid people in "old world" to smart people in "new world".

But what is now happening here is a sort of homicide/suicide pact done over the web forum. A homicide on the part of idiot giving the advice. Suicide on the part of idiot willing to follow the advice. It is a significant step beyond simple transfer of capital.

Thus far the worst occurrence related to Bitcoin mining was one guy suffering heat-stroke or brain-stroke after falling asleep in his very hot bedroom filled with mining equipment.

What is happening here (if followed literally to completion) will quite probably end in actual injury or death of boscocoin. The libertarian in me isn't really against it, if boscocoin has a death wish then let him fulfill it. But it may be a bad marketing for Spondoolies if boscocoin kills himself trying to install their miner.  So I'm somewhat torn ethically. On one hand I'm not really against ruthless people (like bobsag3 and klondike_bar) ripping off naive people. But when the ruthlessness moves into potential death-causing misadventures, I think I'm ethically obliged to raise an alarm.

I'll wait for the comment from the Israeli people who manage this thread.