Proposed extensions to the transaction protocol: Receiver scripts, OP_TIME, more

[jimrandomh]

So, the current Bitcoin protocol allows senders to attach a (limited, not Turing-complete) script to the coins they sent - see https://en.bitcoin.it/wiki/Script. This means that, given client support, I could take my coins and send them in such a way that several keys were required to unlock them; I could then keep these keys on separate computers, for security. Or perhaps I'm in an organization that requires a majority of the board of directors, so I require a minimum number of distinct signatures, or something complicated like that. The current Bitcoin client doesn't support these things, but the protocol does, so these features can be introduced unobtrusively. This scripting system is pretty cool, and, with a little more work and a few extensions, I think it could enable some pretty amazing security features. Since using online wallet services to add features has worked out badly so far, building security features onto the blockchain seems like the right strategy.

But suppose you want to publish a tipjar address, and require two keys to unlock any bitcoins sent to that. Unfortunately, this won't work, because senders aren't going to attach a script to the coins they send; and if you wanted to instruct senders to attach a script, there'd be no easy way to do it, because the Bitcoin address format doesn't support that sort of thing. I would have to receive the coins to a regular single-key address, then forward them along to a two-key address, leaving a window between receipt and forwarding during which someone who had stolen the single key could steal my coins.

Now suppose that instead of publishing an address that's the hash of my public key, I could instead publish an address that's the hash of an arbitrary script. Then, if I want to spend the coins along, I make a transaction containing both the script - which turns out to be a function that says I need some combination of signatures - and also the signatures that make the script return true. This seems like the right way to handle multi-key addresses.

This also seems like the right way to handle time-locked coins. Rather than use the nLockTime field, introduce two new opcodes to push the block number and the block date/time in which the transaction appears. Then, someone can set up spending conditions like "either these three parties all agree, OR two parties agree and it's been a month, OR one party agrees and it's been a year" - and designing and supporting these complicated conditions wouldn't require any support from the official Bitcoin client, they could set it up themselves and have it be completely transparent to everyone else.

The last remaining problem with split keys is how to handle the communication between the devices that hold the keys. This can be awkward - if you have one part of the key on your computer, and one part on your phone, they may be connected through different networks and both behind firewalls or NAT gateways. I think that the right way to handle this problem is to use the blockchain - first have one of the devices publish a dummy transaction that doesn't move coins around but which contains the transaction details and its signature, then have the other device detect the dummy transaction in the blockchain, and compose a real transaction using that signature plus its own.

There is one more feature which I'd like the blockchain to support, but which I'm not sure of the best way to implement. Suppose I have a big, long-term savings account, and I'm worried that someone is going to steal all my keys, including the master key in my safety deposit box. However, I still want to be able to stop them from spending my coins if that happens. So I put my coins in a special address, which is set up so that when someone initiates a spend, that spend is delayed 72 hours. During that time, I can use my private key to publish a "cancel" transaction, which causes the coins to become frozen until a transaction is published that's signed by both my key and by a third-party arbitrator's key. This would require receiver scripts, date/time opcodes, and also new opcodes for some sort of cross-transaction communication mechanism. Any ideas for what that mechanism should look like?

[1714904738]

1714904738

[1714904738]

1714904738

[1714904738]

1714904738

[1714904738]

1714904738

[casascius]

I have proposed exactly the same thing, letting a bitcoin address be the hash of an arbitrary script

https://bitcointalk.org/index.php?topic=45211.0

I imagine proposals speak louder when they are in the form of tested patches / pull requests, the devs have more competing priorities than to write and test it from scratch.

[jimrandomh]

That idea is similar, but in your proposal only boolean expressions on keys are allowed, whereas I propose allowing the full scripting system, and adding a few more opcodes to the scripting system at the same time. Both proposals achieve the important goal of enabling split keys, but this version also enables fancy tricks with time-locking that could not be achieved otherwise.

I think the transaction protocol needs to be changed. Let's make sure it can change exactly once, and get every desirable feature in one go.

[maaku]

Why make the address a hash of the script? Unless the scripting system allowed Lisp-like code-as-data interpretation of scriptSig (it doesn't, but I'm working on a blockchain that does), you'd have to have some sort of system for resolving hashes to actual scripts. There I see two approaches: the client looks at all existing transactions to find a script which matches (so you'd have to publish a 'model' transaction first--this would serve a different role than current bitcoin addresses), or some sort of centralized or federated resolving service (a DHT?). I'd rather just distribute the scriptPubKey itself, base-58 encoded with a checksum and a different prefix than the current address format. But I can see the merits of both.

I approve of adding BLOCKTIME and UNIXTIME opcodes (which is actually a separate issue from nLockTime).

For your dummy transaction, I think that's the wrong approach. This is a “problem” that should be solved outside of the blockchain. I put “problem” in quotes because the only time this would be useful is when you have two devices connected to the Internet (because they are both reading the blockchain and sending transactions). In which case.. why not have them talk to each other directly? This shouldn't be solved at the blockchain level.

For your chargeback suggestion, you could implement that by putting an optional lock time and revocation script on each output. However I would never implement this because undoing a transaction mould have all sorts of bad effects. If the transaction included fees, for example, those would already have been paid to the miner who might have spent them or transfered them. Then what do you do?

