<p>The answers to your questions, in order:</p>

<ol>
<li><p>The fee paid for a transaction is determined by the size of a transaction.  Currently, if you want to do fancy things with bitcoins, you need to put a script in the transaction that <em>sends</em> them -- each output includes a script giving the conditions under which it may be used as an input.  <strong><a href="https://en.bitcoin.it/wiki/BIP_0012">OP_EVAL</a>, <a href="https://en.bitcoin.it/wiki/BIP_0016">p2sh</a> and <a href="https://en.bitcoin.it/wiki/BIP_0017">CHV (check-hash-verify)</a> all provide ways of putting the script in the transaction that <em>receives</em> the coins</strong>.</p></li>
<li><p><strong>This lets you have coins sent to you and do arbitrarily complicated things with them without imposing a fee burden on the sender.</strong>  The coins are yours once they're sent, but you'll have to pay the fee the next time you try to do anything with them (no free lunch here...).  The most important use-case here is to have wallets from which you can spend coins only by using two different devices (for example, both your laptop and your cellphone).  Even if both devices are "virus infested" it's highly unlikely that any single malicious entity has compromised <strong><em>both</em></strong> of your devices.  The hope is that this will put an end to the rash of coin thefts, or at least make it much harder for botnet operators to steal coins from the people who own the machines they've taken over.</p></li>
<li><p>The voting takes place during the blocks found during <strong><em>the seven days preceding</em></strong> 01-Feb-2012.  No timezone was specified.</p></li>
<li><p>The original vote was "yes/abstain".  Gavin put code into the "master" branch of the bitcoin client that would cause anybody who upgraded to the latest version to automatically vote "yes".  This angered some people, who added a new option for a "no" vote.  However, what really matters is whether or not 50+X% vote "yes" -- an "abstain" counts as a "no" vote for the purposes that matter.  <strong>If a minority of the hashpower were to enable p2sh a single malicious user could cause a permanent blockchain split, so it's important that this not be enabled until we are dead certain that a comfortable majority of the hashpower is on board.</strong></p></li>
</ol>

<p><strong>Most of the controversy is over how quickly this proposal was put together and rushed through the approval process.</strong>  The general idea, and the predecessor (OP_EVAL) have been around for a while, but this latest incarnation is very new.</p>

<p>Also, at the moment the mining code in the bitcoin client has a funny concept of a "standard" transaction which is not part of the bitcoin protocol at all -- it's just a gentleman's convention by which some (but not all) mining pools voluntarily choose to omit transactions that use advanced bitcoin features -- if you want to use those advanced features you have to wait longer since there's only one big pool (and several small ones) that will take them (once mined into the chain, however, all clients respect these transactions -- it's just a question of getting them into the chain).  <strong>The p2sh specification forces the "standardness" concept to become part of the protocol -- miners will be forced to use transaction templates whether they want to or not.</strong>  Many consider this to be infringing on the miners' jurisdiction.  Others consider it an affront to aesthetics and an invitation to headaches in the future.</p>

CC BY-SA 3.0
2012-01-29T07:43:02.907Z
Note also that BIP 17 voting is the first week of February, after BIP 16 is rejected.
Luke Dashjr
CC BY-SA 3.0
2012-01-26T04:20:13.547Z
2012-01-26T04:37:57.433Z
2012-01-26T04:37:57.433Z
lamont cranston
<p>Reading <a href="https://bitcoin.stackexchange.com/questions/2595/what-are-the-implications-of-bip-12-vs-bip-16-and-op-codehashcheck">this question</a> and looking in the bitcointalk forums at the related discussion, there seems to be some kind of miner vote being done on whether a change will be implemented in the bitcoin protocol. </p>

<p>It seems to discuss the adding of a function which could allow clients to have restrictions on receiving coins. (Is this it? If so, it would answer Q1. below)</p>

<p>The following things were beyond my understanding though, or difficult to find:</p>

<ol>
<li>An explanation in laymens terms of what the potential change achieved</li>
<li>Why the change is desirable</li>
<li>When the voting is taking place</li>
<li>What the vote is actually for (is it just yes/no, or are there more options?)</li>
</ol>

<p>Note that <a href="https://bitcoin.stackexchange.com/questions/2695/how-can-one-know-which-way-mining-pools-will-vote-for-p2sh">this question</a> addresses the question of which mining pools are voting yay or nay, though it doesn't seem to have an answer yet.</p>

