Gold Parity, here we come.
kinda weird to think about after all these years... what's after that? We don't know, we happen to live in a time that's fundamentally different from any preceding it, for the last 600 or so years, right after the institution of banking was created. |
|
|
|
And if they don't how do they know that the pubkey I am sending them, is the same one as the one I used before, for the same address?
It would be a mistake for them to check. Nobody claims the pubkey is supposed to have any characteristic other than to have a particular hash. Then suppose my private key is only 160 bits, I can indeed theoretically reuse the same address with a different private key after 2^80 tries. |
|
|
|
|
There are several write-only encrypted filesystem using asymmetric encryption out there, I wonder how practical it's to use them for Armory offline transactions? Only pubkeys will be entered on the online computer, so even if the malware can write itself into the filesystem, without knowing the internal structure of it, it will have a very low chance ending up somewhere executable.
|
|
|
|
I wonder how miners do that? If they check all the used pubkeys before they check the hash, that's going to be pretty inefficient, no?
 No idea what you are talking about now? I am going to give up for the night. Do the miners check if a pubkey that hashes to a particular address, is also being used sometime in the past, by searching through the whole blockchain? And if they don't how do they know that the pubkey I am sending them, is the same one as the one I used before, for the same address? |
|
|
|
It's a solution because miners are supposed to record hashes for any unspent address that is reused, so they will already know the hashes of the pubkey, and that's why I say not completely spent. Once again, there is NO SUCH THING AS "not completely spent". Outputs are spent or unspent. It is binary, they can't be partially spent. Until spent the PubKey of an output is UNKNOWN to miners. The PubKey once spent is ALREADY recorded in the blockchain but there is nothing to protect at this point. The output has been spent. It is a non-solution, for a non-problem. So you are telling me that, if I want to reuse the same address for a second time, miners will only check if my pubkey is the same as the one that is already recorded on the blockchain for this address, right? You shouldn't be reusing addresses. So a solution which only protects the most insecure method of doing things only only if the attack happens to occur after the first tx occurs? If you want that as a "solution" why not just pay to the PubKey? Nothing to record just eliminate the issue by not having the hash to begin with. The hash only provides security when the PubKey is unknown. Your "solution" would be to insecurely make the PubKey known through address reuse to prevent the issue of a the hash being "cracked"? Why not just not use the hash and pay directly to the PubKey? I wonder how miners do that? If they check all the used pubkeys before they check the hash, that's going to be pretty inefficient, no? And if they don't then I can try a different pubkey to reuse the same address. |
|
|
|
It's a solution because miners are supposed to record hashes for any unspent address that is reused, so they will already know the hashes of the pubkey, and that's why I say not completely spent. Once again, there is NO SUCH THING AS "not completely spent". Outputs are spent or unspent. It is binary, they can't be partially spent. Until spent the PubKey of an output is UNKNOWN to miners. The PubKey once spent is ALREADY recorded in the blockchain but there is nothing to protect at this point. The output has been spent. It is a non-solution, for a non-problem. So you are telling me that, if I want to reuse the same address for a second time, miners will only check if my pubkey is the same as the one that is already recorded on the blockchain for this address, right? Then they must check all the used pubkeys before they decide if they should check the hash, no? |
|
|
|
No. The Public Key is unknown for the vast majority of active addresses. What is the PubKey or SHA-256 hash of the PubKey for this coinbas reward in this block: https://blockchain.info/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26fHint: only the owner knows. If this output is spent in the future you would have no method of knowing if it was the "real" owner's spend or a pubkey collision. Bitcoin INTENTIONALLY makes the PubKey UNKNOWN until an output is spent. Once it is spent there is nothing to "protect". Addresses shouldn't be reused. So it is not a solution, even for this non-problem. The supposed problem is someone creating two random private keys that spend the same address, because I am the creator of both, I know both, I think I understand what you want to say, but you don't understand me. That isn't the (non) issue proposed. The issue the OP proposed is a hash collision. Two PubKeys A & B such that the hash of A & B are the same. Bitcoin standard tx are payments to the PubKeyHash. So if A & B have the same hash then the private key for A or B can be used to spend outputs sent to that PubKeyHash. A MINER DOES NOT KNOW THE PUBKEYS AT THE TIME AN OUTPUT IS CREATED. Payments are only to the PubKeyHash. The scenario created by the OP is a complete non-issue, however your solution isn't a solution either. How can miners record the pubkey or first round hash for a value they don't know. They won't know the PubKey (as opposed to the PubKeyHash) UNTIL the output has already been spent. It solves nothing. Once spent the PubKey IS recorded. It is part of the input in the tx and is part of the blockchain. Making another recording of it does nothing, it has already been spent. You don't understand the issue at hand I suppose. OP's scheme will only work(i.e., creating a hash collision) by finding two private keys. A birthday attack allows you to find two output values f(x1)=f(x2) for some random pairs of inputs of x1 and x2, it doesn't care what you function f is, whether it is some hash(x) or hash(ecc(x)) or hash(wtf(x)), as long as it's single input and single output it will work, so it's all the same 2^(n/2) attempts whether you try to find two privkeys with colliding hashes from their pubkeys, or just two pubkeys with colliding hashes. However, in our particular case the simplest hash(x) scheme will not work because it requires an infeasible number of equality check and storage space, because the input pubkey length is twice as large as the output length so only the naive method applied, yet for Bitcoin the private key is 256 bits, the same length as the output, cycle detection http://en.wikipedia.org/wiki/Cycle_detection can be applied to reduce the storage space to constant. It's a solution because miners are supposed to record hashes for any unspent address that is reused, so they will already know the hashes of the pubkey if a second pubkey tries to spend the same address, and that's why I say not completely spent. |
|
|
|
No. The Public Key is unknown for the vast majority of active addresses. What is the PubKey or SHA-256 hash of the PubKey for this coinbas reward in this block: https://blockchain.info/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26fHint: only the owner knows. If this output is spent in the future you would have no method of knowing if it was the "real" owner's spend or a pubkey collision. Bitcoin INTENTIONALLY makes the PubKey UNKNOWN until an output is spent. Once it is spent there is nothing to "protect". Addresses shouldn't be reused. So it is not a solution, even for this non-problem. The supposed problem is someone creating two random private keys that spend the same address, because he is the creator of both so he knows both, not someone trying to spend other's address. And for RIPEMD-160, with just 2^80 steps he can find such two private keys. |
|
|
|
A practical and perhaps trivial fix is for miners to record both SHA-256 and RIPEMD-160 hashed addresses for the pubkey of each address that is not completely spent, and reject any further pubkey that hashes to one but not another, while normal users will only need to remember RIPEMD-160 addresses.
There is no such thing as "not completely spent". Outputs are either spent or unspent. Miners won't know the PubKey until an output is spent. The standard tx for Bitcoin is "pay to PubKeyHash". In the output of a tx only the receiving pubkeyhash is known, not the pubkey. Still it is not a credible attack, no fix is needed. Miners shouldn't do anything that encourages address reuse. I am not sure what you are trying to state other than a terminology problem, I would not have written the quoted post without knowing what you wrote here, do you think the "fix" I proposed will work(by checking two different hashes to make sure there will not be a RIPEMD-160 collision through birthday attack, so that no two privkeys can spend the same address) for the supposed problem or not? I have other reasons for such a fix but I want to wait for your clarification first. |
|
|
|
|
A practical and perhaps trivial fix is for miners to record both SHA-256 and RIPEMD-160 hashed addresses for the pubkey of each address that is not completely spent, and reject any further pubkey that hashes to one but not another, while normal users will only need to remember RIPEMD-160 addresses.
|
|
|
|
|
I tend to disagree, Android sucks when it comes to security and cryptographic features, it's a shame that Bitcoin wallets have no chance to take advantage of iOS's security features.
|
|
|
|
|
The real estate developer is a subsidiary of one of China's largest online entertainment company, they have stated that they adopt BTC mainly for two purposes: (1). they want to show that unlike other real estate developers, they have roots in the internet and is kind of young and cool; (2) their mother company have experiences with the payment industry, so they want to explore a bit more about BTC in that aspect.
They also stated that their commitment to BTC will be long-term, the original link is in Chinese, if anyone cares to read I will post it here.
|
|
|
|
If I put my tinfoil hat on, I can't eliminate the possibility that it's some taxpayer funded organizations' plot to : 1. raise as many bitcoins for themselves as possible; 2. guide public opinion to support more regulations and blacklisting for Bitcoin.
Well, anyone would want free bitcoins not just the government, so Im not quite understanding that point. It's funny how they consider the distributed botnet to be not prosecutable, while targetting the also distributed Bitcoin network. |
|
|
|
Actually, there is one thing the Chinese admit to loving more than both saving and gambling: Gold.
Thankfully many of them are starting to see that bitcoin is superior to gold in every single aspect, and their government can't steal it from them.
I foresee both China and India holding more than 30% of the planet's bitcoin each before 2016. The way USSA regulations are starting to look; we'll probably only hold about 1% by then.
bitcoin is not superior to gold in every single aspect. gold is a much safer more secure store of value. it has thousands of years of history as a reliable store of value, bitcoin can make no similar claim. a flaw in bitcoin could be found tomorrow bringing the value crashing down to ~ zero or a crypto that is superior in every way could be invented that would steal ~ all of bitcoins market share. bitcoin is for transferring value and speculating, gold is for making your wealth safe and secure. both very useful for what they do but different utilities entirely. There is a higher chance that your house gets broken into by the burglars than Bitcoin crypto breaks down I believe. |
|
|
|
The original discussion was about being able to find 2 keypairs which form the same bitcoin address in 2^80 attempts on average. Assuming someone has the resources to do this, what is the advantage for them? I can't think of anything they could do to take advantage of this?
Also to perform the attack, I'm thinking you'd need to store at least 52 bytes per address (32-byte private key and 20-byte pubkey hash). This is 52 Yottabytes of data!
Nothing. The OP claim is they could do this at massive expense to spend coins from an address using two different pubkeys and that would be a negative PR for Bitcoin. I am doubtful how much of an effect it would have and if anything people would be a repeat (or thousands of repeats) which wouldn't occur and it would be chalked up to incredibly bad luck. Still anyone with the resources to do this could 51% the network which is an "easier", cheaper and far more direct attack. He can't spend coins from them, all he could find are two hash-collision pubkeys. |
|
|
|
|
And this how you debunk media double-speak, we can be absolutely certain that there is nowhere near tens of millions of victims of this virus, not even a fraction.
|
|
|
|
I'm sure that many traders in China just love Bitcoin because it's something that keeps going up. It could represent black pearl encrusted tigerskin handbags for all they care. However, when it is generally realized that it is the perfect currency for international trade settlement, then expect a wave of factories to begin accepting btc for their exports.
I am more of the hope that those black pearl encrusted tigerskin handbags selling shops in the developed world will someday make the shocking discovery of what kind of a business opportunity it will give them if they start accepting bitcoins. |
|
|
|
|
If I put my tinfoil hat on, I can't eliminate the possibility that it's some taxpayer funded organizations' plot to : 1. raise as many bitcoins for themselves as possible; 2. guide public opinion to support more regulations and blacklisting for Bitcoin.
|
|
|
|
|
It's all the same stuff they have been talking for years, nothing new. It's still a PITA to set up Paypal and use it to buy anything.
|
|
|
|
|
Show Posts
