I wonder if covenants were what Satoshi was trying to achieve with the strange signature procedure, OP_CODE_SEPARATOR and concatenation of scripts.

I don't think the lack of Turing completeness is the biggest limitation. It's unfortunate that scripts do not have direct access to the transaction data itself and some notion of time. If they did, you could implement things like daily withdrawal limits and limit withdrawals to certain classes of scriptPubKeys. Of course, we should probably first experiment with things like that by using something like Reality Keys and additional signatures.

This can be done with something like Reality Keys without needing script extensions.

But isn't that precisely what this proposal is intended to deal with?

Why does it no longer work?

Doesn't that mean that Bob is blindly signing something? Wouldn't that be incredibly risky? EDIT: never mind, Bob is signing with a brand new key.

Unless there is a trust path between the individuals, as might be the case once the user base reaches critical mass.

I've finally managed to stumble across something that appears to be a real weakness of Ripple: privacy.

IIUIC, out of the box Ripple offers very little privacy. Each account has a single address, so once someone you've transacted with knows your address, they can see your entire financial history. Or at least, they can see the amounts, since they might now know the real world identities behind the addresses of the counterparties. In the case of governments the situation is even worse, since governments can be expected to be able to hoover up large numbers of identified addresses.

While Ripple does support account families with multiple addresses, which are similar to deterministic Bitcoin wallets, the standard client doesn't appear to offer any support for it. More worryingly, trust lines run between addresses, not account families, and it is hard to see how this could be different given that there is a public ledger. This wouldn't matter for XRP transactions, but fiat transactions rely on it.

Hosted wallets can provide privacy, but that does mean you have to rely on intermediaries to get privacy, which isn't very desirable.

So, am I missing something, or is this a major weakness?

It would be nice if scripts had access to just the information in the transaction itself and that does not need access to block height or any other data from the rest of the blockchain. Things like number and amounts of the inputs, output scripts etc.

I agree with your general point, but this jumped out:


What are you thinking of that a (spending) script could reveal? A hash preimage?

Double entry accounting is all unsigned integers and addition too. :-)

You are volume weighting the prices of different exchanges at the same point in time, in addition it would be nice to have volume weighted averages of the same exchange (or group of exchanges) over the past 24 hours.

Volume weighted averages would be a very good addition.

I wonder what a Forth expert would make of Satoshi's choice of opcodes. Did he lift it from somewhere, does it look like the work of an experienced Forth hacker? My only experience with Forth is playing around with PostScript a bit, so I can't tell.

I think there was, because the fields are already named scriptPubKey and scriptSig. It was probably preceded by an implementation that had no scripts, just public keys and signatures. I wonder if there was an intermediate phase that allowed multiple keys per output, but not yet full scripts. Maybe the concatenation business made sense in such a context.

Also note that SignSignature and VerifySignature aren't in the files here, although that would be the obvious place to put them. I suspect they used to be there in an even earlier version and were moved to script after that was split off. And script may have been too immature for Satoshi to share just yet. Then again, it's interesting to see that it does already include nLockTime and transaction replacement.

I've also wondered if maybe there was an earlier implementation that used balances, not outputs, as that is what I would have started with. The most obvious starting point might be single input, single output, single signature transactions between accounts. But there is no evidence of this, and maybe previous ideas discussed in the literature already chained individual coins.

A pity that script, VerifySignature and SignSignature aren't included. It might have shed some light on why OP_CHECKSIG works the way it does.

They have their own exchange which is about to go live as soon as they get permission from the Dutch Central Bank, which should be somewhere in February. In the meantime they are running with a closed group of traders, which is allowed.

It's also nice that your blockchain watching functionality allows us to experiment with some of the things we might want to do in a Script 2.0 without too much risk.

Then again, if you used a hash, there wouldn't be any addresses to spend to. One advantage I can see is that doing it with an address rather than a hash is that you don't run afoul of IsStandard. Any other pros or cons?

And speaking of IsStandard, what are the prospects of less restrictive rules any time soon, perhaps only for P2SH scripts?

And of course, it wouldn't bias your decision either way, since you could spend outputs that had been donated to both addresses before destroying the key for the eventuality that didn't happen.