<p>If this is done as part of the work of the bitcoin.org developers, I found it a bit strange that nothing seemed to be mentioned on the bitcoin.org site about it (I checked the news and the FAQ). I suppose that it is more of a miner issue though...</p>

<mining-pools><development><protocol><p2sh><voting>
What is an explanation of the P2SH voting in layman's terms?
Highly Irregular
# What is an explanation of the P2SH voting in layman's terms?

(Asked by: username_0 on 2012-01-25)

Reading [this question](https://bitcoin.stackexchange.com/questions/2595/what-are-the-implications-of-bip-12-vs-bip-16-and-op-codehashcheck) and looking in the bitcointalk forums at the related discussion, there seems to be some kind of miner vote being done on whether a change will be implemented in the bitcoin protocol.

It seems to discuss the adding of a function which could allow clients to have restrictions on receiving coins. (Is this it? If so, it would answer Q1. below)

The following things were beyond my understanding though, or difficult to find:

1. An explanation in laymens terms of what the potential change achieved
2. Why the change is desirable
3. When the voting is taking place
4. What the vote is actually for (is it just yes/no, or are there more options?)

Note that [this question](https://bitcoin.stackexchange.com/questions/2695/how-can-one-know-which-way-mining-pools-will-vote-for-p2sh) addresses the question of which mining pools are voting yay or nay, though it doesn't seem to have an answer yet.

If this is done as part of the work of the bitcoin.org developers, I found it a bit strange that nothing seemed to be mentioned on the bitcoin.org site about it (I checked the news and the FAQ). I suppose that it is more of a miner issue though...

**Tags:** mining-pools, development, protocol, p2sh, voting


---

## 1 answers

### Answer by username_1 on 2012-01-26. Score: 11 | Accepted answer

The answers to your questions, in order:

1. The fee paid for a transaction is determined by the size of a transaction. Currently, if you want to do fancy things with bitcoins, you need to put a script in the transaction that *sends* them -- each output includes a script giving the conditions under which it may be used as an input. **[OP\_EVAL](https://en.bitcoin.it/wiki/BIP_0012), [p2sh](https://en.bitcoin.it/wiki/BIP_0016) and [CHV (check-hash-verify)](https://en.bitcoin.it/wiki/BIP_0017) all provide ways of putting the script in the transaction that *receives* the coins**.
2. **This lets you have coins sent to you and do arbitrarily complicated things with them without imposing a fee burden on the sender.** The coins are yours once they're sent, but you'll have to pay the fee the next time you try to do anything with them (no free lunch here...). The most important use-case here is to have wallets from which you can spend coins only by using two different devices (for example, both your laptop and your cellphone). Even if both devices are "virus infested" it's username_0 unlikely that any single malicious entity has compromised ***both*** of your devices. The hope is that this will put an end to the rash of coin thefts, or at least make it much harder for botnet operators to steal coins from the people who own the machines they've taken over.
3. The voting takes place during the blocks found during ***the seven days preceding*** 01-Feb-2012. No timezone was specified.
4. The original vote was "yes/abstain". Gavin put code into the "master" branch of the bitcoin client that would cause anybody who upgraded to the latest version to automatically vote "yes". This angered some people, who added a new option for a "no" vote. However, what really matters is whether or not 50+X% vote "yes" -- an "abstain" counts as a "no" vote for the purposes that matter. **If a minority of the hashpower were to enable p2sh a single malicious user could cause a permanent blockchain split, so it's important that this not be enabled until we are dead certain that a comfortable majority of the hashpower is on board.**

**Most of the controversy is over how quickly this proposal was put together and rushed through the approval process.** The general idea, and the predecessor (OP\_EVAL) have been around for a while, but this latest incarnation is very new.

Also, at the moment the mining code in the bitcoin client has a funny concept of a "standard" transaction which is not part of the bitcoin protocol at all -- it's just a gentleman's convention by which some (but not all) mining pools voluntarily choose to omit transactions that use advanced bitcoin features -- if you want to use those advanced features you have to wait longer since there's only one big pool (and several small ones) that will take them (once mined into the chain, however, all clients respect these transactions -- it's just a question of getting them into the chain). **The p2sh specification forces the "standardness" concept to become part of the protocol -- miners will be forced to use transaction templates whether they want to or not.** Many consider this to be infringing on the miners' jurisdiction. Others consider it an affront to aesthetics and an invitation to headaches in the future.

> **Comments:**
> **username_2**: Note also that BIP 17 voting is the first week of February, after BIP 16 is rejected.  

---

