Bitcoin Forum
November 19, 2017, 10:15:41 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 [948] 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2009520 times)
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
December 22, 2014, 08:35:39 PM
 #18941

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



1511129741
Hero Member
*
Offline Offline

Posts: 1511129741

View Profile Personal Message (Offline)

Ignore
1511129741
Reply with quote  #2

1511129741
Report to moderator
1511129741
Hero Member
*
Offline Offline

Posts: 1511129741

View Profile Personal Message (Offline)

Ignore
1511129741
Reply with quote  #2

1511129741
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511129741
Hero Member
*
Offline Offline

Posts: 1511129741

View Profile Personal Message (Offline)

Ignore
1511129741
Reply with quote  #2

1511129741
Report to moderator
1511129741
Hero Member
*
Offline Offline

Posts: 1511129741

View Profile Personal Message (Offline)

Ignore
1511129741
Reply with quote  #2

1511129741
Report to moderator
1511129741
Hero Member
*
Offline Offline

Posts: 1511129741

View Profile Personal Message (Offline)

Ignore
1511129741
Reply with quote  #2

1511129741
Report to moderator
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
December 22, 2014, 08:40:37 PM
 #18942

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
Legendary
*
Offline Offline

Activity: 1764



View Profile
December 22, 2014, 08:45:32 PM
 #18943

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. Wink
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
Legendary
*
Offline Offline

Activity: 1064



View Profile
December 22, 2014, 09:02:09 PM
 #18944

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. 

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
NewLiberty
Legendary
*
Offline Offline

Activity: 1162


Gresham's Lawyer


View Profile WWW
December 22, 2014, 09:03:34 PM
 #18945

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. 

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
molecular
Donator
Legendary
*
Offline Offline

Activity: 2408



View Profile
December 22, 2014, 09:46:17 PM
 #18946

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




germany should know better

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
December 22, 2014, 10:00:21 PM
 #18947

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
Legendary
*
Offline Offline

Activity: 1162


Gresham's Lawyer


View Profile WWW
December 22, 2014, 10:10:19 PM
 #18948

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.

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
December 22, 2014, 11:37:06 PM
 #18949

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
Legendary
*
Offline Offline

Activity: 1162


View Profile
December 22, 2014, 11:54:17 PM
 #18950

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
Legendary
*
Offline Offline

Activity: 1149


View Profile
December 23, 2014, 12:05:20 AM
 #18951

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.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
December 23, 2014, 01:25:41 AM
 #18952

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.

it is certainly a trend.  Trezor has it implemented.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
December 23, 2014, 01:34:34 AM
 #18953

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.

what is somewhat circular for me is that, for a given computer, if you have a problem generating enough entropy for RNG for k values, then you probably have an equally hard problem generating enough entropy for privkeys, as i assume their source of entropy is equivalent.  therefore the HMAC of the message + privkey is also insecure.

btw, perhaps someone can clarify for me.  the privkey is simply a random number btwn 1 and 2256.  what's to stop me from self declaring that i will pick the number 75% of the way to 2256 as my privkey?  the chances of a pure RNG generating that same # is infinitesimal.  therefore, it should be safe.
smooth
Legendary
*
Offline Offline

Activity: 1596



View Profile
December 23, 2014, 02:11:43 AM
 #18954

what is somewhat circular for me is that, for a given computer, if you have a problem generating enough entropy for RNG for k values, then you probably have an equally hard problem generating enough entropy for privkeys, as i assume their source of entropy is equivalent.

Not necessarily. Generation of private keys is a rare event, especially with HD wallets. You need a k value for each tranasction.

Quote
what's to stop me from self declaring that i will pick the number 75% of the way to 2256 as my privkey?  the chances of a pure RNG generating that same # is infinitesimal.  therefore, it should be safe.

Nothing, although that's sort like of a brain wallet, and subject to the same flaws. If someone searches through the list of clever but simple methods of picking a key, they will find yours.

NewLiberty
Legendary
*
Offline Offline

Activity: 1162


Gresham's Lawyer


View Profile WWW
December 23, 2014, 03:44:06 AM
 #18955



I picked up a bunch of these hexadecimal dice back when they were still being made.
They were a hit at the Bitcoin conventions and meetups.
Still have some even.

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
December 23, 2014, 04:32:50 AM
 #18956

what's to stop me from self declaring that i will pick the number 75% of the way to 2256 as my privkey?  the chances of a pure RNG generating that same # is infinitesimal.  therefore, it should be safe.

Nothing, although that's sort like of a brain wallet, and subject to the same flaws. If someone searches through the list of clever but simple methods of picking a key, they will find yours.

Exactly, to make this method secure you'd have to randomly select 75.29379857239479209348238048023740720340% of the way to 2^256, which is the same as just banging out 256 bits of entropy on your keyboard (which may not even be that random depending on how you type, dice would be much better)

what is somewhat circular for me is that, for a given computer, if you have a problem generating enough entropy for RNG for k values, then you probably have an equally hard problem generating enough entropy for privkeys, as i assume their source of entropy is equivalent.

Not necessarily. Generation of private keys is a rare event, especially with HD wallets. You need a k value for each tranasction.

The issue with HD wallet seed key generation is even though it happens once, EVERYTHING rests on having true entropy during it's generation, especially for a wallet that may live for decades (which many HD wallets will). However at the same time generating HD seeds or private keys can be done when a machine and wallet software first start when there is the LEAST amount of entropy in a given machine.

For example lets assume someone decides to use a Ubuntu 14.4 VM image pre-configured to run bitcoind automatically. That person starts the VM, logs into a ssh shell, and then issues a bitcoind command to create a new wallet. This a logical user flow, but it also means the system has very little entropy. In this case everything about the system configuration is known ahead of time (it is a pre-configured VM image with known virtual hardware) and the user inputted a minimal amount of new information to capture (even the bitcoind command is known and can be easily guessed). About the only random information the user adds is their personal id/pw, but those might be quite weak because the user figures they are running on a secure home network. In this situation that machine has very little true entropy to use in private key or HD wallet generation. At the same time that key might have a lifetime of decades, during which an attacker can try combinations.

That is why it is important that the random number generator captures as much entropy from as many sources as possible. However most rnd functions do not do so by default and the cryptographically secure methods can vary from OS, i.e. a developer has to find the right function calls for linux, windows, etc.

This is why some people roll dice to generate the seed key for their core wallets, since it is the only way to be absolutely sure. I am positive that right now there probably are several individuals trying combinations on known (to them) weak setups trying to guess HD seeds or private keys.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
December 23, 2014, 11:20:51 AM
 #18957

It seems like there is a market for a device which will generate 256 bits of entropy once and save it forever.

256 bits of entropy should be enough to last a lifetime (except if any of it gets compromised).
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1736

Let's talk governance, lipstick, and pigs.


View Profile
December 23, 2014, 11:27:15 AM
 #18958

If you create a HD wallet that ONLY creates multisig transactions, would that prevent addresses from being reused?

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
December 23, 2014, 11:58:40 AM
 #18959

If you create a HD wallet that ONLY creates multisig transactions, would that prevent addresses from being reused?
What does multisig have to do with address reuse?
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1736

Let's talk governance, lipstick, and pigs.


View Profile
December 23, 2014, 12:38:06 PM
 #18960

If you create a HD wallet that ONLY creates multisig transactions, would that prevent addresses from being reused?
What does multisig have to do with address reuse?
HD wallets reuse addresses when people send multiple payments to them. I think that is a weakness. Isn't there another bitcoin payment for where this is not possible, like multisig?

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
Pages: « 1 ... 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 [948] 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 ... 1558 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!