Topic: Proposal: usage and termonology of a BIP32 wallet (Read 1165 times)

Yes you only need give a hash to the sender.
I meant that if the user wishes to take advantage of the key homomorphism property of ECDSA/BIP32, he can give the sender the account numbers of his smartphone and laptop accounts, and then the sender could generate fresh addresses by himself, instead of asking the user for a new address every time. We've discussed use cases for this, start for example at https://bitcointalksearch.org/topic/m.1496121

I don't really understand P2SH. I thought that all the user would need to provide to the sender is a hash.

I agree in general that it's a good idea to make the Bitcoin client operate (by default) in a simple way that influences users to conform with security guidelines and match the vast majority of common use cases.
However, we should consider whether what you suggested indeed covers all the common use cases. One particular point that we should keep in mind is that BIP32 is a standard for creating keys rather than Bitcoin scripts/addresses. So for example if the user wishes to enhance his security by using a P2SH address that can be redeemed via one privkey that resides on his smartphone and one privkey that resides on his laptop, then he will need to give the sender a pair of account numbers (one that belongs to his smartphone's BIP32 wallet and one that belongs to his laptop's BIP32 wallet), and each time that the sender wishes to send a payment he will construct a script from two fresh pubkeys and thereby derive the P2SH address to send the coins to?

Impressive but I think it will require quite a lot of work getting people to convert to this "new" standard.

re: http://bitcoinism.blogspot.com/2013/07/reclaiming-financial-privacy-with-hd.html



Depth=1 nodes are called accounts. The GUI is focused around displaying accounts. The textual representation of an account's extended public key is called an "account number"

Account 0 is reserved for internal use, to create change addresses and individual use addresses. Requesting a single address from the client should be considered deprecated and require multiple clicks to reach in the GUI.

When a user wants to receive bitcoins, they are encouraged to make a unique account number for each entity that will send them money. They should also be told not to share the account number with anyone other than the intended sender.

A "Receive Bitcoins" function should enquire whether to receive to a new account or an existing account, and should ultimately return an account number (not an address). If the user creates a new account, she should be asked for the name of the sender who will be depositing bitcoins to that account (for address book purposes).

Accounts can be disabled, which means the client no longer scans them for incoming transactions, but can always be enabled in the future.

Services which send bitcoins to users should start asking for account numbers instead of addresses. Services which accept bitcoins from users should create a different Bitcoin account for each registered user and provide them with the account number.

Clients should save account numbers with their associated address book entry, keep track of the most recently used address in that account, and automatically use the next address in the sequence when a user requests to send a payment.

Privacy conscious users should be able to tell their client to use multiple transactions when necessary to avoid associating inputs from different addresses as described in the link above.

Any two entities which want to exchange bitcoins between themselves should only need to exchange account numbers once. From that point on, each one has the information needed to generate every destination address that they will ever require.

As a user, I install a new Bitcoin client and create a wallet. I create account numbers for Mt Gox, Coinbase, LocalBitcoins, my mining pool, etc. I then log in to the website for all those services and update my profiles with their respective account numbers. I also save the account number each one of those services gives me in my client so that I can just "Send 1 BTC to Mt Gox" from the client and the funds will automatically arrive at the correct address.

Calling extended public keys "account numbers" will map well to what users are already familiar with in terms of banking. Recipients can easily track payments from specific customers without requiring address reuse and its associated harm to financial privacy.