My mistake, thank you. Carla makes the redeemScript and gives the hashed result, her address , to Bob.
Still, my point is that Carla needs the same redeemScript to send to Josh. After she does sends to Josh, Josh is not spending that TX just yet. In the meantime someone else, Nigel, looks at the TX Carla executed and sees the redeemScript. He can then spend the TXO and leave Josh empty handed. This is my theory, and what I am trying to reproduce on testnet.
Presumably Josh has his own redeemScript and does not share one with Carla so his redeemScript is unknown unless he has used it before. Furthermore, once Carla's transaction is confirmed, no one can spend that output.Still, my point is that Carla needs the same redeemScript to send to Josh. After she does sends to Josh, Josh is not spending that TX just yet. In the meantime someone else, Nigel, looks at the TX Carla executed and sees the redeemScript. He can then spend the TXO and leave Josh empty handed. This is my theory, and what I am trying to reproduce on testnet.
You mentioned that redeemScripts are not retrieved from previous Tx's. I'm assuming you're not referring to P2SH addresses? From your explanation it sounds like a typical P2PKH where only the owner of the private key, associated with the public key of the address can spend the TX.
I misunderstood what you meant by "retrieving redeemScripts from previous transactions". You can retrieve a redeemScript for a previous transaction. However when a transaction is validated, redeemScripts are not retrieved from previous transactions (which is what I thought you meant).My claim is this: If you are spending an UTXO of type P2SH that encapsulates the hash of an OP_TRUE, you can create a P2SH raw transaction with code that spends (conditioned on not being multisig) by using the redeemScript which was revealed in the previous TX.
That is true.However, no one who legitimately wants to receive money would give someone else an address for an OP_TRUE script. With P2SH, they can specify any script they want, and most scripts that people use still have a public key and a signature. Additionally, well known scripts such as an OP_TRUE have known addresses and people have bots that actively look for transactions sending to an OP_TRUE address and sweeping the funds immediately.
I have a few questions please.
Q1: The redeemScript became visible on the blockchain after some amount was spent from TX, correct? How can we know it was supposed to correspond to
? Just by looking at [3 5 4]?
The script itself is the Q1: The redeemScript became visible on the blockchain after some amount was spent from TX, correct? How can we know it was supposed to correspond to
Code:
OP_3DUP OP_ADD 9 OP_EQUALVERIFY OP_ADD 7 OP_EQUALVERIFY OP_ADD 8 OP_EQUALVERIFY 1
Code:
PUSHDATA(11)[6f93598893578893588851]
Q2: In your example, clearly the recipient of tx is a P2PKH address . That's simply because it happened to be the case that the owner of knew how to solve the the redeemScript and just executed a tx in code, correct?
Not necessarily. It could be anyone who knew the redeemScript (by having generated it himself at some point) who created the transaction and sent it to 1GWdcSNAYdq3eG6YR4tb9YWiRvuC8k7J6V. It doesn't have to be the owner of that address.Code:
1GWdcSNAYdq3eG6YR4tb9YWiRvuC8k7J6V
Code:
1GWdcSNAYdq3eG6YR4tb9YWiRvuC8k7J6V
What if let's say it was a P2SH address instead, and the TX resulted in a further unspent. Would anyone be (again) able to see the redeemScript and solve it even further? So unless the chain of TX's stops with a multisig or a P2PKH address, it can be further spent over and over again by anyone who can see and use this type of redeemScript?
No, it depends on the redeemScript. Not all redeemScripts are anyone-can-spend. You can specify anything you want, and most P2SH scripts that people use still require a signature.Q3: Would I be able to reproduce such a transaction in Node and let's say bitcore-lib? I don't see why not but I am still trying to find specific details on github.
I don't think bitcore-lib allows you to create and spend from non-standard scripts (which is what you want) unless you make raw transactions yourself and construct the scriptSig and redeemScript manually. 