Topic: Designing distributed contracts (Read 9594 times)

https://bitcointalksearch.org/topic/paidbounty-bip-0011-48215

Multi-sig is being discussed here. Multi-sig is a primitive operation that would enable quite a few of the contracts described here and on the wiki.

AFAIK the only contract being implemented currently is multi-signing.

bzzz... any results??

Two CHECKSIGs and two sigs in scriptSig?


This sounds like security-through-obscurity approach. If we're talking about a serious sum (which quite fits in case with inheritance) it quite makes sense to find nodes close to what "grandson" uses and infiltrate the network to stop propagation of his txn and distribute your txn faster.

As I understand normally client connects to a limited number of random nodes. Attacker might instead choose to connect to nodes of prominent miners directly, so he will be able to deliver his txn to miners faster and have higher chances of his txn being included into a block.

It would also make sense to flood network with transactions to slow propagation.



Yes, that was the plan.



ECDSA, as used by bitcoin protocol, also relies both on high-quality crypto RNGs and hashing, so it, in theory, suffers from same preimage and RNG-related attacks. So I don't see how hash-based approach is less secure. If anything, it is more secure because it does not rely on ECDSA's number-theoretic mumbo-jumbo.

Can claims on distributed contracts be sold to third parties?

Suppose there is a ClearCoin-style Escrow contract. Seller sets an escrow expiration date (if he really doesn't trust the buyer, he sets a date very far off in the future). Buyer puts coins in escrowed account. Buyer has limited control over escrowed coins. He can a) release coins to the seller immediately, or b) order the coins returned to another account after the escrow expiration date expires.

If the buyer picks b), can he trade his escrowed coins to a third party? Ideally, could escrowed coins be traded more than once?

Trades would be helpful because:
a) they would make escrow transactions attractive to a wider variety of buyers (many people can risk a partial loss of coins, but can't risk having large sums tied up for a long time.)
b) if the escrow expiration dates were standardized (e.g. Jan 1st and June 1st), failed escrow transactions would create a useful commodity. Escrowed coins would sell at a discount over regular coins. Accordingly, anyone who has promised to pay someone bitcoins in the future would rather back their promises with escrowed coins than with regular bitcoins.

I would love it if escrowed coin balances could be integrated into special versions of the bitcoin client. Standardization of escrow termination dates would limit the new types of balances to a few additional kinds of coins (e.g. Jan 1st this year, June 1st this year, Jan 1st next year, Jun 1st next year). Contract standardization is pretty much essential for bitcoin contracts to be tradeable.

The oracle transaction can be combined with another signature so only the grandson can spend the coins in combination with the oracle. But transactions propagate pretty fast. I don't think it's worth worrying about a race condition much.

For the random number idea, I think to be secure the random number would have to be very large (eg, the size of a hash). Otherwise you can calculate a rainbow table for a huge range of numbers. I thought about hashing the output of the oracle when writing the article, but doing it in a way that isn't susceptible to trivial brute forcing seemed hard.

I don't quite get how "oracle" example is secure. This part:


What prevents malicious party from crafting similar transaction with his output?

E.g. it monitors broadcast transactions and when he sees son's transaction involving oracle sig it will copy it and replace output with his own and broadcast it too. Then it is a race condition. As you said, SIGHASH_NONE means that output is not signed so this copycat transaction is possible, right?

Or oracle itself can construct this transaction itself and just wait for son's input to be broadcast.

BTW I have an idea of how to implement escrow/oracle with somewhat different properties: to make a contract transaction you need to obtain a token (hash) from escrow/oracle service, but service does not need to work with each individual transaction. It is based on hashes, security is derived from complexity of first preimage attack.

Idea is simple: oracle generate an unique random number R associated with event E and announces its hash: hash256(R). Interested parties incorporate hash256(R) in scripts of their transaction. Then if event E happens oracle announces original random number R and it will unlock spending scripts.

In a simplest case:


Use case can be similar to a legacy case, but oracle is required to associate an unique number R with event of death of "John Smith" before transaction is made.

It can also be used for making bets on public events, trading binary options etc.

For example, person A agrees to pay 100 BTC to person B in case exchange rate on a certain exchange is higher than 17.5 on a certain date.

An exchange itself or a third-party service will create a an unique random number RL_x_y for each event EL_x_y which means that exchange rate will be lower than x on date y, and numbers RH_x_y for each event EH_x_y which means that exchange rate is higher than x on date y.

Now A should obtain hash256(RH_x_y) and hash256(RL_x_y) from service and create a transaction for 100 BTC with scriptPubKey like this:


Now if exchange rate is higher service will publish RH_x_y and then B will create txn with scriptSig:


otherwise A will create similar txn which unlocks money to him.

An advantage comparing to signature-based escrows is that service only needs to publish a hash and a random number, but it does not need to process each transaction individually. Also, hash and number are rather small so it is easy to just copy them into GUI form field, so there is no need for software integration between contract-making GUI and service: this service can be a simple static web page.

