Obyte: Totally new consensus algorithm + private untraceable payments

[tonych]

But sorry to say the flaw I see in your analysis is that you don't appear to consider the case where a new branch appears (which was formerly hidden by network disruption, propagation delays, or intentionally) which has a sufficiently different set of witnesses from the "current MC" which any particular node analyzed.

There can't be a branch with substantially different set of witnesses.  There are no forks by design.  This is because the stability point can't advance without support of the majority of witnesses named in the previous stability point.  And there is a rule that the set of witnesses in new units should differ from the witness list at the stability point (specified in the new unit) by no more than one mutation.  The rules are really tight, you can't go too far from the witness list at the stability point.

Can't I sign a unit that has as its parent the, differs by 1 witness from the, genesis. Then sign a unit that has as its parent the, differs by 1 more witness from the, unit I signed in the prior sentence. Repeat as necessary. All those witness can be ones I control which I have sign units in my chain. If necessary I can control different addresses to make it appear that many people were using this chain branch.

So I can build a secret chain branch that double-spends one of my units from the public chain, then I release this secret chain branch. Then it is entirely ambiguous which of the double-spends is first and which of the chain branches is the "real" one, i.e. finality was not reached and the "stability" point was not stable.

I repeat that afaics your design is flawed unless you set a static global list of 12 witnesses.

Your second step (bolded) won't work, therefore all subsequent reasoning doesn't hold.
It won't work because it breaks one of protocol rules.
When you compose a new unit, you include a reference to last ball.  Balls are units that became stable (in your view), and last ball is the latest of such balls, AKA last stability point.  The rule says that your witness list must be compatible with that of last ball, and you are breaking this rule by introducing a second mutation.

That means that before introducing a second mutation you have to wait that your first mutation reaches stability, and this is impossible if your chain is secret and the old witnesses can't see it.

[1714133983]

1714133983

[1714133983]

1714133983

[iamnotback]

But sorry to say the flaw I see in your analysis is that you don't appear to consider the case where a new branch appears (which was formerly hidden by network disruption, propagation delays, or intentionally) which has a sufficiently different set of witnesses from the "current MC" which any particular node analyzed.

There can't be a branch with substantially different set of witnesses.  There are no forks by design.  This is because the stability point can't advance without support of the majority of witnesses named in the previous stability point.  And there is a rule that the set of witnesses in new units should differ from the witness list at the stability point (specified in the new unit) by no more than one mutation.  The rules are really tight, you can't go too far from the witness list at the stability point.

Can't I sign a unit that has as its parent the, differs by 1 witness from the, genesis. Then sign a unit that has as its parent the, differs by 1 more witness from the, unit I signed in the prior sentence. Repeat as necessary. All those witness can be ones I control which I have sign units in my chain. If necessary I can control different addresses to make it appear that many people were using this chain branch.

So I can build a secret chain branch that double-spends one of my units from the public chain, then I release this secret chain branch. Then it is entirely ambiguous which of the double-spends is first and which of the chain branches is the "real" one, i.e. finality was not reached and the "stability" point was not stable.

I repeat that afaics your design is flawed unless you set a static global list of 12 witnesses.

Your second step (bolded) won't work, therefore all subsequent reasoning doesn't hold.
It won't work because it breaks one of protocol rules.
When you compose a new unit, you include a reference to last ball.  Balls are units that became stable (in your view), and last ball is the latest of such balls, AKA last stability point.  The rule says that your witness list must be compatible with that of last ball, and you are breaking this rule by introducing a second mutation.

That means that before introducing a second mutation you have to wait that your first mutation reaches stability, and this is impossible if your chain is secret and the old witnesses can't see it.

Referring the part I bolded for emphasis, I can Sybil attack with numerous addresses. I can make my secret chain branch appear just as "real" as the public one. I can have millions of "users" on my secret chain branch (which are all controlled by me) with witnesses (which are all controlled by me) that aren't on the public chain branch.

Afaics your design has the "nothing-at-stake" flaw. This is a generalized flaw that applies to most designs that don't use proof-of-work. I suggest you read Vitalik's blogs about this:

https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
https://blog.ethereum.org/2014/07/05/stake/


When I entered Dash's (DarkCoin's) thread and explained to Evan that he had a flaw. He invented masternodes to solve the problem. Dash then became the #1 anonymity coin, because I had helped him early identify a flaw.

[galaxiekyl]

But sorry to say the flaw I see in your analysis is that you don't appear to consider the case where a new branch appears (which was formerly hidden by network disruption, propagation delays, or intentionally) which has a sufficiently different set of witnesses from the "current MC" which any particular node analyzed.

There can't be a branch with substantially different set of witnesses.  There are no forks by design.  This is because the stability point can't advance without support of the majority of witnesses named in the previous stability point.  And there is a rule that the set of witnesses in new units should differ from the witness list at the stability point (specified in the new unit) by no more than one mutation.  The rules are really tight, you can't go too far from the witness list at the stability point.

Can't I sign a unit that has as its parent the, differs by 1 witness from the, genesis. Then sign a unit that has as its parent the, differs by 1 more witness from the, unit I signed in the prior sentence. Repeat as necessary. All those witness can be ones I control which I have sign units in my chain. If necessary I can control different addresses to make it appear that many people were using this chain branch.

