Bitcoin Forum
December 12, 2024, 11:39:03 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 [57] 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 ... 1126 »
  Print  
Author Topic: Obyte: Totally new consensus algorithm + private untraceable payments  (Read 1234305 times)
tonych (OP)
Legendary
*
Offline Offline

Activity: 965
Merit: 1033


View Profile WWW
November 13, 2016, 11:50:11 PM
 #1121

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

The system is designed based on assumption that the prevailing witness list is nearly static and evolves slowly.  Most often, we'll need to replace just one witness at a time, and before we need to replace another witness, the first change has more than enough time to diffuse into the system, so that when we replace the next witness we are doing just one mutation again. 

The need to replace more than one witness simultaneously is extremely rare, but still possible, and when it happens someone will have to coordinate the process so that users replace one of the defunct witnesses first, and soon after that, after the first change reaches stability point, they go on to replace the next witness.  This is not quite convenient, can prove chaotic at times, and requires a degree of short term centralization, but no system works optimally in all sorts of edge cases that one can reasonably believe are quite rare to happen.

Simplicity is beauty
valley365
Hero Member
*****
Offline Offline

Activity: 868
Merit: 1003


View Profile
November 14, 2016, 12:21:30 AM
 #1122



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.

If the accounts are locked, how do they make the micro payment to confirm their address? they can't obtain the signature from their escrow in this case.
iamnotback
Sr. Member
****
Offline Offline

Activity: 336
Merit: 265



View Profile
November 14, 2016, 12:23:04 AM
 #1123

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

The system is designed based on assumption that the prevailing witness list is nearly static and evolves slowly.  Most often, we'll need to replace just one witness at a time, and before we need to replace another witness, the first change has more than enough time to diffuse into the system, so that when we replace the next witness we are doing just one mutation again.  

The need to replace more than one witness simultaneously is extremely rare, but still possible, and when it happens someone will have to coordinate the process so that users replace one of the defunct witnesses first, and soon after that, after the first change reaches stability point, they go on to replace the next witness.  This is not quite convenient, can prove chaotic at times, and requires a degree of short term centralization, but no system works optimally in all sorts of edge cases that one can reasonably believe are quite rare to happen.

Okay so basically as I said, same 12 witnesses globally (over long-term time window) unless some extraordinary global political will and consensus exists to replace 1 witness then again same 12 witnesses over long-term time window.

It seems the main advantage this has over Bitshares' DPoS+TaPoS is the asynchrony of the DAG and that exchanges can't vote for the witnesses. But I think DPoS normally has 100 witnesses, or at least it was 20 or so for Steem. And DPoS is in control of the whales so they can bypass politics to change witnesses quickly.
zanzibar
Hero Member
*****
Offline Offline

Activity: 715
Merit: 500



View Profile
November 14, 2016, 12:24:51 AM
 #1124


Loving this tech discussion, iamnotback has some serious knowledge.
HI-TEC99
Legendary
*
Offline Offline

Activity: 2772
Merit: 2846



View Profile
November 14, 2016, 12:39:31 AM
 #1125



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.

If the accounts are locked, how do they make the micro payment to confirm their address? they can't obtain the signature from their escrow in this case.



Most of those ico addresses are multisig addresses which can sign a message instead of making a micro payment. Each of the private key holders needs to sign the message, but that could probably be arranged. The ico buyers would start complaining if all the Bitcoins suddenly moved out of a dev's address, but they probably wouldn't notice or care if that address signed a message to claim BB.




It is possible to use multiple private keys to provide multiple signatures on a message.  This is what a multisig address requires.


valley365
Hero Member
*****
Offline Offline

Activity: 868
Merit: 1003


View Profile
November 14, 2016, 12:50:24 AM
 #1126

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.

Did not see the list in client. Now I saw it, will explore a bit.

I agree with iamnotback that we should use fixed witness list (or a pool of fixed list slightly greater than 12), this could avoid confusions.
galaxiekyl
Legendary
*
Offline Offline

Activity: 2002
Merit: 1113



View Profile
November 14, 2016, 01:23:42 AM
 #1127



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.

If the accounts are locked, how do they make the micro payment to confirm their address? they can't obtain the signature from their escrow in this case.


ardor collect is a exemple.. users on the exchanges had no control over their nxt account and the funds raised were moved without user intervention for distribution..this prove tha devs have the super user power when they want.
galaxiekyl
Legendary
*
Offline Offline

Activity: 2002
Merit: 1113



View Profile
November 14, 2016, 01:38:22 AM
 #1128

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

i'm curious also of know if we must keep our coin on address up distrib or just proof our btc balance ?
galaxiekyl
Legendary
*
Offline Offline

Activity: 2002
Merit: 1113



View Profile
November 14, 2016, 01:46:00 AM
 #1129

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.

maybe 51% of witnesses should be fixed..this will a relative centralization, if the bb community voting is implicated.
valley365
Hero Member
*****
Offline Offline

Activity: 868
Merit: 1003


View Profile
November 14, 2016, 01:52:38 AM
 #1130



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.

If the accounts are locked, how do they make the micro payment to confirm their address? they can't obtain the signature from their escrow in this case.


ardor collect is a exemple.. users on the exchanges had no control over their nxt account and the funds raised were moved without user intervention for distribution..this prove tha devs have the super user power when they want.

There's nothing absolutely fair. If they have BTC then they get BB, I see nothing wrong with it. I remember several years ago there was a coin called CommunityCoin, where it distributes according to the active members in this forum, evenly. Guess what, people created (or already have) 10s, even 40 accounts to claim the coin. Dev made huge effort trying to detect fraud, but many are well hidden until the time when they dump the coin, you realize that they are from the same wallet.

