Hmmm, what will happen if more than 51% of the validators on the network telling you that a conflicting transaction has been sent by the same initiator of your version of the transaction, while in fact, they are all lying?(the initiator only sent one transaction) If a transaction is not validly signed, even if it gets in a consensus set, it still can't be applied to the ledger. If a conflicting transaction is already in a prior ledger, then again, the transaction can't be applied even if it gets in a consensus set (this is basically the definition of "conflicting"). The consensus process only orders transactions to prevent disagreement and double spends. It can't make a transaction valid if it doesn't follow the rules. So what's the case where this is an issue? If both versions of the transaction are validly signed and neither has yet been included in a fully-validated ledger, then who cares which one gets in? Seems that every transaction has to have all validators' signatures attached, will there be storage problem? |
|
|
|
How do they just "forward"? You mean they forward to every validator in the global network to see if there is any conflict?
Like Bitcoin nodes do, all Ripple servers flood transactions across the network. When a Ripple server receives a transaction, it performs the following operations: 1) It checks if it has ever seen this transaction before. For now, assume it hasn't. 2) It checks if it has received the transaction from a cluster peer (server under common administration) that has already checked the signature. For now, assume it hasn't. 3) It internally queues the transaction to have its signature checked and puts the server it received the transaction from on the transaction's exclusion list. 4) If the transaction is received from any other servers, those servers are added to the exclusion list for the transaction. 5) When the transaction gets to the head of the line, the signature is checked. For now, assume it's valid. 6) If the server is able to, it checks if the transaction can apply to the current ledger. If not, it will not forward the transaction. 7) The server forwards the transaction to every server connected to it that is not on the transaction's exclusion list. When sending to cluster peers, it sets a flag indicating it has already checked the signature. Hmmm, what will happen if more than 51% of the validators on the network telling you that a conflicting transaction has been sent by the same initiator of your version of the transaction, while in fact, they are all lying?(the initiator only sent one transaction) |
|
|
|
So Alan how is it going with the usability issue? I don't mean to be demanding but would like it if you can give me some time frame.  |
|
|
|
Since when does guidance become law?  The guidance is meant to be interpreting existing law! Turns out the legislators used a time-machine to go into the future, learn about cryptocurrency, but did not detail it openly in their legislation. However, FinCen found enough clues to detect this hidden wisdom and produce the detailed guidance needed to cover cryptocurrency. So Mt Gox broke laws about cryptocurrency which existed before Bitcoin was created. Ha! http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&sid=d5570d7646c5fc13fe1fa42a61d1dcf1&rgn=div5&view=text&node=31:3.1.6.1.2&idno=31#31:3.1.6.1.2.1.3.1See here: "(m) Currency. The coin and paper money of the United States or of any other country that is designated as legal tender and that circulates and is customarily used and accepted as a medium of exchange in the country of issuance. Currency includes U.S. silver certificates, U.S. notes and Federal Reserve notes. Currency also includes official foreign bank notes that are customarily used and accepted as a medium of exchange in a foreign country." As if they were worried that they were not clear enough that "currency" must be something issued by a government! Onto a serious note: what you have said has just given more weight to the hypothesis that Satoshi is employed by the U.S government, that's why they knew!  |
|
|
|
What I meant is what if the two transactions I sent to distinct groups of validators conflict? I should not be able to double-spend right?
The validators just forward the transactions to each other and each one will include the one it saw first in its initial proposal. One of three things will happen: 1) One transaction will get a majority and the other won't. In this case, that transaction will be included, permanently conflicting out the other. 2) Neither transaction will get a majority. In this case, servers that have seen both transactions (which should be almost all of them) will pick a winner based on a deterministic rule. The transaction that wins by rule should get in during the next round. 3) Somehow, both transactions get a majority (doubt this will ever happen, but suppose it does). In this case, a deterministic rule again determines which transaction gets in. Really, all you need to do is agree on the order of transactions. Validators do that by agreeing on candidate transaction sets in distinct chunks. How do they just "forward"? You mean they forward to every validator in the global network to see if there is any conflict? |
|
|
|
What about my question? How do you reach global consensus? I can propagate two versions of one transaction to two different non-overlapping groups of validators, what will happen? Distinct Ripple networks (if they exist) don't have to agree on anything. If you have validators who have no validators in common, you have distinct networks. To join a network as a validator, you must agree to reach a consensus with some subset of the validators in that network. You also take on a responsibility to manage the set of validators you try to reach consensus with. What I meant is what if the two transactions I sent to distinct groups of validators conflict? I should not be able to double-spend right? |
|
|
|
Since when does guidance become law? |
|
|
|
|
What about my question? How do you reach global consensus? I can propagate two versions of one transaction to two different non-overlapping groups of validators, what will happen?
|
|
|
|
So I read the warrant against Gox, http://cdn.arstechnica.net/wp-content/uploads/2013/05/Mt-Gox-Dwolla-Warrant-5-14-13.pdf , and I think basically they are trying to justify the seizure by saying Gox is involved in dealing in currency and transmitting money for their customers, which Karpeles denied when he registered the account with the bank, however, I doubt whether such accusation is really well-founded. First, the warrant is very assertive that Bitcoin is a digital currency, and Gox is a digital currency exchange, nevertheless, according to http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&sid=d5570d7646c5fc13fe1fa42a61d1dcf1&rgn=div5&view=text&node=31:3.1.6.1.2&idno=31#31:3.1.6.1.2.1.3.1(search for "(m) Currency") Gox cannot be called a currency exchanger or dealer because it doesn't deal in foreign currencies, you cannot exchange dollars for other currencies on Gox directly, you can only exchange them for bitcoins, which is not a currency by their definition.(In fact, the Japanese authority considered Bitcoin a ledger and decided not to regulate) Second, Gox cannot be called a money transmitter either, according to the definition from the same source(search for "money transmitter"):"(5) Money transmitter —(i) In general. (A) A person that provides money transmission services. The term “money transmission services” means the acceptance of currency, funds, or other value that substitutes for currency from one person and the transmission of currency, funds, or other value that substitutes for currency to another location or person by any means. " Especially the following two exceptions: "(ii) Facts and circumstances; Limitations. Whether a person is a money transmitter as described in this section is a matter of facts and circumstances. The term “money transmitter” shall not include a person that only: (A) Provides the delivery, communication, or network access services used by a money transmitter to support money transmission services ...... (E) Provides prepaid access; or (F) Accepts and transmits funds only integral to the sale of goods or the provision of services, other than money transmission services, by the person who is accepting and transmitting the funds." So my conlcusion is there should have been no need for Gox to register as a money transmitter, as they never engaged in exchanging one person's currency and funds for another person's, and Karpeles should indeed answer "No" to the two questions. Any legally knowledgeable guy please enlighten me if I am wrong. |
|
|
|
Coinlab's offers their connections to silicon valley, their connections to business and finance, their access to American market, and their ability to be licensed and legal to operate in America.
I haven't seen any evidence showing they have them, all I see is talk. They are backed by VC's with strong decade long connections in Silicon Valley, they ARE FICEN compliant and DO have a business agreement's with an actual Bank in America. Some of the top investors/guys at Coinlab have decades of experience in the tech industry having held high level positions at companies like Facebook, Google, Amazon, Apple, and others. The industry connections and the legal compliances they agreed to provide to mt. gox they actually DO have. It's not just talk. Now let me ask you this though.... how are they suppose to do anything when Mt. Gox failed to do what they promised to do. How can Coinlab use their connections when Mt. Gox failed to provide them with accounts and technology they promised to provide. Coinlab certainly does have the connections , the backings, and the legal compliances to help and do what they promised to do. You can't do that though when Mt. Gox fails to deliver. And THIS is why Coinlab has sued. They are trying to get the ball rolling and get things done, Mt. Gox has prevented them from doing so though. Everything besides your first paragraph are just speculations, I don't think we know enough to figure out what's really happening(e.g., who breached the contract first). And about the facts you listed in the first paragraph, VC backing means nothing to me(heck, even Opencoin got backings!), and the $500,000 they got is certainly pocket money for VCs. FinCEN compliance is a fine point, but it still doesn't prove their competence. About the agreement with the bank, I don't know enough detail to comment about what kind of an agreement it really is, so I remain skeptical. |
|
|
|
Coinlab's offers their connections to silicon valley, their connections to business and finance, their access to American market, and their ability to be licensed and legal to operate in America.
I haven't seen any evidence showing they have them, all I see is talk. |
|
|
|
|
"End"? When will the all-mighty authorities that you all worship so much be able to shutdown Silk Road? All the talks with no substance, it's getting bored. I guess if you have worshipped the politicians for so long he/she will start to talk like them.
|
|
|
|
Not incredibly difficult to figure out: Mutum Sigilum has been used to funnel Dwolla in and out of Japan for years now. Isn't it convinient that just a few weeks (or maybe not even a week?) from Coinlab lawsuit GOX gets this?
Coinlab agreement was precisely to handle US customers under a more legit frame. How convenient the Feds do this just now!
People will say I am a crazy conspiracy theorist. Think what you will. There is a smoking gun and it points out to Coinlab.
DISCLAIMER: I could give two shits about GOX, and CoinLab. I don't like either. What sucks is that this is going to put a serious dent on Bitcoin after these news are digested fully.
I'm going to lean toward trusting Coinlab on this one. Gox is a screwed up exchange and I am not surprised at all by their alleged breach of contract. I really wanted that to work. Heck, Mt Gox has 500 errors on a day with volume as minuscule as today? Sure, Coinlab haven't failed at anything, because they haven't done anything. |
|
|
|
Strongly agree with the title. Even if I have my Bitcoin address in my signature, you can't prove that I actually own it unless you hack into my computer.
True if you don't spend any. Once you do - out goes your identity. How do you infer from a transaction being made from an address in a signature that the transaction actually was done by this person?! If I would put there for example a MtGox address, it would be swiped but I'd never ever have owned the private key to it. You will be only deanonymized for the address(es) that you use to pay a merchant from - and these can be from a mixing/proxy service. Haha, idea! Quick, everyone pick an address from the blockchain whose private key you do or don't own and post it in your sig. Confuse OP. 1PL8Xy3gb3GAuBCBjdMUoge67em6R7FXeL <------ me? 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX I'm gonna keep my eye on you. I can even frame others up by putting their address in my signature. Now you see it? I am proudhon, all his coins are mine. |
|
|
|
These misled people will only stop when they watch in awe how the drug dealers/gamblers/money launderers still transmit money under bright sunlight despite all they have tried. Why would that stop them? They won't stop bro... If we want to keep using bitcoins, we have to decentralize everything they touch. All right, maybe they will keep trying to hit their heads against a brickwall, who knows. It probably not decentralized enough for a law-abiding Joe Sixpack to use bitcoins, but it's enough for any tech-savvy enough people, especially the outlaws to trade with bitcoins whatever the authorities do. Silk road is there, web of trust is there, the smart contract is built right in the blockchain, and the mining would not stop unless they can confiscate every connected computer in the world. |
|
|
|
|
These misled people will only stop when they watch in awe how the drug dealers/gamblers/money launderers still transmit money under bright sunlight despite all they have tried.
|
|
|
|
For all the complete lack of planning we have witnessed with Gox, Karpeles should be given credit for his foresight of setting up the exchange in Japan. So far the authority there still doesn't seem to know what's going on and why should they care.
Karpeles didn't setup mtgox in japan, he just bought it. As for Japan not knowing what is going on or why they should care, that's naive. If US says jump, Japan will say how high. You're right with Gox, though Karpeles chose to go to Japan to find a job and keep the exchange there, so he played a role. As for japanese authority, I think it's actually naive to believe U.S can just have its way with Japan, or other sovereign nations, things are not as simple as on a high school playground, your alliance complies with your request when it suits their interest, while turns a deaf ear if it doesn't.Thank christ that Gox isn't located in the UK. Nah, there are times when even the UK Gov will be hesitant, otherwise they can just storm Ecuador's embassy, rather than spending millions of pounds to station policemen at its entrance. |
|
|
|
LOL, I love this: Note: There is currently no way to tell if you are in the network minority. This feature is coming. It's actually trivial -- if there are, say, 1,000 generally trusted validators and you see validation from fewer than 700 of them, you might be in the minority. This has been implemented in the server about a month ago, the wiki is just out of date. The results of the Ripple consensus process are never sent to clients directly as verified. The ledger must pass a "validation gate" before it's considered confirmed and this validation gate will never be passed if you're in the minority because you won't get back sufficient validations. In contrast, if you're in the minority, you won't know until manual intervention with Bitcoin. If the world splits (as it did recently) people who are on the minority blockchain have no way to know that they are transacting on a block chain the rest of the world does not think is the longest chain. At best, you could statistically infer you were in the minority eventually based on blocks being found too slowly. Bitcoin could adopt the method Ripple uses to solve this problem. Major mining pools could periodically broadcast a signed object stating the hash of the tip of the blockchain they are currently building on. You could then know if you were in the minority. What consensus is it you have been talking about anyway? Global consensus? If my transaction with someone only gets validated by about 20 nodes, how do the decision, say, propagates to the 1000 other validators globally? Especially if I try to send two transactions simultaneously to two different non-overlapping groups of validators? And the way you talked about Bitcoin is, to say the best, dubious, it's up to the miner to work after the block it received from another, or persist on his own chain, even if you somehow choose the wrong chain due to propagation time, it's unlikely you will make the same mistake when you receive a second, or a third block. Moreover, Ripple never have miners, and Bitcoin common users never have to worry, their transactions will eventually be included. |
|
|
|
Armory will be upgrading to BIP32, but at the moment it uses it's own homegrown version of "Type 2" deterministic wallets. After all, it was the first application to implement them, so I couldn't really have followed any standard But it's not homomorphic encryption. Homomorphic encryption is pretty neat and enables some pretty cool capabilities, in general, but I haven't thought about whether it could be useful for Bitcoin. I bet, if we upgraded the scripting environment, we could find something interesting, but I'm not sure how useful it would be. It would certainly be a fun discussion to have... For reference, Armory's wallet chain together like this: PrivKey[0] = Random(32)
Chaincode = Random(32)
PubKey[0] = Priv2Pub(PrivKey[0]) Then PrivKey[i+1] = (hash256(PubKey[i]) XOR chaincode) * PrivKey[i]
PubKey[i+1] = (hash256(PubKey[i]) XOR chaincode) * PubKey[i] Where the multiplication (*) is scalar-multiplication-mod-N in the first line, and it's elliptic-curve-point-mult-by-scalar on the second line. The magic of elliptic curve math is that if N is equal to the number of points on the elliptic curve, then you end up with matching private and public keychains on both sides. I had actually been meaning to document this precisely somewhere. I guess this was my excuse. As long as the chaincode remains secret, the unreused deterministic addresses will have the same kind of quantum computer resistance as the non-deterministic ones, right? |
|
|
|
Ok, waiting it is then. Thank you for the link . You can do something else, read DeathandTaxes and Gornick's posts. |
|
|
|
|
Show Posts
