Gold collapsing. Bitcoin UP.

[cypherdoc]

Gold collapsing, Bitcoin up 

heh, heh, heh.  i'm the troll, remember?!

[cypherdoc]

ordinary goldbugs and speculators having to liquidate tons of physical gold at local coin dealers is going to be a sight to behold.

[NewLiberty]

I think something is going to happen to gold soon. The price is being suppressed by counterfeit certificates. Rich people want real gold.

I don't think Rich people want gold, I think it's a part of their overall portfolio, they own paper gold.  Rich people believe in the markets, real estate, and the USD because it's served them so well.  They want diversity.  In some cases they want to hide their money, but gold isn't a good way to do that.  We all know the advantages of Bitcoin over gold and in 10 years I believe most rich people will have BTC as a part of their overall portfolio. 

Or alternatively, in 10 years people with bitcoin in their portfolio will be rich.

[tvbcof]

ordinary goldbugs and speculators having to liquidate tons of physical gold at local coin dealers is going to be a sight to behold.

Same holds true for Bitcoin, BTW.  Holding both, and needing to at some point re-initiate a revenue stream, I'll probably draw down my BTC holding more than my phyz ones assuming that both maintain the current unhappy situation of being at an inopportune selling point over the next few years.

Your scenario is nothing especially new.  We saw it during the 2008 crisis.  Plenty of people did not leave themselves enough of a buffer and were forced to liquidate whatever they had.  In some cases this was PMs and the impact was noticeable.  My portfolio suffered, but not to nearly the extent that my more mainstream counterparts who were heavily into mainstream instruments did.  Many enjoyable and productive conversations around the water-cooler ensued.

[msin]

Or alternatively, in 10 years people with bitcoin in their portfolio will be rich.

I guess it depends on how much BTC they have in their portfolio.   

[cypherdoc]

Or alternatively, in 10 years people with bitcoin in their portfolio will be rich.

I guess it depends on how much BTC they have in their portfolio.   

now's the time.  seriously.

[rocks]

listening to johoe is inspiring.  but it appears to me that even if you're using a BIP32 wallet, you'll still be exposed to a hack from address reuse if you choose to accept multiple payments to a single address.  for instance, if you accept 5 payments of 1BTC each to a single address, you will create 5 UTXO's of 1BTC each.  if you then only spend 1BTC from that address, you will leave the other 4 UTXO's behind on that address which will force you to reuse that address later on when you decide to make another payment.  so in that sense, HD wallets (BIP32) are still exposed if you're not careful and don't always force all tx's to empty an address.  i understand that this is not directly related to the reuse of the r value that johoe talks about in this episode, but it's concerning to me nonetheless unless i have something wrong:

http://letstalkbitcoin.com/blog/post/the-bitcoin-game-7-bitcoin-hero-jochen-aka-johoe

Did johoe talk about BIP32 wallets in the stream? I just scanned through, but couldn't find any reference to BIP32 wallets.
However, AFAIK you're right. As soon as the hacker gets the R value of 2 signatures from the same address (e.g. from transactions, but could also be from signed messages (!) or a mixture of both), he can calculate the private key of the address and then spend all the funds still left on that address. So from 0 to 1 outgoing transactions (or publicly accessible signed messages) an address should be safe (from this specific problem). I think so far this is not related to HD/BIP32 wallets other than it's easier to not reuse a single address.

Address reuse is fine, not advised but fine regardless. The issue is if you use the exact same R value for 2 different signatures with the same private key. This an attribute of the DSA algorthim itself, and is not specific to ECDSA or any other DSA variant. As long as you use a truly random R value, then the odds of repeating an R value is less than someone randomly creating a private key that signs a specific address. The problem above is blockchain.info and other wallet software has at times not created random R values or used k values that are guessable, which is contrary to the DSA specification. Software that creates a truly random R value should never repeat an R value given the large numbers involved.

