Bitcoin Forum
December 05, 2016, 10:41:35 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 »  All
  Print  
Author Topic: GEM - as a potential stable value currency  (Read 5454 times)
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
October 19, 2011, 12:17:35 AM
 #41

If that forks the chain, then presumably the malicious humans are on one fork and the non-malicious are on the other fork. How you feel about that is really a function of who comes with you to your fork. If you are on the fork with 99% of people, you win. If you are on the 1% fork, you lose. The great mass of humans retain all the power. There is simply nothing EvilCo can do to "muscle" them around. EvilCo has to "market" them around. EvilCo can't even divide the system 50/50 and have both forks continue. That's an unstable state. It's an all or nothing game.

How is there nothing EvilCo can do to muscle them around if they can simply say "I don't accept your coins unless they're on my fork"? If, for example, the US government passed a law that said "all transactions to non-registered GEM accounts are illegal", all US businesses would switch to a fork that denies transactions to accounts that aren't registered with the US government or whatever. Anyone who wanted to use those sites would have to switch as well. It doesn't have to be an "evilco" per se.

Quote
Most of your logic about bitcoin not being able to scale is sound. However, it was never meant to scale in the way you say it can't. Peer to peer in bitcoin didn't mean that every client user must be a peer. Satoshi wrote from the beginning that competing transaction processing peers would evolve. Most people would just choose a peer and use bitcoin as a service.

*shrug* I think it's a flaw for a "decentralized" currency to become quite centralized.

Quote
If I could submit secure GEM transaction from my phone. I'd have no problem using the system without running a peer at all. As long as I know merchants (and others) have a vested self-interest in keeping EVERYONE honest. AND I know these folks won't be blindly trusting ANYONE to remain honest. Then the system is in safe hands.

No, the system is in the hands of the corporations which means, in turn, the hands of governments.

Quote
There should never be a 51% trust problem. That is a silly problem to try and invent. Trust is a human concept that can't be automated. System validity is easier though. If any single human peer working alone can't detect 100% of system wonkiness then you have design issues.

Detecting it is meaningless if you can't prevent it.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480934495
Hero Member
*
Offline Offline

Posts: 1480934495

View Profile Personal Message (Offline)

Ignore
1480934495
Reply with quote  #2

1480934495
Report to moderator
Red
Full Member
***
Offline Offline

Activity: 210


View Profile
October 19, 2011, 12:45:29 AM
 #42

A bit of your reasoning goes over my head, but I'd mine it. I like the idea of a *coin being tied to something of worth (in this case, power).

I do too. I really can't get excited about coins when speculation is the real focus. I really want to buy things!

After some thought I'm really starting to like your distributed trust system for validation so I'm definitely interested.

Thank you!

I'm going to work on some simplifications and then see how few bitcoin changes I really need to make to get this thing to work.
Red
Full Member
***
Offline Offline

Activity: 210


View Profile
October 19, 2011, 01:29:55 AM
 #43

I reordered this to put the important question at the top.

No, the system is in the hands of the corporations which means, in turn, the hands of governments.

I really want to be open minded about this. Can you give me a single example of when, as a GEM owner and client, I should trust the anonymous opinions of unknown individuals over a 100% consensus of merchants that I personally know, trust and do business with?

Keep in mind, very little of my money goes to anonymous individuals like Guido the killer pimp or Silk Road merchants. Most everything I buy comes from horrible evil corporations like Taco Bell, McDonald's, Amazon, Apple, Safeway and Exxon. I could be biased by the fact that these evil corporations seem to have business models based upon *not* cheating me. I'm not quite as confident in the business models of random anonymous coin users.


How is there nothing EvilCo can do to muscle them around if they can simply say "I don't accept your coins unless they're on my fork"? If, for example, the US government passed a law that said "all transactions to non-registered GEM accounts are illegal", all US businesses would switch to a fork that denies transactions to accounts that aren't registered with the US government or whatever. Anyone who wanted to use those sites would have to switch as well. It doesn't have to be an "evilco" per se.

If you are on the fork with 99% of people, you win. If you are on the 1% fork, you lose. The great mass of humans retain all the power.

If the US citizens and the rest of the world chose to follow what the US government decreed then they are the 99%. Should the US Government turn out to be the 1% or even 10%, their branch will die. Otherwise, we all have free coins on both branches and we all win. This is not GEM specific no coin chain can be forked and have both branches continue.

In bitcoin, if some anonymous party takes everyone down a malicious branch, you'd have to change code and issue new clients. In my model people just have to say "You are malicious! We are not going to trust you anymore. Bye bye!"


*shrug* I think it's a flaw for a "decentralized" currency to become quite centralized.

It is centralized accounting (there is only one valid block list). But with redundant copies and watchdogs. 1,000 redundant copies and watchdogs is probably sufficient. We don't need one billion copies and watchdogs.


Detecting it is meaningless if you can't prevent it.

See above.
Red
Full Member
***
Offline Offline

Activity: 210


View Profile
October 19, 2011, 01:44:37 AM
 #44

If you only accepted blocks co-signed by people you trust, like say the EFF and the Tor project, then even if all the nodes you are connected to are cancer nodes you wouldn't fall victim to double spending because you'll just reject any other block.

Exactly. Thank you! I should learn to be so concise.
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
October 19, 2011, 02:23:58 AM
 #45

I really want to be open minded about this. Can you give me a single example of when, as a GEM owner and client, I should trust the anonymous opinions of unknown individuals over a 100% consensus of merchants that I personally know, trust and do business with?

You personally know amazon.com or google.com? Don't compare your idea with mine, I am merely pointing out a problem. There is no 100% consensus with your system, there are merely trusted nodes that users are using to figure out if they are on the correct chain or not.

Quote
Keep in mind, very little of my money goes to anonymous individuals like Guido the killer pimp or Silk Road merchants. Most everything I buy comes from horrible evil corporations like Taco Bell, McDonald's, Amazon, Apple, Safeway and Exxon. I could be biased by the fact that these evil corporations seem to have business models based upon *not* cheating me. I'm not quite as confident in the business models of random anonymous coin users.

You are drawing a picture from something other than what I said. If the government forces these businesses to operate on your network in a certain way, they must do so or be operating illegally. Since most everyone will be using these trusted merchants as their source of trust, they will be forced to follow whatever path they take. If these trusted merchants refuse to use a fork that allows unregistered accounts, everyone will follow right behind. I'm just pointing out that the merchants can manipulate the system, whether or not it is of their own volition.

Quote
If you are on the fork with 99% of people, you win. If you are on the 1% fork, you lose. The great mass of humans retain all the power.

