TBH, the proposed implementation sounds complicated as well as prone to failure (for most people, their IP changes regularly and port can be changed). You could get the same functionality by implementing one or both of these two features:
1. Allow searching the addresses/labels in the address book. Just put your friend's name in the label for all their addresses, then filter/search by that name.
2. In addition to address labels, have group/category functionality, where you can create a group/category, name it, and add any of your addresses to it. When creating a new address, you could also assign it to a group if needed.
Either one of these seems much simpler, while meeting the use case you describe.
Topic: bitcoin address feed (Read 970 times)
no comments? I would like some feedback whether this is good or bad before I try to implement it or offer a bounty.
Thanks
Thanks
Problem: I find myself manually managing pools of addresses per recipient, for both sending and receiving addresses. To improve privacy, a new address should be used for each transaction. I want to automate managing a set of receiving addresses assigned to each of my friends, as well as a set of addresses for me to send to each friend.
Proposal:
1. Extend the addressbook: for each address, add a "friend" checkbox. If "friend" is enabled, collect and store the IP address or hostname of the friend's bitcoin node, and their RPC port number. Friends are assumed to open the RPC port to each other.
2. Add a new global option: friend RPC. Say bitcoin node A has address Y marked as friend. When friend RPC is enabled, node A will accept valid RPC requests of the following form: username=(BTC address Y), password=(a timestamp, signed using BTC address Y), RPC command=getnewaddress (with no parameter). In addition to verifying the signature, the timestamp should be matched within ~5 seconds, to prevent an eavesdropper replaying the RPC command to DoS the key pool. If valid, node A will generate the new address, add it to the addressbook database using BTC address Y as the name, not the name entered in the addressbook for Y. This will permit renaming address Y without losing track of the address pool based on Y. The client should display the name associated with Y next to these other addresses.
3. Add new GUI elements to manage one address pool per friend. Example: a button to increase the pool by one, or a number field to increase it by more than one. Subtraction should not be permitted below the number of addresses in the pool, but subtraction is okay if the pool has not been filled. While the pool is unfilled, occasional RPC requests should be made to the friend as described above, to obtain new addresses and add them to the pool. Since these are friends, a button to "fill now" should be provided since the friends are likely to contact each other and say "my node's up now."
Not part of this proposal, but these other features come to mind:
Proposal:
1. Extend the addressbook: for each address, add a "friend" checkbox. If "friend" is enabled, collect and store the IP address or hostname of the friend's bitcoin node, and their RPC port number. Friends are assumed to open the RPC port to each other.
2. Add a new global option: friend RPC. Say bitcoin node A has address Y marked as friend. When friend RPC is enabled, node A will accept valid RPC requests of the following form: username=(BTC address Y), password=(a timestamp, signed using BTC address Y), RPC command=getnewaddress (with no parameter). In addition to verifying the signature, the timestamp should be matched within ~5 seconds, to prevent an eavesdropper replaying the RPC command to DoS the key pool. If valid, node A will generate the new address, add it to the addressbook database using BTC address Y as the name, not the name entered in the addressbook for Y. This will permit renaming address Y without losing track of the address pool based on Y. The client should display the name associated with Y next to these other addresses.
3. Add new GUI elements to manage one address pool per friend. Example: a button to increase the pool by one, or a number field to increase it by more than one. Subtraction should not be permitted below the number of addresses in the pool, but subtraction is okay if the pool has not been filled. While the pool is unfilled, occasional RPC requests should be made to the friend as described above, to obtain new addresses and add them to the pool. Since these are friends, a button to "fill now" should be provided since the friends are likely to contact each other and say "my node's up now."
Not part of this proposal, but these other features come to mind:
- Since we're storing the friend's node's IP and RPC port, also collect and store their P2P port number, and enable keepnode if the P2P port isn't blank.
- Consider allowing friends to run other RPC commands. The really useful one would be a PULL FUNDS request. Allow each friend a limit of BTC and allow them access to the "sendtoaddress" command (defaulting to send BTC to the next unused address associated with the friend using the above proposal, but permitting any address).
Jump to: