And for RIPEMD-160, with just 2^80 steps he can find such two private keys.
You are now just combining words which don't make any sense when used together. Hashes don't have private keys. No the issue is a hash collision. With 2^80 attempts one can find TWO PubKeys which hash to the same PubKeyHash. |
|
|
|
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. |
|
|
|
No. The Public Key is unknown for funded addresses that have not been spent yet. What is the PubKey or SHA-256 hash of the PubKey for the coinbase 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 "original" owners pubkey or a collision pubkey. 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 other thing to note is:
Gavin A proposes adding API callbacks into the bitcoin URI so that retailers do not have to use unique addresses per customer, but using one address and be able to track which TXID belongs to which customer by use of the API callback.
so we have Gavin A trying to reduce the need for unique addresses. and we have Luke Jr trying to increase the need for unique addresses.
can we find a room for the main dev's to go in and slug it out for a few matches as to something that can be agreed on that is best for the community..
Link please. Nothing I have read about the payment protocol implies static addresses. |
|
|
|
You can be guaranteed that they will ship before Jan. 1. Even if it is broken, consumes 10x the power, 1/2 the hash rate, and uses someone else's chips, you will be sure they will ship
Wanna bet? (No, I've not learned my lesson about those kind of bets yet.) I will bet if u are willing. HashFast is a US located and registered company. They have binding arbitration agreement in their contract. They essentially lose everything by not shipping by 1 Jan. |
|
|
|
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. |
|
|
|
The only important point for me is that if bitcoin gets a value of say 10.000 dollar do we still have to pay the ridiculous high fees for transactions ....
If i get payed now say 0.001 btc or i have to pay that amount i have to pay the same amount on fee .... how you would see that in the future if bitcoin really would pass the 1 million each.
At this point its already annoying while the value is just hovering around $400.
No. The min fee has been reduced 3 times by a factor of 1000x since Bitcoin began. Today it is 0.1 mBTC (0.0001 BTC or ~$0.04 per KB). To avoid high fees try to avoid dealing with sites that payout tiny amount of Bitcoins (i.e. 0.000001 BTC). Fees in Bitcoin are based on transaction SIZE not value. Sites which payout dust are creating a scenario where spending that dust is either impossible or prohibitively epxensve. They know this and rely on lack of knowledge by noobs to continue to operate. |
|
|
|
The BTC ecosystem sounds contradictory. On one hand everybody says cryptocurrency will take over the world, but on the other hand, not to many people can even afford 1 BTC. How can it take over? Why do you need a whole Bitcoin? A Bitcoin is simply a unit. The price of gold is about $38,000,000 per ton. Can you buy a ton of gold? Could you buy a smaller amount of gold? If BTC gets to expensive and people just start buying satoshis; I guess the price of 1 BTC could be 1 million dollars, only if 1 satoshi = 1 dollar. There are 100,000,000 satoshis per bitcoin. So if 1 BTC = $1M USD then 1 satoshi = $0.01. BTW I personally don't think Bitcoin will reach a price of millions of even hundreds of thousands of dollars per BTC but if it did 8 digits is enough to keep the value of 1 satoshi relative low. |
|
|
|
|
ZWUfbegHh325UeYy3pzMz6Y7NxNgAQwRh7 is not a valid Bitcoin address, so the error message is 100% accurate.
|
|
|
|
It amazes me how short sighted people can be.
Well it is easy to be "short sighted" when pushing an agenda. |
|
|
|
I. Auction bidding. This can be accomplished with a BIP32 address chain Is this supported with blockchain.info or bitcoin-qt at this time? No however I would strongly encourage you to advocate for them to update. |
|
|
|
And likely the last...deflation prevents spending and thus it's not an economy at all but just a speculative commodity, with a finite shelf life. But, we'd never known if we hadn't tried right? After this experiment is over, hopefully we can come up with some realistic solutions to our monetary systems problems.
Keep waiting. Bitcoin actually has monetary inflation and will have it for over a century. Price deflation would still be likely in Bitcoin even in the rate of printing was much higher. |
|
|
|
I. Auction bidding. This can be accomplished with a BIP32 address chain II. Payouts of mining pool
I also don't see how to communicate with my shareholders to ask them for new payment addresses, as I don't know their identity. Worst case scenario if you stop sending regular payments I am sure they will contact you.  In the future you could have them generate a BIP32 public key, put that PubKey in a message and sign the message with the existing address as a cryptographically secure way to transition. |
|
|
|
I honestly can't see bitcoin continuing like this forever. It's price is increasing at such a rate that I believe it must at some point collapse under it's own weight. The price will drop so severely that most disregard bitcoin for the foreseeable future and it is left at a meager price with only hardcore enthusiasts still using the currency.
Sure. Bitcoin has crashed hard in the past and it didn't bring about doom and gloom despite similar predicts both before and after major crashes. |
|
|
|
|
Past performance is not a guarantee of future success.
Still if something is worth $0.02 today then it is worth $0.02 today. Instead of wasting your time of pennies IF (and not saying it will happen) price rises 10,000x wouldn't it be smarter to just buy say $20 worth of Bitcoins and hold them. Same increase on 1000x as many coins.
|
|
|
|
|
Once again. PRICE =/= VALUE.
|
|
|
|
A question for the OP: Are you proposing this just for addresses that are reused after a output, (where the privacy risk is highest), or also for addresses that have multiple inputs but only 0 outputs before the transaction in question? The risks (which are not limited to mere privacy, I might note) are the same for both of these cases. In any case, while I did only provide a single patch upfront, my proposal is to discuss and implement a variety of possible solutions, not any single solution, in the short-term. What? What's the risk? It leaks cryptographic information - that's how that recent 55BTC hack occurred (in combination with the PRNG issues in Java SecureRandom lib). Also in the event that ECDSA is degraded the pubkey being unknown (payments are to pubkeyhash) provides an added layer of security. Commonly people assumes algorithms are either "safe" or "broken" where broken means someone can instantly find a private key from the public key. The reality is often algorithms are merely degraded. As an an example a flaw could be found in ECDSA such that it takes on average 2^60 operations to perform a preimage attack (normally 2^128 by brute force. Now 2^60 is a relatively large number but a dedicated attacker with sufficient resources could attack (over the course of months) a known PubKey. If the PubKey is unknown no attack is possible. |
|
|
|
Why would they interfere? That's only superstition.
The chance that a proof of work (aka share) mined at difficulty 1 will produce a block is 1 divided by the difficulty.
So your hashrate determines how many lottery tickets you get, and the difficulty determines how likely each lottery ticket is to win. That's all there is.
please note that as soon as a block is found all old tickets are thrown away and new are printed  Well no tickets are thrown away as soon as they don't win. Hash = losing ticket Next hash = losing ticket Next hash = losing ticket ..... 1 hash or quadrillions of hashes later ..... Next hash = winning ticket. Block solved. |
|
|
|
Remember price =/= valuation. Not speaking on the merits of the model but if the model is using non-price inputs and speculation drives price up (in short term) faster than the underlying economic activity the model isn't modeling that. However as you see price eventually corrects to value.
Price + Time = Value Economy per se , has no direct Impact in that , the History of BTC speaks for itself That is about the dumbest thing I have heard today. |
|
|
|
What about donation addresses?
An address is an address. The protocol/network cares not the purpose. It is possible to use a dynamic address for donations. |
|
|
|
|
Show Posts
