The refund should not take priority, in fact, it should be the other way around.  A contract should override the refund, provided the contract was submitted in the appropriate timeframe (before the refund locktime).  This is to protect users from holding a contract that has been signed by everyone but him until after the external event is known (or significant information changes), then deciding to discard it or not.  Once the contract has been signed and relayed, it should take priority, unless a refund already occurred.  Submitting the refund is an "escape" so you don't have money locked up at a multisig output that the other party might not ever free up.

Malicious users can submit a refund now before the timelock and mess things up on testnet, but that's not a big concern, because it doesn't really cause much harm for users and can be avoided in most cases.  On the main network it should be fine.  The design for this is contracts that are much longer term, so they will be stored in the blockchain and prevent double spends that way, and users will know if they need to refund or the contract went through fairly easily.

So a summary of what is happening on testnet and what would happen on mainnet:

1)  Funding transactions will be relayed and immediately* included in blocks in both networks.
2)  Refund transactions, which have a timelock and zero sequence number, are relayed in testnet, but not in mainnet.
3)  Contract transactions are relayed and immediately* included in blocks in both networks, but if a refund transaction has been relayed already, this transaction is marked as invalid since it thinks its a double spend.  Currently only a problem in testnet, since mainnet will not even relay the refund transactions.

Is my understanding correct?  If so, it seems like I only have a testnet issue, since stopping relaying of timelock transactions solves the problem of the nodes not understanding sequence number replacement (at least in my use case, where I don't have a timelock on the overriding transaction).

This can be easily solved in client software that stores transactions and only relays at appropriate times (and worst case scenario, you end up with a refund when someone submits a refund before the timelock expires, and only on testnet).

I haven't tested this theory (having two different bitcoin-qt apps could do this), but what I suspect is the problem is it's staying in my local mempool only, which will reject any transactions that it thinks are a double spend.  Since my local client doesn't understand sequence number, it assumes it's a double spend and rejects it without ever accepting it into the mempool on the local machine even before relaying it.  I'm not sure if the timelocked refund transactions ever get relayed (it's my suspicion they are not relayed until the timelock expires).

I am starting to test throwing some basic external state contracts into the testnet blockchain.  I ran into a minor issue with testing, but I think it's due to sequence number not working quite like I thought.

I have TX1, TX1Refund, TX2, TX2Refund, and ContractTX.  TX1 comes from user 1, TX2 comes from user 2.  TXRefund spends with a timelock of currenttime+60 minutes and has a sequencenumber of 1 for the input it is associated with.  ContractTX takes TX1 and TX2 as inputs, but with a MAX sequence number and no timelock.

I have not been using bitcoinJ to propogate transactions, but instead sending them through the bitcoin-qt console using "sendrawtransaction".  If I send the refunds, I cannot submit the contract.  Once sequence number is fully supported, I should be able to do this.

What my understanding of the situation, without getting into the bitcoin-qt code, is that the timelocked transactions (refunds) are held in the mempool (I can see this with getrawmempool), and since sequence number is not being honored, it sees it as a double spend if I try to submit the ContractTx, so it rejects the transaction and does not relay it.  The timelocked transactions are held in the mempool but not relayed.  I likely could send a raw transaction of the contract on another client that has not seen the refunds, since they aren't being relayed (until lock time).

This is unfortunate, but not a roadblock.  I can just make the app not submit refunds until after the lock time, thus not making it look like a double-spend.

Is my understanding of what is happening correct?

The worst I can think of that will happen is someone will somehow get the contract refund tx (which expires some time after the nonces should have been published) and gets that transaction into the mempool of a lot of miners, and it blocks the correct user from redeeming the transaction.  Probably not a concern.

BTW, here are some sample transactions in the chain if anyone is curious:

Funding Transaction 1 - Funds from wallet 1 into multisig address
Funding Transaction 2  - Funds from wallet 2 into multisig address
Contract Transaction - Spends funding inputs to a redeemable location by either a) wallet 1 once nonce1 is known, b) wallet 2 ocne nonce2 is known, or c) wallet 1 + wallet2 at any time.
Contract Refund TX - I made a mistake on this one and accidentally divided the fee wrong and ended up paying a huge fee and only refunding half the funding amounts, oops!  This has been fixed.  This is an example of spending with both signatures.

You don't bet if it's going up or down.  No one is going to bet that it's going down, of course.  The idea is no one really knows what the difficulty will be in December.  Let's use a block 10 increases in the future from now as an example.  If I'm a miner, my profitability will vary tremendously based on what that difficulty is (along with every other along the way).  I cannot make an accurate assessment of whether my investment is profitable.  However, you can have difficulty futures, such that if the difficulty is above X it pays one party, and if it's below it pays the other party.  Both parties put in money up front, and get paid out in December whatever the results are.  It does not matter what X is, there is a price that someone could theoretically pay for both sides.

So you have various levels of X, and they require different contribution shares from each party.  The winner of each contract wins 1 BTC.  For example, you may have:

Difficulty	Price to win if over	Price to win if under
500,000,000	.01BTC	.99BTC
400,000,000	.25BTC	.75BTC
300,000,000	.60BTC	.40BTC
200,000,000	.90BTC	.10BTC
100,000,000	.99BTC	.01BTC

The prices will roughly track the probability of the difficulty being at that level.  For example, with these made up numbers, it would infer there is a 1% chance of being > 500M, a 25% chance of being above 400M, a 60% chance of being above 300M, a 90% chance of being above 200M, and 99% chance of being above 100M.  These kinds of prices will allow him calculate how much BTC he should mine in those 2016 blocks based on current expectations.  In addition, he can also buy some of these contracts, such as above 400M and above 500M, such that it will compensate him if difficulty rises too much, he can at least recover some of his investment.  This has a cost, but if it is lower, he will make up for it in extra bitcoins mined.

Why would someone take the opposite side?  Profit.  Say I think the difficulty will only be above 400M 10% of the time.  So I can bet 75 BTC against it going above 400M.  10% of the time, I lose my 75BTC.  90% of the time, I win 25 BTC.  This means I profit 60BTC.  I still win even if the difficulty rises to 399M.

Taking it an additional step forward, someone could offer a more complicated contract such that the miner only needs to pay a simple price, and the result of the payout would be proportional to the difficulty.  Say a miner only wanted to hedge above 400M in this case.  He could be paid Expectations of Mining at 400M - what he would make mining at the actual difficulty.  So if it was 405M, he would get a small payout, and if it was 600M, he would get a larger payout.  He would pay a small amount for this service, and would use it to make his expectations much more known in the present and make his decision making on expanding rigs, etc... easier to plan.

But the reward is much bigger.  Each miner can choose the appropriate risk/reward they want.  Huge pools with low variance should be able to charge more fees (since most miners prefer low variance), therefore the incentive to have a smaller pool works out.

Why would a bunch of miners going to alt-coins make them valuable?  Bitcoin has already been bootstrapped, there is no need to provide a free lunch anymore to get people to use it.

A+ subject change.

Insurance was used as a simplification for those who don't compare about implementation, but perhaps it was the wrong choice.

Obviously there are legal issues that need to be brought up.  A P2P nature of such a system might negate some of those challenges.  For example, while sports books might be illegal, there are often no legal challenges with two friends who put up a social wager with each other.  Sports also poses challenges, but things like prediction markets (which this could very well be a component) are certainly less grey.

