Is this real life?
Not quite. This is work in progress that I published, an adaptation of Ahmad Kazi's work (Primecoin intermediary and Primecoin Core). The (Datacoin adaptation of the Primecoin) intermediary client ("intermediary" branch) functions as expected. The Primecoin Core 0.16 adaptation (master branch) is not as straightforward.
Thus far, I've managed to get it to sync up to block 4000-odd before it chokes, probably on an improper diff calculation or retargeting mismatch or some such gotcha. Running it under the debugger should throw a bit more light on the issue.
However, the challenging task is to migrate the RPC getdata and senddata commands. 0.16 is a very different environment from 0.8, the architecture is quite different, much more complex and forces the simplistic senddata interface to make some heroic assumptions - about which wallet to use, about which account to use - about which txin to use to pay the fee. The API call itself basically fails to provide basic information for the construction of a transaction to store the data.
I mean, I don't know whether it will fit ...
do you have to send coins to send data also or can you just send data? who has sent some files with this already?
senddata is a lot like sendtoaddress. It creates a tx that contains:
- data
- fee for this data
- inputs (in order to pay fee)
- output (for change)
So the answer is: no, you don't need to send coins to somebody to send data. You can just send data.
Sending a message means that there is a receiver for this message. senddata RPC doesn't add a receiver into tx but as soon as any tx has a data field you can do this (=> needs a bit of coding but doesn't need a hardfork).
The reason I published the work in progress is so that anyone who wants to pick it up and run with it isn't waiting on me unnecessarily.
But it's work in progress. I don't even know if it works yet, I've only just now got it to compile successfully with the refactored API calls, now to find out whether it'll work okay without a receiver (new Bitcoin code can be much more strict about such things).
Cheers
Graham