<p>As there are no known preimage attacks on RIPEMD160 and SHA256, it is impossible to know what the contents of a redeemScript are given just the scriptHash. So yes, it is impossible to know what conditions are necessary to spend from an address given just the address. That is one of the main points of using scriptHashes: it hides the redeemScript from others until it is spent from.</p>

<blockquote>
  <p>Also, can miners learn the final condition if the output is spent at its second nLockTime, like when Bob and Carol try to spend, they must also provide the redeem script, thus allowing miners to see that if they wait 500 more blocks they can claim the entire output, not just the fee, and not include it in a block until then.</p>
</blockquote>

<p>Yes, this is currently a problem. If the transaction is signed and broadcast, the redeemScript will be revealed and miners could then see the ANYONECANSPEND condition in which case they may be incentivized to not let the transaction confirm. This is an issue.</p>

<p>However that issue is not without solution. This is specifically something that <a href="https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki" rel="nofollow noreferrer">MAST (BIP 114)</a> fixes. Basically un-visited branches in the script are hidden behind a hash. So if MAST were available and the redeemScript made use of it, then the conditions which were not used (e.g. the ANYONECANSPEND condition) would be hidden behind another hash and thus outside observers would not know about it.</p>

<p><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html" rel="nofollow noreferrer">Taproot</a> is an expansion on MAST which adds further privacy by making it so that observers won't even know that there were other branches that were not used.</p>

CC BY-SA 3.0
2018-01-30T02:07:11.717Z
Thank you as always professional answer. But what if I spend it at second nLockTime, when Bob and Carol can sign, this will require them to also post the redeem script, and in the redeem script the final condition with ANYONECANSPEND will be visible, correct? So a malicious miner may not include this in any block, and wait 500 more blocks to claim the entire output.
skydanc3r
CC BY-SA 3.0
2018-01-30T02:09:54.337Z
The miner can copy the redeemscript, keep it for 500 more blocks and use it as anyonecanspend later. Again, this does not ensure him profit because any miner can do it, it will be a race between miners to claim it, but still if they all collude they are incetived to not include it in a block and wait until they can claim it, whoever finds the first block after it's anyonecanspend locktime expires is the lucky one, so be it. Silent gentleman's understanding.
skydanc3r
CC BY-SA 3.0
2018-01-30T02:16:23.087Z
I updated my answer to address that.
Ava Chow
CC BY-SA 3.0
2018-01-30T10:53:50.683Z
Thank you - very clear. Can we use MAST or Taproot NOW, in production? or is it a softfork that has to be implemented first?
skydanc3r
CC BY-SA 3.0
2018-01-30T17:08:44.030Z
MAST and Taproot are still in design and implementation phases. They will require a soft fork in order to be used.
Ava Chow
CC BY-SA 3.0
2018-01-30T23:43:30.620Z
Until the soft forks are deployed what variant do we have to make such a script, that finally ends up with ANYONECANSPEND but has multiple (like 3 or 4 branches) until the final one, which should be safe from miners incentive to keep them away as soon as redeemScript is revealed and last branch with anyonecanspend is made public?
skydanc3r
CC BY-SA 3.0
2018-01-31T00:11:40.153Z
Unfortunately there currently is no way to hide that.
Ava Chow
CC BY-SA 3.0
2018-01-30T02:05:19.047Z
2018-01-30T02:16:16.177Z
2018-01-30T02:16:16.177Z
Ava Chow
<p>Consider the following scenario.</p>

<p>Alice, Carol and Bob create and fund a script with the following rules:
if now, alice pubkey, bob pubkey
else
if now+500 blocks, bob pubkey, carol pubkey
else
if now+1000 blocks, ANYONECANSPEND</p>

<p>The question is if anyone (besides Alice, Bob and Carol who have the redeem script) can tell by looking at the address (script hash) that its final condition is ANYONECANSPEND, and miners for example choose not to include it in a block until the last nLockTime passes and the miner can claim the entire output, not just the fee.</p>

<p>Based on my current understanding, just by looking at a native P2WSH address (hash of script) it tells you nothing about the redeem script, or am I wrong?</p>

<p>Also, can miners learn the final condition if the output is spent at its second nLockTime, like when Bob and Carol try to spend, they must also provide the redeem script, thus allowing miners to see that if they wait 500 more blocks they can claim the entire output, not just the fee, and not include it in a block until then. Thank you.</p>