Decentralizing and splitting it out might get around some of the challenges (for example, someone who merely reports the difficulty wouldn't be likely to be troubled with it, but reporting difficulty in specific formats (say hashes before hand, and nonces afterward) might).  Having peers form their own bets and use external values might get around some of it.  Having a service that helps peers find each other also may work, or just having it as a p2p network as well could work.  Obviously due diligence is needed with legal experts before actually undertaking anything like this seriously, but first understanding if there is even interest is a first step.  Bitcoin difficulty seemed like a good first target, simply because it is interesting to many people who currently hold coins and that it could actually be beneficial for the Bitcoin community to have such a market exist.

This is just a simple misunderstanding due to my simplification of how it would work.  This is merely a hedge.  This exists today without any need for scamming through securities.  You have someone put up capital to cover a fixed payout and lock it in the blockchain.  You know the funds are there, and you know you can access it once the difficulty is adjusted.

The price would be determined by those willing to bet on the difficulties.  If the price was priced too low, non-mining speculators could invest in it, driving the price up, and if too high, speculators would flock to the other side.  Those who are best able to predict the price profit, those who are worse lose, and the miners who purchase the insurance get a fair price and can accurately calculate the best guess at difficulty (and can hedge against any unexpected rises).

Change the numbers until it's profitable!

I did some basic calculations on a possibly better way to hedge against difficulty increases.  You have a mining rig that can mine at 1GHash/sec.  At the current difficulty, that's worth .01BTC per day.  Over the entire period, it would be worth .14BTC.  If difficulty increased to infinity, it would be worth 0BTC for the next period.  If it doubled, you would be getting .07BTC for the next period.  So you want the contract for the next period to pay .07 to make up for the loss of mining ability if it doubled.  If it quadrupled, you'd get .035 BTC, so you'd want it to pay out .105BTC.  This comes out to being a x^-1 function with a max payout of .14BTC.  Say you had each share pay out .01BTC, someone with a mining rig might buy 14 shares of it.  Chances are, they get a fraction of the payout (it only goes up 20%).  The further futures out are worth more.  But they could buy those (likely for a higher price), and you could even have a structured amount that pays out for every period from now until a year from now.  You could guarantee an exact profit of bitcoins for your mining rig (you know what it costs to buy the futures, then subtract it out).  A very easy way to find profitability and let other people speculate on getting the price right.  Miners no longer need to be speculators on difficulty, and can know exactly what they are getting into.  The only variable left is the BTC Price and cost of electricity.  But they can know for $X of mining equipment, they will get Y BTC after a year.

This assumes having a block time of 10 minutes is really important.  And you may end up with a more flawed mechanism if try to set future difficulty based on expected growth, where you end up setting the difficulty far to high and end up with one really, really long period of a too high difficulty.

You could structure a series of all or nothing bets to get a pretty smooth transaction at different difficulties.  The ideal situation would be where a miner could get a flat payout no matter what difficulty happened.  I haven't thought enough about how that might need to be structured, but it seems reasonable it could be done.

I agree, and I have a solution for that issue.  It basically requires the capital to be locked up.  And I can do with a transaction that gets put on the block chain that can only be unlocked by the "winning" party once the difficulty adjusts.  It can proportionally pay out with a little bit of logic different (or even some other calculation other than linear), but right now I'm focusing on all-or-nothing.  I'm trying to figure out what kind of things would be useful for the Bitcoin community to hedge against (or offer insurance against), or if it should just be entertainment based (Satoshi Dice seems to be handling that well).

One drawback with this approach is the lack of ability to have a proportional payout (e.g. a Bitcoin mining difficulty contract that pays out proportionally based on how close to 100M difficulty the next difficulty will be), but I thought about it a bit more and it at least is possible through having multiple outputs on the contract that kick in at different conditions. It's not entirely as flexible as a purely proportional payout, but you could have it in steps and get virtually the same effect:

For example, rather than betting if the next difficulty increase will be over 80,000,000, you could have a contract that pays proportionally at 10,000,000 increments.

You collect 1BTC from 2 people betting, and then make 10 outputs for example.  Each output will pay to Party A if the difficulty is above 10M*(N+1) (where N is the output number).  If the difficulty ended up being 92M, then the first 9 outputs would pay to Party A, and the last one would pay to Party B.  So you get a close-enough proportional contract in this.  The downside of this is you have 5x as many fees for redeeming as a pure proportional, and it's still got some big chunks.  I'm not sure that's a big enough concern, and of course, a transaction aware oracle could be introduced to handle such cases.  I'm a fan of keeping it simple, and until that becomes unfeasible, or there becomes demand for it, stick with the simple case.

Cool.  That's pretty much what I was thinking of, although that pays out proportionally (well, it won't after we hit 100M difficulty, but theoretically it could pay out proportionally).

Perhaps.  But there are a lot of morons who have bought into the "need faster blocks!" idea.

It's technically just informational.  The funny part is how they are investigating "consumer complaints about transaction times".  Gotta love people who don't understand Bitcoin whining about how it is broken.

Just trying to gauge interest to see if any miners would find this valuable.  Right now there is a lot of uncertainty in mining about future difficulty increases of the network, and that can make a huge difference on the profitability of expanding mining rigs.

For example, you could have insurance against difficulty increases by certain blocks, which would pay out if difficulty increased more than expected.  For example, you could buy difficulty insurance that the difficulty after the next was > 70,000,000, where you might pay 1 BTC and get 10 BTC if it was above that level.  Obviously the market would help determine the prices of such insurance.  This could be a way to hedge against unexpected difficulty increases so that you don't lose your mining investment.  Or you could simply do it for fun and try to make money by betting what the difficulty would be.

I am not offering any service of any kind, just trying go gauge general interest.