Bitcoin Forum
December 10, 2016, 03:23:26 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Poll
Question: What P2SH solution will you support? (multiple votes allowed)
None, I don't like multi-factor authentication - 20 (10.9%)
People who want multi-factor authentication should use extremely long "Script addresses" - 17 (9.2%)
OP_EVAL (BIP 12) - 15 (8.2%)
/P2SH/ (BIP 16) - 92 (50%)
CODEHASHCHECK - 40 (21.7%)
Total Voters: 143

Pages: « 1 2 3 4 [5] 6 7 8 »  All
  Print  
Author Topic: Old P2SH debate thread  (Read 17024 times)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
January 15, 2012, 03:54:16 PM
 #81

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.

1481340206
Hero Member
*
Offline Offline

Posts: 1481340206

View Profile Personal Message (Offline)

Ignore
1481340206
Reply with quote  #2

1481340206
Report to moderator
1481340206
Hero Member
*
Offline Offline

Posts: 1481340206

View Profile Personal Message (Offline)

Ignore
1481340206
Reply with quote  #2

1481340206
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
January 16, 2012, 02:05:13 AM
 #82

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
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
January 16, 2012, 10:40:30 AM
 #83

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
Hero Member
*****
Offline Offline

Activity: 497


View Profile
January 16, 2012, 04:31:35 PM
 #84

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 16, 2012, 04:34:33 PM
 #85

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
Sr. Member
****
Offline Offline

Activity: 389


View Profile
January 16, 2012, 04:51:33 PM
 #86

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
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 16, 2012, 05:28:28 PM
 #87

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.


How often do you get the chance to work on a potentially world-changing project?
notme
Legendary
*
Offline Offline

Activity: 1526


View Profile
January 16, 2012, 05:32:08 PM
 #88

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.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
FairUser
Sr. Member
****
Offline Offline

Activity: 261


View Profile WWW
January 17, 2012, 08:10:31 PM
 #89

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
Hero Member
*****
Offline Offline

Activity: 896


View Profile
January 17, 2012, 08:19:20 PM
 #90

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
Legendary
*
Offline Offline

Activity: 1526


View Profile
January 17, 2012, 08:25:34 PM
 #91

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

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 17, 2012, 10:15:25 PM
 #92

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.

How often do you get the chance to work on a potentially world-changing project?
FairUser
Sr. Member
****
Offline Offline

Activity: 261


View Profile WWW
January 18, 2012, 03:16:50 AM
 #93

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
Member
**
Offline Offline

Activity: 85



View Profile
January 19, 2012, 08:17:14 AM
 #94

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
Legendary
*
Offline Offline

Activity: 1526


View Profile
January 19, 2012, 09:45:40 AM
 #95

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.

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

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
interlagos
Hero Member
*****
Offline Offline

Activity: 497


View Profile
January 19, 2012, 12:55:32 PM
 #96

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
Hero Member
*****
Offline Offline

Activity: 616



View Profile
January 19, 2012, 01:13:06 PM
 #97

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
Legendary
*
Offline Offline

Activity: 1302



View Profile
January 19, 2012, 02:27:45 PM
 #98

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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
DeepBit
Donator
Hero Member
*
Offline Offline

Activity: 532


We have cookies


View Profile WWW
January 19, 2012, 02:28:10 PM
 #99

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.

Welcome to my bitcoin mining pool: https://deepbit.net ~ 3600 GH/s, Both payment schemes, instant payout, no invalid blocks !
Coming soon: ICBIT Trading platform
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 19, 2012, 03:41:15 PM
 #100

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. Smiley
Pages: « 1 2 3 4 [5] 6 7 8 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!