<p>This is discussed here.</p>

<ul>
<li><a href="http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/11/15/2#l2156425" rel="nofollow">http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/11/15/2#l2156425</a></li>
</ul>

<p>i.e., that would require AnyoneCanPay to be vulnerable as you describe it.</p>

CC BY-SA 3.0
2012-07-19T15:29:33.500Z
So... as long as the spending transaction has other inputs, it's safe. But a spending transaction with only one input would be vulnerable, even without AnyoneCanPay, right?
hmp
CC BY-SA 3.0
2012-07-19T14:54:43.530Z
2012-07-19T14:54:43.530Z
Stephen Gornick
<p><a href="https://en.bitcoin.it/wiki/OP_CHECKSIG#Hashtype_SIGHASH_NONE">The bitcoin wiki OP_CHECKSIG page</a> describes the behaviour of SIGHASH_NONE like this:</p>

<blockquote>
  <p>The output of txCopy is set to a vector of zero size.</p>
  
  <p>All other inputs aside from the current input in txCopy have their
  nSequence index set to zero</p>
  
  <p>Think of this as "sign none of the outputs-- I don't care where the
  bitcoins go."</p>
</blockquote>

<p>The <a href="https://en.bitcoin.it/wiki/Contracts#Theory">contracts</a> page also talks about SIGHASH_NONE:</p>

<blockquote>
  <p>SIGHASH_NONE: The outputs are not signed and can be anything. Use this
  to indicate "I agree to put my money in, as long as everyone puts
  their money in, but I don't care what's done with the output". This
  mode allows others to update the transaction by changing their inputs
  sequence numbers.</p>
</blockquote>

<p>If I sign a transaction where all the inputs are SIGHASH_NONE then a miner can change the outputs to whatever he likes.  If any of the inputs are SIGHASH_ALL then the miner can't change the outputs.  So a group of people can each sign their own SIGHASH_NONE input to a transaction, send them privately to the coordinator who signs his own SIGHASH_ALL input before publishing the transaction.  That way the individual contributors don't need to know the destination address so long as they trust the coordinator.</p>

CC BY-SA 3.0
2016-04-27T14:05:57.473Z
One should note that the ability to add additional inputs depends on the SIGHASH_ANYONECANPAY bit being set as well.
runeks
CC BY-SA 3.0
2012-07-19T18:31:02.543Z
2012-07-19T19:21:37.787Z
2012-07-19T19:21:37.787Z
Chris Moore
<p>If I understand correctly, SIGHASH_NONE in the <strike>output</strike> <em>input signature</em> means that spender of this output doesn't sign <em>his</em> outputs. But doesn't that mean that the spending transaction is by design insecure? E.g. a malicious miner could switch the outputs to his addresses and put a modified version in the block. </p>

<p>Am I missing something? What is SIGHASH_NONE intended for?</p>

<p><strong>Edit:</strong> Now I understand why I was confused! The SIGHASH_NONE is in the input signature, not in the output. Somehow I thought it's an attribute of the output, and it didn't make sense to me why the <em>previous</em> spender would be able to decide how the <em>next</em> transaction should be signed.</p>

CC BY-SA 3.0
2015-05-27T00:58:45.683Z
note that the sighash byte appended to the signature cannot be modified by the miner. eg the miner cannot change a sighash_anyonecanpay into a sighash_none. this is because even though the signature itself does not form part of the message (txhash) to be verified, the sighash byte actually does form part of the message and so it is verified in the signature. [more detail here](http://bitcoin.stackexchange.com/a/37095/2116)
mulllhausen
<transactions><protocol>
What is the point of SIGHASH_NONE?
hmp
# What is the point of SIGHASH_NONE?

(Asked by: username_0 on 2012-07-19)

If I understand correctly, SIGHASH\_NONE in the output *input signature* means that spender of this output doesn't sign *his* outputs. But doesn't that mean that the spending transaction is by design insecure? E.g. a malicious miner could switch the outputs to his addresses and put a modified version in the block.

Am I missing something? What is SIGHASH\_NONE intended for?

**Edit:** Now I understand why I was confused! The SIGHASH\_NONE is in the input signature, not in the output. Somehow I thought it's an attribute of the output, and it didn't make sense to me why the *previous* spender would be able to decide how the *next* transaction should be signed.

**Tags:** transactions, protocol

> **Comments:**
> **username_1**: note that the sighash byte appended to the signature cannot be modified by the miner. eg the miner cannot change a sighash_anyonecanpay into a sighash_none. this is because even though the signature itself does not form part of the message (txhash) to be verified, the sighash byte actually does form part of the message and so it is verified in the signature. [more detail here](http://bitcoin.stackexchange.com/a/37095/2116)  

---

## 2 answers

### Answer by username_3 on 2012-07-19. Score: 17 | Accepted answer

[The bitcoin wiki OP\_CHECKSIG page](https://en.bitcoin.it/wiki/OP_CHECKSIG#Hashtype_SIGHASH_NONE) describes the behaviour of SIGHASH\_NONE like this:

> The output of txCopy is set to a vector of zero size.
>
> All other inputs aside from the current input in txCopy have their
> nSequence index set to zero
>
> Think of this as "sign none of the outputs-- I don't care where the
> bitcoins go."

The [contracts](https://en.bitcoin.it/wiki/Contracts#Theory) page also talks about SIGHASH\_NONE:

> SIGHASH\_NONE: The outputs are not signed and can be anything. Use this
> to indicate "I agree to put my money in, as long as everyone puts
> their money in, but I don't care what's done with the output". This
> mode allows others to update the transaction by changing their inputs
> sequence numbers.

If I sign a transaction where all the inputs are SIGHASH\_NONE then a miner can change the outputs to whatever he likes. If any of the inputs are SIGHASH\_ALL then the miner can't change the outputs. So a group of people can each sign their own SIGHASH\_NONE input to a transaction, send them privately to the coordinator who signs his own SIGHASH\_ALL input before publishing the transaction. That way the individual contributors don't need to know the destination address so long as they trust the coordinator.

> **Comments:**
> **username_4**: One should note that the ability to add additional inputs depends on the SIGHASH_ANYONECANPAY bit being set as well.  

---

### Answer by username_2 on 2012-07-19. Score: 0

This is discussed here.

* <http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/11/15/2#l2156425>

i.e., that would require AnyoneCanPay to be vulnerable as you describe it.

> **Comments:**
> **username_0**: So... as long as the spending transaction has other inputs, it's safe. But a spending transaction with only one input would be vulnerable, even without AnyoneCanPay, right?  

---

