Bitcoin Messaging App - Send and Receive Messages - Try It Today !

[girayeser]

GitHub Repository: https://github.com/theRomanMercury/BitcoinMessagingApp

A revolutionary Windows-based application that enables you to send and receive secure messages using Bitcoin Core. Take your communication to the next level by leveraging the Bitcoin blockchain!

Features:

🔹 Blockchain-Based Messaging:

Send and receive messages via Bitcoin’s OP_RETURN field for maximum security and transparency.

🔹 Inbox Updates:

A real-time inbox automatically checks for incoming blockchain messages using an integrated Timer system.

🔹 Easy-to-Use Interface:

Simplified login with Bitcoin Core RPC credentials and a clean design for seamless interactions.

🔹 Open Source:

Fully open-source and ready for contributions!

Why This Matters:

Bitcoin isn’t just a currency—it’s a powerful decentralized platform. By using the Bitcoin Messaging App, you can:

- Ensure your messages are immutable and secure.

- Leverage the blockchain for creative use cases beyond transactions.


Support Development:

💡 Love the project? Consider contributing to its growth:

Bitcoin Donation Address: bc1qqx2asqpelkh0trqhd44qgx9xsklnw0pu3n559u

Join the movement!

[ABCbits]

Hi, are you creator of this app or just sharing it? Anyway, i think it's not exactly revolutionary when https://memo.cash (on BCH network) already use OP_RETURN to create functional social media.

[girayeser]

Hey,

Thanks a lot for your comment and for bringing up memo.cash — it's a great example of what's possible with OP_RETURN and on-chain social media, especially on the BCH network. Respect for the work that's been done there.

Yes, I'm the creator behind this project, and while it might not feel revolutionary compared to earlier implementations like Memo, my goal here is to build upon those ideas and take things a few steps further — especially in terms of privacy, user identity, and modular expansion.

Feedback like yours helps a lot, happy to connect. Thanks again!

[apogio]

Quillbot AI Detector and GPTZero gives 100% AI content on both of user's posts.
I wouldn't spend a lot of time discussing with OP, as it's most likely a bot.

[pooya87]

Bitcoin isn’t just a currency—it’s a powerful decentralized platform. By using the Bitcoin Messaging App, you can:
- Ensure your messages are immutable and secure.
- Leverage the blockchain for creative use cases beyond transactions.

Bitcoin is a decentralized payment system and not a decentralized cloud storage or a messaging app. And just because the option exists to inject arbitrary data into the chain, that doesn't mean Bitcoin is made for it!

[ABCbits]

Yes, I'm the creator behind this project, and while it might not feel revolutionary compared to earlier implementations like Memo, my goal here is to build upon those ideas and take things a few steps further — especially in terms of privacy, user identity, and modular expansion.

What kind of privacy you're talking about? After all, the message isn't encrypted and Bitcoin blockchain is available publicly (can be seen on various Bitcoin block explorer).

Bitcoin isn’t just a currency—it’s a powerful decentralized platform. By using the Bitcoin Messaging App, you can:
- Ensure your messages are immutable and secure.
- Leverage the blockchain for creative use cases beyond transactions.

Bitcoin is a decentralized payment system and not a decentralized cloud storage or a messaging app. And just because the option exists to inject arbitrary data into the chain, that doesn't mean Bitcoin is made for it!

