Topic: Why blockchains might want to consider using AT "Turing complete" txs - page 2. (Read 21682 times)

So you can make AT on a platform to do a very specific set of smart contracts and not others, right?  So a dev can pick just which kind of smart contract the platform needs and no more, and if there is not code for that smart contract, it can be made?

Unfortunately like most media articles it is full of mistakes - most importantly AT allows for the creation of arbitrary code so there is no limit of 5 kinds of "smart contracts" (it is just that only that many ATs have actually been written so far).

For normal end users who want to create their own ATs the idea is to provide a very simple web UI to do so but any user who has the skills to code an AT is not limited to that as they can just construct an AT using the raw machine code.

Here is some good news about AT

https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/

Qora AT is 95% done, some minor additions and a lot of stress tests yet to be done. 

The developer appears to have gone quiet for some time now.

Any word on Qora AT?

An AT "trustless lottery" is already running on the Burst blockchain (mainnet) - the announcement was made here https://bitcointalksearch.org/topic/m.10254497 and the actual AT assembler code can be found here: http://pastebin.com/xiDdMzEG

Expect more of the AT use cases to be appearing soon.

After careful review of GCC and LLVM we are now more leaning towards using LLVM to create a high level language for AT (which will be C++ hopefully).

Also the Lottery AT has been ported to the AT API and should be appearing very soon on Burst.

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).

This initial idea at getting the atomic cross-chain transfer to use different hashes is flawed in that it is no longer trustless, however, @burstcoin worked out a way that it can in fact be made to work.

For those interested in the technical details: https://bitcointalksearch.org/topic/m.9843577

After a question that was raised about AT in the Burst (a blockchain based upon HDD storage that should be going mainnet with AT before xmas) topic I have realised that AT can be used to help anonymize the transfer of funds.

Although it wouldn't be practical until there are hundreds (if not thousands) of ATs running - the idea is that the "atomic cross-chain transfer" AT could be easily modified so that instead of both ATs having the same hash they each have a different hash that is a different function of the "shared secret".

For example let's say that the secret is: "secret"

The typical atomic cross-chain transfer would have the SHA256 value of this (2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b) hard-coded into both ATs.

But let's consider that our 2nd AT actually has the hash of "terces" hardcoded in it (04d3368f72736ed54c3cb63454eef23c2ecfb1deed27e2a4aa8e442e898fdbf5) instead of the same hash as the first (this second hash would of course have to be securely transferred between the two parties concerned when the first party creates its AT).

Until "secret" has been published there is no way that "terces" can be published so we have the same behaviour as before but just a manual step now in between (i.e. reverse the secret then send this to the 2nd AT). Of course reversing the secret would be rather to easy to discover so instead one would use a complex function involving transformations and rounds but the idea is the same.

Thus once the secret has been published on the one chain it should be very hard to actually trace which funds went where between the two blockchains (assuming similar ATs are running on both blockchains at around the same time).

AT integration on Qora will be continued as normally into the existing private repository.

Slightly OT, but Qora has just announced Open Source for 9th December:  https://bitcointalksearch.org/topic/qora-100-pos-assets-names-voting-open-source-881230

xcp

Is there a list of the coins that are working on AT integration?  We know about Qora and NXT.  Looking at the bounty thread, there are some other developers who "showed an interest", but do we get to know which ones?  Or are they keeping it under wraps until they have something to show?

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.

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).

This is a very important concept to internalize. I don't think Satoshi realized it, and I think if he did Bitcoin Script would be very different from what we have.

In a future ideal world where arbitrary zero-knowledge-proofs are time-tested and have robust implementations, everybody except for the N entities directly involved in a transaction would validate a short, opaque proof that some computation took place authorizing the transaction.

If you're designing a better transaction system, you should design with that ideal in mind.

While I am thinking about "higher level" languages ideally what I'd like to do is to have GCC able to compile code based on the AT instruction set so if there are any GCC gurus (i.e. people that know how to add a new instruction set for it to work with) who are interested in AT then please get in touch.

I'm not quite sure about the issue you've raised here - we have already written all the boundary checks and completed all the unit tests to prove that they work (it is basically just *one* function that each op code which needs to check if a memory location is valid calls and it could easily be *inlined* for better performance).

Actual AT machine code doesn't need to do any such checks as the machine will simply gracefully fail if they attempt to read or write outside of their valid memory range.

The design choices made were primarily about keeping the *code size* of the ATs as small as possible (thus only the SET_VAL op code takes a 64 bit literal value and most other op codes take one or two 32 bit addresses) and preventing anything such as "self-modifying code" or invalid branching.

Also I am neither a fan of the JVM nor Java (and haven't written any code in Java since the 1990s) so it is perhaps unsurprising I had not even heard of the Moxie project that you mention before I read your post.

Anyway - if Moxie is suitable for blockchain usage then of course people should decide which VM is the best fit for their blockchain (we are not claiming AT is *the best VM* but simply that it is *available* and that we have already built an atomic cross-chain transfer program for it so it should be quite useful even as is and without a higher level language).

In regards to "dead code" it is envisioned that ATs with no UTXOs left could be removed as part of pruning.

As far as performance goes only testing will reveal how useful an addition AT is (note that limits are recommended to prevent AT from ever becoming too big a burden for peers to handle).