Feature request: relax input and output requirements, P2SH

[dexX7]

In the context of the following lines:

Has a single or the largest pay-to-pubkey-hash input by sum 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

Those requirements were introduced at some point to bring consensus without affecting history.

I'd like to propose the following:

1. Don't invalidate transactions with other input types. This is a low hanging fruit, given that there are very specific rules in place to determine the sender ("highest contribution by sum").
2. Consider pay-to-script-hash outputs as reference output.

This could be introduced at some block height in the future, because it would affect history otherwise.

The benefits of allowing any input type are far greater than P2SH, but the focus of this issue is to lay out a basis to support P2SH (escrow) recipients and senders.

[ripper234]

+1 important.

[dexX7]

Given the recent comments related to this topic:

m21 commented 10 days ago:
Spec guidance needed.

m21 commented 3 hours ago:
Once architecture on this issue appears in the spec -- will schedule for implementation.

@marv-engine, @dacoinminster: what's your opinion about this topic?

[dacoinminster]

I think it's worth experimenting with this on the test system. Not sure where it fits in priorities though.

[ripper234]

I think it is within the new roadmap that @DavidJohnstonCEO published. It's quite useful for exchanges and people wishing to keep Master Protocol currencies secure.

[petertodd]

BTW you may be interested in the work Counterparty is doing with this stuff: https://github.com/CounterpartyXCP/counterpartyd/compare/multisig

My suggestion to them was to go with a direct scriptPubKey-based scheme; they've implemented fixed-format multisig as a new address type basically.

[dexX7]

Well.. there are quite a few things they do quite well, also related to smart property issuance. It's not that those techniques are unknown or groundbreaking and CHA defines currently the top position related to plain multisig data encoding, whereby @grazcoin ironically labeled this approach as MIP 1 (Mastercoin Improvement Proposal 1). -- That just as a sidenote and unrelated to P2SH.

---

I'm curious and I quickly looked over the code, but couldn't find an answer on the first glimpse. Our class B transactions are basically build this way:

In:
Vin  0  pay-from-pubkey-hash:    [Sender]                    (input)
Out:
Vout 0  pay-to-pubkey-hash:      [Exodus]                    (marker)
Vout 1  pay-to-m-of-n-multisig:  [Sender] [Data 1] [Data 2]  (data)
Vout 2  pay-to-pubkey-hash:      [Receiver]                  (reference)
Vout 3  pay-to-pubkey-hash:      [Sender]                    (change)

And let's assume we combine P2SH sender and receiver with plain multisig as medium to transport data, then this would result in something like:

In:
Vin  0  pay-from-script-hash:    [Sender]                    (input)
Out:
Vout 0  pay-to-pubkey-hash:      [Exodus]                    (marker)
Vout 1  pay-to-m-of-n-multisig:  [??????] [Data 1] [Data 2]  (data)
Vout 2  pay-to-script-hash:      [Receiver]                  (reference)
Vout 3  pay-to-script-hash:      [Sender]                    (change)

We fill the first slot of the m-of-n package with the sender's public key for redemption purposes and anything else would be a step backwards imho, given >80 % unredeemed multisig outputs, so what the best approach here and (@petertodd) how does XCP handle this? There are of course a few options, such as using one of the keys derived from the script-hash, an unrelated pubkey or maybe even the one related to Exodus, but still I'm wondering, what the best practise would be here, since we should stick to a pattern, if we do it.

---

@dacoinminster: the first sort-of "test" was done before we even prohibited P2SH in the first place:
https://blockchain.info/tx/1c69dfee55768695a2c890bfb561c9651bdd1d243b0d536e8a3503c7701d4fab

But I assume you meant an integration in Mastercore + live usage on testnet instead of simply constructing those transactions. @m21 mentioned above he needs spec guidance, so this is sort-of a chicken-and-egg issue. Frankly said, I rather don't want to mess with the current MC codebase where encoding/decoding is a bit all-over-the-place. I outlined in the first post what I think would be a solution to create the basis for any P2SH implementation (as well as support for oracles), but unfortunally that's all I'm able to do at the very moment. Gener and David probably already hate me for delays that I cause in a different project, but I simply can't help it at the moment. Once that's over (soon), I can of course take my own shot at this, whether that involves formalizing what I wrote above, code for MC or an external tool for the purpose of a demonstration.

[dexX7]

Partly solved by #246.

[eflorent2020]

Please help: suppose Martin sent an Omni Asset (MaidCoin or TetherUSD) to a bitcoin address created for multisig (keys are owned by Bob and Alice). Is there a way to spend the asset or is it definitly burnt ? Bob and Alice are willing to help/spend but they know they can't import two keys in Omniwallet. Token is actually burn ? Guidance on how to use omni-core cli ?

[dexX7]

Hi @emmanuel-florent,

sending and receiving assets from P2SH/multisig is possible, and the tokens are not burned.

However, there is currently not a very handy way to do so. If you have all keys imported to Omni Core, then you should be able to send via the UI, but you can also use the CLI (e.g. with omni_send or by crafting a raw transaction).

If using Omni Core is currently not an option for you, please feel free to provide me with further information; I should be able to craft a raw transaction in the next days, which could then be signed by all parties. Do you have access to all keys?

[eflorent2020]

Ok so there is no impossibility at the protocol level so it's a nobility.
Unfortunatly I didn't find a lot of answer/documentation some maybe I can write some ?

1/ First need to setup like explained in Omnicore Readme is that it ?

2/ build a rawtransaction ? not sure how to do it ?
Holding address
Want to spend to 1CvGqy3fEL6pAYWjQb6f7ca9kUSmwXFSHy
Token ID 31.
3/ Instructions for Alice and/or Bob to broadcast a minable valid asset ownership change ?
(ex: Alice send Private key to Bob is acceptable in that case)
Thanks a lot, I'll try yo write the how-to as Alice asked for.

[dexX7]

Hey @emmanuel-florent,

there is a discussion about a related topic in this thread, which you may check out:

OmniLayer/omniwallet#1314