Nah…decentralized crypto-currency, if not bitcoin, is the future.  There is not doubting that in my opinion.  Also, regarding the original poster that claims there is "no authority" that recognizes bitcoin, that's completely wrong.  The people using bitcoin are the authority.  In a sense, the people participating in bitcoin are a government…and one which many people will perceive to be more legitimate than legacy governmental authorities.

I'll admit that I may have read too much into your post.  It just seemed like you were suggesting Bitcoinica is a scam operation and that ripple isn't an idea worth exploring.  Note: I'm not endorsing Bitcoinica, it could be a scam for all I know.  I have played with it and I do know that the spreads he charges are huge.  I don't think he actually needs to scam anyone…he's making huge money off those spreads and that should be completely obvious to anyone trading on his system.
Ok…so right here I disagree.  From what you've been describing of Wechsel, it's not comparable to Ripple.  You can convince me otherwise, but nothing I've found on Wechsel on the web has done so.  If anything, it's convinced me that Wechsel is more like a bond market for the common man.  This is not at all what ripple is.  Again, if you don't see the difference, then I claim you really don't understand ripple.
I understand law.  I know what statutory, common and regulatory law means.  I understand how the legal enforcement of a trading system like Wechsel might be differently impacted by statutory and common law.  What I fail to understand is how it's relevant.  Ripple makes an assumption that there is little or no legal enforcement of the debt obligations created between trusted parties.  This is why they are called trust relationships.  You trust them to fulfill their obligation regardless of what any legal system might have to say about the matter (whether statutory or common law).  I do business with mtgox despite the fact that I realize I would have little recourse if they simply vanished with my money.  Why?  Because I trust them (with a little bit of money anyway).
Please elaborate on the benefits and drawbacks.  I am genuinely interested to hear these benefits and drawbacks that you believe are common to Ripple and Wechsel's.  I am not discounting the possibility that Wechsel's and Ripple are very similar, it's just that from what I've read, I don't yet see the similarities.  I much prefer discussing specifics and technicals than broad generalities.
Great.  I read what I could.  I'm not convinced the parallels are as strong as you believe.  I can assure you I'm very familiar with a lot of forms of debt and investment.  As I said before, Wechsel's seem like a bond and trading system for the common man (most people in the US aren't very literate when it comes to bond investing and typically only invest in bonds indirectly, if at all…hence, bond investing isn't something you can assume everyone has the literacy to discuss).

Ok.  I tried to wrap my head around it over the weekend.  What gives me pause with both OP_EVAL and BIP-16 is that they are pushing code onto the stack for later execution.  This undermines the deliberate desire to keep the scripting language non-turing complete.  An example of the things that I wonder about with OP_EVAL is could I nest an OP_EVAL in serialized code I push on the stack.  The "standard transactions" checks could trivially stop such a thing, but you've now created a situation where you're dependent on such "standard transactions" checks for the security of the system.  I would instead like to see a day where there is enough confidence in the implementation of the scripting system that such checks could be discarded.

I have a lot of experience in language and virtual machine design (bytecode interpreters, JIT VMs, and dynamic translation engines), so this topic is very interesting to me.

Could you explain why you think it's a dead end?  BIP17 seems cleaner to me, but with an upgrade related security issue.  While BIP16 seems like a hack (and I don't like OP_EVAL if only for the fact that it makes static analysis more difficult and it doesn't really add much capability aside from running some code in a slightly different context (outside of the scriptSig execution context)).  There also seems to be a strong urge to not allow the full use of scripting facilities in scriptSig, which I can only attribute to a "cargo cult" that has formed based on past issues.  Both BIPs seem to be contortions that try to do things in a backward compatible way…and actually, I think "backward compatible" is the wrong way to look at it.  They aren't backward compatible at all…it's just that they are designed to exploit some permissiveness in the validation rules of old clients…but the old clients aren't actually doing what they need to do with respect to validating these new kinds of transactions.  I have a strong feeling that this is wrong headed.  It would be better for the old clients to reject these new transactions and for miners to upgrade and once there is general agreement that 70 or 80% of the mining power is ready to accept the new transactions, then set a date a month or two out when miners will start allowing them.  Any stragglers (miners or clients) will quickly switch over when they realize they are at risk of having un-marketable coins.

