mflaxman · April 12, 2021 17:03 · Apr 12, 2021
diff --git a/wallet ID thoughts.txt b/wallet ID thoughts.txt
@@ -0,0 +1,37 @@
+Separately, I'm now conflicted on whether the first address should be encoded in some non-address format, so that there is no ambiguity for end-users.
+
+Here's one imperfect solution that would be trivial for any bitcoin wallet developer to implement:
+1. Fetch receive address 2,147,483,647 (`2^31 -1`) for the descriptor record, let's call this address X
+2. Calculate the double-sha256 digest of X in hex
+3. Truncate to something more reasonable, perhaps 160 bits (40 characters in hex)
+4. Prepend some identifier for UX, I suggest `MW-` (multisig wallet).
+
+I find code much clearer as a way to communicate, here is what that looks like in python:
+```
+>>> from hashlib import sha256
+>>> RECEIVE_ADDRESSS = "tb1qlrjv2ek09g9aplga83j9mfvelnt6qymen9gd49kpezdz2g5pgwnsfmrucp"
+>>> encoded_address = sha256(sha256(RECEIVE_ADDRESSS.encode()).digest()).hexdigest()
+>>> print("MW-" + encoded_address[:40])
+MW-82bd5553796fe13b8244368d56eed9997893b953
+```
+
+Or in bash:
+```
+$ echo -n MW- && echo -n tb1qlrjv2ek09g9aplga83j9mfvelnt6qymen9gd49kpezdz2g5pgwnsfmrucp | openssl dgst -sha256 -binary | openssl dgst -sha256 | cut -c 10-49
+MW-82bd5553796fe13b8244368d56eed9997893b953
+```
+
+Bech32 encoding would be even better as it's designed to handle this problem, but then it starts to look like an address to end-users and we're back to square 1.
+
+--
+
+Pros of encoding:
+* Using an address as a wallet ID is inherently confusing, in an already confusing process.
+* Some users will mistakenly think this is the only address they're supposed to use, and this will encourage address re-use.
+* This (gently) encourages poor privacy practices as it links one address to your multisig wallet. Perhaps you have a file backed up to the cloud that lists your assets, and one entry is called `Bitcoin Wallet ID [FIRST RECEIVE ADDRESS]`. An entry called `Bitcoin Multisig Wallet MW-82bd5553796fe13b8244368d56eed9997893b953` leaks no information (unless of course you create a transaction to/from the 2,147,483,647th address).
+
+Pros of just using the first receive address:
+* If users do send bitcoin to that address, they can easily spend it. There is no risk of loss.
+* Bech32 is already designed to make manual verification as easy as possible.
+* It requires very minimal developer effort and has less complexity.
+* Privacy conscious users saving data in the cloud could reference their wallet by its bitcoin core checksum. It should be ovbious to even newbies that saving a bitcoin address in the cloud is a privacy concern.
No results found