DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?)

[monsterer]

Did you announce the details of these long range attacks you perceived, I don't recall.  

There was the long con attack (building trust over time), which isn't technically a long range attack. The long range attack was whereby a node syncing with the network had no objective measure of which chain/channel was legitimate.

[TPTB_need_war]

Are you refering to this http://blog.emunie.com/?p=53 ?
Where do you see the similarities to POS ?

No, it was on these forums - there was a consensus primer, but it lacked critical information. What I could discern at the time was that it was vulnerable to long range attacks (like POS), and there were edges cases around when the validating nodes changed. Both of these problems challenge the idea of an append only ledger, unless you add trusted authorities.

Did you announce the details of these long range attacks you perceived, I don't recall.  

Also the voting nodes change at specific intervals, theres an edge case where the majority of the selected voting nodes are offline, or unavailable and dont vote.  That then results in a failed vote and the ledger state is in "limbo" until the next set of selected voting nodes then vote.  As they are voting on the state of the ledger, their vote encapsulates the data as a matter of course from the missing vote.  Not really a critical issue.

I figured voting would be the way you would try to do it.

Which vote occurred first? How do you prove it with a mathematical data structure?

Can't be done without a LCR or centralization.

I am not against you Fuserleer. But reality is reality. Please don't blame me for reality.

We've seen NOTHING from you but endless waffling and attacking of other solutions for 3 years.

Apparently you haven't been reading my technical posts.

[Fuserleer]

Are you refering to this http://blog.emunie.com/?p=53 ?
Where do you see the similarities to POS ?

No, it was on these forums - there was a consensus primer, but it lacked critical information. What I could discern at the time was that it was vulnerable to long range attacks (like POS), and there were edges cases around when the validating nodes changed. Both of these problems challenge the idea of an append only ledger, unless you add trusted authorities.

Did you announce the details of these long range attacks you perceived, I don't recall.  

Also the voting nodes change at specific intervals, theres an edge case where the majority of the selected voting nodes are offline, or unavailable and dont vote.  That then results in a failed vote and the ledger state is in "limbo" until the next set of selected voting nodes then vote.  As they are voting on the state of the ledger, their vote encapsulates the data as a matter of course from the missing vote.  Not really a critical issue.

I figured voting would be the way you would try to do it.

Which vote occurred first? How do you prove it with a mathematical data structure?

Can't be done without a LCR or centralization.

If you even bothered to read the primer I posted months ago, such a realization you just had would of been apparent MONTHS ago.

You don't need to know which vote occurred first, apparently you're smart, so get your head out of the box a bit and think.

[TPTB_need_war]

Are you refering to this http://blog.emunie.com/?p=53 ?
Where do you see the similarities to POS ?

No, it was on these forums - there was a consensus primer, but it lacked critical information. What I could discern at the time was that it was vulnerable to long range attacks (like POS), and there were edges cases around when the validating nodes changed. Both of these problems challenge the idea of an append only ledger, unless you add trusted authorities.

Did you announce the details of these long range attacks you perceived, I don't recall.  

Also the voting nodes change at specific intervals, theres an edge case where the majority of the selected voting nodes are offline, or unavailable and dont vote.  That then results in a failed vote and the ledger state is in "limbo" until the next set of selected voting nodes then vote.  As they are voting on the state of the ledger, their vote encapsulates the data as a matter of course from the missing vote.  Not really a critical issue.

I figured voting would be the way you would try to do it.

Which vote occurred first? How do you prove it with a mathematical data structure?

Can't be done without a LCR or centralization.

If you even bothered to read the primer I posted months ago, such a realization you just had would of been apparent MONTHS ago.

You don't need to know which vote occurred first, apparently you're smart, so get your head out of the box a bit and think.

You did not address the technical challenge. You just used ad hominem and inconclusive statements to avoid it.

What people don't like is when they can't bullshit any more.

Edit: When ever someone asks you to actually give details, you get offended and state I have revealed no technical work in public, which is obviously false. Just read this thread.

Also you've forgotten that I debated you on your primer back in Sept or whenever you created that thread.

[Fuserleer]

Did you announce the details of these long range attacks you perceived, I don't recall.  

There was the long con attack (building trust over time), which isn't technically a long range attack. The long range attack was whereby a node syncing with the network had no objective measure of which chain/channel was legitimate.

Ahh yes I remember now.

I mentioned I think up thread (or in another one) that I made some mods to the consensus to deal with this possible edge case, but I didn't publish yet.  

In a nutshell your short term endorsements take a greater weight over your long term.   There are some Sybil considerations to take into account, but they are similar to those that can happen over the long term where by a successful attack can provide a window to pull a Finney.  The best approach for that is to simply wait until the next vote is in 30s or so later as I mentioned in previous posts before.

