On Sun, Jun 14, 2015 at 7:02 PM, Gregory Maxwell wrote: > I'm not a great fan of this proposal for two reasons: The first is > that the strict ordering requirements is incompatible with future > soft-forks that may expose additional ordering constraints. Today we > have _SINGLE, which as noted this interacts with poorly, but there > have been other constraints proposed that this would also interact > with poorly. > I'm not clear on why this is a problem, so long as the canonical ordering BIP is *optional*. Unless there is a specific plan to soft fork a change that would break the BIP and it is fairly imminent, I see this only as a reason not to integrate it into isStandard(). > The second is that even absent consensus rules there may be invisible > constraints in systems-- e.g. hardware wallets that sign top down, or > future transaction covenants that have constraints about ordering, or > proof systems that use (yuck) midstate compression for efficiency. Right > now, with random ordering these applications are fairly > indistinguishable from other random uses (since their imposed order > could come about by chance) but if everyone else was ordered, even if > wasn't enforced.. these would be highly distinguishable. Which would > be unfortunate. Maybe they shouldn't be doing that. :-P > I think perhaps the motivations here are understated. We have not seen > any massive deployments of accidentally broken ordering that I'm aware > of-- and an implementation that got this wrong in a harmful way would > likely make far more fatal mistakes (e.g. non random private keys). > In my reading of various wallet client sources, it is common that wallet clients will use cryptographically weak sources of randomness to sort outputs -- that is, the ones that actually bother to randomly sort. I can hunt down some examples if this would substantially contribute to the discussion. As an alternative to this proposal the ordering can be privately > derandomized in the same way DSA is, to avoid the need for an actual > number source. If getting the randomness right were really the only > motivation, I'd suggest we propose a simple derandomized randomization > algorithm--- e.g. take the order from (H(input ids||client secret)). > This sounds similar to an idea that Sergio pitched to me privately, which was for wallets to have a private sorting key that they can use to sort inputs and outputs. However, I suspect that adding yet another key which will necessarily require special key rotation rules and maybe special backup procedures will mean that this standard will not be widely adopted any time soon. Ideally, I'd like to see someone write a different BIP with the sorting key idea and let them compete in the wallet client market rather than trying to anticipate what is best for all clients and distilling two good ideas into one artificially. -Kristov