Topic: Miners: Time to deprioritise/filter address reuse! (Read 51830 times)

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

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.

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.

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

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

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?

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.

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.

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.

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

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.

S/he has not used their btc yet

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.

Ok, who is this person:

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

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

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".

But it can't use the bitcoind wallet trough RPC?
I have a VM dedicated to various coins with their services running constantly (takes very long to download the missing blocks in the chain and to verify the block index, but the PC can keep up with the network quite well).

Hmm... Armory is available in two versions -  0.88.1-beta (64bit only, uses lots of RAM) and 0.89.99.16-testing (Vista, 7, 8 only, uses less RAM).
No version that would work on Windows 2003 32bit...

Does not directly support wallet.dat, but if you've only got a couple addresses it's easy to import them.

Armory relies on either bitcoind or Bitcoin-Qt to connect to the network and download the blockchain for it, so you can just install Armory alongside your existing Bitcoin-Qt installation and it will just use that.

Even better you can set up bitcoind to constantly run in the background as a service and just use Armory when you need to make a transaction.

Not really, I have set 0.2BTC as the automatic payout and I think it is normal for me - I get it about every 4 days. Also, 0.2BTC is about $150 at current rate, so it's not "dust".
Sure, if I mined with USB Block erupter and wanted to be paid every day then yes, there would be too many transactions.

Does it support the wallet.dat from the original client?
Does it support the block database from the original client (I do not want to wait another two weeks for the new client to download the blockchain).

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 -- furthermore, doing so will cause you way less expense in the long run, because otherwise you'll have "dust" in that address that will cost you in transaction fees a significant fraction of whatever you spend.

Honestly, the whole interface would work better IMO if people's balance showed the expected amount that they can actually spend, *AFTER* transaction fees are deducted.  That would dispel illusions like getting "just as much Bitcoin" by getting mining paid daily as by getting it paid annually.  It would also go a long way toward making transaction fees easier to deal with; showing people their actual buying power as opposed to a number 30% or more of which may be illusory if their wallet is mostly "dust".

There's a huge distinction in fees between many tiny txouts and one big txout, regardless of the number of addresses they are sent to.  The argument about wanting to get many teeny-tiny mining payments at a single address shows that at least some users just aren't getting that distinction. Because it looks exactly the same in your wallet until you get REAMED on transaction fees when you try to spend it, it's too easy to miss.