The legality depends greatly state to state.  There is skill gambling on sites like worldwinner (although the site is highly flawed because the site rigs it so you only compete against people nearly identical in skill to you, and the house just collects huge fees, and bans you if you win too much).  I remember the site not letting me play when I was in Arizona, but was legal elsewhere.

Poker is one of those grey areas where it hasn't really been tested in courts, although some states are super strict with this stuff and others aren't.  Some have rules about the house taking a cut, etc...

I probably should have mentioned it.  I'm glad I understood it correctly, it's one of those things I was a bit shaky on.  From my understanding, everything should work as expected with both the way everything is currently set up and should continue to work even if transaction replacement is enabled in the future.

I am agnostic to the hashing algorithm used, so I can easily switch.  The only reason I used RIPEMD160 is I had some test cases that I ran through an online hash webpage that used RIPEMD160 and it let me calculate the hash values independently.

I'll change the code when I get home, but I just need to calculate the nonce hashes using that algorithm, which I believe should be pretty easy to do using the same webpage I used to calculate the nonce hashes.

If you have any notes from the presentation, I'd be interested in seeing how it applies to the oracle application.  I'll likely try to present something to our local meetup group in the future.  It's a tough balance to tread between being overly technical and simplistic with these audiences.  I think it would be a lot better to have a sample app that people could use to play with and really touch and feel.  In the mean time, I might try to put together some type of youtube video that shows how it might work in action.

I need to understand exactly what the limitation is.  My understanding is the network won't even relay anything that has a timelock < currenttime.  In this case, the sequence number doesn't cause any issues, as the transactions are ignored, since every sequence 0 is timelocked.  The sequence number is used just in case the network starts relaying these transactions (and supports replacement).

Unless I am way off on how what the limitations are.

I was able to make quite a bit of progress on this and completed all the main test cases.  I need to start creating a test app and a protocol for communicating for users.

I had to make some very basic changes to the script to get it to work.  Here is a quick summary of the process that is used:

Each user drafts a funding transaction that goes to a 2 of 2 mulitisig output, but does not sign or broadcast it.

Each user sends the draft to each other along with a refund transaction that spends each funding transaction by sending it back to its owner.  The other user signs this transaction and sends back the signature so each user has a way to get their money out of the 2 of 2 multisig output in case the other user never signs and broadcasts his funding transaction.  The refund transactions have a sequence number of 0 and a lock time of 1 hour after the current time.

One of the users also creates a contract transaction that uses a P2SH output that spends the two funding transactions.  He sends it to the other user to sign.  This transaction has a higher sequence number for its inputs and a final lock time, so it should replace the refunds once it is signed and valid.  After both signatures are added, this transaction can be broadcast.  The script for the output is as follows:

OP_RIPEMD160 OP_DUP [trueNonceHash] OP_EQUAL
OP_IF
 OP_DROP [trueUserPubKey] OP_CHECKSIG
OP_ELSE
 [falseNonceHash] OP_EQUAL
 OP_IF
  [falseUserPubKey] OP_CHECKSIG
 OP_ELSE
  2 [trueUserPubKey] [falseUserPubKey] 2 OP_CHECKMULTISIG
 OP_ENDIF
OP_ENDIF

It's a slight modification of the one retep suggested.  To spend it, you have a few options.  If you can cash it in alone because you know the nonce values, need to add the nonce and your signature to the scriptSig.  If you want to redeem it with the mulitisig option (for example, if the oracle disappears or you wish to have an early buy-out), you need to add a scriptsig of 0 [trueUserSig] [falseUserSig] 0.  The first 0 is there to get hashed by the RIPEMD160 function and not be equal so we get to the final else case.  The last zero is there to account for a bug in checkmultisig that pops an extra item off of the stack.

Users can automatically create the "no oracle refund" ahead of time as well, and set a lockTime on the transaction of well past the event (say a week) in case the oracle cannot be found, and set it with a 0 sequence number on the input.  Then the transaction is replaced by anyone who can redeem it.

