So do you think that multisig or Shamir's would solve the issue (as I am not clear how you could ever create a *perfect* system - maybe such a thing is not actually possible)?

Please note that I did get a few PMs from @udecker about AT and Mastercoin (I assume this is the Craig that you mention as that is the name he used in the PMs).

Whilst I don't know how easy it would be to implement AT on Mastercoin I am willing to help out where I can (if devs such as Craig are interested to pursue this avenue).

Understood - but the offline device does have the private key and presumably could display that, and if it can do that then it could also display the "k" value that could then be audited via another offline device.

Yes - I understand that - I wasn't concerning myself with "evil implementations" but just wrong ones (that might leave you open to more simple attacks).


Also understood (and perhaps Shamir's is another method when one is considering protecting large amounts of offline funds).

Perhaps a better RFC might help (or maybe a BIP)?

IMO having a "standard" is the key thing (provided it works as expected and being deterministic can be easily tested for conformance).

Being a big fan of "regression tests" I have found ECDSA sigs to be a bit of a PITA.

Isn't that exactly what the point of the RFC is (i.e. every implementation should have exactly the same result if they have followed the RFC correctly)?

I had thought that the idea of making k deterministic rather than random was a better solution all around (and from memory there is already an RFC that describes exactly how this can be done).

It's not that hard to understand - if two blockchains have both implemented AT then you can use a similar "atomic cross-chain transfer" technique that TierNolan had described for doing the same thing between Bitcoin clones (which unfortunately isn't usable except on testnets because nLockTime is non-standard).

The two AT instances (one on each blockchain) have "timeout refunds" and the need to send a "secret" that both ATs hold the hash of (as you can't reverse a hash the secret cannot be determined except through brute force which would never be practical).

Once the initiator sends the secret to the AT on the second blockchain the creator of that AT sends the secret back to the AT on the first blockchain. As ATs act as their own accounts they automatically do the escrow (and unlike TierNolan's approach there is no issue of tx malleability).

You can read the details here: http://ciyam.org/at/at_atomic.html

Thanks for the mention - but unfortunately no-one from Mastercoin has bothered to contact CIYAM.

AT is going to go *mainnet* on some other coins very soon so if Mastercoin is interested then they could always send me a PM.

In that case you certainly would not want to use it so instead find a website that does use the safe approach or use vanitygen as suggested by others.

My guess is that website has been set up by scammers (unfortunately about 90% of what goes on in the whole crypto-currency area at the moment is scamming).

OP - it is spelt as Ethereum (you might want to change your Subject) and another similar concept is AT (http://ciyam.org/at).

@Brad Pitt and @LOBSTERHACKED both obviously have no idea about how these type of new vanity address websites work so OP should just ignore their posts.

I would advise the OP to simply verify that the website works as @JoelKatz explained and assuming it does weigh up the risk as stated by him (which I echoed).

As pointed out by @JoelKatz the only risk is that you have given out your public key but as soon as you send BTC *from* the vanity address you would have done that anyway.

We may also be *announced* at the next Bitcoin conference in Dubai (December 11th from memory) but that will be up to one of the teams that is looking into AT.

(unfortunately we don't have oodles of BTC to spend on marketing like the competition does)

No problem although I am not directly involved with the Qora coding (also I believe that qora has been sick recently) - my understanding is that the development is going well and we should be ready to test in a few weeks.

Thanks to one of the devs working on implementing AT in another Java coin it was brought to our attention that our "indirect" and "indirect indexed" addressing ops needed two complimentary ops (so that fetching and storing via this approach is supported).

I have now updated the AT specification (http://ciyam.org/at/at.html) and the C++ prototype (http://ciyam.org/at/_at.cpp.html) to provide the new op codes.

(relevant op codes are IND_DAT, IDX_DAT, SET_IND and SET_IDX)

Note that this doesn't affect the atomic cross-chain transfer use-case as it doesn't use any of those op codes.

He knows about bootstrap.dat and has an up-to-date blockchain so that link is of no help.

Unfortunately I haven't heard of anyone providing the index file(s) but if you do find that please let update this topic (as I might be interested in this also for testing purposes).

I guess it would also be nicer if bitcoin-qt could show some progress when re-indexing (so at least you'd have an idea how long until it will complete).

Yup - I use "g_" as a prefix for global variables and of course global variables should not be in a real version of AT (although some constants such as max. number of steps per AT and max. number of ATs per block would be expected to be provided).

The function_data stuff is only for testing purposes (it would not be included in any "real implementation"). Any real implementation would need to implement the AT API instead (http://ciyam.org/at/at_api.html).

Sorry for the confusion (understand that the C++ code published is a "prototype" that is useful for testing ATs and uses hard-coded pseudo API data rather than making real API calls).

With the announcement that Counterparty made in regards to Ethereum I am being asked whether AT is still a contender.

Firstly let's be clear that Counterparty do not have Ethereum on *mainnet* now and most likely won't have it on *mainnet* for at least a few months.

Secondly AT has been designed to be much more *low-level* which should make it much quicker to implement (especially as we have already created unit tests for all of the instruction codes except the API ones and we will be creating unit tests for those also).

As an added incentive - I am going to offer another 20 BTC if a Bitcoin clone can achieve the goal of this bounty before the end of 2014 (which would make AT the *first mainnet* Turing complete transaction system for blockchains).