Using BTC as time sequence server to allow cross chain atomic swap and increase security of altchain


Active Member
Feb 26, 2016
From Satoshi's paper:

3. Timestamp Server
The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.


It is the timestamp server that enables the rest of bitcoin to work and without a timestamp server, it appears trivial to double spend as there wont be a way to know the balance of an account at any given time. Regardless of whether a timestamp server alone is sufficient, it is clearly necessary.

We will ignore all issues regarding PoW vs PoS vs PoAnything and concentrate on creating a universal timestamp, or rather a time sequence server via bitcoin. The effect of having a universal clock is that synchronized operations can be done across all other blockchains who adopt the bitcoin time sequence server.

A. In the beginning there was no bitcoin and until genesis block it was not possible to be utilized in any way. However, now that it exists and is clearly "real", we have enormous amounts of hashrate securing the steady stream of bitcoin blocks. Due to the way the consensus works, there is a chance that the current block is superceded by a "better" block and even the most recent 2 blocks, or 3, or ... However, the chances rapidly diminish to an extremely remote possibility. The exact number of confirmations that is considered safe from reorg is certainly a critical decision, but it does not affect the proof of time stamp serverness.

Let us call this depth L, for lag. It will be assumed that any bitcoin blocks with L or more confirmations are permanent. For practical applications, it is suggested to have a mechanism to detect and recalibrate in the rare case of a bitcoin reorg beyond L blocks, but if the probability of such an event is remote enough, other means of compensating for it are also possible, ie insurance type methods of risk sharing.

B. Given the assumption that any blocks with L confirmations are valid, at any given time there is a "current" permanent BTC block, with its blockhash. And most times a new block is generated, we get a new permanent BTC block. However, when there is a small reorg or a replacement of the tip, we do not get a new permanent BTC block. A simple way to calculate whether a new BTC block advances the permanet BTC block is to verify that it is L+1 confirmations from the previous permanent block.

What this means is that as bitcoin does its small reorgs, the permanent blocks will not advance until things catch up. However since most reorgs are caused by a new pair of blocks that extend the chain and bypassing the current tip, this stop/starting of the permanent blocks are mostly insulated. This stop and go behavior combined with the +/- 2 hours tolerance on timestamps makes the BTS not a timestamp server, but a time sequence server. It is not as useful, but still a framework that can be built upon.

We now have a sequence of permanent blocks Ti, Ti+1, Ti+2, ... with the proven characteristic that each Ti came after the preceding one, ie. an ordering of blockhashes. Another small concession that will be made is that we will assume that SHA256 collisions can be ignored, bitcoin now does not allow duplicate blockhashes, so even if there is a collision it will probably not affect things, but the odds of such are so small, it will simplify the analysis to ignore its effects.

C. What can be done with the set of permanent blockhashes? They can be used by any external blockchain or in fact anything as proof of time sequence. Using the law of common sense and assuming the ban on time travel is still in effect, we can see that to be able to know a specific blockhash Ti indicates it must have happened after that blockhash appeared. Since Ti first appeared in the mining node even before it was submitted, it could have been known right after blockhash Ti-1 appeared. Yes, this will be a very slow clock indeed, but a clock nonetheless.

Being able to refer to a permanent blockhash Ti shows that it happened after L+1 confirmations ago. What this means is that regardless of whether this hash Ti is put into the altcoin's chain via consensus or by attacker, all blocks after it are shown to have happened after the earliest time that Ti was known.

Let us assume that the permanent blockhash sequence is either fully or partially referred to in the external chain. This gives us a partial ordering of all the external chain blocks as having happened no sooner than when Ti was known. If the protocol gives more weight to referals to the oldest Ti, then an eventual consensus will arise with external chain blocks grouped into segments such that each segment is known to have happened after the blocks in the prior segment. By having a block rejection rule to reject blocks too far from the past, if this "too far" is set to be a fraction of the times between Ti, then we get a provable time ordering if there is 1 or more Ti between two external chain segments and a likely time ordering for adjacent segments.

D. Now each external chain is divided into universally verifiable groups of blocks, that regardless of the strength of the consensus mechanism for that external chain (even if it has none!), it is able to conduct cross chain transactions with other external chains using the same segmentation. Well, not quite. Of course if the external chain is some arbitrary ledger that can be updated at will by some corporate entity, then these security assumptions do not hold up. What is required is another rule in the external chain that after R permanent Ti blocks have passed, that it is permanent. This R (for reorg) factor will then allow other external chains to know that after R permanent blocks it cannot change and also the partial time sequence is externally verifiable.

E. This is just a first draft and many improvements are possible. For instance, by using blocks very close to the current, the external chain can create a lot finer grain ordering internally, unless bitcoin reorgs the referred blocks away.

F. tl:dr it wont be fast, but using bitcoin as the universal clock, all external chains that add a few consensus rules can interact as long as enough bitcoin confirmations are waited.

G. Appendix: put fancy math that almost nobody understands here
  • Like
Reactions: _mr_e and Bloomie


New Member
Mar 3, 2016
Putting this link here for someone like me who is still learner of Bitcoin and Cryptocurrency:source

What is trusted timestamping?

Trusted timestamping allows to prove you held a document, some information or a file at some specific point in time, in a way that can't be forged. Read more at Wikipedia.

What is it good for?
  • Before signing an NDA, you can keep a trusted proof of the knowledge you had in that field prior to to signing it.
  • You can prove you developed a specific revesion of your software in a specific point in time by timestamping the hash of your revision tree. With Git, its as simple as timestamping the current commit SHA1.
  • Before sharing your ideas with third parties, you can timestamp the information you're about to share with them, as well as the fact that you're sharing it with them, to help resolve possible disputes.
  • Contracts can be timestamped (along with digital signatures of both parties) to prove when they were signed.
  • Musicians and other digital art producers can prove when they created their work.
How does timestamping on the Bitcoin network work?
Its possible to hash the data you wish to timestamp and turn it into a Bitcoin address. By making a small payment (a satoshi, or 0.00000001 BTC) to it, the payment is stored on the blockchain along with the address you paid to.

Since only the hash is stored on the Bitcoin blockchain, no one can tell what data you stored, but given the pre-hashed data you can prove the data was created prior to the block that contains the payment made to that address.

