Topic: Implementing External State Contracts - Feedback Requested - page 4. (Read 11232 times)

Mike, in Example 1: Providing a deposit,  it is unclear when and where/what (i.e., input or output) is to be signed. I've deduced that in step #2, the user is not suppose to sign the input or the output except with zeros; making it impossible for the website to broadcast it. And in step#4, the website is suppose to sign the output of Tx1 and input & output of Tx2. And in step #5, the user replaces the zeros on both the input and output in Tx1.

Or did I miss something?

Which parts of a tx are signed is covered in the theory section of the contracts page:

https://en.bitcoin.it/wiki/Contracts

Let me know if you find that unclear.

Will do.

Mike, can you shed some light on alp's statement listed below specifically as to which parts of the transaction are signed. I believe the answer can be found in the image below.

I think it's important to have a good understanding of the Bitcoin protocol before trying to understand contracts. jadair, I suggest you read up on it so you aren't confused by things like the distinction between transaction hashes and transactions themselves. Then the scheme may become clearer.

I don't really understand how your mechanism would work.  Perhaps you might want to go into detail in what you are proposing.  What are the inputs and outputs of each transaction in your scenario?  What are the contents of the scripts that are non-standard?

but your method has flaws as you admit. I am just trying to help you find away around the flaw by asking questions and thinking differently about the problem.



I just joined a tennis league. And at each match each player brings a can of unopened balls. So there is two cans of unopened balls; these represent the two (2) funding transactions in your case. We open and subsequently play with one can of balls and the loser of the match gets to keep the used balls and the winner gets to keep the unopened can of balls.

We do not open both cans and mix them up and try to decide later who gets which balls. Because what if both players brought cans of balls and player1 removes the pops his can open and then finds out that player2 brought a can, but the can was already opened. Sounds kinda like your dilemma. Well this is easy to solve. Check the cans before you play. If the cans aren't up to code, then everyone takes the can they brought and goes home. This is what I am suggesting to you.

Inside each of the funding transactions, add an oracle script to go and check that the other persons funding transaction exists and is as expected. If not, then return funds. If an oracle can check who the 2016 World Cup Winner is, it can certainly check to see if a certain set of transaction took place. Yes?
 

Party 1 needs a way to ensure that Party 2 will actually fund a contract.  The reverse is true as well.  The exploit is, one party could fund it, the other could sit and wait until he knew the result, and then decide to fund it then.  The shared address is a way of locking up the funds so that they cannot be double spent without both parties consent.

What do you mean by keep them separate?  Party 1 and 2 send the proper funds to an address that each controls respectively (and possibly does not broadcast it).  They share the hash of each transaction, allowing a contract transaction to be created and signed.  The oracle has zero involvement up to this point.  Party 1 only wants to sign that contract if it knows that Party 2 will broadcast his funding transaction in the immediate future.  Party 2 wants the same from Party 1.

So pretend Party 1 is devious.  He has a transaction hash ready, he creates the contract transaction with the proper input from party 2, the proper output, and he gives it to Party 2 to sign.  Someone must sign first.  It *may* be possible to find a trusted third party that can merge a transaction.  I do not know if this is technically possible (it's a bit unclear to me which parts of a transaction are actually signed, but I believe the input signatures are *not* included.  That's something that might be improved upon).  You still need a trusted third party to take half-signed transactions and merge them together.  The method I describe reduces the need for that.


You have the following procedure:
1)  Party 1 and Party 2 each create a funding transaction to the shared address.  They can tell each other the hashes of each transaction so that a contract transaction can be formed.  The contract transaction is only valid if both parties actually broadcast their funding transaction.
2)  Once the contract is created and signed, so long as the funding transactions are broadcast and included in the blockchain, the contract is valid.  But party 1 and party 2 cannot trust each other to carry this out.  Which is why the refund is needed.  If either party fails to fund their transaction by a specific time or block number, the contract is cancelled and funds are returned.  This prevents either party from being able to back out of the bet in case of a loss, but enter the bet if he will win.  There is a small delay here, so this is not ideal for things that can change very rapidly (faster than blocks are confirmed and transactions added).
3)  Each party gets a refund transaction with a lock time and a low sequence number.  This transaction is intended to be replaced by the contract transaction.  The purpose of this is to ensure that if either party tries to delay entering the contract, he is automatically refunded and the contract is cancelled.  If either party does not fund the contract in time, the refund is broadcast, and the contract now is invalid and cannot replace the refund transaction.  If the contract is funded before the lock time of the refund, either party can then broadcast the contract.  If a party tries to issue the refund before the lock time and the other party broadcasts the valid signed and funded transaction, the higher sequence number of the contract will win.

