Exchange cannot have exclusive control over users' BTC.
Sounds like a double spend waiting to happen. Explain how you think an exchange can accomplish this? |
|
|
|
|
If they weren't trying impossibly large transactions, would they be able to succeed?
|
|
|
|
|
You want to sue them because other portions of the Bitcoin community stole your info and are now selling it?
Shouldn't you go after the thief and not kick the victim any more?
|
|
|
|
Miners should be viewed as profit driven entities.
They have a negative incentive to relay transactions, which means you can't depend on being peered with them to hear about transactions. A doublespend is as easy as sending one tx to the miner, and one to the merchant, the miner has no incentive to relay the transaction, so the merchant may never hear about it until it is in the blockchain, and they are out of a payment.
It is for this reason that it should be a standard to break trust in 0conf transactions, because eventually miners will stop relaying transactions so they alone are able to mine the fees.
This was helpful. I'm trying to understand better how transactions get propagated on the network, and how that can be controlled. How does one control who the transactions get relayed to, e.g., deliberately choosing to only send a transaction to a specific miner? Can this be done on any wallet application, or do most wallet apps automatically control the propagation of the transaction on the network? Also, is there a drawback to this, e.g., the fewer nodes that you send the transaction to, the lower the likelihood that the transaction gets picked up in the next block? What you're describing almost makes double spends seem too easy! It's a little disconcerting, but agreed with your point about the importance of getting that first confirm. I suppose that's the lesson. I've given thought on how to determine mining nodes, over the course of a couple hundred transactions and blocks, you should be able to determine with great confidence if a node is a miner or not. By both listening for blocks and sending transactions, you should be able to determine a path of peers back to a mining node. Like, listen for a few blocks and see which peer gives you blocks the fastest on average, then peer with their peers and repeat. Eventually you will have to start sending transactions (this part is under the assumption that mining nodes do not relay transactions) and see when they don't always get included in a block (telling you that you found a mining node, but it wasn't the one that mined the block). This process would most certainly take more than a few days to complete, the more nodes you put out into the wild attempting it, the faster it would be accomplished. Or, you could just assume that a miner's getwork is done directly on their node. But either way, once you are peered directly with a miner, you are very likely to be able to doublespend under the current implementation of not relaying conflicting transactions. |
|
|
|
If you are only connected to one "full" node, you are in trouble... but if you connect (randomly!) to many, then you are more likely to be fine. Multibit is based on this approach, and it surpassed a million downloads recently, so it's a successful model. Read this: https://code.google.com/p/bitcoinj/wiki/SecurityModelInteresting stuff, I'll see if I can't ensure random node connections on a regular basis. And I'll have to time my downloading of new blocks to make sure that the time remains constant on average. |
|
|
|
Are you just implementing your own version of Simplified Payment Verification?
There is a lot of discussion out there already on the vulnerabilities of this.
I've never looked at Simplified Payment Verification, but I'll see if that is indeed the idea I am making. That's amazing. You and Satoshi Nakamoto think alike  (he wrote about this in his white paper) I've read the white paper before, so I probably just forgot what it was called and was just subconciously using the whitepaper as my source. But what would some ways to keep my node from being tricked? If downloading the entire blockchain is not an option. |
|
|
|
Are you just implementing your own version of Simplified Payment Verification?
There is a lot of discussion out there already on the vulnerabilities of this.
I've never looked at Simplified Payment Verification, but I'll see if that is indeed the idea I am making. EDIT: And it is. |
|
|
|
|
What are some security concerns of a node which only saves transactions that involve itself?
Other than the obvious of being unable to verify transactions, and relying on them being buried a few blocks deep before "accepting" them. What other attacks would such a node be vulnerable to, and what are possible ways to defend against them?
Right now the node I'm running saves headers, coinbase, and tx involving itself. What am I vulnerable to?
|
|
|
|
|
Is this supposed to be a gox joke?
|
|
|
|
On a side note, let's stop the misuse of the word "collision" please. A "collision" in an algorithm is when two different inputs give the same result.
A fail wallet client having a fail keyspace and always giving the same keys is not a collision, is just a fail
I suppose you're right. It's semantics really though. In time there will be collisions because the probability is not 0. However, not only do you have to match an in-use key, that key also has to carry a balance.
By brute-forcing keys, the probability is the lowest. Anything related to a vanitygen that's not truly random, is at risk of being brute-forced as it seriously diminishes the keyspace. As time goes on, if people do not adhere do the rinse-and-don't-reuse address policy, the collision probability will increase. People are already generating lists upon lists of private keys just for the sake of generating them. As hardware and storage technology increases, its less of a monetary drain to just let a computer go to work generating Millions upon Millions of addresses every second.
The probability is non-zero, but thats also why they say its improbable not impossible.
I can't wait to get my hands onto a ASIC designed to generate keys. |
|
|
|
I don't think you fully understand how large 2^256 is:
Isn't it 2^160? since bitcoin address is actually a 160bit hash. Now 2^160 is still quite large, but let's assume every person on earth uses Bitcoin, and has 100 addresses (the default of Bitcoin qt client pre-generates 100 addresses). Now we are down to (2^160)/700B Are you still confident that it's large enough? I personally have over 100M private keys generated. But even 100 addresses per person is an understatement, the spec recommends never using an address twice, especially since once you sign a tx, it becomes that much easier for a QC to crack your private key. Unless the algorythm is cracked, no, we will not see collisions, stop spreading FUD.
Personally I believe it's FUD to exclaim that we WONT see collisions. There have been a few cases where wallet implementations have resulted in extremely reduced keyspaces. |
|
|
|
Even if you produced an address collision, you still need a private key that can sign the tx.
Yes, but it does not have to be the same public/private key pair. Hmm, so then we'll see collisions even sooner. |
|
|
|
Technically, addresses are only 160bit hashes.
If that RNG is not working properly, that is a bug in the RNG. Bitcoin has already exposed problems with the Android RNG.
Even if you produced an address collision, you still need a private key that can sign the tx. |
|
|
|
Make your own key by hand then Pretty sure my RNG would be very easy to bruteforce. Facts and maths are great, but you never know do you!
That's why I've had my vanitygen running on the satoshi wallets since 2011.
I really want you to be telling the truth, and I really want you to succeed, just to prove that it can be done. |
|
|
|
How is a mixer "unethical"?
Is it unethical to have window blinds so anyone that wants to can't look into your house too?
Is it unethical to use cash since it doesn't have a tracking microchip in it to see where you're going with it?
I mean, should the exchange tell it's customers whether or not it mixes their coins, and then if it mixes them with non depositors coins as well? |
|
|
|
I don't think you fully understand how large a 2^256 is:  That image is exactly what I'm talking about it. And I don't think you understand how easily a flawed RNG can shorten the work required to bruteforce a key, let alone generate an inuse one on accident. |
|
|
|
|
I am officially giving my opinion that Bitcoin as we know it will not exist, or if it does, it won't be the major cryptocurrency in use.
Cryptocurrencies are here to stay, but I doubt Bitcoin will be a major player in the long run.
|
|
|
|
|
Because I'm sure we're all aware that due to the nature of random number generators, and implementations, the more widespread the adoption of Bitcoin, the more likely it is that we will see key collisions.
Are we even sure that ECDSA even has an unbiased distribution?
|
|
|
|
|
I've heard so much stupid stuff from both sides of the fence.
|
|
|
|
|
Are there any ethical concerns with an exchange using their balances to mix coins? Since the tainted coins would be returned to customers when they withdraw?
|
|
|
|
|
Show Posts
