Thoughts on storing data on chain and bloat

There are several websites (nanote, nanoo steganography) that help you encode data on the nano blockchain. Similar to which stores short messages on the Bitcoin Cash blockchain, I was wondering what are your thoughts on storing/posting media such as blog posts with images on chain? Is it frowned upon?

I do realize it will take a lot of POW to post a basic blog post, especially with images involved, but that is up to the user or service.

  • Too much bloat for any media. Only money.
  • Blog text, but no images.
  • Only short messages like twitter.
  • Anything goes.
  • Banano.

0 voters

I fail to see what besides transactions gets processed by the Nano network and stored in the ledger.
So what's the point?

Sorry @zergtoshi I forgot to mention the point! There are a few reasons I can think of and there are probably more use cases to use a decentralized ledger for data.

  • Censorship resistance, e.g. posting about a government: Tiananmen Square Massacre, Whistleblower leaks.
  • Timestamping documents for proof of existence.
  • Decentralization and permanency of data.
1 Like

I think @clemahieu made intent clear a while back.

One of my wishlist items, however, is some way be deterministic before a transaction is created in order to watch for a transaction. What I mean is, I'd really like a way to tell a user to send me 1.0 Nano with a memo of 1FA342D1, so that I can watch for that transaction to be confirmed. It would require some number of "free text/ambiguous" bytes that serve zero purpose to the transaction but serve purpose to implementation of a transaction.

Current implementation is to use a unique address that eventually times out (like BrainBlocks) or append some unique sequence of digits at the least significant side of the transaction amount (unsupported by many wallets).

(I fully acknowledge my site you listed,, is a "gimmick". And even though I make an attempt with a checksum to limit the noise in only parsing nanote messages, plenty of random transaction get through [one reason the second idea, storing in least significant digits, does not work]).


Couldn't you instead use something like IPFS? Then just store the hash

I agree with @SomeNano, when a transaction is broadcasted we could have another 8 bytes (or more) field whose only purpose is to be broadcasted and not to be store in the ledger.

1 Like

That still uses bandwith, albeit not very much.
Yet bandwidth is one of the potential bottlenecks.

How would you find that information later, of it's not being stored in the ledger?

All those uses can be fulfilled by many other blockchain projects. There's no reason to use Nano for them.
Nano's success relies on being laser-focused on value transfer only. Adding anything else complicates it and complications are a very bad design direction. Whatever benefit could be had by adding these things to Nano, that benefit would be dwarfed by the drawbacks.


8 additional bytes won't be a problem. You don't need that information later see it this way. A customer wants to buy a product, like for bank transfer you tell him to send the tx with a particular memo. When your node receives a tx you look for the memo, if the memo is the same then you know it's exactly this customer who paid. You don't need the memo for later use.

I don't think adding an 8 bytes field would complicate anything, it's just a field that is pass along the transaction and not stored in the ledger. it is possible. a little bit like the proof of work. The PoW is not used in the signature of the tx so it would be the same for the memo field

Well, if it's not stored in the ledger I can't say for sure that it's bad. However, there's already a solution for the problem you describe that doesn't require a change to the Nano protocol. Just create an address for a transaction, like how Brainblocks does it. As pointed out a few comments above, your proposed solution takes up extra bandwidth, so there's already that negative about it when a solution without this drawback already exists (i.e. how Brainblocks does it).

Best design practice is to avoid unnecessary complications. Adding 8 bytes could have unforeseen complications down the road. So could adding 8 bytes for the express purpose of communicating some kind of message - that would change the purpose of Nano transactions to also include messages and Nano design might get distorted/bogged down/distracted by having to accomodate this. Nano's goal is to be the most optimized value transfer protocol possible and that means extras have to be ruthlessly discarded in my opinion.

Value transfer in foreign exchange markets is one of Nano's target use cases. FX markets are the world's biggest markets at $5 trillion/day. Colin has pointed out several times that in FX, the fastest protocol wins. If Nano doesn't avoid unnecessary extras it may not be the fastest value transfer protocol in the future. It might get trumped by some other protocol that is better optimized and faster. And for design purposes it would be a good idea to assume that speed will win in other value transfer use cases too.

If Nano is to achieve its goal of being an Internet RFC for value transfer, it has to be laser focused on this goal or risk losing out to another protocol that is better optimized for this purpose. Achieving this goal would be a colossal achievement that would bring colossal value.


This is a fine method and has proven to work well.

Nano over it's few years has created a norm around address reuse, though. When someone sends an amount to a known address, there is trust. When someone sends (or receives) through an intermediate account, in creeps uncertainty.

  • Sender: Am I sending funds to the right place?
  • Recipient: Can I trust my intermediary service to forward funds to my account?

One might argue that using a new unique account for every receive only to forward on has far more overhead than some relatively small number of bytes of "memo" (especially when pruning is live).

I think the memo has to be on the ledger, though. It needs to be part of the block chain to ensure integrity.

I don't know how you can reliably use such a memo field, if it's not stored in the ledger.
What happens, if the receiving node isn't online when the transaction gets broadcast and the transaction gets then later sent by a node that has it stored without the memo?
I agree it needs to be stored

If you want to reuse the address I can imagine using some of the last of the 30 decimal places to effectively add a memo. That would require wallets to support that number of decimal places and you'd have to make users aware of that (paying next to nothing in excess to being allowed to reuse an address).
But it'd allow adding a memo to a transaction with the current protocol.

1 Like