Topic: CoinCovenants using SCIP signatures, an amusingly bad idea. (Read 15034 times)

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

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

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 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.

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)

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.

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 I invented) once the right tools are made.

Clunky pieces of metal, indeed, no such luck.

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? (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...)

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.

a.k.a. the personal chargeback covenant 

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.

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.

* "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.

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.

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.

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?

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?

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.

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

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 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.