Topic: GEM - as a potential stable value currency (Read 6248 times)

It very well could be. Most hashes aren't designed to be hard to calculate. They are designed to be hard to reverse. If you can meet that goal and be efficient to calculate, that is a feature for most hashing tasks.

I googled but I couldn't find reference to the scrypt algorithm. Is it a serialized version of unix crypt or something? Hash creation is really a black art. That is why the government holds competitions to create and attack them. The biggest potential problem with a new hash is not that somebody mike make it faster to calculate. But that someone might find a trivial way to reverse it or to mathematically reduce its complexity. This is how most hashes like MD4 die.

Again, I have zero information on scrypt or artforz, so I'm not making any specific claims.

It is still in the planning stages. I'm learning some of the bitcoin code details.

There really is no reason that 10 minutes needs to be enforced. I just wanted to not needlessly vary from the bitcoin specification in the initial discussion. The same constraints apply that apply in bitcoin. Once a block is generated, it needs to be replicated to everyone who cares. Other chains have shown that can be done faster than every 10 minutes but I'm not sure what would be optimal.

I have to admit I don't know too much about Script except it was designed to be hard to implement on a GPU. When it comes to depending on the security of hashes, you really want to go with the most tested/abused algorithms. You also want to avoid depending on old algorithms staying secure for too long. SHA-256 is one of the SHA-2 hash series. There is already an open competition for more secure SHA-3 hashes.

However, the proof-of-work is really not being done for extreme security. It is mostly just a random number generator burning electricity over time. What GEM would need is an algorithm that isn't going to be easily broken, but also one that is not too easily optimized. If someone could run the algorithm much cheaper, they could theoretically exceed Koomey's law. I'm not sure the best, but going with the Bitcoin implementation assures GEM wouldn't accidentally do worse than bitcoin.

Yes, you are correct. It would be trivial to scale generation so that different people could choose to generate 1, 10, or 100 GEMs at a time based upon the hashing power they had at hand.

And yes, any initial mapping to dollars would be purely psychological. Any chosen relationship would be mathematically equivalent.

Woot! Thanks, that clears up lots for me. Whenever I saw it the term "operator" popped into my head!