So I can build a secret chain branch that double-spends one of my units from the public chain, then I release this secret chain branch. Then it is entirely ambiguous which of the double-spends is first and which of the chain branches is the "real" one, i.e. finality was not reached and the "stability" point was not stable.

I repeat that afaics your design is flawed unless you set a static global list of 12 witnesses.

Your second step (bolded) won't work, therefore all subsequent reasoning doesn't hold.
It won't work because it breaks one of protocol rules.
When you compose a new unit, you include a reference to last ball.  Balls are units that became stable (in your view), and last ball is the latest of such balls, AKA last stability point.  The rule says that your witness list must be compatible with that of last ball, and you are breaking this rule by introducing a second mutation.

That means that before introducing a second mutation you have to wait that your first mutation reaches stability, and this is impossible if your chain is secret and the old witnesses can't see it.

Referring the part I bolded for emphasis, I can Sybil attack with numerous addresses. I can make my secret chain branch appear just as "real" as the public one. I can have millions of "users" on my secret chain branch (which are all controlled by me) with witnesses (which are all controlled by me) that aren't on the public chain branch.

Afaics your design has the "nothing-at-stake" flaw. This is a generalized flaw that applies to most designs that don't use proof-of-work. I suggest you read Vitalik's blogs about this:

https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
https://blog.ethereum.org/2014/07/05/stake/


When I entered Dash's (DarkCoin's) thread and explained to Evan that he had a flaw. He invented masternodes to solve the problem. Dash then became the #1 anonymity coin, because I had helped him early identify a flaw.

i enter in this discution without experience..but from a logical point of view..i think that "imnotback" raise a probleme of security..because if one user can become full witness..this one can troll her confirmation branch if this one isn't confirmed by witness genese..user can buil her branch of confirmation and rob bytes of other user passing on her branch..If he no longer needs to report to the genese witnesses.



testnet (tn) work good   but i dont undersand..chatbot said distrib starting after 25 december..it isn't the first begin of livenet distrib
  in more chatbot cant check address balance of btc testnet..i suppose this is normal ?!

[tonych]

Typical multi-sig and smart contracts are not going to grow the size of transaction by orders of magnitude.

I am calculating ~2000 bytes per Ethereum transaction and that is diluted since not all of those are smart contracts. I figure 10,000 bytes per smart contract might be the average, which is an order-of-magnitude higher than your example. And we are concerned here not with the average, but the outlier transaction that becomes uneconomic to do. So that might be 100,000 bytes.

It is not Ethereum.  Byteball smart contracts are neither as advanced nor as big.

And I don't see much use of Byteball in microtransactions, in particular because we don't address the blockchain bloat (or rather ledger bloat) problem.

Okay but the gas payment of a smart contract is typically a microtransaction.

There are no separate transactions to pay solely for "gas".  The payment of the fee is included in every unit.

Their external reputation may still have the same value even if they profit by attacking, destroying, and shorting on the exchanges some two-bit altcoin.

I don't think reputation works this way.  And if somebody holds the belief that he can betray trust and profit from attacking a two-cent coin and nothing happens, he is not going to be chosen as witness.

Also there is probably also a tradeoff in that the lower the value of the fees for witnesses at low market caps, then perhaps the more incentive witnesses have to game and attack the system. That is getting into what I alluded to by "nothing-at-stake".

That would be true if the ability to earn fees were the only witness' stake.  But it isn't.  As I said, the stake is outside the system, it is the reputation, the trust, the business that a witness has in the real world and would damage if it were to misbehave.

But their reputation on the coin itself is only as valuable as the fees they can earn with that reputation. Their external reputation may still have the same value even if they profit by attacking, destroying, and shorting on the exchanges some two-bit altcoin. They don't have any huge stake in the coin itself, neither in the form of mining hardware investment nor in the form of opportunity cost of huge future fees forsaken. I am not going to waste my time arguing with someone who isn't well versed/experienced with economics. You asked me to present the flaws I see, so I have presented. I see no benefit to arguing. Either we can agree on rational truth, or not. I will submit if you provide a truthful and compelling argument. Otherwise it means I think you are incorrect.

Imagine you have a $100bn business, then Byteball comes along and you get involved to some extent, but it is still a small part of your business.  Somehow, people come to believe that you are trustworthy enough, and they name you a witness.  Will you try to game the system?

[tonych]

But sorry to say the flaw I see in your analysis is that you don't appear to consider the case where a new branch appears (which was formerly hidden by network disruption, propagation delays, or intentionally) which has a sufficiently different set of witnesses from the "current MC" which any particular node analyzed.

There can't be a branch with substantially different set of witnesses.  There are no forks by design.  This is because the stability point can't advance without support of the majority of witnesses named in the previous stability point.  And there is a rule that the set of witnesses in new units should differ from the witness list at the stability point (specified in the new unit) by no more than one mutation.  The rules are really tight, you can't go too far from the witness list at the stability point.

Can't I sign a unit that has as its parent the, differs by 1 witness from the, genesis. Then sign a unit that has as its parent the, differs by 1 more witness from the, unit I signed in the prior sentence. Repeat as necessary. All those witness can be ones I control which I have sign units in my chain. If necessary I can control different addresses to make it appear that many people were using this chain branch.

