I've written up a rough draft of another idea.  This one should allow a distributed derivatives exchange or prediction market to exist on top of Bitcoin while permitting most of the bets to be off the blockchain.  I used constructs from my payment network scheme - bet channels similar to payment channels.   The write-up is here:

https://en.bitcoin.it/wiki/Off-Chain_Betting

Feedback appreciated.

[UPDATE]

I've written up a rough draft of an idea for decentralized networks allowing instant, off-chain payments.  The networks would use the block chain for settlement, but use chained micropayment channels for payment clearing.  I used constructs invented/described by Mike Hearn, hashcoin, cjp, Meni Rosenfeld, retep and others in the idea.  The network would utilize two-phase commit of a payment across a chain of micropayment channels through multiple intermediary nodes.

The write-up is here, as a draft under my Wiki user page:

https://en.bitcoin.it/wiki/User:Aakselrod/Draft

UPDATE

Proof-of-concept here:

https://github.com/aakselrod/libtxchain-java

When I buy bitcoins, I export a portion of my labor from the Bitcoin economy to the local fiat economy, adding to Bitcoin's trade surplus and raising the Bitcoin economy's currency value.

When I buy something with bitcoins and the merchant accepts them as dollars through BitPay, I've imported from the fiat economy into the Bitcoin economy, reducing Bitcoin's trade surplus and lowering the Bitcoin economy's currency value.

In order to grow the Bitcoin economy, it needs to be easier to acquire bitcoins by exporting labor. Some ways to do so:

• Get payment processors, ad networks, affiliate networks, etc. to PAY OUT using Bitcoin.
• Write payout plugins for open source and COTS affiliate program, affiliate network, ad server software to handle Bitcoin payments.
• Start an affiliate program or network which accepts fiat and pays out in Bitcoin; this would require good fraud prevention via waiting period before payout or other measures.
• Start an ad network which sells traffic to an ad exchange like Yahoo! APT for fiat, buys bitcoins and uses them for payout; this would require tracking which publishers' traffic is judged by the ad exchange to be fraudulent.

As of 0.8, the IsStandard check looks to see if a transaction is finalized. If I'm correct in my understanding, this means that 0.8 nodes won't accept into their memory pools or relay non final transactions. This would be a very similar effect to having transaction replacement enabled on the network when 0.8 and later clients make up the majority of the network.

When this happens, contracts like two party escrow and rapidly adjusted micropayment channels can use non final transactions to prevent permanent loss of bitcoins, and dominant assurance contract vendors won't need to worry about funders broadcasting their non final transactions early so they hang out in memory pools and block the final, successful transaction from propagating.

I'm working on a description of a peer-to-peer instant transaction clearing network based on others' previously explained concepts with chained two-step commit and routing/reputation information stored in the blockchain as a side effect. I think transaction replacement may reduce the need for reputation, which in my scheme is mostly a way to reduce the risk of maliciously burned coins. The scheme would allow the network to settle on the blockchain, reducing but not eliminating the need to increase the maximum block size.

I'm on my phone, so please pardon the lack of links.

Is anyone from Richmond or nearby interested in having a Bitcoin meetup? Maybe at one of the many local beer places, or we could talk to hack.rva about doing a meeting?

I started writing unit tests yesterday for re-enabling transaction replacement.  I'd like to ask the community for their ideas for transaction replacement use cases so that I can work toward a solution that would work for as many people as possible.

I'm also considering the idea that if transaction replacement is not enabled, many use cases would be enabled by changing the semantics of nLockTime such that transactions with an nLockTime in the future (either block number OR time) must not be accepted to the memory pool at all.

Some caveats to think about:

• CTransaction::IsNewerThan appears to have a flaw in the final loop of the method, unless there are side effects people care about.  In the current incarnation (which dates back to sometime in 2009 or possibly even back to the original code), it's possible for some inputs to have higher sequence numbers than the previous version of the transaction and for some to have lower sequence numbers and still have the transaction come out as "newer."  Unless this is done for specific side effects, it appears to be a bug (though easily fixed).  As far as I can tell, the only code that calls CTransaction::IsNewerThan is CTransaction::AcceptToMemoryPool, and that code path is never hit due to the disabling of transaction replacement.  In addition, that code doesn't use any side effects of that loop as far as I can see.
• I haven't found any code that prevents transactions from using the outputs of non-final transactions in CTransaction::AcceptToMemoryPool.  In the event of transaction replacement, such code will be necessary in case outputs are changed about.  It may be desirable to restrict the way outputs may be changed to prevent double spends.
• At the very least, we'll need to add output to RPC and possibly to the UI to show whether unconfirmed transactions are final or not.  This will be important to merchants to ensure that they don't take 0-confirm transactions that can be replaced out from under them, causing a double spend in reality, regardless of how they've propagated through the network.
• Some form of discouragement should be undertaken to prevent miners from including versions of transactions that aren't the latest version.  If this uses block rejection, this will cause miners not following the rules of the majority to mine blocks that will not be accepted in the consensus chain, causing lots of dead-end branches.  If this uses transaction fees to incentivize miners to get the maximum fees by including the latest version, it might be a good idea to restrict newer versions to force them to pay higher fees with each version.  This still requires guesswork on the part of the sender to predict how much of a transaction fee addition would make miners willing to validate the new version of the transaction.  It also means we may need to change the rules for transaction replacement with regard to inputs, allowing a new input to cover the additional transaction fees if needed (this would mean modifying at least CTransaction::FetchInputs as well).
• There are no incentives to forward multiple versions of a transaction; in fact, there is a disincentive: each time a new version is received, it must be validated before being accepted to the memory pool and forwarded.  This resource usage could actually cause a DoS, as Gavin has mentioned, if too many versions of a transaction are forwarded through the network.  Anti-DOS code would have to be added to somehow throttle propagation of new versions; some people may even modify their nodes to not propagate such transactions at all, which would defeat the purpose of this whole debate.
• Changing the semantics of nLockTime to mean that non-final transactions can't be in the memory pool doesn't change the block validation rules.  It also prevents non-miner nodes from having to validate a lot of different versions of a transaction, causing DoS.  The caveat is that in actual use, nLockTime will have to be set far enough out that the final version of the transaction has virtually 0 chance of not making it into a block by the time nLockTime expires.  This would prevent a timelocked transaction from being accepted by miners over a finalized transaction with a lower fee.

