I don't see a point in "officially" depreciating something that must be supported forever anyway.

I agree.

I assume we're actually talking about "deprecation" not "depreciation" ("depreciation" being pretty meaningless in this context)...

Deprecation is not obsolescence; and seems the perfect word for it to me.


1 being the obvious definition here.

"deprecate" is used all over the place in software.  It means a feature who's use is discouraged.  Perfect.

I do. By officially deprecating it, that could mean that we will remove the ability to make new legacy transactions in a future hard fork. Eventually, another hard fork could remove it altogether, destroying any still-unspent legacy outputs.

^This.   Although I see the value in P2SH or any similar system, I am deeply concerned about the backup issues.  I put in a lot of work to make paper backups in Armory, to make it as simple as possible for users to make one backup ever, and not have to worry about it again.  "Regular users" who must rely on a consistent backup solution will fail.  It doesn't happen.  No matter what you do, they will forget to set it up, not realize their backup drive was disconnected, not set it up again after a system restore, or reinstall OS, etc.

But with proposals that require all everything to be hidden behind script hashes: your wallet must be backed up (or at least the script information) after every single transaction.  Your system dies right after a transaction before you've had a chance to save the script, and you'll never recover it again.  This is something I'm battling with multi-sig scripts, but was comforted by the fact that at least regular users who want to avoid all of it don't have to deal with it and can use regular addresses which can be scanned for in the blockchain.

That's what this thread was about.  Gavin addressed the issue for multi-sig and escrow.

There are some possible scripts whose properties depend on being public. David Schwartz describes one here that achieves anonymous donations/transfers, although it requires new opcodes for the scripting system.

Such a system would not be possible under P2SH.

Script can be public and not part of the transaction.

Post the script somewhere public and you have a public copy of the script.
A more elegent solution would be a cloud based repository of scripts.
A p2p solution would be a DHT that users can submit scripts to and query scripts based on their hash.

Just for information:

There is a mapping from current bitcoin public key, to p2sh receiving address; just as there is a mapping from public key to non-p2sh address.  There's no need to keep scripts around on disk, nor really to worry about all your addresses changing.  Both those things can be handled with a bit of clever software and access to the public key (which is available in current scriptPubKey standard scripts).

Perhaps I'm misreading Maged's concerns, but there is no need to worry that one deterministic backup isn't enough.  The public and private keys remain the same.  What changes is the way the public key is converted to an address.

For a given public key it will always be the hash of the script (or equivalent):


Note that since the <signature> bytes will not (cannot) be included in the hash of this script, there is no part of it that changes with different transactions; so it is always the same hash and therefore always the same receiving address.

Hi, please bear with me I have not had time to study the code and bitcoin protocol and understand how scripts work in depth, but as a bitcoin user and miner, I have been wondering since BIP16 and 17 have been introduced:

Why does BIP16 NOT vastly increase the options for pre-computing hash collisions?  If we're not sending scripts anymore, but hashes of scripts, then the more expressive the script language, the more ways there are to try to make a script that hashes to something known: to scan the blockchain for unspent transactions and attempt to come up with a matching hash that pays the attacker.  Even with something as simple as paying to multiple bitcoin addresses script, you can pre-generate a billion bitcoin addresses, then find some combination and ORDERING of the script to pay those addresses whose hash collides with another script.  The more opcodes and the longer you allow the script to be, the more dangerous this becomes. 

If new opcodes are ever added, can we guarantee there be restrictions preventing the new opcodes from working on scripts generated before the opcodes were added, to not allow retro-active additions to the script language to prevent brute forcing collisions for old addresses?

Does the existing script language require strict sorting of addresses in advance to prevent the above attack? Does the existing language disallow inserting NO-OP opcodes to increase the number of scripts you can attempt to collide with?  Possibly I'm just missing something and the script language is far less expressive than it seems, but it looked like it contained a stack, as well as a no-op, as well as the ability to include "user-supplied data" (a bitcoin address).  Something that allows inserting other script hashes into the script makes it exponentially more dangerous.  I'm hoping I'm completely off base here, but I haven't seen this addressed anywhere.