So I can build a secret chain branch that double-spends one of my units from the public chain, then I release this secret chain branch. Then it is entirely ambiguous which of the double-spends is first and which of the chain branches is the "real" one, i.e. finality was not reached and the "stability" point was not stable.

I repeat that afaics your design is flawed unless you set a static global list of 12 witnesses.

Your second step (bolded) won't work, therefore all subsequent reasoning doesn't hold.
It won't work because it breaks one of protocol rules.
When you compose a new unit, you include a reference to last ball.  Balls are units that became stable (in your view), and last ball is the latest of such balls, AKA last stability point.  The rule says that your witness list must be compatible with that of last ball, and you are breaking this rule by introducing a second mutation.

That means that before introducing a second mutation you have to wait that your first mutation reaches stability, and this is impossible if your chain is secret and the old witnesses can't see it.

Referring the part I bolded for emphasis, I can Sybil attack with numerous addresses. I can make my secret chain branch appear just as "real" as the public one. I can have millions of "users" on my secret chain branch (which are all controlled by me) with witnesses (which are all controlled by me) that aren't on the public chain branch.

Please re-read the part you did not bold, is it clear?
You can have millions of "users" on your secret branch but how would you make it appear more "real"?  Remember, you can't advance the stability point on your secret branch, hence you can't replace more than one witness with yours.  Let me know if anything's still unclear.

[iamnotback]

There are no separate transactions to pay solely for "gas".  The payment of the fee is included in every unit.

And some smart contracts will only represent a micropayment of value on each execution transaction.

Imagine you have a $100bn business, then Byteball comes along and you get involved to some extent, but it is still a small part of your business.  Somehow, people come to believe that you are trustworthy enough, and they name you a witness.  Will you try to game the system?

Flies are attracted to honey because they need to eat. Billionaires are not attacted to be paltry paid witnesses for altcoins.

A power vacuum is filled by the most ruthless and best liar. Observe politics.

Some Iron Laws of Political Economics (written by a guy with a 160 IQ who happens to be the one who invented the term "open source").

[iamnotback]

But sorry to say the flaw I see in your analysis is that you don't appear to consider the case where a new branch appears (which was formerly hidden by network disruption, propagation delays, or intentionally) which has a sufficiently different set of witnesses from the "current MC" which any particular node analyzed.

There can't be a branch with substantially different set of witnesses.  There are no forks by design.  This is because the stability point can't advance without support of the majority of witnesses named in the previous stability point.  And there is a rule that the set of witnesses in new units should differ from the witness list at the stability point (specified in the new unit) by no more than one mutation.  The rules are really tight, you can't go too far from the witness list at the stability point.

Can't I sign a unit that has as its parent the, differs by 1 witness from the, genesis. Then sign a unit that has as its parent the, differs by 1 more witness from the, unit I signed in the prior sentence. Repeat as necessary. All those witness can be ones I control which I have sign units in my chain. If necessary I can control different addresses to make it appear that many people were using this chain branch.

So I can build a secret chain branch that double-spends one of my units from the public chain, then I release this secret chain branch. Then it is entirely ambiguous which of the double-spends is first and which of the chain branches is the "real" one, i.e. finality was not reached and the "stability" point was not stable.

I repeat that afaics your design is flawed unless you set a static global list of 12 witnesses.

Your second step (bolded) won't work, therefore all subsequent reasoning doesn't hold.
It won't work because it breaks one of protocol rules.
When you compose a new unit, you include a reference to last ball.  Balls are units that became stable (in your view), and last ball is the latest of such balls, AKA last stability point.  The rule says that your witness list must be compatible with that of last ball, and you are breaking this rule by introducing a second mutation.

That means that before introducing a second mutation you have to wait that your first mutation reaches stability, and this is impossible if your chain is secret and the old witnesses can't see it.

Referring the part I bolded for emphasis, I can Sybil attack with numerous addresses. I can make my secret chain branch appear just as "real" as the public one. I can have millions of "users" on my secret chain branch (which are all controlled by me) with witnesses (which are all controlled by me) that aren't on the public chain branch.

Please re-read the part you did not bold, is it clear?
You can have millions of "users" on your secret branch but how would you make it appear more "real"?  Remember, you can't advance the stability point on your secret branch, hence you can't replace more than one witness with yours.  Let me know if anything's still unclear.

If what you are claiming (for your protocol design) is that a majority of the 11 old witnesses have to sign units on my secret chain for it to advance in terms of the stability point (i.e. that you don't let me select new witnesses when the old ones fail to sign), then the problem shifts to one where if 6 of 12 witnesses stop signing (or don't sign enough to provide convergence to a total order) then the stability point never moves forward in the entire system (not just on my secret chain). The entire Byteball system can become suck and nothing can become final.

Either way, it is a flaw. So which is your choice of poison in your design?


Edit: also I can devise an attack to side-step your protocol rule. Build a chain branch that has no double-spends and make it public. Gradually change my list of witnesses one-by-one on the units I sign as the old witness happily sign units on my chain branch to advance the stability point. I can spam with as many Sybil address signed units as necessary to convince the witnesses that my chain branch is "real". Then once I've got the old witness down to a minority, I can take my chain branch private and complete the attack I explained to you before.