This is an attempt at Mike Hearn's "exercise for the reader." It relies on P2SH (or multisig) and nLockTime, with no transaction replacement.

1. A vendor agrees to produce a good if X BTC are raised by date D and to pay Y BTC to each of n contributors if X BTC are not raised by date D, or to pay nY BTC if X BTC are raised and the vendor fails to produce the good to the satisfaction of 2 of 3 independent arbitrators picked through a fair process
2. The arbitrators create a 2-of-3 P2SH address with a public key from each arbitrator, which will allow them to judge the performance on actually producing the good
3. For each contributor:
3a. The vendor and the contributor exchange public keys
3b. They create a 2-of-2 P2SH address from those public keys
3c. With no change, they create a transaction with an input of X/n BTC from the contributor and an input of Y BTC from the vendor, with X/n+Y going to the address created in 3b
3d. The vendor signs a transaction of the entire balance of the transaction in 3c over to the contributor with nLockTime of D and gives it to the contributor
3e. The contributor signs a transaction where the output is X+nY to the address created in step 2 and the input is the output of the transaction in 3c, signed using SIGHASH_ALL | SIGHASH_ANYONECANPAY and gives it to the vendor
4. As date D nears, nLockTime comes close to expiration.
4a. If enough (n) people contribute, all of the inputs from 3e can combine to make the output valid, creating a valid transaction sending that money to the arbitrators, which only agree to release the funds when the vendor produces a satisfactory output
4b. If not enough people (<n) contribute, nLockTime expires on the transaction in 3d, meaning each contributor can sign and redeem her transaction containing X/n + Y BTC from 3c
4c. Note that there is a limit at which it can be more profitable for the vendor to make the remaining contributions when D approaches

[Edit]

So I've been curious about uses for the two-party escrow mechanism enabled by multisignature transactions and P2SH.  I'm interested in replacing Contracts example 7 with something that doesn't require nLockTime or transaction versioning.

As I understand it, a two-party escrow mechanism would work as follows for minimized-trust transactions:

1. Alice wants to buy a widget worth X BTC from Bob
2. Alice creates two public keys, A1 and A2.  Bob creates two public keys, B1 and B2
3. Together, Alice and Bob create a 2-of-2 multisignature address C1 from A1 and B1
4. Alice signs a partial transaction T1 with an input of 2X BTC and an output of 3X BTC to C1 and passes it to Bob
5. Bob adds an input of X BTC to T1, signs it, and broadcasts T1 to the network
5a. The result is that Alice paid 2X BTC and Bob paid X BTC to the address, so they both have a stake in agreeing about how to release the money and griefing/fraud are prevented by both Alice and Bob by making those actions more expensive than playing honestly. In addition, both Alice and Bob are protected from fraud in the initial transaction as T1 is invalid unless both inputs are valid unspent outputs from previous transactions.
6. Bob sends Alice the widget
7. Upon receipt of the widget, Alice signs a transaction T2 from C1 paying 2X BTC to Bob at key B2 and X BTC back to herself at key A2 and passes T2 to Bob
8. Bob signs T2 and broadcasts it to the network, receiving his payment and "security deposit" and sending Alice's "security deposit" back to her

In the event that Alice and Bob can't agree on who should get how much money based on partial/complete nonperformance of the contract, they can both pick an arbitrator Trent, who generates three public keys, R1, R2 and R3.  A new 3-of-4 multisignature address is created for A1, B1, R1 and R2 so that Trent can only spend the money with agreement of either Alice or Bob, and this turns into a third-party escrow situation if the parties desire.  Eventually, some amount is sent to A2, some to B2 and some to R3.

Would this work in rapidly-adjusted microtransactions as well?  For example:

1. Alice wants to buy about 100MB of transfer from a Wi-Fi access point operated by Bob and pay .0001 BTC per 10kB
2. Alice and Bob create a transaction T1 to C1 as in previous steps 1-5, with Alice paying in 2 BTC and Bob paying in 1 BTC
3. Alice signs a transaction T2 from C1 with 1.0001 BTC going to Bob at key B2 and 1.9999 BTC going back to herself at key A2, sending T2 to Bob who does not broadcast it
4. Alice continues to use 10kB of bandwidth at a time, signing a new version of T2 each time with an ever-increasing amount going to Bob and ever-decreasing amount going back to her
5. Alice notifies Bob when she is done, at which point Bob stops providing services to Alice and signs and broadcasts T2, thereby completing the exchange

This would enable such rapidly-adjusted microtransactions without relying on transaction versions or nLockTime, which means they're practical as soon as P2SH is available on the network.

I would like to know whether this would actually work as I described it, as I have some other ideas relying on transactions like this.

Edit: Changed Trent's keys from T1, T2, T3 to R1, R2, R3 so they aren't confused with transactions T1 and T2.

Is anyone working on any cash-settled futures/options exchanges against physical commodities (precious metals, base metals, oil, natural gas, coal, agricultural commodities, electricity)?  I think it might help reduce the volatility of the BTC.  It might also drive adoption.

Just as interestingly, is there anyone working on open-source software for creating such derivatives exchanges?  Would OpenTransactions be a good fit?