Should we change the default to P2SH?

[jl2012]

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?

[1714799328]

1714799328

[1714799328]

1714799328

[justusranvier]

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]

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.

[Mike Hearn]

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]

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

[Peter Todd]

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]

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. 

[Peter Todd]

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]

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.

[Peter Todd]

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]

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)

[jl2012]

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