Update: Bitcoin-qt 0.8.2 doesn't relay transactions with small outputs by default. A lot of miners still accepts those transactions, so it'll work fine in the short-term (and once the transactions is accepted into a block, it'll be part the Bitcoin network forever). This method will be replaced in the future, when it becomes difficult to send those transactions.

What are the advantages of using the Bitcoin network?
  • You're not dependent on any single authority. Traditionally, trusted timestamps are issued by trusted third parties called TSAs (Time Stamping Authority), which are prone to data corruption and tampering. On the Bitcoin blockchain, your timestamp is safely stored all over the world, and ismuch harder to tamper with.
  • Its anonymous. No one knows who you are, what data you're timestamping, or even the fact that you're timestamping anything.
  • Its really cheap. At the current rates (~$110), including the transaction fees, it costs around 5 cents. You can make a transaction without fees, lowering the cost to $0.00000116, a fraction of a cent. However, it is highly recommended to pay the fees to support the miners who verify your timestamp with their computing resources. In addition to that, making such a tiny transaction without fees might take long to get into the blockchain, if ever.
  • Its really simple. You can create trusted timestamps using any Bitcoin client, and its easy to automate the process using bitcoin's JSON-RPC API.
Will it hold in court?
IANAL, TINLA. That being said, I believe it will. From a technical point of view, its nearly impossible (much more so than with TSAs) to fake a timestamp created like that. You will probably need to bring a technical expert to testify to that.

Doesn't it destroy the Bitcoins used to pay to that address?
Yes. The coins are sent to an address that they can never be redeemed from, effectively taking them out of circulation. However, because its only a fraction of a bitcoin, the effect is minimal. To put this in perspective, creating one billion timestamps is equal to 10 BTC being lost due to someone losing his private keys (which is quite common and happens on much larger scale).
And this video explains use of Bitcoin TimeStamp good too:

Last edited:


Mar 6, 2016
regardless of the strength of the consensus mechanism for that external chain (even if it has none!)
Still wrapping my mind around this. Could an external chain have its security entirely based upon this mechanism, in a sort of disconnected, time-delayed, non-invasive mergemining?


Active Member
Feb 26, 2016
Not entirely. the synchronized chain would need to establish consensus inside of each time segment, but there are many ways to achieve this, even using non-blockchain methods.

Also, the reference might be time delayed, but things can happen in realtime. A bit hard to see this at first, but the key idea is to think about time zones. Let's assume we have an atomic clock with reliable time, but it is 3 hours time shifted. We dont have to wait 3 hours, we just adjust the time by 3 hours and get a "realtime" clock using an old signal.

It does require a consensus rule where all things are tagged with the latest permanent block. Alternatively, a tx can be rejected if it misses the time window, but I prefer a system where a valid tx is valid and having as few things as possible to invalidate it. And if it is rejected by some nodes and not others, then getting consensus seems much more difficult. A bit more overhead to add meta data with the later sequence markers, but I think it is worth it as the blocknumber could be used instead of the full blockhash

So each tx/block in the synchronized chain will have an (earliest, latest) time bracket. Propagation delay requires it to span at last 2 blocks, but still that is 3 synchronization points per hour. Not sure if it can be interleaved, simpler to just say things are synchronized on even blocks, with the odd blocks there to take care of the times when a new block appears as a new tx propagates


Active Member
Feb 26, 2016
Finally had some time to code this up.

A segment is the set of all altcoin blocks that refer to a specific BTC hash.
A segment merkle is the merkle root of all the blockhashes in a segment

Each peer follows these consensus rules:

each altchain block refers to a fix distance (3 back) from BTC chaintip and a timestamp that is within 1 minute of a deterministically calculated "now" (using BTCD combined with BTC recent blocks)

An altchain block is rejected if its timestamp is not within 1 minute of the deterministic "now" working backward from the alt block timestamp. ie. get the N most recent BTCD and BTC blocks from the alt block timestamp and do a simple averaging and projection of "now" using the timestamps in those recent blocks. I think the median "now" can be 30 seconds after the most recent BTCD timestamp

also an altchain block is rejected if it does not refer to the correct BTC hash, 3 or 4 (needed due to propagation delays at segment boundaries) back from the current BTC chaintip.

Now the fun begins. As it is, the security level depends entirely on the security of the altchain. If you have a full node always running on all the altchains, then it is probably adequate, but it would be nice to be able to independently verify any altchain after the fact.

To do this we need to rely on an external reference, ie BTC blockchain. However nothing prevents an attacker from rewriting the altchain and then posting the attacker's segment merkle. With this protocol, if this does happen, then the attacker's chain is the mainchain and new nodes will follow the attacker's chain. So we need to rely on the majority stake to validate a segment merkle.

When a new segment starts, the altchain miner posts the segment merkle to the BTCD chain. To prevent last minute sniping by the attacker, honest miners should also add their segment merkle, even if it agrees with what is already posted. If any node sees an invalid segment merkle, then it needs to post the valid one.

When the next segment starts, a consensus segment merkle is calculated from the BTCD chain using combined stake to determine the winner and written to the BTC chain. As soon as this tx is seen in the mempool, any node that disagrees needs to post the valid stake consensus segment merkle.

In the event of conflict, the same stake based consensus is used to determine the valid segment merkle.

Each node should use the original segment blocks data it recorded when calculating the segment merkle. This minimizes the effect from invalid segment merkles in the BTCD chain. Any detected attacks on the BTCD chain should be posted to the BTC chain to help resolve conflicts. The specifics of the data posted is still being worked out.

Currently it takes 3 BTC blocks to reach a consensus segment merkle, but due to the occasional fast (and empty BTC) blocks it is better to relax this to 6 blocks. This gets us an expected time per segment of 1 hour and we can wait an extra confirmation before resolving conflicts, which avoids the vast majority of the small BTC reorgs (90%+ are for one block due to propagation delay)
[doublepost=1465207448,1465206729][/doublepost]After extensive discussion with Anonymint, the process is improved to avoid the messy conflict resolution phase.

Since the basilisk lite nodes are already relying on the iguana full nodes, we can have a set of recently active and reliable iguana nodes to directly validate a segment merkle to the BTC chain. To make the costs more reasonable, the BTCD chain can be used for high frequency and the BTC for hourly (or daily)

An altcoin that doesnt fund the signing costs will lose the BTC secured status, but can still have BTCD secured status, unless it also runs low for that. However, provision will be made for any node to be able to pay into a group fund for each private chain, so any interested party can top up the fees required to get the additional BTCD and BTC security.
[doublepost=1465207833][/doublepost]Now I need to figure out how to properly determine if indeed a majority signed a schnorr signature


Active Member
Feb 26, 2016
more invaluable feedbacks, seems the N@S dragon is finally slain with the "delayed PoW" that this method represents.

I am coding up the actual implementation with the suggested changes