OP = Original Post (post #1 in a thread) / Original Poster (in this thread, You), depending on the context.

I will. I'm not sure exactly when though. It will be the most important next step though.
I specifically want to figure out how little of bitcoin I really need to change. Once I have the coherently written down, I'll post it so people can brainstorm about ways to attack it.

I have to admit I don't know what "in the OP" means? I've see OP several times. What is it an abbreviation for?

Red, I hate to ask this, but can you post a tl;dr summary in the OP?  I find all this very interesting but I admit much of it goes over my head, and it's hard for me to follow what I'm not getting.

I guess a compare/contrast from bitcoin/GEM would be good, as most people here already understand (to a degree) Bitcoin, and showing how GEM differs in each regard would be helpful (to me at least).

I was asking how people new to the network would know who to trust.


Fixable by a central authority. It's a copout for something that's supposed to be decentralized.


Yeah I'm really not that worried about it, but I would like to see details on how this blacklisting is actually accomplished. I realize this stuff takes a shitload of thought though, I spent an immense amount of time on it myself, but I did solve it with the second proposal, except it was incredibly data heavy even with 1/5th-1/10th the transaction sizes of bitcoin.

I guess my main concern returns to scaling up and trusting down to a smaller number of peers. It's another one of those "it can work, until it doesn't" type deals.


The only way to have a node accept an invalid primary block is if everyone (including end clients) is in on it together and forking. Essentially, the solution I've come up with if there is a >50% attack on the reputation is to stop approving transactions. No one can get away with approving bad transactions on either of our designs, but they can get away with DoSing/splitting or infiltrating the trust/reputation then quitting.

So I guess now is the time to bring up what happens when the network is intentionally or unintentionally split? I really don't even think this is possible, but it has been brought up to me before as a possibility if governments use ISPs as a way to target the network. Bitcoin will eventually resolve this by the longest hash winning. Certainly isn't a clean way of doing it though as confirmed transactions will unconfirm and so on. But the network will carry on with a resolved chain eventually. I'll go into more detail on how I hope to solve this in my proposal without any confirmed transactions ever unconfirming.


It's a possibility, but they can't do it without the clients knowingly accepting it. In the mean time, these merchants will be forced on to their own fork that no one will use. The point is, if the eventuality of all this is going to boil down to a few supernodes, it is so much easier to accomplish.


but you said this -- "Merchants at a minimum need to stop considering their transactions as "confirmed" until things settle down."

That sounds like they have confirmations that could be reversed to me.


I'm hoping that an attack on the consensus would never be possible. At least once the network was widespread in use. What I worry about is splitting the network permanently. I don't think this could ever be done, but I don't know for sure. At least it brings the attack on encoin into the realm of entirely theoretical rather than just needing a certain amount of hashes. But I'll detail all of this stuff in the new proposal when I finish it. I really need to stop posting here and work on that instead when I have time.

Not that I know of, except of course the potential to delay transaction acceptance another block.

There is quite a bit of flexibility in some of the transaction formats owing the the script part. I have no idea yet if there is enough room to manipulate the hashes there. But in any case, it is useful to reduce the flexibility and timeframe any node has for hash manipulations. Since we have lots of folks with a strong background in hash manipulation!


I don't understand the question. If you were anonymous before, you still are. If you were known before you still are. If you don't have a single BTC you can't announce your prescience. But once people know who you are, anyone can ask you what block you are on.

Is there some benefit to getting the winning hash other than being the block that gets accepted? The hash is somehow based on the transaction log, right? So have the transactions in an alphanumeric order. Thus the only way to change the hash is to add or remove transactions. Difficult to do if everyone's watching. Very difficult to know if your 256-bit hash is going to be the best or not vs an 8-bit hash.


What about people who don't have any business with the network yet? Or haven't had any for some time?


I have a little more faith in the intelligence of the NSA should they attempt to attack the bitcoin network. If the primary objective is to take down the network, all they need to do is attack the chain directly. I believe we've already discussed this. Transactions will slow or fail to get confirmed at all, recent history will be constantly re-written, and miners will make a lot less money, furthering the ease of the attack. They will not attempt to re-write long past history.


How is causing the complete cessation of the network "no damage done"? Do you think if visa went down for a day that there would be "no damage done"? And if the developers are going to lock in a block, they are absolutely going to have to issue a new client that EVERYONE will need. And if they build on the NSA chain, all the miners who mined in those 2016 blocks just lost all of their money. That is a lot more than no damage done. And fuck relying on the developers to fix these problems. The network should be able to handle it itself. Relying on the developers to fix every major problem is such a pussy way out. And oh, hey look, it can just be done again for something as useless as a block checkpoint.


There absolutely, unequivocally is.


I'm aware we both have a solution to the 51% attack because hash power doesn't secure the network. That doesn't mean there aren't other issues that need to be ROCK SOLIDLY addressed.


LAME.


LAME. What does this exchange tell its peers? "Something is going on right now lol, so anything you do here might not be reflected on the rest of the network. GL"


Who says everyone has to stop trading? It's decentralized. If 5 are malicious, do you think they are going to tell their peers that they're malicious?


I think you have a bit more fleshing out to do. Nuclear exchange war, while sounding cool, is not a solution to a 51% attack, it's another problem.


A confirmation should be absolute.


And do what, sit with their thumbs up their asses in the mean time? They are, apparently, waiting on somebody more trusted than them to figure out what is going on when that more trusted person may well be the cause of the problem.


Sounds far too complicated to me. What if the client wants to use a merchant they've never used before? Or a new client like I asked before? I don't see any manner for fork resolution other than "human intervention". You're gonna have to come up with something better than that if you want to convince people that this is a better option than a bunch of terahashes.

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 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.



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.


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.

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%.


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.


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.


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.

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.



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!

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.

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


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.

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.


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.



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.

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.


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.


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.


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.


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.


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.

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.



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.



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. 



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.

No, you said this:


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?


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.


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.


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.


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.

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.

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.


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.


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.