Bitcoin Forum

First go read and understand CoinWitness (https://bitcointalk.org/index.php?topic=277389.0), it describes an application for using proven computation in scripts, and also provides some background about the provable computation tools which I won't repeat here.

In this message I describe another application for using provable computation (SCIP) as a script replacement, but this one isn't at all serious. It's downright amusingly bad.

A checksig operation in a transaction script logically receives a pubkey, a signature, and a hash of the masked transaction (effectively a hash of the transaction with the scriptsigs removed; all this ignoring sighash flags for the purpose of discussion).

In a world where we have a SCIP-script checksig operator it would work similarly:  It would receive some optional additional public data, a public key (verification key), a signature (proof), and a hash of the masked transaction.   To produce a signature for this system you would run the SCIP-script program corresponding to the verification key inside the SCIP prover, giving it as a public input the hash of the masked transaction and any extra public or non-public inputs. If the program accepts the result is the proof your transaction needs to be considered valid.

Because the hash of the masked transaction itself is part of the public input, the SCIP-script could also require the unhashed masked transaction as a non-public input when it runs. The program could then test any of the non-masked data in the transaction, and only ACCEPT if it likes it.  E.g. it could check the scriptpubkeys against a list or their output values against a range.  It could choose to only sign if the transactions' nlocktime was high or low enough, or any mixture of these options.  Because the inputs (which are themselves transaction hashes) are covered under the hash,  the script could go further and require that you provide the input transactions— and it could apply whatever tests it wants on the inputs— potentially following them all the way back to an enormous number of coinbase transactions, imposing any computable rules it likes along the way.   If you can't satisfy the rules, you can't spend the coin.

A particular sort of rule could take the form of requiring any output scriptpubkey to be of the form THIS_VALIDATION_KEY && {whatever rules you want} and by doing so you have effectively created a coin which is forever subject to a covenant (http://en.wikipedia.org/wiki/Covenant_%28law%29) which will run with the coin and forever constrain the use of it and its descendants degrading and its fungibility.

(Actually accomplishing this requires a bit of a hack: a SCIP program can't have its own validation key built into it, as that would be circular. But that is no fundamental limit here: the script can go read it out of the scriptpubkey of the input transaction that is being spent we can trust that its the right one because if it isn't transaction will be invalid even though the proof accepted).

Any attempt to think of why someone might want to do this leaves me screaming in horror— Which you should expect as this is the robotic equivalent of a home owners association.

(E.g.  In a fit of tonal (https://en.bitcoin.it/wiki/Tonal_Bitcoin) advocacy, Luke-Jr could start stamping coins with a covenant that only allows or makes their user pay higher txn fees unless the txout amounts were round tonal numbers.)

A more serious point is that this kind of tool makes it rather difficult to intentionally exclude functionality from script— any data under the signature in a cryptographically strong way, even indirectly like all the data in prior transactions, its subject to testing by the script.

What horrifying ways can you imagine covenants being used? :P

Rick-roll bucks.

Bootstrapping this process works ok? The initial scriptpubkey of the input transaction didn't have this validation key, so the SCIP program should say that a standard input there is ok too?

If I understand correctly, the user who receives the coin is the one who decides to add the extra THIS_VALIDATION_KEY rule that will be enforced forever from this point forward? So this user is restricting himself to receive a coin that can only be spent in the future if the extra validation rule holds? I suppose that this would make the coin less valuable in comparison to a regular coin that doesn't have this restriction, so why would the user decide to add this extra validation rule to the coin that he receives in the first place? For example the most extreme validation rule would be that this coin is destroyed and cannot be spent at all, and here obviously the user would prefer to receive a fully-functional coin instead of this destroyed coin.

Yep. Not a problem.  The content of a scriptpubkey is not evaluated when its created, only when it's consumed.  Assuming you have no covenants in effect when you create a transaction you can put whatever you want into the scriptpubkey.   Later when someone goes to spend it, they'll have to cope with whatever covenants you added (which can then look back from their position in the consuming transaction and find themselves in the output of the prior transaction).

The world is a weird and complicated place. Covenants on real property are common, at least in some places, it's not always easy to predict what people would do. Sometimes they do things which are simply crazy.

If you really want you can cook up some actual applications: I'd like to pay your company contingent on performing something but have the ability to take the payment back if you fail.  Likewise, your employees want to receive those funds right away (as they don't trust their bosses) but understand that the funds could be taken back if there is a default.  A temporary (but still heritable) covenant could allow the coins to circulate but preserve the clawback. Perhaps even local vendors would accept these conditional coins— preferring to receive the business and tolerating the risk.

Generally I don't think the idea of covenants is a good one, quite the opposite.  I was hoping to see people suggest some more awful ways which people might use this ability because of insanity, greed, or simply because they are misguided.

This is amazing in a terrible way. Some evil ideas:

- Coins with a self destruct counter. Each transaction decreases the counter, once it reaches zero you can only spend it as fees.
- Freicoin embedded inside bitcoin, instead of being a separate currency.
- Snowballing txouts: The tainted inputs verify that there's a tainted output stricktly bigger than all of them. So to spend 1BTC of tainted value you must turn make a 1.0001 output of tainted value. And so on until all the available bitcoins are locked into one big txout.
- Spamcoins: To spend it you must make a one satoshi output in your transaction. Bloat that UTXO!

Obviously the risk is limited, everyone receiving these coins would know about the fact that there are rules governing them, and would need to know the rules to be certain that they're actually spendable at all. This could make them actually useful in certain cases (especially if the covenant eventually expires). Some less evil ideas:

- Trustfund coin: Instead of a ton of txouts, each with a different locktime, you get a coin that lets you unlock some of the value back to regular coins as a function of height. It also embeds the extended public key for the locked part, so you can't safely transfer it to someone else, as you'll always have the ability to spend it.
- Antitheft coin: Variant of the above, you can only send < 1BTC of unlocked value per hour (or some other amount), or you can send all of the value to a prespecified address at any time. Limits how much of your money can be stolen as long as you retain a copy of your private keys.

Ohhh. I like the katamari (snowballing) coin and the spamcoin.

Lemme power-up the spamcoin some and externalize its cost:

- Smashcoin:  Any spend of a coin with this covenant must retain the covenant and provide proof of an attack on an alternative cryptocurrency. (e.g. SPV proof of bloating some other cryptocoin's UTXO, or mining multiple blocks at the same height (with some committed data))

(In particular, if it required that there be no payee at all beyond the covenant for one of its outputs. ... and it becomes a self-administering bounty for attacking something else 0_o spooky. Fortunately most attacks are not cryptographically provable)

I think both Trustfund and Antitheft need access to the blockchain headers (to read the height, and to read the time in a secure manner). One interesting thing is that no amount of following back the inputs can actually get you a connection to the chain headers. You could just provide them as additional inputs and it could have headers-only (SPVish) security. To more strongly bind in the headers you'd want to add a "CHECKPOINT" field to transactions: in that field you put a block header hash and a restriction for how far back in the chain that block is allowed to be. This data would be included in signatures (thus available to the SCIP-script), and if the value in it isn't in the chain the transaction is invalid.  (SCIP verifies your execution was faithful, but you could be lying in your inputs, so care is required that you don't overly trust any of them, e.g. don't just ask them for the time)

I was thinking a potentially useful application of this could be security deposits, where an output can be spent before a specified block height only if cryptographic proof of fraud is presented, and in this case, it can only be spent to a miner sacrifice output (anyone can spend 100 blocks after the specified block height).  After the specified block height, the output can be spent like normal by the depositor.

Indeed, redeeming a fraud proof is a canonical use of a SCIP-script (esp since it can keep the fraud proof itself private, preventing miners from taking it, which no simple on-chain fraud proof support can do).  Though this doesn't require a covenant (a script that encumbers future coins), just a script.

Even if you want to ensure the deposit goes to a (fair) miner sacrifice?  I'm thinking of this for the case of sybil attack prevention in p2p networks where the deposit isn't placed with anyone in particular.  In this case, if the deposit is claimable by the first person to present the fraud proof, then it will simply be claimed by the attacker, as he will have the advantage of surprise.

You split up the amounts: a portion goes to the finder to encourage people to look for fraud, and the rest of the deposit goes to a txout that can't be spent before a given block height far off in the future.

Just make sure the amount that goes to the finder is low enough that there is no incentive to commit fraud to collect the fidelity deposit.

Reminder: this thread is supposed to be about a _bad_ idea.

- Identicoin covenant: some kinds of officially issued IDs have a smart chip in them that can response to signature challenges and also can return a signed copy of your name and other info. Any Identicoin scriptpubkey output is constrained to have the covenant, a regular script, and an extra PUSH with the real name, DOB, etc. of the party being paid, as proven by a signature of the masked transaction hash by the users' ID card provided in the SCIP private input.

- Adultcoin covenant: Like the above, but DOB and blockchain headers constrains any future recipient to be >18.  (but without the other properties: people wouldn't want their names on their "adult" purchases, after all)

- decaying-crypto covenant: Outputs are required to be of the following basic form:

HASH160 <n> SHIFT-RIGHT <target> LESSTHAN
IF
    TRUE
ELSE
    (other conditions)
    (require all txout scriptPubKeys to follow this same form, but with n=n+1)
ENDIF

Stealing the coins is possible by solving the PoW, and is made twice as easy every time the coins are spent.

- piss-off-gmaxwell covenant: You must provide a message with one or more of the following words: "asshole", "fuck-off", or "distributed hash table" signed by Gregory Maxwell's public key. Uniqueness is enforced by a n-of-m digest timestamping oracle.

- bloat covenant: Only spendable if n prior blocks are over 1MB in size. Also, anti-bloat.

- it-feels-good-to-pretend-to-be-regular covenant: Spending block is required to have a timestamp exactly 600 seconds ahead of previous block.

- delorean covenant: Only spendable if the timestamp on the spending block is prior to the timestamp on the block the txout was created in.

- attack-all-the-pools covenant: Only spendable if difficulty less than a certain value. Also see "I am an ASIC manufacturer" covenant: only spendable if difficulty greater. (can increase on every transaction)

- there-can-be-only-one covenant: Requires that the distinct scriptPubKeys / transactions ratio in the last n blocks be less than a given ratio. Further more, decrease that ratio every time the coins are spent.

- panopticon covenant: Requires n prior blocks had only transactions following the identicoin covenant.

- fidelity-bonded distributed-hash-table covenant: To spend, the prior block is scanned for "request" transactions with scriptPubKey's of the form "RETURN <magic> <digest>" and for every digest the corresponding message must be included in the scriptSig.

- game-of-life covenant: Include a n*m bit buffer on scriptSig and scriptPubKey, prove that the transition rules of Conways Game of Life were applied. Note that because the Conways Game of Life is turing complete you can embed a tape machine and thus a PoW crypto-currency in the bit buffer given a sufficiently large blocksize.

- nomic (http://en.wikipedia.org/wiki/Nomic) covenant: Given a txout included in block n, to spend it in block m the blocks n...m are scanned for "nomic" transactions containing scriptPubKeys of the form "RETURN <magic> <opcodes>", and those sub-scripts are appended to the master script to form the next scriptPubKey that all txouts must adhere too.

Very creative :)

I was going to say that you can't do this one:  The SCIP-script can't have a completely free form input like "what time was the last block" because you must know all the inputs when you run the prover and the prover takes time and so does confirmation. But you actually could, with the right opcodes which would effectively be a transaction which requires the miner to lie about their time. In general ones which are the function of the _last_ blocks directly become tricky, because if you want the SCIP to actually process the block you have to have it.  (Easier if you have script operations to test these things and just push their test ID and result onto the stack, so you can compute the proof in advance assuming those things to be true).

And the rest? oyyy..

I am imagining a dark future where for laughs people had encumber a bunch of coins and then treated them as destroyed and largely forgotten.  Then a long while later the coin's value increases tremendously and that 1 BTC output where you have to advance the game of life to use the coins... "well, the game of life isn't that bad".  Adds new meaning to the gaudiness of the nouveau riche and the idea of "tainted" coins. :P

Without pretending that I fully comprehend all of this, I think this means that anyone with the ability to write such a covenant into a transaction manually could create all sorts of rules about how the coin (or even all coins from the originating coinbase?) can be used in the future? Could you write fully algorithmic rules? With recursive properties? Genetic algorithms? Cure my naivety, or at least try!

Well that's the thing really: you don't actually need SCIP to do covenants - SCIP just tends to make them a lot more efficient and easy. For instance consider this proposal of mine: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02602.html A overly complex joke yes, but the basic idea is a covenant. In fact OP_MAST gets you pretty close because of how it lets you reference whole fragments of code so easily by digest.

In my mind the biggest difference is that it makes them hard to _forbid_, if SCIP-scripts just were implemented in the most obvious way (add a OP_CHECKSCIP) we would have likely gotten the ability to create covenants without even realizing or intending it because the technology is just so _generally_ powerful.  If I make it sound like a negative thing it's because covenants can screw up fungibility (as our whimsical examples show), so while they can be useful and important to some protocols, we might want to take care in how we enable them. (Or at least consciously decide that they're a net win! ... and yes, sure, I wouldn't turn down SCIP in order to avoid covenants)

The work that ultimately inspires this discussion (SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge (http://www.scipr-lab.org/) by Eli Ben-Sasson et al.) lets you convert arbitrary C programs into compact proofs which show that the program in question was faithfully executed and accepted a set of public and private inputs. In the future we could potentially use this system (or its descendants) as an alternative to Bitcoin script and the checksig operator and do a lot of neat things with it.   There are engineering challenges which will need to be overcome to make it a practical reality— their current implementation needs— say— two CPU hours to "sign" a transaction for a fairly modest set of program rules. But the validation is fast, and thats the biggest deployment hurdle. In the mean time, its a fun to think about while the tech matures. I posted a more serious application for it in another thread (https://bitcointalk.org/index.php?topic=277389.0).

The idea that cryptography can be applied like this is insanely brilliant, and so these pre-emptive thought experiments are vital. To think that the power of cryptographic/computational discoveries will not cease to improve cryptocurrency implementation is... I cannot find a superlative, Nakamotish? I will attempt to understand the posted links! A whole new generation should be encouraged to do the same, the whole cryptocurrency concept is so much more important than I even thought possible

Visa/Mastercard covenant: every transaction moving the coins must be also signed by a public key controlled by visa or mastercard, thus restoring their financial censorship privileges.

Contact covenant: You can only spend the coin after proving that you've discovered a messsage probably created by extraterrestrial intelligence (according to whatever language complexity rules) when running a SETI@home work unit.

Curecoin covenant: You can only spend the coin after proving that you've solved a folding@home work unit.

Which brings me to the off-topic...Why there's so many people in the altchain subforum looking for proof of work schemes that make ASICs harder to build and no one seems to be looking for a way to use SCIP to substitute SHA256 and make miners help cure cancer while they secure the network? Maybe with proof stake to vote on the elegible work units or something, I don't know.
I remember saying to newbies reusing the proof of work for useful stuff was probably impossible, but I didn't knew about SCIP then...
That would remove the mining wastefulness argument against proof of work once and for all.

I failed to understand (for example I have no idea why you said "lie about their time"), could you please try to explain the above in a way that might be more clear?

One thing that I can see is that the Bitcoin script language could be extended to include a new opcode (unrelated to SCIP) that puts on the stack the timestamp of the block in which this transaction resides, and similarly an opcode that puts on the stack the timestamp of the previous block (relative to the block in which this transaction resides), and then bind the SCIP program to use these two public inputs, and the SCIP program would be completely trivial i.e. it would just check the difference between its two inputs. So except for enforcing the covenant, SCIP isn't needed here, because the regular Bitcoin script can directly check the condition on the difference between the two timestamp values.

Another thing that I can see is that the specified SCIP program (verification key) will have the hash of the genesis block (or a more recent checkpoint block hash) hardcoded into it, and will receive non-public input which is the all the next blocks, and the SCIP program checks that the entire hash chain is valid, and fetches the timestamp value from the last block that it hashed. But this way you can only fetch the timestamp of the previous block, not the current block?

Hard to forbid or impossible to forbid? Instead of OP_CHECKSCIP, can there be a way to incorporate SCIP into Bitcoin scripts in a way that disallows covenants?

Hard/ugly not impossible.  Don't allow a transaction with a SCIP checksig to pay to a SCIP scriptpubkey, and don't fix the fact that there is no sighash flag that lets you built a transaction that can only ever be spent by one other.  (otherwise a covenant could require you to form every output as two-stage "you must pay to a future transaction which has the required SCIP code").

I keep thinking that it's possible to pass the output data being signed through some kind of malleable encryption so that the signer, and only the signer, can substitute the ouputs... but every system I've come up with is either insecure (third parties can replace the outputs) or can still make a covenant (as they only make a single replacement possible, and a covenant could require you to construct two candidate outputs and then make sure both meet the covenant criteria).

I don't currently think we should forbid covenants, though perpetual ones are utterly moronic. Ones that last one or two transactions sound useful to me... and the considerations required to forbid them are too ugly.

Yes, everything that doesn't require zero-knowledge could be instead done with a sufficiently powerful script.  SCIP avoids the complexity of implementing every possible interface you might want and then executing in those things in the network.

WRT lie about the time:   Say you do something (e.g. a OP to provide them as public inputs, or better to compare them to static values and fail the transaction, and provide the static values as public inputs) to make the times visible to the SCIP so the SCIP can test them. The SCIP validation isn't execution, it's verification of a witness, and you cannot change the inputs to ones other than the prover used. While you might happen to pick a convenient time that wouldn't be a lie, if the transaction ever gets mined it likely will be due to a lie.  (and, practically, no one is going to accept dynamic data as TX validation inputs, no one wants to ever run validation more than once per network block per transaction).

Thats not a great way to do that, because it doesn't bind to a specific chain. For example, say it started at the genesis, I could just mine a diff 1 fork which met whatever criteria you wanted.  If you want to do something to bind a chain I suggest an opcode which you use to push a header hash and max_distance, and iff its valid in the current chain the value gets combined with the data being signed. Otherwise, the transaction fails.  This way the SCIP-script can know that a specific block (and all blocks before it) is in the chain. I don't see any way to get tests on _this_ block except by opcodes that push constrains on this block.

Time limited ones seem useful to me too.  For example, secondary markets for bets - outputs whose ownership is ambiguous before a specified time (dependent upon an oracle releasing secret before this time) could be transferred on the blockchain by the individuals involved without requiring signatures from the others, but while preserving their potential claim to the output.

* "Pool's closed" covenant, can only be spent when specific detectable pools are below a certain density in the recent chain, or when a decenteralized pool like P2pool is above it.

Backdoor covenant - Normally like a regular coin, but an arbitary payload can be attached to it at any point in time through a transaction by the creator of the covenant. When spending it, there's a check for the lastest signed payload for it in the blockchain, and that is then executed.

Viral Proof-of-Work-Verified Payload Backdoor Covenant - Like the above, but here you are required to attach the covenant to another coin when spending this one, and *anybody* can attach a payload to it through proof-of-work, where the payload with the computationally hardest proof-of-work generated so far is the one who is executed when you spend the coin. The proof-of-work is of course individual for each instance of the VPoWVPBC.

Theif's downfall covenant: the coins sitting at an address must find an instance of themselves trying to be spent at least X blocks prior before they are actually sent.  Trying to spend the coins again to a different address will reset this process and the countdown begins again.  The coins may be instantly sent to a failsafe address (likely a brainwallet or cold storage) in the event of trespass. 

If you are a living human being who becomes aware of an unauthorized spend attempt, you will actually have time to stop it.  This may make your coins practically immune to theft.  The equivalent of saying "You may come into my house, you may steal my private keys. You may enter my vault, you may attempt to steal my coin.  But if you do you must suffer the mandatory waiting period, and I will know about it, and I can instantly redirect the transaction to a destination I have already approved of.

a.k.a. the personal chargeback covenant  :D

I am not tempted to call it such, because bitcoin should never be associated with the word "chargeback."  Coded correctly, the coins wouldn't leave your wallet until your specified delay has passed, only then they would become irreversible. There would be no way to stop the transaction after this, so the key is setting a delay that affords you the convenience and security balance that you desire.  

You might ask: Why not just keep them in a brainwallet or a paper wallet to begin with?  Those are great too but just slightly inconvenient.  This is the only method I know of so far that 1) Tells you when your coins are being stolen and 2) gives you time to do something about it.

The ultimate test of this would be to put some BTC at a timelock address, tell everyone in the world the private key, and see if anyone can indeed manage to extract it before you can.

Bah, just logical semantics! No, I agree that it could be implemented that way. But I believe that it wouldn't prevent it being used to reclaim coins that were made in a fair trade, although we are of course in "amusingly bad idea" territory after all. Still, it feels tempting to see whether it might be possible to imagine a practical implementation that doesn't throw the "trustless finality" concept away altogether...

I recently sold one of my Avalons and ended up doing the whole trade based on trust (well, buyer trusted me, he sent the whole sum of coins, then I delivered the miner  :)) Thieves covenant would have a useful function in this trade, like a trustless escrow. But of course, he could have received his miner and then reclaimed the coins, maybe we solve this one with the telekinetic revocation for exchange of physical items? :P (kind of has the same problems really...) It seems that one party always has to assume some risk, whatever transactional logic or stratification of intermediaries is used (i.e. an escrow agent could equally sacrifice their reputation for the coin, too). With human beings come self interest and unreliable intentions, we're naturally limited in our social dependencies I believe. 


As I say, it works great in one set of circumstances: when you're playing by the rules and being Mr. Nice Guy. People change; you might have all sorts of experiences that alter your outlook on behaving well, that negatively impact your earning ability or your personal wealth. And these things happen to some people early on in life, so they can often be inclined to lie, cheat and steal; people behave the way that works out for them based on what they know (whenever the experience of "knowing" takes place in the sequence of living). Mechanisms that work around these proclivities are to be cherished and protected for now, even if they're a pain in the ass in practice. The irritation of ferrying transaction signatures from a cold storage wallet, or the worry of forgetting the brain wallet seed you finally burned the paper copy of... it's the price you pay for such a useful capability. And as has been discussed before, even those two examples are far from infallible (I'm sure that, however unlikely, one day someone will start up a fresh wallet or use a brain wallet seed that just so happens to correspond to a private key that's already in use. Given enough days of random chance, that is...)

This is all really quite in the spirit of this thread.  ... Delicious flirtations with ideas on the boundary of really useful and horrible train-wreaks.

As long as the charge-back covenant doesn't run with the coin forever it would become safe to accept these coins once it was free of the covenant.

> It seems that one party always has to assume some risk

If you discount the cost of wasting your time and tinkering with technology, true zero risk exchanges of some digital "assets" are at least theoretically possible. E.g. I can easily buy a SHA256 pre-image from you today using Bitcoin. The math tells us this capability should, in fact, be fully general... and that any digital good who's acceptance you can codify into a program can be sold risklessly with Bitcoin (using the contingent payment protocol (https://en.bitcoin.it/wiki/User:Gmaxwell/why_hash_locked) I invented) once the right tools are made.

Clunky pieces of metal, indeed, no such luck.

Futures-contract coin, call variety.
If spent before X time, can only be spent in transaction where it is exchanged with a single colored coin representing some particular quantity of a commodity.

Futures-contract coin, put variety.
Same as above but is a colored coin representing quantity of commodity exchangeable before X time only for single bitcoin of predetermined amount.

Tax covenant coin: Every time it is spent, one satoshi must be sent to address of bastard who imposed covenant, and largest txout of transaction must carry covenant forward.  Can also use to support charity or devs, I suppose.

All your key are belong to us coin:  Can only be spent with a proof-of-work hash -- some subsequence of which must match subsequence of private key.  Rude way to spank foolish people use same address more than once.

Lotto coin:  Each time changes hands, 1% of tx value sent to special address.  one time in thousands, gives spender key to that address and starts a new one.

Returning coin:  Each time spent, is small chance of it return to wallet of someone who spent it six tx previously.  (picture accountant trying figure out. )

Stable-value coin:  Txout of exactly equal value carrying same covenant must exist in any transaction where spent.  No divisibility or aggregation.

Amusing.

Escrow is a fascinating problem to tackle, but Thief's Downfall covenant the way I envision it probably wouldn't/couldn't be used for escrow.  Greg is absolutely right in that we walk a fine line between introducing entirely novel/useful features with SCIP while running the risk of gumming up the bitcoins into entirely undesirable and unusable bits of information.

If used responsibly, even the act of sending coins into the Thief's Downfall Covenant would require knowing the private key of the current address and the private key of the address the coins are going into.  Think of it as a kind of failsafe to make sure that someone doesn't unknowingly accept coins that are bound by all sorts of rules they don't want to play by.  A malicious buyer could not pay you with these slow coins unless he knew your private key.  And even if he did it would be easy to identify that these kinds of rules have been set up.

I hope it doesn't just come across as semantics.  I couldn't use the TD coins as an escrow because initiating the transaction doesn't send the coins out to anyone (they wouldn't accept my word as a form of payment).  I couldn't use the TD for a chargeback because once the transaction is finalized there would be no way to get the coins back, and the new owner would no longer be subject to their mandatory waiting period.  All this is doing is allowing some folks define a window of time to make choices.  Think of it like putting a much longer fuse on your stick of dynamite.  Currently the fuse is instantaneous.  Yikes.

Thus the life cycle of the coins looks like: (My normal bitcoins --> My Slow Bitcoins --> Your Normal Bitcoins)

I had an idea that I thought would work to prevent covenants.

There exist chameleon hash functions... these are hash functions which are parametrized by a public key and are cryptographically strong collision resistant hashes to anyone who doesn't know the secret corresponding to the public key. ... but someone who knows the secret can trivially compute collisions.

My thought was that if you had the hash over the transaction outputs pass through a chameleon hash then you could tell the covenant you were using one set of outputs, but then substitute another set after obtaining your signature. But it would still be secure because no one else could make this substitution.

Unfortunately it seems like it wouldn't work: The covenant could force you to use a nothing up my sleeve number as the public key for the hash, e.g. like the txid of the coin you are spending.

Just add a rule to require all SCIP inputs must be sent to standard pubkey hash outputs, so covenant is not possible. However, this will eliminate all "good use" of covenant.

I wonder if covenants were what Satoshi was trying to achieve with the strange signature procedure, OP_CODE_SEPARATOR and concatenation of scripts.

You could provide the hash preimages in the scriptSig to the covenant.