For sure a nonce cannot be re-used - so in a P2P situation each client would make sure it does not allow nonce re-use to occur so this is easily prevented (it just requires storage space for old nonces which could perhaps be reduced by prefixing nonces with say a date to allow for the later removal of old nonces).

Okay - these are very good points and it is not a "true OTP" at all (for the obvious reason you pointed out) but is instead a PRNG key stretcher (starting with a shared secret). In order to never re-use the same "pseudo OTP" (is that term acceptable?) a message nonce is combined with the shared secret (the nonce itself would be sourced from /dev/random or equivalent).

Of course the "shared secret" could also be determined using ECDSA key pairs (as an alternate to using GPG or some other method of communicating the shared secret).

Strange that you'd bother typing it then (and why are you so keen to become the teacher to someone who you are are so keen to insult?).

If you haven't gathered what the purpose of this topic is (and the previous one linked to in the OP) then that isn't my problem.

Enjoy venting!

If you really want someone to actually read a very long reply (which presumably you must have wasted quite a bit of time typing) then next time I'd suggest not starting it with that.

Not as yet.

In regards to a minimum program size understand that things like "standard I/O" don't apply to AT so basically you would need to look at something closer to cross compiling I think (just like people creating programs for CPUs that don't have an OS - and note that at this stage there is not even a "heap").

Over time the plan is to extend the AT API to include more and more functionality to make it easier for standard systems such as GCC to work with it.

You can be a *lot more confident* than that.

There *was no double spend* as *you simply cannot double spend* because otherwise Bitcoin would have *no point to exist*.

"If you don't like what you see here - get the funk out."

(Extreme II)

True - but they are also trying to convince everyone to use their own browser (something we are not planning to do).

Also it should be noted that if we get GCC to do AT then you'll have every fancy tool you could ever want at your disposal.

Interesting - not a single question about any algo I have (supposedly) written but instead a lot of lecturing (funny how people are so happy to tell you not to write any code rather than review any code you have written).

For all you armchair critics know I have simply put a standard OpenSSL call in a function wrapper!



As for the NSA it is not paranoia but actual known issues made public by Wikileaks that I am referring to.

Personally I think it would be really strange that true cypherfunks would be so adverse to helping people who are trying to work out how to play with encryption.

If they really are so arrogant then it is clear why they have lost to the NSA and other such organisations.

I think you have mistaken me for someone naively creating a "new crypto algo".

I am not doing that at all (SHA256 is actually used by Linux systems for /var/random when physical random data is not available - so unless you are going to suggest that the Linux kernel devs are idiots then perhaps you can stop comparing me to some newbies).

It is interesting how the "arrogance" of the above posts (you referenced) came about - if I were the NSA and I wanted to stop anyone questioning about crypto that is exactly the approach I think I'd use also.

Perhaps the cypherfunks were too naive themselves - they got infiltrated by NSA and didn't even realise it - so next thing they are recommending everyone in the world to not think and just do what they are told with the banner "trust us".

If I were a cypherfunk then I think I would be *ashamed* to be so quiet.

Good points - I am not inventing a new type of cypher.

The idea of a OTP is at least hundreds of years old.