P.S.  It also occurs to me that as a "democratic money" that this process is exactly the way it should happen.  Trying to exploit the permissiveness of old clients feels like it's subverting what should be an, albeit painful, but consensus building exercise.

Not really…you just pointed to some websites and made a claim that it proves ripple is bunk without any actual explanation.

It sounds like a vexel is a bond that can be traded and whose repayment is backed by government force.  You don't trade debt with ripple (I suppose you could, but it's beyond the scope of ripple).  If you don't understand that, then you don't understand Ripple.  I'm not sure why you think ripple and vexel's are the same thing.  You haven't even attempted to explain it.  You just make some assertions that it's beyond the capacity of a native english speaker to comprehend.  I think english is expressive enough that it should be possible to explain such a thing.

A bucket shop isn't necessarily a scam.  It just a derivative betting service on some underlying asset.  Intrade.com is a bucket shop.  It does happen to be illegal in a lot of places (but that probably has more to do with the fact that it is betting and it takes business away from the actual exchanges…wall street probably didn't like the competition).  I won't speculate on whether Bitcoinica is a scam or not…I do know that he needs competitors…he's making way too much money with the spreads he charges.  Other people could probably make a nice living if they cut into his business a little.

I'm not suggesting the BGP code be used directly…just that it's a system designed for decentralized routing that one could learn from (perhaps learning what not to do).  As for exploits by traders, I think you're imagining attacks against a system that doesn't even exist yet.

I'm not quite following you here.  Note that ripple isn't about circulating anything…you're never selling or trading any debt on any kind of market.  There are only ever bi-lateral debt obligations created in ripple.  They aren't like bonds that you would trade on a market.  And ripple like debts created in a p2p bitcoin exchange system would be designed to be settled in very short time timeframes (daily, weekly, etc).  Ripple is a great way to describe it because value "ripples through" many bilateral credit agreements in order to find a trusted path through that network that ultimately facilitates a trade between two parties that don't have a direct trust relationship.

PS.  It's worth noting the existing exchanges already work like this…two people that don't trust each other can execute a trade on mtgox…but they both have to trust mtgox.  Each person allows mtgox to run a negative balance…one person deposits ฿100 with mtgox and another deposits $600.  Mtgox owes one of those people ฿100 and the other $600 (and reflects that in their account balance).  The trade happens and each withdraws their balance from mtgox, which is settles the debt.  There are 2 bilateral credit arrangements.  A p2p exchange would simply add the ability to do the same thing over multiple hops.

The only practical difference between these is that by restarting evaluation you ensure that all execution context other than stack is cleared.  I think you could have made OP_CODESEPARATOR ensure that everything other than the stack is wiped and have achieved essentially the same objective.  If you have good tests for every opcode that ensure it behaves correctly and leaves all execution context in the correct state, you could breath a little easier about such possible exploits.

Both BIP-16 and BIP-17 have an OP_CHECKSIG in the scriptSig.  It seems you're concerned about whether it's executing in the same context as the rest of the scriptSig or it's run in some other context (i.e. scriptPubKey).  It's seems the concern is the same concern that originally motivated you to split the execution of scriptSig and scriptPubKey.  It feels like an irrational fear, but maybe the implementation of the opcodes has been historically buggy and the fear is warranted.

