Old P2SH debate thread

[Luke-Jr]

FWIW, the BIP16-as-preprocessor argument seems fundamentally flawed to me... The C preprocessor acts on explicit statements at compile-time. Scripts are already compiled, and BIP16 is affecting behaviour without any statements or equivalent.

[1714789883]

1714789883

[1714789883]

1714789883

[1714789883]

1714789883

[runeks]

By the way last time I checked P2Pool was third in hashrate distribution (after DeepBit and BTCGuild) so convincing a few pool owners might still work for some time, but in a long run individual miners should be involved in decision making and everybody should understand the pros and cons of a particular approach.

Current global p2pool hash rate is around 70-80 GH/s. So it's less than 1%.

[Matthew N. Wright]

By the way last time I checked P2Pool was third in hashrate distribution (after DeepBit and BTCGuild) so convincing a few pool owners might still work for some time, but in a long run individual miners should be involved in decision making and everybody should understand the pros and cons of a particular approach.

Current global p2pool hash rate is around 70-80 GH/s. So it's less than 1%.

Just think: Theoretically here pretty soon you'll be able to drop $50k on 2 ButterflyLabs rack boxes and get that on your own.

[interlagos]

By the way last time I checked P2Pool was third in hashrate distribution (after DeepBit and BTCGuild) so convincing a few pool owners might still work for some time, but in a long run individual miners should be involved in decision making and everybody should understand the pros and cons of a particular approach.

Wherever you are getting that information, it is incorrect.

P2Pool is growing, but it's not growing that fast.

I checked at bitcoinwatch.com it could have been a spike or other pools were down, anyway it seems more than 1% right now.
And then there is this Unknown blob, what if those guys aren't following the thread and won't upgrade?
We should consider all consequences.

[DeathAndTaxes]

I checked at bitcoinwatch.com it could have been a spike or other pools were down, anyway it seems more than 1% right now.

No need to speculate on known fact. p2pool has ~80GH/s.  It has never had more than 100GH/s and certainly nothing like the >1000 GH/s necessary to be the #3 pool.  Currently the global hashrate is ~9400 GH/s so p2pool is <1%.

[localhost]

Understanding all this things in details would take me too much time. As far as I understood, that /P2SH/ thing is going to break stuff... I say just keep it on the testnet long enough before making a decision about it then... As already said, it's not as if there was a deadline to release it...

[Gavin Andresen]

All righty, I mostly stepped away from the keyboard for a couple of days and I'm less frustrated and angry.

So first, I want to apologize to Luke for calling his CODEHASHCHECK code "a joke." I was frustrated that after weeks of discussion and gathering consensus around /P2SH/ he and piuk (and a couple others) decide it would be a good idea to propose slightly-different-but-not-obviously-better alternatives.

I still think Luke went about this the wrong way; for example, I think I would have been happy to accept a patch that made supporting /P2SH/ optional if he had presented it rationally instead of posting "ALERT! GAVIN IS HIJACKING BITCOIN! ACTION NEEDED!" I'd still be happy to accept a patch turning on/off the "put /P2SH/ in the coinbase" (assuming the general consensus is that is a good idea), but that's a discussion that should happen in the Dev/Tech forum.

In fact, most of the discussion in this thread on the merits of various proposals belongs in the Dev/Tech forum, and most of the concerns expressed here in this thread have already been discussed over the last several months.

[notme]

All righty, I mostly stepped away from the keyboard for a couple of days and I'm less frustrated and angry.

So first, I want to apologize to Luke for calling his CODEHASHCHECK code "a joke." I was frustrated that after weeks of discussion and gathering consensus around /P2SH/ he and piuk (and a couple others) decide it would be a good idea to propose slightly-different-but-not-obviously-better alternatives.

I still think Luke went about this the wrong way; for example, I think I would have been happy to accept a patch that made supporting /P2SH/ optional if he had presented it rationally instead of posting "ALERT! GAVIN IS HIJACKING BITCOIN! ACTION NEEDED!" I'd still be happy to accept a patch turning on/off the "put /P2SH/ in the coinbase" (assuming the general consensus is that is a good idea), but that's a discussion that should happen in the Dev/Tech forum.

In fact, most of the discussion in this thread on the merits of various proposals belongs in the Dev/Tech forum, and most of the concerns expressed here in this thread have already been discussed over the last several months.

Thank you for bearing this responsibility Gavin.  It must take great patience.

