Decrits: The 99%+ attack-proof coin

[sor.rge]

1. I thought we already decided that excluding transactions was not a possible attack (unless 100% of peers are evil), because the honest fork would be readily identified as including all transactions (including those from the evil fork). The worst that could happen is a transaction could be delayed by one CB period, if the evil fork withheld propagation of TBs (to non-evil peers) until the CB (where it can't be withheld any more and still be a public fork) or if the evil fork included transactions from the honest fork one CB later (so as to be not readily identified as the evil fork).

Things are as not as simple, because if we count the branch with more transaction as the honest one, then the attacker can introduce his own transaction which wasn't broadcasted, and win. So in practice you don't know whether it's a transaction which has been dropped or added by an attacker. The time limits resolve this.

2. The only attack vector is that evil peers will not let non-evil peers sign their CBs and evil peers could create one or more forks in addition to the honest peers. There might even be multiple factions of evil peers who don't want to share tx revenue and thus exclude other peers. So the problem is how to identify which fork is the consensus in order to properly award tx fees?

The proposed resolution of this is by timing. If you introduce some precise time windows when a message must be broadcasted, then the nodes who are always online can decide whether the protocol was followed. The protocol can be modified such that if an SH decides to not include a TB in his CB, he must declare that immediately at the time of that TB. In this way CB is built continuously and not just decided last minute, so there can be no surprises at the time of CB. Therefore anyone who observes the process can decide if TBs are being withheld or being dropped dishonestly. Etlase2 had a more elaborate solution above.

b. The honest peer's opinion is only valid for himself, and can't be proven to the world without 51% consensus.

True. But the ability of the honest always-online node to see through 51% attack with just passive observation is already a good start.
Still the assumption of guaranteed broadcast message delivery must be taken.

[AnonyMint]

1. I thought we already decided that excluding transactions was not a possible attack (unless 100% of peers are evil), because the honest fork would be readily identified as including all transactions (including those from the evil fork). The worst that could happen is a transaction could be delayed by one CB period, if the evil fork withheld propagation of TBs (to non-evil peers) until the CB (where it can't be withheld any more and still be a public fork) or if the evil fork included transactions from the honest fork one CB later (so as to be not readily identified as the evil fork).

Things are as not as simple, because if we count the branch with more transaction as the honest one, then the attacker can introduce his own transaction which wasn't broadcasted, and win. So in practice you don't know whether it's a transaction which has been dropped or added by an attacker. The time limits resolve this.

Incorrect, because every fork can pick up this transaction in its next CB. The evil fork has to broadcast the CB else the fork doesn't exist in public view.

2. The only attack vector is that evil peers will not let non-evil peers sign their CBs and evil peers could create one or more forks in addition to the honest peers. There might even be multiple factions of evil peers who don't want to share tx revenue and thus exclude other peers. So the problem is how to identify which fork is the consensus in order to properly award tx fees?

The proposed resolution of this is by timing. If you introduce some precise time windows when a message must be broadcasted, then the nodes who are always online can decide whether the protocol was followed. The protocol can be modified such that if an SH decides to not include a TB in his CB, he must declare that immediately at the time of that TB. In this way CB is built continuously and not just decided last minute, so there can be no surprises at the time of CB. Therefore anyone who observes the process can decide if TBs are being withheld or being dropped dishonestly. Etlase2 had a more elaborate solution above.

This doesn't solve a non-problem that doesn't exist with transactions. It does nothing to solve the 51% attack with signing of the CB. Signing of the CB is necessary to decide the order of peers who can sign TBs.

b. The honest peer's opinion is only valid for himself, and can't be proven to the world without 51% consensus.

True. But the ability of the honest always-online node to see through 51% attack with just passive observation is already a good start.

No it accomplishes nothing as I already explained. We are walking in circles going no where. The 51% attack can not be avoided by any decentralized design.

I want to stop wasting time and move to things we can accomplish on fixing other Bitcoin weaknesses.

[sor.rge]

Incorrect, because every fork can pick up this transaction in its next CB. The evil fork has to broadcast the CB else the fork doesn't exist in public view.

This can be made impossible by spending the money on this wallet and not including this transaction. On block N the attacker broadcasts a transaction which spends all money from his wallet, but doesn't include it in his CB, using 1 CB "grace" period. On block N+1 he announces and includes 10 transactions involving money on the same wallet. The honest guys can't include them since they already confirmed the money spent, and the bad guy wins by 9 transactions. If you didn't observe this happening and you just see the blocks, you can never tell whose version is honest.

It does nothing to solve the 51% attack with signing of the CB. Signing of the CB is necessary to decide the order of peers who can sign TBs.

Imagine the CB is signed continuously, with every TB. There is no way to withhold a TB and announce it later: this would create a discontinuity easily observable, and the attacker will have to deny his own signatures. There is no way to drop TBs: everyone knows it has just arrived and the evil guy has it, so if he ignored it it's a fraud.

We are walking in circles going no where. The 51% attack can not be avoided by any decentralized design.

Then you'll have to explain how the attack works, under the new set of assumptions, namely: the broadcast delivery is guaranteed in bounded time and everyone is constantly online. Or wait for the system to be implemented and try to implement the attack. At this point I don't see such an attack.

[Charles999]

I will throw some hash poer at this. could be worth a lot

[digitalindustry]

i like what is happeing on this topic - i'm now going to read it -

[firefop]

come up with a implementation and i will hack it.

This.

Also, your assumptions about how this will work are exactly that... assumptions. You dependent on someone everyone not being stupid or malicious enough to legitimately break your system. The primer on how to do it either through buying power or collusion are right there (and both of these scenarios will actively ignore any disincentives).

Bad idea is just bad.

[digitalindustry]

"As far as qualifications, I've been programming since I was about 12, but only as a hobbyist. After learning about bitcoin I went on a two year study of economics, cryptography, network protocols, byzantine fault tolerance, and so on while discussing and refining the various proposals that have eventually led to this one, the 6th, which I think is as close to perfect as an imperfect system can get. So, no qualifications really. Just a vision with the ability to come up with the design implementation whenever I need to dig ."



Nobody I know understands human economics better than I do , so I may be able to help you , sometimes things are hidden right in front of you , I will read the  topic , I will need the binary translated in some parts but.

[AnonyMint]

Okay I worked through all the possibilities as explained upthread and below, and have concluded that Proof-of-Consensus can't work. I will now be stopping all further work on this dead-end. And all those who have a well functioning brain stem will stop this now.

As I wrote from the very beginning of my involvement in this thread (which is why I had stopped work on my Proof-of-Hard Disk version of Proof-of-Consensus on May 13, 2013, before Etlase2 emailed me to check out his idea), there is no way to get the randomized entropy to randomize the order of which peers can sign the TBs. Upthread we had discussed the impossibility (network overload scenarios) of allowing all (potentially unlimited if attacker spams) SHs to sign within a CB, so Etlase2 offered the clever solution of using the signatures on the prior CB to randomize the order and we convinced ourselves that this could not easily be gamed if we used a function to modulate the self-chosen hash keys of the SHs with this random entropy.

But the problem is that there is no way to have consensus on who has signed the CB. If peers (wanting to be SHs on next CB) will separately broadcast their signatures, then who decides which were broadcast within the time limit and compiles it into a CB? If those peers will instead sign a CB that was signed by a prior peer until all who want to sign have signed it (within a deadline), the problem is who decides the order that they sign?

There is no possible solution. This is why only Proof-of-Work is viable for achieving consensus.

So we are done. End of story. STOP.

Incorrect, because every fork can pick up this transaction in its next CB. The evil fork has to broadcast the CB else the fork doesn't exist in public view.

This can be made impossible by spending the money on this wallet and not including this transaction. On block N the attacker broadcasts a transaction which spends all money from his wallet, but doesn't include it in his CB, using 1 CB "grace" period. On block N+1 he announces and includes 10 transactions involving money on the same wallet. The honest guys can't include them since they already confirmed the money spent, and the bad guy wins by 9 transactions. If you didn't observe this happening and you just see the blocks, you can never tell whose version is honest.

Along with the need to sign the CB periodically to gain the randomized entropy I mentioned above, I also admitted this possibility of double-spends in my prior post. And both of these reasons are why only the 51% fork can be the consensus. And thus why I have concluded that 51% attack is possible (in any form of P2P decentralized consensus, not just money). But we can't even accomplish the required randomized entropy so as I stated above Proof-of-Consensus does not work. This is a dead end.

It does nothing to solve the 51% attack with signing of the CB. Signing of the CB is necessary to decide the order of peers who can sign TBs.

Imagine the CB is signed continuously, with every TB.

Then can't get the randomized entropy for deciding the order of signing.

We are walking in circles going no where. The 51% attack can not be avoided by any decentralized design.

Then you'll have to explain how the attack works, under the new set of assumptions

Those assumptions won't provide the required randomized entropy for deciding the order of signing.

[AnonyMint]

Per my prior post, Proof-of-Consensus is a dead-end.

We could still look to improve critical flaws in Bitcoin while employing a Proof-of-Work system:

• Eliminate the 10 min delay by offering the option for spender to place some funds in escrow as a guarantee against double-spend, and escrowed money is forfeited to the ether if there is a double-spend.
• Eliminate Bitcoin's declining debasement schedule so there is funding from minting forever
• Add tx fees to incentivize peers to include more transactions in their TBs
• Consider a Litecoin-like Proof-of-Work that disfavors ASICs
• Improve anonymity as we discussed in this thread

I am liking my domain name autonomoney.com because the greatest thing about decentralized currency is that no centralized authority controls who can become a spender and a merchant and there is instant signup with no approvals needed.

We need minting so any one can go earn some coins with capital while sidestepping anti-money laundering laws. We need that minting to not stop in 2034 when the 78 cycle predicts this current global crisis to bottom.

[freedomno1]

Better POC than most alt's observed
Will look into this

[firefop]

Per my prior post, Proof-of-Consensus is a dead-end.

We could still look to improve critical flaws in Bitcoin while employing a Proof-of-Work system:

• Eliminate the 10 min delay by offering the option for spender to place some funds in escrow as a guarantee against double-spend, and escrowed money is forfeited to the ether if there is a double-spend.
• Eliminate Bitcoin's declining debasement schedule so there is funding from minting forever
• Add tx fees to incentivize peers to include more transactions in their TBs
• Consider a Litecoin-like Proof-of-Work that disfavors ASICs
• Improve anonymity as we discussed in this thread

I am liking my domain name autonomoney.com because the greatest thing about decentralized currency is that no centralized authority controls who can become a spender and a merchant and there is instant signup with no approvals needed.

We need minting so any one can go earn some coins with capital while sidestepping anti-money laundering laws. We need that minting to not stop in 2034 when the 78 cycle predicts this current global crisis to bottom.

I'm fairly sure you wouldn't be able to eliminate it entirely. But I would expect once the network hash rate grows past some point we'll see an increase in block generation rate (and a reduction in block rewards to match) and also an increase in number of transactions per second.

I believe that making it non-deflationary isn't an improvement that anyone will want... that's bitcoins primary strength. If we eliminate that we no longer need to mess with tx fees.

Changing the proof of work to be asic hostile should be a non-starter, it's doomed to failure by it's very design. Nobody can design any digital process that cannot be accelerated by application specific processes. If you fix the proof of work process then someone is able to design an fpga or asic to follow that process. It might be possible to design some sort of rotating proof of work system that cycles through creating variants of different types of proof of work in an attempt to delay the development of specific hardware. But then again it probably wouldn't be cost effective... as adoption grew the people wishing to profit from creating such hardware would rapidly outpace whatever development work you could afford to do on the proof of work.

There are ways to improve anonymity working on and off the blockchain currently.

[AnonyMint]

Per my prior post, Proof-of-Consensus is a dead-end.

We could still look to improve critical flaws in Bitcoin while employing a Proof-of-Work system:

• Eliminate the 10 min delay by offering the option for spender to place some funds in escrow as a guarantee against double-spend, and escrowed money is forfeited to the ether if there is a double-spend.
• Eliminate Bitcoin's declining debasement schedule so there is funding from minting forever
• Add tx fees to incentivize peers to include more transactions in their TBs
• Consider a Litecoin-like Proof-of-Work that disfavors ASICs
• Improve anonymity as we discussed in this thread

I am liking my domain name autonomoney.com because the greatest thing about decentralized currency is that no centralized authority controls who can become a spender and a merchant and there is instant signup with no approvals needed.

We need minting so any one can go earn some coins with capital while sidestepping anti-money laundering laws. We need that minting to not stop in 2034 when the 78 cycle predicts this current global crisis to bottom.

I'm fairly sure you wouldn't be able to eliminate it entirely. But I would expect once the network hash rate grows past some point we'll see an increase in block generation rate (and a reduction in block rewards to match) and also an increase in number of transactions per second.

Did you miss the point that the spender puts up a forfeitable escrow to guarantee he won't send a double-spend, thus the recipient decides to accept the funds immediately, thus the delay is ALWAYS eliminated when the two-parties make this agreement.

Note the escrow must be sent into the blockchain say 10 minutes before the actual spend, otherwise the escrow could be double-spent. Thus this requires a spender to keep escrows around waiting for when spender needs to use them. Does require some pre-planning on the part of the spender, but at least frees the recipient from waiting.

I believe that making it non-deflationary isn't an improvement that anyone will want... that's bitcoins primary strength. If we eliminate that we no longer need to mess with tx fees.

Both of these points have been thoroughly rebutted in my comments in my thread:

https://bitcointalk.org/index.php?topic=160612

The summary is that small debasement is more fair and society will demand it and get it any way. Even gold is debased annually.

Also some currency is lost over time, so we need debasement to offset it. Moderate debasement is synonymous with renewal, anti-stagnation, and innovation for many reasons such as discussed in my other thread:

https://bitcointalk.org/index.php?topic=226033

And minting does not require including transactions, so still need tx fees.

And minting is necessary to provide a way to obtain currency without passing through anti-money laundering id checks (per the March 18 FinCen guideline). Did you see that now even mailing cash is becoming illegal:

http://armstrongeconomics.com/2013/06/11/mailing-cash-is-prohibited-in-usa-france-bars-even-gold/

Changing the proof of work to be asic hostile should be a non-starter, it's doomed to failure by it's very design. Nobody can design any digital process that cannot be accelerated by application specific processes. If you fix the proof of work process then someone is able to design an fpga or asic to follow that process.

Hmmm...(I had been thinking about this point already)

However perhaps we can shift the balance in favor of rewarding large quantity of RAM, so general purpose computers are on a more level playing field. If we can shift the time component to the performance of RAM and away from the CPU, then perhaps we defeat ASICs economically.

I just don't know yet if it is possible to make the random lookup the largest time component of the calculation. I will study more.

May want to stay within the CPUs local cache since it is highest-speed, or a combination of local cache and large RAM bound. Need to look at details of the economics.

It might be possible to design some sort of rotating proof of work system that cycles through creating variants of different types of proof of work in an attempt to delay the development of specific hardware. But then again it probably wouldn't be cost effective... as adoption grew the people wishing to profit from creating such hardware would rapidly outpace whatever development work you could afford to do on the proof of work.

Agreed I think there is too much similarity between classes of possible Proof-of-Work.

There are ways to improve anonymity working on and off the blockchain currently.

Not entirely what we need apparently. I think we will need a Bitcoin replacement to get the anonymity just right. I am open to be refuted by details.

[digitalindustry]

2034 when the 78 cycle predicts this current global crisis to bottom.

ha ha ha .

just forget that -

And this "Crisis" is not Global its "Western" , its just that the West expanded to touch a lot of the globe with a debt money system, that worked by expansion of effective "capital" based on a singluar directional information system(s). 

Why i pull up your factually inccorrect comment , and why it is important to correct you , is becasue many nations are going to walk away with a lot of the GPD of the world in an effective "transfer of wealth", the same could be said for Cryptocurrency -

that is not to say i'm saying;  "The West , give up on it" , that's not what i'm saying , i'm saying a 78 Cycle can't predict the Internet multidimensional effect on information and it didn't predict the Television.

[digitalindustry]

"So we are done. End of story. STOP."

i'll also tell you something else about humans for free -

any human that says "no" to a new idea , has usually a primary motive , because even if a failure is a failure , often new ideas sprout from that ,as the effect of that information spreads .

so you give yourself away every time , to me , but not to others.

But that's human life hey ?  

For example the – “ create it an I’ll hack it or attack it “ is a much more positive comment.

[sor.rge]

Those assumptions won't provide the required randomized entropy for deciding the order of signing.

Now you came up with another argument, one which is completely unrelated with what was discussed yesterday I must add, and pretend that you've closed the question. You argument includes no details, just a keyword. That doesn't work that way, you didn't convince me of anything - I didn't follow the entropy talk of the last month. As I said, either an attack is spelled out, in whatever form, or it doesn't exits.

It's ok for me if you don't want to continue the discussion, you don't have to. The final answer should come out of an implementation anyway, not from the arguments.

[digitalindustry]

come up with a working implementation, give me the source and i will destroy it. the bet still stands.

Exactly, the bet is still live. I am taking this post to mean that you are calling back your demand for immediate payment in this post:

your system is huge , complex and failish, there is alot of stuff that could and will go wrong. you are giving the power of the system to the devs(central control) from the start. and you cannot buy in with out all current SH agrees. and no one hold my money, and the network cannot do such a task without central control, or the possibility of fail.

bitcoin is different: anyone can buy hardware to mine, no one have(or can ever gain) absolute veto rights.

now give me my btc: 13MXCTA2CPYbREMqNaf5VK2ArSc3QYm8cc

Which means you concede that, on paper, you have not been able to defeat the system.

i'm on page 3 and have a +1 for "Decrits" - its getting exciting , don't ruin it for me. if you are an angry BTC ASIC pre-order victim don't even comment.

[digitalindustry]

1) Decrits is intended to be a "trickle-in" type currency, where most new currency enters the economy in a random way. The randomness ensures that those with lots of decrits can't control new money, and they can't make credit/fractional reserve/debt money more appealing than "real" decrits. When demand for new currency arises, the people are intended to make it and distribute it, so there is little incentive whatsoever to accept a bank's credit.
2) An expanding economy is indicated by those willing to waste resources in creating new currency to facilitate trade. If decrits could be compared to a metal that does not have much utility other than in trade, then it would be a metal commonly distributed throughout the Earth that only requires you to invest tools and time.
3) Most of the time, enough of the currency will be in circulation so that it is not necessary to waste the effort and doing something actually productive will be much more lucrative--like a job. But if money for basic human needs is hard to come by, people will waste effort in making currency. This is the threat that all people should be able to have over the wealthy.
4) This further encourages increasing the velocity of money because money will then be given away freely. It discourages using money--a tool, no more--as a way to control or disrupt society.
5) If changing something as irrelevant as a hashing algorithm is what it takes to restore the balance, then the protocol must facilitate this in every way possible. Via section 4, a new currency can be created where the old currency can be accepted at a 1:1 value, while new currency can be created again by whatever means is easily available to the population.