If the US citizens and the rest of the world chose to follow what the US government decreed then they are the 99%. Should the US Government turn out to be the 1% or even 10%, their branch will die. Otherwise, we all have free coins on both branches and we all win. This is not GEM specific no coin chain can be forked and have both branches continue.

I see no provisions for a dying branch. I see that many branches could easily exist with your system of trusted nodes. There is no proof-of-work supersession, so whoever wants to trust whichever fork will remain on that fork. There is nothing that will cause that fork to die off unless every single user of that fork chooses to stop using it.

And the US and the rest of the world do NOT have a choice if major merchants are forced to do something by the US government. Your coins have little to no value if they cannot be used anywhere.

Red
Full Member
***
Offline Offline

Activity: 210


View Profile
October 19, 2011, 03:46:24 AM
 #46

You personally know amazon.com or google.com? Don't compare your idea with mine, I am merely pointing out a problem. There is no 100% consensus with your system, there are merely trusted nodes that users are using to figure out if they are on the correct chain or not.

I'm really not trying to be obtuse. If I have been personally successful trading with amazon.com and apple.com, then yes I know and trust those merchant addresses. If every node I trust is on the same the same branch as me, that is 100% consensus for me.

There should generally be no invisible branches. That is true of bitcoin also. The only time an extended branch might exist that I don't know about, is in cases of network partitioning. With my version, everyone gets immediate notice of network partitioning. No one gets a surprise 8 hours later when 80 blocks magically get reorged from a previously hidden malicious chain.

You are drawing a picture from something other than what I said. If the government forces these businesses to operate on your network in a certain way, they must do so or be operating illegally. Since most everyone will be using these trusted merchants as their source of trust, they will be forced to follow whatever path they take. If these trusted merchants refuse to use a fork that allows unregistered accounts, everyone will follow right behind. I'm just pointing out that the merchants can manipulate the system, whether or not it is of their own volition.

The same is true of any chain. If a government says, "You can't use this client or this chain!" Then you either follow the law or break the law. No system can make something illegal into something legal. And no system makes it impossible for altered clients to fork the chain.

I see no provisions for a dying branch. I see that many branches could easily exist with your system of trusted nodes. There is no proof-of-work supersession, so whoever wants to trust whichever fork will remain on that fork. There is nothing that will cause that fork to die off unless every single user of that fork chooses to stop using it.

And the US and the rest of the world do NOT have a choice if major merchants are forced to do something by the US government. Your coins have little to no value if they cannot be used anywhere.

Branch dying is purely pragmatic. It does not need to be enforced by code.

Say there are 7,500,000 BTC in existence. Now say the US government says the American users (10%) *must use* the US branch, but the 90% of the world decides they want to stay on the original branch. So now the US branch has 7.5 million BTC and the world branch also has 7.5 million coins. That means 15 million independently spendable coins if the two forks persist. This is an untenable state.

If the US branch continued, the 90% of the folks on the world branch would just spend or cash out their 6.75 million *free* coins on the US branch. That would crash the US exchanges and bankrupt the merchants. They simply cannot continue. They would have abandon the 10% branch or abandon the coin system entirely.

Exchanges and merchants simply can't trade on multiple forks of the same chain. They have to pick one and only one. If you want to trade with them, you have to go with their choice.

It's really not a hard problem to solve. You maintain and trade on the branch you can see. So does everyone else. Normally there is only one branch everyone sees at the same time. If people disappear, then re-appear on a different branch, then there was an honest network partitioning. You settle it according to pre-agreed upon rules. If a new branch nobody has seen comes out of the blue, everyone simply ignores it.
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
October 19, 2011, 04:17:47 AM
 #47

The same is true of any chain. If a government says, "You can't use this client or this chain!" Then you either follow the law or break the law. No system can make something illegal into something legal. And no system makes it impossible for altered clients to fork the chain.

There is no need to alter the client for trusted nodes to decide which transactions to accept. In bitcoin, everyone is forced to accept transactions because they are secured by proof-of-work. Yours are secured by trusted nodes and some yet-undisclosed function--"The function just serves to get everyone to the same starting place. If it turns out the fittest block was created by someone nobody trusts, they can choose the next fittest. Anyone can pick any block, announce their intentions and see who follows them. If nobody does, they can switch to choice most popular among the circle they trust. If nobody trusts their circle, that is no fault but their own. GEM can't make people like you!"

Quote
Branch dying is purely pragmatic. It does not need to be enforced by code.

Doesn't seem like there's a whole lot keeping it together, either.

Quote
Exchanges and merchants simply can't trade on multiple forks of the same chain. They have to pick one and only one. If you want to trade with them, you have to go with their choice.

And if "they" get together and decide to change the protocol, you have no recourse. Except whining on a message board, of course.

Red
Full Member
***
Offline Offline

Activity: 210


View Profile
October 19, 2011, 05:59:56 AM
 #48

There is no need to alter the client for trusted nodes to decide which transactions to accept.

Trusted nodes like any node, accept all valid transactions. I'm assuming you questioning what happens if a trusted node attempts to deny that a valid transaction happened? That was actually slated for a section I indexed but haven't written yet. But any node can easily spot nodes which are denying transactions. When it becomes a pattern, they simply cease to trust those nodes and broadcast the evidence. They can easily spot double spends as well and broadcast that evidence. Neither of those acts can be kept secret. Bitcoin chooses not to act on either of these actions. If I implement GEM it will.
 

In bitcoin, everyone is forced to accept transactions because they are secured by proof-of-work.

In Bitcoin, everyone is forced to accept transactions because everyone else is accepting those transactions.
My process follows the same logic.
In bitcoin, a rogue client can run off accepting alternate block chains. No one else will care.
My process follows the same logic.


Yours are secured by trusted nodes and some yet-undisclosed function--

Certainly, but the function and process will be agreed upon in advance. Just like with Bitcoin.
The trusted parties will be non-anonymous and known to all. No one can be expected to trust anonymously.
Evidence of distrust will be published for all to see. Actions are not just denied. Known parties are publicly accused.


"The function just serves to get everyone to the same starting place. If it turns out the fittest block was created by someone nobody trusts, they can choose the next fittest..."

The major difference is, in Bitcoin, if any random anonymous individual shows up with a block chain that *NOBODY* has ever seen, but it has a greater proof-of-work. Then everyone *must* accept this as the new gospel truth even if it erases a month of valid confirmed transactions. That is just silly.


Quote
Branch dying is purely pragmatic. It does not need to be enforced by code.
Doesn't seem like there's a whole lot keeping it together, either.
Quote
Exchanges and merchants simply can't trade on multiple forks of the same chain. They have to pick one and only one. If you want to trade with them, you have to go with their choice.
And if "they" get together and decide to change the protocol, you have no recourse. Except whining on a message board, of course.

