Bitcoin Forum
October 24, 2017, 11:53:01 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Should we change the default to P2SH?  (Read 923 times)
jl2012
Legendary
*
Offline Offline

Activity: 1694


View Profile
October 28, 2013, 04:52:29 PM
 #1

The default bitcoin address is pay-to-key-hash. Should we move it to P2SH as default? It saves 2 bytes per UTXO. It also provides a little bit more anonymity as other people won't know the script until it is really redeemed.

On the other hand, would that be less secure than pay-to-key-hash, as in P2SH one only needs a collision of HASH160 to steal the coin, while in pay-to-key-hash one needs to break both HASH160 and ECDSA?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
1508845981
Hero Member
*
Offline Offline

Posts: 1508845981

View Profile Personal Message (Offline)

Ignore
1508845981
Reply with quote  #2

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

Posts: 1508845981

View Profile Personal Message (Offline)

Ignore
1508845981
Reply with quote  #2

1508845981
Report to moderator
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
October 28, 2013, 04:55:20 PM
 #2

On the other hand, would that be less secure than pay-to-key-hash, as in P2SH one only needs a collision of HASH160 to steal the coin, while in pay-to-key-hash one needs to break both HASH160 and ECDSA?
You don't just need a HASH160 collision, you need a HASH160 collision which also happens to be a valid input script.
jl2012
Legendary
*
Offline Offline

Activity: 1694


View Profile
October 28, 2013, 04:59:25 PM
 #3

On the other hand, would that be less secure than pay-to-key-hash, as in P2SH one only needs a collision of HASH160 to steal the coin, while in pay-to-key-hash one needs to break both HASH160 and ECDSA?
You don't just need a HASH160 collision, you need a HASH160 collision which also happens to be a valid input script.

Yes, but a valid input script could be as simple as pushing a non-zero value to the stake.

In pay-to-key-hash, you need a HASH160 collision, and the private key for that collision, which may not even exist.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
October 28, 2013, 05:00:00 PM
 #4

It also expands the size of the entire chain that must be stored forever. It's really not a saving unless you consider the cost of archiving and transmitting the chain to be free. It's cheap, but it's not totally free.

The most efficient form byte-wise overall is raw pay to pubkey, which is why it was the default in bitcoin 0.1 when you could get a direct peer-to-peer connection between parties.

It doesn't change the privacy aspects at all. The output always contains a random number. Hashing that number doesn't make it more or less private.
jl2012
Legendary
*
Offline Offline

Activity: 1694


View Profile
October 28, 2013, 05:04:49 PM
 #5

It also expands the size of the entire chain that must be stored forever. It's really not a saving unless you consider the cost of archiving and transmitting the chain to be free. It's cheap, but it's not totally free.

The most efficient form byte-wise overall is raw pay to pubkey, which is why it was the default in bitcoin 0.1 when you could get a direct peer-to-peer connection between parties.

It doesn't change the privacy aspects at all. The output always contains a random number. Hashing that number doesn't make it more or less private.

We may have a smarter way to archive. We don't need to do it byte-by-byte. Use a single byte to denote common output scripts so the archive nodes may drop all those "OP_EQUALVERIFY OP_CHECKSIG " crap

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
October 28, 2013, 05:28:58 PM
 #6

We may have a smarter way to archive. We don't need to do it byte-by-byte. Use a single byte to denote common output scripts so the archive nodes may drop all those "OP_EQUALVERIFY OP_CHECKSIG " crap

That's already how sipa's UTXO database works.

FWIW I used to think otherwise, but I agree with Mike for the most part these days as I'm 99% sure UTXO growth isn't a major problem. I'll publish something better soon, but in the meanwhile gmaxwell has a nice summary: https://bitcointalk.org/index.php?topic=314467.msg3371194#msg3371194

Having said that, P2SH needs wider support all the same. It's embarrassing that something that should take about five lines of code isn't supported in so much wallet software.

etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
October 28, 2013, 06:01:36 PM
 #7

We may have a smarter way to archive. We don't need to do it byte-by-byte. Use a single byte to denote common output scripts so the archive nodes may drop all those "OP_EQUALVERIFY OP_CHECKSIG " crap

That's already how sipa's UTXO database works.

FWIW I used to think otherwise, but I agree with Mike for the most part these days as I'm 99% sure UTXO growth isn't a major problem. I'll publish something better soon, but in the meanwhile gmaxwell has a nice summary: https://bitcointalk.org/index.php?topic=314467.msg3371194#msg3371194

Having said that, P2SH needs wider support all the same. It's embarrassing that something that should take about five lines of code isn't supported in so much wallet software.

The simplicity is over-stated.  The concept is simple and can be represented in 5 lines of code.  But the last thing I want is for a bug in my implementation to switch to the wrong conditional under some specific circumstances and send coins intended for my 1... address to an unspendable 3... address.   These kinds of changes are dangerous when all the contextual code around it was written assuming one address type.

The code in question is remarkably sensitive, and a stupid oversight in the code could lead to massive loss of coins.  Maybe I'm overstating it... but I have some users with seriously a lot of money, and I'm sure they appreciate my paranoid diligence in things like this.

For reference, once I finally get this next version of Armory locked down, I'm going to work on this and make sure there's loads of tests for it in all the available contexts. 

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
October 28, 2013, 06:13:02 PM
 #8

The simplicity is over-stated.  The concept is simple and can be represented in 5 lines of code.  But the last thing I want is for a bug in my implementation to switch to the wrong conditional under some specific circumstances and send coins intended for my 1... address to an unspendable 3... address.   These kinds of changes are dangerous when all the contextual code around it was written assuming one address type.

