I think what Dexx is getting it is allowing a sequence of Master Protocol packets anywhere in the multisig outputs, as long as the packets are contiguous. I'm not sure that's necessary at this stage (I think if we're to lock in packet ordering then let's keep it simple). Also re 1-of-3, yep I know technically we can go higher but not while maintaining widespread support. My own view is that we'll see OP_RETURN before better native multisig handling in the reference client, but that's pure speculation of course.Dexx, I know you posted an analysis a few pages back but could you pick say two or three transactions, post them & a brief summary on why you think they're invalid/contain junk. Happy to take a look

I guess I'd like to hear the other devs comment about these packets with "junk" in them which are there already. Can you point a couple of them out? I'd like to know what logic currently makes them valid. That is what will probably end up in the spec, just to avoid changing anything.

Advertisedsites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Ad vertise here.

1. Ok will enforce the req minimum fees require for purchase accept. 2. I think it should be. A buyer can place only one purchase offer transaction on any sell offer transaction.

Thanks. Yes and I agree, keeping it as simple as possible, would be good.Okay, I'll try to cover a few cases I found:1. https://blockchain.info/tx/bda81e0c2117fb6ecefb92143995a6ebc3d9569f54c4a0c074ff3070bcf3e011 Input: compressed public keyOutput: compressed input public key, data-package #1, data-package #2No conflict.2. https://blockchain.info/tx/95b10a4721a69a1028e70fd2ccd0692219095fb6f5087b9e72b155a3e0832602 Input: uncompressed public keyOutput: uncompressed public key, data package #1Conflict: "Has one or more 1-of-n OP_CHECKMULTISIG outputs each containingpublic keys, one of which must be the senders address" (has only one compressed public key)3. https://blockchain.info/tx/f8e2eb56f50f7a98a8c76ef45ed591aedd8aa973c5f4dfd5b7685aae4b48ae6c Input: uncompressed public keyOutput: compressed public key, data package #1Public key was compressed, but that's no conflict.4. https://blockchain.info/tx/4842af86dac35a2c294f56511c7d08362330e82bd5fcae32c07119844e019b0a Input: uncompresssed public keyOutput: compressed public key with flawed prefix byte, data package #1Conflict: "As one signatory must be the sender forpurposes, ...""Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys," (not the case, because of a small flaw during the compression [prefix "02" instead of "03"], so this output is neither redeemable nor the sender's address)5. https://blockchain.info/tx/2ae17011888e9a2e6c752999774cd6d88feb7c0751abe72a602be89858e44f6a Input: compressed public keyOutput: unknown package, data package #1Conflict: "As one signatory must be the sender forpurposes, ...""Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys," (not the case, because the first package has no relation to the input address)6. https://blockchain.info/tx/1ce1e44f40da1f7eddca5f81d72d76a005f8f45b83ee1f9b07ca901f3e6ec235 Input: uncompressed public keyOutput: data package #1, compressed public keyThis is an edge case. All data packages are ordered (it's only one) and it includes the sender's address.

I think what Dexx is getting it is allowing a sequence of Master Protocol packets anywhere in the multisig outputs, as long as the packets are contiguous. I'm not sure that's necessary at this stage (I think if we're to lock in packet ordering then let's keep it simple). Also re 1-of-3, yep I know technically we can go higher but not while maintaining widespread support. My own view is that we'll see OP_RETURN before better native multisig handling in the reference client, but that's pure speculation of course.Dexx, I know you posted an analysis a few pages back but could you pick say two or three transactions, post them & a brief summary on why you think they're invalid/contain junk. Happy to take a look