All of this holds for every block chain based crypto currency including EnCoin.

If the exchanges and the merchants all decide to do something you don't like. Well, sad for you.
Unless you happen to be among the 99% of the clients who decide not to follow them. In that case, they lose.

The 99% can take all their existing coins and trade amongst themselves on one fork.
And sell the 99% of coins they have on the other fork for goods. Never putting another dollar back into the exchange for merchants to use to cash out. Bye bye evil merchants. Bye bye evil exchanges. It's an OWS wet dream.

Trust me. The 1% has to follow the 99%, even if the 1% is all the merchants and all the exchanges.
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
October 19, 2011, 09:29:11 AM
 #49

Trusted nodes like any node, accept all valid transactions. I'm assuming you questioning what happens if a trusted node attempts to deny that a valid transaction happened? That was actually slated for a section I indexed but haven't written yet. But any node can easily spot nodes which are denying transactions. When it becomes a pattern, they simply cease to trust those nodes and broadcast the evidence.

You said yourself that, just like bitcoin, there will be few nodes eventually. "The people" have to place implicit trust in the trusted nodes because there is simply no way they would be able to keep up. It doesn't matter if they know about it or not, because by the time something like this might happen (via huge popularity and government intervention), they won't have a choice anymore as Bitcoin/GEM visa has control of the network.

Quote
In Bitcoin, everyone is forced to accept transactions because everyone else is accepting those transactions.
My process follows the same logic.

In Bitcoin, everyone is forced to accept transactions because the people are validating those transactions. It is unlikely that Bitcoin visa would ever be able to outclass the people in this respect. They could, however, start refusing blocks with undesirable transactions (or government-mandated illegal), forcing people to start blocking those undesirable transactions as well.

Quote
Evidence of distrust will be published for all to see. Actions are not just denied. Known parties are publicly accused.

Publicly accused, privately continuing to take it in the ass because the people have no choice if they want to use the value that they own.

Quote
The major difference is, in Bitcoin, if any random anonymous individual shows up with a block chain that *NOBODY* has ever seen, but it has a greater proof-of-work. Then everyone *must* accept this as the new gospel truth even if it erases a month of valid confirmed transactions. That is just silly.

So is designing a system that asks for the government/banks to step in and control the network.

Quote
All of this holds for every block chain based crypto currency including EnCoin.

Where was encoin block chain based?

Quote
If the exchanges and the merchants all decide to do something you don't like. Well, sad for you.
Unless you happen to be among the 99% of the clients who decide not to follow them. In that case, they lose.

You are giving control, intentionally, to GEM visa. The people don't have a choice. Want to spend your GEMcoins? Do what I say or your coins are worthless. In Encoin, everyone who wishes to monitor the network can do so, AND they have a voice in the network. The goliath has no hope of outclassing the many davids. And even if the goliath did have a hope of outclassing the davids, each client will see which network is true and refuse to do business with the other automatically. No message board rant required. No public outcry necessary. No government or corporation can influence it. It is controlled by the people. The way I think it should be. The governments and corporations need to comply with OUR network or gtfo. If you leave it wide open to be regulated, it will be.

Quote
The 99% can take all their existing coins and trade amongst themselves on one fork.

99%, lol. Ask 100 Americans who the US Secretary of the Treasury is. How many do you think will get it right? I'm quite sure it will be less than 99. So while you believe the 99% will be paying attention to the public outcry on a message board, the reality is it will be far less. If you think explaining bitcoin/GEM is difficult now, imagine explaining to them that they need to trust somebody else because the government/corporations is regulating bitcoin/GEM and it just isn't right! Then convince them to take your worthless money in trade that can't be used with big merchants or on the exchanges. I wonder how far that will get you.

Red
Full Member
***
Offline Offline

Activity: 210


View Profile
October 19, 2011, 05:37:21 PM
 #50

I'm pretty sure I've explained myself well enough for everyone else to understand. As such, I'm not going to address each non sequitur.

I will address two things though.

You said yourself that, just like bitcoin, there will be few nodes eventually. "The people" have to place implicit trust in the trusted nodes because there is simply no way they would be able to keep up. It doesn't matter if they know about it or not, because by the time something like this might happen (via huge popularity and government intervention), they won't have a choice anymore as Bitcoin/GEM visa has control of the network.

First, I didn't say there would be "few" nodes. I said whoever wants to be a node will be a node, most people won't.

If there are a billion users of GEM there will not be a billion always on nodes burning 200W continuously. That seems silly.

If a million merchants see the benefit in running their own nodes, woot! If a million others want to watchdog them to make sure there is no corruption, woot! Certainly in that group of 2 million individuals there is someone I trust. If there isn't, I'm not trading with anyone. I need to trust someone to send me my goods.


Second, I'm trying to make a quasi-anonymous, peer-to-peer, implementation of digital currency that can be treated like cash but with the ability to magically change hands over the internet. I'm not trying to overthrow the fucking government. Not even the Iraqi or Syrian governments.


Oh well, one more time.

It is unlikely that Bitcoin visa would ever be able to outclass the people in this respect. They could, however, start refusing blocks with undesirable transactions (or government-mandated illegal), forcing people to start blocking those undesirable transactions as well...

When Visa or the Government pries everyone's Bitcoin/GEM/EnCoin client out their cold dead hands, then everyone *must* change to new rules. Until then, the 99% of coin owners rule.

If Visa convinces 1% of coin owners run their modified client on a forked history, they give away 99 times as many free coins to the people they didn't convince. If they convince 99% of coin owners to run their modified client, they give away 1% free coins, but those attempting to continue the other fork have given away 99%. This holds for EnCoin as well. If Visa modifies the EnCoin client but forks from an existing Primary Block, they have the same power and risk the same liabilities.

In all cases (Bitcoin/GEM/EnCoin), it is probably easier and less risky for Visa/Government/EvilCo to just launch their own modified client on an alt-chain and tout their process improvements to the masses. But if Visa wants to go through all the sound and fury of forking the common history. And they successfully convince 99% of coin owners to adopt their improved client. Then I'll either cash out or go with them. Those are my only two choices. The people have spoken.
Red
Full Member
***
Offline Offline

Activity: 210


View Profile
October 19, 2011, 07:31:47 PM
 #51

By the way, I found a reference to the BitCoin forking I previously mentioned. It was the first example of one group changing rules and long recorded history behind another groups back. They guy with 184 billion bitcoins didn't even get to voice an opinion. Such is the will of the masses.

Value overflow

On August 15 2010, it was discovered that block 74638 contained a transaction that created over 184 billion bitcoins for two different addresses. This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed. A new version was published within a few hours of the discovery. The block chain had to be forked. Although many unpatched nodes continued to build on the "bad" block chain, the "good" block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
October 19, 2011, 09:37:19 PM
 #52

First, I didn't say there would be "few" nodes. I said whoever wants to be a node will be a node, most people won't.

No, you said this:

Quote
However, it was never meant to scale in the way you say it can't. [..] Most people would just choose a peer and use bitcoin as a service.

It wasn't meant to scale is not the same as "whoever wants to be a node will be a node." It's quite different, actually. And I think by agreeing that Bitcoin doesn't scale well, you are also agreeing that it becomes more and more cost-prohibitive as the network gets more and more use. Meaning that fewer and fewer peers will be capable of being trusted nodes. Meaning that fewer and fewer people will be running the network. Fewer points of attack, fewer points of control, but ok because this is how it's supposed to work?

Quote
If there are a billion users of GEM there will not be a billion always on nodes burning 200W continuously. That seems silly.

For somebody who bandies about the term non-sequitur, I would like to point out that this is in fact a http://en.wikipedia.org/wiki/Non_sequitur_(logic)

Nodes don't need to burn 200W to be a network peer in any of the designs we've talked about! So why would you say that? That seems silly.

Quote
If a million merchants see the benefit in running their own nodes, woot! If a million others want to watchdog them to make sure there is no corruption, woot! Certainly in that group of 2 million individuals there is someone I trust. If there isn't, I'm not trading with anyone. I need to trust someone to send me my goods.

You use the first person perspective in an attempt to elucidate your point far too frequently, and every time you do it, it makes your argument fall flat. This says nothing to address any of my concerns. Could the internet keep up with 2 million individuals being full peers, transferring 1 TBish a day at visa-like transaction levels, which would double google's estimate of the total current size of the internet every 2 or 3 days? And lol if a new merchant wanted to become a trusted peer.

Quote
Second, I'm trying to make a quasi-anonymous, peer-to-peer, implementation of digital currency that can be treated like cash but with the ability to magically change hands over the internet. I'm not trying to overthrow the fucking government. Not even the Iraqi or Syrian governments.

Wasn't I saying that we should worry about the government attempting to subvert or overthrow the digital currency, not the other way around? I believe this is another non sequitur; better yet, ignoratio elenchi. Can't really rage against the man with your digital cash if the man controls it too.

Quote
When Visa or the Government pries everyone's Bitcoin/GEM/EnCoin client out their cold dead hands, then everyone *must* change to new rules. Until then, the 99% of coin owners rule.

If Visa convinces 1% of coin owners run their modified client on a forked history, they give away 99 times as many free coins to the people they didn't convince. If they convince 99% of coin owners to run their modified client, they give away 1% free coins, but those attempting to continue the other fork have given away 99%. This holds for EnCoin as well. If Visa modifies the EnCoin client but forks from an existing Primary Block, they have the same power and risk the same liabilities.

How does this address refusing transactions that aren't with wallet addresses registered with the government? Oh, because of ignoratio elenchi. No modified client is required--just central, easily regulated nodes that everyone is forced to trust because no one else can do it. Since no one actually has a say in anything now except for the elite few, they could do something simple like agree to double the transaction fee. The cost of running GEMvisa is very expensive, after all. And if you don't like it, you can leave.

Red
Full Member
***
Offline Offline

Activity: 210


View Profile
October 20, 2011, 12:17:48 AM
 #53

I'm not going to worry now, about issues I might not have to worry about at all. If everyone decides GEM/EnCoin isn't interesting because it is not a Ponzi scheme, this thing will fall flat. Right now, I think there is about and 85% chance of failure in that regard.

I'm saying as best as I can tell Bitcoin is running 20,000 peers or so. There's not that many transactions, but still nobody is complaining about scalability issues. If I can get there, and transaction rates start to climb, woot! Then I'll worry about optimizing the broadcasts.


Nodes don't need to burn 200W to be a network peer in any of the designs we've talked about! So why would you say that? That seems silly.

I think one billion peers redundantly checking every transaction is silly. Any number of peers mining at any level to maintain trust is completely unnecessary.


Wasn't I saying that we should worry about the government attempting to subvert or overthrow the digital currency, not the other way around? I believe this is another non sequitur; better yet, ignoratio elenchi. Can't really rage against the man with your digital cash if the man controls it too.

Good word! Woot!

But I'm not raging against the man at all. I'm not worried about the government trying to subvert or overthrow my currency. I don't even care if people can avoid taxes, and I certainly don't want to stop the government from tracking down major criminal rings. I just don't want them needlessly profiling my internet cheeseburger deliveries. That is why I called it quasi-anonymous. If I'm a major government nuisance they have ways of tracking me down (as with bitcoin). But it is way too much bother to cross reference every single quasi-anonymous internet cheeseburger purchaser and send the result to the Obamacare administration to assist in re-education. 


How does this address refusing transactions that aren't with wallet addresses registered with the government?

Quite frankly I thought that concept was silly when the liberal guy mentioned it. I thought it hilarious when he called it a "feature" of bitcoin.

But I handle it exactly the way Bitcoin did in the example I posted. If some group deliberately changes the client to outlaw certain transactions others want, it causes a fork. If people want to stay on their original fork they can. Just the way the Bitcoin folks could have locked in the block with 184 Billion BTC had they wanted to stay on that chain. If it becomes necessary the original fork can modify their client to outlaw all Visa registered addresses to invert what was done to them. It's war. Everything is fair.

As far as I can tell the situation would be exactly the same in EnCoin. Different clients would begin to automatically trust different peers. The ones running Visa compliant peers would see the others as maliciously accepting invalid transactions, and drop their trust. The originals would see the Visa nodes as maliciously rejecting valid transactions, and drop their trust. How is this not a fork? You have the same original balances, but different balances based on more recent transactions.

I'm sure you will tell me differently.
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
October 20, 2011, 01:14:32 AM
 #54

I'm not going to worry now, about issues I might not have to worry about at all.

Why not? If you don't worry about them now, they are going to be a shitload harder and more costly to fix when the time comes. See Y2K bug.

Quote
I'm saying as best as I can tell Bitcoin is running 20,000 peers or so. There's not that many transactions, but still nobody is complaining about scalability issues. If I can get there, and transaction rates start to climb, woot! Then I'll worry about optimizing the broadcasts.

Actually, quite a few people have complained about the size of the block chain. Some even go as far to argue that it makes new users very put off that they have to wait hours before sending or receiving their first transaction. Obviously actual transaction data is very minimal at this point. But if you base your idea on bitcoin, every small transaction is going to make bigger transactions cost more data. Imagine having to send 50-100 inputs on a transaction for 20 GEMs.

