Support multisig recipients on simple send

[ripper234]

I would like to send MSC-derived currencies to proper multisig recipients (regardless of Class A/B/C encoding) ... proper m-of-n Bitcoin style multisig where multiple signatures are needed to release the MSC.

[dexX7]

+1

Those restrictions are currently in place to disallow multisig usage though:

Has a single or the largest pay-to-pubkey-hash input signed by the sending address

Any input not meeting the requirement for type (pay-to-pubkeyhash) will trigger the invalidation of the transaction

Only pay-to-pubkey-hash outputs will be considered for the reference address

And for the special case, if you are referring to true m-of-n instead of P2SH (addresses with a 3), then this may interfere with data packages and clients may assume this m-of-n output is actually data.

Actually this is a good example in favor of output bound sends vs. address based.

[LOLLOLOOLOL]

Actually this is a good example in favor of output bound sends vs. address based.

The output model can treat all inputs the same without regard to source and all outputs the same without regard to destination (at least in terms of the form of a transaction).

Also, I'm not currently aware of any Mastercoin feature that would inherently be impossible if the Master Protocol were to adopt this model. Keep in mind that the discussions I've had on this model pertain to my own ideas of best practices and requirements of a protocol layer. These ideas are not necessarily shared - thus my prior discussions may not serve to establish a case of applicability for Mastercoin.

[ripper234]

See #189

[dexX7]

I created two (untested) pull requests for mastercoin-tools and the Masterchest library to add passive P2SH support. It's yet another topic how P2SH based Mastercoin transactions are created, but the ability to understand such transactions should be distributed before users start to use this feature on a broader scale.

A small problem I see: we store a public key of the sender as first recipient in the m-of-n class B multisig output for redemption purposes, but public keys can't directly be derived from scripts. We could address this by letting the user chose which public key he likes to use or we could use a filler, e.g. the public key associated with the Exodus address.

https://github.com/zathras-crypto/masterchest-library/pull/5
mastercoin-MSC/mastercoin-tools#66

I set the block height at which P2SH is supported to 306000 which is in about a week. Is this feasible?

[zathras-crypto]

In principle I'm against devoting development resources to this unless the foundation prioritizes above existing work on Core, as the timeframes expressed in the last dev sync are already extremely difficult to achieve (we agreed a 6-8 week timeframe to build Master Core to the level of existing implementations which is about mid July, then there is the expectation that we somehow deliver a feature as complex as Meta DEx ready for live on 31 July (just 2 weeks later) which is already turning smiley faces upside down).

With that said, the pull you have submitted (at first glance) would remove the artificial limitations I put in for 'Chest to block P2SH - if we're going to do it I suggest the way to go is to keep them invalid to spec, and run up test sites of Chest.info & Omni that do support P2SH and fling a few TMSC transactions around. The prod implementations will drop them, whilst the test implementations will honour them and we can analyse behaviour.

Honestly not trying to be negative on this, more than happy to work towards this goal, but I am trying to drag the Core project kicking and screaming to the deadlines the foundation is looking for, and am conscious of diverting resources away from that.

Thanks as always DexX :)
Zathras

[ripper234]

Nobody said this is high priority.
@zathras-crypto everything you know in the immediate timetable is higher priority than this.

When in doubt, consult the roadmap or Craig/myself.

[zathras-crypto]

Hey Ron, gotcha, thanks. FYI my concern around timetables stemmed from the timelines in the pull requests (which make P2SH live within a matter of days) - I'm way behind on some of the discussion so perhaps incorrectly assumed priority.

Thanks
Zathras

[dexX7]

Ahh sorry, not wanted to create any pressure. The block height was chosen almost arbitrarily.

[ripper234]

Don't get me wrong - this is an important feature and I want it done "ASAP".
However our other "ASAPs" are more important right now.

On Mon, Jun 9, 2014 at 11:34 AM, dexX7 notifications@github.com wrote:

Ahh sorry, not wanted to create any pressure. The block height was chosen
almost arbitrarily.

—
Reply to this email directly or view it on GitHub
#194 (comment).

Ron Gross
Executive Director, Mastercoin Foundation
mastercoin.org | ripper234.com | ripper234 on skype (Inbox != Zero
http://ripper234.com/p/how-i-learned-to-let-go-of-inbox-zero/) | PGP
http://pgp.mit.edu/pks/lookup?op=vindex&search=0x7468729E28277264
Schedule my time at meetme.so/RonGross

[dexX7]

Currently only inputs which were pay-to-pubkey-hash outputs are allowed and any occurence of something else completely invalidates the transaction. This rule was introduced to invalidate P2SH transactions which caused consensus issues between the different implementations.

Since this issue is exactly about enabling P2SH, I think we should not start to whitelist different kinds of inputs, but rather remove the input restriction altogether - at some agreed upon block height in the future. This reduces complexity at no cost and is risk free, because the feature (P2SH + input freedom) is enabled at a given height and therefore has no impact on historical transactions.