Author: Melvin Carvalho 2013-06-19 12:19:40
Published on: 2013-06-19T12:19:40+00:00
On June 18, 2013, Alan Reiner proposed an alternative address format made possible by BIP 32. This would allow for a "Wallet ID" and "One-time payment" code to be specified instead of the standard one-use Base58-Hash160 addresses. Parties with a persistent relationship would be able to prove that payment addresses they provide each other are linked to a particular wallet, reducing exposure to MitM attacks without the need for SSL or a web of trust, and without compromising the privacy of either party. This could be used between businesses that frequently do business, by exchanging and verifying public keys beforehand, or could be used by an exchange to identify if a customer withdrawal address is related to their last deposit address, and if not enforce extra authentication measures.Reiner suggests an optional second form for sending someone an address, called "wallet-linkable" addresses. With BIP 32, the address is computed by the payee (the person sending the address to receive money). The option would be to send just the {PublicKeyParent, Multiplier[i]} and let the receiver of that address compute the address on their own. This provides the useful property that they can recognize when addresses specified in this way come from the same wallet because the PubKeyParent will be the same. This is optional for the person providing the address.One downside is that the only way this works with P2SH violates one of the goals of P2SH slightly, but may not matter much if it's all done under the hood by the software. Instead of providing a 20-byte hash of a script, you provide all the public keys and multipliers for the individual addresses. The payer's software automatically verifies all addresses and creates the P2SH script itself. It requires revealing more information than is necessary for the payer to pay the payee, but it may not really be a problem given the benefits.The proposed use cases include two parties who decide they will start a relationship and exchange the public keys of their wallet and verify them in a reliable manner. After that, when one party requests a payment address from the other, they can optionally send {PubKey, Multiplier}, and the payer's software will identify the owner of that address or let you select who you think the address belongs to, and it will verify it. When a customer first provides a deposit to an exchange, it will send money from an address in their wallet, and the software will provide the exchange the {PubKey,Mult}. When the customer later provides a withdrawal address, the site can automatically trust the address as long it is provided in the alternate form and the public keys match.In conclusion, Reiner suggests an alternative address format that would allow for a "Wallet ID" and "One-time payment" code to be specified instead of the standard one-use Base58-Hash160 addresses. This new format allows for persistent relationships and reduces exposure to MitM attacks without compromising privacy. The downsides include violations of P2SH goals and revealing more information than necessary. Use cases include businesses frequently doing business and exchanges identifying customer withdrawal addresses.
Updated on: 2023-06-06T18:58:14.573817+00:00