Can you clarify what you mean by "whitelisting all blocks before the softfork 
block"?

The most conservative approach could be to leave the code in place until the 
very last non-segwit P2SH UTXO from before the soft fork block has been spent. 
But this would never happen if even a single private key is lost.

After making these transactions non-standard and removing the code, 
transactions containing these OP-codes could be considered valid (perhaps still 
checking the signature, etc). Some miners would still run the code and mine 
those transactions, but others wouldn't verify them. This is strictly less bad 
than losing those funds forever, but doesn't seem acceptable either.

Is there a variant of the above scenario where a miner puts up some very large 
deposit (e.g. 10x the size of the UTXO) if they mine such a legacy transaction, 
and can lose that if someone else runs the code and finds the transaction 
invalid?

Sjors

> Op 15 nov. 2017, om 20:54 heeft Mark Friedenbach via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> 
> As good of an idea as it may or may not be to remove this feature from the 
> code base, actually doing so would be crossing a boundary that we have not 
> previously been willing to do except under extraordinary duress. The nature 
> of bitcoin is such that we do not know and cannot know what transactions 
> exist out there pre-signed and making use of these features.
> 
> It may be a good idea to make these features non standard to further 
> discourage their use, but I object to doing so with the justification of 
> eventually disabling them for all transactions. Taking that step has the 
> potential of destroying value and is something that we have only done in the 
> past either because we didn’t understand forks and best practices very well, 
> or because the features (now disabled) were fundamentally insecure and 
> resulted in other people’s coins being vulnerable. This latter concern does 
> not apply here as far as I’m aware.
> 
> On Nov 15, 2017, at 8:02 AM, Johnson Lau via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>> In https://github.com/bitcoin/bitcoin/pull/11423 
>> <https://github.com/bitcoin/bitcoin/pull/11423> I propose to make 
>> OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard
>> 
>> I think FindAndDelete() is one of the most useless and complicated functions 
>> in the script language. It is omitted from segwit (BIP143), but we still 
>> need to support it in non-segwit scripts. Actually, FindAndDelete() would 
>> only be triggered in some weird edge cases like using out-of-range 
>> SIGHASH_SINGLE.
>> 
>> Non-segwit scripts also use a FindAndDelete()-like function to remove 
>> OP_CODESEPARATOR from scriptCode. Note that in BIP143, only executed 
>> OP_CODESEPARATOR are removed so it doesn’t have the FindAndDelete()-like 
>> function. OP_CODESEPARATOR in segwit scripts are useful for Tumblebit so it 
>> is not disabled in this proposal
>> 
>> By disabling both, it guarantees that scriptCode serialized inside 
>> SignatureHash() must be constant
>> 
>> If we use a softfork to remove FindAndDelete() and OP_CODESEPARATOR from 
>> non-segwit scripts, we could completely remove FindAndDelete() from the 
>> consensus code later by whitelisting all blocks before the softfork block. 
>> The first step is to make them non-standard in the next release.
>> 
>> 
>> 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org 
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to