Quote from: BurtW on August 22, 2014, 03:57:24 PM

Quote from: jonnybravo0311 on August 22, 2014, 12:59:22 PM

BurtW, thanks for the informative replies! You state that using any address (be it a vanity address or a randomly generated one) multiple times poses privacy risks. What's your stance on mining in pools? Some pools (Eligius, p2pool, etc) use a BTC address as your worker name, and pay directly to that address as part of the generation transaction. Other pools (GHash, BTCGuild, etc) use a wallet address that you provide to send you payouts.

I mean, I suppose if I were entirely paranoid, every time a block was found or a payment was made I could reset my miners/pools to use different addresses, but that seems a bit like setting up a faraday cage in my basement and wearing a tin foil hat Wink

OK you have hit on a pet issue of mine so sorry in advance for the long post.

My position is that every periodic payment should be done using deterministic key pair generation. Of course this includes all mining payouts. The way this would work is that instead of generating a normal private/public key pair and giving the Bitcoin address of the public key to your mining pool for payout you would generate an extended private/public key pair and give the extended public key to the mining pool.

An extended public key contains within it the first public key and information on how to generate an entire sequence of public keys that correspond to the same key pair sequence that is generated by the extended private key. So the mining pool would send your first payment to the first public key, your second payment to your second public key, your third payment to your third public key, etc.

Meanwhile your client can generate the first private key that corresponds to the first public key, the second private key that corresponds to the second public key, etc. so you can claim/spend the BTC when you are ready.

This way every single periodic payment can be sent to a unique public address. Cool, right?

However, I do not know of a single pool that supports this payment mechanism. I do not keep up with all the various mining pools having given up mining at the end of the GPU mining era myself. So, if there is a pool that supports this please let me know.

All miners should demand this from every pool they use and only use pools that support this mechanism.

In the mean time, while waiting for this to be implemented system wide, the next best thing you can do is create an address that you only use for your mining income and nothing else. Never spend these coins directly. Instead always send them through a mixer before you use them or at least send them through a few rounds of coinjoin transactions (called shared send on the blockchain.info wallet) before you use them.

Certainly no need to apologize. I'm always interested in learning more about ways to improve this thing called Bitcoin

. Truth be told, I'm one of those vanity address guys - mostly because I thought they would be cool to have. I've generated a few and have used them here and there (for example, my forum profile has one attached to it).

To answer your question, I don't know of any pool that offers the type of functionality you're describing. I know p2pool certainly doesn't (I've spent quite a bit of time with that code).

I like the idea of this extended key you proposed. Where I'm a bit confused is in the execution of your mechanism, specifically here:

Quote

An extended public key contains within it the first public key and information on how to generate an entire sequence of public keys that correspond to the same key pair sequence that is generated by the extended private key.

Both you, as the owner of the private keys, and the pool, as the one who would have to generate public keys based upon the extended key, need to be synchronized. I get how you can create this and say, "Here's an extended key with n public keys" and you've created that "n" of private keys corresponding to them. What I don't get is how you'd make that "n" dynamic. I'd appreciate if you'd educate me a bit. Thanks!