GEM - as a potential stable value currency

[Etlase2]

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

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.

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.

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

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.

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.

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.

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 really isn't a fundamental 51% issue.

There absolutely, unequivocally is.

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.

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.

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.

LAME.

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.

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"

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.

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?

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.

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.

Merchants at a minimum need to stop considering their transactions as "confirmed" until things settle down.

A confirmation should be absolute.

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.

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.

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.

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.

[1715018588]

1715018588

[1715018588]

1715018588

[1715018588]

1715018588

[Red]

Is there some benefit to getting the winning hash other than being the block that gets accepted?

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!

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.

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

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.

Silly Example Bitcoin Tangent:

The point wasn't that it doesn't do damage it was that it is fixable despite the algorithm. And the opportunity never should have been allowed in the first place. As far as I can tell LiteCoin has a rolling block lock every 2016 blocks. For them that is every 3.5 days. In GEM I think it should be no more then 30 minutes.

LAME.

I know you want there to be no possible way to mount any attack. Make that so. I'm working within the constraints of the tool kit given to me.

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"

Yes. That appears to be the case at the moment. It doesn't stop intra-exchange trading. But it does stop the exchanges from taking in new BTC or paying out BTC. The rule seems to be, "I'm not trusting transactions on this fork. If everyone else isn't trusting transactions on this fork."

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?

As you remarked at the beginning there is very little a malicious node can do in this sense. It can either delay a valid transactions, or accept invalid transactions. In either case the node would quickly be blacklisted by the non-malicious nodes.

However, if your computer tells you that a significant number of others are building on a block chain with obviously invalid transactions. It is your business decision to decide what action you should take. You are certainly not going to move to a branch with obviously invalid transactions. But if 99% of the other do, your node is probably buggy. Better to know this now than later.

Nuclear exchange war, while sounding cool, is not a solution to a 51% attack, it's another problem.

If too many EnCoin nodes start accepting invalid Primary Blocks, you will have the same human intervention issue. Someone is undermining confidence and you need to figure out who to trust. Perhaps the government mandated EnCoin merchant node changes and didn't tell anyone. Maybe all US merchants begin DOSing unregistered accounts and only accepting their own PBs. Maybe there is a message on every US merchant's website that says download the compliant client if you want to continue spending your EnCoins.

Like I said. It was be a nuclear war. The system could not continue with both forks as is.

A confirmation should be absolute.

That's why I call it a confirmation.

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.

If this doesn't take seconds, there is a war on. It is equivalent to the period when you are waiting for the chosen peer to finish creating the next Primary Block. In that period, nobody can be sure what the new balances will be.

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.

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?

Outside of the above few second period while consensus stabilizes. The PB building period. There will be one and only one latest block. Every merchant will have announcements in it. If a new client has the address of a merchant they've never used before, they client will tell them if there is an announcement in that block. If it's not already there, the merchant is non-anonymous the client can ping for confirmation. If the merchant is deliberately anonymous and non-announcing, then there is nothing to confirm.

The only time a client would ever see anything interesting at all is in the case where, Target and Walmart are trading on one fork, but Sears and Home Depot are trading on another for an extended period (30 minutes). In that case something really wonky is going on so you get a message.

What is EnCoin going to tell people when some group is deliberately attacking the consensus?

[Etlase2]

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.

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

The point wasn't that it doesn't do damage it was that it is fixable despite the algorithm.

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

As you remarked at the beginning there is very little a malicious node can do in this sense. It can either delay a valid transactions, or accept invalid transactions. In either case the node would quickly be blacklisted by the non-malicious nodes.

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.

If too many EnCoin nodes start accepting invalid Primary Blocks,

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.

Maybe all US merchants begin DOSing unregistered accounts and only accepting their own PBs.

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.

That's why I call it a confirmation.

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.

What is EnCoin going to tell people when some group is deliberately attacking the consensus?

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.

[johnj]

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

[Red]

Red, I hate to ask this, but can you post a tl;dr summary in the OP? 

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?

[johnj]

Red, I hate to ask this, but can you post a tl;dr summary in the OP?  

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?

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

[Red]

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

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

[Red]

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.

[Red]

I believe this scenario is more possible with SHA-256 as ASICs could increase the efficiency by a huge margin over the current high end GPUs. Scrypt, on the other hand, was specifically designed to prevent brute-force attack optimization. I believe ArtForz said that one would be hard pressed to make ASICs more cost effective than CPUs.

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.