Welcome to the discussion about this section. Here you can ask questions or post feedback about this specific lecture.
Is there not a video intro for this section? âAdvanced Bitcoin Scripting (P2SH)â
@filip, thereâs nothing to watch or read on the Introduction section, why does this section exist?
Also, why did we get so far without any practice assignments? Canât we put in practice on regtest mode what we learned so far?
1 Like
Thank you for the work. I learned a lot today!
I think there was a mistake at Pay-To-Script-Hash Transaction Part 2 - How to Redeem at around minute 8.
You said, that the number 2 on the stack would indicate that there are 2 signatures coming and thus OP_MULTISIG would pop/drop the next 2 elements from the stack.
I think the number 2 indicates, that at least 2 signatures (M) must match to verify against the given pubkeys (N) for the particular multisig transaction and thus the function will simply drop all items left from the stack to finish its operation.
1 Like
@filip . Hi Filip, Just to clarify my understanding of things. In the basic Pay to Public Key Hash scenario, to spend what you own you have to prove you own it first . So you supply the unlocking script. The unlocking script is applied to the locking script of your UTXO input (the output from a previous transaction). So the locking script is originally created by a previous transaction (correct ?) Once that is âsolvedâ by you , you are deemed to be the rightful owner and the âredeemedâ amount is spendable in the current transaction. Is that a correct summary please ?
If the above is correct then my next question covers the multisig use-case. I am trying to get my head around the specifics of WHO provides the locking script. It sounds like to me that the previous transaction has to magically know that you have a multisig wallet which will receive the funds and the previous sender must produce a multi-sig locking script. Then when you want to redeem the funds, you provide the unlocking solution to the multisig script. Is this correct please ?
many thanks, Paul
5 Likes
Well, they both are true. It indicates the number of signatures in the script. That is used to say that 2 out of 3 signatures need to match, correct. But it also tells the computer that 2 elements should be popped from the stack.
Letâs say that the 2 was only for saying that at least 2 signatures need to match. Then I could in theory put 5 signatures on the stack, even though only 2 need to match. But that wonât work. The computer would only pop 2 of them. Then you would get an error.
So the nr 2 is required for both of these reasons. Good question!
I love that you are questioning all of this, it shows you are really going to understand this.
Your first understanding is basically correct, as far as I understand your reasoning.
The second part is not totally correct. When we are talking about a pay to script hash transaction. We have to separate the locking script (which only contains a hash) and the redeem script (which contains the multisig script). The sender of the previous transaction therefor doesnât need to know that it is a multisig wallet, since that person will only create the locking script containing the script hash.
The script hash is created by the multisig wallet owner, given to the sender. The sender doesnât know the content of that script. Itâs just a hash. Thatâs the beauty of the P2SH type.
To summarice. the receiver creates the redeem script, containing the multisig redeem script, hashes it. Now he gives the hash to the sender. Then the sender just constructs a P2SH transaction to that hash. Then when the receiver (multisig owner) wants to spend those funds, they use the original redeem script and their keys and can spend the tx.
Let me know if you understand it better now 
4 Likes
Thanks Filip for taking the time out to respond in detail. I do get the process (as you outlined) concerning the P2SH transaction and i get the original basic Pay-To-PublicKey-Hash transaction type. In my second question I was really referring to the long-winded multisig scenario that didnt involve a P2SH. I revisited your videos and from what i can see in a standard multisig where it is not a P2SH tranacgion, all the âworkâ is put back onto the sender of the transaction. So that seems to be the answer in that case. Much appreciated, Paul
Yes thatâs correct. And thatâs why P2SH txâs is a lot more popular in those kinds of use cases. But we also have to remember that the wallet does most of the work when it comes to constructing transactions. But the sender in that case needs to know that it is a multisig tx.
@filip Sorry if I missed this in a previous video but are signature 2 and 3 encoded with some kind of nonce or timestamp? Otherwise I am struggling to see how you canât just replay those sigs in some future transaction. Or are we saying that because everything is going to be hashed, it doesnât matter that we use publicly available information?
I donât know exactly anymore how Filip showed it, but signatures are always different for every transaction. A signature is derived from the private key, partical utxo to send to a particular bitcoin address. So you never can use the same signature twice because the utxo would be on a different bitcoin address.
Check this video to see how digital signatures work:
https://youtu.be/Aq3a-_O2NcI
2 Likes
Thank you for this Fabrice
1 Like
Im still puzzling to solve a challenge I would like to accomplish. The challenge is to divide a payment over three public keys. Looking to the BTCPayServer solution, you are able to add a multisig adress in the store, which means you can solve the wish that you need more than 1 people to spend the amount the shop received. But suppose you want to divide the amount of money in the multisig where 1 person can redeem only 60% and an other 40%, is this possible to build with a P2SH? Probably we come on the terrain where we need smartcontracts though? Or do we have to create an other script as soon the payment is in which will send the bitcoin further to two other addresses? What could be the path to realize this? @filip
1 Like
Hello sir, it could be a way to do it, but that is a really complex challenge, you might going to need to create your own script or app that can monitor the address at any moment:
Once a transaction is received
- It should calculate the amount received, divided into the % established.
- Build a P2SH (or more), each to send the % calculated.
- Participant signatures must be collected and assembled in the transaction.
- All the mention steps should be inside the logic of the script/app.
It could be more easy to do it by using an smart contract.
Remember all of this is just theory, maybe in a near future we might see some wallets/apps that could integrate this ideas into their logic.
Hope this gives you a clear view of the subject, keep learning!
If you have any doubt, please let us know so we can help you!
Carlos Z.
1 Like
Thanks! Seems I found a nice challenge I will finish this course further to see how far I can come. The fact that itâs probably easy to do this by smart contracts, on which blockchain we should build this? Iâm looking to RSK (rootstock) Komodo and Elements. What would be handy, taking the fact that when we want to make use of BTCPayServer on a raspberrypi it should be not to heavy. Iâm also curious what you can do with transmuter https://github.com/btcpayserver/btcTransmuter Seems it can solve something in this challenge as well. Will activate this as soon my BTCPayServer is synced on the Raspberry. Thanks!
1 Like
Iâm running into a hard error which I still canât solve after tryiung all kind of solutions I find on Google.
When I run the transaction.js which has this content:
âuse strictâ
const fs = require(âfsâ);
const assert = require(âassertâ);
const bcoin = require(âbcoinâ);
const KeyRing = bcoin.wallet.WalletKey;
const Script = bcoin.Script;
const MTX = bcoin.MTX;
const Amount = bcoin.Amount;
const Coin = bcoin.Coin;
const privateKey1 = fs.readFileSync(â./regtest-key1.wifâ).toString();
const privateKey2 = fs.readFileSync(â./regtest-key2.wifâ).toString();
const keyPair1 = KeyRing.fromSecret(privateKey1);
const keyPair2 = KeyRing.fromSecret(privateKey2);
const publicKey1 = keyPair1.publicKey;
const publicKey2 = keyPair2.publicKey;
const m = 2;
const n = 2;
//Redeem Script
const redeem = Script.fromMultisig(m, n [publicKey1, publicKey2]);
//P2SH Script
const script = Script.fromScripthash(redeem.hash160());
console.log(script);
I get this
error in my terminal:
Seems something wrong with the assert module. I checked my code, update the module, used an other nodejs version. This moment I have v12.13.0
Iâm working on Ubuntu 18.04 machine.
Maybe I can find any help here?
Perry
In the meantime I found a great add on on BTCPayServer. The create Payment Forwarder. You can forward funds when there is any balance and give a percentage of the balance to pay forward. Incredible fantastic Here a screenshot of the interface:
More info on: https://github.com/btcpayserver/btcTransmuter
Itâs still in Alpha but will test it next week. Thanks for this great course BTW, what a big lessons
Perry
1 Like
Hello sir, the issue is on the variable âredeemâ, you must have a âcommaâ between the #of signs require and the publickeys
Here is your variable
const redeem = Script.fromMultisig(m, n [publicKey1, publicKey2]);
Just need to add the ", " like this:
const redeem = Script.fromMultisig(m, n, [publicKey1, publicKey2]);
After that, you should be able to get P2SH without any issue from your âconsole.log(script);â variable.
This was mine, has an example:
<Script: OP_HASH160 0x14 0xe1cf9cfb8a2507f052eafc534f84e18087e2b4cb OP_EQUAL>
Hope you find this useful!
If you have any doubt, please let us know so we can help you!
Carlos Z.
1 Like
Excellent! thats a great news that you find a way to fullfil that objective, today while i was researching about your issue, i was thinking to advice you to check about the âbcoinâ library to see if they have something like that!, glad to know that you find it 1st! 
Please keep me notice it about your achievements on this subject! 
Carlos Z.