The long term endorsements now are the primary determiner of how much reward you get of new supply, fees, etc.

[Fuserleer]

Are you refering to this http://blog.emunie.com/?p=53 ?
Where do you see the similarities to POS ?

No, it was on these forums - there was a consensus primer, but it lacked critical information. What I could discern at the time was that it was vulnerable to long range attacks (like POS), and there were edges cases around when the validating nodes changed. Both of these problems challenge the idea of an append only ledger, unless you add trusted authorities.

Did you announce the details of these long range attacks you perceived, I don't recall.  

Also the voting nodes change at specific intervals, theres an edge case where the majority of the selected voting nodes are offline, or unavailable and dont vote.  That then results in a failed vote and the ledger state is in "limbo" until the next set of selected voting nodes then vote.  As they are voting on the state of the ledger, their vote encapsulates the data as a matter of course from the missing vote.  Not really a critical issue.

I figured voting would be the way you would try to do it.

Which vote occurred first? How do you prove it with a mathematical data structure?

Can't be done without a LCR or centralization.

If you even bothered to read the primer I posted months ago, such a realization you just had would of been apparent MONTHS ago.

You don't need to know which vote occurred first, apparently you're smart, so get your head out of the box a bit and think.

You did not address the technical challenge. You just used ad hominem and inconclusive statements to avoid it.

What people don't like is when they can't bullshit any more.

You'd have known that information about voting a long time ago if you were actually reading the content I produced instead of just attempting to shoot it down.

That leads me to think you are actively wasting my time which pisses me off to be frank.

[Fuserleer]

We've seen NOTHING from you but endless waffling and attacking of other solutions for 3 years.

Apparently you haven't been reading my technical posts.

Technical posts do not a finished product make.

[TPTB_need_war]

We've seen NOTHING from you but endless waffling and attacking of other solutions for 3 years.

Apparently you haven't been reading my technical posts.

Technical posts do not a finished product make.

They are not NOTHING. Whereas from you we have NOTHING. No details that can be analyzed on any topic. Just puffery and vague generalizations. If I am mistaken, please point me to even one post where you have eludicated some detailed technical issue. I wasn't attacking you, but now you are attacking me. So here is my reaction.

I am simply saying that you can not attain append only with voting, because there is no way to prove with a mathematical data structure when each majority vote occurred relative to a competing claim. That is precisely why only LCR solves the problem for double-spends. Once you release details, I will go into more detail on attacks. I don't want to waste my time on a vague moving target.

[Fuserleer]

Edit: When ever someone asks you to actually give details, you get offended and state I have revealed no technical work in public, which is obviously false. Just read this thread.

Also you've forgotten that I debated you on your primer back in Sept or whenever you created that thread.

I get offended when people demand that I give details as if I have some form of obligation to do so. 