[FairUser]

All righty, I mostly stepped away from the keyboard for a couple of days and I'm less frustrated and angry.

So first, I want to apologize to Luke for calling his CODEHASHCHECK code "a joke." I was frustrated that after weeks of discussion and gathering consensus around /P2SH/ he and piuk (and a couple others) decide it would be a good idea to propose slightly-different-but-not-obviously-better alternatives.

I still think Luke went about this the wrong way; for example, I think I would have been happy to accept a patch that made supporting /P2SH/ optional if he had presented it rationally instead of posting "ALERT! GAVIN IS HIJACKING BITCOIN! ACTION NEEDED!" I'd still be happy to accept a patch turning on/off the "put /P2SH/ in the coinbase" (assuming the general consensus is that is a good idea), but that's a discussion that should happen in the Dev/Tech forum.

In fact, most of the discussion in this thread on the merits of various proposals belongs in the Dev/Tech forum, and most of the concerns expressed here in this thread have already been discussed over the last several months.

Gavin,

I beg of you, give users MORE time to adopt this change and think about the dates you choose.  We have several users on our pool that are either travelling or are away from their PC's for extended periods of time, and if this is going to require everyone to update then getting all the pool admins on board so they can then warn/inform their user's about the change is critical.  Nobody sent me or Geebus a memo, I just happen to find it, and this is true for A LOT of user's on this forum and other forums.  Waiting until the day when it just stops working to only find out that a critical change was made a week ago and that's why we were unable to mint new coins is frustrating to everyone involved.

I think as a core developer, you should be in touch with or have a list of all the pool admins contact info in order to notify them of these types of changes, then they can send the word out to their users however they see fit.  We (@BitcoinPool) would gladly put the news of this on the front page and e-mail all our users about the change. One post on one forum on the Internet and hoping/expecting everyone to read it just doesn't seem to be a good way to spread the word.

Other than that, keep up the good work.

[simonk83]

All righty, I mostly stepped away from the keyboard for a couple of days and I'm less frustrated and angry.

So first, I want to apologize to Luke for calling his CODEHASHCHECK code "a joke." I was frustrated that after weeks of discussion and gathering consensus around /P2SH/ he and piuk (and a couple others) decide it would be a good idea to propose slightly-different-but-not-obviously-better alternatives.

I still think Luke went about this the wrong way; for example, I think I would have been happy to accept a patch that made supporting /P2SH/ optional if he had presented it rationally instead of posting "ALERT! GAVIN IS HIJACKING BITCOIN! ACTION NEEDED!" I'd still be happy to accept a patch turning on/off the "put /P2SH/ in the coinbase" (assuming the general consensus is that is a good idea), but that's a discussion that should happen in the Dev/Tech forum.

In fact, most of the discussion in this thread on the merits of various proposals belongs in the Dev/Tech forum, and most of the concerns expressed here in this thread have already been discussed over the last several months.

Seems to me that the consensus of you devs (as voted between yourselves) was for P2SH.  That alone is good enough for me.  Luke missed out on that, and that's too bad, but he's one person in a group that disagrees.  Oh well.

Aside from that, the poll in this thread (while obviously not amazingly accurate) also indicates P2SH as a preferred solution by more than double the votes.

Seems pretty clear to me.

[notme]

All righty, I mostly stepped away from the keyboard for a couple of days and I'm less frustrated and angry.

So first, I want to apologize to Luke for calling his CODEHASHCHECK code "a joke." I was frustrated that after weeks of discussion and gathering consensus around /P2SH/ he and piuk (and a couple others) decide it would be a good idea to propose slightly-different-but-not-obviously-better alternatives.

I still think Luke went about this the wrong way; for example, I think I would have been happy to accept a patch that made supporting /P2SH/ optional if he had presented it rationally instead of posting "ALERT! GAVIN IS HIJACKING BITCOIN! ACTION NEEDED!" I'd still be happy to accept a patch turning on/off the "put /P2SH/ in the coinbase" (assuming the general consensus is that is a good idea), but that's a discussion that should happen in the Dev/Tech forum.

In fact, most of the discussion in this thread on the merits of various proposals belongs in the Dev/Tech forum, and most of the concerns expressed here in this thread have already been discussed over the last several months.

Gavin,