CC BY-SA 3.0
2018-01-30T10:52:13.320Z
I think that is an interesting or maybe conflicting use case: if N+1000, ANYONECANSPEND - a miner would also be an "ANYONE"? Or do you have specific people in mind, that shall be able to spend?
pebwindkraft
<transactions><script><p2sh><p2wsh><anyone-can-spend>
anyonecanspend final condition of a script can be spotted just by looking at the script hash, without the redeem data?
skydanc3r
# anyonecanspend final condition of a script can be spotted just by looking at the script hash, without the redeem data?

(Asked by: username_0 on 2018-01-30)

Consider the following scenario.

Alice, Carol and Bob create and fund a script with the following rules:
if now, alice pubkey, bob pubkey
else
if now+500 blocks, bob pubkey, carol pubkey
else
if now+1000 blocks, ANYONECANSPEND

The question is if anyone (besides Alice, Bob and Carol who have the redeem script) can tell by looking at the address (script hash) that its final condition is ANYONECANSPEND, and miners for example choose not to include it in a block until the last nLockTime passes and the miner can claim the entire output, not just the fee.

Based on my current understanding, just by looking at a native P2WSH address (hash of script) it tells you nothing about the redeem script, or am I wrong?

Also, can miners learn the final condition if the output is spent at its second nLockTime, like when Bob and Carol try to spend, they must also provide the redeem script, thus allowing miners to see that if they wait 500 more blocks they can claim the entire output, not just the fee, and not include it in a block until then. Thank you.

**Tags:** transactions, script, p2sh, p2wsh, anyone-can-spend

> **Comments:**
> **username_1**: I think that is an interesting or maybe conflicting use case: if N+1000, ANYONECANSPEND - a miner would also be an "ANYONE"? Or do you have specific people in mind, that shall be able to spend?  

---

## 1 answers

### Answer by username_2 on 2018-01-30. Score: 1 | Accepted answer

As there are no known preimage attacks on RIPEMD160 and SHA256, it is impossible to know what the contents of a redeemScript are given just the scriptHash. So yes, it is impossible to know what conditions are necessary to spend from an address given just the address. That is one of the main points of using scriptHashes: it hides the redeemScript from others until it is spent from.

> Also, can miners learn the final condition if the output is spent at its second nLockTime, like when Bob and Carol try to spend, they must also provide the redeem script, thus allowing miners to see that if they wait 500 more blocks they can claim the entire output, not just the fee, and not include it in a block until then.

Yes, this is currently a problem. If the transaction is signed and broadcast, the redeemScript will be revealed and miners could then see the ANYONECANSPEND condition in which case they may be incentivized to not let the transaction confirm. This is an issue.

However that issue is not without solution. This is specifically something that [MAST (BIP 114)](https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki) fixes. Basically un-visited branches in the script are hidden behind a hash. So if MAST were available and the redeemScript made use of it, then the conditions which were not used (e.g. the ANYONECANSPEND condition) would be hidden behind another hash and thus outside observers would not know about it.

[Taproot](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html) is an expansion on MAST which adds further privacy by making it so that observers won't even know that there were other branches that were not used.

> **Comments:**
> **username_0**: Thank you as always professional answer. But what if I spend it at second nLockTime, when Bob and Carol can sign, this will require them to also post the redeem script, and in the redeem script the final condition with ANYONECANSPEND will be visible, correct? So a malicious miner may not include this in any block, and wait 500 more blocks to claim the entire output.  
> **username_0**: The miner can copy the redeemscript, keep it for 500 more blocks and use it as anyonecanspend later. Again, this does not ensure him profit because any miner can do it, it will be a race between miners to claim it, but still if they all collude they are incetived to not include it in a block and wait until they can claim it, whoever finds the first block after it's anyonecanspend locktime expires is the lucky one, so be it. Silent gentleman's understanding.  
> **username_2**: I updated my answer to address that.  
> **username_0**: Thank you - very clear. Can we use MAST or Taproot NOW, in production? or is it a softfork that has to be implemented first?  
> **username_2**: MAST and Taproot are still in design and implementation phases. They will require a soft fork in order to be used.  
> **username_0**: Until the soft forks are deployed what variant do we have to make such a script, that finally ends up with ANYONECANSPEND but has multiple (like 3 or 4 branches) until the final one, which should be safe from miners incentive to keep them away as soon as redeemScript is revealed and last branch with anyonecanspend is made public?  
> **username_2**: Unfortunately there currently is no way to hide that.  

---