This is a great description of DSA and ECDSA if you are interested. It provides all the math required to understand Elliptical Curves and DSA , but in a descriptive manner for non-mathmatitions.

http://kakaroto.homelinux.net/2012/01/how-the-ecdsa-algorithm-works/

Towards the end it describes the R-reuse issue in the context of a hack on Sony where Sony used the same R value for everything, in gross violation of DSA's spec.

Now I’ll discuss on how and why the ECDSA signatures that Sony  used in the PS3 were faulty and how it allowed us to gain access to their private key.

So you remember the equations needed to generate a signature.. R = k*G and S= k^-1(z + dA*R) mod p.. well this equation’s strength is in the fact that you have one equation with two unknowns (k and dA) so there is no way to determine either one of those. However, the security of the algorithm is based on its implementation and it’s important to make sure that ‘k‘ is randomly generated and that there is no way that someone can guess, calculate, or use a timing attack or any other type of attack in order to find the random value ‘k‘. But Sony made a huge mistake in their implementation, they used the same value for ‘k‘ everywhere, which means that if you have two signatures, both with the same k, then they will both have the same R value, and it means that you can calculate k using two S signatures of two files with hashes z and z’ and signatures S and S’ respectively :

S – S’ = k^-1 (z + dA*R) – k^-1 (z’ + da*R) = k^-1 (z + da*R – z’ -dA*R) = k^-1 (z – z’)

So : k = (z – z’) / (S – S’)

Once you know k, then the equation  for S because one equation with one unknown and is then easily resolved for dA :

dA = (S*k – z) / R

Once you know the private key dA, you can now sign your files and the PS3 will recognize it as an authentic file signed by Sony. This is why it’s important to make sure that the random number used for generating the signature is actually “cryptographically random”.  This is also the reason why it is impossible to have a custom firmware above 3.56, simply because since the 3.56 version, Sony have fixed their ECDSA algorithm implementation and used new keys for which it is impossible to find the private key.. if there was a way to find that key, then the security of every computer, website, system may be compromised since a lot of systems are relying on ECDSA for their security, and it is impossible to crack.

There is another recent attack on ECDSA specifically where an attacker with something on the order of 2^33 signatures for a private key might be able to back out the private key itself. But that is a gross usage of reuse, to put in context you would require more signatures than the total number of bitcoin transactions so far, all on a single address.

That said it demonstrates that ECDSA is still relatively new and not completely understood, it is possible (likely?) that more attacks or even fundamental flaws on ECDSA will be uncovered. This is why bitcoin has 2 forms of encryption protecting an address (a hash and a signature) and why every address I use that I care about are zero spend addresses, and thus still protected by both forms of encryption.

[flipperfish]

listening to johoe is inspiring.  but it appears to me that even if you're using a BIP32 wallet, you'll still be exposed to a hack from address reuse if you choose to accept multiple payments to a single address.  for instance, if you accept 5 payments of 1BTC each to a single address, you will create 5 UTXO's of 1BTC each.  if you then only spend 1BTC from that address, you will leave the other 4 UTXO's behind on that address which will force you to reuse that address later on when you decide to make another payment.  so in that sense, HD wallets (BIP32) are still exposed if you're not careful and don't always force all tx's to empty an address.  i understand that this is not directly related to the reuse of the r value that johoe talks about in this episode, but it's concerning to me nonetheless unless i have something wrong:

http://letstalkbitcoin.com/blog/post/the-bitcoin-game-7-bitcoin-hero-jochen-aka-johoe

Did johoe talk about BIP32 wallets in the stream? I just scanned through, but couldn't find any reference to BIP32 wallets.
However, AFAIK you're right. As soon as the hacker gets the R value of 2 signatures from the same address (e.g. from transactions, but could also be from signed messages (!) or a mixture of both), he can calculate the private key of the address and then spend all the funds still left on that address. So from 0 to 1 outgoing transactions (or publicly accessible signed messages) an address should be safe (from this specific problem). I think so far this is not related to HD/BIP32 wallets other than it's easier to not reuse a single address.

Sorry for being stupid. Thank you, rocks for pointing that out. Only with the same R value of 2 different signatures from the same address (and thus public/private key) the hacker would be able to calculate the private key. As the R value is a part of the signature, that would be a big problem, otherwise.
However, I remember reading something about similiar or related R values from which the private key can be calculated, too (by using a system of linear equations). Probably that is the thing, that confused me.

[molecular]

I think something is going to happen to gold soon. The price is being suppressed by counterfeit certificates. Rich people want real gold.

I don't think Rich people want gold, I think it's a part of their overall portfolio, they own paper gold.  Rich people believe in the markets, real estate, and the USD because it's served them so well.  They want diversity.  In some cases they want to hide their money, but gold isn't a good way to do that.  We all know the advantages of Bitcoin over gold and in 10 years I believe most rich people will have BTC as a part of their overall portfolio. 

Or alternatively, in 10 years people with bitcoin in their portfolio will be rich.

hehe... and then they will diversify.

[solex]

Bitcoin is going to shine like a diamond in the midst of the smoldering wreckage of this god-forsaken SNAFU

[rocks]

However, I remember reading something about similiar or related R values from which the private key can be calculated, too (by using a system of linear equations). Probably that is the thing, that confused me.

Hi flipperfish, if you find a link describing a related R value attack please post it, am also curious to understand that better. That said it sounds to be somewhat analogous to related key attacks against AES, related key or related R values are a worthwhile area of study in order to understand the algorithms better, but they are not real attacks. True cryptographically random R values are not related by definition.

[cypherdoc]

listening to johoe is inspiring.  but it appears to me that even if you're using a BIP32 wallet, you'll still be exposed to a hack from address reuse if you choose to accept multiple payments to a single address.  for instance, if you accept 5 payments of 1BTC each to a single address, you will create 5 UTXO's of 1BTC each.  if you then only spend 1BTC from that address, you will leave the other 4 UTXO's behind on that address which will force you to reuse that address later on when you decide to make another payment.  so in that sense, HD wallets (BIP32) are still exposed if you're not careful and don't always force all tx's to empty an address.  i understand that this is not directly related to the reuse of the r value that johoe talks about in this episode, but it's concerning to me nonetheless unless i have something wrong:

http://letstalkbitcoin.com/blog/post/the-bitcoin-game-7-bitcoin-hero-jochen-aka-johoe

Did johoe talk about BIP32 wallets in the stream? I just scanned through, but couldn't find any reference to BIP32 wallets.
However, AFAIK you're right. As soon as the hacker gets the R value of 2 signatures from the same address (e.g. from transactions, but could also be from signed messages (!) or a mixture of both), he can calculate the private key of the address and then spend all the funds still left on that address. So from 0 to 1 outgoing transactions (or publicly accessible signed messages) an address should be safe (from this specific problem). I think so far this is not related to HD/BIP32 wallets other than it's easier to not reuse a single address.

Sorry for being stupid. Thank you, rocks for pointing that out. Only with the same R value of 2 different signatures from the same address (and thus public/private key) the hacker would be able to calculate the private key. As the R value is a part of the signature, that would be a big problem, otherwise.
However, I remember reading something about similiar or related R values from which the private key can be calculated, too (by using a system of linear equations). Probably that is the thing, that confused me.

yeah, i was trying to follow that from johoe's discussion.  apparently he was able to construct a RNG "prediction" table but i'm not sure exactly how he did it.  i'm thinking that it must be specific to the blockchain.info lack of initialization bug in their software.  once he figured out what the problem was, that being only 256 possible random #'s to choose from, and after he noticed a pattern of R values, he was then able to predict the overall sequence of RNG thereafter.  did i get that right?

[Peter R]

Adding to what @rocks said…

