Boscocoin, you are getting trolled really hard by bobsag3. I don't even know how to call this type of homicidal trolling where an US based non-electrician gives an electric advice to the UK based non-electrician.

bobsag3 who lives in the USA doesn't understand the typical US split-phase wiring.
http://en.wikipedia.org/wiki/Electrical_wiring_in_North_America
http://en.wikipedia.org/wiki/Split-phase_electric_power

boscocoin who lives in the UK doesn't understand the typical UK ring circuit wiring.
http://en.wikipedia.org/wiki/Electrical_wiring_in_the_United_Kingdom
http://en.wikipedia.org/wiki/Ring_circuit

I wonder if boscocoin could somehow order US-style electrical devices with delivery to the UK address and then install them into ring circuit in his home. That would necessarily end with electrical fire or electrocution. Would that be a "homicide through a web forum advice" or "death by misadventure and terminal stupidity"?

LevelDB is an educational toy database. Ripping this out and replacing it with something professional-grade without doing a major rewrite is sure to find buyers.

Yeah, this torrent is a good one to debug your connection. I have one machine seeding it and I see various clients reporting download speed in the range from 10kB/s to 10MB/s (100kbps to 100Mbps).

Nobody yells "Freeze!" anymore. AFAIK all law enforcement is now trained to first create a distraction by e.g. activating the alarm on the suspect's car. There's apparently a great overlap between various computer hackers/fraudsters and the expensive car enthusiasts. Only after the suspect runs away from the computer he gets served with the warrant.

It wasn't "feeble authentication", it was "feeble anti-denial-of-service defense".

What you proposing is workable, but worsens the denial-of-service attacks by increasing the CPU load. The better way would be to lower the number of rounds instead of increasing it, or change other constants that have no influence of the CPU load. If the goal is to simply make an unmodified program unable to connect then the simplest and least CPU intensive solution is to change the handshaking prompts/response. At least the failure will be immediate and will not require any CPU intensive cryptography before the disconnect.

Port knocking (properly, intelligently implemented) is not an authentication measure, but anti-DoS, anti-scan & anti-brute-force measure. Only after successful port knocking the regular, CPU-intensive authentication can be attempted. Without proper port knock nearly all port-scans will fail and nearly all incoming packets are ignored. The objective is to prevent from creating any meaningful load on the defended equipment, no matter what the network protocol is being attacked. I find it quite common that people underestimate the CPU and network load that the SSH daemon under attack can create on a machine.
I don't consider Cisco's implementation (Lock&Key) a "venerable" implementation, it is basically a telnet login (on an alternate port) that always looks like failure. But it is reasonably successful in its main goal: drastically reducing the CPU load on the attacked router/switch and making brute-forcing of any equipment behind it impossible. For any OS different than Cisco IOS there are much better port-knocking implementations available. But the Cisco's implementation is probably the most widely used one and therefore still worth mentioning despite being phased-out and considered obsolete.

Well, the Svartholm case is still open, but is the good example of "prosecuting a person" is not the same as "prosecuting a computer with certain IP address". There are other cases, where such a defense was successful.

While I don't know the specifics of Ulbrich's case I recognize a pattern in similar cases: getting lazy and mentally attached to the same laptop with favorite OS,  same network adapter, same phone, same SIM-card, etc. Nobody will comment publicly on pending/unsolved cases, but I've heard some non-public comments from my friends in IT. I've also seen what a skilled sys-admin can do on a Windows Home Edition hotel-loaner machine with telnet and IPsec control panel. I think I have a broad understanding of which cases weren't prosecuted and why.

But in general discussing security on an open forum is difficult for a professional. Nearly every person that I know will have the knowledge that is "off record" and shared only with friends. There's this old saying: "Those who know, don't tell. Those who tell, don't know."

Feds already had the server, they didn't need to hack into it. The feds were trying to locate the owner of the server and collect the evidence.

I proposed to use widely known & deployed technologies (IPsec&Kerberos) for which attacks are theoretical/academic or of concern to the paranoia-security-set only. A form of port knocking is still widely deployed and used on nearly all Cisco IOS routers/switches (Cisco Lock&Key) and nobody is proposing that as an only line of defense, only as the first one, essentially a defense against port-scanning and password-brute-forcing.

What you proposed is a textbook example of "security by obscurity": changing a constant in the cipher implementation. I still think that "security by obscurity" is a valuable tool in evasion and counter-intelligence, but not discussed in the cryptography textbooks.

I reread your posts in this thread and I noticed that you've numerous times tried to switch the subject of the discussion. Normally I would suggest the standard "switch to decaf", but this thread is about Silk Road and they didn't sell coffee. So I don't know what you should switch to, sorry.