Quote
I think one billion peers redundantly checking every transaction is silly. Any number of peers mining at any level to maintain trust is completely unnecessary.

As I have brought up, I'm going with a much more merchant-focused paradigm for the new encoin proposal. Whenever I get around to finishing it. I had a bit of a crisis on some of the data duplication that I believe I have mitigated. Merchants of higher repute will be required to verify more transactions, but they are being paid in the form of transaction refunds for their efforts. I don't believe I have everything solved, but I'm being a lot more technical with the next version, so hopefully it will spawn some more technical solutions.

Quote
But I'm not raging against the man at all. I'm not worried about the government trying to subvert or overthrow my currency. I don't even care if people can avoid taxes, and I certainly don't want to stop the government from tracking down major criminal rings. I just don't want them needlessly profiling my internet cheeseburger deliveries. That is why I called it quasi-anonymous. If I'm a major government nuisance they have ways of tracking me down (as with bitcoin). But it is way too much bother to cross reference every single quasi-anonymous internet cheeseburger purchaser and send the result to the Obamacare administration to assist in re-education. 

I don't disagree with you here, but I still strongly appreciate that my design will allow a much more varied group of people to partake in the workings of the network. I most definitely don't want it saddled in the hands of megacorps because they're the only ones who can afford to run it.

Quote
But I handle it exactly the way Bitcoin did in the example I posted. If some group deliberately changes the client to outlaw certain transactions others want, it causes a fork. If people want to stay on their original fork they can. Just the way the Bitcoin folks could have locked in the block with 184 Billion BTC had they wanted to stay on that chain. If it becomes necessary the original fork can modify their client to outlaw all Visa registered addresses to invert what was done to them. It's war. Everything is fair.

Again, no change in the client is required, only that the "trusted nodes" need not approve these transactions. It doesn't cause a fork when everyone relies on the same trusted nodes. If all of these trusted nodes are non-anonymous megacorps, they will have to do what the government tells them to do. New, (un)trusted nodes with the capability to support the network can't just pop up out of nowhere.

Quote
As far as I can tell the situation would be exactly the same in EnCoin. Different clients would begin to automatically trust different peers. The ones running Visa compliant peers would see the others as maliciously accepting invalid transactions, and drop their trust. The originals would see the Visa nodes as maliciously rejecting valid transactions, and drop their trust. How is this not a fork? You have the same original balances, but different balances based on more recent transactions.

