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. |
|
|
|
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. |
|
|
|
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). |
|
|
|
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. |
|
|
|
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? |
|
|
|
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. |
|
|
|
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. |
|
|
|
Byteball spends transaction fees to the witnesses (and perhaps the payer portion is effectively burned as it is passed along?) instead of employing proof-of-work (but I am not yet clear if this is used as the metric of the chain length in any way in consensus algorithm).. These fees per section “1. Introduction: Exchange rate” on page 3 are tied to the system wide exchange value of adding bytes to the database.
Furthermore, I am sorry to say that my analysis is that once the exchange price has risen high enough, the transaction fee will exceed the value of the transaction and so the transaction can't be economic. This appears to break the coin. The transaction fee is equal to transaction size. How can it be related to the exchange price? Because the bytes being spent in the transaction have an exchange value. As the exchange value rises, then the quantity of bytes that will be transacted will decrease. When it decreases below the size of the transaction, the transaction is no longer economic. Well, while theoretically possible, the valuations need to be quite high for this to happen. The size of a simple transaction is about 500 bytes, let's round it up to 1000 bytes. For this fee to be equal to $1.00, the market cap will have to be $10 12, or $1tn. Okay good point, but the counter point is that we shouldn't assume that all lower valued transactions will be necessarily simple transactions. Let's think multi-sig, smart contracts, etc, then we might see problems at around $10 - $100 billion market. And if those are micropayments (which smart contract gas is for example), then we are getting into potential trouble at $100 million market cap. Typical multi-sig and smart contracts are not going to grow the size of transaction by orders of magnitude. 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. 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. |
|
|
|
Byteball spends transaction fees to the witnesses (and perhaps the payer portion is effectively burned as it is passed along?) instead of employing proof-of-work (but I am not yet clear if this is used as the metric of the chain length in any way in consensus algorithm).. These fees per section “1. Introduction: Exchange rate” on page 3 are tied to the system wide exchange value of adding bytes to the database.
Furthermore, I am sorry to say that my analysis is that once the exchange price has risen high enough, the transaction fee will exceed the value of the transaction and so the transaction can't be economic. This appears to break the coin. The transaction fee is equal to transaction size. How can it be related to the exchange price? Because the bytes being spent in the transaction have an exchange value. As the exchange value rises, then the quantity of bytes that will be transacted will decrease. When it decreases below the size of the transaction, the transaction is no longer economic. Well, while theoretically possible, the valuations need to be quite high for this to happen. The size of a simple transaction is about 500 bytes, let's round it up to 1000 bytes. For this fee to be equal to $1.00, the market cap will have to be $10 12, or $1tn. |
|
|
|
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). |
|
|
|
Byteball spends transaction fees to the witnesses (and perhaps the payer portion is effectively burned as it is passed along?) instead of employing proof-of-work (but I am not yet clear if this is used as the metric of the chain length in any way in consensus algorithm).. These fees per section “1. Introduction: Exchange rate” on page 3 are tied to the system wide exchange value of adding bytes to the database.
Furthermore, I am sorry to say that my analysis is that once the exchange price has risen high enough, the transaction fee will exceed the value of the transaction and so the transaction can't be economic. This appears to break the coin. The transaction fee is equal to transaction size. How can it be related to the exchange price? |
|
|
|
hello @tonych
i check new testnet (tn) but i dont know if i will do good choice..so can yu tell me if it is best to choose full wallet or light wallet..wht do yu recommend ? i can reboot after install it if my choice doesn't satified me ?
I think you'll have the best experience with the light wallet, but the choice is yours. |
|
|
|
Yes I am AnonyMint.
I haven't been reading the thread to see if there are any follow ups.
I am still analyzing your design. I think the main issue is because afaics witnesses have nothing-at-stake and afaics it can't be objectively determined which witnesses are creating units referencing MCs which create ambiguity about whether finality was really final. It may also not be objective which witnesses are mishaving. But I may not yet completely understand the design.
Don't confuse with PoS, witnesses' stakes are outside the system. I mean stake in more general terms of what is at risk in the game theory of attacks not specifically its assumed meaning in PoS, but I need to understand your design better before I can posit anything concrete on that. Any way... I mean exactly the same. I don't understand how you achieve this sentence in Section 6 of the white paper: We would stop traveling as soon as we had encountered the majority of witnesses.
How can you know what the set of witnesses is in the history when the set is allowed to change in time? It is the set of witnesses specified in the unit we started traveling from. |
|
|
|
Yes I am AnonyMint.
I haven't been reading the thread to see if there are any follow ups.
I am still analyzing your design. I think the main issue is because afaics witnesses have nothing-at-stake and afaics it can't be objectively determined which witnesses are creating units referencing MCs which create ambiguity about whether finality was really final. It may also not be objective which witnesses are mishaving. But I may not yet completely understand the design.
Don't confuse with PoS, witnesses' stakes are outside the system. Looks like you want to get a deep understanding of the design, then you have to read the first few sections of the white paper that discuss consensus. |
|
|
|
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. |
|
|
|
 Hello again! Your current linked Bitcoin address is 2MsYNtcpSzcbMMFD24mMmyDiQkP8AtaUp8C. Please make sure that 2MsYNtcpSzcbMMFD24mMmyDiQkP8AtaUp8C is indeed your address and move all your coins to this address. The amount of bytes you receive will be proportional to the total balance of this Bitcoin address on December 25. Current balance of this address is 2.37 BTC. ***************************************************** pls can u kindly confirm the steps ( japanese style "step by step" easy instructions...... ================================================= 1/ send micro payement 2/ get see the btc adress 3/ send micro payment to adress 4/ check balance is updating & at same avoid risk of hacker robing btc 5/ send full amt btc to safe adress 6/ normally BTC just moved around inside the same wallet is this correct  ? 7/ balance of btc will update inside byteball system until a cut off date & time 8/ receive byteball & blackbytes Yes, that's correct. |
|
|
|
hello tonych & gd day frds starting the test Your payment from 2MsYNtcpSzcbMMFD24mMmyDiQkP8AtaUp8C has 1 confirmations now. Please make sure that 2MsYNtcpSzcbMMFD24mMmyDiQkP8AtaUp8C is indeed your address and move all your coins to this address. The amount of bytes you receive will be proportional to the total balance of this Bitcoin address on December 25. Current balance of this address is 0 BTC.***** am using this wallet = http://testnetwallet.com/wallet***** and normally my bal is = My Wallet
2.37195213 Confirmed Balance0.00000000 Unconfirmed Balance ************* seems byteball cannot see my balance coming from this online wallet ; may be its due to level of confirmation or bug of display on the testnetwallet... will let u know Seems like you are confusing wallet and address. Wallet is a collection of multiple addresses, and wallet balance is the sum of balances of all addresses. This address has 0 balance indeed http://tbtc.blockr.io/address/info/2MsYNtcpSzcbMMFD24mMmyDiQkP8AtaUp8C. The bot instructs you to move coins within your wallet to this single address. |
|
|
|
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 |
|
|
|
What happens if you send bitcoins from an exchange ?
For verifying your Address? Yes ?! Hmm first I thought that's stupid. But when I think about it... It depends on the Exchange's wallet System. But maybe you could link their wallet to your Account. tonych? If an exchange reuses the same address as its hot wallet, you could try. But you will not be alone. |
|
|
|
|
Show Posts