page 5 - well you did study some economics - , now you have credibility in my view . {likely women will throw themselves at you}

[AnonyMint]

2034 when the 78 cycle predicts this current global crisis to bottom.

ha ha ha .

just forget that -

Hey "birdbrain" (your avatar and your Dunning–Kruger effect behavior), click on the link in the quote below and read the details to correct your ignorance:

Side note, Martin Armstrong's 78 year (i.e. 3 x 26 year human maturity generations) real estate cycle predicts that bottom in 2033. I wrote that the 26 year downhill portion of this cycle appears to repeatably correspond with massive unemployment (and a major war) due to a new technological paradigm, e.g. the early 1900s destruction of cottage industry by mass production and now the destruction of menial labor by the personal computer automation and robotics. In the 1700s, it was agricultural technology disruption of employment. The masses delay their adjustment to the new skills with debt and socialism, which thus causes the resultant financial crisis to drag on longer and be more severe.

And this "Crisis" is not Global its "Western" , its just that the West expanded to touch a lot of the globe with a debt money system, that worked by expansion of effective "capital" based on a singluar directional information system(s).

http://www.mpettis.com/2012/06/11/what-is-globalization/#comment-18964

Why i pull up your factually inccorrect comment , and why it is important to correct you , is becasue many nations are going to walk away with a lot of the GPD of the world in an effective "transfer of wealth", the same could be said for Cryptocurrency -

There is a transfer of wealth from people don't work (Western debt-funded consumption) to those who do work (the poor in the developing world who are slaving away). However this transfer is done in the context of debt funding for fixed capital (real estate & infrastructure) investment in the  developing world, as the developing world is massively short the dollar with dollars bond issues and dollar loans soaking up a lot of the QE from the west, since interest rates are negative in the west. Thus the bankers manage and own the transfer in the macro perspective.

that is not to say i'm saying;  "The West , give up on it" , that's not what i'm saying , i'm saying a 78 Cycle can't predict the Internet multidimensional effect on information and it didn't predict the Television.

It sure did predict the technological revolutions that cause the massive unemployment, which cause the socialism to sustain a generation who can't make the shift to the new skills. See my link in the quote of myself above for the proof.

Be careful. I know more than you think I do. It will be revealed in onion layers as you make a public display of your arrogant ignorance, as I have done to numerous others in these threads.

[AnonyMint]

"So we are done. End of story. STOP."

i'll also tell you something else about humans for free -

Ignorance for free. Wow, you are so generous.

any human that says "no" to a new idea , has usually a primary motive , because even if a failure is a failure , often new ideas sprout from that ,as the effect of that information spreads .

Yes like moving forward from the failure as efficiently as possible, to the new ideas of how we can improve on Bitcoin, as I have done immediately upthread.