Why would anyone voluntarily switch to a visa-compliant client? That is the only way it could work in Encoin. Transactions are either valid or not based on the account balance. There is no central group of trusted nodes that everyone relies on to tell them what transactions are compliant. If I can figure out a way to reliably determine a window of when transactions were sent (I think I've got something, but it will require discussion), peers who decide to not validate a valid transaction will lose reputation. Do it enough times and that peer won't be allowed to validate transactions anymore. So the government could mandate something all they want, but any peers following the mandate won't be allowed to do anything. Tongue

Red
Full Member
***
Offline Offline

Activity: 210


View Profile
October 20, 2011, 02:50:59 AM
 #55

The long and the short of it is that I don't have enough time or motivation to personally do an elaborate implementation like EnCoin. That is not to say that I don't think it should be done. EnCoin should be done and could be great. I wouldn't have spent so much energy on this if it didn't show promise.

The one thing that drives me about EnCoin/GEM is the stable currency. That is the part I'm fascinated by and the part so many here go "ho hum" over. I really think most normal people (meaning potential currency users) would take to stable coins much more intuitively than to variable value ones like Bitcoin.

I'm quite skeptical, in fact, that Bitcoin can reach mass adoption from where it is. I think it was much more likely to reach mass adoption 18 months ago. I think the boom and the bust will end up consolidating most Bitcoins into the hands of only a few individuals. By next December it risks looking, to new adopters, like a newCoin with a 10.5 million coin pre-generation. I think most potential users will reject the "they got half, we compete for the rest" argument.

However, until Bitcoin's failure becomes apparent, I doubt stable coins will get much traction on this site.

----

I'm in agreement with, and have great respect for, all the stuff you wrote that I'm not responding to. I'm only confused about a couple of things at the end.

Again, no change in the client is required, only that the "trusted nodes" need not approve these transactions. It doesn't cause a fork when everyone relies on the same trusted nodes. If all of these trusted nodes are non-anonymous megacorps, they will have to do what the government tells them to do. New, (un)trusted nodes with the capability to support the network can't just pop up out of nowhere.

I'm confused about which system you are referring to? If you mean GEM, I was considering "need not approve these transactions" as requiring a client change (at least on the merchant machines) to know which transactions not to include in blocks. Crap "client" is such a sucky word for me to use. In this case I mean the merchant's peer node, not the human client machines.

I was planning to require each peer to diff their own work with the proposed "fittest" next block. This is a slimmed down version of your PB union mechanism. My concept was that since each peer is receiving every transaction, diffs should be very close to exact matches. If the "fittest" block seems to be missing *lots* of known transactions (DOS), that block can be locally rejected and node that produced it marked "untrusted". If everyone follows the same procedure they will all arrive at a common "fittest" non-DOSed block. At that point they can announce their use of the non-DOS block. They will add to their announcement, blocks X,Y,Z rejected for (DOS, invalid transaction, double spend, etc). These serve a consensus flags to warn everyone else.

I guess the last sentence confuses me the most. I was presuming there would be lots of merchants and exchanges in different countries and legal jurisdictions. If all the US nodes started DOSing particular transactions, all others nodes would know about it immediately. The risk belongs to merchant/exchanges/transaction receivers.

Human clients (transaction spenders) potentially benefit from chain forks. During any chain forking dispute, they have control of twice as many coins. They can simply contact service providers on each fork, or run multiple instances, one trusting each fork.


Why would anyone voluntarily switch to a visa-compliant client? That is the only way it could work in Encoin. Transactions are either valid or not based on the account balance. There is no central group of trusted nodes that everyone relies on to tell them what transactions are compliant. If I can figure out a way to reliably determine a window of when transactions were sent (I think I've got something, but it will require discussion), peers who decide to not validate a valid transaction will lose reputation. Do it enough times and that peer won't be allowed to validate transactions anymore. So the government could mandate something all they want, but any peers following the mandate won't be allowed to do anything. Tongue

Again, my bad choosing the word "client".

I presumed that merchants would switch to visa-compliant nodes. These would keep only visa-compliant balances. Presumably, if you wanted to trade with these nodes you would have to agree to their balances and send them only visa-compliant transactions. Non-visa compliant nodes (merchants/clients) would quickly lose trust in the visa-compliant ones and vice versa.

However, the visa nodes are still functioning, self trusting and forked from the rest. That means *any* client sending visa compliant transactions can potentially double spend. Once on the visa fork. Once on the original fork. The renegade fork wouldn't last for very long.
Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
October 20, 2011, 04:11:55 AM
 #56

The long and the short of it is that I don't have enough time or motivation to personally do an elaborate implementation like EnCoin. That is not to say that I don't think it should be done. EnCoin should be done and could be great. I wouldn't have spent so much energy on this if it didn't show promise.

That is a totally fair argument. You just have to be aware that I will whine about the faults it inherits from bitocin. Cheesy

Quote
I'm confused about which system you are referring to? If you mean GEM, I was considering "need not approve these transactions" as requiring a client change (at least on the merchant machines) to know which transactions not to include in blocks. Crap "client" is such a sucky word for me to use. In this case I mean the merchant's peer node, not the human client machines.

I understand what you meant. I'm saying it is much easier for the government to force something on this group of trusted peers. I really don't think it is *that* unlikely if the system were to reach visa-like levels. I know I've been picking on the US government, but they are at the forefront of destroying civil liberties in the name of national security quite a bit lately. And if other countries do not follow suit, they are forked from the US so that US citizens alone can spend their money on both forks, resulting in chaos. So odds are they would follow suit. I don't know if it would work or how much it would accomplish, but it seems like you are leaving open the option to fork the network--which is the bigger issue in general.

Quote
I was planning to require each peer to diff their own work with the proposed "fittest" next block. This is a slimmed down version of your PB union mechanism. My concept was that since each peer is receiving every transaction, diffs should be very close to exact matches. If the "fittest" block seems to be missing *lots* of known transactions (DOS), that block can be locally rejected and node that produced it marked "untrusted". If everyone follows the same procedure they will all arrive at a common "fittest" non-DOSed block. At that point they can announce their use of the non-DOS block. They will add to their announcement, blocks X,Y,Z rejected for (DOS, invalid transaction, double spend, etc). These serve a consensus flags to warn everyone else.

But how is this all reconciled among everyone who uses the network? Clients that aren't peers can't know all that is going on. How does everyone know what the fittest block is unless they have all the blocks? How can a client be sure that blocks XYZ were rejected for a valid reason unless you give them the full, signed copy? And even then they can't be sure unless they have the whole block chain as well.

Quote
Human clients (transaction spenders) potentially benefit from chain forks. During any chain forking dispute, they have control of twice as many coins. They can simply contact service providers on each fork, or run multiple instances, one trusting each fork.

This is a terrible, terrible thing though. Surely you can see that.

Quote
However, the visa nodes are still functioning, self trusting and forked from the rest. That means *any* client sending visa compliant transactions can potentially double spend. Once on the visa fork. Once on the original fork. The renegade fork wouldn't last for very long.

Which one is the renegade fork? Tongue

Etlase, scalability is a non-issue. GEM is not analogous to VISA, but to the dollar. Something like Bitpay would be analogous to VISA. If we ever reach high transaction volumes then only businesses will be trading on the network itself while consumers move to third-party payment processors. Also, since in GEM any block that gets validated with 90-100% consensus is basically a checkpoint in the blockchain that can never be rewritten, it would be possible even for full nodes to just maintain a database with the current balances instead of a detailed log with every historical transaction.

The network that runs GEM or Bitcoin or Encoin is very analogous to visa. Except businesses don't have to record a terabyte per day of data and transfer a gigabyte per second of data to use visa.
To maintain a database of current balances, a system needs to be in place to ensure that everybody agrees on those balances. The balances need to be the block chain, not the bloated block chain as it is. Unless you get away from that, you're stuck with it.

TiagoTiago
Hero Member
*****
Offline Offline

Activity: 616


Firstbits.com/1fg4i                :Ƀ


View Profile
October 20, 2011, 04:36:46 AM
 #57

...

... I could be biased by the fact that these evil corporations seem to have business models based upon *not* cheating me...

...
If the big corps were successfully cheating you, how would you know? If they found ways to profit more by cheating you and get away with it, it would not surprise me at all if they did so, in fact i would expect them to do so.


</off-topic>

(I dont always get new reply notifications, pls send a pm when you think it has happened)

Wanna gimme some BTC for any or no reason? 1FmvtS66LFh6ycrXDwKRQTexGJw4UWiqDX Smiley

The more you believe in Bitcoin, and the more you show you do to other people, the faster the real value will soar!

Do you like mmmBananas?!
Red
Full Member
***
Offline Offline

Activity: 210


View Profile
October 20, 2011, 07:33:48 AM
 #58

But how is this all reconciled among everyone who uses the network? Clients that aren't peers can't know all that is going on. How does everyone know what the fittest block is unless they have all the blocks? How can a client be sure that blocks XYZ were rejected for a valid reason unless you give them the full, signed copy? And even then they can't be sure unless they have the whole block chain as well.

I really need to draw something. I'll probably screw this up explaining in text. I'm going to explain the issue for anyone else who might stumble in. I know you already understand it.

So the issue is, if we have (N) peers all validating every broadcasted transaction. And every ten minutes we want all valid transactions batched up into an immutable block. And we want every node to agree on the same block of transactions, so we all share the same history. How do we reach consensus?

In Bitcoin, every node works redundantly, and POW randomness blesses one node's block. This blessing is based on time. Everyone agrees to use the first block they hear about.

GEM's doesn't have this timing randomness as a starting point. Everyone's 10 minutes happens at the same time. So to replace the above process randomness, I'm suggesting a "fitness" function.

---

Say we have lettered nodes and numbered blocks that increase with time. And say (via magic) that Nodes A, B, C & D are all on the same block chain.

1) Contains announcement transactions from A, B, C, D
2) A, B, C, D
3) A, B, C, D
4) A, B, C, D  (this is the announcement pattern everyone expects to see if the network is not partitioned.)

----

So, the first thing that happens is, nodes A, B, C & D broadcast announcement(4) transactions to tell everyone they are building upon block (4) in the chain.
Every node receives these announcements, validates the transactions and places them in the next block they are building.
Every node also receive normal transactions, validates them and keep adding them to their blocks.
[time passes, 10 minute timer elapses]

----

Now we have four independent potential next blocks. (5a, 5b, 5c, 5d)
We need a bit of randomness that can pick one so it can be broadcast to the others.
Before we can pick one, we need to know the set we are picking from.
Fortunately block (4) contains announcements from all the nodes who were around 20 minutes ago.
Our currently building block (5) contains announcements from all the nodes around in the past 10 minutes.
Let's assume that if a node was validating transactions 20 minutes ago and they are in our building block, then they are a candidate to choose from for block (5).

