1

Is it possible in Ethereum to issue multi-sig transactions which are not implemented on smart contract level but instead via signing, similar to Bitcoin?

The following would be an example of a multi-sig transaction - might work in practice differently, just for sake of argument:

signature1 = sign(privateKey1, message);
signature2 = sign(privateKey2, signature2);

Background + Motivation: I am doing a thought experiment whether or not it makes sense to block transactions that have code associated (instead of being private key-controlled). E.g.: If one issued a centralized-fiat-token and wants to ensure KYC-compliance, one might want to only allow these centralized-fiat-token to be sendable to and from KYC-approved addresses. However, these addresses could actually be controlling a multi-sig wallet or even be a proxy contract that gives other non-KYC-compliant parties access to these tokens. To prevent that, one could limit transferrability to only approved addresses that do not have any associated code.

[This is obviously a bad idea because, 1) e.g. the mist wallet is/was a code-controlled wallet and as such be locked-out, 2) I might want to move funds to another account that I control myself, without undergoing (parts of) the KYC procedure again.]

If we could show that multi-sig transactions are anyway possible even without code in multi-private-key scenarios, then the whole argumentation of blocking code-controlled addresses would break down.

1

Your intuition is correct and it's easy to make a proof-of-concept, although it has some limitations.

A and B want shared access to funds so they both have to sign to spend them.

A and B each make their own private key. They exchange hashes of their public keys (*), then the actual public keys.

They add their public keys together using ECC addition. You can do this with pybitcointools. This creates a new public key. They make this into an address.

They send money to the address (or do whatever they're trying to do).

To spend the money, A sends their private key to B, who adds to private keys together to make the private key of the public key they made earlier. A spends the money.

(*) I think you can do ECC multiplication instead of addition and avoid this step, but I'd have to check it works the way I think it does.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.