The way Tony proposed is not perfect, but at least fair using some information that people can not so easily fraud, which I think is a pretty good one which is simple and straightforward.
tonych (OP)
Legendary
*
Offline Offline

Activity: 965
Merit: 1033


View Profile WWW
November 14, 2016, 08:19:12 AM
 #1131

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

i'm curious also of know if we must keep our coin on address up distrib or just proof our btc balance ?

You can move the coin however you want but it should be on the linked address on the distribution date.

Simplicity is beauty
marseille
Hero Member
*****
Offline Offline

Activity: 938
Merit: 500



View Profile
November 14, 2016, 08:43:26 AM
 #1132

There's nothing absolutely fair. If they have BTC then they get BB, I see nothing wrong with it. I remember several years ago there was a coin called CommunityCoin, where it distributes according to the active members in this forum, evenly. Guess what, people created (or already have) 10s, even 40 accounts to claim the coin. Dev made huge effort trying to detect fraud, but many are well hidden until the time when they dump the coin, you realize that they are from the same wallet.

The way Tony proposed is not perfect, but at least fair using some information that people can not so easily fraud, which I think is a pretty good one which is simple and straightforward.

I agree. I remember a lot drama at CommunityCoin where the focus of the thread was completed diverted. Which is definitely not good for the coin. Here we need to focus on the coin development and features.
lerecidiviste
Newbie
*
Offline Offline

Activity: 40
Merit: 0


View Profile
November 14, 2016, 09:31:36 AM
 #1133

hello tonych    gd mrg frds


pls question about = WITNESS  the 12

who are they ? how u select them ? when can we see them ?

what is there profile : capital, computer power, etc ......

are they up & running when ?

thanks
 Roll Eyes


iamnotback
Sr. Member
****
Offline Offline

Activity: 336
Merit: 265



View Profile
November 14, 2016, 10:22:55 AM
 #1134

tonych, I am going to leave this thread now, because I have other work to do. If there is anything you want me to read or respond to, please PM me at any time.

I suggest and I think you already decided to emphasize the asynchronous advantage of you blockless DAG compared to for example Steem's DPoS. This provides more robustness than a synchronous round-robin cycling through a set of witnesses that produce blocks in DPoS.

I hope my summary on the prior page of thread, exemplifies one possible wording of how to better summarize the algorithm of Byteball in fewer words for any cases that can benefit from a more concise summary.

Btw, your design helped me refine how I articulate my design in my white paper, because it helped me develop a general model for the taxonomy of consensus ordering designs. This is why I prominently cite Byteball in the current draft of my white paper as I consider it a keystone prior art in that taxonomy.

The stability point design concept is technically clever (and complex enough that I had to apply some effort to wrap my mind around it). You are obviously a smart guy.
galaxiekyl
Legendary
*
Offline Offline

Activity: 2002
Merit: 1113



View Profile
November 14, 2016, 11:53:48 AM
 #1135

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

i'm curious also of know if we must keep our coin on address up distrib or just proof our btc balance ?

You can move the coin however you want but it should be on the linked address on the distribution date.

Quote

pls let me know good..the first distrib will be done 25 december on bb tn or after 25 december on live net ?..we must paired btc addresse before end november or we can wait live net ?
tonych (OP)
Legendary
*
Offline Offline

Activity: 965
Merit: 1033


View Profile WWW
November 14, 2016, 12:00:30 PM
 #1136

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

i'm curious also of know if we must keep our coin on address up distrib or just proof our btc balance ?

You can move the coin however you want but it should be on the linked address on the distribution date.

pls let me know good..the first distrib will be done 25 december on bb tn or after 25 december on live net ?..we must paired btc addresse before end november or we can wait live net ?

The testnet distribution will happen in late November (the bot was designed for livenet and still says 25 December, it doesn't apply to testnet).

Simplicity is beauty
tonych (OP)
Legendary
*
Offline Offline

Activity: 965
Merit: 1033


View Profile WWW
November 14, 2016, 12:04:15 PM
 #1137

pls question about = WITNESS  the 12

who are they ? how u select them ? when can we see them ?

what is there profile : capital, computer power, etc ......

are they up & running when ?

In your wallet, see Menu -> Settings -> Witnesses.
In testnet, I control all 12 witnesses, they are always online.

Simplicity is beauty
iamnotback
Sr. Member
****
Offline Offline

Activity: 336
Merit: 265



View Profile
November 14, 2016, 09:27:19 PM
Last edit: November 14, 2016, 09:38:46 PM by iamnotback
 #1138

tonych, I return for one final clarification. Am I correct that if the 12 witnesses do not change, then they can only create one total order in the DAG even if they attacking? The only damage rogue witnesses can do is to stall (and indefinitely if they are the majority of witnesses) the forward movement of "stability points", i.e. finality of transactions?

They can stall by not signing units or signing branches that the other witnesses have not seen.
piebeyb
Legendary
*
Offline Offline

Activity: 2464
Merit: 1039


Bitcoin Trader


View Profile WWW
November 14, 2016, 10:14:05 PM
 #1139

I saw that the wallet was working fine just waiting for the launch, at least to see the community response to byteball

marseille
Hero Member
*****
Offline Offline

Activity: 938
Merit: 500



View Profile
November 15, 2016, 06:01:32 AM
 #1140

I downloaded mac version and it syncs to 51% then stuck, and I exit it and restart, it starts from 0% again... is it a known issue?
Pages: « 1 ... 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 [57] 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 ... 1126 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!