Move Mastercoin Protocol to P2SH

[ripper234]

This is important for exchanges using cold storage. @dacoinminster when can we schedule this?

[dacoinminster]

This is an interesting feature which we will have to do carefully, especially since we already found an exploit which was blocked by our NOT allowing multi-sig. I'm also thinking that simply implementing our savings address feature might be a better use of our time. I think this needs some further discussion, especially in regards to what functionality the exchanges need.

Have you spoken to exchanges about this topic? If so, what have they said? If they want multi-sig, I'd like to understand the use-cases for how they want to use it. (For instance, how does multi-sig help with cold-storage?)

On Thu, Mar 20, 2014 at 2:25 AM, Ron Gross notifications@github.com wrote:

This is important for exchanges using cold storage. @dacoinminsterhttps://github.com/dacoinminsterwhen can we schedule this?

Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/85#issuecomment-38147667 .

[ripper234]

I have asked the exchange developers to comment here.

[ripper234]

cant provide an estimate, I can only say it will happen in several months. We will use it for stronger security of cold storage. When it does I hope mastercoin will support this.

J.R please take this into consideration when prioritizing this issue.

[dexX7]

@ripper234: are you referring to P2SH addresses (BIP 16)? That are those starting with a 3. At least recognizing transactions which use them should be more or less easy with zathras' library., e.g. 3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC sends 50 MSC to X or vice versa. 3QJ.. is a multisig P2SH address which can be accessed, if 2-of-3 participants sign the transaction. (see example from Gavin)

Allowing them is not a risk and they differ from standard multisig transactions which we use for encoding.

Including them in the wallets, e.g. "user creates 2-of-3 multisig wallet" is a whole different topic though and probably needs very much work.

[ripper234]

I'm not familiar enough with the details - which multisig addresses are not P2SH addresses? Basically yes though - I want the parsing/state engines to recognize transactions to/from multisig/P2SH addresses.

[dexX7]

I reviewed P2SH transactions again and came to the conclusion this is not feasibleat the moment without making significant adjustments due to the very different transaction structure.

https://blockchain.info/tx-index/53761687/1 (simple send to P2SH 1-of-5 multisig [theoretical]) https://blockchain.info/tx-index/53670893/0 (simple send to pubKeyHash [valid])

Redeeming P2SH (1-of-5 multisig): https://blockchain.info/tx-index/53775008

Using standard multisig transactions is also not practial due to the ambiguousness of inputs and reference outputs. Unless this is high priority I suggest to postpone this feature.

[dacoinminster]

Very interesting experiment. I think we are planning to postpone this due to Peter's other comments, but I am curious: what's so bad about the 2-step simple-send experiment you did? The data was successfully encoded, yes?

On Wed, Apr 2, 2014 at 1:08 PM, dexX7 notifications@github.com wrote:

I reviewed P2SH transactions again and came to the conclusion this is not feasibleat the moment without making significant adjustments due to the very different transaction structure.

https://blockchain.info/tx-index/53761687/1 (simple send to P2SH 1-of-5 multisig [theoretical]) https://blockchain.info/tx-index/53670893/0 (simple send to pubKeyHash [valid])

Redeeming P2SH (1-of-5 multisig): https://blockchain.info/tx-index/53775008

Using standard multisig transactions is also not practial due to the ambiguousness of inputs and reference outputs. Unless this is high priority I suggest to postpone this feature.

Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/85#issuecomment-39377137 .

[dexX7]

Yes, the data was correct.

Short: the current implementations don't recognize the P2SH address as "receiver" and it's also not possible at the moment to use a P2SH address as "sender".

Long: a regular output to the receiver has the following form:

OP_DUP OP_HASH160 [hash of public key of receiver] OP_EQUALVERIFY OP_CHECKSIG 

An output to a P2SH address does not simply use an address starting with another character (3 instead of 1), but has another form:

OP_HASH160 [hash of redeem script of receiver] OP_EQUAL 

It would be required to add a new parsing path to recognize this pattern.

The input of a regular transaction looks like this:

[signature] [sender's public key]

And in a P2SH multisig transaction the input looks like this:

[empty] [signature(s)] >|[number of signatures required] [public key 1] [public key 2] ... [public key n] [n participants]|< OP_CHECKMULTISIG

The part between the >|...|< is the "redeem script" and hashing and base58 encoding the redeem script returns the address (3Qv6...). We could extract the redeem script from the input to derive the address which then could be used as "input reference" for the Mastercoin transaction.

Another issue: the multisig output part of a class B transaction looks like this:

[1 signature required] [sender's public key] [data package 1] [data package 2] [3 participants] OP_CHECKMULTISIG

Because there is no public key related to a P2SH address (3Qv6..), a workaround would be required: one could use a public key of one of the multisig participants for example.

To summarize: it's possible, but I think it's safer to implement this on all wallets after the SP launch.

Nevertheless this may pave a the way for a P2SH encoding which was mentioned during the OP_RETURN discussion. If you like, please visit https://coinb.in/multisig/ - "Verify" and paste the following redeem script to see what this actually is:

512103d44511bc546df26bc6bda4fd6ecc29d85b7ce997b886697e1e0ef29d109b40cd21022c162480f24f9756a251ab8b102b1410f15db86eafdb571adf6bcb4a87d0a601210251a0b96e7a105dcb219ce7ec9c1a9aa0c36fcd85f3788262eef6edddea1c64bf2102053b4d4ebd81e88040d24b22a62ace8918e1e04fb0b292e86912fa41f86d61aa21028adc20e0116e4e0df892aa57f62c333a063739f45c653e33cf7f2b48f18f3c7555ae

:)

[dacoinminster]

Yeah, I don't think anybody was contemplating a change like this before the SP launch :)

So, could mastercoin-on-P2SH simply specify that the first multi-sig address is always the sender, and the second multi-sig address is always the "reference address" (the receiver, in case of simple-send)? The public key of the sender would then be the one used to sign the transaction to prove it really came from the sender . . .

I apologize if I'm misunderstanding something here!

On Wed, Apr 2, 2014 at 5:07 PM, dexX7 notifications@github.com wrote:

Short: the current implementations don't recognize the P2SH address as "receiver" and it's also not possible at the moment to use a P2SH address as "sender".

Long: a regular output to the receiver has the following form:

OP_DUP OP_HASH160 [hash of public key of receiver] OP_EQUALVERIFY OP_CHECKSIG

An output to a P2SH address does not simply use an address starting with another character (3 instead of 1), but has another form:

OP_HASH160 [hash of redeem script of receiver] OP_EQUAL

It would be required to add a new parsing path to recognize this pattern.

The input of a regular transaction looks like this:

[signature over the output which is spent] [sender's public key]

And in a P2SH multisig transaction the input looks like this:

[empty] [signature(s)] >|[number of signatures required] [public key 1] [public key 2] ... [public key n] [n participants]|< OP_CHECKMULTISIG

The part between the >|...|< is the "redeem script" and hashing and base58 encoding the redeem script returns the address (3Qv6...). We could extract the redeem script from the input to derive the address which then could be used as "input reference" for the Mastercoin transaction.

Another issue: the multisig output part of a class B transaction looks like this:

[1 signature required] [sender's public key] [data package 1] [data package 2] [3 participants] OP_CHECKMULTISIG

Because there is no public key related to a P2SH address (3Qv6..), a workaround would be required: one could use a public key of one of the multisig participants for example.

To summarize: it's possible, but I think it's safer to implement this on all wallets after the SP launch.

Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/85#issuecomment-39399210 .

[dexX7]

No, you got it almost right! :) One must provide a public keys (02... 03...) for the multisig, but a receiver reference is actually the hash of a public key (1EXo..). Because we can't un-hash the address and we usually don't know the public key, we'd need to sneak the address somehow into a public key -- for the sake of an example:

Receiver address: 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
Hex of this address: 946cb2e08075bcbaf157e47bcb67eb2b2339d242
Public key: 020000946cb2e08075bcbaf157e47bcb67eb2b2339d2420000000000000000000a

[dacoinminster]

Ah! So the main difference is that there are no standard bitcoin addresses anywhere in these P2SH message, but we can put whatever bytes we want into the public keys, so we can hide any bitcoin addresses in those bytes?

The main thing we'd lose (I think) is the output to the recipient, which means that nothing would happen at all on the recipient's bitcoin-only wallet, and further, the recipient couldn't use that output to immediately send another MSC transaction that is dependent on the transaction they received (by including the dust they received). Instead, they have to wait for sufficient confirmations.

I think we can live with that. But as we've agreed, no hurry on this. I'm just glad we have a plan.

Thanks for looking into this!!

On Wed, Apr 2, 2014 at 6:32 PM, dexX7 notifications@github.com wrote:

No, you got it almost right! :) One must provide a public keys (02... 03...) for the multisig, but a receiver reference is actually the hash of a public key (1EXo..). Because we can't un-hash the address and we usually don't know the public key, we'd need to sneak the address somehow into a public key -- for the sake of an example:

Receiver address: 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P Hex of this address: 946cb2ehttps://github.com/mastercoin-MSC/spec/commit/946cb2e08075bcbaf157e47bcb67eb2b2339d242 Constructed public key: 020000946cb2e08075bcbaf157e47bcb67eb2b2339d2420000000000000000000a

Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/85#issuecomment-39403871 .

[dacoinminster]

I'm broadening this issue to include everything regarding moving to P2SH (anti-censorship concerns, etc) as well as the multi-sig issue that started the conversation

[ripper234]

Can someone @petertodd @dacoinminster @CraigSellars can a rough ETA on when we can support some form of multisig?

Is it reasonable to have it in Q4 2014, or only in Q1 2015?

Context

I assume blockpop will support that, hopefully we can migrate to blockpop on Q1 2015.

[dacoinminster]

No idea. Also, I have yet to see a nice UI for n-of-m multisig.

On Thu, Jun 26, 2014 at 7:14 AM, Ron Gross notifications@github.com wrote:

Can someone @petertodd https://github.com/petertodd @dacoinminster https://github.com/dacoinminster @CraigSellars https://github.com/CraigSellars can a rough ETA on when we can support some form of multisig?

Is it reasonable to have it in Q4 2014, or only in Q1 2015?

Context https://docs.google.com/spreadsheets/d/1FdxxnujeMb_1kWlz1Esqut_jmmWNicbS3Meh1F83tUo/edit#gid=0 )

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/85#issuecomment-47230631.

[LOLLOLOOLOL]

Have you seen Armory lockboxes? I wouldn't say the ui is beautiful by any means, but it's definitely functional. On Jun 26, 2014 10:34 AM, "dacoinminster" notifications@github.com wrote:

No idea. Also, I have yet to see a nice UI for n-of-m multisig.

On Thu, Jun 26, 2014 at 7:14 AM, Ron Gross notifications@github.com wrote:

Can someone @petertodd https://github.com/petertodd @dacoinminster https://github.com/dacoinminster @CraigSellars https://github.com/CraigSellars can a rough ETA on when we can support some form of multisig?

Is it reasonable to have it in Q4 2014, or only in Q1 2015?

Context < https://docs.google.com/spreadsheets/d/1FdxxnujeMb_1kWlz1Esqut_jmmWNicbS3Meh1F83tUo/edit#gid=0>

)

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/85#issuecomment-47230631.

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/85#issuecomment-47255278.

[ABISprotocol]

@LOLLOLOOLOL @dacoinminster @ripper234 @dexX7 Just as a background note and remark, see some ruminations on this subject ~ which may provide some possible leads and helpful connections ~ here and also at here. The bitcointalk posts referenced there may be helpful for review (and have some comments from @dexX7 as well). Note: I've just tested with two parties, (myself and someone else), no mediators. I like the concept though, it's good.

[LOLLOLOOLOL]

IMO the Copay wallet by Bitpay is pretty revolutionary as far as multisig/P2SH wallets go. Good UI, communications between signers, and open source. Could this be leveraged to support Master Protocol transactions?

https://github.com/bitpay/copay/

https://copay.io/

[petertodd]

@ripper234 blockpop is certainly compatible with P2SH. That said, don't think in terms of P2SH, think in terms of moving to a scriptPubKey model - we don't want to have to upgrade all over again when P2SH v2 comes out.

I'd do this by changing everything that refers to an address in the code to use H(scriptPubKey) instead. This really shouldn't be a big deal other than requiring a one-time-reindex. Beyond that just make sure the UI consistently does sane things when presented with P2SH, as well as scriptPubKey formats that it doesn't recognize.

And yeah, Copay is really cool!