Yeah, mythical omnipotent "Feds" with access to secret OS-independent "0days" that hack back the telnet clients (not the server)! I think this the new height of paranoia that I've encountered.
 

I don't think you have your threat model right for the things you keep proposing. Or maybe you keep changing your threat model, I don't fully understand your writing.

What I proposed was an excellent defense for a single person trying to evade being by using various locations and various machines with various OS-es. As a second line of defense if located that single person wants to hide behind plausible deniability to evade or weaken prosecution.

What you were originally proposing (modifying a cipher by changing an implementation constant) would be a decent defense for an already known group of people (lets say a fraternity) who want to hide their internal communication from competing groups (other malicious pranking fraternity) and also spread and weaken possible prosecution of their own malicious pranks.

I still disagree with you. The knowledge and access to "the private bitbucket server" is still very incriminating.
And this:
is just a trope. Security through obscurity is an excellent defense when the defending group is small (like one person). Intelligent port knocking will look quite innocuous and will enable a range (or ranges) of possible sources, not a single address. And instead of SSH (Swiss Army Crutch of bad sysadmins) use good old telnet reinforced with IPsec or Kerberos.

Your advice is questionable legally and operationally.

1) From the legal point of view, finding such a modified software would be a definite proof that the law enforcement located a true culprit
2) From the operational point of view the need to compile/carry your own modified software makes it difficult to be truly mobile and evasive

While "port knocking" could be construed a "security theater" it has offsetting advantages.

1) From the operational point of view intelligent port knocking can be done without specific tools. You can do it yourselves from any computer or you can describe it to somebody over the phone and have unrelated people knock on your ports to disperse the attention and the resources of the adversary
2) From the legal point of view it would be easier to "reasonably deny" the actions made using a shared/unmodified computer. Like one of the PirateBay guys who's now imprisoned and all the evidence prosecution has was from a machine anyone in his office could access.

I think your methodology is very similar to the "network coordinates" technology from Harvard.

They piggybacked it on Azureus (a bittorrent client) and it was used for a while under the name Vivaldi.

Here's the link I was able to find quickly:

https://www.usenix.org/legacy/events/nsdi07/tech/full_papers/ledlie/ledlie_html/index.html

but there are much better papers about the subject, I just can't recall the specifics anymore.

Personally I think this is an internet age reinvention of the geocentric astronomy and the mathematical model that allowed the geocentric astronomers achieve a tolerable accuracy.

Edit: Also, a Wikipedia link:

http://en.wikipedia.org/wiki/Vivaldi_coordinates

It works just fine (and for more than one coin) provided:

1) don't change the coin's default P2P port, you'll get de-prioritized and will get less connections
2) the arguments processing is somewhat convoluted and the "testnet" daemon will look into "mainnet" .conf file, therefore it is better to have single such file and set the "testnet" (and others that you want to differ) through the command line. You can leave "port" and "rpcport" at the defaults.

I've been running 4 coin daemons on a single computer with a single hard-linked *.conf file for many years now.

Edit: I forgot about one thing:

3) it seems like some hackers monitor coins P2P networks for IP addresses running multiple daemons and do extremely aggressive scans for hackable services on those addresses. Maybe they think that they discovered a coin exchange or some such high-value target? Don't know the real reason, but observed this effect multiple times. So if you are e.g. running sshd on the default port on the same IP address prepare to have serious CPU load from failed ssh login attempts.

Raspbery Pi actually has a very efficient parallel processor available on chip: AlphaMosaic VideoCore. The problem is that its architecture and toolchain are secret and can only be obtained after signing a very expensive NDA with Broadcom.

Programming AmVc would certainly be very stimulating intellectual experience, but you won't be able to share it here.

So this "semantic leak" is now only apparent in the block layout on the wire and on the disk? But the "abstract virtual machine" of Bitcoin script cannot discover its internal bit ordering? Do I understand you right?

Then can you state again what is the possible attack that the "opcode limit" is protecting against?

Thanks.

I'm sorry I haven't kept with the advances in the theoretical computer science. But I believe we have already discussed the "non-TC" chestnut here and the consensus was that one can abuse P2SH to escape the "no-loops" restriction.

Let me try to dig the thread and I will edit this message later. Edit:

https://bitcointalk.org/index.php?topic=431513.msg6533466#msg6533466

The operative words were "opcode limit" in the "Turing complete language vs non-Turing complete (Ethereum vs Bitcoin)" thread.

I apologize for writing too ambiguously the first time. I'm going to try to linearize my thoughts better now:

1) Given the current Bitcoin script language with the following problems (amongst others):

1a) implicit conversions between integers and bit strings with semantics depending on precise detail of OpenSSL implementation (word size, word order in a large integer, byte order in a word)
1b) ostensibly allowing emulating iteration by mutual recursion of P2SH invocations

