Miners: Time to deprioritise/filter address reuse!

[justusranvier]

But it can't use the bitcoind wallet trough RPC?

Not yet.

Right now it needs direct access to the downloaded blockchain files. Being able to connect to a remote bitcoind is a feature that he'll add "soon".

[Syke]

Slowing down transactions is not the right way of accomplishing the intented purpose. The right way is to make unique addresses easier to use.

[Syke]

Bitcoin is never anonymous, no matter how you use it.

Ok, who is this person:

https://blockchain.info/address/1Dc7NUeohUaujaqzcUg9XQ7YLzSGjn1FRG

[Luke-Jr]

Bitcoin is never anonymous, no matter how you use it.

Ok, who is this person:

https://blockchain.info/address/1Dc7NUeohUaujaqzcUg9XQ7YLzSGjn1FRG

Doesn't matter, there's a pseudonym visible.
Anonymity means you cannot name them at all.
Bitcoin is at best pseudonymous.

Practical difference: a pseudonym can be named/identified and theoretically be found, whereas someone anonymous cannot be identified at all distinct from any other actor.

[prophetx]

Bitcoin is never anonymous, no matter how you use it.

Ok, who is this person:

https://blockchain.info/address/1Dc7NUeohUaujaqzcUg9XQ7YLzSGjn1FRG

S/he has not used their btc yet

[Cryddit]

Slowing down transactions is not the right way of accomplishing the intented purpose. The right way is to make unique addresses easier to use.

First, this doesn't slow down transactions unless blocks are full (at the 1Mb limit) in which case *some* transactions would be slowed down anyway.  This just gives the *FIRST* transactions to all addresses higher priority than the *SECOND* or later transactions to all addresses.

[User705]

Not sure if this was answered but how would this affect things like Asicminer dividends or are large transaction prioritized anyways?

[murraypaul]

I don't see the problem with mining.  You don't need to give the pool a payment address until it's time for you to take your balance.  You can put *MONTHS* or even *YEARS* of mining output in a single tx, in a single address

Which is a really bad idea, and one that I imagine most pool operators would strongly advise you not to do.
Bitcoins in your account with a pool are not really yours, not yet. They are just a ledger entry saying that the pool owes you money.
If the pool is hacked, or just vanishes, those Bitcoin are gone.
And it isn't as though that hasn't happened, more than once.

[DeathAndTaxes]

I don't see the problem with mining.  You don't need to give the pool a payment address until it's time for you to take your balance.  You can put *MONTHS* or even *YEARS* of mining output in a single tx, in a single address

Which is a really bad idea, and one that I imagine most pool operators would strongly advise you not to do.
Bitcoins in your account with a pool are not really yours, not yet. They are just a ledger entry saying that the pool owes you money.
If the pool is hacked, or just vanishes, those Bitcoin are gone.
And it isn't as though that hasn't happened, more than once.

Agreed.  The trust free (or reduced trust) alternative is to provide the pool a BIP32 address chain and the pool simply sends periodic payments to a new address each time.

[Luke-Jr]

How would that work with pools that have public stats? Especially Eligius, actually.

Perhaps show hash(BIP32 seed)? Otherwise, public seeds would not result in any more privacy.

Actually, I was thinking we should use hash(recurring invoice id) for the stats page, and not publish a list of those at all.
wizkid057 disagrees at the moment, though, so I'm not sure how it will turn out.

[niothor]

I assume you have already implemented this , can you give some feedback on its' effects?
I know that there are lost of variables , (time between blocks which leads to more or less transactions) but do you have any average on how the number transaction/blocked mined has evolved?

[btcdrak]

Luke-Jr: how is the patch working out in practice? All ok?

[Luke-Jr]

Luke-Jr: how is the patch working out in practice? All ok?

No, it really needs to be rewritten differently (as expected).
Unfortunately, that's very involved.

[btcdrak]

Juke-Jr,

I am sorry if this has been covered elsewhere, but I was thinking about the issues of address non(reuse) and how that affects paper wallets. Is there a way to have HD paper wallets? Something like you can scan the paper wallet to get an address to send funds to?

Unless there is a technical solution, this seems be an instance where it's not very practical when saving funds to cold storage.

[phillipsjk]

The structure of HD Wallets is presented here.

If your are storing leafs, they have 512 bits of data. This is about twice as much data as traditional keys.

In the "serialization format" section, it says that the keys are up to 112 Characters in base-58 format, which is longer than traditional addresses, IIRC. However, in theory, you only have to back these up once.

I think a more interesting question is if this can be made to work with Pay to Script Hash and M-of-N Multisignature Transactions.

[kkurtmann]

this topic is still relevant with all the newbies thinking an address is a wallet