I beg of you, give users MORE time to adopt this change and think about the dates you choose.  We have several users on our pool that are either travelling or are away from their PC's for extended periods of time, and if this is going to require everyone to update then getting all the pool admins on board so they can then warn/inform their user's about the change is critical.  Nobody sent me or Geebus a memo, I just happen to find it, and this is true for A LOT of user's on this forum and other forums.  Waiting until the day when it just stops working to only find out that a critical change was made a week ago and that's why we were unable to mint new coins is frustrating to everyone involved.

I think as a core developer, you should be in touch with or have a list of all the pool admins contact info in order to notify them of these types of changes, then they can send the word out to their users however they see fit.  We (@BitcoinPool) would gladly put the news of this on the front page and e-mail all our users about the change. One post on one forum on the Internet and hoping/expecting everyone to read it just doesn't seem to be a good way to spread the word.

Other than that, keep up the good work.

Pool users shouldn't have to update anything.  Pools build the block they hand out, users just try to find a nonce for it.  You should know this if you run a pool.  Additionally, there is a development mailing list you can join where this was heavily discussed:
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development

[Gavin Andresen]

Pool users shouldn't have to update anything.  Pools build the block they hand out, users just try to find a nonce for it.  You should know this if you run a pool.  Additionally, there is a development mailing list you can join where this was heavily discussed:
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development

notme is exactly right; the change is backwards-compatible, pool users don't have to do anything.

Pools and solo miners should upgrade, or they run a (very small) risk that they'll waste time hashing a block that can't be valid.

The risk is very small because it requires that somebody mine a block containing a /P2SH/ transaction that is valid-under-the-old-rules, invalid-under-the-new. That won't happen by accident, somebody malicious will have to create such a transaction and then find a miner who is willing to put that non-standard transaction in their block (and is willing to create a block they know the network will reject).

They would spend a lot of time (and therefore money) on an attack that would do nothing but slow down transaction confirmations a tiny bit and maybe trip up some random, unlucky mining pool or solo miner who didn't bother upgrading.



Gory details if you're not already bored:

Old miners and clients will ignore all /P2SH/ transactions; they won't relay them to other nodes and won't put them in blocks they mine, because they're non-standard.  So an attacker can't broadcast an invalid /P2SH/ transaction and hope it gets included in a block; they'll have to mine a block themself, or partner with a big solo miner or pool who is willing to produce bad blocks.

If an attacker DID manage to create a block with a timestamp after the switchover date and a bad /P2SH/ transaction in it, then some percentage of the network will try to build on that bad block.  Lets say 70% of hashing power supports /P2SH/.  That would mean only 70% of the network was working on a good block-chain, and the result would be transactions taking, on average, about 14 minutes to confirm instead of the usual 10 minutes.

In other words: they'd give up a $300 block reward and manage to just give the network a tiny little hiccup.

[FairUser]

Pool users shouldn't have to update anything.  Pools build the block they hand out, users just try to find a nonce for it.  You should know this if you run a pool.  Additionally, there is a development mailing list you can join where this was heavily discussed:
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development

notme is exactly right; the change is backwards-compatible, pool users don't have to do anything.

Pools and solo miners should upgrade, or they run a (very small) risk that they'll waste time hashing a block that can't be valid.

The risk is very small because it requires that somebody mine a block containing a /P2SH/ transaction that is valid-under-the-old-rules, invalid-under-the-new. That won't happen by accident, somebody malicious will have to create such a transaction and then find a miner who is willing to put that non-standard transaction in their block (and is willing to create a block they know the network will reject).

They would spend a lot of time (and therefore money) on an attack that would do nothing but slow down transaction confirmations a tiny bit and maybe trip up some random, unlucky mining pool or solo miner who didn't bother upgrading.



Gory details if you're not already bored:

Old miners and clients will ignore all /P2SH/ transactions; they won't relay them to other nodes and won't put them in blocks they mine, because they're non-standard.  So an attacker can't broadcast an invalid /P2SH/ transaction and hope it gets included in a block; they'll have to mine a block themself, or partner with a big solo miner or pool who is willing to produce bad blocks.

If an attacker DID manage to create a block with a timestamp after the switchover date and a bad /P2SH/ transaction in it, then some percentage of the network will try to build on that bad block.  Lets say 70% of hashing power supports /P2SH/.  That would mean only 70% of the network was working on a good block-chain, and the result would be transactions taking, on average, about 14 minutes to confirm instead of the usual 10 minutes.

In other words: they'd give up a $300 block reward and manage to just give the network a tiny little hiccup.

Thank you for the detailed explanation.  Much appreciated.