so you give yourself away every time , to me , but not to others.

Any more content-free statements to clutter this thread?

For example the – “ create it an I’ll hack it or attack it “ is a much more positive comment.

That accomplishes nothing. I have provided UNARGUABLE logic justifying my assertion that Proof-of-Consensus can not work. Now you just need to understand the logic that has been presented. See my next post.

[AnonyMint]

Those assumptions won't provide the required randomized entropy for deciding the order of signing.

Now you came up with another argument, one which is completely unrelated with what was discussed yesterday I must add, and pretend that you've closed the question. You argument includes no details, just a keyword. That doesn't work that way, you didn't convince me of anything - I didn't follow the entropy talk of the last month. As I said, either an attack is spelled out, in whatever form, or it doesn't exits.

It's ok for me if you don't want to continue the discussion, you don't have to. The final answer should come out of an implementation anyway, not from the arguments.

The discussion in the prior day or two was Etlase2 trying to find a solution to the 51% attack that you and I explained. But any signing of TBs will require a deterministic order as explained below. Thus that discussion does not escape from the insoluble problem below.

What part of the UNARGUABLE logic did you not comprehend? Let me try to summarize it again, and then you may tell me which part(s) you need more elaboration on.

1. For a SH peer to sign a TB and have it accepted by the consensus, there must be a determined order for signing. Without a deterministic order, which SH would go first or next? Obviously there must be an order.

2. This order needs to be randomized, otherwise it is possible to game the system.

3. The only way to randomize this order, is for the prospective SH peers to sign a CB, then all those who sign are eligible to be selected to sign TBs in the next CB period. The order of those selected is determined from the entropy of all those signatures on the CB. The first N closest hash keys are selected in a determined order, where N is the number of SHs peers that sign TBs per CB.

All of the above was already presented in upthread discussion between myself and Etlase2.

Now I discovered an insoluble problem.

4. There is no way to generate the signed CB. I quote what I wrote upthread:

But the problem is that there is no way to have consensus on who has signed the CB. If peers (wanting to be SHs on next CB) will separately broadcast their signatures, then who decides which were broadcast within the time limit and compiles it into a CB? If those peers will instead sign a CB that was signed by a prior peer until all who want to sign have signed it (within a deadline), the problem is who decides the order that they sign?

There is no possible solution. This is why only Proof-of-Work is viable for achieving consensus.

So we are done. End of story. STOP.

If you can find any holes in the above logic, please tell me.