Bitcoin Forum
January 01, 2026, 07:08:07 AM *
News: Latest Bitcoin Core release: 30.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Cipher Pulse: E2EE Messaging with Blockchain-Based Time-Locks (Trustless)  (Read 54 times)
Cipher-Pulse (OP)
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
December 17, 2025, 12:12:28 AM
 #1

Hello everyone,

I'd like to introduce Cipher Pulse today, a secure and open-source messaging application. While it has many privacy features (E2EE, P2P, etc.), I want to highlight a specific feature that I believe will be of particular interest to this community: cryptographically guaranteed Time-Locks.

The Problem: Releasing Information in the Future

How can you guarantee that a message or file is only accessible at a specific future date and time, without having to trust a central server? Servers can be hacked, their clocks can be manipulated, or their operators can be forced to reveal information prematurely.

Our Solution: The Blockchain-Based Time-Lock

Cipher Pulse solves this problem by using the blockchain as a decentralized and immutable source of time.

Here's how it works:

When you send a "Time-Locked" message, the message's decryption key is encrypted and stored on our servers.
The unlock date and time are recorded as a timestamp on a public blockchain.
The message can only be decrypted when the user's client can verify in a trustless manner that the time condition on the blockchain has been met.
The result: The message's release isn't controlled by Cipher Pulse. It is governed by a decentralized and immutable consensus. There is no administrator who can "open the message early."

Concrete Use Cases for the Bitcoin Community

This technology opens up interesting possibilities:

"Dead Man's Switch": Reveal private keys or sensitive information only if you fail to check in before a certain date.
Sealed Bids: Allow participants to submit encrypted bids that can only be revealed at the close of the auction.
Digital Wills: Pass on instructions or access to your heirs at a future date.
Scheduled Announcements: Prepare a revelation or publication that cannot be altered and will be made public at a precise moment.
Technical Foundations

To ensure the project's credibility, the rest of the cryptographic stack is also robust and open-source:

Authentication: SRP (Secure Remote Password) - The server never sees your password.
Key Exchange: X3DH (for asynchronous session establishment).
Conversational Encryption: Double Ratchet (for Perfect Forward Secrecy and post-compromise security).
Identities: Support for BIP-39 mnemonics and DiceKeys for robust recovery and entropy.
The project is a monorepo (backend + frontend + desktop) and is fully auditable.

GitHub Link: https://github.com/oykdo/cipher
Web Demo: https://cipher-pulse.onrender.com

I'm here to answer your questions, especially about the Time-Lock implementation. Any constructive criticism on the security model or cryptography is welcome.

Thank you for your time. I am signing off for now. I will address all the points raised in several hours (euw timezone)

大家好,

今天我想向大家介绍 Cipher Pulse,一个安全且开源的消息应用程序。虽然它拥有许多隐私功能(如端到端加密、P2P等),但我想重点介绍一个我认为会引起本社区特别关注的功能:加密保证的时间锁。

问题:如何在未来发布信息

您如何能保证某个消息或文件只能在特定的未来日期和时间被访问,而无需信任任何中心化服务器?服务器可能被黑客攻击、时钟被篡改,或者其操作员可能被强迫提前泄露信息。

我们的解决方案:基于区块链的时间锁

Cipher Pulse 通过使用区块链作为去中心化且不可篡改的时间源来解决这个问题。

工作原理如下:

当您发送一个“时间锁定”消息时,该消息的解密密钥会被加密并存储在我们的服务器上。
解锁的日期和时间会作为时间戳记录在公共区块链上。
只有当用户的客户端能够以无需信任 的方式验证区块链上的时间条件已满足时,消息才能被解密。
结果: 消息的发布不受 Cipher Pulse 控制。它是由一个去中心化、不可篡改的共识机制来管理的。没有任何管理员可以“提前打开消息”。

比特币社区的具体用例

这项技术为许多有趣的应用场景打开了大门:

“死亡开关”:只有在特定日期前您未能“报到”时,才会揭示私钥或敏感信息。
密封投标:允许参与者提交加密的投标,这些投标只能在拍卖结束时被揭示。
数字遗嘱:在未来的某个日期将指令或访问权限传递给您的继承人。
定时发布公告:准备一份无法更改的公告或发布内容,它将在精确的时刻自动公开。
技术基础

为了确保项目的可信度,其余的加密技术栈同样强大且开源:

身份验证:SRP (安全远程密码) - 服务器永远看不到您的密码。
密钥交换:X3DH (用于异步会话建立)。
会话加密:双棘轮算法 (Double Ratchet) (提供完美前向安全和后攻防安全)。
身份:支持 BIP-39 助记词和 DiceKey,以实现强大的恢复能力和高熵值。
该项目是一个单体仓库(包含后端、前端和桌面应用),完全可审计。

GitHub 链接:https://github.com/oykdo/cipher 在线演示:https://cipher-pulse.onrender.com

我在这里回答大家的问题,尤其是关于时间锁的实现。欢迎任何关于安全模型或密码学的建设性批评。

感谢您的时间。
BattleDog
Full Member
***
Offline Offline

Activity: 125
Merit: 152



View Profile WWW
December 31, 2025, 11:16:24 PM
Merited by Vod (1)
 #2

(.....)
Here's how it works:

When you send a "Time-Locked" message, the message's decryption key is encrypted and stored on our servers.
(......)

If the server is in the loop, it can always censor by not serving it, and if it ever serves it, a modified client can ignore the wait for chain condition check and decrypt early.

So the only way a trustless timelock really holds is if the key material is cryptographically unrecoverable until some public, independently-verifiable event happens, not just "our client won't try until the timestamp says ok".

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!