Topic: Withdrawing BIP 17, and proposing BIP 18; please review patch - page 2. (Read 3480 times)
Good!
I don't see a point in "officially" depreciating something that must be supported forever anyway.
I just had a few minutes to skip BIP 18, but I like it so far. Is there any reasons we would not want to depreciate the scriptPubKey/scriptSig system? In other words, is there any use case for knowing the actual script ahead of time?
Unfortunately, with the advent of Deepbit adding BIP 16 support, the possibility of BIP 17 being implemented is pretty much gone. I therefore regret to announce the official Withdrawl of BIP 17. If anyone else wants to take over as its "champion", feel free to re-open it, but I am convinced it is a lost cause at this point. Short of something major happening within the next day or two, I will be switching Eligius (my pool) over to BIP 16, and merge backported BIP 16 support into the future 0.4.5 and 0.5.4 stable releases.
However, BIP 16 isn't completely irreparable: I am proposing BIP 18 as the next step forward. This proposal is 100% protocol-compatible with BIP 16 and requires no software changes at all. It is simply a formal rewriting of the specification in a more consistent manner, and implies developers will make a full commitment to P2SH, using it for all new address/transaction types (without breaking compatibility with "legacy" addresses).
Finally, Gavin's BIP 16 backport does not merge cleanly into 0.4.x/0.5.x, and seems to have fallen behind on a few fixes made in the "master" branch. I have attempted to resolve this, but would appreciate as many reviews of it as possible before merging to stable. Unlike BIP 17, the code to implement BIP 16 is very complicated and hard to follow, so there is plenty of room for error.
Edit: Gavin noted the backport doesn't need to actually mine P2SH into blocks, so here is a simpler patch that only validates them. Please audit this one instead.
However, BIP 16 isn't completely irreparable: I am proposing BIP 18 as the next step forward. This proposal is 100% protocol-compatible with BIP 16 and requires no software changes at all. It is simply a formal rewriting of the specification in a more consistent manner, and implies developers will make a full commitment to P2SH, using it for all new address/transaction types (without breaking compatibility with "legacy" addresses).
Finally, Gavin's BIP 16 backport does not merge cleanly into 0.4.x/0.5.x, and seems to have fallen behind on a few fixes made in the "master" branch. I have attempted to resolve this, but would appreciate as many reviews of it as possible before merging to stable. Unlike BIP 17, the code to implement BIP 16 is very complicated and hard to follow, so there is plenty of room for error.
Edit: Gavin noted the backport doesn't need to actually mine P2SH into blocks, so here is a simpler patch that only validates them. Please audit this one instead.
Jump to: