I am not sure exactly what you are referring to - but in regards to blockchain pruning ATs could be removed provided that they have become inactive (we are likely to further formalise this down the track).

It is possible to hard-code values into ATs but understand as the Initiator and Responder would need different values we'd have to have two ACCT ATs rather than just one (at the moment the code is the same regardless of which role).

The next main focus for the AT project is going to be UI so we will consider how we can make the workflow and UX better as we proceed.

Actually you haven't quite got it - Alice's timeout needs to be the longer one (as it is Alice that will be sending the "key" to Bob's AT first).


I'm not sure how that could be achieved - the best approach IMO is that the hash of the ACCT AT code could be published and compared to (to prove that it is the code that you think it is without having to actually understand AT machine code) and that you check the timeout value before proceeding.

Assuming there is enough of a time gap then there is not much that can go wrong (unless Bob's internet dies after Alice sent the secret and he can't get it working until the refund expiry time for Alice happens).

The timeouts can be defaulted by the UI but of course you cannot prevent a user from changing the default.

This is why Bob and Alice must carefully check each others AT's before proceeding. I think we'll eventually create a tool for AT "verification" down the track in order to make it very easy to be sure you aren't being cheated by an incorrectly coded AT.

Creating an LLVM or GCC implementation for any new micro-processor is not something that is going to be able to be "made easy" as it is a very specialised software development area.

Only those who are not completely confused by the documentation on the website that I am really interested in hearing from. I am not trying to be "elitist" but just practical in that only people very familiar with assembly language and writing compiler implementations are going to be able to be suitable candidates for this task.

As for C++ examples - they will be easy enough to create once we actually have a C++ compiler.

We have already published much more than "hello world" examples of AT (http://ciyam.org/at) and the first ACCT (Atomic Cross-Chain Transfer) between two separate blockchains (Qora and Burst) has already happened.

Do you seriously think we don't have a product that works?

Perhaps you have created this in response to the NYT article that points to Nick Szabo (and fair enough if so).

But in any case what exactly is the point of your "poll" as you surely realise that any "poll" on this forum is 100% rubbish (as the outcome will be controlled by sockpuppets)?

I understand that but am just wondering if the tx will be relayed (my understanding is that currently txs that have future nLockTime values are not relayed to prevent attacks).

So a tx that uses these new op codes (assuming both are adopted) will still be "non-standard" if the nLockTime is in the future?

Is this OP_RELATIVECHECKLOCKTIMEVERIFY a new op code and is it designed to basically replace nLockTime?

Since no-one took up the offer to implement AT on a Bitcoin clone I have decided to redirect these funds towards trying to find an LLVM/GCC developer to implement AT for a C++ compiler.

https://bitcointalk.org/index.php?topic=1063376.msg11400417#msg11400417

If people are still interested in implementing AT on a Bitcoin clone you are welcome to contact me and the CIYAM Team will help.

This is not a bounty but will be the reward for someone to create an LLVM (or GCC) implementation for AT (Automated Transactions).

If you have experience in creating LLVM or GCC code at the instruction code level (such as having worked on adding a new CPU instruction
set to either compilers) then please contact myself via PM and include a link to your resume.

The amount will only be paid upon completion and a completion date will need to be set in advance. Once a developer has been found then
this task will be published on CIYAM Open (http://ciyam.org/open).

Funds address: https://blockchain.info/address/1AKRYi1Q2LtEAnEYzjjZXkZRXL33RKA53e

If others want to add to this reward 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)

iEYEARECAAYFAlVYibEACgkQZPzMrvJlEZATPACdGmRkLqLhsA4qLWq+a3OOv4Ko
D54AoKSRsG0LK7JbRSrHLngTExRmKjYO
=fqJn
-----END PGP SIGNATURE-----

Just a couple of notes regarding the draft media release:

- it should be "Atomic Cross-Chain Transfer" (i.e. ACCT) rather than "Atomic cross-chain transfer"
- please change "ian and vbcs" to CIYAM Developers (and wherever it currently says CIYAM should read CIYAM Team)
- I would remove Key from the info-graphic for the Burst AT (as it makes it look as though the Key is initially public which of course it isn't)

To be clear on the terminology we are using the ACCT Initiator enters a Password which is transformed into a Key and Lock with the Lock being published in both ATs. After the Responder's AT has been created (which is the matching AT on the other blockchain) then the Initiator will send the Key to it in a message to perform the transfer. The Responder now can see the Key which they then send to the Initator's AT and the atomic transfer will have been completed.

Not very likely with a PoW implementation as the economics of the "coin" is what enables the "work" to get done (unless of course the mining is all government provided).

But with other low-cost consensus systems (and so far none have really being proven to be anywhere near as reliable as Bitcoin) the motivation could be the value of what else the system can provide (e.g. a decentralised "blogging" implementation) so assuming the cost to participate is negligible then the utility of the software platform could provide the reason for people to support the network (much like the motivation for running a ToR node).

Agreed and the major focus of the AT project (after we have released AT on Qora and published the ACCT) is to create a UI generator for ATs which will be able to automatically construct UI.

Disclosing the content of any private message without getting permission to do so is something that I consider to be rather "poor behaviour" but if you are going to do so it should be at least accurate.

So let me state publicly that we have already worked out a variation of the ACCT that would be helpful in making it very hard to track funds being transferred between blockchains assuming enough such transfers (of the same amounts) were taking place. The method was outlined on this forum in a topic that I ended up locking due to it being spammed.

To be clear there is simply no point though in us (the CIYAM AT team) focusing on that until the initial ACCT has been published and we have had sufficient feedback to make it as "user friendly" as we can.

If @vbcs is interested in taking up the offer then perhaps create a CF AT for funding the creation of this special ACCT variation and I would perhaps also suggest that a "mixer" AT could be developed as well (that is designed just for moving fixed amounts between different accounts on the one blockchain).

The issue is that AT code and data is public (and have to be that way) so they don't really fit into a blockchain whose purpose is to make everything secret.

I do remember watching a film called Dark Star back when I was a teenager (directed by none other than John Carpenter).

It had some rather silly stuff - about the most silly part I recall was an alien that looked exactly like an inflatable bouncy toy - but the conversation with the AI "bomb" was interesting.

Welcome to use the CIYAM code which includes parts of the Bitcoin code as well (but might be easier to follow in terms of the C++ classes as it doesn't involve any Boost stuff).

https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp

Although I am not really against increasing the block size I think that Bitcoin will always be limited by its confirmation time which is suitable for large txs but not small ones.

It seems that quite a lot of people think that we should only have one blockchain (the Bitcoin one) and to me that has never made much sense (unless you are heavily invested in it).

To be decentralised means to not have a single point of failure. If the world was to rely upon Bitcoin as its only blockchain then it would have a "single point of failure".

Although I also acknowledge that most "alt coins" offer little innovation I still think that the future will be many blockchains that can work together (this is why I invented Automated Transactions or AT which is a blockchain "agnostic" smart contract system).