Understand that you can do a "decoderawtransaction" on the "offline computer" before you bother to sign it and create the final QR code (and understand that the particular QR code being used is only big enough to hold a couple of hundred bytes).

So unless we are talking about your *offline* computer being compromised then we are not seriously talking about a possible "attack vector" are we (and okay I am happy to change 0% to let's say 0.00001%)?

The is getting rather OT but what kind of exploit can you possibly have when we are talking about signing a tx offline (either it is going to be signed or it isn't)?

You see a risk with using QR codes for comms?
(I see risk when you use USB like Armory does)

Sure - and agreed -  but understand that the post I replied to was already OT as the OP was about Java (not JavaScript).

Allow me to answer this in another way.

If you are wanting to use either bitaddress.org or brainwallet.org (or anything else similar) then the approach that I would recommend is:

1) Buy and old laptop that has no WiFi (or *remove* the WiFi card).

2) Plug up ethernet and modem (depending on how old) sockets so it can't "accidentally" get connected.

Use a bootable USB OS that has your preferred .js scripts and .html pages *pre-installed* (http://susestudio.com/a/kp8B3G/ciyam-safe if interested).

Use QR codes to move data between your *offline*and *online* computers (100% *air-gapped* and 0% risk).

The actual ISO name is ECMAScript (http://en.wikipedia.org/wiki/ECMAScript) and as stated by others apart from using the name Java as part of its more commonly known name (a decision likely made by Netscape to try and "cash in" on the success of Sun's Java by renaming what was originally called LiveScript to JavaScript) the two languages have technically nothing more in common then they do with C or C++ (i.e. just some syntactic similarities).

Second task completed by K1773R:

https://github.com/ciyam/ciyam/commit/2287caff6d4328f75b28aabfc2426d1fc065cd70

and

http://blockchain.info/tx/f39b95b266ca9b48c79de235810800810fda0ca90efa6c63fe968e740c6d90ea

Congratulations to K1773R!

Interesting - at the top of both of those tx's the following appears on blockchain.info:

Unable to decode input address (followed by a small BTC amount)

and looking at the "Output Scripts" the script for the above reads as this:


Strange indeed.

There is another "unable to decode output" at the end of the list (with 0 BTC which perhaps makes more sense as being some sort of message to "identify" the mining pool?).

Sure - I understand that a C++ web app generator must seem a bit like some sort of Analytical Engine (http://en.wikipedia.org/wiki/Charles_Babbage#Analytical_Engine) to many on this forum.

But understand that by using C++ you can create *faster* and *more secure* web apps than nearly anyone else can (and by doing Software Manufacturing you aren't writing a single line of C++ nor do you have to even look at the source code if you aren't interested in that)!


There is not a large amount of docco yet (when I get more time I will be doing a lot more work on this) but I have put what is currently there up on the website (http://ciyam.org/docs/) and in particular regarding "Software Manufacturing" you should read this one: http://ciyam.org/docs/methodology.html.


That could be done but would be a rather huge task (the system took 10+ years to build) - if anyone wants to devote the time and effort towards doing that then they would be more than welcome to.

That's *exactly* what I do - so how does that "discount it for your case" (it is open source and is already on github so you don't need anything from me to order to use it - just clone it)?

In order to help the non-GPG potential workforce to easily "join in" we are now working on OpenID "sign ups" (so you will be able to use your Google or Facebook account, etc.) - this is still "under wraps" for the "public launch" so stay tuned!

It can be done *better* than that (http://ciyam.org/open) - if you are interested to "sign up" and test then just PM me.

(Xenland already has a Project there)

The "minimum" transaction fee has been lowered before and if the "fiat value" of a bitcoin rises a lot more then I'd expect it to be lowered again.

Note that provided you aren't receiving tons of small payments (which if you don't mine with a pool or play SD you aren't likely to have) then you can set your client to pay 0 fees and that will work provided your coins are "old enough" (although txs with zero fees can take longer to be initially "confirmed").

I think that if you are smart then a brainwallet is really not too hard to do. The problem that we are really trying to deal with here (as far as I can tell) is to help those that are "not so smart" (and therefore are unable to create a secure brainwallet).

So I would think that your brainwallet is safe (as I do mine and I welcome the challenge of anyone that wants to try and crack mine - there is a *lot* of BTC there to steal if you can).

Pretty much correct - to spend an "unspent output" (i.e. a part of your total BTC "balance") you must include the public key for the address and a script signature (so it can be verified). At that point any other "unspent outputs" to that same address are *more vulnerable* as your public key is now known (before only a RIPEMD hash was known).


A transaction is actually a "script" that can have multiple inputs and outputs with the "inputs" being either "coinbase" (from mining) or "unspent outputs" (from transactions that were sending funds to yourself).

Each "input" must be completely spent (fees are actually the total amount of the inputs minus the total outputs so you effectively don't spend a small amount of your inputs in order to "pay a fee").

Typically your input(s) are not going to exactly match the amount you want to send and so a "change" address is added as another output to solve this.


The network has nothing to do with it - your client will "somewhat" randomly choose which "unspent outputs" to use (with some checks to avoid you needing to pay too much in fees).

It's can be very easily edited/extended (just do a view source and you'll see it's quite readable) - also if anyone has enough interest to dedicate some time working on extending this then I will be happy to put up a task for it on CIYAM Open and allocate at least a bitcoin or two towards the effort.

The case *is* crucial - you are probably seeing the effect of looking up "firstbits" which is when you do a search on the first x characters for an address (that search is case insensitive and merely tries the match the *first* address that starts case insensitively with what you typed as a convenience for "vanity address" usage).

You can search for 1CIYAM and you'll find my vanity address but if you sent anything to 1CIYAM... rather than 1ciyam... you would be sending it to the "great bit bucket in the sky"!

I agree with the use of scrypt (which I use in my offline key generation) and many of the other good suggestions.

Creating a secure "brainwallet" is actually very difficult (as Gavin has pointed out).

The "memory key" idea I have created (http://ciyam.org/memory_key.html) is another way to help - but of course if you want to create something "impossible" to brute force you need to be "creative" and you need to "work at it" (it can take quite a while to come up with something good enough).

I am willing to "test" publicly what *I* can come up with but of course I don't think that the same approach would necessarily work for others.

The problem of creating "secure" passwords has become "the problem" of our time as the "brute force power' has become so strong that a "new approach" is very much needed (if we are ever going to be able to get the "mums and dads" little own "grandmas and grandpas" using it successfully).

Minimum browser requirements for using CIYAM Open's "client side encryption over plain HTTP" and *why*

From another thread I gather there is still a bit of confusion about why .js support and some newer DOM features (sessionStorage and localStorage in particular) are necessary.

CIYAM Open is *not* using "https" (although of course this can be added if people really want it in which case the client side encryption would simply not occur as encrypting *twice* is of course going to slow everything down as has already been noticed with Mega's approach) and so one cannot put anything "important" in a cookie as it can be "spied" upon (in the clear).

Now also in order for the client to be able to generate the OTP it needs to do *crypto* which you're not going to be doing without Javascript (am not interested in doing such things in Java for various reasons - perhaps the most obvious the recent warnings about trusting it) so you *need* Javascript support (and you *need* it to be switched on).

You also *need* to have the sessionStorage and localStorage DOM objects available. The sessionStorage is where your "password secret hash" (that is *never* transmitted) is stored (after you type in your password to log in). Later when I add in the ability to "stay logged in" the localStorage object is required in order to persist this hash (and yes - things are less secure if you elect to use that feature).

Hope that helps clarify things.

Unfortunately no can do - this is *client side crypto done over plain HTTP* which is only suitable for browsers that support sessionStorage (but I will add be adding an error message if the object is null).