I think you'll find it's actually worse than that (from what I recall reading it won't be included in the mempool of peers at all unless you are running "testnet").

@Elwar

You are probably referring to nLockTime and yes the issue is that nLockTime txs whose time (or block) is in the future are not accepted by peers (so your client would have to re-broadcast the tx after that point in time).

It still has some value in that the tx could be manually sent to another person (thus acting like a last will) provided that they eventually broadcast in order to make sure the transfer actually happens.

@OP - this of course has nothing to do with encryption (as Bitcoin doesn't encrypt anything).

That depends on your UTXOs - you do realise that if you are using bitcoin-qt it *hides* the change addresses?

I'd say the vast majority of people using bitcoin-qt do not understand how it works well enough to be able to find their entire balance by just using say blockchain.info.

That is not correct - it will be broadcast immediately - you just won't be able to see the tx as confirmed until you have caught up.

Okay - so the main document to help with the AT machine itself is http://ciyam.org/at/at.html and the C++ prototype is here: http://ciyam.org/at/_at.cpp.html.

For the Bitcoin "script" side of things I have come up with this: http://ciyam.org/at/at_script.html.

The other key document is the AT API which is here: http://ciyam.org/at/at_api.html.

Again I am happy to help explain things to interested parties and yourself or others are welcome to send me a PM to get my Skype id if you'd like to be able to chat with me directly.

Understand that the bounty is not there so that "I do all the work" so you are only going to get answers to relevant questions (rather than *code*). If I had the spare time I'd code this myself but I am working 14 hours per day currently on the CIYAM project (and not being so young I do need to get at least 8 hours of sleep and some exercise every day).

Bounty has been upped to 20 BTC now.

Saffron has announced their interest to implement AT but not until next year so there is still a great opportunity for a talented dev to pick up this bounty before the end of this year!

Another use case in the pipeline is that of "oracles".

I have been reading about other similar ideas to AT using web services and to me that is a truly terrible idea (it is just going to make forks all the more likely).

So what I think work better is that you have a number of different oracles create their own ATs that will only accept a message from their creator as a "signal" that they can pass on if inquired upon.

An AT that wants to know the "outcome of an event" could have say have 5 of these oracle AT ids hard-coded into them. When the time is right it would send a message to each which would reply with the answer and the "majority" would become the decision that is made.

This is robust in case of new nodes (that need to run all ATs no matter how old the event was) and in terms of keeping forks limited.

Interesting - could not a simpler "hashcash" approach have been used (where x hashes are returned for x blocks each with a difficulty of y using the actual block hash and a nonce)?

He was never their *chief scientist* (that is Gavin's title).

I think this sidechain concept is very exciting and I hope that at least one dev might consider adopting AT (http://ciyam.org/at) to test Turing complete processing on a sidechain (there is already a 10 BTC bounty for a successful atomic cross-chain transfer between Qora and a Bitcoin clone on offer here: https://bitcointalk.org/index.php?topic=826263.0).

An AT for a *lottery* has already been developed so perhaps one idea might be to have a specific "lottery" side chain.

I really hope that this proposal gets adopted as it will allow for "100% air-gapped" offline tx signing to be done without needing any blockchain information (just the tx itself) in order to show the person signing the inputs, outputs, the change *and the fee* (the last not being possible currently).

Personally I have always felt that this was an oversight by Satoshi.

With Type 1 deterministic addresses if you managed to crack a private key it won't help you to crack another (you need the seed for that) but with Type 2 if you crack *any* private key then it has been proven that you can crack any other (key hardening can be used in Type 2 to make that much more difficult of course).

Having watch only wallets is not necessarily a reason to want to use Type 2 wallets (you are perhaps trading convenience for security).

It would be simple enough to generate 10K Type 1 deterministic addresses (that are based upon compressed keys) offline with a file that could hold just the public keys of these to be transferred via QR code (might take about 50-100 QR codes) which would be safer than any other method.

If you are keen on doing this then perhaps let's see if we can work out something (it is something I could add to the CIYAM Safe https://susestudio.com/a/kp8B3G/ciyam-safe).

Thanks (it seems you know this stuff better than me) - so you do agree that Type 1 is the *safer* option unless you really need the Type 2 functionality?

(I have implemented a Type 1 deterministic Wallet for CIYAM but am still weighing up whether to "go the extra mile" to provide Type 2 as well although eventually I will do so by offering a choice of either type)

Agreed - but the OP would not have wanted Type 2 if he was just after 1 private key (and stated as much).


There is a paper that was published showing how Type 2 keys (even when hardened) are not as secure as Type 1 - I have not seen a satisfactory reply to this paper yet (although I don't claim to understand all the details in order to judge it's merit myself).

Any particular reason you want type 2 deterministic addresses?

They are actually less secure than type 1 (i.e. one private key hacked means all are done).

Does this make it clearer? https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp#L538 and https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp#L54

Basically a random 256 bit number will work but it has to fit within the curve range (it is very unlikely that it won't but the sanity check is necessary).

I am using OpenSSL for the random number (as does Bitcoin as I sourced that part from Bitcoin itself) but you could of course use "hex dice" or some other method if you don't trust OpenSSL.

Great! I should have read that a bit closer sorry.

I really hope we can get that one in as it greatly simplifies offline tx signing (am willing to offer a bounty if that will help). I'm not sure why others don't like QR codes but I think they are the most secure method of doing offline tx signing.

BTW - have you noticed this? http://ciyam.org/at/at_atomic.html

It was inspired by your atomic cross-chain transfer in Bitcoin Script (I will add a link to your webpage for credit when we've got it completed).

I would really love to see an optional op code for specifying the *change amount* (the tx would be invalid if it doesn't match what the change amount actually is).

This would allow offline tx signing to be able to show the user the change amount without needing any blockchain info (a huge benefit if you want to do offline signing with a QR code like CIYAM Safe does).

You might be pushing it a bit with less than 2GB of RAM depending upon what other software you are running.

Perhaps use the Task Manager's Performance tab to get an idea of whether the PF Usage is very high in particular.

You might also want to check the Processes tab (from the View menu use Select Columns to make sure you have VM Size selected). Click on the VM Size column twice too see your biggest consumers (bitcoin-qt will be likely at the top) and maybe see if you can shut down one or two other processes.

I was in discussion today with some people from the music *industry* (for those that are not aware my major at uni was music and in particular music composition).

I have an idea that we can create an AT to *change the music world* and get rid of all the middle-men that currently control it (the main reason I did not become a professional musician).

An AT would be created by a sponsor (think about the sponsors that made all of the classical music we have if you have trouble believing that anyone would do this). This AT would wait for a proven signature from the artist that would include a hash of a hash of a poor quality version of the artwork.

Once the artist has seen that the sponsor has sent the hash of the hash (assuming they are happy that the poor quality version is what they want the high quality version to sound like) then they send the first hash and the final product is released (ensuring that they get paid). If they don't actually release a good quality product then everyone will know that (so the artist's rep would be damaged greatly).

The AT once it sees the valid hash will send the funds to the artist (if not done in time a refund would occur to the sponsor).

It requires no middle-men and allows sponsors to get recognition (if they choose to go public) for artworks (and gives the artist recognition whether or not the sponsor wants to be anonymous).