[Minor]

I will not claim to understand the details of the discussion, but If I understand the high-level issue, we are trying to find a second solution to a problem for which we already have a solution (use double length addresses).
That tells me a couple of things:
- There is no urgency in adopting a second solution.
- The second solution had better be significantly better than the existing one and be thoroughly verified.

To those who say that the double length address solution is unacceptable because it will create higher fees to the coin sender, I would argue that if double length addresses become the norm they will not incur higher fees.

Now for a naive proposal:
Rather than requiring two keys that security conscious users can keep on separate devices, why not just split the existing key in two, and keep the two halves in separate devices?

[notme]

To those who say that the double length address solution is unacceptable because it will create higher fees to the coin sender, I would argue that if double length addresses become the norm they will not incur higher fees.

Fees are higher because these transactions take more bytes.  I don't think your argument has any teeth.

Now for a naive proposal:
Rather than requiring two keys that security conscious users can keep on separate devices, why not just split the existing key in two, and keep the two halves in separate devices?

You can't just slap the keys back together to sign because you never want both keys on the same device.

[interlagos]

I'm wondering if the following scenario is possible with P2SH:

"Ex:  I want to buy a FPGA miner for 100 bitcoins.

I put 100 in escrow.  The seller is required to put some amount, maybe 10%  along with mine in to escrow.  Range could be a sliding scale from 1% to 100% of the amount I put in escrow.  Escrow now contains 110 coins.

You would have to be a pretty rich jerk to maliciously scam people repeatedly.  Worst case scenario, untrusting buyers could demand 100% matching escrows for first time transactions."

quoted from:
https://bitcointalk.org/index.php?topic=60158.msg701749#msg701749

[EhVedadoOAnonimato]

I will not claim to understand the details of the discussion, but If I understand the high-level issue, we are trying to find a second solution to a problem for which we already have a solution (use double length addresses).
That tells me a couple of things:
- There is no urgency in adopting a second solution.

This summarizes my feeling. It's not like it is impossible to do multi-sig payments, they just result in slightly larger transactions.

Anyway, as says the quote above, I cannot claim I understand the details. I would just like to know if theymos opinion that this is mostly a style issue is a consensus, or there's more than style at stake. (not saying that style isn't important, it definitely is. I just want to understand if there is more to it)

[kjj]

I will not claim to understand the details of the discussion, but If I understand the high-level issue, we are trying to find a second solution to a problem for which we already have a solution (use double length addresses).
That tells me a couple of things:
- There is no urgency in adopting a second solution.

This summarizes my feeling. It's not like it is impossible to do multi-sig payments, they just result in slightly larger transactions.

Anyway, as says the quote above, I cannot claim I understand the details. I would just like to know if theymos opinion that this is mostly a style issue is a consensus, or there's more than style at stake. (not saying that style isn't important, it definitely is. I just want to understand if there is more to it)

The issue isn't "slightly" larger transactions.  Complex transactions can be much larger than normal transactions, and it puts the burden on the wrong party.  See this post.

[DeepBit]

I'm wondering if the following scenario is possible with P2SH:
"Ex:  I want to buy a FPGA miner for 100 bitcoins.

Actually this is possible with any multisig scheme, even without special redeeming scripts.

[DeathAndTaxes]

I will not claim to understand the details of the discussion, but If I understand the high-level issue, we are trying to find a second solution to a problem for which we already have a solution (use double length addresses).
That tells me a couple of things:
- There is no urgency in adopting a second solution.

This summarizes my feeling. It's not like it is impossible to do multi-sig payments, they just result in slightly larger transactions.

Anyway, as says the quote above, I cannot claim I understand the details. I would just like to know if theymos opinion that this is mostly a style issue is a consensus, or there's more than style at stake. (not saying that style isn't important, it definitely is. I just want to understand if there is more to it)

It isn't a solution.  It is completely nonviable.

I use multi-sig so I (not you) gain the advantage of higher security.
My address is longer so when YOU (not me) transfer funds You (not me) pay the higher fees.

I get all the benefit you get all the fees.  Also the fees can be significantly more and rise w/ more complexity and security (for example not just 2 sigs but 3,4,5).

So you pay more and more and more in fees and I get more and more and more security.  

Multi-sig will have a very limited usefulness (mostly academic) without a change to protocol.  It would be like pricing gas on the inverse of how large your car is and wondering why fuel efficiency sucks.