[casascius]

Why make the address a hash of the script? Unless the scripting system allowed Lisp-like code-as-data interpretation of scriptSig (it doesn't, but I'm working on a blockchain that does), you'd have to have some sort of system for resolving hashes to actual scripts. There I see two approaches: the client looks at all existing transactions to find a script which matches (so you'd have to publish a 'model' transaction first--this would serve a different role than current bitcoin addresses), or some sort of centralized or federated resolving service (a DHT?). I'd rather just distribute the scriptPubKey itself, base-58 encoded with a checksum and a different prefix than the current address format. But I can see the merits of both.

The most compelling reason to make the address a hash of the script is so that people can send to normal-looking Bitcoin addresses without having to specify some monstrous address to express the logic.  (Requiring a new form of bitcoin address would make it a non-starter anyway - everyone would have to have multiple addresses to make sure they can be paid by everyone, and new users would be put off by why people have to have a short and a ridiculously long address.  And every website that allows withdrawals of Bitcoins would have to be modified to accept new addresses)

For the suggestion I had made (OP_CHECKSIGEX), that's pretty much precisely what I had in mind.  It would be, rename OP_CHECKSIG to OP_CHECKSIGEX (meaning "check signature expression"), and change its implementation such that the blob of bytes could contain some sort of coded logic, and for backward compatibility, a blob of bytes consisting of only a pubkey (as transactions are now) would be treated as a single operation that verifies a signature.  There is no need to scan the blockchains for "model" scripts.

The OP's suggestion is pretty much identical, except that he would like to see more operations available rather than the simple boolean ones I had proposed.

[theymos]

Scripts must be stateless and time-independent unless these transactions are required to mature in the same way as generation transactions. Otherwise the transactions will cause a lot of trouble after reorgs. This has been discussed many times.

[maaku]

theymos, can you provide a reference for that? It's not an intuitive result.

EDIT: to be clear, once accepted into the blockchain BLOCKTIME or UNIXTIME would return the block number/timestamp of the accepting block. I thought that would be obvious, but just noticed it hasn't been explicitly said by anyone. Does that fix the issue you are referring to?

[hashcoin]

The reason for nLockTime instead of OP_TIME is that a transaction should only every be able to transition from INVALID to VALID while going forward in time; never VALID to INVALID.  The reason is in the event of a reorg/split, transactions that were valid before should remain valid, so they can easily just be included in the new chain.

Imagine if there is a split that doesn't include some transaction that went invalid before the split occurred.  That TX, and all other TX that depend on it, now can't get into the new chain.

[jimrandomh]

We could guarantee that a transaction stays valid even if it's moved to a later block; how about instead of OP_BLOCKTIME and OP_UNIXTIME, make OP_BLOCKTIME_CHECK and OP_UNIXTIME_CHECK, fusing pushing the time and failing if it's too early together? They could still be skipped over by conditionals, so you can do the complicated realistic stuff, but you couldn't write a script that ever transitioned from valid to invalid with those opcodes.

But I actually think keeping the transaction associated with its block, and determining its validity that way, is better. You could make a receiving address with rules like "may be claimed by A within 72 hours; goes to B otherwise".

[theymos]

theymos, can you provide a reference for that? It's not an intuitive result.

We can't safely do OP_BLOCKNUMBER.  In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block.  The OP_BLOCKNUMBER transaction and all its dependants would become invalid.  This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.

[maaku]

Cool points for quoting Satoshi, but I'm afraid that line of reasoning doesn't hold up. During the reorg the client needs to revalidate transactions to prevent a double-spend, and in the case of a double-spend those transactions will go VALID -> INVALID in the reorg (if not, this is an exploitable hole; PM me if you run a large mining pool ).

Yes, just as with the double-spend case it is possible that there might be transactions dependent on the now-failing BLOCKNUMBER/UNIXTIME transaction that don't get included either. However there are three points to be made: 1) this is no different than the analogous double-spend situation; 2) it would only happen if the 2nd and following spenders do not each wait the usual number of confirmations (making “tough luck” appropriate IMHO); and 3) it's not exploitable.

[theymos]

this is no different than the analogous double-spend situation; 2) it would only happen if the 2nd and following spenders do not each wait the usual number of confirmations (making “tough luck” appropriate IMHO); and 3) it's not exploitable.

This is different because it could happen accidentally due to network segmentation. The maturation time required on generations and OP_TIME (if it was implemented) ensures that segmentations are OK as long as they don't last longer than 100 blocks. Without maturation times, segmentations couldn't last longer than 6 blocks without causing massive accidental damage.

[maaku]

Again, that isn't any different than with double-spends. ByteCoin posted a double-spend attack exploiting segmentation just a few posts below Satoshi's in the thread you pulled that quote from. From a technical perspective the two cases are identical. In either case it could happen accidentally or maliciously that transactions are invalidated due to a double-spend or timeout. But I reiterate my original point #3: it's not exploitable, short of a 51% attack (a network segmentation attack being a funny sort of 51% attack).

Keep in mind we are talking about the stars aligning under already extraordinary, unpredictable, and exceedingly unlikely circumstances. I would like to see the chances of this calculated and compared to, say, being hit by a deorbiting satellite, or being struck by lightning twice.

Unless it's exploitable, in which case show me the protocol.