Removing SIGHASH_FORKID and implementing replay protection in a different way

Technical
#1

Original post, in Polish language: Replay protection zrobione lepiej, czyli jak to powinno wyglądać - Polskie Forum Bitcoin

As far as I know, SIGHASH_FORKID is still present in BCH. If that’s the case, then in my opinion, it should be replaced with something better. The reason is simple: it breaks previous timelocked signatures, before the split. The locktime field in transactions was present since 2009, so we can safely assume, that it could be used before to create some transactions like “Now we have 2015, and this transaction will be valid in 2025 or later, unless I will move the same coins in a different transaction earlier”.

So, how to implement it better? The answer is SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, where the same amount is present on a single input, and a single output. Then, such transaction could be free for each user, if such input was present in any block before the split, otherwise currently used fees should apply. Then, miners could automatically collect such transactions with such sighashes, construct huge transactions with N inputs and N outputs, where N coins would be splitted at once, by including a single coinbase output.

Of course, to avoid locking users with timelocked SIGHASH_FORKID, I think both options, with and without this flag, should be accepted in the future.

#2

We are not changing the forkid bit right now during upgrades anymore (ABC used to do it for the old chain after upgrade time, their so-called “automatic replay protection” otherwise known as poison pill).

We can leave “better replay protection” implementation up to any chain that wants to fork away from BCH. Or from BTC. Or from XEC (if they still use that scheme).

Nobody has come forward since 2017 with a timelocked transaction that has been disadvantaged by the replay scheme chosen by BCH.

Somehow it was a only an issue before BCH forked, and from a very particular crowd of developers that rhymes with “Sore”.

Effectively, the forkid was set to zero on BCH main chain anyway - the replay protection was done via the digest method that was also implemented in 2017 for auxiliary purposes (reducing malleability).

2 Likes
#3

In other words, this feature is deprecated.

If it doesn’t break anything and it doesn’t make anything less efficient, I would suggest not to touch it as in the saying “don’t fix what is not broken”.

PS.

Also, on a side note @garlonicon, I wouldn’t waste my time on forum.bitcoin.pl, that forum is full of speculators who are only interested in price - which is the reason I left it in 2018 or so.

Posting highly technical topics there is a complete waste of time, that forum was over in 2018 and is essentially a village full of barbarians.

Casting pearls before swines.

Tak na boku, @garlonicon, to nie marnowałbym swojego czasu na forum.bitcoin.pl, tamto forum jest pełne spekulantów, którzy są zainteresowani wyłącznie ceną - co jest powodem dlaczego opuściłem to forum w 2018 czy coś koło tego.

Pisanie wysoko technicznych tematów tam jest kompletną stratą czasu, tamto forum skończyło się w 2018 i jest właściwie wioską pełną barbarzyńców.

Rzucanie pereł przed wieprze.

#4

Correct. And if this forum didn’t have a 20-character limit I wouldn’t need more than one word.

#5

Huh? 20-character limit?

You mean the title?

#6

No, comment replies must be > 20 chars

#7

To be pedantic, the feature was introduced with a default value of zero which is equal to turning the feature off.

So this deprecated feature has never actually been turned on. Cold war style.

If in a future point in time BCH decides to remove this deprecated feature, that would be entirely without cost to the wider ecosystem.

1 Like
#8

I guess more fitting name is “dead on arrival feature” then.

#9

Again, for better or worse, ABC was using this feature to “turn off” (= split off into their own networks) the outdated chains after upgrades.

This isn’t viewed as something we need any longer. Was done for a couple of years though.