Re: [bitcoin-dev] Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard

[Mark Friedenbach via bitcoin-dev]

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 
>  wrote:
> 
> In 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
> 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

[bitcoin-dev] Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard

[Johnson Lau via bitcoin-dev]

In 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks

[Jacob Eliosoff via bitcoin-dev]

>
> Sorry, I was careless with the use of `>=` there. You are correct, forks
> form a tree. For this proposal, every leaf must be assigned a unique
> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which
> number is bigger), as long as they are unique. Transactions are only valid
> IFF `nForkId` matches exactly the `nForkId` of the software validating it.
> As described above, the transaction doesn't even contain `nForkId`, and the
> node surely is not starting to guess which one it could be.
>

OK, but then it seems to me you have a dilemma for, eg, your LN commitment
tx.  You either give it the specific nForkId of the fork it's created on -
making it invalid on *all* other forks (eg, any future "non-contentious
upgrade" HF that replaces that fork).  Or you give it nForkId 0 - which has
the "BCH tx valid on Segwit2x (& vice versa)" flaw.

It may make sense to revise your proposal to incorporate Luke's
OP_CHECKBLOCKATHEIGHT
, and make
the fork ID a (block height, hash) pair rather than just a number.  But I
still think the idea of fork-specific addresses is a keeper!


On Tue, Nov 14, 2017 at 8:49 AM, Mats Jerratsch  wrote:

>
> But I like the 'old' idea of putting the hash of a block that MUST be on
> the chain that this txn can eventually be added to. If the hash is not a
> valid block on the chain, the txn can't be added.
>
> It means you can choose exactly which forks you want to allow your txn on,
> pre-fork for both, post-fork for only one, and gets round the issue of who
> gets to decide the nForkid value.. since you don't need one. Also, all the
> old outputs work fine, and LN not an issue.
>
> I'm missing why this scheme would be better ?
>
>
> I do agree that solutions like `SIGHASH_BLOCKCOMMIT` are superior in the
> sense that they are very difficult to circumvent. However, a fork could
> also follow the original chain in SPV mode and allow transactions protected
> with these mechanism. Since it's fundamentally impossible to disallow
> transactions in future projects, the goal shouldn't be to make this overly
> complicated.
>
> Furthermore, this schema is not just adding replay protection. It makes
> transacting safer overall (due to a dedicated address format per fork) and
> allows light clients to differentiate between multiple forks. In the past
> three months, at least $600k has been lost by users sending BCH to a BTC
> address [1].
>
> Thanks for the clarification.  How would a tx specify a constraint like
>> "nForkId>=1"?  I was thinking of it just as a number set on the tx.
>>
>
> Whether the transaction is replay protected or not is specified by setting
> a bit in the `SigHashId`. If this bit is set, then the signature *preimage*
> MUST have `nForkId` appended. `nForkId` is not part of the final
> transaction, someone who wants to verify the transaction must know which
> `nForkId` it was created with.
>
> If the bit isn't set, it means `nForkId=0`, which allows other forks to
> validate the signature.
>
> Also note that since forks form a partial order, but IDs (numbers) form a
>> total order, ">=" will miss some cases.  Eg, suppose BCH had forked with
>> nForkId 2, and then you set up a LN funding tx on BCH with nForkId>=2, and
>> then Segwit2x forked (from BTC!) with nForkId 3.  The BCH funding tx would
>> be valid on Segwit2x.  This is more of a fundamental problem than a bug -
>> to avoid it you'd have to get into stuff like making each fork reference
>> its parent-fork's first block or something, someone has written about
>> this...
>>
>
> Sorry, I was careless with the use of `>=` there. You are correct, forks
> form a tree. For this proposal, every leaf must be assigned a unique
> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which
> number is bigger), as long as they are unique. Transactions are only valid
> IFF `nForkId` matches exactly the `nForkId` of the software validating it.
> As described above, the transaction doesn't even contain `nForkId`, and the
> node surely is not starting to guess which one it could be.
>
> [1]
> https://twitter.com/khannib/status/930223617744437253
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev