Topic: re-use of addresses - page 4. (Read 5530 times)

There is no risk of brute forcing an address.  PubKeys with 128 bit security are beyond brute force for both current and future classical computing.  The laws of physics protect the PubKey from brute force attacks, the PubKeyHash provides a secondary line of defense against other potential attacks (quantum computing, cryptanalysis of ECDSA, flawed k value generation, etc).  It is still a good idea to no reuse addresses but the possibility of someone by brute force generating the same private key is essentially for all practical purposes zero.

I reuse my address all the time, but after reading this, i will consider retiring my main receiving address.

I believe brute forcing an address takes time. So, I assume it would still be safe to reuse an address over a short period of time. My address do not have much anyway.

Agreed.  I would never say address re-use should never occur.  Also for a small amount of funds the risk (and potential loss) is minimal.  Sometimes accepting lower security is an acceptable option.  The important part is making an informed decision.  At BitSimple we do allow address reuse on "deposit addresses" .  There is no way to technically prohibit a user from depositing more than once.  If we ask them not to, some users will still do.  However we do periodically sweep deposit addresses and prevent reuse in the primary wallet.

Good point Peter.  that's a lot of coins for the "taking"

"Never" was purposely provocative.  I do agree with your assessment that given enough time bitcoin will need to be extended to more secure cryptographic primitives.  But I think that any weaknesses will emerge very slowly such that by the time it is feasible to attack one of those 9 rich addresses, the funds will be protected by better security.  


It is a fact that repeat k-value problems can only apply in address re-use scenarios, so I agree that address re-use introduces a new risk.  You've suggested deterministic k-values in the past [as per T. Pornin, “Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA),” from Request for Comments: 6979, ISSN: 2070-1721, August 2013] and hopefully we see a push in this direction.  

But here's why I like address re-use sometimes: when someone asks me for help getting set up with bitcoin, I normally create a laminated paper wallet for them (and a TrueCrypt back-up).  But I can see it in their eyes that they don't trust the paper wallet.  So what I invariably do is (a) send the paper wallet 0.1 BTC, (b) produce a signature using the paper wallet to spend that 0.1 BTC, (c) broadcast the TX to the network (their public key is now known), and (d) prove to them that this particular paper wallet works when they see the transaction confirmed.  We then load the paper wallet with additional funds.  

I know that this is not optimally secure, but the new user is actually more confident because they've already witnessed that this particular key works.  It seems people understand that the key can't "break" in the future because it's just a number, but how do you explain to someone that the key didn't come "broken" if you never test it?  I know you can sign some text and verify the ECDSA signature locally, but this only convinces me because I understand how bitcoin works.  It is not at all convincing to my mom, for instance.  

Please read.  I said explicitly that 128 bits of security is beyond brute force for both current and all conceivable future classical computing.   However that doesn't mean that ECDSA will always have 128 bit security (emphasis to the portion you quoted and ignored).

What is the strength of a 256 bit ECDSA public key if the same k value is used for multiple transactions? 0 bits
What is the strength of a 256 bit ECSDA public key in the safe of a QC implementing Shor's algorithm? Potentially very low
What is the strenght of a 256 bit ECSA public key if weaknesses are exposed which reduce the effective security of the cipher?  <128 bits (how low depends on how severe the flaw)

So while 128 bit strength is beyond brute force there is no guarantee that both today and in the future that secp256k1 will have 128 bit security.  History is full of ciphers which have degraded security.  Some degraded to a point of only academic curiosity (say 112 bits is degraded but there is no economical attack) and some degraded to a point where attacks became trivial.

Most notably in the face of flawed k value selection (Android RNG, bitcoin.js, etc) re-used addresses had an effective security of 0 bits while addresses which were not re-used (pubkey remained unknown) had 160 bits of security.

Same wallet, same set of keys, same implementation and the security varied from 0 bits to 160 bits based solely on if the key had be re-used.  Yes I would call that a reduction in security.

It's been explained a couple times already:

    -  the security level is reduced from 160 bits to 128 bits.  
    -  finding the discrete logarithm of a random elliptic curve element with respect to a publicly known base point must remain infeasible.  

I most agree with your assessment with the exception of "never".  Never is a very long time and I believe Bitcoin will need to be extended to more secure cryptographic primitives on a long enough timeline.  Not sure about you, but if we get to a place where known pubKeys are considered cryptographically weak and developers are implementing a transition to addresses based on stronger cryptography I would much rather wait that out holding value in unknown PubKeys.

Still I would point out that known public key and leaking private key are not mutually exclusive.   The most notable developer error involves repeat k values.  Repeat k values can only apply in an address reuse scenario.  If your wallet has a flaw which leads to a repeat k value you are insulated from that risk by not reusing addresses.   That is why I likened the PubKeyHash as a secondary safety.  Sure if the primary security system is flawless against all current and future threats then there is no need for a second safety.  I have never needed my backup chute when skydiving, and statistically I probably never will, that doesn't mean I jump with one chute though.