Thanks, Mike. Looks like I'll be wading into BitcoinJ if you're happy to see it extended in this manner.

Contracts are only of interest to people willing to modify the core Bitcoin code, currently (or significantly extend another implementation like BitCoinJ). There's no API for generic crafting of contracts and it doesn't make much sense to create one, imo.

I'm very interested in the bitcoin contract creation.
Is it possible for the standard client to do this, or is it only available through an API?
Are there any code examples of it in use?

But what's the justification for such a complicated opcode and set of changes? And yes, an opcode whose result changes depending on the context in which it's verified counts as 'complex' to me, relative to most of the other opcodes.

I haven't seen any use case for such a thing yet, given that it'd require a forced global upgrade.

Here is how I would define OP_BLOCKNUMBER:

1. If transaction input is verified in context of AcceptToMemoryPool it is defined as current best height + 1. (I.e. next block's index.)
2. If transaction input is verified in context of ConnectBlock it is defined as this block's index, i.e. height of block chain at time block was created + 1.
3. If transaction input is verified in context of CreateNewBlock it is defined as current best height + 1 (i.e. index of block which is in process of being mined).

These contexts already do exist as different flags to ConnectInputs(), but they are not passed to VerifySignature() and VerifyScript(). But it is trivial either to pass an additional parameter or record this info in state of transaction. I don't think this qualifies as a serious surgery, if you're concerned about code complexity I can try to make a patch which implements it and we'll see...

Now if it is defined this way I don't see how bad things you talk about can happen.

Once txn is in block its input is well-defined and so all nodes will agree on its validity. So this cannot be used to cause block chain splits. If blocks are reorganized then new transaction might have problems getting into next block, but it is also the case with double-spend scenarios, so it's nothing new. Impact can be minimized by requiring transactions with inputs which use OP_BLOCKNUMBER to mature for some time.

For transactions which are in pool validity might change over time, so different nodes with different chain heights might disagree, but this is not a problem because transactions are re-checked once they appear in blocks. It will only have effect on transaction relaying, and if transaction is not relayed then it hurts only one who made it.

You can't construct the reclamation tx without the hash of the transaction it's reclaiming.

I think I'm missing an implied step in there.  How is the hash useful as security to them?  Couldn't you just fail to broadcast the send after you get the reclaim?

But we could just skip that step entirely and end up in the same place.  They give you the reclamation transaction first, and then invalidate it (as described earlier) if you fail to send.

If you want the operation to be atomic you can create the initial send, hash it, send the hash to the recipient and then wait for them to reply with the reclamation tx. Once you have the reclamation tx, broadcast the send.

The transaction of your coins for their promise to return your coins is not atomic.

And thank you for the other part.  I had been wondering about nLockTime and sequences for a while now, but hadn't dug into them.  But now I know.  Another nifty gem hidden in the bitcoin design.

OK, I'm going to be busy for a few days so I added a final fourth example of how to lock coins to arbitrary external state using an oracle. Minor adaptations should make things like network-enforced futures contracts possible, for those who are interested in that.

I thought about it more since I wrote that post.

Something like OP_BLOCKNUMBER is probably 'possible', but would require serious surgery on the codebase. Having explored the system in more depth, I understand why Satoshi chose to implement this as a property of the transaction rather than in script.

Currently, script evaluation is independent of context. If OP_BLOCKNUMBER is defined to be the block the transaction appears in, it has no meaning outside the block chain (eg in the memory pool), so is a script containing it valid or invalid? If it's defined to be the current best height, it's possible to fork the chain when it's included (so this isn't an acceptable definition).

It's important to note that nLockTime is a property of the whole transaction, not an input. You could potentially write a transaction in which different inputs used the current block number in different ways, resulting in a lot of weird edge cases and bugs.

The design of Bitcoin is quite subtle and changing it in big ways isn't to be taken lightly. So far nLockTime seems to offer enough power to achieve many different things, most proposed uses for OP_BLOCKNUMBER can be rephrased to use the existing facilities.

Hmm, latest message I can find on OP_BLOCKNUMBER is of May 03 http://forum.bitcoin.org/index.php?topic=6900.20
and Mike says "I don't know.". Is there a new information, like, a concrete attack scenario?

If all nodes are required to validate scripts then yes, it is problematic because blocknumber might be different.

But if only miners check these complex scripts at time they are included into a block then I see no problem -- OP_BLOCKNUMBER is fixed in context of block being made. The only problem is reorg, but this can fixed too through maturation time, as ByteCoin says.

Solutions which use OP_BLOCKNUMBER seem to be orders of magnitude simpler than ones which use nLockTime, so why dismiss it just because there _might_ be problems, i.e. in absence of concrete attack scenarios? I would guess that if nLockTime looks more complex then it can have well-hidden security problems.


Yep, and with OP_BLOCKTIMESTAMP you can also check for hashrate growth before difficulty updates. (I.e. if hashrate went up blocks will be generated faster and so timestamp will be lower than you would expect otherwise.)