I am not thinking anything. Simply stating a fact. The product design required trust in the developer and the company. Granted, very little, but still some. This randomness issue should have been a central focus of the dev, and if it couldn't be proven, the feature should have been removed. This is evidence of architectural failure. Whether flaws were designed-in to be exploited at some plausibly deniable distance-in-time, or if they were pure mistakes, still shows an architectural failure in the system and design goals. A product like this should retain zero "trust me bro" in the design. I was never comfortable with recommending it to friends and family. When they would ask about it, I would say "I'm not sure, but it looks like a good option". Never would I saw "This is provably secure with generating and storing your keys". There were too many unaddressed concerns, where there should have been none. I treated them as newbie devices. When you pile on the pattern of behavior of the developer when confronted with criticism, that adds to the concern. Now that a bug has been exposed that, from a design perspective, in my opinion should have been left out as a feature because of pure uncertainty around lack of audit, the evidence points to the direction that coinkite's judgment should be questioned and treated adversarially. This should have already been understood even without evidence to the effect. One should always verify and not trust. When you cannot verify, then your alternative is still not to trust. Your alternative is to find a way to eliminate trust. I'd like to know why people should entertain less secure alternatives as a replacement when there is @SeedSigner