16:27:31 <UkoeHB> On further reflection I decided to ACK tevador's boolean relative lock proposal for the next HF. It is not clear *right now* that there would ever be meaningful adoption, the rule is cheap enough to give proponents the opportunity to prove its desirability (which would be a nice win for the project/ecosystem).
16:28:19 <UkoeHB> The privacy attributes of a boolean lock are worse than no lock, but it *is* an incremental privacy improvement over current timelocks, and I favor judicious incremental improvements over all-or-nothing.
16:31:02 <UkoeHB> If the 'experiment' succeeds we can look at an approach with stronger privacy (ring sig or baked into the curve tree proof). If it fails, we can kill it just like current timelocks are slated for the axe.
22:34:26 <br-m> <torir:unredacted.org> I also ACK the boolean relative lock (the simple "leaky" lock). I'd prefer doing it as a soft-fork after the FCMP hard fork, just to not delay the fork further, but will support if others want to release with the HF. BasicSwapDex currently relies on timelock support on the non-Monero chain in a swap between Monero and another  [... too long, see https://mrelay.p2pool.observer/e/lsqLmp0LRXFBUzhm ]
22:34:26 <br-m> <torir:unredacted.org> I'd also like to point out that on-chain data is not sufficient to indicate actual use of relative locks. Relative locks are ideally only published in the case where one party is not cooperative in a swap or channel. This means that the vast majority of transactions relying on relative locks might not actually ever appear on t [... too long, see https://mrelay.p2pool.observer/e/lsqLmp0LRXFBUzhm ]
22:36:50 <br-m> <torir:unredacted.org> I should note that I'm not a BasicSwapDex developer, merely an observer. This is my non-authorative opinion.
22:44:25 <UkoeHB> torir: good point about publication. Adoption can be gleaned somewhat from activity around payment channel services. Like how rbrunner7 concluded multisig is barely used due to a lack of multisig-related issues cropping up.