So as a trivial example fitness function, let's use the hamming distance between block (4)'s hash, and the hashes of announcement transactions (A-D) inside of block (4). All nodes have that information already. (Hamming distance means XOR two hashes and count the ones digits in the result. So the result will be a number between 0 and 256 for Sha256 hashes.)

Say we get the following results:
sha(4) hamming sha(4A) = 128
sha(4) hamming sha(4B) = 125
sha(4) hamming sha(4C) = 127
sha(4) hamming sha(4D) = 130

That means the nodes in fitness order are: B, C, A, D

-- Node A --

Since Node (B) is the "fittest" (B) broadcasts his transaction block (5b) first.
Every node receives block (5b), revalidates it, diffs it with their personal block (5n) looking for transaction DOS and double spends.
If block (5b) fails,
    the node removes node B's trust.
    And broadcasts a warning transaction, "node(A) failed node(B, 5b) for DOS"
    Then asks the next fittest node (C) for their transaction block (5c)
If block (5c) passes, and the node broadcasts an announcement(5c) transaction.

----

Since this all happens in parallel, node (A) receives announcements as the other nodes make decisions.
If the other nodes agree with (A) about (B's) transaction DOS, then node (A) will receive:
    A's Announce(5c)
    B's Announce(5b)
    C's Announce(5c)
    D's Announce(5c)
    "node(A) failed node(B, 5b) for DOS"
    "node(C) failed node(B, 5b) for DOS"
    "node(D) failed node(B, 5b) for DOS"

If the other nodes disagree, then node (A) will receive:
    A's Announce(5c)
    "node(A) failed node(B, 5b) for DOS"
    B's Announce(5b)
    C's Announce(5b)
    D's Announce(5b)

If A receives the latter it can change its mind, switch to 5b and re-announce to preserve consensus.

----

Anyway I was right. It needs a diagram. But that's the gist of the process.


This is a terrible, terrible thing though. Surely you can see that.

Yes, its almost a nuclear option. That's why I'm so sure nobody will let it happen. And why I want everyone to have advance warning is somebody even tries.

I asked in another thread what the exchanges do if a block chain fork attempts to erase/revert a "confirmed" transaction block they had already payed out on. The reply was "they shut everything down until everyone figures out what the fuck is happening!" I'm not sure it was an authoritative answer, but it made perfect sense.

That was basically what happened when they forked to bitcoin chain to remove the extra 184 billion coin. Absolutely everything stopped while everyone emailed everybody they knew to stop the old clients and start new ones. Fortunately, few were doing business or trading at that point. But if they were, those trading on the original client would have gotten a hell of a shock when 53 blocks of their transactions magically disappeared!

Etlase2
Hero Member
*****
Offline Offline

Activity: 798


View Profile
October 20, 2011, 01:33:20 PM
 #59

Anyway I was right. It needs a diagram. But that's the gist of the process.

Have you been reading my mind? Eerily similar to what I have come up with, although I am trying to do it on a 10 second timer instead of a 10 minute one. And only 1 node is pre-determined to create the next transaction block, but there is a continuing list of backups if the one before doesn't show in time. I came up with the 1 node only thing to significantly reduce the amount of data required to reach consensus. 1 node in 1 "trustnet" creates the block, is signed by >50% of their trustnet, is signed again by the first node with a hash of the signatures, then is passed on to the other trustnets, all but one who sign the signed block in a similar manner. The next one in line creates a new transaction block that uses the hash of the previously agreed upon one as a starting point. Although I believe it will be proposed that each new block will use the 2nd most recent block to help reduce the problem of internet delays.

Using hamming distance is a bad idea since you will get collisions like mad, but I'm guessing you are aware of that. Why not just use the lowest/highest hash value?

I guess my major problem comes back to is who is allowed to make transaction blocks? When do you know that peers agree that Amazon is trusted enough to make blocks? Do you place some kind of maximum number of trusted peers? How do you plan on preventing/mitigating denial of service attacks on these trusted peers? What happens if some of these peers decide they don't like GEM anymore and stop running a trusted node? Are you relying on existing trusted nodes to bring in new trusted nodes? If so, what if exchange A trusts X,Y,Z but exchange B trusts M,N,O? Exchanges would become the "center of the universe" as you've said, but now they actually have the power to control the network too in more than just theory.

We're getting really close to the same system, but I'm trying to have mine fully automated while you're relying on trust. And you've still got the problem of a bloated block chain, 1 hour+ wait times for confirmations, and now central points of attack/maliciousness. And really, if two chains exist, how does an end-user know how to trust one over another? I know you claim the 99% and all, but in reality this is not going to be obvious to your everyday user. There is no easy 99%.

Quote
Yes, its almost a nuclear option. That's why I'm so sure nobody will let it happen. And why I want everyone to have advance warning is somebody even tries.

Who's "nobody"? The only definition I can see is a trusted group of peers who may or may not have the best interests of the network at heart. And how are you so sure? Your vote of confidence is not going to convince many people that it will work the way you say it will only because you say it will. Bitcoin relies on hashing power, GEM relies on trust placed in a small number of peers, Solidcoin2 relies on trust placed in a smaller number of peers, Encoin relies on trust of a large number of peers and rewards those peers in the form of ca$$$h money for doing so. The more peers there are, the harder it is to get them to agree to do something shady, and the harder it is to plan coordinated attacks to bring down the network. And if EVERY client only needs a relatively tiny amount of data (consensus block) to be sure that someone is trying to fuck with the network and proof can be easily provided so that they can automatically switch to the honest fork, there is little room for any kind of coordinated attack.

Quote
I asked in another thread what the exchanges do if a block chain fork attempts to erase/revert a "confirmed" transaction block they had already payed out on. The reply was "they shut everything down until everyone figures out what the fuck is happening!" I'm not sure it was an authoritative answer, but it made perfect sense.

You are taking this far too much to heart if you are designing a rock solid cryptocurrency. Bitcoin is not that cryptocurrency, and by using its fault to mollify fears about your cryptocurrency, you're in a bad way.

Quote
That was basically what happened when they forked to bitcoin chain to remove the extra 184 billion coin. Absolutely everything stopped while everyone emailed everybody they knew to stop the old clients and start new ones. Fortunately, few were doing business or trading at that point. But if they were, those trading on the original client would have gotten a hell of a shock when 53 blocks of their transactions magically disappeared!

Yes, fortunately the problem was handled early enough on. Would be a bit of a problem if it were the world's alternate currency though.

Red
Full Member
***
Offline Offline

Activity: 210


View Profile
October 20, 2011, 08:53:09 PM
 #60

Using hamming distance is a bad idea since you will get collisions like mad, but I'm guessing you are aware of that. Why not just use the lowest/highest hash value?

Hamming was the first thing that popped into my head. Any function that isn't trivial for individual nodes to manipulate is equivalent.

Specifically though,  I wanted a two stage function. Each node's announcement transaction is sent prior to building the block it ends up in. So, the hash of the block becomes dependent on the announcements. Therefore, no node can "optimize" his announcement transaction in order to have the fittest hash. The variable he must optimize against cannot yet be known. (I'm not completely sure I have the specified the example correctly. But that was the concept.)


