Bitcoin Forum
March 19, 2024, 11:12:54 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Designing distributed contracts  (Read 9594 times)
garyrowe
Full Member
***
Offline Offline

Activity: 198
Merit: 102



View Profile WWW
June 24, 2011, 01:42:56 PM
 #41

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

The trust scores you see are subjective; they will change depending on who you have in your trust list.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710846774
Hero Member
*
Offline Offline

Posts: 1710846774

View Profile Personal Message (Offline)

Ignore
1710846774
Reply with quote  #2

1710846774
Report to moderator
killerstorm
Legendary
*
Offline Offline

Activity: 1022
Merit: 1015



View Profile
June 26, 2011, 12:58:35 PM
 #42

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

Quote
The signature uses the SIGHASH_NONE flag, thus the recipient can be anyone (the oracle does not care). If the man dies, the son can claim the funds by taking this transaction, adding an output to one of his own addresses, and then broadcasting it.

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:

Code:
scriptPubKey: HASH256 <hash256(R)> EQUALVERIFY DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG
scriptSig: <sig> <pubKey> <R>

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:

Code:
IF HASH256 <hash256(RH_x_y)> EQUALVERIFY DUP HASH 160 <pubKeyBHash> EQUALVERIFY CHECKSIG
ELSE HASH256 <hash256(RL_x_y)> EQUALVERIFY DUP HASH 160 <pubKeyAHash> EQUALVERIFY CHECKSIG
ENDIF

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

Code:
<sig> <pubKeyB> <RH_x_y> 1

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.

Chromia: a better dapp platform
Mike Hearn (OP)
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1078


View Profile
June 26, 2011, 09:10:13 PM
 #43

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.

cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 27, 2011, 05:13:22 AM
 #44

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.
killerstorm
Legendary
*
Offline Offline

Activity: 1022
Merit: 1015



View Profile
June 28, 2011, 10:28:07 AM
 #45

The oracle transaction can be combined with another signature so only the grandson can spend the coins in combination with the oracle.

Two CHECKSIGs and two sigs in scriptSig?

Quote
But transactions propagate pretty fast. I don't think it's worth worrying about a race condition much.

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.


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

Yes, that was the plan.


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

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.

Chromia: a better dapp platform
Andrew Vorobyov
Hero Member
*****
Offline Offline

Activity: 558
Merit: 500



View Profile
September 29, 2011, 10:59:07 PM
 #46

bzzz... any results??
Mike Hearn (OP)
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1078


View Profile
September 30, 2011, 01:14:57 AM
 #47

AFAIK the only contract being implemented currently is multi-signing.
maaku
Legendary
*
expert
Offline Offline

Activity: 905
Merit: 1011


View Profile
September 30, 2011, 05:55:55 AM
 #48

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.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
Andrew Vorobyov
Hero Member
*****
Offline Offline

Activity: 558
Merit: 500



View Profile
October 14, 2011, 08:21:54 PM
 #49

https://bitcointalk.org/index.php?topic=48215.0
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!