[cryptohunter]

Many people complain about limiting to the "richest" people, why so? in real life the people have more money will be easier to make more than those with less money. It's not really the unfairness.

It's not really unfair? like provable math wise or you mean just average people common sense wise? sometimes you have to see through the eyes of the average person who will reason without doubt that rewarding those that are already super rich with the lions share is not fair at all.

If you wish to start a poll on the main board discussing it and sampling opinion then go ahead. I am certain you will not find many in the alt section will share your views. Since your main initial market will be the altcoin traders then this is the market that is important to you.

This has been discussed MANY time before in the alt main board and the vast majority are very much against new coins being distributed like this.

Without nulling the top 2-5% of BTC wallets you can ensure this will have the "unfair" tag attached to it in the future. It is a major criticism which has been voiced in this thread a great many times already. Why not eliminate this criticism or reduce it and not have to beg the big icos and exchanges to do the right thing. The random snapshots will stop them breaking down their wallets to smaller amounts.

The only thing here is the dev can not be accused of gaming it for his gain especially since unless he is a btc super whale or has agreements with those that control a substantial amount of BTC then he could end up having less than any whales that decide to claim or any exchange that does not play ball. Not sure either of those things is a great scenario. The worst aspect for him really is having other large ICO funds dumping BB on the exchanges to fund rival projects. I mean jl777 saying he will not pocket the money but rather fund komodo with it is fair enough what else could he do other than not claim (if he even said this anyway) but how is that good for BB?

[tonych]

But sorry to say the flaw I see in your analysis is that you don't appear to consider the case where a new branch appears (which was formerly hidden by network disruption, propagation delays, or intentionally) which has a sufficiently different set of witnesses from the "current MC" which any particular node analyzed.

There can't be a branch with substantially different set of witnesses.  There are no forks by design.  This is because the stability point can't advance without support of the majority of witnesses named in the previous stability point.  And there is a rule that the set of witnesses in new units should differ from the witness list at the stability point (specified in the new unit) by no more than one mutation.  The rules are really tight, you can't go too far from the witness list at the stability point.

Can't I sign a unit that has as its parent the, differs by 1 witness from the, genesis. Then sign a unit that has as its parent the, differs by 1 more witness from the, unit I signed in the prior sentence. Repeat as necessary. All those witness can be ones I control which I have sign units in my chain. If necessary I can control different addresses to make it appear that many people were using this chain branch.

So I can build a secret chain branch that double-spends one of my units from the public chain, then I release this secret chain branch. Then it is entirely ambiguous which of the double-spends is first and which of the chain branches is the "real" one, i.e. finality was not reached and the "stability" point was not stable.

I repeat that afaics your design is flawed unless you set a static global list of 12 witnesses.

Your second step (bolded) won't work, therefore all subsequent reasoning doesn't hold.
It won't work because it breaks one of protocol rules.
When you compose a new unit, you include a reference to last ball.  Balls are units that became stable (in your view), and last ball is the latest of such balls, AKA last stability point.  The rule says that your witness list must be compatible with that of last ball, and you are breaking this rule by introducing a second mutation.

That means that before introducing a second mutation you have to wait that your first mutation reaches stability, and this is impossible if your chain is secret and the old witnesses can't see it.

Referring the part I bolded for emphasis, I can Sybil attack with numerous addresses. I can make my secret chain branch appear just as "real" as the public one. I can have millions of "users" on my secret chain branch (which are all controlled by me) with witnesses (which are all controlled by me) that aren't on the public chain branch.

Please re-read the part you did not bold, is it clear?
You can have millions of "users" on your secret branch but how would you make it appear more "real"?  Remember, you can't advance the stability point on your secret branch, hence you can't replace more than one witness with yours.  Let me know if anything's still unclear.

