Topic: Modify OP_CHECKSIG (Read 1253 times)

Yep you're right.  Standardize them as proposed, I say...

I think we're promoting slightly different things here.  My only point is that this OP_CHECKSIG modification has some "different" behaviors than a "standard" multi-signature transaction, and thus, we should work for both to be supported as "standard" scripts.   I really like your idea, and fully support getting into the client design.  But I don't think it precludes us from having to answer Gavin's post about how to standardize multi-signature scripts that are currently possible without your modification.

For those other multi-sig uses you mention, these are already possible without a change to OP_CHECKSIG, and would not be inhibited by such a change.

Changing OP_CHECKSIG would allow normal people to send normal transactions that require 2-of-3's or similar schemes to unlock.  This would be for the receiver's security, so he can leave his client offline and his coins are already protected without him having to manually resend them to a 2-of-3 scheme (which would require him to stay online).

On the other hand, if the sender of the transaction is trying to join a 2-of-3 scheme on purpose, he can simply emit a transaction that contains the script with all three of the addresses.

There's more uses to the multi-sig functionality than just what you're talking about.  I always think of a 2-of-3 transaction online, where the buyer puts 110%*purchase price into such a 2-of-3 transaction between seller, buyer and third-party.  When the goods arrive and the purchase is complete, both buyer and seller offer their signatures to give the 100% of purchase prices to the seller, and return 10% to the buyer.  If there is any dispute, no one gets the money until it is resolved.  If one of the parties is too stubborn or disappears, the other party can appeal to the third-party to get their signature, and give them the 10% for arbitrating.

In this case, the buyer created the 2-of-3 tx with two other parties, but the other two parties don't know about it until the buyer explicitly tells them.  I still like the idea, I was just commenting that it adds an extra step if you want all the other parties to know that they're involved.

-Eto

The way I see it, of those three parties, two of them are yourself, and the third one is your "wallet security provider".  Each address will have been generated in a short ceremonial webservice exchange between the two said parties, and so should be recognized by both parties.  See the example I posted at https://bitcointalksearch.org/topic/m.477009 .

In a scenario where we use "(A AND B) OR C", parties A and C are both yourself, the user.  A is a private key on your hard drive, C is your private key you keep in your safe as a recovery tool, and B is a keypair whose private key is known only by your wallet security provider and which will only sign transactions when authorized by you (preferably "out-of-band" e.g. SMS).

So, JimBob is running this safe Bitcoin client and is configured to use the wallet security provider YourBitcoin.com.  When he clicks Generate Address, his client makes a webservice call to YourBitcoin, providing public keys for A and C.  YourBitcoin.com returns a newly generated public key B, and with that, both parties can calculate the resulting "safe" Bitcoin address.

+1 for this idea. 

I have no comments about integration, release, and not forking the blockchain, in general.

The only concern is that other parties have no other way to know they are part of a particular transaction unless you send them the serialized string and the transaction hash.  They can see the string includes their address in the appropriate place and that it hashes to the "address" in the specified transaction.  This creates an extra step to "executing" a transaction, as it's not really complete until all parties are notified by the original sender about.

Of course, people don't have to use it. I do like this as an option.

-Eto

I was thinking recently that it might be a good idea to write the code for all of the proposed (and agreed-upon) changes to Bitcoin's core structure and put them in place, but keep them disabled until a transaction version increase is forced by some critical bugfix.

An enhanced version of OP_CHECKSIG could also specify which hash algorithm is used for hashing the transaction before signing.

Because I want to enable these features reasonably soon, and modifying the way CHECKSIG works means a blockchain fork for clients that haven't upgraded.  Which means giving at least 6 months notice to give everybody time to upgrade their clients.

At some point that will make sense, but with what I'm proposing it is not necessary. When SHA3 is finalized or a weakness is found in ECDSA or SHA256 maybe it'll be time to do that...

Here is an idea: why not just modify the OP_CHECKSIG (which currently checks a single signature) so it itself supported multiple signatures that could be joined with logic?

Right now, we take the HASH160 of a single pubkey A to match the address, and OP_CHECKSIG matches that pubkey A to signature A.

What if OP_CHECKSIG were enhanced so that what we provide as A, could also be a binary-serialized expression?  Right now, you input A and a valid signature for A, and get true.  With enhancement, into OP_CHECKSIG you input "(A AND B) OR C", and three signatures A B C (which aren't more parameters, they are merely more bytes stuffed into the same parameters via binary serialization).  Not all three signatures have to be valid, just enough have to be valid to make the expression evaluate to true.  Of course, pubkey "A" by itself is still a valid expression, one which validates only with a valid signature for A, and which is what is considered a standard transaction today.

Since a bitcoin address is based on what amounts to HASH160(A), with this modification you could have a normal-looking Bitcoin address based on the entire expression, since it would merely be HASH160 of the binary serialization of the expression.  There would be no need to bloat the addresses or introduce a new format.

The sender would know no different.  The sender's script would be exactly the same.  The only difference is the bitcoin address is based on the hash of a multi-pubkey expression rather than a single pubkey.  The spender would need to provide the entire original expression and just enough signatures to satisfy it.  Voila.