A sigchain is a chain of timestamped signatures. It can be used to issue and transfer tokens at the speed of the lightning network.
Tokens can be issued and transferred on sigchains in one of two ways: a fully censorship resistant way that is slow and expensive and a mostly censorship resistant way that is fast and cheap. The fully censorship resistant way is similar to omni and counterparty (it's also no faster or cheaper than a bitcoin transaction on the base layer) except it inherits some things from RGB, namely, client side validation and better privacy due to not disclosing the full transaction to anyone but the recipient. The second way, however, is about as fast and cheap as lightning, and is also mostly censorship resistant, but you briefly have to put some trust in an oracle. You can override him later if he does censor you by redoing your transaction the first way.
Suppose an oracle maintains a publicly viewable array -- which I will call a sigchain -- of entries having this form: ["keyhash","message","signature","timestamp","ordinal"], and suppose the sigchain has this form: [entry,entry,entry,etc. ]. Suppose the signature in each entry on this sigchain is only valid for the keyhash within that entry concatenated with the message, the user signature, the timestamp, and the ordinal number. Supposing such a sigchain exists and at least one person -- the oracle -- can add entries to it, imagine a world where users send data to the oracle consisting of a keyhash, a message, and a signature, which I will call a datum. If users send a datum to the oracle, the oracle can -- possibly in return for a lightning payment -- create a timestamp and an ordinal number, concatenate the datum with the timestamp and the ordinal number, and immediately add a new entry to the sigchain in the format mentioned above. Any user who submits a datum can then verify that his or her message is attested on the sigchain at a certain timestamp. An ordinal number is a numerical value which follows a timestamp on a sigchain. If there are multiple entries in a sigchain with the same timestamp, those entries are supposed to be ordered alphabetically, and the ordinal number attests to their order for a given timestamp.
Suppose a user called Alice wants to send a message to a user called Bob and ensure it is verifiably attested on the sigchain. Alice can create a datum and send the oracle a lightning payment plus her datum. If the oracle accepts the payment and adds an entry to the sigchain, Alice can send a copy of her datum with her true pubkey (not just its hash) to Bob. Bob can verify that the pubkey provided by Alice hashes to the keyhash in the datum provided by Alice. Then he can verify that her pubkey really signed the message in the datum or discard it if not. Supposing the signature checks out, Bob can verify whether or not the datum is attested on the sigchain by using Alice's keyhash to look up the set of entries in the sigchain containing Alice's keyhash. If Bob finds a set of entries containing at least one match, Bob can use Alice's pubkey to check if their signatures check out for the message in that entry and discard any entries where the signature does not check out. If there are multiple entries remaining after this procedure, Bob can treat the entry in the set with the earliest timestamp as the only valid entry for that pubkey. If the earliest timestamp in the set is the same for multiple entries, Bob can sort the entries alphabetically and treat the one with the lowest alphabetical value as the only valid entry. If the datum in that entry matches the datum given to Bob by Alice, Bob can consider the datum attested on the sigchain.
In this way, Alice can quickly send Bob arbitrary messages which are verifiably attested on the sigchain.
If a group of people wish to use a sigchain without fear of censorship, it seems wise to keep the oracle who runs the sigchain in the dark as much as possible about the contents of their messages. Otherwise, the oracle might censor their entries and refuse to add them to the sigchain -- even for a fee -- if it does not want to attest to certain content.
In the sigchain system described in this protocol, censorship is unlikely if users do not reveal the contents of their messages to the oracle, but only send it a hash of their messages, just as they send it a hash of their pubkeys. As long as users do not reveal their messages to the oracle, it only sees a keyhash, a message hash, a signature, and a payment. It is blind to the messages it attests. Therefore, assuming that users only send the oracle a datum containing a keyhash and a message hash but not a full message, the oracle should not have any reason to treat any datum differently from how it treats others. Moreover, other users can still verify that the oracle attested to a user's full message if the message creator provides them with the full message. The message recipient can hash the message, check if that hash is attested on the sigchain, and -- relying on the assumption that there are no hash collisions for ripemd160 hashes -- infer that the oracle's attestation is valid for the full message and only that message, nothing else.
However, this procedure is not sufficient to avoid all censorship of the sigchain. For one thing, users might reveal the contents of their messages to the oracle, such as if the oracle is -- perhaps unbeknownst to them -- one of the people to whom they are sending a message. Also, the oracle might decide to censor an entry not based on the content of the associated message but based on the keyhash which was sent alongside the entry. This might happen if oracles must, for legal reasons, abide by a blacklist of keyhashes and not attest to messages accompanied by those keyhashes. Also, supposing the oracle ceases operations at some point, that is equivalent to censoring all of its users if no one can add to the sigchain anymore.
To ensure that sigchains are censorship resistant despite these obstacles, there is an alternative way for users to add entries to a sigchain. Specifically, users can add any datum to the sigchain by creating a bitcoin transaction where their datum is in an op_return field. Suppose a user encodes their op_return data in this way: ["keyhash","msghash","sig"]
In sigchain entries created via op_returns, the keyhash field is 20 bytes, the msghash is 20 bytes, and the signature is 40 bytes. An op_return entry in the format mentioned above can substitute for getting an entry attested by the oracle.
Suppose that an oracle's sigchain entries are all shared with a distributed network of sigchain nodes in a manner similar to how bitcoin transactions and blocks are shared on the bitcoin network. Users who wish to independently construct a sigchain and come to consensus on its contents could run a sigchain node which listens for new entries to the sigchain via a gossip protocol with the oracle as its source. A sigchain entry is always considered a valid addition to the sigchain if and only if it matches the format of entries added by the oracle or the format of entries created via op_returns. Another condition is that all copies of the sigchain must sort every entry based on each entry's timestamp. The entry with the earliest timestamp is the first entry on the sigchain, followed by the next earliest, and the next earliest, and so forth. If some entries have the same timestamp, those entries can be sorted alphabetically in ascending order and assigned an ordinal number: the one with the lowest alphabetical value is first and gets the ordinal number 0, followed by the one with the second lowest alphabetical value which gets the ordinal number 1, and so forth.
It may be noted that op_return entries don't have a timestamp in the text of the op_return. For these entries, a timestamp can be inferred using the timestamp of the block the datum is included in. This eliminates the need to put a timestamp in the op_return itself. To allow for up to 544 sigchains, users can put a nonce in their message and use a brute force hashing technique to can ensure that the hash of the first 3 hexadecimal digits of their message hash and their keyhash are always 0s. If each oracle who runs a sigchain commits to one globally unique number out of 544, users of that oracle's sigchain attestations can use these bruteforce techniques to ensure that their entries always make it into the right sigchain even if censored by that sigchain's oracle.
Sigchain nodes construct the sigchain by ordering all entries having this form: ["keyhash","msghash","signature","timestamp","ordinal"] -- regardless of whether they showed up on the blockchain or in the oracle's array. Sigchain nodes consider both sets of entries -- sorted by timestamps and assigned ordinal numbers as necessary -- as constitutive of the sigchain. As long as the sigchain is defined not only as the set of entries in the oracle's array but also as the set of entries constructed using the data in op_returns on bitcoin's blockchain, the oracle cannot censor the sigchain but only deny users access to its own timestamping service. Effectively, there are two sets of people who can add entries to the sigchain: the oracle and bitcoin's miners. Members of either set can be "hired" to perform this service. If the oracle becomes censorious or goes offline, bitcoin's miners can be relied upon to be less censorious, albeit possibly more expensive or slower.
There may be cases where sigchain wallets discourage pubkey reuse by checking if a heyhash is associated with multiple entries in a sigchain and considering only one of them valid, specifically the one whose timestamp is the earliest. In such a case, it might seem possible to trick users into accepting a message which is later invalidated when a second entry signed by the same pubkey is inserted into the sigchain by the oracle or by bitcoin's miners with a timestamp before the original. This could be especially devastating if monetary value in the form of tokens are considered sent and confirmed only if they are in a message which has the earliest timestamp for that pubkey in the sigchain.
One scenario to guard against is where bitcoin miners mine a block which adds an entry to the sigchain where the timestamp of the new block is in the past. In this context, it is useful to recall that there are limitations about how old a block's timestamp can realistically be. A block is invalid if its timestamp is older than the median timestamp of the past 11 blocks. In practice, no block has been mined whose timestamp was older than 7000 seconds in the past, which is a bit less than 2 hours. As a result, there is an easy way to reduce miners's ability to past-date a sigchain entry: if a sigchain entry appears in a bitcoin block, sigchain nodes can add 2 hours to the timestamp of that block and use the adjusted timestamp for the sigchain entry. This procedure should be perfectly reproducible by all sigchain nodes and relatively harmless to users. Users are not expected to use the op_return method of adding entries to the sigchain except in extraordinary circumstances, so they should not be too harmed by the fact that the op_return method is considerably slower. In fact, there is a second reason why the op_return method is expected to be the slower option: op_returns aren't added to bitcoin's blockchain until mined, which on average happens about every ten minutes, whereas the oracle can add entries to the sigchain immediately. So who cares if op_return entries are even slower due to being post-dated by 2 hours?
Preventing oracles from past-dating an entry in the sigchain is harder. I do not know a good way to absolutely prevent it in all cases. However, the oracle's ability to past-date entries can be limited through fraud proofs. Suppose that every time any entry is added to the sigchain, either via op_returns or via the oracle, the oracle must -- before adding any entries after the date of the latest one on the sigchain (including op_return entries) -- use its own pubkey to create an entry on the sigchain which I will call a fraud proof. The message in this fraud proof must be a hash of several hashes concatenated together, specifically, a hash of the previous merge minable entry (unless the current entry is the first merge minable entry in the sigchain) and a hash of each entry that made it onto the sigchain after the previous fraud proof (or starting from the beginning of the chain if the current entry is the first fraud proof in the sigchain). All of these entry hashes must be ordered by the timestamps of their corresponding entries, or, in the case of multiple entries with the same timestamp, ordered alphabetically as described earlier.
If the oracle creates a fraud proof every time any entry is added to the sigchain, then most of the entries on the sigchain will belong to the oracle's keyhash. There will basically be a fraud proof originating with the oracle immediately following every entry that does not originate with the oracle except where several entries are added to the sigchain via op_returns in one block. In the latter case, the oracle must also hash these entries and include them in proper order when it creates its next fraud proof.
The reason why a signed hash of the past state can be used as a fraud proof is this. Consider that an oracle might attempt to alter the history of a sigchain in three ways: by changing the timestamp of a past entry, by inserting a new entry in between the timestamps of two older entries, and by dropping an old entry altogether. Users who already have a full copy of the sigchain can detect these alterations of the sigchain's history because their copy of the sigchain will no longer match the one the oracle presents on its website. However, without proof that the oracle attested to the state recorded in theircopy of the sigchain, users who do not have a full copy of the sigchain, such as spv wallet users and new node users who are still syncing the sigchain, cannot know which copy of the sigchain is correct: the one provided by a regular node or the one provided by the oracle. With fraud proofs, the state of the sigchain is signed by the oracle with every entry, and past entries in the sigchain can be used to independently construct what the hash of the fraud proof should be at any given position. If a new user or an spv wallet user wants proof that the oracle signed some entry with a given position, a fraud proof can provide an ironclad demonstration. Moreover if, for a given timestamp:ordinal pair, a user sees two different fraud proofs signed by the oracle, that user then knows that some alteration took place and the oracle violated some rule. Fraud proofs thus make alterations of a sigchain's history detectable as long as there are independent nodes who keep copies of fraud proofs.
Fraud proofs are useful because they prevent the oracle from altering the history of the sigchain without detection. Moreover, some of the data in these entries can be added to bitcoin's blockchain through a blind merge mining transaction. If this is done, anyone who obtains the full list of sigchain entries via the sigchain's peer to peer network can verify the history of the sigchain up to the time of the latest fraud proof whose signature has been added to bitcoin's blockchain in an op_return.
What's more, fraud proofs can be merge mined. The oracle's pubkey and signature can be added to bitcoin's blockchain in an op_return by anyone. If any user does add the oracle's pubkey and the signature of a fraud proof to bitcoin's blockchain, then the first such signature on bitcoin's blockchain that is valid for a fraud proof at a given timestamp:ordinal pair can be used to conclude that that is the only valid fraud proof for that timestamp:ordinal pair, and that any future entry which masquerades as a past entry is invalid. Anyone will be able to verify that a past-dated entry's timestamp is invalid as long as it is past-date to a time before the most recent merge mined fraud proof, because they can check whether the hash of that entry is included in the most recent merge mined fraud proof or not. Users can thus use merge mined fraud proofs to come to consensus about the order and history of a sigchain up to the time of the latest merge mined fraud proof.
Messages and sigchains can be used to issue and transfer assets at speeds roughly equivalent to bitcoin's lightning network. Suppose a user called Alice wants to issue 100 tokens. She can create an issuance message, hash it, sign the hash with a pubkey, concatenate her keyhash, msghash, and signature into a datum, and add an entry containing that datum to the sigchain either via the oracle or via an op_return. An issuance message must have this format: "keyhash 1ef...50a received 100 tokens from an issuance transaction, the token id is 5d2...9a4." The pubkey that hashes to the recipient keyhash must sign issuance transactions and the token id must be globally unique for each asset.
Once Alice's signature is in the sigchain, Alice can prove to anyone that she issued 100 tokens by sending them her message and her pubkey. Other people can use the information provided by Alice and the sigchain to verify that 100 tokens were in fact issued and were sent to the keyhash provided by Alice. Alice could also issue more tokens of the same kind by creating a similar message again, thus inflating the supply of tokens. If her token is one where inflation is desirable, such as a usd-based stablecoin where more tokens are periodically issued when users pay to create them, that is well and good.
Suppose a company wishes to issue token issuances in a way that is publicly auditable. There is a way to do that. The company can ensure that each of their pubkeys only adds one message to the sigchain containing the terms of the issuance and they can publish the full, unhashed issuance message on a public website. The company may also declare on its website which pubkeys are valid issuers of that company's tokens. User wallets can then ensure that they only accept tokens with provenances that trace back to a public issuance by one of those approved pubkeys.
Later, I will explain how users who receive tokens can verify the provenance of their tokens before providing a receipt for the transaction. Users who desire to reject tokens whose provenance does not lead back to a public issuance can use wallets which refuse to provide a receipt for such transactions. Thus client side validation with sigchains is sufficient for ensuring that token issuance is auditable in cases where it is desirable for a token to have an auditable supply.
Suppose a user called Alice controls the pubkey 1ef...50a which, through its keyhash, has already received 100 tokens from an issuance transaction or another transfer transaction. Alice wants to transfer 50 tokens to someone's keyhash. She can create a transfer message, hash it, sign the hash, concatenate her keyhash, msghash, and signature into a datum, and add an entry to the sigchain either via the oracle or via an op_return. A transfer message must have this format: "keyhash 4a1...990 received 50 tokens from pubkey 1ef...50a, the token id is 5d2...9a4." The sender's pubkey must sign transfer transactions. Clients only see them as valid if the sender sent tokens they previously received either via issuance transactions or through other transfers.
Suppose a user called Alice wants to transfer 50 tokens to a user called Bob. Alice gets a keyhash from Bob (suppose it is 4a1...990) and uses one of her own pubkeys (suppose it is 1ef...50a) to sign a transfer message, hash it, and put the resulting datum on the sigchain. Then she sends Bob a full copy of her message. The transfer message is just like the one mentioned above: "keyhash 4a1...990 received 50 tokens from pubkey 1ef...50a, the token id is 5d2...9a4," where pubkey 4a1...990 is Bob's keyhash. Bob can use Alice's pubkey to look up the set of entries in the sigchain containing Alice's keyhash and her signature. If Bob finds a set of entries containing at least one match, Bob can verify whether Alice's message was signed by her pubkey and attested on the sigchain as the earliest message signed by that pubkey. If any of these checks fail, Bob can disregard the transaction as invalid.
If every sigchain wallet abides by the rule that only the earliest message signed by any pubkey is valid, that should prevent double spends. If some wallets do not abide by this rule, the users of those wallets will not have that protection against double spends. This major downside may encourage them to adopt wallets that only treat the earliest timestamped message by each pubkey as valid.
Assuming Bob's wallet verifies that the earliest timestamped message by Alice's pubkey "checks out" in terms of having a signature that is attested on the sigchain, Bob's wallet is now at the part of the transaction where it should check the provenance of the tokens transferred to him. In order to do this, Alice's wallet must send Bob's wallet a proof of provenance. This can be done at the same time the token transfer message is sent. Suppose Alice received her tokens directly from an issuance transaction. In that case, she should send Bob the message which transferred her the tokens -- that is her proof of provenance.
Bob's wallet can use Alice's proof of provenance to check if the issuance transaction follows the rules his wallet follows. For example, was the issuance signed by a pubkey belonging to a company he trusts to legitimately issue tokens? Is the signature of the issuance attested to on the sigchain? Was it a publicly auditable issuance? If the proof of provenance fails any of these checks, Bob's wallet can disregard the transaction as invalid.
Perhaps Alice did not receive her tokens directly from an issuance transaction but from a prior transfer. If so, her proof of provenance will be longer. She will need to send Bob a trail of transfer messages proving that every token she sends him was issued according to the rules Bob's wallet follows. This proof of provenance could be rather long. Once Bob's wallet has a complete proof of provenance from Alice, it can check everything out by ensuring that the tranfers and issuance transactions are attested on the sigchain. If any check fails, Bob's wallet can disregard the transaction as invalid. In this way, Alice can only send Bob money and expect anything in return if she first validates that their wallets follow the same rules (such as by checking version numbers) and that her proofs of provenance check out before sending anything to the sigchain for attestation. This does impose a storage burden on sigchain users, who must store a train of messages in order to validly send anyone money and expect a receipt. But these storage costs should be low as long as messages are small. In fact, wallets can disregard transactions with too-long messages as invalid.
Sigchain users can always see if a given pubkey ever signed multiple messages on the sigchain and only accept the earliest messages from a given pubkey. They can also use the sigchain plus the proof of provenance to ensure that they are not receiving counterfeit tokens but only tokens that come from issuers they trust. These protections should reduce the likelihood of counterfeiting and double spending to acceptable levels of trust minimization. All a user needs to do is verify that the sender has enough tokens to cover the expenditure (that is what the proof of provenance is for) and that they aren't accepting a late message (by only considering the earliest message signed by a pubkey as valid). Given those two provable facts -- i.e. that the sender has enough tokens to cover the expenditure and isn't double spending anything in this transaction (because this pubkey never signed anything before) -- the recipient can be confident that they have proof that they received the tokens and no one else has them.
In many of these examples I assumed Alice received 100 tokens at one of her keyhashes and later sent out 50. If wallets never consider a second expenditure from a pubkey as valid, how can Alice ever get her money back? The answer is similar to how bitcoin works: when Alice sends money to Bob, she can send any "change" -- leftover funds not given to Bob -- to a new keyhash belonging to herself. Thus her transfer transaction would look like this: "keyhash 4a1...990 received 50 tokens from pubkey 1ef...50a and keyhash 30c...bb4 received 50 tokens from pubkey 1ef...50a, the token id is 5d2...9a4," where 4a1...990 is one of Bob's keyhashes and 30c...bb4 is one of Alice's keyhashes. If Alice is concerned that such a transaction will give Bob a way to check if she still has that money in the future (since he will see the transaction too and can check if her new keyhash is associated with a new message in the future), Alice can immediately send her money out again to yet another new keyhash. As long as the second transfer uses lightning to pay the transfer fee and as long as Alice does not show Bob the second transfer message, it should be a cheap way to restore Alice's privacy, because Bob will only be able to see the message hash, not the message or the new keyhash within it.
Issuing tokens or transferring tokens should not typically involve much waiting. The steps for issuing tokens are typically: validate some data, send it to an oracle, and pay a lightning payment. The issuance should ordinarily be considered valid as soon as the oracle adds the entry to the sigchain, which shouldn't take more than a few seconds since the oracle doesn't have to validate anything. Transferring tokens should also be very fast. It is the same procedure except now you have to also send a message to the recipient and wait for him to give you a receipt (after he looks up some signatures on the sigchain and then validates the data). Again, none of this should take a long time.
One exceptional case might be this: suppose an entry to the sigchain is made via an op_return instead of via the oracle. This might be necessary for a user whose keyhash is on some sort of blacklist. Hopefully, to avoid delays when buying their coffee, blacklisted individuals would transfer the tokens to a new keyhash via an op_return transaction well before they go to get coffee. These transactions are uncensorable since they are done using bitcoin's blockchain and, unless the blacklisted person leaks the new keyhash to someone and it gets to the oracle, they should be able to use their funds again censor-free (and therefore at lightning speed). If they don't take that precaution, waiting for a confirmation will probably be necessary unless the recipient is okay with receiving unconfirmed payments on the blockchain.
It is important to note that the sigchain oracle cannot alter the past of a sigchain except for messages that happened after the most recent merge mined fraud proof. Some users therefore may not consider a transaction finalized until someone merge mines a fraud proof that includes their transaction in its concatenation of hashes. I don't think most users will think this way unless their transaction is of a kind where their counterparty is likely to have an opportunity to collude with the oracle to alter the sigchain's history. I doubt this will usually be a concern, especially for low value transactions.
One might wonder if another exceptional case involves doublespend attempts. For example, suppose Alice adds an entry to the sigchain via the oracle which sends some tokens to Bob and simultaneously adds an entry via an op_return which sends the same tokens back to herself. Might Bob have to wait in this case? No. If Bob's wallet sees an entry in the sigchain via the oracle and another entry waiting for confirmation via an op_return (or even one that is already confirmed), all Bob's wallet needs to do is rely on the policy of "only the earliest entry is valid." Op_return entries are post-dated by 2 hours, so as long as the oracle entry is confirmed before then, that is the one Bob's wallet should consider valid.
It is also possible for the oracle to collude with Alice with an intention to insert an entry before the entry where Bob is the recipient, and in this past-dated entry, Alice's funds are sent back to one of Alice's keyhashes. This is a potential concern for Bob, who cannot know that this will happen in advance. If it happens, Bob will probably lose an item of value and the transaction that was supposed to pay him for it will effecively be removed from the sigchain -- unless he got lucky and someone merge mined a signature that is valid for an entry which includes his transaction in its concatenation of hashes before the sigchain was able to effectively help Alice doublespend. If Bob does not get lucky in this manner, he will lose money because he trusted the oracle which colluded with Alice to do a doublespend. However, even if that happens, there will be publishable proof that the oracle acted fraudulently as long as someone (such as Bob himself) keeps a copy of the fraud proof signed by the oracle when Alice's original entry was added to the sigchain. Bob can use that fraud proof to publicly shame the oracle. If Bob publishes this proof of fraud on the internet, many people might be dissuaded from using the dishonest oracle. If the oracle can be trusted not to act maliciously in this way, the system is robust even against these types of frauds.
Token transfer messages and token issuance messages can specify spending conditions that must be followed by token recipients. A field can be added to a transfer message saying something like: "The recipient can only spend this if they sign the transfer and disclose the preimage to this hash: 7ea...026, alternatively the sender can spend it if the timestamp of the expenditure is after timestamp such-and-such." That would effectively put the funds in an htlc on the sigchain. A network of payment channels using htlcs could then be created that is basically a clone of the lightning network. Other spending conditions could also be enforced, developers could let their imaginations go wild.
If smart contracts are used, recipient wallets will need to understand the spending conditions of the tokens they receive and know what to do with them. If a wallet receives tokens but does not understand the spending conditions, it should disregard the transaction as invalid. Perhaps the user can download a wallet which does recognize the spending conditions, import his private keys to that wallet, and then his new wallet will regard the transaction as valid.
A wallet will also need to understand the spending conditions of the ancestors of its tokens in case they restrict their descendants in ways which are not mentioned in the latest message. They can use a token's proof of provenance to check if any ancestor transactions created spending conditions which the current wallet does not understand.
There may be circumstances where an oracle can no longer provide its services and must stop operations. If a wallet only knows about the oracle's attestations by checking the oracle's website, that wallet's users could be in for a bumpy ride if it suddenly ceases operations. Their wallet would look up data on the sigchain via bitcoin and via the oracle's website, which, if it no longer exists, contains no transactions. Thus the transactions on bitcoin's blockchain would suddenly be the only valid ones which that wallet knows about, and this could result in double spends where oracle transactions that used to exist prior to an attempted doublespend on the blockchain are suddenly no longer considered part of the sigchain as recognized by such wallets.
This scenario seems similar to a scenario where some bitcoin users use a wallet which relies on a node that stops working. Their wallet also stops working and consequently it can seem like they lost money. But users who run their own sigchain nodes would not be affected in the same way, nor would users who get data about the sigchain not only from the oracle's website but also from a peer to peer sigchain network.
There are other downsides to a sigchain's death, including that the sigchain can now only be added to by means of bitcoin transactions, slowing everything down and probably making everything more expensive. Strategies to mitigate or avoid the downsides of an oracle's death include: first, choose oracles responsibly. Don't use a sigchain run by a disreputable oracle that might go away at any moment. Consider using a sigchain maintained by a quorum of oracles who share the income obtained via transaction fees. Reliable oracles should also post all updates to the sigchain in multiple places simultaneously so that users' wallets don't display errors due to a website being down, and wallets should get data about the sigchain from a peer to peer network rather than only relying on the sigchain's website.
An oracle's death is sort of a "censor everyone" scenario. No one can add to a sigchain by means of a dead oracle, but since sigchains are censorship resistant, users can still add to the sigchain by adding transactions to bitcoin's blockchain. This would make sigchains as slow as bitcoin after the oracle's death, but, if there are sigchain wallets with lightning support, users could still migrate to those wallets and basically get the sigchain up to speed again, albeit with some new encumbrances like channel management and liquidity issues.
Another option to mitigate oracle death is to hard fork to a new oracle whenever the current one dies and ensure that the new oracle has a copy of the sigchain. If the oracle's death is not sudden but prepared for ahead of time, this even brings the possibility of a smooth transition.