The only idea I would ask anyone to accept is that "secure hashes are secure" (as many other crypto algos work upon that assumption I don't think I have violated any sacrosanct idea).

If SHA256 is not secure then Bitcoin should have already been destroyed (and that is the OTP method that I use).

A good point - as stated - this topic is not intended for those without the necessary skills (the question I am raising is exactly how much skill is required).

Many have tried to point out that I should be incompetent to create a brainwallet - yet my brainwallet stands (and anyone with any brains knows that there are bots working 24x7 to crack brainwallets).

So I accept your criticism but also just point out that I am somehow able to beat the odds (do you think that is just luck - especially after I've published my address for months?).

So let's start with a very simple but important thing - the "one time pad".

It is actually the best method of encryption in existence as it only relies upon the two sides having a shared secret at one point in time.

Before asymmetrical crypto was implemented the issue was "how to exchange keys" but of course that is now much easier using DSA technology. There is still however some problems with trusting the keys that are used that could only be solved by offline (or direct) communication.

But assuming we are happy that we have solved the issue of exchanging a key (whether via GPG or an in person meeting) then we can start to build a secure method to exchange messages without needing to use any 3rd party software.

I created a topic about "brainwallets" that some of you might have followed (https://bitcointalk.org/index.php?topic=885616.0) where I challenged the idea that "no-one can create a secure brainwallet".

I pointed out my own brainwallet address with 1 BTC (https://blockchain.info/address/1Au4v6dZacFVsWXeKUMJd99AtyBZeqti2L) and it still has that 1 BTC there (so those wanting to show that you can't create a good brainwallet are not doing a good job in that they seemingly are unable to sweep that 1 BTC and it has been there for a long time - and as I took out 9 BTC previously the public key is available also).

My next challenge to conventional thinking is with crypto itself. We are constantly told *don't roll your own crypto* and for sure just like *don't create a brainwallet* it is not something that *anyone can do* but I think that those who are smart enough to create a brainwallet should also be thinking about exercising their skills at creating crypto (if they are keen to work out how to do so).

Why?

Because maybe you shouldn't trust anyone else to create it for you.

Everyone here should be well aware that any publicly created crypto could likely have been influenced by the NSA or other groups (as has already been exposed by Wikileaks and others).

So I prefer that we discuss ways of creating new crypto rather than saying "we can't discuss that as we are not qualified". As that is the easiest argument to force everyone to use unsafe software (i.e. don't think for yourself just use what *we say you should use*).

Glad to know - I will make a note to update all the test cases (as many of the op codes are going to have the same issues). Unfortunately when the test cases were first created the precise syntax had not been worked out (am happy to see that burstdev has been very accurate to what had been intended). This was mostly an issue of the "list" output from the original C++ prototype and the Java version of that (rather than an issue with the specification itself).

The use of @ indicates a variable to be "assigned" whereas the use of $ indicates a variable to be "read" (of course @ could mean read and write but $ should never indicate write and normally the first variable will be the one to be assigned if there are two).

Creating a simple and consistent syntax for a "virtual CPU" is actually not so easy (as I discovered).

I will say that you are in good hands with the Burst developer as he has even corrected myself over inconsistencies with AT.

If you are keen to participate more with AT then feel free to make more direct contact with those involved to become "part of the team" (there is no intention to make ATs "too hard" but we are at the very start of creating tools to make that easier so I hope people can be tolerant while we work on making it more accessible).

Apart from using a "testnet" you could use the C++ prototype, however, it can only emulate API functions with appropriately provided test data (and doesn't implement the A and B 256 bit registers at this stage).

I agree that it would make things easier to have a better "emulator" for testing (but am unfortunately rather too busy at the moment to put a lot more effort into the C++ prototype).

Perhaps this is something that Burst could consider creating (having an Assembler tool is a great start as writing pure machine code is very time consuming).

Whilst what you say makes some sense the point is that no-one except "nerds" will use Bitcoin Core anyway (it was never really designed for non-technical users and nor should it be if we want to actually be the backbone for other platforms).

There are still many people that don't trust internet banking (and in fact maybe they are not so stupid when you look at the way the problems that HTTPS has been facing with the NSA and others determined to weaken it for their own purposes) but until you can create a Bitcoin account using online banking (and have it insured) then you are never going to see much more widespread adoption (in the Western world) than we already have achieved IMO (although a complete collapse in confidence that people have for fiat currencies could change that).

The other main point is that you are looking at things the wrong way around - instead of trying to weaken the back-end to suit your front-end use case you need to improve your front-end to work with a more secure back-end (which is what any bank wanting to provide Bitcoin accounts for their customers would do).

Your job is to make a Bitcoin client/service work as securely as possible without the user being inconvenienced (i.e. it should be very simple for them to use but still as secure as possible).

Most welcome - the ideas are the easy part (it is only in the coding that the blood, sweat and tears will appear).

If the private key(s) are encrypted client-side then also tx signing can be done client-side meaning that the server would never be able to actually spend any BTC from any client (the main issue is whether the clients can trust the .js they are running).