What are you talking about?  How do you weaken the stregnth of the security by exposing the public key.  Asymmetric cryptography is built around the notion that you must expose the public key.  Doing so is a key (pun intended) part of the process.  You assume NO security around the public key and protect the private key.


Also keep in mind that is 128 Bit keys become weak, then there is a bigger problem than Bitcoin wallets.

As DeathAndTaxes pointed out, the security level is reduced from 160 bits to 128 bits when the public key is known.  This is fact.  Inspecting the 30 richest bitcoin addresses, I found 9 with publicly known public-keys, representing a total of 419,308 BTC.  The individuals and groups that control these address are obviously confident with 128-bit security and (IMO) the extremely-small risk of compromising secp256k1 by crypto-analysis or by breakthroughs in quantum computing.




I'll probably be torn to shreds for this comment, but it is my opinion that no one will ever lose a single satoshi due to a security weakness at the protocol level.  The vastly more real threats in my opinion are user and developer error.  User errors include losing keys due to theft, malware, damaged paper wallets, forgetfulness, trusting incompetent of unscrupulous third-parties, etc.  Developer errors centre around leaking private keys, for example due to reuse of the per-message secret number k while producing an ECDSA signature, or generating bitcoin addresses that don't actually correspond to a known private key.

In the future, instead of "security by wesson" , my house will say "security by multisig" 

Agreed.  There is also the security aspect to consider.  Say some Bitcoin millionaire decided to drop a ten thousand BTC into Sean's wallet.  That information will be instantly and globally available, even to bad actors.  For that kind of money someone may decide to engage in some rubber-hose cryptanalysis (aka $5 wrench analysis http://xkcd.com/538/ ).  The idea that literally the entire planet needs to know every detail of your finances to provide accountability is a naive implementation of a good concept.

how long until stealth features part of core and stable?

Simple solution: Stealth Addresses.
In this context, "Stealth" is a misnomer. Stealth addresses can be used to receive bitcoins in a "stealthy" manner, but they are also perfect for organisations like charities that are interested in the exact opposite of stealth - high public exposure for one particular donation address. With stealth, they can publish one address publicly but never actually receive any coins with it, thus maintaining all the privacy and security advantages of not re-using addresses.


By the way, it's not at all true that legit charities don't care about financial privacy.
They care about their own privacy: no one needs to know where they send their donated coins. If they want to be transparent (and they should), they will publish a full report detailing their expenses, but they don't necessarily want the money to be easy to track.  
They should also care about the privacy of the people who donate to them: I'm not sure you'd want the government to know that you donated to wikileaks. Of course it's your job to worry about your financial privacy; personally, I always mix before donating. But it sure would make things easier if the charities I donate to would use stealth addresses.

Yes u only reveal a part of the key when u use it to create a transaction

It's only tomorrow if his wallet is flawed. Since these issues are well-known by wallet authors, his wallet is probably fine. In which case, he has 128-bit security and that is pretty good. He can mitigate the risk by transferring funds out frequently, and by monitoring the news for developments in quantum computing. He probably figures his expected loss from reusing addresses is more than compensated by the donations he gets from having a fixed, published address.

Not if he wants to maintain highest level 160-bit security!  That's what we just got done discussing.
But i guess it doesn't matter since he wouldn't have that much at any given time if it kept clearing.

well no he can keep clearing that address.

Yes, I understand.

In a nutshell, I believe the answer to my question is:
the transaction is signed once with the public key
of the sender (which is then visible), and
the protocol requires nothing further to create those
outputs and send them along.

Yes but there would no longer be any unspent outputs associated with that keypair.  It is more of an issue if you don't spend all the outputs.

Inputs are just references to specific outputs.

So say your address was assigned the following outputs

1 BTC to Address A
1 BTC to Address A
3 BTC to Address A
5 BTC to Address A
All these outputs would be locked to the PubKeyHash (decoded addresses).   The PubKey is unknown to the public.

Now lets say you wanted to send 0.5 BTC to your friend.  Your wallet may construct a tx with 1 BTC as the input and two outputs 0.5 BTC to your friend and 0.5 BTC in change.

So you are left with
1 BTC to Address A spent
1 BTC to Address A
3 BTC to Address A
5 BTC to Address A
0.5 BTC to Address A (or B depending on wallet behavior) <- your change

The issue is the tx spending the 1 BTC revealed the PubKey for address A however you still have another 9 BTC in other unspent outputs which share the same address, pubkeyhash, and pubkey.   The attacker now knows the PubKey for your other 9 BTC.  This by itself doesn't allow the theft of funds however if there is a flaw/weakness which requires the PubKey to be know, spending 0.5 BTC left 9 BTC in a weakened state.

On the other hand if you didn't re-use addresses each of those outputs would be a different Address:
1 BTC to Address A spent
1 BTC to Address B
3 BTC to Address C
5 BTC to Address D
0.5 BTC to Address E <- your change

The PubKey for Address A has been revealed however there are no unspent outputs associated with A.  You don't really need to think about it, this is the default behavior of most clients (including bitcoin-core).  Just request a new address whenever someone needs to send you funds.