It's equally possible that I am indeed being framed, and by ostracizing me, you effectively choose to trust the evil guy.
so the worst thing that could happen to me is that my validator needs to run with a smaller list of trusted nodes. As long as the list is sufficiently diverse that doesn't hurt. I can employ this(and other) tactic to eliminate enough validators from your UNL to push my percentage to over 51%, so your "as long as" becomes invalid, consensus should work when I, a malicious guy, controls only 30%(I am sure not going to tell you) of your trusted nodes, gaining 21% more control by eliminating somehow "more susceptible" non-colluding nodes doesn't sound too impractical. Besides, when a Ripple network is at its beginning, how do you decide which nodes are more trustworthy? A botnet may flood the whole network with its sockpuppets which obtain their XRPs through a variety of means, and stay as cooperative and helpful as possible, but after they start gaining people's trust they may start abusing it without even getting noticed, heck, they don't even need to be 51%, just big enough to have a significant number of trustworthy nodes. I suspect maybe Opencoin is now putting a tightened grasp on XRP control just because of this. |
|
|
|
The problem is how can you prove I am trying to be two validators? Say I only give one guy a false key, and if he's trying to accuse me then I can say everything including the supposedly signed ledger is made up by him, I can say I never produced such a thing, and the guy trying to accuse me is a fraudster himself.
"Prove" is a stronger word than "mistrust". To mistrust you (or your two validator identities) I don't have to prove anything, it's enough that my gut feeling tells me that there's something fishy with those two validators, so I stop trusting them. Onkel Paul It's equally possible that I am indeed being framed, and by ostracizing me, you effectively choose to trust the evil guy. |
|
|
|
Quantum Computers that do calculations in Qubits are not too far away; they have now been able to do calculations using 84 Qubits!! Holy! In 2009, researchers at Yale University created the first rudimentary solid-state quantum processor. The two-qubit superconducting chip was able to run elementary algorithms. Each of the two artificial atoms (or qubits) were made up of a billion aluminum atoms but they acted like a single one that could occupy two different energy states. http://spectrum.ieee.org/nanoclast/computing/hardware/largest-quantum-computer-calculation-to-datebut-is-it-too-little-too-lateIn Brian Wang's interview with D-Wave’s Rose, there's a discussion of the company’s new 512-qubit chip that should be, according to their calculations, 1000 times faster than the 128-qubit chips that D-Wave is currently working with the best is from a group in Australia that has made a real 1 atom qubit. In September 2012, Australian researchers at the University of New South Wales said the world's first quantum computer was just 5 to 10 years away, after announcing a global breakthrough enabling manufacture of its memory building blocks. A research team led by Australian engineers created the first working "quantum bit" based on a single atom in silicon, invoking the same technological platform that forms the building blocks of modern day computers, laptops and phones http://www.gizmag.com/d-wave-quantum-computer-supercomputer-ranking/27476/Even if their claims are bs, someone should be looking into this, it's only a matter of time before they begin mass producing these, bringing the price down: how many of these will it take to break the SHA256 encryption? 512? http://www.dvice.com/archives/2012/04/quantum-simulat.phpThey're up to 7 real qubits so far... obviously D-Waves computer is not a true Quantum computer, but that level of hashing power is enormous it could crack the SHA256 in no-time. First, they are nowhere near being capable of cracking ECDSA or RSA, the most direct proof is they are not factoring any number larger than 21. Second, even if a QC is created, the best they can pull off is a 51% attack, which can be done by any government right now with classical computers. |
|
|
|
Will every node have to obtain my verification key from other nodes on the network, or will they get it from me?
Why would they need your verification key at all? If you mean to process your transactions, it works much the same way as Bitcoin. Your "account" is a hash of the public key and transactions include the public key in them. If you mean you're acting as a validator (which is absolutely not needed to introduce transactions) then they would get your public key from whatever source induced them to trust you. You can publish it through HTTPS. If it's just me, as a validator I can always propagate two versions of my signatures corresponding to different keys, I can still cheat without being found. Then you would be two validators. If either validator wasn't behaving rationally, people would just stop trusting it. To do any real harm, you'd need to control a significant fraction of the validators that people trust. Then it'd be much like a Bitcoin 51% attack -- except after all that trouble, people would just stop trusting you and you'd have to start over from square one. Whereas, with a 51% attack on Bitcoin, it's much harder to recover. (Though not impossible, of course.) With Bitcoin's proof of work based algorith, you have to trust that the majority of mining power will not collude against you. With Ripple's consensus algorithm, you get to choose the validators that you trust not to collude against you. Admittedly, this has disadvantages as well -- if you choose very badly, you could suffer for it. In realistic scenarios though, I don't think it's that hard to choose wisely. And the attack is so hard to make and gains you so little (just a denial of service attack unless you control the *vast* majority of validators), I don't think anyone is likely to bother. If they have to obtain it from someone else, then you have to use either PKI, or a web of trust, which I assume is what you use no?
Not really a PKI or a web of trust. The simplest way is to publish it using HTTPS. Look at https://bitstamp.net/ripple.txt for example. The problem is how can you prove I am trying to be two validators? Say I only give one guy a false key, and if he's trying to accuse me then I can say everything including the supposedly signed ledger is made up by him, I can say I never produced such a thing, and the guy trying to accuse me is a fraudster himself. It's not really relevant, you have to either trust a authoritative third-party or the people who transmitted this information to you, like the digital certificate of the website(PKI), forum on which your website address is published, or other Ripplers who told you where the validator's website is(web of trust). Most importantly, you can't prove I am cheating if I try to frame someone by claiming I received a copy of ledger signed with a different key from him, especially if I control more nodes than him(nowhere near 51%), which are not known to collude. |
|
|
|
"And like every good American, I don't like what I don't understand!"
*close tab*
The biggest problem of typical Americans with Bitcoin, is their math education is in shambles. This is a fact that can't be changed by just changing their attitude. |
|
|
|
Why not just refuse to deliver for people using addresses with unconfirmed transactions in it?
Absolutely. I mentioned this in the post just after the OP. The only transactions which are a problem are those where delivery is made first (such as buying petrol, or after a restaurant meal). Fiat transactions of this type are done quickly and the customer is gone. I had an idea: what about just spending bitcoins like physical coins, with fixed denominations? This should not be too difficult to implement on a client: the client creates several hundred addresses in a batch(like when you are asleep), and fill them with bitcoins in fixed denominations, 5 BTCs, 2 BTCs, 1BTC, 0.5 BTC..... whenever the user needs to spend, the client chooses a number of addresses with just enough BTCs in them(no more than 15 for a price with three digits after the dot I guess), and generate a transaction with all these addresses as inputs. The merchant can then just check if all of the address are "fresh" to decide if he will accept the payment. Each address will be used only once, and the client will periodically check the number of remaining unused addresses to determine if another round of creation is required. |
|
|
|
Guys, don't forget that Bitcoin has eventual consistency. And there is no way to circumvent CAP theorem. So there is no a solution to the slow confirmations problem. It doesn't matter. Every business has a small overhead from transaction errors, counterfeit fiat money, bad debt or theft which result in net losses. These losses are absorbed by raising the average product price paid by all customers of each business. A business suffering a loss from a rare Bitcoin double-spend will have to absorb such a loss, or insure against them if it decides that is the best approach. However, it seems likely that double-spend losses will be smaller overall than those seen with bad fiat transactions. Why not just refuse to deliver for people using addresses with unconfirmed transactions in it? And for anything valuable enough to use Finney attack it's reasonable to wait a bit longer. |
|
|
|
What would be the negative implications of 30-second blocks with a reward per block that would keep the same creation rate we currently have?
Too many orphaned blocks? |
|
|
|
|
Hmmm, so what's the "SHA-256 became completely broken" everyone, including Satoshi was talking about in the post OP referred to really meant?
|
|
|
|
|
Thank you maaku. My 0.5 BTC because we all want to see it happen.
|
|
|
|
Will every node have to obtain my verification key from other nodes on the network, or will they get it from me?
Why would they need your verification key at all? If you mean to process your transactions, it works much the same way as Bitcoin. Your "account" is a hash of the public key and transactions include the public key in them. If you mean you're acting as a validator (which is absolutely not needed to introduce transactions) then they would get your public key from whatever source induced them to trust you. You can publish it through HTTPS. If it's just me, as a validator I can always propagate two versions of my signatures corresponding to different keys, I can still cheat without being found. If they have to obtain it from someone else, then you have to use either PKI, or a web of trust, which I assume is what you use no? |
|
|
|
Correct me if i'm wrong!
You are wrong. If Bitcoin was using (double) MD5 for its proof-of-work hashing algorithm, we'd be just fine. How about having 2 valid blocks with same hash? How can you? The blcokheader, other than the nonce, has deterministic data in it, no? |
|
|
|
It's fascinating to watch people who share absolutely no common trait with geeks getting nervous over this geeks' toy daily. And surrealistic to see anarchistic crazy talks we are all familiar with becoming realities.  |
|
|
|
Random wild speculation, not going to justify. This one looks a bit "close"  http://onlinelibrary.wiley.com/doi/10.1002/ecjc.20186/abstractEDIT: I think even if we can never know his real identity, we can still speculate on his personal experience, like how he comes to give himself this name(suppose it's not his real name), that's mostly why I find these things relevant. |
|
|
|
What will happen if I send one fake version of the proposed ledger to one validator, and another version to the rest of the network? How can the honest nodes finds out who is cheating? Everything is either signed or sent to a node who already knows the hash of the item it wants because it was referenced by something signed, so you can't send a fake anything anywhere. Basically, consensus just determines the order in which transactions are applied to resolve the double spend problem. Once a transaction is applied, conflicting transactions are blocked. Candidate transactions must be signed by the account that issued them. Validations and proposals must be signed by validators you've chosen to listen to. Otherwise, you just ignore it. Will every node have to obtain my verification key from other nodes on the network, or will they get it from me? |
|
|
|
I think if you still need to select several third-parties to decide which one of the two transactions invloved in a double-spend is valid, it's essentially a "commander and lieutenant" solution to Byzantine Generals problem.  You go with the transaction that's in the consensus ledger or one of its prior ledgers. If there isn't a consensus ledger, you deem the network fatally broken and don't trust any transaction. What will happen if I send one fake version of the proposed ledger to one validator, and another version to the rest of the network? How can the honest nodes find out who is cheating? |
|
|
|
I think if you still need to select several third-parties to decide which one of the two transactions invloved in a double-spend is valid, it's essentially a "commander and lieutenant" solution to Byzantine Generals problem. |
|
|
|
|
And for address hashing I think we can just switch to SHA256(SHA256(PubKey)+PubKey), right?
|
|
|
|
LIARS, LIARS, LIARS !!
Please do something for me: DIE.
In the more than a decade that I've discussed everything from politics to religion to philosophy over the Internet with people, I can count on my two hands the number of times I've become convinced that a person was not arguing in good faith. You have joined a very exclusive club. Joel, can I get a reply to my last question: is there a place where I can see the total amount of XRPs in circulation? Thanks. |
|
|
|
|
Show Posts