I guess my major problem comes back to is who is allowed to make transaction blocks? When do you know that peers agree that Amazon is trusted enough to make blocks? ... Are you relying on existing trusted nodes to bring in new trusted nodes?

We're getting really close to the same system, but I'm trying to have mine fully automated while you're relying on trust.

I think we are getting really close too. Especially because I don't think I'm relying on "trust" as much as you think I'm relying on trust.

Nobody is really "trusted" in the "blessed" sense of the word. Anyone can broadcast announcement transactions for a given block. Even if they choose to be anonymous. The process is equivalent to sending 1 BTC to yourself. The question becomes, "Why should anyone else CARE what block you think we all should build upon?"

That is where non-anonymity comes it. Nodes can become known by choice. This does not automatically make their announcements any more trusted than anonymous announcements. It does however make these individuals identifiable to those who ALREADY trust/distrust them through business or personal relationships.

A peer can say, "Hi I'm Red! I'm a GEM speculator, as such I have a personal interest in making sure the system is transactionally secure." Really though, they probably just publish a standard X.509 certificate from a well known certificate authority. The same thing sites do for https and ssl. Non-anonymity is the basic defense to the Sybil attack. Certificates cost money and require jumping through hoops. (And best of all, I don't have to implement that process!) If some known individual acts maliciously his certificate gets a death penalty. If he is a merchant, all his customers see the blacklisting.


If so, what if exchange A trusts X,Y,Z but exchange B trusts M,N,O? Exchanges would become the "center of the universe" as you've said, but now they actually have the power to control the network too in more than just theory.

There is some sense of this and it should be analyzed for logic flaws and potential attacks. But our goals are the same, we both want to make it obvious in advance that forking attacks cannot succeed.

The method I've discussed is not so "pure" as yours. But I think I can prove that pragmatically, it has the same effect.

Silly Example Bitcoin Tangent:
Say the NSA decides to mount a secret chain forking attack on bitcoin. So at the next difficulty change, they secretly begin building their own secret fork containing nothing but empty transaction blocks. Say they borrow one of those new GPU based super computing clusters the national science foundation sponsors. So at the end of two weeks, they have a 2050 block empty chain, to inject in and override bitcoins existing 2016 block transaction fork.

So what happens? Momentary chaos. All the exchanges stop trading. Everyone jumps on IRC and decides the new empty chain is a scam. They "lock in" the most recent block from the 2016 block chain, (issue new clients if they have to) and everyone just goes on ignoring the NSA chain. Or everyone decides, No damage done. No double spends. We'll just re-run all the transactions on top of the NSA chain and start trading again once we are caught back up.

There really isn't a fundamental 51% issue. There is a momentary chaos problem. But those problems will get fixed, and they'll get fixed by those who care enough to show up in IRC (or wherever) and fix them. Everyone else ends up having to agree.


GEM Analogy Tangent:
Say the NSA tries the same trick. One fork has zero announcements from known parties. The other fork had a consistent chain of announcements. The basic rule says, "NEVER blindly trust a fork that everybody you know has vanished from." So every client just ignores the NSA fork, and there is zero chaos.

----

So back to the exchanges for a moment. Keep in mind that exchanges DON'T trust each other. But they do have to monitor each other. Every exchange needs to be notified within seconds if the other exchanges disagree with their opinion of history. It doesn't initially matter who is right and who is wrong. If there is a fork, they MUST take human action.

Quote
Yes, its almost a nuclear option. That's why I'm so sure nobody will let it happen. And why I want everyone to have advance warning is somebody even tries.
Who's "nobody"?

Most immediately it means every exchange. But this trickles down to everyone else.

If there are 10 exchanges trading on the same chain, if one exchange sees the nine other announce on a different block, he has to follow or stop trading. That is a human decision. Maybe his node is faulty and made the wrong decision. Maybe all the others are malicious. Either way, it is fool hardy for him to pretend nothing wonky is happening.

If 5 exchange announce on one block and 5 announce on another block, everyone has to stop trading until they can figure out what is happening. (Is this a bug? An NSA attack?) But the point is, they get the notice within seconds. The exchanges don't blindly follow each other out of trust. They monitor each other out of DISTRUST and based on a self-preservation requirement to do so.

To avoid making needless human decisions every 10 minutes, GEM will have some simple easy to enforce consensus rules:
Say:
1) Everyone who announced in the previous block, and who announced at the start of this block, is in the starting set.
2) Anyone who had been blacklisted is out.
3) We use this fitness function.

This should serve in every case where nobody is deliberately trying to subvert the consensus. But in cases where somebody is, the exchanges will immediately negotiate their differences, or there will be a nuclear exchange war.


However, if there is war, everyone gets advanced notice when half the exchanges drop off a block. When I say "advanced notice" I mean that everybody gets notified there is a discrepancy within 10 minutes. But nobody considers any transaction absolutely confirmed for 30 minutes.

So if any merchant sees known exchanges announcing on multiple blocks, they can simply wait till they see exchange consensus before announcing about their chosen block. If no consensus appears within seconds or minutes. Human merchants need to know something wonky is happening. Merchants at a minimum need to stop considering their transactions as "confirmed" until things settle down.

They don't have to see 100% consensus in exchanges. Merchants just need to confirm their exchange isn't going rogue. And they need to see that their trading partners and competitors are all announcing onto the same block. It's the 99% strength in numbers thing. Until they are sure, they simply avoid announcing their commitment to any given block.

Clients, on the other hand, may not care about exchanges at all. They simply want to know if they can buy something from Apple,  McDonald's or whoever. If they STOP seeing announcements from the folks they have traded with in the past (easy to implement). Or don't see an announcement from a new merchant they want to trade with (also easy to implement). Then they should wait until the system settles. They simply periodically ping the merchants they use, asking each for their latest block announcement. Once they see consensus among their merchants, everything should be good to go. Before that point, client's can still attempt to send transactions. But they shouldn't expect merchants to deliver the goods until consensus is re-established and GEM transactions become irreversibly confirmed.


Pages: « 1 2 [3] 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!