Well that seems bad (though I can't imagine how it could be actually exploited…other than creating confusion about transaction IDs).  Is there a problem with the scope of what is getting signed?

So, instead of a fork, you try and create a hacky solution that old clients won't completely reject, but at the same time won't actually fully verify?  It doesn't seem so clear cut that this is preferable to a fork.  It seems like a bigger risk that you have clients passing along transactions that they aren't really validating.  And, I'm not sure a block chain fork is the end of the world.  Consider that when a fork occurs (the first block with a newer transaction type not accepted by the old miners and clients), most transactions will still be completely valid in both forks.  The exceptions are coin base transactions, p2sh transactions and any down stream transactions from those.  If you've convinced the majority of miners to upgrade before the split occurs (and miners take steps to avoid creating a fork block until some date after it's been confirmed that most miners support it), then miners that have chosen not to upgrade will quickly realize that they risk their block rewards being un-marketable coins.  So, I'm pretty sure they'll quickly update after that point.  People running non mining clients will also quickly follow when they realize mining activity on their fork is quickly dying off (but the vast majority of the transactions that appear valid to them will also be just as valid in the newer fork).  The big risk for people that haven't upgraded is that someone double spends by sending them a plain old transaction after they've already spent those coins via a new style transaction that the old clients don't accept.  But even then it might be difficult for such a transaction to propagate if the vast majority of people have upgraded.

Could you explain that a bit more?  I'm not sure how a particular hop in ripple could have a negative cost associated with it.  It could have zero cost, but how could it be negative?  People pay you to execute a trade through their node?  If the cost is the trade fee that they charge, each hop would either increase the cost or not, but how would it reduce cost?  In any case, I think we could borrow heavily from BGP when designing a decentralized ripple routing scheme.

Ah, right.  Why do you say there's no practical need?  One practical need is to determine a priori whether a script is too computationally expensive to be allowed.  With OP_EVAL, I could push some code on the stack and evaluate many times over…it's possible you could trivially mitigate that problem by limiting the number of allowed OP_EVALs, but it does make it difficult (if not impossible) to determining up front, in all cases, the cost of running a given script.  You could push code onto the stack that pushes more code onto the stack and executes another OP_EVAL (creating an infinite recursion that may be difficult to detect).  For reasoning similar to the omission of loops and jumps, I would be hesitant to have an OP_EVAL.  I think the code separator & checkhashverify (or ideally pushcode) is the cleaner approach.  The whole objective here is that you want a mechanism to hash the script required to spend a transaction.  OP_EVAL goes way beyond that.  And even BIP16, which also evaluates code you push on the stack, seems wrong to me (and would make the implementation more complex and static analysis more difficult).

With a general OP_CODESEPARATOR OP_PUSHCODE, you would have the flexibility of pushing any sequence of code onto the stack for the purposes of later computing a hash value, but you would never be executing code that was pushed onto the stack.  One improvement upon that would be to somehow ensure that only code which will actually execute would be hashed (to make it impossible to just push a random value onto the stack and then use its hash).  OP_CODEHASHVERIFY has that advantage, but requires that the hashed code immediately precede the operation.  It's possible I'm being overly paranoid though.

As for backward compatibility & chain forks, I think I would prefer a clean solution rather than one that is compromised for the sake of backward compatibility.  Then I would lobby to get people to upgrade to clients that accept/propagate the new transactions and perhaps create patches for some of the more popular old versions designed just to allow and propagate these new types of transactions.  Then when it's clear that the vast majority of nodes support the new transactions, declare it safe to start using them.  Any stragglers that haven't updated might find themselves off on a dying fork of the block chain…which will be a great motivator for them to upgrade.  

Can someone remind me why BIP-12 has fallen out of favor?  OP_EVAL might add some amount of flexibility (regarding where a script is defined vs when it is actually executed), but none of these proposals seems radically different form one another.

I would suggest solving the p2p exchange problem first.  It's something that many people recognize is needed and if implemented well, will become an overnight sensation.  Many people might get lost in the detail (or not have time to study the detail) of an all encompassing proposal like this, but solve a real problem with it and you'll be successful.

I've felt and written many times that it would be fairly easy to take some existing exchange software, package it such that it's easy for anyone to download and install, then add the ripple like capabilities to it.  There would be two networks involved…one is a p2p communications network very similar to they way bitcoin propagates blocks and transactions.  The second would the the ripple network.  The ripple network forms by users installing this software and creating accounts for peers (or allowing open registration of accounts).  For each peer, you would set the maximum amount of debt allowed (default would be zero, but for some trusted peers you might allow them to run a negative balances).  A person could accept a deposit from a peer and credit their account.  All peers would have a balance at all times (positive or negative).

Then I'd take a very close look at BGP (border gateway protocol).  BGP was designed to solve the problem of decentralized routing on the internet.  By design, it doesn't require any node to have a complete view of all routing paths on the internet.  Each node maintains tables used to make routing decisions in it's localized portion of network (including metric that associate a cost with certain paths).  It strikes me that finding paths through a ripple network is the exact same problem.  The cost associated with a certain path would be the fees that a given node might charge for exchanges (similar to the metric that routing protocols assign to a path).  A path might also be reachable, but not be able to accommodate the full amount of credit that needs to be exchanged.

Orders would be announced and propagate through the p2p communications network.  A node that is originating an active, matching order would then proceed to try and find a ripple path back to the source of that order.  If successful, a trade is created and signed by the endpoints and all intermediate nodes.  To preserve privacy, the trade may optionally be encrypted such that only the nodes involved can decrypt it.  Once signing is complete, the bitcoins are delivered with the bitcoin transaction hash and order hash signed by the seller of the coins.  When the nodes see the signed delivery (and verify the correct amounts), they update their account balances.  Nodes can settle up with peers as they see fit (once a day, once a week, via paypal, ACH, wire, etc).  

Since an order and a trade are separate items, nothing prohibits an order from being a partial fill.  Orders can have an expiration on them and if someone doesn't honor an order, you can flag that node to avoid trades with it in the future.

The full order book can be established simply by listening to the p2p network, optionally tuning out orders from nodes you don't trust (or that have proven to be untrustworthy).  All nodes can optionally publish the trades they witness (optionally choosing to respect a request that it not be published).  Others can subscribe to order execution feeds of nodes they trust.  Dark orders are simply orders that don't get announced on the p2p network and that listen and try to execute on matching public orders when they appear.  Some nodes can allow dark orders to be placed directly with them and automatically matched with other dark orders on the same node.

Because at every step of the way, you are only dealing with trusted peers, many of the issues of creating two way, multi-block chain atomic transactions aren't really necessary.  I realized some time ago that even if you did that, you still have to trust the issuer of the coins you're trading for bitcoin…and if you have to trust the issuer, you're only going to want to accept coins issued by a limited number of people that you have some established relationship with…since there is trust involved either way, you really don't need the complexity of another block chain and atomic transactions between the two chains.

Super nodes will arise in this network (perhaps the existing exchanges will be super nodes) but the network overall will be very resilient against any one node going offline.  Many people already have a trust relationship with the existing exchanges (i.e. you extend mtgox a line of credit when you allow them to hold your dollars or coins).  This would be no different than installing p2p exchange software and extending mtgox a line of credit for whatever amount of dollars you're comfortable with (then actually sending them the dollars so that you can execute trades through them).

Actually, anyone could do this…you don't need to be a pool operator.  Any transaction could be used to timestamp things.  I think it's very possible that time stamping arbitrary things using the bitcoin block chain could indeed become popular.  Some might consider that spam, but if the volume of such activity increases, then so will the fees that miners require to get transactions into the block chain.  In fact, I even wonder whether time stamping something could eventually become the most important kind of transaction that bitcoin enables.  People will need bitcoins just for their ability to be used to pay the transaction fee required to get something timestamped in the block chain.  This will increase the revenues of miners and further strengthen the bitcoin network by attracting more miners.  It will drive the cost of a bitcoin transaction higher, but that's inevitable.  This will give rise to privately issued coins that work off block chain and are effectively zero cost with periodic settlement between institutions using the more costly bitcoin network.

I think we should encourage the use of bitcoin for time stamping things.

In the bitcoin network (and the bitcoin client software), there's nothing that tells you "this transaction is a double spend"…until there's a block that contains transactions that conflict with yours, you don't know for sure…you're just dealing with probabilities until then.  If a significant number of peers aren't reporting a transaction, it's an indicator that they might consider the transaction invalid.  There are other things you can look at to assess risk outside of the bitcoin network itself (perhaps it's a customer you've transacted with many times before…that would be another risk mitigator).  What you describe is basically what we do today…the merchant has the option to accept a transaction immediately and we will alert him if we later determine a transaction to be invalid.  It just that the merchant's risk doesn't go to zero until after 6 confirmations and we would like to dramatically shorten that timeframe in the future (such that for 99% of all transactions, the merchant's risk goes to zero in 3 seconds or less).

The way I think about a bitcoin transaction is that at t0 (time zero) the risk of a double spend is fairly high…after just a few seconds, the risk drops off substantially and over time the risk approaches zero.  While we aren't doing it today, our plans are to use transaction radar (probably modified a bit to incorporate other risk assessment factors) and then immediately guarantee payment for the merchant for transactions up to a certain value that aren't showing any signs of being risky after a couple seconds.  Right now, we only guarantee that the merchant will get paid after a full six confirmations.  That can take up to an hour and in a few cases, many hours.  The merchant can decide whether the act immediately or wait on 1 or more confirmations.  We've yet to have a single instance of a double spend, but that doesn't mean there isn't a risk of it.

The only reason we haven't yet implemented these things is that we're still working on building other features that are more urgent. 

I'm aware of that.  But right after P2SH is supported, you then have to whitelist new transactions to get multi-sig.  This whitelisting process requires coordination.  I just wonder whether most (if not all) valid scripts should be allowed along with the p2sh change (subject to limitations on the number and complexity of operations).  Since the script language is not turing complete, it is possible to estimate the cost of executing a script and impose such limitations.  Otherwise, every time a new type of transaction becomes desired, you have to go through this process of coordinating the upgrade of clients to support it.

Regarding backward compatibility, I think Gavin makes good points about BIP-17 in the OP (especially the point about spend transactions automatically being considered valid no matter what by old nodes).

The more I study this, the more I'm starting to feel that allowing just a specific set of standard transaction types is an unnecessary constraint on the system.  Is it an irrational fear?  Why not allow all valid scripts?  What is the risk?  It seems like it's going to be a real problem going forward if every time someone comes up with some new type of transaction they want to craft that they need to get the entire network to upgrade in order to do it (especially with P2SH).  This kind of coordinated upgrade should only be necessary if you're adding or changing the behavior of the opcodes.  Soon after the P2SH transition happens, you're then going to need to convince miners to start accepting various multi-sig transaction types.  Each time you do this, you have to be very careful or risk serious chain split.  It seems to me that the need for more interesting transaction types, and the risk of chain split when adopting them, warrants serious study of lifting the "standard transactions" restrictions.

It can be even better than this.  One of the output addresses of the transaction can be a hash of the email message.  The recipient sees the transaction hash in the header, hashes the email payload (see CommitCoin) then checks to make sure one of the output addresses is that hash.  I think that output can have a value of 0 (if not, then 1 Satoshi).  If it pays you enough bitcoins, it moves the message into your inbox (if not, it stays in spam or some other low priority folder).

As for Casascius' concern about HDD space, I don't think the bulk of emails would be sent this way, but it would be a way that one could bypass spam filters if you're a correspondent that's unknown to the recipient.  Also, remember that nodes on the bitcoin network do not need to retain the full transaction history to work…they only need to retain all unspent transactions.

On further thought, I would revise this:

   scriptSig: [signature] OP_CODESEPARATOR [pubkey] OP_CHECKSIG OP_PUSHCODE
   scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

To be:

   scriptSig: [signature] OP_CODESEPARATOR [pubkey] OP_CHECKSIG
   scriptPubKey: OP_PUSHCODE OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

The reason is that in the previous form if you wanted to attack it, it's only necessary to reverse the hash160 function with whatever the scriptSig leaves on the stack.  In the second form, not only would you need to reverse the hash160 function, but it would also have to be a valid script sequence (a bit more secure).

I sat down and studied these proposals this morning.  However these proposals came about should be set aside in favor of doing what's best for bitcoin.  I have no idea what transpired, so I feel my judgement isn't clouded in that respect (could be in other respects, but not that one).

Disclaimers: I've not considered any backward compatibility issues which might trump everything I have to say.  I've also not considered any implementation concerns (complexity of the code, etc).  That might also trump what I have to say.  And finally, while I think I have a good grasp of bitcoin scripting, I am by no means an expert.

I think sending coins to a script hash is good thing and perhaps the way it should have always been done, even for simple transactions.  The BIPs say that P2SH makes it possible for the recipient to define the script required to spend coins.  But here's an observation:  It has always been the case that the recipient defines the script required to spend coins.  It's just that there has, to this point, been a universal assumption that when the recipient sends you an address, that the recipient desires that a specific kind of script (a simple single signature).  It's also not true that with P2SH that the recipient doesn't need to tell the sender the form of the script that is desired.  The recipient is telling the sender the form of the script.  It's just that since the script is only executed when spending coins, the only thing necessary to communicate to the sender is a hash of the script, not the entire script.  All transactions should work this way (the sender will never have to ask whether this is a simple, single signature transaction, or a P2SH transaction…they will all be a P2SH).

I think BIP17 is a superior proposal to BIP16 and BIP12.  BIP12 (OP_EVAL) simply adds complexity to the method of executing scripts.  Validation of scripts now needs to look into the content of data push opcodes.  I can't see that it introduces any particular security holes (i.e. AFAIK there's no way to put something onto the stack that didn't originate inside the script itself …akin to a SQL injection attack).  However, I also can't see that it adds value.  BIP16 feels like it's caught somewhere between BIP12 and BIP17.  It's neither a general purpose OP_EVAL proposal and yet it still requires special handling and execution of code pushed onto the stack for no other reason than to compute its hash.  This just feels a bit hacky to me, especially in light of OP_CODESEPARATOR, which seems to be designed for this sort of thing.

I'm not sure why the use of OP_CODESEPARATOR is a concern.  It seems to me that the way BIP17 is using it is exactly what it was intended for.  It's purpose as far as I can tell is to provide a means of isolating the portions of a script that should be subject to a hash/signature from those that shouldn't (i.e. you obviously wouldn't want a signature to actually be included as part of the hash used for signing purposes).  I assume that there is an implicit OP_CODESEPARATOR that sits between the ScriptSig and ScriptPubKey (the terminology here should probably be updated to better reflect what these two things really are…but I'm not sure how I would describe them).  I supposed if I had it to do over, I would have created an opcode to push a segment of script onto the stack…it would push just the portion of code since the last OP_CODESEPARATOR.  Then you could have something like

   scriptSig: [signature] OP_CODESEPARATOR [pubkey] OP_CHECKSIG OP_PUSHCODE
   scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

Now that I type this, I realize this would only require one new opcode, OP_PUSHCODE instead of OP_CHECKHASHVERIFY…maybe BIP18?  Like BIP17 (unlike BIP12 and BIP16), there are no special execution semantics, and OP_PUSHCODE seems a little more generally useful than OP_CHECKHASHVERIFY (which is generally desirable for things that are going to consume an opcode).

I don't see any issue with using OP_CHECKSIG in the ScriptSig.  And, in fact, it's in the scriptSig in both BIP16 and BIP17 (the only difference is a meaningless difference the mechanics of how it gets executed as far as I can see).  But if someone can come up with a plausible reason to be concerned, they should certainly voice it.  I don't however think it's good to make a decision based on a vague feelings (for or against).