Sounds like a reasonable suggestion to add the .dll/.so targets to the standard make (although I guess you'd want some regression testing stuff to be sure they do actually work).

This is exactly how AT works (once an AT has been created it cannot be modified and it will run forever unless it has been terminated according to the rules of the blockchain it runs on).

It may end up possible at least in places like China where you do have basically irreversible fiat txs online (with the likes of Alipay) although certainly not currently.

A technology such as Automated Transactions (AT - http://ciyam.org/at) can act as a trustless 3rd party to perform Atomic Cross-Chain Transfers (ACCTs) between blockchains (provided both blockchains implement AT).

This technology has already been developed and an ACCT between two blockchains is expected to be demonstrated within a few weeks (the two blockchains concerned are Burst and Qora).

It should be noted that this type of exchanging doesn't require a website and it should also be noted that it will only apply to exchanging one crypto currency for another (not fiat).

My understanding is that the creator of the AT would send say 1M BURST to the AT and if 50K was added by others then it would pay back the creator monthly payments that include a proportion of those extra funds (so the whole amount is not locked for 12 months but the monthly payouts are limited so that the creator cannot simply "dump" their BURST).

The use of an AT in order to "lock up funds" (in return for some interest) is an interesting concept and one that is far better than any other approach (as you don't need to trust anything other than the actual code).

At first I was mystified as to what the purpose of this AT was but having seen other offers to stop coin dumping I finally "got it" (not being a miner nor invested in the coin itself sometimes this things are not obvious to me).

The AT team will be happy to further review this new AT code and hopefully we'll have an endorsed version available soon for this new use case (as usual we won't charge for our work but any donations made via the ATDevelopment Crowdfund AT would be appreciated).

Nice to see you've noticed that - mostly I remember how the forum was back in 2012 before there were any ad sig campaigns - the main problem it had then was the "forum rank" being related just to the number of posts (so a huge amount of +1 posts were appearing).

Back then what happened was that "activity" was introduced - a great solution to making the silly posts pointless (and it really helped cleaned the forum up). But then in 2014 these ad sig campaigns started introducing more crap posts than we have ever seen before.

It is a shame to see a forum that used to provide solutions to problems simply "give up" and let the ad sig spammers win.

As has been pointed out *many, many* times already it is the shit posts not the ads themselves that are the main issue.

Note that only the ad sig posters (such as the one I've quoted) ignore this *time and time again* and keep trying to tell everyone they should disable the sigs when they know full well what the problem is.

Stop with the bullshit please.

Personally I am almost done with this forum - so if they are going to allow the same rubbish on the new forum then @theymos please send me an address to return the 50 BTC I am minding for this forum (I'll send a GPG request for this in the next few weeks I guess).

If it is suggesting a tx fee that large then *you must be trying to spend dust* so let's rewind and you tell us "how did you get your BTC" (if it wasn't faucets is it tiny mining payouts)?

You have your fee set correctly?

My guess is that you got all your BTC from faucets or other such "free" ways and it is all just "dust" (meaning you have a bunch of very low BTC "inputs" that basically can't be spent).

You are going to have to lose a fair % of your BTC in order to rescue some of it to become usable or wait for a very long time to spend that "dust".

You can read about it here: http://ciyam.org/at/ (it is very technical documentation at this stage sorry).

XOR could allocate memory?

(that seems odd to me)

Yes - good point - so nice to have a topic with smart people rather than just ad sig posts (but I guess they might be about to follow).

Interesting - as a potential attack vector it wouldn't be so easy but I'd guess it still could be such a potential if the txs were relayed wouldn't it?

It does seem strange to disable XOR - was there any reasoning stated for that?

Although not the latest source I see this:


in EvalScript (so assuming the return value is whether the script is valid then I guess not).

AT is a virtual CPU so they are "machine code" (a bit like the contents of an .exe for Windows).

The AT Assembler allows a higher level than writing raw machine code (which is just hex bytes) but lower level than languages such as C or Python.

It is envisioned that for the most part people will actually just use "templates" and not have to worry about writing "code" at all. You will select the appropriate template (let's say Crowdfund) then fill in some values (such as payout account, amount to raise and time limit to raise the funds) and the assembly (and machine code) will be generated for you automatically.

Imagine being able to exchange W coins of X type for Y coins of Z type (with no trusted 3rd party) and you begin to get the point.

We are not trying to change Bitcoin Script to become Turing complete at all but instead to extend it to allow AT txs that are Turing complete themselves.