I built a simple testbed that encodes data in "sigs" (that use random K values) and although not the cheapest way to store data (the experiment was two bytes per sig and on an average laptop was taking roughly 15 seconds per byte pair to "mine" the sigs) it demonstrates that it is impossible to stop encoding of whatever data you want in the blockchain without even using OP_RETURN stuff.

I don't think anyone was more disappointed than the CIYAM Developers when we completed ACCT and then saw it get *zero media coverage*.

We had never expected profits but just wanted to see our tech "work" across two blockchains to help create "a truly decentralised exchange" mechanism and had hoped that at least the achievement would have been "picked up" by the media (as it was a "world's first").

Hopefully the Burst community can "re-group" and move forward (rather than attacking each other over the past). The CIYAM Developers have not "abandoned" this project despite our own disappointments - so please focus on the next steps rather than on who is to blame about the failure of the last ones.

(and yes - "don't trade with me as apparently I am a scammer")

When you think about UTXOs they are not a single balance for a private key - you can actually have multiple UTXOs for the same address (thus private key).

It is important not to get confused by keys and UTXOs as they are not a one-to-one thing.

Provided that the UTXOs you are using haven't been used then sure you could create a tx, sign it and then store it as long as you like before actually broadcasting it (not quite sure what the use of that would be apart from perhaps from some sort of "will" that when broadcast would transfer your coins to say a sibling or child).

Note that if you use any of the UTXOs "in the meantime" then the offline signed tx would become an invalid "double spend attempt".

Bitcoin (or clone) txs don't have a "timeout" but instead can have a "nLockTime" (which is a time before which they are not valid to redeem). Note that if you use nLockTime your signed tx can't actually be broadcast (successfully) until that block/time has been reached (before that it will be considered to be "non-standard" and just rejected).

Balances are really something of an illusion that is provided by wallets for end-user simplicity as the Bitcoin protocol itself only works with UTXOs (not *account balances*). In this way Bitcoin is very different to some other alt coins that implement the concept of actual account balances.

With a Bitcoin (or clone) tx the issue with "change" depends on your initial UTXO set (the "inputs" if you like which you can see using "coin control").

If you only have one UTXO (for say 10 BTC) and want to send someone 1 BTC then 9 BTC is going to be sent to a "change address". If you later want to send another 1 BTC then the "source" is going to have to be from that "change address" but if your client has not seen the confirmed transaction then it will likely prevent you from using that (this may depend upon the version of the software).

Without your client being up-to-date it is still possible to send further txs from the 9 BTC "change" but you will have to use "raw transactions" to do that (which is not recommended for anyone other than very advanced users).

Bitcoin txs can become "outdated" only generally because they are lacking in sufficient fees to get processed in time (so they'll get dropped from the "memory pool" of each node). If your client is still running then it will generally keep "resending" the tx (which is why it is not a good idea to get your fee wrong as you can end up with your coins in "limbo" if your client doesn't realise it is trying to send a tx with a too low fee). Typically if your tx is in the category of having a "too low fee" to be processed then within 24 hours it will normally have been removed from the memory pool of every node (assuming your client has been stopped).

