For those not aware AT has gone *mainnet* now with Burst (and we are expecting Qora to go live soon also).

There is still a bounty to get AT implemented on a Bitcoin clone so hopefully we'll see that happening soon also.

A simple assembler has been written for AT and others are now looking into getting GCC to be able to create AT machine code (in which case you would be able to pick whichever language you prefer to write them in).

If revealing an address helped then we'd have a more serious issue (as that would mean that RIPEMD160 is not a secure hash algo).

I didn't reveal the address I did for any other reason except to prove that the funds (originally 10 BTC and now 1 BTC) are still there after a very long time (so none of the bots that try and crack brainwallets have been able to crack it).

It was actually a "canary" address (back when it held 10 BTC and when BTC wasn't worth so much) although because I have re-used the address (meaning the public key has been published) it now only serves the purpose of proving that it isn't so easy to crack a brain wallet.

IMO having a single blockchain (working with a single proof mechanism) is a "single point of failure" so that is why AT has been designed to be bolted on to different blockchains.

Also I will presenting a new type of "proof" which I have been very busily working on (am getting some math analysis done before I publish anything) which will be part of a platform for creating blockchains and blockchain applications.

The first blockchain to go live with AT is Burst (https://bitcointalk.org/index.php?topic=731923.msg9910950#msg9910950) so to qualify for this script implementation of AT bounty the actual atomic cross-chain transfer can be done using Burst (although I am guessing that Qora will also be live before the end of the year).

So my guess is that you'd be surprised that my brainwallet requires no such tools and is far less than 12 words (of course there are no dictionary words involved).

It was actually created as a test to see if it would have its funds stolen (I am rather surprised the funds are still there after so much time).

True - but the simpler the software the better (in terms of being able to access your funds even when you are on holidays, etc.).

And being able to sign a tx without being online is an important feature for security IMO.

Actually even that won't be necessary down the track as ATs could be created that will pass on messages to people wanting to query "asks and bids" (the future will not be centralised).

Although I am not going to give out any precise clues as to how I created my own brainwallet clearly words that appear in any dictionary are not what you should use (and hashes of dictionary words are really no better).

If you were going to use hashing then you'd want to use "salt" and "rounds" also (and in any case is not really a "brainwallet" anymore as now you need software to unlock it).

I will answer on his behalf that the "atomic cross-chain transfer" AT use case will be the first one to be built on both blockchains which will allow Burst and Qora transfers to occur in a trustless manner without a 3rd party.

I guess the point I was trying to make is that although it is a skill (and I like your Parkour analogy) it is still "possible" to create good brainwallets (and I do agree that it is not a common skill and so I do understand not recommending the use of brainwallets for most).

Perhaps it is the sort of "nanny state" attitude that was annoying me (so many people trying to suggest you *can't create a secure brainwallet*) so I just wanted to show people here that I actually *have* a secure brainwallet (funds are still there) and I don't think I am some sort of "freak of nature" for being able create that.

Sure - but any clients that continue to rely upon random numbers for sigs are going to be future targets for thefts (as there is simply no way that the client can guarantee the random number generator it is relying upon isn't rigged).

Perhaps what is best is that the "safety rating" of any particular wallet takes this into account (most end users are not going to understand the tech but they can understand a "poor safety" rating or the like).

Was not aware of that - thanks for the link.

Unfortunately all sig methods are problematic (whether deterministic or not) and some smart people have shown ways that you can have corrupt software disclose your private keys without you even knowing.

I don't think we have any current way to be safe from that.

Fighting is rather pointless - let's just try and help each other with useful information.

This is the link you are interested in: https://bitcointalk.org/index.php?topic=581411.0

It's funny - but as soon as I learned that ECDSA (at least in terms of what is used by Bitcoin) relied upon random values I saw a weakness.

So although not happy about it I am not surprised that we have ended up with this situation (I've never liked the idea of relying upon random numbers).

It certainly was their code that was crappy - it lacked initialisation that led to the cracking of private keys (maybe you need to read up more on what happened).


For sure deterministic sigs will get rid of the problems of poor random values (but of course that won't get rid of all problems).

Interesting - as the feedback I'd got from gmaxwell was that he didn't think that the RFC should be used.


If not ECDSA then what (RSA)?

We have seen a big problem with compromised private keys due to bad random values used by crappy .js code (and this is not the first time we have seen such things) yet the Bitcoin devs seem to not be very enthused about changing things (presumably they are very busy with other things but I am asking them to consider what is most important at the moment).

I think this needs to be elevated to priority #1 as if people can't trust their private keys due to poor RNG (and we have been made aware that the NSA seems quite determined to compromise RNGs as much as they can) then we can't really trust anything to keep BTC safe.

We need deterministic sigs and we need them ASAP - if there is an issue with RFC 6979 then please solve it via another RFC or create a BIP that achieves the same thing.

The main thing is - stop with not doing anything and let's get deterministic sigs happening so no further such issues as have happened recently with blockchain.info happen again.

Oh - in that case it must have changed quite a bit from when I last examined it - it is now implemented as a sidechain (in accordance with the spec. for those or are you just using the same nomenclature)?