And it's not practical anyway. Most people don't want to pay $0.23 (current TX fee recommendation for no priroty on https://mempool.space/) to create single TX, which is equal sending one message.

[bitmover]

Yes, I'm the creator behind this project, and while it might not feel revolutionary compared to earlier implementations like Memo, my goal here is to build upon those ideas and take things a few steps further — especially in terms of privacy, user identity, and modular expansion.

What kind of privacy you're talking about? After all, the message isn't encrypted and Bitcoin blockchain is available publicly (can be seen on various Bitcoin block explorer).

I have seen similar projects that used lightning network to send messages. This way there would be some privacy.

Nut using main chain to do that is crazy...expensive and bad privacy.

But using LN it could work well. I never used but I know some projects that tried to

[pooya87]

I have seen similar projects that used lightning network to send messages. This way there would be some privacy.

Nut using main chain to do that is crazy...expensive and bad privacy.

But using LN it could work well. I never used but I know some projects that tried to

Why use bitcoin or anything bitcoin related to communicate in first place? Why not just encrypt the message using a strong encryption algorithm and then simply send the message through email?

Even sending it P2P should be easy. One of the basic apps you can write is a P2P chat client. All you need to do is write a much smaller script compared to Bitcoin's P2P protocol to open a socket and  connect to the other peer and send them the message!

In C# it is like 3 lines of code to start listening for incoming connections.

Code:

Socket listenSocket = new Socket(ipEndPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
listenSocket.Bind(ipEndPoint);
listenSocket.Listen(backlogSize);

And to send, receive or connect you just call the Send/Receive/Connect-Async method on the socket with the first two needing a buffer set first. That's it! Clean, safe, private and completely P2P and free without needing to spam the bitcoin blockchain.

[nc50lc]

Yes, I'm the creator behind this project, -snip-

Have you actually tested your app?

It's using createrawtransaction without a way to indicate inputs/outputs and it's adding the OP_Return output weirdly.
Ref: https://github.com/theRomanMercury/BitcoinMessagingApp/blob/main/MainForm.cs#L75-L81
Not to mention, that command will return a serialized raw transaction that isn't broadcasted to the network, using that without using sendrawtransaction does nothing.

It's using listtransactions for the 'inbox' and 'inbox message count' while that command will only return 10 transactions by default, the only arg it included is: "*" (all labels)
Ref: https://github.com/theRomanMercury/BitcoinMessagingApp/blob/main/MainForm.cs#L116
Also, it wont work in multi-wallet scenario since there's no way to specify --rpcwallet arg.

BTW, you forgot to edit the "yourusername" placehodler in the readme.
That's something...

[girayeser]

Have you actually tested your app?

Thanks for reviewing it. I’m planning to test, refine, and improve it whenever I have time.

What kind of privacy you're talking about?

I’m considering a privacy feature where the message sent via OP_RETURN would be encrypted and only readable by the recipient using their private key.

And it's not practical anyway. Most people don't want to pay $0.23 (current TX fee recommendation for no priroty on https://mempool.space/) to create single TX, which is equal sending one message.

I’m also considering running it for free on the off-chain testnet. If it's possible.

[ABCbits]

What kind of privacy you're talking about?

I’m considering a privacy feature where the message sent via OP_RETURN would be encrypted and only readable by the recipient using their private key.

So how the sender supposed to encrypt the message, without knowing private key of recipient address?

And it's not practical anyway. Most people don't want to pay $0.23 (current TX fee recommendation for no priroty on https://mempool.space/) to create single TX, which is equal sending one message.

I’m also considering running it for free on the off-chain testnet. If it's possible.

You didn't start development of your app using testnet?

[girayeser]

So how the sender supposed to encrypt the message, without knowing private key of recipient address?

1.Encrypt your message with the recipient's public key

2.Embed it in a Bitcoin testnet transaction using OP_RETURN

3.Recipient decrypts it with their private key

You didn't start development of your app using testnet?

I haven’t started development on testnet yet because I’m currently working on synchronizing both Bitcoin Core mainnet and testnet, setting up the .conf files, backups, and configuring the RPC settings. At the same time, I’m reviewing feedback and ideas shared on the forum to figure out the best possible structure and direction for the application.

[nc50lc]

1.Encrypt your message with the recipient's public key

This will only work in a blockchain where OP_Return has a standard limit higher than 80 Bytes.
Even a small message like "Ok" could result with an encrypted message higher than the standard limit when converted to hex.

Have you actually tested your app?

Thanks for reviewing it. I’m planning to test, refine, and improve it whenever I have time.

So you didn't test it before releasing.

Anyways;
Like the consensus of the few members who participated in this discussion,
I also doubt that the utility if this App can justify the cost of just sending a message and the burden that it could cause to the blockchain.

[ABCbits]

So how the sender supposed to encrypt the message, without knowing private key of recipient address?

1.Encrypt your message with the recipient's public key

2.Embed it in a Bitcoin testnet transaction using OP_RETURN

3.Recipient decrypts it with their private key

That makes sense. But it require you to know recipient's public key, where it's only exposed when
1. The address spend it's Bitcoin.
2. Recipient share signed message or public key to you.

I also have same concern with @nc50lc about 80 bytes limit of OP_RETURN. Since performing asymmetric encryption with ECSDA isn't something people usually do, i unable to find information about overhead size of it's encryption.

[girayeser]

I also doubt that the utility if this App can justify the cost of just sending a message and the burden that it could cause to the blockchain.

 Do you think using testnet or moving some functionality off-chain could eliminate most of the costs and avoid adding unnecessary load to the blockchain?

I also have same concern with @nc50lc about 80 bytes limit of OP_RETURN. Since performing asymmetric encryption with ECSDA isn't something people usually do, i unable to find information about overhead size of it's encryption.

I will think about it.

[Silentcursor]

Bitcoin isn’t just a currency—it’s a powerful decentralized platform. By using the Bitcoin Messaging App, you can:

- Ensure your messages are immutable and secure.

- Leverage the blockchain for creative use cases beyond transactions.

Who actually wants their private chat and sensitive messages burned into a public ledger?

We have existing end to end encrypted social apps that are faster and ensure users privacy outside of the Bitcoin ecosystem. Allow Bitcoin to do what it was meant to do which is being a currency.

[mcdouglasx]

I do not support any idea that implies worsening its scalability without a greater benefit. Otherwise, what’s next? Using the blockchain to keep a public record of companies’ accounting? I would prefer that OP_RETURN be eradicated or simply made costly to minimize its use for trivial purposes.

[nc50lc]

I also doubt that the utility if this App can justify the cost of just sending a message and the burden that it could cause to the blockchain.

Do you think using testnet or moving some functionality off-chain could eliminate most of the costs and avoid adding unnecessary load to the blockchain?

That would, but take note that every testnet blockchain isn't permanent.

For example: our "testnet3" is already on the brink of getting abandoned to be replaced by "testnet4".
And as you can see in the numbering; there were testnet1 then testnet2 in the past.

Once it gets to the point of being unusable or it can't serve its functions efficiently, a new testnet chain will be created.
Like if its blocks are bloated with transactions containing OP_Return outputs to the point that syncing testnet requires a lot of bandwidth.
Or when test transactions can't get confirmed with low transaction fee since there are a lot of "messages" in the nodes' mempools.

P.S.: I'm not against nor support the idea but I think the mainstream will not adapt such thing given that there are already better alternatives out there.
The niche (bitcoiners) wont like it for misusing the blockchain either.

[pooya87]

I would prefer that OP_RETURN be eradicated or simply made costly to minimize its use for trivial purposes.

It's best to have OP_RETURN and not have "special cost" for it because OP_RETURN outputs are provably unspendable so they can be purged from the UTXO set. The alternative could potentially push people to abusing the protocol and injecting their data using standard scripts that can not be purged which will not only bloat the chain but also the UTXO set.

We just have to discourage people from using bitcoin blockchain a cloud storage and hope the fee market takes care of the rest.