Note that "dust" txs won't be propagated at all (so they won't even enter the "memory pool") and generally only "out of date" clients will be trying to send those (this kind of issue can be a big problem if you play with "raw transactions" and don't get your fee calculation correct).

You can sign a tx "offline" and then send the signed tx online with no risk about the private key (assuming your offline to online comms are secure for which I'd recommend using QR codes for 100% air-gapped safety).

It's a pity that ad-sig posters and people with no actual experience of this are the ones offering incorrect advice (but not surprising)

You *can* do exactly what you want to do (send coins without "being up to date") you just won't be able to see the tx confirmed locally (but the other party will once it confirms). Also there is no need to get as complicated as "raw transactions" if all you are wanting to do is send some coins you "already have".

Transactions are sent separately to blocks - it is the miners that put them into blocks not the tx creator. Just be sure you have the correct fee (so that the tx doesn't "end up in limbo").

You should be able to trace your transaction via a blockexplorer to be sure that it confirms.

Be aware though that any "change" amounts could complicate things if you are going to do multiple txs (but for just the one tx you should have no problem).

Updated OP to remove irrelevant content.

About AT on other platforms we have been approached by a few but none so far have gone as far as to actually trying to implement it (hopefully that will happen soon though).

Also any funds for AT are being handled by @vbcs.

I would like to just say that this: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf is the best solution to the current issue with block size that I've seen so far.

You can keep on asking me questions all you like but as I have stated @vbcs is now in charge of AT (not me).

Seriously the technology is not about "me" it is about a decentralised Turing complete system that has been proven to work and has been working for many months.

If my reputation is of concern then the community can easily remove it (I am not going to challenge that). I care about "changing the world" more than I care about "what people think about me".

@vbcs is now in charge of AT (and it is therefore up to him about whether to sever ties with the name CIYAM).

I will continue to help where I can and am asked to do so but I will most likely be leaving the forum (so that the project is not harmed any more due to me).

Yes I made a stupid mistake (was drunk and got pissed off by an idiot troll).

It was very unfortunate that the mods seriously thought I was ever going to try and do anything wrong with the forum's money and it is a pity that the 200 BTC (yes I was holding that much for the forum) I had held previously has been "removed from the record" (no now it looks as though I only was looking after 50 BTC - but I can prove that is not correct with a GPG signed message from @theymos if required).

Why my "stupid stunt" affects the AT software I don't quite get (and in fact I only wrote the C++ version anyway).

If you guys think that the name CIYAM is such an issue now then feel free to fork and rename as it is open source.

Personally I have been rather disappointed that 4 years of good work that I have done is just "thrown out the window" because of one "stupid mistake" I made whilst drunk but I guess that is the problem of "social media" (it only cares about "drama").

Use the "rescan=false" option if using the RPC command "importprivkey" although skipping the scanning is only advised if the address for that key has a zero balance (such as a brand new vanity address you just generated).

Not if you are using HTTPS (which I assume they would be recommending).


It wouldn't really matter if they did as they don't have the private key needed to create the response QR (which ties into the next question).


It uses a *nonce* so presumably it will never repeat such a value twice and no future nonce value would be able to be predicted (assuming the server has a good source of entropy).

I had the exact same idea back when I was creating the CIYAM Safe (as it uses QR codes for 100% air-gapped offline security) and I think it is likely to be the future for authenticating.

To make it even more secure if the smartphone was surrounded by a "see through" Faraday cage (which will still work with QR codes) then your authenticating device would be safe from being hacked.

Okay - topic locked.

I did *obey* the contractual demand from @theymos to return the funds within 14 days (was done within 3 days) but for sure I understand why I caused you and others to be upset.

Anyway - when the funds are moved from the address that they are stored at I hope people will not start up again (as those funds are not the forum's now they are actually mine as I am no longer holding any funds for the forum). Any "list" of the treasury funds should have been updated to remove the address that was at issue.

Thanks for at least considering to change the trust to neutral in the future.

In regards to "the record" I think it was unfair of @theymos to remove the *fact* that I had responsibly held 200 BTC for the forum for (from memory) six months (he could have just changed that trust to neutral rather than deleting it to make it look as though I never did anything right at all).

At the time I returned 200 BTC of the 250 BTC I was looking after was because I felt it was actually unsafe for me to be holding so much BTC for the forum (this was when the price was rising towards 1K USD).

If I had ever had some idea of "stealing the forum's BTC" then it would have happened when I had 250 BTC of it (and when BTC was approaching 1K USD).

I had agreed to return the funds to @theymos before I had even realised that the posts had got deleted (I only noticed that after I read @theymos reply to my apology).

Even @theymos has stated that their removal had nothing to do with my "stunt" and was just part of normal moderation.

There was no intent to actually "extort" - it was a *stunt* mostly from anger and frustration.

The forum's funds were never at risk and I would never have stolen them (I think @theymos believes me in that regard).

It was unfortunate timing that the posts in question (which were removed) did not get removed before I had "lost the plot" (and yes of course I wish I had just waited longer then everything would have been fine).

When I used to post on comp.lang.c++.moderated there was *no acceptance of trolling at all* so perhaps I was spoiled in having been a part of a "useful group" of technical people that were working on improving the C++ language.

Well people can say that they think that they "know exactly what I am thinking" but that does not make it true (just as silly if I was to start saying I know exactly what you were thinking when you posted your post).

Obviously if I really thought what you are saying I did then I would not have posted unless I actually *wanted negative trust*.

(or do you believe that was what I was actually after?)

When I first signed up to this forum it was actually something I was reticent to do as I am not a liker of any "social networking" stuff (the only such thing I had used previously was "usenet" which perhaps shows my age).

The fact that I "lost it" actually wasn't a big surprise to me (but of course was a "disappointment" although perhaps it was more surprising that I had managed not to lose it for years before).

To be honest I never thought that my "stunt" post was actually going to be *believed* but perhaps that was because I had drank a few too many beers that night.

The offline storage is actually on USB "flash drives" so the "offline PC" isn't really important at all (apart from it staying offline).

Anyone who actually knew about the CIYAM Safe (which is what I had publicly stated before I was using to hold the forum's funds) would know that it is a Live OS but seemingly @theymos and the mods were not aware of this and took my "stunt" post as being "for real".