ribuck

Hero Member



Offline



Activity: 826

Merit: 1007







DonatorHero MemberActivity: 826Merit: 1007 Re: Withdrawing BIP 17, and proposing BIP 18; please review patch March 14, 2012, 01:36:37 PM #6 Quote from: theymos on March 14, 2012, 12:14:28 AM I don't see a point in "officially" depreciating something that must be supported forever anyway.

The reason for official deprecation is so that developers know that future enhancements are unlikely to be developed for the deprecated part of the system.



This keeps the actively-developed portion of the software as small as possible. This reduces the risk of bugs and security holes being introduced in the future, and makes coding and testing easier.



If the old way of doing things is completely subsumed by a new and better way, the old way should definitely be deprecated. The reason for official deprecation is so that developers know thatenhancements are unlikely to be developed for the deprecated part of the system.This keeps the actively-developed portion of the software as small as possible. This reduces the risk of bugs and security holes being introduced in the future, and makes coding and testing easier.If the old way of doing things is completely subsumed by a new and better way, the old way should definitely be deprecated.

realnowhereman



Offline



Activity: 504

Merit: 500









Hero MemberActivity: 504Merit: 500 Re: Withdrawing BIP 17, and proposing BIP 18; please review patch March 14, 2012, 03:05:55 PM #7



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



Code: From WordNet (r) 3.0 (2006) [wn]:



deprecate

v 1: express strong disapproval of; deplore

2: belittle; "The teacher should not deprecate his student's

efforts" [syn: {deprecate}, {depreciate}, {vilipend}]



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

realnowhereman



Offline



Activity: 504

Merit: 500









Hero MemberActivity: 504Merit: 500 Re: Withdrawing BIP 17, and proposing BIP 18; please review patch March 15, 2012, 10:06:28 AM #17



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):



Code: OP_PUSH <signature>

OP_CODESEPARATOR

OP_PUSH <public key>

OP_CHECKSIGVERIFY



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.

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

Tril



Offline



Activity: 213

Merit: 100







Full MemberActivity: 213Merit: 100 Re: Withdrawing BIP 17, and proposing BIP 18; please review patch March 16, 2012, 03:34:35 PM #19 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.