I've only run basic unit tests on this code so far, need to clean it up a bit before publishing, but plan to start making a very basic app for testnet to actually start publishing some transactions and seeing if this works.  If it does, I'll try to start working on the protocol and possibly some demo websites that anyone can use (on testnet for now).

Almost all users are using clients that do not overpay.  Very few people mess with raw transactions.  There are instances of people screwing up testing stuff or trying to be cute.  You are trying to solve a problem that virtually does not exist and cannot be solved.  If you want to use this use case, code it without making a mistake and test the hell out of it.  Then your users won't screw up.

Better will need to have real tangible benefits to overcome networking effects, and if they did, it might be worth the fork then, especially if it was planned out well in advance.  It will be interesting to see how things play out, and it's tough for the first version of anything to survive long term, almost always something is left out and someone improves.  Bitcoin has a pretty huge first player advantage, though.

User error in raw transactions and in code are something to be very careful of.  This has happened a lot.

Explicitly calling out the fee is a good improvement, and seems like something that should be considered in the future (all blocks after N need to have correct outputs, and have a way to tell miners).  That's a nasty fork, and I'm not sure how much benefit there is to it. 

Yes, it might even be preferred for the website to have the unsigned transaction, as he has no clue what he is signing.  If the website is not careful, the transaction could possibly be a spend out of one of his addresses (he would have to ensure that no one deposits funds into the address of his public key, or inspect each transaction).  The website would have no idea if the transaction matches one of his unspent outputs or not since he doesn't have the connected script or the transaction being generated.

In this use case, you don't broadcast the transaction until after you receive a "refund" transaction.   So no nodes see it except yourself (if you are doing it right).  The refund is then given back to you, which you can't broadcast until after you broadcast the funding transaction.

Users are unlikely to be creating raw transactions like this, though, so some software will need to present it to them what is going on.  That makes it far less likely that a mistake will be mad in creating these transactions.

The website could set the deposit and give refunds earlier by having a higher sequence number that refunds some, and locks up the rest.  This would have to be worked out after the deposit is there with the refund.

Users can see the contents of transactions, so I have no clue why you think a hacker would be able to change any of this.

There is no need to make this "more secure", the data is all there to the party that cares the most (the user), and once published to the blockchain, it's available for the website.

The 10BTC deposit is an example, you could do it with any amount larger than dust and it would work the same.

You can write software that displays things to users and double-checks with them and tries to do the correct thing.  Users can take the transactions and try to validate them independently of your software if they so choose.

I literally have no idea what you are worried about or concerned about, these are fairly trivial problems and easy to solve.

There is no way to validate it through just the hash.  The user could create the refund transaction and give it to the website (since he knows what the hashed transaction is), or he could tell the website how much to make the refund for.  If he screws up, then he loses (either by paying a huge transaction fee or getting an invalid refund that ends up in limbo until the website grants a new refund).  The user can verify that the refund is for the correct amount before signing and broadcasting anything.  This is *his* responsibility (and likely should be a part of whatever custom wallet he is using to do this).

BTW, I have implemented this in Java if you need sample code.  It's a bit messy now and needs some refactoring but it at least should work.  Disclaimer:  I have only done basic testing with it so far, and need to actually create some transactions on testnet to show it works.

You can specify whatever value you want as an output.  It just won't be valid if it's too high.

Thanks for the quick reply.

I was digging through the bitcoinJ code and had it mostly figured out.

From my understanding, the new clients (that know about this special rule) will do an extra check, but old clients that don't treat it specially will not do the extra check, thus making a situation where an invalid scriptSig evaluation occurs would validate as correct?  And anyone trying to spend them will only end up in blocks that are mined by old clients, and those blocks will be orphaned since the majority of the network will do the extra validation.  Is this correct?

I was able to switch to using the nonce-hash script and it so far has gone very well.

I had some questions about P2SH, though.  Here is the example used for it:
scriptSig: [signature] {[pubkey] OP_CHECKSIG}
scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

If I understand how the script processing works, you push all of the scriptSig onto the hash, then start processing the scriptPubKey.  I presume that the {[pubkey] OP_CHECKSIG} in this example is a single piece of data that is pushed onto the stack, and not the actual operations.  It's a bit unclear to me.  So assume its just data.

