Open nuttycom opened 1 week ago
str4d
commented
1 week ago Furthermore, users of the SDK should not have to know about ephemeral addresses in general
That's irrelevant to the FFI interface, which is internal to the SDK. It's fine to have a separate method here, that is used alongside the existing method inside the SDK without exposing it.
nuttycom
commented
1 week ago Furthermore, users of the SDK should not have to know about ephemeral addresses in general
That's irrelevant to the FFI interface, which is internal to the SDK. It's fine to have a separate method here, that is used alongside the existing method inside the SDK without exposing it.
What is the advantage to having two separate methods here?
@daira can you expand on why you think it should be a separate FFI method? IMO that just increases complexity for consumers. This method is specifically intended to return addresses that the app needs to check to find UTXOs belonging to the wallet, and in that respect there is no difference between the transparent addresses that the wallet has generated; remember that these are effectively external addresses: counterparties may use them to return funds to the wallet, so they are "public" information. The only reason that we generated them using a separate key path is we wanted to ensure that they would not collide with transparent addresses generated from a bitcoin-derived wallet.
Furthermore, users of the SDK should not have to know about ephemeral addresses in general; we should not create yet another logical category of addresses that wallet developers need to consider when evaluating how to protect users' privacy. We want to avoid linking transparent addresses to one another, irrespective of whether those addresses are provided by the user to a counterparty directly, or indirectly as the consequence of a ZIP 320 transfer.