Topic: Old P2SH debate thread - page 4. (Read 19705 times)

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)

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://bitcointalksearch.org/topic/m.701749

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

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

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?

Thank you for the detailed explanation.  Much appreciated.

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.

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

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.

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.

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

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.

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...

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%.

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.

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

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

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.

I originally voted for Luke's CODEHASHCHECK proposal because it sounded more elegant and because I fully support the idea of bitcoin becoming more democratic. However I liked the analogy of P2SH like being a preprocessor to C++ in this post by Stefan Thomas: https://bitcointalksearch.org/topic/m.691560 so I might consider voting for P2SH as well. Of course one might argue that bitcoin protocol should not evolve as C++ but that's another story.

Anyway my point is that we should consider worst cases more carefully compared to what particular approach enables.
There must be a step-by-step plan of what might go wrong and what our actions should be.

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.

Can anyone provide links to anything that has details on this incident? I've tried searching without luck.

You are correct.  I'm tired and you're right.  Each implementation would be required to perform all the validations.  Since validations are pretty much all we're doing here, it's an everyone or no one scenario, not a buffet.  Sorry for the derailment.