2) a non-binary compatible but only morally-compatible scripting language featuring:

2a) explicit type conversion operators and type tagging of the stack storage, in particular clean conversions between integers and bit strings
2b) somehow type-safe or type-checking implementation of P2SH invocation that verifies both arguments and return values

3) will allow writing a completely new scripting interpreter

3a) in a theoretically strong programming language like a Lisp subset that is provable (Lisp because I'm most familiar with it, but there are many other candidates, I did not keep up with recent developments in the theoretical computer science)
3b) that can be mechanically/automatically verified and proven to obey certain theorems and conditions

4) said interpreter then can be translated

4a) to C/C++/Java/etc. via completely mechanical translation or manual pattern-based transliteration of a very restricted subset Lisp to be incorporated in a software-only implementation
4b) to SystemC/Verilog/VHDL/etc. to be synthesized into a logic circuit (with stack memory) for the hardware-assisted implementations and for additional verification

The 4a) output in a restricted C++ subset could then replace the current, completely improvised, implementation in Bitcoin core. Because of subset C++ use it most likely would be longer in terms of lines of code, but it would be also much simpler to analyze.

The 3b) step has an additional problem that all the existing Lisp provers use only conventional ring of integers arithmetic. Since Bitcoin depends on an elliptic curve over a finite field the proving software would have to be extended to efficiently handle that. From my school days algebra I remember that the stratification group->ring->field significantly influences the complexity of proofs. Sliding back from "ring of integers" to "abelian group of elliptic curves" could potentially greatly reduce the set of theorems that could be mechanically proven.

I realize that the points 1-4 still read like a complex sentence in a patent application. I'm not good at writing easy to read essays. But from the purely technical point of view the two-level process is the way to maximize correctness (1st language for proving/verification, 2nd language for implementation/integration).
 

This claim about "typed data" and "provability" is false. There are actual proofs of that coming from the people involved in designing/implementing Algol 68. I don't have any references handy, but in broad terms the progression "classic Von Neumann" -> "type-tagged Von Neumann" -> "static-typed Von Neumann/Harvard modification" strictly increases the set of programs that have provable results. I also remember than in the USA IBM did pay for some academic research about "PL/I without implicit type coercion" that had similar results.

As an aside to the theoretical results: in school I had side income helping debug/fix/extend several RPN-style / Forth-style language interpreters including then-popular commercial implementations by Tektronix & HP in their IEEE-488 lab-control equipment. For that application type-tagging was (and is) a godsend both for human programming and for automated program analysis/translation.

Imagine what you could achieve if you actually opened the Spondoolies' cases and blew the air over their radiators using large centrifugal fans. Obviously, don't do that with customer's equipment, experiment with your own. I understand that as a prepaid hoster, you care very little MTTR/MCTR, downtime isn't hitting your pocket. Also, the expected useful lifetime of Bitcoin miner is much shorter than a general purpose server, so you may in fact see very little failures before your customers liquidate their equipment.

I've posted couple of months ago on the Spondoolies' thread regarding just that:

The physics of it is really simple: it doesn't make sense to first concentrate the heat only to dissipate it right afterwards. But my point of view is different than yours, you are just providing the hosting service, whereas I talk like end-user minimizing the overall costs. Your customers obviously do care about the appearances, whereas I cared much more about things like avoiding downtime, minimizing staff workload, maximizing their morale and nearly zero about how it looked.

Essentially there's nothing wrong with what you wrote above, except that it shows that you don't understand the needs of a premium property landlord. "Keeping the lights on" takes much more than simply keeping the light on: the property needs to be attractive, safe, desirable, etc. To be honest I don't completely understand the large landlords either, but at least I spoke (not negotiated) with them on several occasions and have some understanding. Neither did I work for Victoria's Secret, but again spoke with friends who did. What I could say:

If somebody comes with an idea how to turn hot aisles in their Bitcoin mine towards the windows and combine it with bikini fashion show in those hot aisles, then landlords like CBRE will offer you really competitive electricity prices with their leases. The only downside will be that you'll have to travel worldwide, but again CBRE will cover the costs.

I get a tingle that you are getting closer to understanding dealing with large landlords.

Ha ha, impeded airflow! One of my coworkers had actual numbers for MTTR (Mean Time To Repair/Reconfigure/Replace) and MCTR ('Cost' instead of 'Time') for tight racks vs. slack racks (after a merger of two companies with vastly different cultures) and the numbers aren't supporting the claims of the OCD crowd.

I however understand your position when marketing yourself to the owners of Spondoolies' hardware which is in large part "status symbol" crowd.

Obviously they have the "right to kick/ban". The question: is do they really want to do it? Stupid anti-DoS defenses are actually quite common way how people loose market reach of their web portals when their target audience moves to a different way of accessing the Internet.