Check out the project on GitHub: https://github.com/theRomanMercury/BitcoinMessagingApp
This cool Windows app lets you send and receive secure messages using Bitcoin Core. Take your messaging game up a notch by tapping into the Bitcoin blockchain!
What’s in it:
🔹 Messaging on the Blockchain:
Send and receive messages through Bitcoin's OP_RETURN field, offering top-notch security and transparency.
🔹 Real-Time Inbox Updates:
An inbox that updates in real-time, automatically checking for incoming messages on the blockchain with an integrated Timer.
🔹 User-Friendly Design:
Login is a breeze with Bitcoin Core RPC credentials. The design is clean and makes for smooth interactions.
🔹 Open Source:
It's all open-source, and we’re ready for contributions!
Why it’s Important:
Bitcoin isn't just for transactions it's a solid decentralized platform. With this Messaging App, you can:
- Keep your messages secure and unchangeable.
- Use the blockchain for more than just transactions.
Support the Development:
💡 If you dig this project, think about helping it grow:
Bitcoin Donation Address: bc1qqx2asqpelkh0trqhd44qgx9xsklnw0pu3n559u
Join the movement!
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.
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!
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.
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!
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).
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 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.
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.
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...
Thanks for reviewing it. Im planning to test, refine, and improve it whenever I have time.
Im considering a privacy feature where the message sent via OP_RETURN would be encrypted and only readable by the recipient using their private key.
Im also considering running it for free on the off-chain testnet. If it's possible.
So how the sender supposed to encrypt the message, without knowing private key of recipient address?
You didn't start development of your app using testnet?
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
I havent started development on testnet yet because Im 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, Im reviewing feedback and ideas shared on the forum to figure out the best possible structure and direction for the application.
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.
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.
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.
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 will think about it.
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.
I do not support any idea that implies worsening its scalability without a greater benefit. Otherwise, whats 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.
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.
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.