I'm not sure how the oracle would be involved here.  The oracle can certainly know a contract was funded properly (although he doesn't have to, because this lets you test the oracle to sign bogus transactions).  But it won't know if either party pulled an exploit on the other where he tried to fund only after having a sure win.

The ones you list here:


So the oracle can solve the issue you listed:
At least I think.

Rather than tossing the funding transactions into a "shared address" why not keep them separate? I am thinking chained oracle transactions if you know what I mean.

You are correct the oracle will automatically sign transactions based on external states.  I don't follow what you mean by "see if both parties did fund their funding transactions".  What funding transactions do you mean?  Why does the oracle care?

Why do you say this (i.e., "it is possible the oracle may not be available to adjudicate the event, may refuse to sign a transaction, or may hold the funds hostage")? My understanding of an "oracle" is that it will make a decision one way or another in an automated way, an application.

Also, why can't the oracle see if both parties actually did fund their respecting funding transactions? It is an oracle.

Yes, broadcasting a transaction will generally mean sending it to the entire bitcoin network, not broadcasting to a single member.  Hashes are useless for the network, but a transaction will be relayed if valid (and standard usually is a requirement with the satoshi client), and discarded if invalid (not enough inputs, not signed properly, etc...).

Reading between the lines I have come to the conclusion that to "broadcast" means to broadcast the transaction, not the hash of the transaction. Let me think.

Why is Tx1 signed twice? And correct me if I am wrong, by the same user. Is it just to make it so that the website doesn't broadcast it?

I am not sure how you would propose doing such a thing, or what benefit it would provide.  Can you elaborate on what you have in mind?

Why can't you chain it?

Not in that case becasue it's not chained.  Both parties would need to provide inputs to the transaction.  There might be a way to do a more complicated merged transaction with ANYONE_CAN_PAY options, I haven't looked into it much.



No, because Tx1 is final and ready to go, just unbroadcast.  Signing Tx2 might mess up the hash of Tx2, but no one cares, since it isn't required for anything yet.  Only if you want to chain on the end of it ahead of time.

I am confused though in the Providing a deposit example. Doesn't in step 5, "signing the contract and putting the new signature in the appropriate spot" mess up the hash that was given to the website and used in Tx2? Therefore making Tx2 invalid.

Can't you structure your transaction in a similar fashion so that Party 2 is receiving a incomplete signed funding contract transaction (i.e., a hash)?

Step 3, the website does not have the transaction, they only have a hash of the transaction.  There is nothing to broadcast.  However, with the hash, he can create a chained transaction that is signed, and is only valid once Tx1 is broadcast.  But the user won't broadcast it until he gets the refund transaction back from the website and confirms its valid.

Referencing the Example 1: Providing a deposit @ https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit

Why after step#3, can't the website just sign Tx1 and broadcast it and keep the users payment?

The first prototype I made was very thrown together to generate hardcoded transactions just to prove it would work.  I shifted to a slightly different model.  I need to pull a little bit more work into actually getting redemption working, but I'm close.  Here is the depot: https://code.google.com/r/allenpiscitello-oracle2/  I'm building on top of bitcoinj.  I haven't had a huge amount of time to take my prototype (scattered through a big mess of stuff on my machine, not suitable for publishing), but this should at least show some of the ideas.

As for your question about sequence of events.  Transactions do eventually need to be broadcast.  Different transactions can be broadcast at different times, so it depends which exact transaction you are referring to. You generally have it correct, you can construct the transactions and pass them around as they get funded.   This is exactly how I expect the redemption contract to work.  Oracle signs it, gives it to Party 1, then Party 1 signs it and broadcasts.  For constructing the contract itself, that's a trickier issue since there can be some exploits that Party 2 could employ to get an advantage.  For example, let's say Party 2 has a signed funding contract for the transaction.  Rather than signing and broadcasting it, he simply holds it.  He waits until the event happens (or more information is known), then he decides to fund it or discard the transaction.  If the event will go in his favor, he signs it and broadcasts for a sure win.  If it goes against his way, he simply never funds it.  Party 1's only option is, after a set amount of time, he gives up that Party 2 will ever sign it, and makes a new transaction that spends it.

I could have misunderstood your concern, but let me know if I missed the mark.