retep - Thanks for the post.  I'll need some time to digest to see how to modify my approach based on this.

This should simplify how oracles work quite a bit (and give them some plausible deniability if an oracle service just published nonces for various events).

I'm going to toy around with things a bit and see if I can implement what you proposed.  It is quite promising.

The standard/non-standard transaction stuff is something I am aware of, I've been working with non-standard transactions on testnet, so this is not terribly new for me.  I'd like to see if I can find something general purpose and simple enough to get traction to be added as a standard transaction if needed, but a good case would have to be made.  The <data> OP_DROP <standard tx> proposal already exists, so it was easy to piggy back on that.  My first implementation had a complex script similar to what you described in your first post, and Mike suggested I move to the other script.  A standard transaction that would work would be far superior, of course, because I wouldn't have to convince anyone, or wait on nodes to upgrade.

Can you explain in slight more detail where I would use P2SH?  In particular, which transactions would need to be modified for that to work?  I presume the contract transaction.  The redemption transaction is already a standard output, so that wouldn't be needed.

When you say the oracle needs to be interactive, I presume that means the oracle needs to sign the transaction because we would have to make a non-standard transaction otherwise?  And the benefit of using the Multisig here (compared to drop) is its standard?  And we basically need to compute a public key for the oracle based on a contract expression?  Then we sign the redemption contract ourselves, and have the oracle sign it (assuming he agrees with the contract and its payout).

I'm looking pretty long term, so I'd like to design for the best architecture long term and push for those features to be standardized and relayed.  I'm not in a hurry to make this work on anything other than testnet for some time.

Your questions are coming from fundamentally not understanding how transactions work.  If you are interested in that, start a new thread, ask questions or read the link Mike sent.  Once you are up to speed, apply that knowledge to the topic at hand.

outputs are future inputs.  That's the simplest thing.  Outputs can be spent by inputs that sign transactions.  Read the transactions wiki page, read it again, then read it a third time.  Then start a new thread if anything is unclear.

I need to look at this closer but I had a similar thought when looking at this, and dismissed it thinking it couldn't protect against the losing party using the signed nonce condition against him, but it really looks like your scripts are better for this.  I may try playing around with this and see if I can get it to work and what the implications are.

Thanks for your contribution!

Obviously the nonce would have to be a pretty large data set, as you could just hash over all possible values and figure out how to spend it.  That seems like the only concern I can think of- someone could just brute force this to figure out what the nonce was.  I'm not sure if scripting allows for checking that a signature matches on some arbitrary set of data, but it seems like you could have an issue there where someone could brute force attack until he finds one that matches, then cashes out the bet prematurely.

Ready fire aim.

You sign a previous output when you spend it.  An output from Tx1 is an input in Tx2.  You need to sign it in Tx2.  Signing an output in Tx1 is not a concept that exists.

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?

I fail to see how this is a clear advantage for anyone other than those accepting funds.  And of course, there is benefits in accepting many types of payments (different credit cards, different national currencies, etc...).  If the hassle is too much (only small number of customers would use it and you have to exchange it, etc..)

Which is why Bitcoin is not terribly widespread other than for speculating in 1st world countries.  It's not able to provide significant advantages yet.  Why would anyone jump through tremendous hoops to buy bitcoins for fiat just to spend Bitcoins to possibly get a small discount, when they could have used fiat to begin with?  The only case you have is when you want to pay an individual with Bitcoins and he balks because it's too hard to spend it.  If some store near you started accepting Pokemon cards as payment alongside dollars, and gave a 1% discount, but you had to collect them all to be able to pay it, it would be stupid to think you would pay in Pokemon cards.  Sure, collectors of Pokemon cards might think this is a great deal for them, but no one is going to care.  If Bitcoins made these transactions significantly better (5% discount with Bitcoin), etc... you would have people who might get interested, and maybe the cost of obtaining Bitcoins would be worth the discount.  Still, a lot of hoops to save a few pennies.

That's why remittance will be awesome for Bitcoins.  There is a potential to make a huge impact, not just save pennies.  That's why Silk Road is huge.  That's why Satoshi Dice is huge (although part of that might be boredom of hoarders).

There are scenarios between "no one using it" and "widespread domination" that are successes for Bitcoin.  There may be certain applications where it is highly useful and others where it's painful, and it still would be a success. 

While seeing a lot of places that accept Bitcoins as payments might make someone think they are useful, they need to realize they are useful *for them*.  And to do that, it needs to be a better experience than fiat.  And presently, it's not even close.  That doesn't mean it won't be in 10 years.

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.

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?

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

First learn to walk before you run.  You have fundamental misunderstandings about how transactions in Bitcoin work.  Start here: https://en.bitcoin.it/wiki/Transactions

If you have this little clue on how things work, you should not even consider writing an app, as it will almost certainly lose a lot of money for whoever uses it.  Try reading before making a lot of dumb assumptions and arguing with people who know a lot more than you.

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?

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.

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.

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.

People spending bitcoins doesn't help them go mainstream.  What helps them go mainstream is use cases where they are vastly superior to use, or trivially easy to obtain.  There are limited usecases where that is true at the present time (I believe this will change in the future, but it isn't true now unless you are using Silk Road).

We need to focus on use cases where Bitcoins are vastly superior to the alternatives at the present time, and give people a compelling reason to use them other than "they are cool".  Remittance, greymarkets, reducing trust, etc... are all valid use cases for this.  Getting a bunch of merchants to basically immediately exchange them through BitPay doesn't do much other than put more available on exchanges, lowering the price, and inducing panics.  It is no different than selling on an exchange first, then using fiat to pay for something.

Find those killer apps and use cases where it crushes.  Invest in those areas.  Show how it IS superior instead of a toy for geeks.  Silk Road has already done this.  We need more places where you don't need to convince someone how great it is, the results speak for themselves.  If you can send money to Kenya and give people there better results, people will start using it.  If you can use it to play poker without risking seizure or fraudulent companies, do it.  People will follow if they can see the benefits.  Forcing them to imagine them will never work, and someone who sees a "Bitcoin Accepted Here" sign won't make them adopt it unless it gives them a better experience.

Hoarding isn't that bad.  Hoarding is a sign that someone thinks something will be more valuable in the future than it is now.  This reduces supply now and raises supply in the future.  Think about the following scenario:

There is a hurricane that hits Florida and destroys the food and water supplies.  What happens to the price of food and water in Florida (assuming no meddling)?  The price simply goes up.  This means people will conserve food and water (probably much fewer showers than normal, no watering of lawns, etc...).  It also is a signal to the market that water and food are in short supply in Florida compared to other places in the country.  The natural response is "greedy" people trying to make profits driving trucks of food and water to Florida to take advantage of the potential profits.  The trucks arrive, and supplies increases, and the price goes down.  A crisis averted.  Rather than seeing very high prices until they can supply themselves food and water, prices level out (probably still higher than normal due to costs of transportation, but still much lower than if nothing was done).

Speculation is a very similar problem, but instead of using distance as a way of signalling where things are more valuable, time is the entity that is used.  Rather than driving a truck to Florida, people are simply storing Bitcoins in the present so that they can use them in the future.  This reduces supply now, and potentially increases it in the future.  Those who are hoarding must pay some cost.  They would much rather have a big screen TV or a car now than in 10 years, but if they can get a return on investment, they would prefer to forgo that spending and instead get it in the future with a bonus (increased price).  Hoarders are simply transporting Bitcoins to the future, where they are more valuable, no different than those who make profits helping a crisis.

The basic economics of this is easy to show what happens.  Supplies drop now (and demand increases if people are expecting gains long term), raising the price much earlier than it would have before.  As the price rises, you see more sell-off, and the supply decreases.  You end up with stable prices much faster than before.  The fact we have $90-100 Bitcoins now with such little activity shows that the increased usage in the future is already being accounted for.  You end up with more stable prices and an auto-correcting system where even if the distribution mechanism (mining release rate) doesn't match what is actually optimal, hoarding and profit taking takes this very close to optimal.

Hoarders are a great thing for the Bitcoin economy, much like those who transport goods from areas that have surpluses to those that have shortages.

I'll have to try to make it to the next one.

I'll try to make it to the next one.

It's spelled "Joos".