There's always the simple VM outlined in this as a starting point:
http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf

See chapter 9: A RISC-Architecture as Target.

The problem with colored coins concept, ripple, AE, XCP, all of them, is there is always the gateway that needs to be trusted. No offense to you, but this is fundamentally a single point of failure.

I am talking about directly doing trades with other coins blockchains so there is no need for any trust. The code is open source and deals with the escrow process on both coins and makes sure each party gets the other coin. Some magic with multisig and timeouts can implement this, eg from URLs I posted.

A simplified idea is to automate the functions of a gateway deposit and withdrawal. Put in escrow checkpoints (this is the hard part as funds need to get swept into a separate escrow acct) and the only thing you need to trust is that the software continues running. We can provide that assurance by making sure altcoind's are installed on 100+ hub servers and that the software that manages the escrow process gets runtime on these hub servers.

I see the high level pieces, but I cannot solve all the details myself. The big problem is how to be able to set aside DOGE in a "global" account that can then be accessed by whichever node is the forging node when the time comes to finalize the transaction.

I need help from some of the smarter guys here to figure this out. We will get NXT escrow ability, if anything from the NXTcash effort, so once we have that, the NXT side is done for this. Just need a way to do trustless decentralized escrow of BTC and other altcoins.

James

Time used should be the key, maybe adjust it for CPU speed of forging node. Current swap state would need to be put into blockchain so next forging node can pick up where it left off, but we can limit memory space.

I am envisioning services provided by code running on the hub servers, so it is feasible to have 20 different altcoind's running and ready to be called. Also, anything else we can think of can be encapsulated into a function call. Need to be able to suspend a script after time limit anyway, otherwise infinite loop will be bad problem

James

Once we have a low-level language we'll be able to use any high-level language to translate it into low-level one.

Translation from high-level to high-level is much more difficult.

If you use the abstract syntax tree based approach of Franz, your code would be platform neutral and any high-level language would only need to target the AST.

Nxt is simple. Let's follow KISS principle as long as possible.

So we agree then. Simplified machine language of some sort. Preferably one that already has compilers for C!

Just add ability to make function calls that are implemented by processes running on hub servers. Saving state to blockchain and each forging node restores it. Might need to charge 1 NXT for each context, but I bet a lot of people will gladly pay that to make sure their withdrawals are verified on external blockchain!!

James

We need some kind of a competition. The goal is to find a language with min number of opcodes.

The problem is not with AST approach. The problem is that Nxt should be as simple as possible to become wide-spread as much as possible. By mentioning "AST" word u increase entry barrier for programmers.