The reconciliation protocol assumes using one role consistently. Since it is irrelevant which one is which, we can imply that the initiator of the P2P connection will assume the role of reconciliation initiator.
This protocol simplification will seep into the implementation.
The reconciliation protocol assumes using one role consistently. Since
it is irrelevant which one is which, we can imply that the initiator of
the P2P connection will assume the role of reconciliation initiator.
This protocol simplification will seep into the implementation.
Having two booleans means we have to deal with all 4 cases:
Allowing only 2. and 3. means we can have just one boolean and derive the value of the other from it.
However, since it is completely irrelevant which one is which we can just assign the roles based on who is the P2P connection initiator. https://github.com/bitcoin/bitcoin/pull/23443 does that (+ trying to handle the nonsensical cases).
I think this redundancy can be a source of confusion and/or bugs.
The idea behind two non-implied roles was future upgradeability, which might be not based on the connection.
The fact that you caught a (comment) mistake in the code which was acked and near-merged is probably a good argument towards dropping this redundancy. @sipa what do you think?
@naumenkogs I'm fine with just making the reconciliation direction fixed by the protocol. There is still a version number in sendtxrcnl, which could be used for future extensions.
Then I hope for the following events to occur shortly:
(unless we come to a different opinion in the meanwhile) (also unless it takes too long and Luke rushes us to do something :))
I missed this was a PR already.
ACK 8b107a0af6c0566d524041ac6c96678c88bb3b3b
@vasild kinda unrelated to this PR. I'm not sure we have to always seek a synchronization between BIPs and master. I expect this BIP to be updated at least couple more times along the Erlay merging, and I think it's no big deal if e.g. the lag is one month.
Sounds good to use the version for future upgrades - then the sendtxrcncl can be expanded/appended with further data as needed.
Yeah, the waterfall model where design is followed by implementation rarely works. There will be iterative steps where some mods will be done to the design while the implementation is happening. We just have to keep in mind alternative implementations and not let things diverge too much for a long time, in case somebody implements stuff based on an outdated spec.
ACK 8b107a0af6c0566d524041ac6c96678c88bb3b3b
