|
Title: Why not add other options to the Change mechanism of Bitcoin client. Post by: snoleo on August 29, 2013, 08:43:33 AM The bitcoin change mechanism is explained at here :
https://en.bitcoin.it/wiki/Change I'd like to suggest applying two additional options (as B & C in the following) for users to choose from in the bitcoin client: A. When sending the change, generate a new address (in the default the first 100 addresses are generated in the current keypool beforehand), and send the change to this address (the current mechanism). B. When sending the change , choose a random address from the current keypool, and send the change to this address. C. User can choose an address from the current keypool (must from the current keypool) as the receiving address which all the changes will be sent to. When user choose B or C, the backup of the wallet.dat will never become invalid since there will be no newly generated addresses beyond the current keypool size. In face, generating new addresses for changes will not make the trace for one account's transactions impossible but only make it more difficult or more time-consuming. Many junior users will also get confused when their wallet contains large number of newly generated addresses that all belong to themselves after they make many transactions. Title: Re: Why not add other options to the Change mechanism of Bitcoin client. Post by: He1l_Q on August 29, 2013, 11:08:20 AM Good idea!
Title: Re: Why not add other options to the Change mechanism of Bitcoin client. Post by: TierNolan on August 29, 2013, 01:12:54 PM The bitcoin change mechanism is explained at here : https://en.bitcoin.it/wiki/Change I'd like to suggest applying two additional options (as B & C in the following) for users to choose from in the bitcoin client: A. When sending the change, generate a new address (in the default the first 100 addresses are generated in the current keypool beforehand), and send the change to this address (the current mechanism). B. When sending the change , choose a random address from the current keypool, and send the change to this address. C. User can choose an address from the current keypool (must from the current keypool) as the receiving address which all the changes will be sent to. When user choose B or C, the backup of the wallet.dat will never become invalid since there will be no newly generated addresses beyond the current keypool size. Deterministic wallets solve this too. A wallet which is banned from creating new addresses would also achieve the same thing. You press a button and 500 private keys are generated and then you backup that wallet. |