travwill: I am very sorry for your loss of coins.

Even though your loss might be from the dropbox account. I would not trust your Mac. Anti-virus are definitely not a guaranty that your computer is virus free.

You can either re-install OS X after backup up your wallets to re-import them later. (Assuming there are no EFI rootkits installed on the Mac).
Better move your money to other wallets either on paper or on another computer dedicated to coins (always keeping a minimum of coins on a running computer).

The recommendations for VMs are valid, they increase the difficulty of getting access to the wallets from a backdoor, but they remain exposed.

For encrypted partitions, they are essentially accessible from the backdoor when they are mounted (software is running). It is of use only when your computer is powered off.

Why re-invent languages! How many times it simply better to use something that is already proven to work. But maybe this time it is worth it as I do not know much about their idea except the big lines.

On that, I still don’t understand how it could scale database size wise?

Also, with too many distributed networks out there, the security get stretched too thin as there is not enough hashing power in one place. One reason why I liked the idea of Adam Back to have a Bitcoin Beta network that eventually rolls in the production Bitcoin network.

That is great news and I support the effort.

The linux community has never made it up to Visual Studio debugging capabilities. Linux and *nix have other advantages, but not this one.
Xcode is somewhat making progress, but is still not that great yet.

Means I will need to give VS 2012 a go…

Count me in for 10x. If you have that many.

I think the value of a coin is heavily dependant on the security of the transactions. I believe that characteristic of a coin is underestimated.

The security of Bitcoins transactions is supported by the hash power.
The security of Feathercoins transactions is supported by a centralized system at the moment. I believe that system lowers the value of our FTCs.

The total hash power of a coin is very tied to it’s value for me. The more hash power and the more it is distributed, the more I trust in it. I trust in storing my wealth in the coins that will live long with a supportive community.

That is why I stick to mining FTC only. No hopping. Hopping is just lowering our reputation.

The more people will trade with FTC and the more people will mine FTC, the higher the value.

[quote name=“wrapper0feather” post=“43467” timestamp=“1386860838”]
Your post was close to an FMEA, there was no priority analysis or comparison of the effectiveness of any action to prevent this fault. All maintenance actions need to be against the Cause of failure not the symptom, to be affective.
[/quote]

I admit I did not provide any background. My judgement is based on my 26 years of experience in computer security and the fact that I have seen over and over through my life technologies exploited. In the end, it boils down to motivation by the attackers.
I think we can say that anything crypto currencies is already under attack. Network exploitation is just awaiting.

[quote]
Preventative measures can be taken, but analysis also opens up the potential of premature attack, especially if there are no resources to implement defence. Why do all the work for the attacker?
[/quote]
I am not proposing to do work for the attackers, they, like me, already know how to tackle and exploit a software stack.
I am only proposing to hardened some nodes on the network. I can attest that I am running one with added security features already, but I am only one and I would like to share the know how with others.

[quote]
That is one reason Feathercoin has kept with the Bitcoin protocol unless forced to act on real attack vector.
[/quote]
I agree with you this, the idea to start from something proven working is certainly good combined with the fact that Feathercoin was put together really fast with very little time and resources. Nothing wrong there. It remains that ‘all’ crypto coins are using the same protocol out there.

[quote]
The other thing is, these have already been noted as modes of Failure, development of the forum and community is one of the Task that has been implement to guard against this possibility of failure already.
[/quote]
I will check those out.

[quote]
Condition monitoring of a fault is usually the most effective option if there is a monitor-able symptom available. Planned Maintenance is next, Last of all, and most dangerous, is Design Out.

This is because design out is prone to unknown difficulties and you always have to deal with consequential bugs.
Another mode of failure Feathercoin is experiencing is diversion from it’s core development area. At the moment forum expertise is thinning due to it being spread supporting the massive influx of new members. This is an Current, actual fault heppening now, we need to deal with on a high priority basis.
[/quote]
I understand very well and I support you.
In the meantime, we are all vulnerable to worm attacks that I described in the forum.
The actions I am taking are not taking away any resources from the Feathercoin community and it is not my intention. I am putting my time where I think it is worth it.

[quote]
The action we have taken is to educate and bring on new members. Updating the web site and adding guides.
[/quote]
Great work :)

[quote]
Also, this post should have been posted in the [b]Attacks and Security[/b] section of the forum. The technical development area was specifically set up to develop feathercoind and feathercoin-Qt, there are other forum areas for other related topics.
[/quote]
I want to apologize about this. I just found it. Somehow I lost track of it. Any moderator could move this thread in it?

[quote]
Ideas are great, implementation is the difficult part. I am involved because the real actions of the Feathercoin members and volunteer team deserves all the support I can give.
[/quote]
Cool :)

[quote]
[quote]
As to exploit JS nodes, it would come down to similar Javascript exploitation targeting the underlying JS engine, which is often written in C++
Sometimes harder, but sometimes the JS is very powerful, assuming you can inject JS code.
[/quote]

That’s a pretty big assumption that usually starts with the keyword ‘eval’ somewhere in the code. But even then, you’re going to be hard pressed to pull off a stack-smack given how it lays out it’s memory, and the nature of the scheduler. I suppose anything is possible, but in an OS-level exploit race between a program written in C, and one written in Javascript, my money is going to be on the C code every time.

When I was designing Link, the blockchain filesharing protocol, this was something I was hyper aware of when dealing with encoding of strings which are necessarily length-prefixed. Eventually the assumption had to be made that it would be safe to allocate 65,535 bytes for a single string, and the client would need to handle the case where the string size is less than the encoded length by detecting the invalid op-code that would follow and declare the stream corrupt, or it simply ran out of memory due to excessive allocation. Doing this in Javascript made this trivial, where as doing it in C++ would have been error prone and potentially dangerous if bad assumptions were made.
[/quote]

I agree with you, no doubt.

The nodes running BitcoinJS are typically running the lightweight version of the protocol only. But it is a step in the good direction and maybe we should push to have full nodes running on it.

As to exploit JS nodes, it would come down to similar Javascript exploitation targeting the underlying JS engine, which is often written in C++
Sometimes harder, but sometimes the JS is very powerful, assuming you can inject JS code.

No instance attested of an exploit running out there, but sometimes I wonder.

In any case, if a worm spread it will be too late to take action.

Thanks for your support :)

As posted in this thread : [url=http://forum.feathercoin.com/index.php/topic,5810.0.html]http://forum.feathercoin.com/index.php/topic,5810.0.html[/url],

we want to make the crypto coins software more robust against hacking in general.
One concern I have in particular is the homogeneity of the network at the moment. Typically, an exploit will work against a specific error in the code and will gain execution under certain conditions. To prevent an exploit to succeed, we can try to change it’s environment in a way that will make it fail.

In an effort to have different runtime versions running out there, I thought I could at least try to compile feathercoind with another compiler. Then, maybe add some more security features.

So far, we’ve got feathercoind and bitcoind compiled/running built using clang with the -fsanitize=address option flag. Although the cost is slower execution time, it is much safer from buffer overflow exploitation and makes the runtime code different from other nodes.

This is one example of what we can do.

Any ideas will help the community :)

Tomorrow I will do my best to post the steps to build feathercoind with clang/asan (Address sanitizer).