We end up with the stack as:
{[pubkey] OP_CHECKSIG}
[signature]

Then we get the hash operation, which will replace the top item on the stack with the 20-byte-hash of that data.  So the stack is now:

[hash]
[signature]

We add another hash that should match:

[hash]
[hash]
[signature]

Then we get OP_EQUAL, and the top two items are equal, so we have
1
[signature]

on the stack, and it's valid.

This makes it seem like the signature is not needed at all.  I must be missing something.  What is evaluating the script that's part of the scriptSig?

I have no idea why you think this has anything to do with doing this at the expense of market share.  I think Bitcoins are great, but when you have a disruptive technology, you need to give a superior experience.  I'm not relegating anything, consumers will (and have).

If Google+ had a significant advantage over Facebook, it would win out.  Same reason why Bitcoin is not winning the fight.  People need to focus on areas where it is WAY better, instead of not really any better (or worse).

I had a similar idea, might even be an alt-coin with this type of thing, but there needs to be an incentive to give the right answer.  Kenneth Massey (he has a ranking system used in the BCS for college football), has a weighted ranking system where he takes inputs from anyone, and if they don't correlate well to everyone else, they are not weighted as heavily.  Perhaps you cold have a system where pick what event actually happened, and if they answer with the majority, they get rewarded from any saboteurs and any fees that people betting might pay for arbitration.  Still not sure how it would work, maybe some alt-coin just for answering events whether they occur or not?  Might be a lofty goal for down the road, I'm sure someone smart can come up with a way for this to actually work if its possible.

A lot of really bad advice in this thread so far, so make sure you talk to someone who knows what they are doing.

This is not tax advice but my best understanding of the situation.

If you are running a mining operation like a business, you will take the value of the bitcoins at the time you mine them as income.  This is going to be tricky, since you likely are a part of a mining pool and get lots of payments periodically.  You might be able to deduct the costs of your mining rigs and reasonable other costs (electric bill for the operation, etc...).

You can do capital gains on the value gained from the time you mined the coins to the time you sold them.  Or capital losses if they went down in value.  Long term vs. short term capital gains depends on how long you held them.  You'll also need to worry about self-employment taxes if you treat this as a business.  You may be able to treat it as hobby income, but then you cannot deduct expenses.

To properly report, it will be a huge pain in the ass.  The simpler method that you might be able to use is to take all the money you sold them for on an exchange and report it as other income.  Talk to a tax attorney (not some H&R Block data entry specialist) for a better opinion.  Above all, do not listen to anyone on this forum (including myself).

Mike,

If you could update the wiki, it would be great, I bet it is more clear what needs to be changed to you than me.

One thing about the oracle being stateless, I am considering that right now, where the oracle is split into two entities.  One that will provide external state, and one that will validate it.  The desire for a stateless oracle is nice, but somewhere a state is needed to be maintained (obviously this could be google, a sports website, etc...), I'm just not sure it's as convincing of a use-case and maintaining the nonces seems like a trivial problem.  There's a security risk, but keeping the nonces offline and only transferring when needed could at least give some security.  Splitting the oracle into a "news service" and a signing service shifts the problem around, and it could make the script simplify to "go check this news service with this event and go get its nonce.".  Oracles can be dumb and maintain no state, although the burden just shifts.  But in this case, you pretty much eliminate for the oracle, since you program the hashes of the nonce right into the script.  Maybe there's a use case for both?  When you can easily automate it into a script, the script method, for simple events that will be published in a known way that publishes nonces, use this other way.

retep,

Re: the derivative pubkey, I assume this is mechanism serves a similar purpose to the expression hash in the original proposal?  The oracle doesn't want to sign a transaction unless he agrees it should be paid out, and he has no idea what the contract was if he doesn't have a derivative pubkey to use.  He can validate that the derivative key was in fact the one that should be generated by the original contract.  But if we go with the nonce idea, this all isn't important because oracles become naive to transactions.  Do I understand this correct?

I'll update my proposal based on Mike's changes to the Wiki and make sure I have everything correct before working any more on the code.