I'll also only provide details that I am comfortable can be in the public domain without being subject to abuse or worse, plagiarism.  Surely that is my decision and shouldn't be criticized for it (you've done the same thing).

[Fuserleer]

We've seen NOTHING from you but endless waffling and attacking of other solutions for 3 years.

Apparently you haven't been reading my technical posts.

Technical posts do not a finished product make.

They are not NOTHING. Whereas from you we have NOTHING. No details that can be analyzed on any topic. Just puffery and vague generalizations. If I am mistaken, please point me to even one post where you have eludicated some detailed technical issue. I wasn't attacking you, but now you are attacking me. So here is my reaction.

Id attribute that statement to suggest you just didn't read them, as it seems apparent its happened before.

[TPTB_need_war]

We are derailing the thread. Ever since the discussion of the ability to prove checkpoints without a LCR, there is no technical discussion, just stupid noise posts. Because it is a very researchy topic and unless someone shows a solution to analyze then is going to be a bunch of vague crap. Come on guys. Let's keep the thread informational.

[skywave]

Can't we (you) just agree that time will tell/prove what eMunie can do/is capable of, and that the impatience (which I can fully understand) to get your hands onto the baby and grope her, as well as laying your eyes on the documentation, is unbearable to most?

But rest assured that Fuserleer himself is impatient, yet determined

[Fuserleer]

The LCR rule in Bitcoin is a compromise IMO.

I believe that initially Satoshi was investigating a number of consensus mechanisms, but had POW in there from early on to regulate the issuance of supply.

POW is perfect for that task, he who does more work gets rewarded and the hash method of proving so coupled with difficulty is pretty much bang on the money for a fixed total supply emitted over time.  POW based currency issuance is a race to the finish line, and as we know, in a race there can only be one winner in any event.  Someone wins, gets the reward, starts over.  This distribution of new supply while not always fair, is simple.

On the consensus side of things I think it was quite a bit different.  I imagine Satoshi had many designs for it, some failed, some were impractical...perhaps too bandwidth heavy for the connections of the day, which now isn't so much a problem, whatever.  Yet just happened to realize that he could use POW, which was primarily meant for currency issuance also as a form of agreement.  The winner of the race not only gets the prize, but also has a say on the outcome of some event.

Is it smart thinking?  Sure it is, of that there is no doubt.  Is it the only way to skin a crypto cat?  No.

The issue is that the outcome of the race is not final.  Some guy on his own somewhere can be running his own race in secret, then come and steal the prize and enforce a different opinion on how things should be from that point on.

No one else seems to think this is an absolute CRITICAL problem other than me, and more than that, they declare that the LCR + POW where the past can be altered, is the one and only solution to any similar problem.  LCR + POW is a compromise plain and simple, no real workable solution for P2P consensus could be found at the time due to whatever reason (probably technology capabilities) other than LCR + POW and so efforts were taken by Satoshi to make it as safe as possible.  

I'd have probably done the same, especially after all the shit the banks had just pulled.

Transactions are deterministic in nature, a previous transaction determines what future transactions can occur.  If I give Bob $10, that act then determines the entire set of transactions that I and Bob can make in the future.  LCR and POW doesn't consider this fact at all, there is zero correlation between the event and the recorded outcome which allows for the outcome to be changed at someones will.  What good is a record of event where that can happen?  Including deterministic properties in the outcome of events is excatly what eMunie does, and it makes it MUCH harder to forge or change the outcome of an event once it is agreed upon.

I'm going to post an example after this...

[Fuserleer]

I'll put up a compressed and detailed blurb once I have time, currently work has more priority than talking.  

However, allow me to post a real simple and clear example...forget Sybil, forget Byzantine, network partitions and everything else.  No doubt someone will comment about those issues as no one here seems to read very often.  This example is ONLY to highlight the very basics of append only mechanics and there is nothing new here, it was all included in the consensus primer, which by now has been reviewed by a number of reputable people.

None have found a legitimate flaw that could be exploited easily, and seeing as everyone is happy to accept that LCR + POW can be exploited with enough resources, yet can live with it, Im happy enough too.

You must remember that eMunie tracks balances ONLY and doesn't not reference outputs as inputs or anything similar!  Failure to do this will result in a misunderstanding of even basic concepts.

Assume there is a network of 4 nodes, A, B, C and D, where one of them is malicious, any, it doesn't matter.

A is making transactions, B, C and D are vying for endorsements and all have a connection to A.
Periodically B, C and D are presented with a challenge from A, if they provide the correct solution, they are honest.  You can classify this as a POW, and it makes up the 1st part of resource expenditure.
Assume B, C and D present correct solutions.
A makes a transaction, and upon doing so endorses one of the connected nodes B, C and D.  Lets say that A endorses B.  
A also pays a fee for making the transaction which is the 2nd part of resource expenditure.
A makes another transaction, this time endorsing C.

This continues for a period of time with A endorsing one of the B, C, or D nodes for each transaction.

Later D wishes to attempt to change history as hes malicious, but there is no way for him to do this, he can have access to all POW and fee resources on earth and he still cannot. Why?

In an append-only ledger, an attempt to inject, modify, change or remove a transaction that is in the past results in a consensus trigger.  There is a small window of time allowed for propagation and clock drift, you could assert this time period akin to a confirmation.  Any node that sees such transactions after this time period has expired, regardless of if the transaction is legal or not, will have to rely on a vote result to determine if it can be included in its copy of the ledger.

It is the role of the endorsed nodes to vote on what the current state of the ledger should be, and the state with the maximum votes wins.  Only a portion of the full set of endorsed nodes are eligible to vote at any time, and this is determined by the endorsements made in recent transactions.

In our case, B, C, and D will be eligible to vote as they have been present throughout the duration of A's transaction making marathon.

Assume there is a transaction that propagated slowly, but providing that the majority of the endorsed nodes have seen it, then it will be included in the state that is voted in.  If D is included in that vote, and wants the transaction to be included, he can present his vote and that is all.  He cannot spend any amount of resource to force such a transaction to be accepted if the majority state that is shouldnt.  

Even if he created 1M fake transactions right now and presented them with forged timestamps and what not, all they would do would be to trigger a vote, which is already happening.  If he created 1M transactions with the correct time stamp and other data, they would only get included in the next vote, by a different set of voters.

Once the vote is in, and the ledger state is decided upon, the ONLY state that endorsed nodes can now vote on is the next.  There is nothing D could do to force a re-vote, and even if he could, all the other endorsed nodes would vote exactly the same as they did before.

Now this bit is important.....the set of endorsed nodes that may vote is deterministic and the vote result for each node is deterministic from the data they have.  The determinism is seeded by the transactions for which some resource has been expended to create (fee & challenges).  

Such is the nature that a transaction sent 1 second earlier or later can change the vote in some circumstances, but the result of that vote will always be the same after the fact.  If transactions that are older than a certain period of time are not included in the ledger until the outcome of that vote is known, then that transaction cannot possibly influence the determinism of the vote, thus the vote result is the same.

One edge case I will touch upon is the instance where a node accidentally accepts a transaction that is outside of the expiration time, in this event that nodes ledger state will start to deviate from everyone else so he will have to call upon other nodes to find out the real state and the result of past votes.  Assuming that his ledger is not too far out of sync with everyone else, he will have enough true data available to verify the results of these past votes and resolve the deviation automatically.

There you have it, a brief example into a ledger that is final, trustless, expends resource and decentralized.  If you can't understand that, well, I can't help you anymore.

This as mentioned only touches on the question in hand and there is a lot of other stuff that exists alongside these principles.

Some surely will argue this is a propagation based method, which is incorrect, propagation only plays a small part to invoke a trigger to decide whether it should be included.  If the decision is NO, then that transaction will fail a short time later, and the user will be prompted it has happened (within 30s) and can represent it.

[masterOfDisaster]

I admit I haven't read the whole thread (which I will likely do).
Searching within all posts didn't show an occurance of Proof-of-Burn.
This was invented by Slimcoin (burning coins to generate virtual miners that process transactions and write the blockchain).
I'd like to know what's your view of Slimcoin or rather Proof-of-Burn (because Slimcoin is more dead than alive, but Proof-of-Burn as consensus mechanism not necesarily).
If you don't find information about it, I might dig in my bookmarks for bitcointalk threads, source code and more when I'm at my computer.

[Come-from-Beyond]

The LCR rule in Bitcoin is a compromise IMO.

LCR failed hard during that famous Bitcoin Fork 2013. Other mechanisms were used to solve the problem.

[Fuserleer]

The LCR rule in Bitcoin is a compromise IMO.

LCR failed hard during that famous Bitcoin Fork 2013. Other mechanisms were used to solve the problem.

Indeed it did, thats a good case in point.

[patmast3r]

...
Periodically B, C and D are presented with a challenge from A, if they provide the correct solution, they are honest.  You can classify this as a POW, and it makes up the 1st part of resource expenditure.
...

Maybe this falls into the category of information you don't want to be pulic yet but I'll ask anyway.
Could you go into more detail on what such challanges might look like ? To me - obviously no expert in any sense of the word - it would seem difficult to make sure nodes aren't acting good-natured when answering challenges while acting evil when it comes to forming consensus.

[Fuserleer]

...
Periodically B, C and D are presented with a challenge from A, if they provide the correct solution, they are honest.  You can classify this as a POW, and it makes up the 1st part of resource expenditure.
...

Maybe this falls into the category of information you don't want to be public yet but I'll ask anyway.
Could you go into more detail on what such challanges might look like ? To me - obviously no expert in any sense of the word - it would seem difficult to make sure nodes aren't acting good-natured when answering challenges while acting evil when it comes to forming consensus.

The challenges are fairly simple and are to ensure that nodes have the data they claim, and are providing the service they claim to in an honest manner.

For example, if node D was advertising that he was acting as a ledger resource, nodes don't have any real way to know if the ledger information he is serving up is legit, they wont know if its valid until they receive it.

This isn't a huge problem, as the act of node D sending out incorrect ledger information is more of a hindrance (it wont validate so requesting nodes have to go elsewhere) than anything else, but we want to limit the endorsement of dishonest nodes as much as possible.

Basically, A would present a challenge to D requesting some information that is public, and only if D was doing the job he claims would he have that information and provide the correct solution.  

It could be something as mundane as sending the merkle root hash for all transactions on the 25th December 2015.  If D is providing a ledger service, he should have that information and be able to provide the hash.  A then compares D's solution to his, if they match D is likely honest.

D will never know directly if he sent the correct solution to A, at best he can guess that he did if he gets an endorsement soon after.

[TPTB_need_war]

Another flaw in Satohi's design:

Doesn't that simply mean it is a lottery like Bitcoin, all the miners compete to get the pay because the time they do win it pays for all the failed attempts?

Surely like Bitcoin only as much mining power will tend to be applied as the payouts generally tend to cover on the average?

-MarkM-

But but the amount of gas is consistent system wide. How will that work such that the profitability is market adjusted and not a centralized action? Otherwise you can't be sure your script will run because you don't know which miner will win the block. Any way, I just want someone to explain to me what their current design is, so I can analyze it.

They were in research before and changing designs so much I stopped tracking them.

Bitcoin doesn't have this problem because TX/s rate is so low and block reward is the majority of the reward. Once TX/s goes high, Bitcoin will also break because of this.