MultiChain data storage limitations/questions.

Question

Hello,

I am currently starting a project and am hoping that MultiChain will be fit for our uses. I want to be able to store a file in the chain (ranging in size from approx 3MB to 7MB) so as a locally stored copy of the file can be compared to the data that is stored within the blockchain to ensure that this indeed is the file in question and that it has been in no way altered since it was created.

I have done quite a bit of reading through this website and have seen how metadata can be stored as part of the OP_RETURN part of the transaction however the limit on this is approx 125KB. Elsewhere on this forum it has been stated that the maximum size one can encode is 8MB. Am I missing something here? Is there a way to encode more data than 1048576 in a transaction? If the transaction size can be set to 10000000 what happens to all this other available space and is there an api call to manipulate this? My current chain has the following params configured:

only-accept-std-txs = true              # Only standard transactions are accepted to mempool and relayed.
max-std-tx-size = 3000000               # Maximal size of standard transaction.  (1024 - 10000000)
max-std-op-return-size = 1048576        # Maximal size of the data after OP_RETURN.  (0 - 1048576)
max-std-op-drops-count = 5              # Maximal amount of OP_DROPs in the script. (0 - 100)
max-std-op-drop-size = 64               # Maximal size of the script element followed by OP_DROPs. (0 - 32768)

I have been currently using the sendwithmetadatafrom api, along with listtransactions and getwallettransaction to query the transactions from the other node. Could you elaborate a bit more on these limits of file size etc, and point me in the right direction as to how to best proceed.

On another related issue, I wrote a simple shell script which was basically a for loop to do 10000 of these transactions (sendwithmetadatafrom with the addresses and approx 100KB of metadata) however it appears to have broken the chain somewhat. 490 of these transactions completed and the rest I am not quite sure what has happened to them. I was thinking that perhaps with the 15secondconsensus time that some transactions got bottlenecked and were parsed wrong, however while I can see the send transactions from the first node they are not available for query on the second node? Am I on the right track here or do you have any information on what would be the best way to effectively "load" a chain full of transactions.

I am new to MultiChain and any help you can give me here will be greatly appreciated.

Thanks in advance,

Rua

Answer 1

Hi Rua. We've tested MultiChain with up to 8 MB of metadata per transaction, but the current wallet design cannot handle a large volume of these transactions in a scalable way - a new set of APIs and enhancements are coming down the line to make all this much more scalable.

But in terms of the application you're talking about, I would recommend hashing the files (using the SHA-256 algorithm for example) and just embedding those hashes on the chain, rather than the full file contents. This is sufficient to enable you to verify that a file has not changed, because the slightest modification to a file will lead to a completely different hash value, and it's computationally impossible to 'fake' up a file to match a particular hash, if you don't have the original one.

Comments

I know it sounds kind of ridiculous but for purposes of this project I am trying to actually store the file contents and not just a hash of those contents. Are there any options open to me here?

For an example of a 3MB file hypothetically I am currently thinking I will split it over a number of smaller packets and store it in a series of transactions spanning the data over the 120KB limit of the metadata that I can store in the OP_RETURN. I can then store the relevant transaction ids in a seperate db in order to reconstitute the file in the future should the need arise.

Can you foresee any issues in me accomplishing what I'm after using the api at its current state of evolution?

Is sendwithmetadatafrom the most appropriate part of the api to use?

Or could you suggest an alternative methodology?

Thanks again for the help,

Rua

---

Hello Rua,

Have you been able to store file content to the blockchain? I am also trying something similar.
thanks