Thanks for your patience in letting me check this through with you, I really appreciate it guys.

Now talking only about Multisig:

The Multisig script in a transaction output contains a series of values which must be satisfied, one per signatory. Are these just the public keys of the signatories?

If so is there a way for a malicious signatory to change the order or value of these private keys if say there were two inputs to this transaction which two spate parties needed to sign?

Edit for clarification: that is to say could one party sign to release the first input, modify the transaction and then pass it to the second party to sign and release the second input.

I've had a look around but can't find a definitive answer to my previous question.

Talking only about P2SH:

I understand that this is a hash of the script which needs to evaluate to True when run and is provided in the input of the transaction that spends it.

Is this input script stored in full in the input of the transaction which spends it when the transaction is mined to the blockchain?

In the case where OP_CHECKMULTISIG is used in the script are all the public keys and Scriptsigs stored in the input of the new transaction?

I also take it a transaction with one or more P2SH inputs that has one or more P2SH outputs is standard? Assuming each script is below 1,650 bytes and the total transaction is below 100,000 bytes.

Ah, I didn't realise that. Is the public key stored 'as is' or is it a shortened or hashed version of it the public key?

If it's not shortened is it provided in full for all to see that the new transaction spending that output is valid?

Thanks, can I also check I've got this right:

When the transaction is stored on the blockchain, the Scriptpubkey script which contains the address is stored as the conditions to satisfy to use the output.

The Scriptsig and public key are not stored on the blockchain.

Scriptpubkey is an actual script, stored on the blockchain that is the condition required (to evaluate as 'True') to be able to spend that output to another transaction's output(s), with one script per output.

So to confirm I've got the logic of this and the dependencies correct:

Scriptsig is the signature which unlocks Scriptpubkey where Scriptpubkey is the output of a given transaction which must be satisfied to be spendable to a new output.

Am I right in thinking that Scriptsig is the private key signing over the (entire?) transaction which can then be verified by the public key?

And the public key can be verified as it matches a hash of the previous transaction's output (the Bitcoin address)?

Both the public key and Scriptsig are sent with the new transaction.

Therefore the above dependencies prove the person who broadcast the new transaction has possession of the private key for the output of the previous transaction.

Thanks for all the help here.

I'm going to have a think and re-word an attempt at getting this correct so I can confirm I understand it. It may be tomorrow though.

Ah, I did not quiet understand. So in the above example you are already assuming I have the public keys. If so I now get this.


By 'provide' here do you mean that they provide separate signatures to 'spend' each of the two outputs to this new transaction?


Ok, so they would both need to see the script and verify the P2SH address which is the output of the new transaction is from that script and those public keys. I assume they would do this before signing their respective inputs? Where one would have to sign, then pass the transaction on to the other to then sign the second input and broadcast? Hope I have this correct now?

Thanks for taking the time to explain this.

So talking specifically about P2SH if I have the public keys for all the signatories I need (say 3 public keys) this is all the information I need to generate the P2SH address, where I can specify m <= 3 and n as >= 1 but <=3?

Thanks,

So to rectify the last example I gave the first and second person would get the 4 escrow to sign the output P2SH script first. Then the first person would sign the first input and P2SH output, then then second person would sign the second input and P2SH output and broadcast the TX.

That way there is no risk of the escrow broadcasting the TX early. (Edit: and rendering the funds un-spendable)

Have I understood this correctly now?

Thanks for this.

I'm talking more specifically in a scenario where a number of parties are collating funds to a single P2SH address.

To give another example two people are trusting 4 separate escrow to look after their funds, so the first person creates a Transaction with 2 inputs (one for each person depositing the money) and one P2SH output. The first person then signs the first input and the P2SH output script and passes it to the second person who does the same. The second person then passes it to the first escrow.

In this scenario we must assume that we cannot fully trust any of the escrow who need  to sign in sequence. Therefore what is to stop the any of these escrow from signing the transaction's output P2SH and then broadcasting it early excluding the other escrow from signing? E.g. if the first escrow broadcasts then could they create an 3-of-3 instead of the intended 6-of-6?

I'm currently under the impression this would not be possible because it is enforced by the script which was created by the first person as 6-of-6?

I'm not sure if this is a suitable use-case however as I understand P2SH requires proof to spend the output, but I'm not sure about enforcing that the output validates as true before it is mined to a block.

For a P2SH transaction does the script specify how many signatures are required for the 'n' of m-of-n?

For example, if 6 people agree to set up a 6-of-6 P2SH transaction and sign it in sequence, where Person A is the first to sign and Person F is the last to sign. Does Person A who creates the P2SH script specify in the script that 6 People have to sign?

I.e. could Person E sign and broadcast the P2SH transaction, missing out Person F and making the transaction 5-of-5?

Great. That's what I thought but was getting worried something I could not see may have changed.

Thanks again DeathAndTaxes.

I've just found a few posts saying nLockTime is not supported dated for around 2013 (here is one example), but according to this thread the above is true. Can I confirm that this is still the case?

Thanks.

There was a lot of news about how transaction malleability had been fixed in Bitcoin Core 0.8/0.9 did this not resolve transaction malleability? Or are you saying one cannot assume that all nodes on the network are conforming to not causing transaction malleability when relaying transactions?

Just moved some coins I had on the site for a short period to try and trade them over. When I went to withdraw the site went down (502). Not sure if it was something I did .

Update: to Vircurex's credit the site was back up within a few minutes and I withdrew with no issues.

Thanks.

Using P2SH multisig is there a way to create a script which enforces who the recipient will be?

I.e. if you had two parties who had locked funds up under a 4-of-6 escrow, where the two parties are not the signatories required to release the funds and any four of the six escrow could sign to release to either party. Could the script be set up such that it can only be released to party 1 or 2. Because under this scheme four of the escrow could conspire to send the funds to an address other than one of the party address?

Ok, registered as 'No_2' and have placed a bet.

Am registered, will place a bet and give this a try.

Thanks a lot for all the help today. Got my MSDs done for now.