The code in question is remarkably sensitive, and a stupid oversight in the code could lead to massive loss of coins.  Maybe I'm overstating it... but I have some users with seriously a lot of money, and I'm sure they appreciate my paranoid diligence in things like this.

For reference, once I finally get this next version of Armory locked down, I'm going to work on this and make sure there's loads of tests for it in all the available contexts. 

With all due respect, that your code was designed in such a way that is assumed one address type is something I would be a little embarrassed about myself - even in the early days it was easy to see how different types of addresses would simply have to be developed in the future if the scripting system was going to be of any use.

But in the meantime, I wouldn't be embarrassed to take however long it takes to do it right!

etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
October 28, 2013, 06:22:14 PM
 #9

The simplicity is over-stated.  The concept is simple and can be represented in 5 lines of code.  But the last thing I want is for a bug in my implementation to switch to the wrong conditional under some specific circumstances and send coins intended for my 1... address to an unspendable 3... address.   These kinds of changes are dangerous when all the contextual code around it was written assuming one address type.

The code in question is remarkably sensitive, and a stupid oversight in the code could lead to massive loss of coins.  Maybe I'm overstating it... but I have some users with seriously a lot of money, and I'm sure they appreciate my paranoid diligence in things like this.

For reference, once I finally get this next version of Armory locked down, I'm going to work on this and make sure there's loads of tests for it in all the available contexts. 

With all due respect, that your code was designed in such a way that is assumed one address type is something I would be a little embarrassed about myself - even in the early days it was easy to see how different types of addresses would simply have to be developed in the future if the scripting system was going to be of any use.

But in the meantime, I wouldn't be embarrassed to take however long it takes to do it right!

Regardless of how I wrote it, it's been in use for 2 years with only one address type.  All testing and evaluation has been done with the single type that was in use.  Anyone who has a piece of software as sensitive as Armory is not going to be recklessly upgrade a majorly sensitive operation because someone on the internet said it should be "an easy five lines of code." 

The problem is not the complexity of the change, it's the time and attention span to make sure it was done right and thoroughly tested before people use it with real money.  Anything else would be reckless, no matter how the original code was written.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
October 28, 2013, 06:36:53 PM
 #10

Regardless of how I wrote it, it's been in use for 2 years with only one address type.  All testing and evaluation has been done with the single type that was in use.  Anyone who has a piece of software as sensitive as Armory is not going to be recklessly upgrade a majorly sensitive operation because someone on the internet said it should be "an easy five lines of code." 

The problem is not the complexity of the change, it's the time and attention span to make sure it was done right and thoroughly tested before people use it with real money.  Anything else would be reckless, no matter how the original code was written.

Well, what can I say, this is one of those things where adding P2SH v2.0 or whatever else comes next should be a lot less stressful if adding P2SH v1.0 is done well.

Anyway, don't let me rush you.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2324



View Profile
October 28, 2013, 07:09:17 PM
 #11

It also expands the size of the entire chain that must be stored forever. It's really not a saving unless you consider the cost of archiving and transmitting the chain to be free. It's cheap, but it's not totally free.
Compared to pay-to-address by 1 byte per spent txout, but that data is completely predictable, so you can define a more efficient serialization of block data to disk that eliminates that overhead (or at least reduces it to ~ -log2(probability transaction is P2SH) bits).

Likewise, in the pay-to-pubkey case (where you lose the hash protection of the pubkey), sufficiently smart serialization also leaves the size the same.

Given sufficiently smart storage it pretty much can't fail to reduce size, since some txouts will never be spent... though the the fact that P2SH is limited to HASH160 is kinda lame.

Certainly if I were to redo the system it would be P2SH only (with some hashtype flag for forwards compatibility)

Bitcoin will not be compromised
jl2012
Legendary
*
Offline Offline

Activity: 1694


View Profile
October 29, 2013, 02:05:48 AM
 #12

The simplicity is over-stated.  The concept is simple and can be represented in 5 lines of code.  But the last thing I want is for a bug in my implementation to switch to the wrong conditional under some specific circumstances and send coins intended for my 1... address to an unspendable 3... address.   These kinds of changes are dangerous when all the contextual code around it was written assuming one address type.

The code in question is remarkably sensitive, and a stupid oversight in the code could lead to massive loss of coins.  Maybe I'm overstating it... but I have some users with seriously a lot of money, and I'm sure they appreciate my paranoid diligence in things like this.

For reference, once I finally get this next version of Armory locked down, I'm going to work on this and make sure there's loads of tests for it in all the available contexts.  

With all due respect, that your code was designed in such a way that is assumed one address type is something I would be a little embarrassed about myself - even in the early days it was easy to see how different types of addresses would simply have to be developed in the future if the scripting system was going to be of any use.

But in the meantime, I wouldn't be embarrassed to take however long it takes to do it right!

Regardless of how I wrote it, it's been in use for 2 years with only one address type.  All testing and evaluation has been done with the single type that was in use.  Anyone who has a piece of software as sensitive as Armory is not going to be recklessly upgrade a majorly sensitive operation because someone on the internet said it should be "an easy five lines of code."  

The problem is not the complexity of the change, it's the time and attention span to make sure it was done right and thoroughly tested before people use it with real money.  Anything else would be reckless, no matter how the original code was written.

Would it be easier to support sending to P2SH first? You just need to make sure the coin is sent to the right script, and don't have the responsibility to the redeemablity of the script.

I can imagine it is more risky to generate P2SH addresses. I usually double check the validity of an pay-to-keyhash address using bitaddress.org. I always put my tinfoil hat on when handling bitcoin. We need more independent implementations of P2SH to allow people doing such checking

The signing part may go wrong but not very risky. You may end up with an invalid transaction, but hardly sending the coin to limbo

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Pages: [1]
  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!