If ECDSA signatures are produced correctly, re-using an address for multiple outgoing transactions does not pose a security problem.  When the first ECDSA signature associated with a particular bitcoin address becomes public, the address's public key becomes known.  This reduces the security with which the remaining bitcoins are protected from 160 bits to 128 bits.  Cracking 128-bit security is still far beyond our present capabilities.  Also note that producing a bitcoin-signed message from that address (e.g., to publically prove control of funds) would have the same effect of reducing the security from 160 bits to 128 bits. 

Producing additional ECDSA signatures (additional outbound TXs) from that address has no meaningful effect on security either, provided the k-values used in signature generation remain unknown. As an example, the address 12WRnQR85ZUT7dhmaHBNL5dde2QLYieW6v presently holds $24,000,000 of bitcoins and has made multiple outgoing transactions.  For each outgoing transaction from this address, we can inspect the signatures and determine the R values.  This doesn't help us "hack" the address to any meaningful extent except in the case where the signatures were produced incorrectly (for example, by using a low-entropy k-value).

The point I want to make is that this is not some "discovery" of some flaw in ECDSA.  The thefts due to re-used or low-entropy R/k values are a result of buggy software.

The solution is for the community to demand that bitcoin hardware and software wallets use deterministic signatures, for example following RFC6979.  When RFC6979 is used, the k-value used for producing the ECDSA signature is derived deterministically from the message and the private key.  This has the benefit of

   (1) eliminating the need for a RNG when producing signatures (and thus the risk of using a flawed RNG)
   (2) making software/hardware audits much simpler (just load test private keys and make sure the signatures match what's expected [it's very difficult to audit a RNG, on the other hand])

Adding deterministic signatures is not a significant software project either.  Basically, rather than calling a random number generator when selecting k:

   k = random256bits()
 
we pass the private key and the message to an RFC6979 library function instead:

   k = rfc6979(privkey, message)

This rest of the code remains unchanged. 

[NewLiberty]

yeah, i was trying to follow that from johoe's discussion.  apparently he was able to construct a RNG "prediction" table but i'm not sure exactly how he did it.  i'm thinking that it must be specific to the blockchain.info lack of initialization bug in their software.  once he figured out what the problem was, that being only 256 possible random #'s to choose from, and after he noticed a pattern of R values, he was then able to predict the overall sequence of RNG thereafter.  did i get that right?

With only 256 possible RNs, predicting them would be hardly even necessary. 

[molecular]

Bitcoin is going to shine like a diamond in the midst of the smoldering wreckage of this god-forsaken SNAFU

germany should know better

[cypherdoc]

yeah, i was trying to follow that from johoe's discussion.  apparently he was able to construct a RNG "prediction" table but i'm not sure exactly how he did it.  i'm thinking that it must be specific to the blockchain.info lack of initialization bug in their software.  once he figured out what the problem was, that being only 256 possible random #'s to choose from, and after he noticed a pattern of R values, he was then able to predict the overall sequence of RNG thereafter.  did i get that right?

With only 256 possible RNs, predicting them would be hardly even necessary.  

Is that necessarily true? If they were numerically sequential, it might be. But since they all "look" random,  then it seems a predictive table would be quite handy.  

[NewLiberty]

yeah, i was trying to follow that from johoe's discussion.  apparently he was able to construct a RNG "prediction" table but i'm not sure exactly how he did it.  i'm thinking that it must be specific to the blockchain.info lack of initialization bug in their software.  once he figured out what the problem was, that being only 256 possible random #'s to choose from, and after he noticed a pattern of R values, he was then able to predict the overall sequence of RNG thereafter.  did i get that right?

With only 256 possible RNs, predicting them would be hardly even necessary.  

Is that necessarily true? If they were numerically sequential, it might be. But since they all "look" random,  then it seems a predictive table would be quite handy.  

Yes, though if merely issuing 256 transactions, one of which being validated would be enough, then getting the order right for each TX would be gravy.

[rocks]

Bitcoin is going to shine like a diamond in the midst of the smoldering wreckage of this god-forsaken SNAFU

germany should know better

At least Japan and Germany are not as bad as the US over the past couple of years. With QE3 the US printed $85b/m for $1.02T/year, that's trillion. The US's deficit was less than a trillion recently (although not by much), so the FED was not just monetizing 100% of the deficit but also buying down additional outstanding debt as well. I'd like to believe it can't get any uglier than that, but I'm sure they'll find a way to surprise me.

Edit: This is also why the FED has over a trillion in mortgage debt on it's balance sheet, and not only government debt as it should only have. Because the FED was printing more than 100% of the deficit, there wan't enough US gov debt to buy, so the FED had to resort to buying non-US gov assets as well. This is outright printing no matter how they try to spin it.

[inca]

Bitcoin is going to shine like a diamond in the midst of the smoldering wreckage of this god-forsaken SNAFU

germany should know better

At least Japan and Germany are not as bad as the US over the past couple of years. With QE3 the US printed $85b/m for $1.02T/year, that's trillion. The US's deficit was less than a trillion recently (although not by much), so the FED was not just monetizing 100% of the deficit but also buying down additional outstanding debt as well. I'd like to believe it can't get any uglier than that, but I'm sure they'll find a way to surprise me.

It isn't quite as clear cut as all that though. Here in the UK we have QE, too. The BOE bought government bonds, GILTS, and basically own the market and allows ZIRP to continue happily. Last time I checked they owned more than a third of the entire British national debt. The bonds owned by the BOE are paid an annual interest payment (coupon) by the UK government. It is simply handed straight back. The bonds will be held until they expire. Apart from the initial emission via the deficit in the form of inflation the newly created debt has no effect in the long term to the balance sheet of the UK. It is illusory.

It is similar in the US. It is total banana republic stuff and I expect there will be a tipping point where there may be a sudden flight from a Western currency, say when a certain % (50?) of national debt is owned by the central bank. But this can be gamed and obfuscated for a long time. Other central banks can print money out of thin air and use it to buy different nations bonds, or even buy stocks lol.

Central banks crossed a line in 2008. They now control all markets. They have dislocated the markets in such a way that it is impossible to measure the true value of any stock or commodity or even gold.

Bitcoin is necessary as it cannot be inflated outwith its algorithmic schedule.

[rocks]

The solution is for the community to demand that bitcoin hardware and software wallets use deterministic signatures, for example following RFC6979.  When RFC6979 is used, the k-value used for producing the ECDSA signature is derived deterministically from the message and the private key.  This has the benefit of

   (1) eliminating the need for a RNG when producing signatures (and thus the risk of using a flawed RNG)
   (2) making software/hardware audits much simpler (just load test private keys and make sure the signatures match what's expected [it's very difficult to audit a RNG, on the other hand])

Adding deterministic signatures is not a significant software project either.  Basically, rather than calling a random number generator when selecting k:

   k = random256bits()
 
we pass the private key and the message to an RFC6979 library function instead:

   k = rfc6979(privkey, message)

This rest of the code remains unchanged.  

Was not aware of RFC6979, thank you for sharing. Has any wallet software started to move in this direction or implemented this approach?

It seems this will work well for an existing HD wallet, where no new private keys need to be generated. However most wallet software needs to be able to create new wallets and still require the ability to generate cryptographically random numbers in order to create new private keys or a new HD seed. So the problem of wallet software requiring true random numbers still exists.

It could even be argued that RFC6979 might make wallet developers less aware on how to obtain true random numbers since RFC6979 "fixed" the problem, and as a result generate weak HD seeds. I remember for Armory there was a discussion last summer that resulted in more entropy being added to HD seed generation, I am sure most wallet software is not as paranoid and could still be weak here even with RFC6979. Weak HD seed generation is much more of an issue than moderately weak k value generation IMHO.

BTW, Not sure if the need for RFC6979 in general is more of a statement on how hard it is to produce true random numbers, or if this is more of a statement on the state of software engineering today.