It should be no harder to build AT into a CryptoNote system than any other blockchain (and I don't believe it is a huge task to do so).

In the future I would hope that the *only laws* that matter are those governed by the *laws of mathematics*.

All other laws are really not something very useful (just look at the "great job" that governments all over the whole world are doing with monetary laws).

You would be most welcome to use this: http://ciyam.org/at

(a bounty to get an atomic cross-chain transfer between Qora and a Bitcoin/Litecoin clone has been created and it is hoped this will be achieved before the end of 2014)

There is no such thing as a "sending address" but most likely the "coin control" feature is what you are actually wanting to use (at least that is my guess).

Assuming that you are using Bitcoin Core (i.e. bitcoin-qt) then select Settings -> Options and then go to the Display tab and click "Display coin control features". When you next click on the Send button you'll now see "Coin Control Features" where you can click Inputs to find your "change address" UTXOs.

If they are invalid then other nodes would reject them - so I don't think that they could be *invalid*.

I think to make things clearer about what CIYAM is I need to perhaps draw a comparison with *gong fu* (martial arts).

When I set out to create CIYAM I had the goal of being ten times more productive than most other devs - already I have well surpassed that goal (e.g. the CIYAM Open website was created in around 5 minutes and that was done using a Galaxy S3).

So now that I have achieved more than 10x normal productivity levels I have been working on achieving 100x normal productivity levels (and am getting close to that).

Basically CIYAM is a *gong fu* for software engineers - it is a discipline and a skill set that takes a lot of effort to attain but can make the individual more powerful than most teams are.

I have clarified that the AT and AT API implementation must be open source (the rest of the platform is not my concern) and I will be publishing an AT API specification document at the end of the week.

The "atomic cross-chain transfer" AT itself will be coded by myself and will simply require that the blockchain platform correctly implements AT and the "generic fuctions" for the AT API.

When I publish the AT API I am going to "up the bounty" so those interested might want to "get cracking real soon".

Let's see if we can get an atomic cross-chain transfer to occur between to different blockchain mainnets before the end of the year.

Updated and added support for appending OP_RETURN messages (don't tell Luke Jr.).

This is only a concern for those running *full nodes* really (which is no *average Joe*) - so Joe is pretty much *fine*.

The point that AT is about is that it is *blockchain* agnostic (i.e. it doesn't care which blockchain you use).

If we end up with *only one* then AT *still works* so I don't quite get your point (*economics* is not going to *get rid of AT* for some unspecified reason when I've just pointed out that multiple blockchains are not *essential* for AT).

I somehow doubt he is going to provide that - there seems to be a few divided opinions about *what is best* for the future but certainly I think nearly all of us can agree that 7tps is not what we want to be saying about Bitcoin in a few years time.

It doesn't really matter much if you *re-use* addresses for change (the address is not the relevant thing - the UTXO *is* so each change UTXO is still another UTXO regardless of what address it is tied to).

You are indeed much better off to use "sendmany" in order to reduce your tx fees (and to reduce your number of *change* UTXOs at the same time).

You need to do some learning about how Bitcoin works first I think (change addresses are *essential* due to the fact that all UTXOs are fully spent when you create a tx that uses them).

Your issue with tiny amounts will be undoubtedly due to the way you have received your BTC (either via tiny pool payouts, ad-sigs or faucets I would guess).

You can use "coin control" to try and "reduce the UTXO bloat" but seemingly you have gone too far to want to do this all manually so you might want to look into using a script to help you (there are at least one or two available).

In short you *can't clean it up without paying fees* as you have too many very small UTXOs (lesson to be learned - don't get so many small amounts - they are more of a hassle than they are really worth).

I have been testing the CIYAM Wallet today and so far all is going pretty well (several txs involving 1 or more inputs and 1 or more outputs have all worked fine) so for those that struggle to understand the cryptic code in Bitcoin itself (I know that I do) then you might find this a little easier to follow: https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp#L705

No guarantees that it is perfect yet (still got a lot of testing to do) but it will certainly help those keen to create their own wallets to see how creating and signing raw transactions works at the *low-level*.

I regularly use "signrawtransaction" with the additional "private key(s)" arg in order to *not* have to put the private key in a wallet when doing offline signing - but if I want to sign a message *offline* then I am forced to first import the private key into the wallet.

It would be nice if we could add an extra arg to "signmessage" that is a private key (so there is no need to import it into the wallet).

I just took a quick look at their source code and it does indeed appear as though they are using Shamir's Secret Sharing algorithm (just test it and see if it works would be my suggestion).

I did state that I have the final decision and if I am unable to "see" the Script implementation (for the purposes of getting AT to work on other blockchains) then I would not be very happy.

I don't care if the majority of the coin is "closed-source" but I would be asking for the AT part (at least the Script changes) to be made public so that other blockchains can use AT.

As a general rule I don't support "closed source" and AT itself will always remain open but I am not going to dictate to others what to do with their source code.

It does not involve Oracles at all (at least for now).

The key is that AT API functions need to be O( log N ) to make sure an AT can't *clog up the works* (we may allow slower functions that cost more fees to execute down the track).

Each AT has its own memory blocks (code and data) which are fixed in size when the AT is created.

I'd assume that it would do that for you (but I am not familiar with this new version of bitaddress.org).

Assuming it is using Shamir's (and I guess so by their use of the word "shared" that confused you to start with) then it is a "multisig" concept but not the Bitcoin *multisig* concept.

So it isn't using Bitcoin multisig *just one private key* but you can get that private key by N of M people providing their "secret share" of the private key.

Hope that makes some sense.