Open Steve132 opened 6 years ago
schancel
commented
6 years ago It seems like this requirement makes no sense/is ambiguous then, because if a wallet makes a different sighash than a node, then it will become incompatible.
This is what's supposed to happen, in November. Between now and November, another upgrade specification will be produced, which will use forkID 0 at the date of the hardfork.
Steve132
commented
6 years ago This is what's supposed to happen, in November. Between now and November, another upgrade specification will be produced, which will use forkID 0 at the date of the hardfork.
So are you saying that, according to the spec, wallets that are not fullnodes are not supposed to be capable of signing and broadcasting transactions between now and november?
schancel
commented
6 years ago @Steve132 No, they are supposed to work. The new forkid for nodes, following this version of the Bitcoin Cash spec, changes in November.
Steve132
commented
6 years ago I said "If a wallet makes a different sighash than a node, then it will become incompatible" in reference to the fact that the spec says "Update forkid[1] to be equal to 0xFF0001. ForkIDs beginning with 0xFF will be reserved for future protocol upgrades.This particular consensus rule MUST NOT be implemented by Bitcoin Cash wallet software."
So, lets assume that we are now in december of 2018. Therefore, following this specification, nodes are now using a forkID of 0xFF0001. However, also following this specification, wallets use a forkID of 0.
Two different forkIDs, so transactions from wallets cannot be verified by nodes in Dec2018 because they now have different sighash algorithms. Right? What am I missing?
Either wallets must also change their forkID to 0xFF0001 to match by Dec2018 (in which case, what does the 'wallets must not do this' part mean?!) OR nodes must use a forkID of 0 during Dec2018 and ignore this part of the spec completely (in which case, why even have this written here?!) OR it is intended behavior that "conforming" wallets are no longer compatible with the network (in which case, why would someone conform to a spec that makes their wallet not work?)
My point is this: The spec, as written, seems to introduce an incompatibility between wallets and nodes after the date of the november hardfork. Either the spec is wrong, or cannot be followed by wallets, or my interpretation is wrong.
I can make this simple: Can you clarify, specifically, what the value of forkID will be in each of the following cases during each of the following times? Like, can you fill in this table for me?
| Date | forkID (Wallets) | forkID (Nodes) |
|---|---|---|
| Now | ||
| After Nov2018 |
The forkid version change effects the replay protected sighash. The forkid change for the may 2018 hardfork is specified to "not be implemented for wallets". Does that mean that sighashes will be different based on whether the compiled code is a fullnode or a wallet? How will transactions verify? It seems that if I create a transaction and sign it using a wallet that is using the old forkid, then try to broadcast or relay the transaction using a Full node that has a new forkid, the signature hash will be different and the transaction will not relay or verify.
It seems like this requirement makes no sense/is ambiguous then, because if a wallet makes a different sighash than a node, then it will become incompatible.
How is this supposed to be implemented?
Side question: why is it necessary to update the forkid for the sighash at all here? It doesn't seem necessary for all hardforks. We needed to change the sighash for the btc hardfork because the hardfork was contentious and we were trying to achieve a chain split....but since we explicitly want to avoid a chain split in may2018 why wouldn't we just rely on Nakomoto consensus?
It seems unsustainable and buggy to continually update the forkid on every hardfork. It will introduce an exponential amount of work to maintain block explorers, wallets, and other libraries to compensate. I'm concerned that it will tax engineering resources to develop the ecosystem or even could result in bugs that will lose user funds.