The key point is that all ATs would need to be *restored* to the previous state they had at the point of the re-org (and then re-executed).

I don't think it is *multisig* in the Bitcoin sense but instead is using Shamir's Secret Shared algo (you might want to find out more about it first).

If a re-org occurs then the ATs would need to be "re-executed" (yes - we have thought of this - obviously their state cannot be retained if they are *rolled back*).

The exact mechanism for doing this would need to be worked out for each platform (i.e. how to *undo* state).

It also partly depends upon how you *deal with the state* (i.e. it could be stored *explicitly* in txs or it could be worked out *implicitly* by just publishing hashes).

The explicit approach would make re-orgs simpler (but would cause some bloat), whilst the implicit approach would use very little space but would complicate the re-orgs.

Please PM me in order to get contact details - and there is a *bounty* on offer (currently 5 BTC) for achieving the first "mainnet" *atomic cross-chain transfer/transaction* between Qora and a Bitcoin/Litecoin (i.e. Script) clone.

That is great news - I am very supportive of where this is going!

Very nice to see you here Gavin.

The timestamp is not intended to be an *actual timestamp* but instead one that is calculated by block height and tx within the block (i.e. an *artificial timestamp*).

I only used the word "timestamp" as that *makes it easier to follow*.

I actually had thought it was your invention (sorry Matt) - but yes - I do remember hearing about it before.

The real question is do you think it is feasible to do this before the "hard-fork"?

To update - the Wallet package (and related Transaction package) changes have now been committed.

I still need to do a bunch of testing but the CIYAM Wallet is now very close to being "ready for use".

Also you may have read about the CIYAM AT project bounty (https://bitcointalk.org/index.php?topic=826263.0) - I am being contacted by several interested parties about implementing AT on other blockchains so this should be one exciting area to follow.

It is looking very likely that the *very first* atomic cross-chain transfer/transaction between two different blockchains (mainnet) could happen before the end of this year!

Sorry I don't use Twitter but feel free to do so yourself.

Yes Nxt-to-Qora would of course be possible (assuming Nxt AT goes to *mainnet*) but understand that the bounty itself is only being offered for a Qora to a Bitcoin/Litecoin clone succeeding in performing an atomic cross-chain transfer/transaction via AT between them (as Qora have said they will take AT to *mainnet* first and I then want to see a "mainnet" version of a Bitcoin/Litecoin clone also).

Keeps those wheels in your head rolling - there are likely to be more bounties down the track!

Note that this bounty is going to be added to (by myself if no-one else) as I am very keen to see this happen.

I have already been contacted by a few interested devs so those *waiting for the bounty to increase* might want to at least "get in contact" so they will still have a "chance at the bounty".

In any case *everybody wins* if AT appears on multiple chains as it means all those blockchains will be able to do things like "lotteries" and "auctions" as well as "atomic cross-chain transactions".

Oh - oops - I see - so it just *divides* the private key into "parts".

Maybe "parts" would have been a better word then (they would have to be kept in the right order so am guessing they might "prefix" each part with a number to be able to re-assemble the private key correctly).

EDIT: Now I know why they use the word "share" - they are using Shamir's Secret Sharing algo (which will also prefix each part but you only need M of N parts to recreate the shared secret).

Nice addition!

I think the word "share" is probably not the best choice - am pretty sure that in order to construct a M of N address you need to use "public keys" (rather than addresses) so maybe they should change the word "share" to "public key"?

Let's see if we can *ramp it up a notch* with this: https://bitcointalk.org/index.php?topic=826263.0

I reformatted the OP and made it clear that at least the AT and AT API part must be open source and that my judgement is final but I won't be changing it much again (so the *rules won't be changed from this point on*) apart from to fix any typos or clarify anything that is ambiguous.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

To win: Be the first Script (i.e. Bitcoin or Litecoin) clone to implement a *working version* of AT on mainnet which will be used to
perform a successful "atomic cross chain transfer" with Qora (which will be implementing AT soon).

This will need to be performed within 1 month of Qora going live with AT (and if that doesn't happen within 3 months then
this bounty will be called off).

Bounty Address: https://blockchain.info/address/1AKRYi1Q2LtEAnEYzjjZXkZRXL33RKA53e (this address is kept in cold storage)

I created AT (http://ciyam.org/at) in order to allow any blockchain to have "Turing complete" txs easily added and it will soon be appearing
on some non-Bitcoin based blockchains, however, one of the *killer apps* for AT (atomic cross-chain transfer - at least IMO) really needs to
work with Bitcoin/Litecoin clones as soon as possible (and down the track there might be bounties offered for other blockchain variations).

I am not really concerned if the coin is *popular* (use of some low value coin is okay as long as the network is stable enough to achieve the
desrired result) but it must be using its *mainnet* and it must successfully accomplish an "atomic cross chain transfer" between itself and Qora
using AT.

In order to help *get the ball rolling* I've already outlined a fairly simple approach that could be used to get AT working from Script
(http://ciyam.org/at/at_script.html) and I will offer my personal assistance (with technical questions) free of charge (assuming I have
the available time).

Note that the code for the AT and AT API implementation must be "open source" using the MIT license (even if the rest of the code is not) and the final
say over whether the result to collect the bounty has been achieved will be up to myself.

If others want to add to this bounty then please send your BTC donation to the above address (note the following signed message to prove
that I own it and the GPG sig for this announcement).

1AKRYi1Q2LtEAnEYzjjZXkZRXL33RKA53e
This address is under my control!
G3YRn7DmQF0Jf5nBaJiw3SfMVroQzFB4N6X1AmNGmUYEaTCbfTOoZExiE2qAqHLdnA4IgIx+D+ccwVsjF3CWCuI=


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAlRk4YIACgkQZPzMrvJlEZATTgCghPw1X2sGRbXLxOlObggxjn2/
vFQAnj/xMMk5pXr1kXOJB8HfkGOEUCPL
=73Pq
-----END PGP SIGNATURE-----

Actually I am pretty sure that it was *his idea* called "O(n) blocks" or something like that (I just use the term "compressed blocks" as I think that is more "intuitive"). As stated one major thing that would need to be resolved is "transaction malleability" for this idea to be a "goer" (and see my posts in the previous page for the explanation).

Funnily enough I had *come up with the same idea* (I am using it in my own blockchain design) about six months ago - but I never thought to suggest it for use with Bitcoin at the time.

Note that with the "compressed blocks" idea we'd be able to handle 50 txs/sec with the current 1MB limit.

Yes - basically the blocks just contain the txids - which can be matched with those in each nodes memory pool (assuming they are present - they may need to "request" txs if they don't already know about them).


That would be part of the "validation" - to illustrate:


So during validation the block is "expanded" by replacing the txids with the actual txs and then the expanded block can be persisted.

The transaction hashes (malleability issues aside) mean they don't need to worry about the *honesty* of their peers - either each tx matches or it doesn't. The blockchain hasn't been changed in basic design either and for *normal bitcoin core nodes* that relay txs they will already have (at least most of) the txs for new blocks in their memory pool.

If you are worried about a "brand new node" that needs to catch up then I would suggest that they could be given "full blocks". As stated my goal wasn't to save on disk space (so the blocks would still be *stored* exactly as now). The idea is that for "general block publication" (to nodes that have most if not all relevant txs in their memory pool) there is no need for the tx scripts to be included in the block (saving a lot of bandwidth).

Nodes that "don't relay transactions" (nor keep a memory pool) would be a problem but I think that generally they would be connecting to things like "stratum" servers which could always just send them "complete blocks".