If what you are claiming (for your protocol design) is that a majority of the 11 old witnesses have to sign units on my secret chain for it to advance in terms of the stability point (i.e. that you don't let me select new witnesses when the old ones fail to sign), ....

That's correct, I'm glad it is clear now.

... then the problem shifts to one where if 6 of 12 witnesses stop signing (or don't sign enough to provide convergence to a total order) then the stability point never moves forward in the entire system (not just on my secret chain). The entire Byteball system can become suck and nothing can become final.

Either way, it is a flaw. So which is your choice of poison in your design?

To address this issue, we have sufficiently large number of witnesses, so that we can afford to lose 5 witnesses and still continue operation.
If we lose 6 or more, all at the same time, yes we become stuck.
Remember, witnesses are elected for a number of criteria, and one of them is that the would-be witness is not going to disappear suddenly.  Even if this happens, the community has a chance to replace the inactive witness before another such failure.

Edit: also I can devise an attack to side-step your protocol rule. Build a chain branch that has no double-spends and make it public. Gradually change my list of witnesses one-by-one on the units I sign as the old witness happily sign units on my chain branch to advance the stability point. I can spam with as many Sybil address signed units as necessary to convince the witnesses that my chain branch is "real". Then once I've got the old witness down to a minority, I can take my chain branch private and complete the attack I explained to you before.

Again, seems like you are assuming you can convince somebody with the number of your Sybil units.  And not just somebody -- the acting witnesses.  The acting witnesses, and other users likewise, are not going to change their own witness lists to stay compatible with your Sybil units.  Your Sybil units will be accepted into the DAG, but, being incompatible, they are not going to be selected as best parent, hence they have no chance to appear on the MC, hence none of them can ever become last ball (which necessarily lies on MC).

[iamnotback]

Until convinced otherwise, I have the following description of Byteball in my white paper. I will edit this according to any insight gained from here forward. Readers please be aware this summary is subject to change (and thus may or may not be correct).

Byteball is a DAG of vertices named “units”, each which reference parent ancestor units. Units are either transaction events or delegate witness events. The DAG is effectively a variant of Transactions as Proof-of-Stake (TaPoS) as explained in section “2. Database structure” on page 5 of the Byteball whitepaper— a variant which doesn't require synchrony on additions to the database as explained in the same section on page 4. Each transaction event unit lists a set of 12 delegate witnesses which are the authority for selecting the “best parent” total order “main chain” from amongst all possible partial order chains in the parent DAG history of the said unit. W.r.t. to finality of transaction events, this set is only allowed to change by 1 delegate until a majority of the said 12 delegates have witnessed the main chain of the descendent children of the said unit. Finality of consensus is analogous to the end of an epoch and beginning of the next one. Byteball has either a security vulnerability that renders finality impossible or risks finality becoming stuck requiring a hardfork to rectify (and unlike DPoS there can't be an election to replace delegates).

Byteball doesn't employ proof-of-work to select the set of delegate witnesses nor to form a longest chain of consensus, because witness units are supposed to provide finality (but note the alleged vulnerability). Similar to Satoshi's proof-of-work, transaction fees are employed to prevent spamming and a portion is paid to delegate witnesses (and perhaps the payer portion is effectively burned as it is passed along?). These fees are not allowed to vary per some competing service providers in a free market; and instead per section “1. Introduction: Exchange rate” on page 3 are tied to the system wide exchange value of adding bytes to the database. Byteball has the incorrect monetary theory, because the confidence in and thus the value of money is greater the higher the senioriage[Armstrong]. This fixed fee design makes it uneconomic to issue some transaction events when the exchange price (and thus market capitalization) is too high or inadequate spam resistance when the exchange price is too low.

Additionally, it is unlikely that Byteball's 12 delegate witnesses won't become an entrenched monopoly because politics are power vacuums that attract the most cunning, ruthless, best liars; and because the voters would have to agree to only change one per epoch, yet large groups rarely attain 92% agreement on anything. Also the Byteball whitepaper admits in section “17. Choosing witnesses” on page 20 that it will depend on some trusted community servers providing advice on which witness to vote for, yet there doesn't appear to be sufficient objectivity in the design for community observers to even objectively detect and prove in every instance which delegate witnesses are misbehaving. The signatories of units necessarily being light clients for scaling and since they can't be online always are trusting “proofs” from witnesses they trust, thus aren't two-factor validation security.

[Armstrong] https://bitcointalk.org/index.php?topic=1665943.msg16749910#msg16749910

[iamnotback]

Edit: also I can devise an attack to side-step your protocol rule. Build a chain branch that has no double-spends and make it public. Gradually change my list of witnesses one-by-one on the units I sign as the old witness happily sign units on my chain branch to advance the stability point. I can spam with as many Sybil address signed units as necessary to convince the witnesses that my chain branch is "real". Then once I've got the old witness down to a minority, I can take my chain branch private and complete the attack I explained to you before.

Again, seems like you are assuming you can convince somebody with the number of your Sybil units.  And not just somebody -- the acting witnesses.  The acting witnesses, and other users likewise, are not going to change their own witness lists to stay compatible with your Sybil units.  Your Sybil units will be accepted into the DAG, but, being incompatible, they are not going to be selected as best parent, hence they have no chance to appear on the MC, hence none of them can ever become last ball (which necessarily lies on MC).

Okay so you are telling me that the current witnesses on the branch I am trying to create have to agree with 11 of 12 with my list of witnesses when they sign units on my branch? So this means the entire system has to agree on the same 12 witnesses for all main chains for the entire system?

If that is your design, then yes you can prevent my attack but at the cost of having 12 very entrenched witnesses which can never be migrated away from because political action never reaches 92% agreement.

So why not just use 12 federated servers and name this Visa, Mastercard, or Paypal instead? No need for the facade of a DAG nor to claim/insinuate by association to our Satoshi ecosystem that it is decentralized. Distributed is not same as decentralized.

[tonych]

Edit: also I can devise an attack to side-step your protocol rule. Build a chain branch that has no double-spends and make it public. Gradually change my list of witnesses one-by-one on the units I sign as the old witness happily sign units on my chain branch to advance the stability point. I can spam with as many Sybil address signed units as necessary to convince the witnesses that my chain branch is "real". Then once I've got the old witness down to a minority, I can take my chain branch private and complete the attack I explained to you before.

Again, seems like you are assuming you can convince somebody with the number of your Sybil units.  And not just somebody -- the acting witnesses.  The acting witnesses, and other users likewise, are not going to change their own witness lists to stay compatible with your Sybil units.  Your Sybil units will be accepted into the DAG, but, being incompatible, they are not going to be selected as best parent, hence they have no chance to appear on the MC, hence none of them can ever become last ball (which necessarily lies on MC).

Okay so you are telling me that the current witnesses on the branch I am trying to create have to agree with 11 of 12 with my list of witnesses when they sign units on my branch? So this means the entire system has to agree on the same 12 witnesses for all main chains for the entire system?

If that is your design, then yes you can prevent my attack but at the cost of having 12 very entrenched witnesses which can never be migrated away from because political action never reaches 92% agreement.

So why not just use 12 federated servers and name this Visa, Mastercard, or Paypal instead? No need for the facade of a DAG nor to claim/insinuate by association to our Satoshi ecosystem that it is decentralized. Distributed is not same as decentralized.

How have you come to "the same 12 witnesses"?
To be eligible for inclusion on the MC, you have to agree about 11 witnesses, not 12 (1 mutation allowed).
For a change of the witness list to reach stability, support of the majority, that is 7 out of 12, or 58% witnesses is required.

[szafa]

Can i send back btc when i confirm this is my btc?

[marseille]

Many people complain about limiting to the "richest" people, why so? in real life the people have more money will be easier to make more than those with less money. It's not really the unfairness.

It's not really unfair? like provable math wise or you mean just average people common sense wise? sometimes you have to see through the eyes of the average person who will reason without doubt that rewarding those that are already super rich with the lions share is not fair at all.

If you wish to start a poll on the main board discussing it and sampling opinion then go ahead. I am certain you will not find many in the alt section will share your views. Since your main initial market will be the altcoin traders then this is the market that is important to you.

This has been discussed MANY time before in the alt main board and the vast majority are very much against new coins being distributed like this.

Without nulling the top 2-5% of BTC wallets you can ensure this will have the "unfair" tag attached to it in the future. It is a major criticism which has been voiced in this thread a great many times already. Why not eliminate this criticism or reduce it and not have to beg the big icos and exchanges to do the right thing. The random snapshots will stop them breaking down their wallets to smaller amounts.

The only thing here is the dev can not be accused of gaming it for his gain especially since unless he is a btc super whale or has agreements with those that control a substantial amount of BTC then he could end up having less than any whales that decide to claim or any exchange that does not play ball. Not sure either of those things is a great scenario. The worst aspect for him really is having other large ICO funds dumping BB on the exchanges to fund rival projects. I mean jl777 saying he will not pocket the money but rather fund komodo with it is fair enough what else could he do other than not claim (if he even said this anyway) but how is that good for BB?

Most new people in this game, wish to get as much as possible. But how do you argue with rich people in real life? Rich people gets money easier as compare to us. this is life. Here Tony wants to distribute the coins in a fair and relative simple way, based on BTC it is a fair way. You can argue for days why not use Litecoin, why not Ethereum, why not combine all altcoins, why not check all my US$, this does not make sense to me.

[valley365]

From the white paper it seems that the introduction of witness is to do some sort of automatic check points, do I understand correctly? Many coins do manual checkpoint by releasing new software. If we have another automatic way to checkpoint the existing DAG, then witness should no longer be needed.

Yes, there is some similarity with checkpoints, with important differences though that make the system decentralized:
1.  There are 12 "checkpointing authorities", not 1
2.  Each and every witness can be replaced by users, without developer intervention

But do you have a mechanism for ensuring that most users will have the same witnesses? If you let people to choose randomly, it will not be good. As if I am let to choose all by myself, I'd probably make a list of my friends which I trust the most.

Yes.  When you create a new transaction, you choose parents - earlier transactions in the DAG.  At least 1 of the parents must have the witness list that differs from yours by no more than 1 mutation.  That means that users should mostly agree on the witness list.  The white paper discusses this issue in depth.

What happens if I can't find such parent, the transaction fails? Also as a user, how do I choose witness? if I have full control of the list, then there's no guarantee that I can choose most the same as others.

If you can't find such parent, you can't send any transaction.  But remember, although it is the default behavior to choose parents among the most recent childless units, you don't have to behave this way, you can also choose an older parent if it is compatible with your witness list.

You edit your witness list in your wallet.  Obviously, having full control also means being able to hurt yourself (not fatally, though).

Then there will be a high probability that the system can't find 11 matching, if you give the right to everyone to edit his list freely. A better way is possibly the byteball website provide a list of say, 20 witness, that everyone can randomly pick 12 out of it. If you let people to choose randomly, then I can see it will be easily mismatch and your 11/12 rule may not work.

[HI-TEC99]

Many people complain about limiting to the "richest" people, why so? in real life the people have more money will be easier to make more than those with less money. It's not really the unfairness.

It's not really unfair? like provable math wise or you mean just average people common sense wise? sometimes you have to see through the eyes of the average person who will reason without doubt that rewarding those that are already super rich with the lions share is not fair at all.

If you wish to start a poll on the main board discussing it and sampling opinion then go ahead. I am certain you will not find many in the alt section will share your views. Since your main initial market will be the altcoin traders then this is the market that is important to you.

This has been discussed MANY time before in the alt main board and the vast majority are very much against new coins being distributed like this.

Without nulling the top 2-5% of BTC wallets you can ensure this will have the "unfair" tag attached to it in the future. It is a major criticism which has been voiced in this thread a great many times already. Why not eliminate this criticism or reduce it and not have to beg the big icos and exchanges to do the right thing. The random snapshots will stop them breaking down their wallets to smaller amounts.

The only thing here is the dev can not be accused of gaming it for his gain especially since unless he is a btc super whale or has agreements with those that control a substantial amount of BTC then he could end up having less than any whales that decide to claim or any exchange that does not play ball. Not sure either of those things is a great scenario. The worst aspect for him really is having other large ICO funds dumping BB on the exchanges to fund rival projects. I mean jl777 saying he will not pocket the money but rather fund komodo with it is fair enough what else could he do other than not claim (if he even said this anyway) but how is that good for BB?

Agreed, the dev should eliminate all the Bitcoin wallets from the big icos and exchanges from the snapshots. Most of those addresses are public, and strictly speaking the exchanges don't own the coins in their cold wallets, their customers own them. The ico addresses have already made their devs millionaires, they don't need more money from BYTEBALL to fund development of their coins.

[valley365]

Many people complain about limiting to the "richest" people, why so? in real life the people have more money will be easier to make more than those with less money. It's not really the unfairness.

It's not really unfair? like provable math wise or you mean just average people common sense wise? sometimes you have to see through the eyes of the average person who will reason without doubt that rewarding those that are already super rich with the lions share is not fair at all.

If you wish to start a poll on the main board discussing it and sampling opinion then go ahead. I am certain you will not find many in the alt section will share your views. Since your main initial market will be the altcoin traders then this is the market that is important to you.

This has been discussed MANY time before in the alt main board and the vast majority are very much against new coins being distributed like this.

Without nulling the top 2-5% of BTC wallets you can ensure this will have the "unfair" tag attached to it in the future. It is a major criticism which has been voiced in this thread a great many times already. Why not eliminate this criticism or reduce it and not have to beg the big icos and exchanges to do the right thing. The random snapshots will stop them breaking down their wallets to smaller amounts.

The only thing here is the dev can not be accused of gaming it for his gain especially since unless he is a btc super whale or has agreements with those that control a substantial amount of BTC then he could end up having less than any whales that decide to claim or any exchange that does not play ball. Not sure either of those things is a great scenario. The worst aspect for him really is having other large ICO funds dumping BB on the exchanges to fund rival projects. I mean jl777 saying he will not pocket the money but rather fund komodo with it is fair enough what else could he do other than not claim (if he even said this anyway) but how is that good for BB?

How can you "nulling the top 2-5% of BTC wallets"? If you do so, people can easily split BTCs into different wallets and make the requests, you won't be able to achieve your goal at all.

To your other point, I am sure a lot people when receiving bytes will dump it in exchange. That's why paying in stages like Tony suggested will help (a little). Whether people dump the coin or not depends on their assessment/impression whether the coin has potential or not. That's why a dev roadmap and plan will be helpful. We need to make it a platform with other apps, and develop various things on top of it, when people see the potential of the coin, they won't dump (or at least not as much).

[tonych]

From the white paper it seems that the introduction of witness is to do some sort of automatic check points, do I understand correctly? Many coins do manual checkpoint by releasing new software. If we have another automatic way to checkpoint the existing DAG, then witness should no longer be needed.

Yes, there is some similarity with checkpoints, with important differences though that make the system decentralized:
1.  There are 12 "checkpointing authorities", not 1
2.  Each and every witness can be replaced by users, without developer intervention

But do you have a mechanism for ensuring that most users will have the same witnesses? If you let people to choose randomly, it will not be good. As if I am let to choose all by myself, I'd probably make a list of my friends which I trust the most.

Yes.  When you create a new transaction, you choose parents - earlier transactions in the DAG.  At least 1 of the parents must have the witness list that differs from yours by no more than 1 mutation.  That means that users should mostly agree on the witness list.  The white paper discusses this issue in depth.

What happens if I can't find such parent, the transaction fails? Also as a user, how do I choose witness? if I have full control of the list, then there's no guarantee that I can choose most the same as others.

If you can't find such parent, you can't send any transaction.  But remember, although it is the default behavior to choose parents among the most recent childless units, you don't have to behave this way, you can also choose an older parent if it is compatible with your witness list.

You edit your witness list in your wallet.  Obviously, having full control also means being able to hurt yourself (not fatally, though).

Then there will be a high probability that the system can't find 11 matching, if you give the right to everyone to edit his list freely. A better way is possibly the byteball website provide a list of say, 20 witness, that everyone can randomly pick 12 out of it. If you let people to choose randomly, then I can see it will be easily mismatch and your 11/12 rule may not work.

Well, the list was editable from day one, and nobody has complained yet.

[HI-TEC99]

Many people complain about limiting to the "richest" people, why so? in real life the people have more money will be easier to make more than those with less money. It's not really the unfairness.

It's not really unfair? like provable math wise or you mean just average people common sense wise? sometimes you have to see through the eyes of the average person who will reason without doubt that rewarding those that are already super rich with the lions share is not fair at all.

If you wish to start a poll on the main board discussing it and sampling opinion then go ahead. I am certain you will not find many in the alt section will share your views. Since your main initial market will be the altcoin traders then this is the market that is important to you.

This has been discussed MANY time before in the alt main board and the vast majority are very much against new coins being distributed like this.

Without nulling the top 2-5% of BTC wallets you can ensure this will have the "unfair" tag attached to it in the future. It is a major criticism which has been voiced in this thread a great many times already. Why not eliminate this criticism or reduce it and not have to beg the big icos and exchanges to do the right thing. The random snapshots will stop them breaking down their wallets to smaller amounts.

The only thing here is the dev can not be accused of gaming it for his gain especially since unless he is a btc super whale or has agreements with those that control a substantial amount of BTC then he could end up having less than any whales that decide to claim or any exchange that does not play ball. Not sure either of those things is a great scenario. The worst aspect for him really is having other large ICO funds dumping BB on the exchanges to fund rival projects. I mean jl777 saying he will not pocket the money but rather fund komodo with it is fair enough what else could he do other than not claim (if he even said this anyway) but how is that good for BB?

How can you "nulling the top 2-5% of BTC wallets"? If you do so, people can easily split BTCs into different wallets and make the requests, you won't be able to achieve your goal at all.

The big icos often have their Bitcoins locked in multisig wallets that the devs agreed to keep their coins in. They agreed not to move Bitcoins out of those addresses without permission from their communities. However, they can easily use those addresses to claim BB, they made no agreement with their communities about claiming BB with their ico addresses.

Our dev could easily miss out the waves, lisk, and komodo ico addresses, and those coin's devs can't move Bitcoins out of them without breaking the promises they made to their communities.

[iamnotback]

Edit: also I can devise an attack to side-step your protocol rule. Build a chain branch that has no double-spends and make it public. Gradually change my list of witnesses one-by-one on the units I sign as the old witness happily sign units on my chain branch to advance the stability point. I can spam with as many Sybil address signed units as necessary to convince the witnesses that my chain branch is "real". Then once I've got the old witness down to a minority, I can take my chain branch private and complete the attack I explained to you before.

Again, seems like you are assuming you can convince somebody with the number of your Sybil units.  And not just somebody -- the acting witnesses.  The acting witnesses, and other users likewise, are not going to change their own witness lists to stay compatible with your Sybil units.  Your Sybil units will be accepted into the DAG, but, being incompatible, they are not going to be selected as best parent, hence they have no chance to appear on the MC, hence none of them can ever become last ball (which necessarily lies on MC).

Okay so you are telling me that the current witnesses on the branch I am trying to create have to agree with 11 of 12 with my list of witnesses when they sign units on my branch? So this means the entire system has to agree on the same 12 witnesses for all main chains for the entire system?

If that is your design, then yes you can prevent my attack but at the cost of having 12 very entrenched witnesses which can never be migrated away from because political action never reaches 92% agreement.

So why not just use 12 federated servers and name this Visa, Mastercard, or Paypal instead? No need for the facade of a DAG nor to claim/insinuate by association to our Satoshi ecosystem that it is decentralized. Distributed is not same as decentralized.

How have you come to "the same 12 witnesses"?
To be eligible for inclusion on the MC, you have to agree about 11 witnesses, not 12 (1 mutation allowed).
For a change of the witness list to reach stability, support of the majority, that is 7 out of 12, or 58% witnesses is required.

To reach any significant mutation seems highly improbable.

For example to get 2 mutations, we need 1 of the 11 witness at the last stability point to agree with 1 of the 2 of the mutations we want to make. To get 3 mutations, we need that prior sentence plus 1 of the other 10 witness from the starting stability point to agree with 2 of the 3 mutations we want to make. To get 4 mutations, we need that prior sentence plus 1 of the other 9 witness from the starting stability point to agree with 3 of the 4 mutations we want to make. Etc.

Three mutations seems very unlikely unless those two witness were misbehaving, in which case it seems everyone globally will want to get rid of those two witness. But that presumes there can even be an objective truth about misbehavior and that agreement can be reached. Getting 9% of the witnesses to agree on 2 witness to expel and 18% to agree on 1 witness to expel seems improbable.

Four mutations seems to be extremely unlikely, requiring 9% of the witnesses to agree on 3 witness to expel, 18% to agree on 2 witnesses to expel, and 27% to agree on 1 witness to expel.

And that presumes that the replacements for those expelled witnesses agree with the subsequent mutations. So actually the odds are worse than I just stated. Four mutations actually requires 14% of the witnesses to agree on 3 witness to expel, 27% to agree on 2 witnesses to expel, and 41% to agree on 1 witness to expel.

If there is indeed a proliferation of witnesses, who in the heck is going to have any confidence that a majority of some set of 12 (of the multitudes of such sets) won't go defunct leaving all those addresses (money!) in limbo forever. The cognitive load and worry on the users is unfathomable.

The state of this system will either solidify on 12 witness every where which are highly trusted, or it will devolve into Swiss cheese. You still don't seem to understand the most basic element of monetary theory, which is that the value of money is solely based on the CONFIDENCE that it can be spent later and someone will accept it.

Rube Goldberg machines are intentionally more clever than they need to be.