I used to have a similar problem that disappeared about 2 byteball updates ago.
Maybe it's not related with what you are seeing, but when it seems that the synchronization is struck, click in another window which is opened in your desktop.
Then click back in byteball wallet window and see if the percentage jumps ahead.
If it jumps then it was not really struck, but simply failing to update the percentage.
When it was happening with me I was running byteball within kde inside whonix/debian virtualbox inside linux.
I haven't installed new byteball version yet to see if the problem's resurfaced.
If you confirm the behaviour I've just described, then I think it'd be related to one of those nasty environment incompatibilities.

To be fair, and in retrospect, I probably misunderstood that you were not concerned discussing byteball centralization generically and in theory, as a quality, but in particular, as it manifest itself at the current situation and stage of the project, with the real people involved, as I think I understand now, and for that I appologize.

As for the general/theoretical situation of collusion of most witnesses and how impotent the rogue cartel would be against an economy that value its platform a lot, please see pages 21/22 of white paper by the same author (not cited here for brevity) about how to deal with them (schism).

Still to be seen how easy/hard collusion of majority witnesses could form, mechanisms of changing witnesses, schism, would be coordinated etc, keeping in mind all incentives (economical, reputational etc) involved.


That was easy as per my own admission there.

I think I wasn't able to to express myself appropriately as I certainly wasn't advocating any urge for "tonych to relinquishing control over" anything, much less "breaking down the current one man cartel" in anyway.
In fact, I think the current situation is heath and expected for this stage of the project, and changing witnesses to be risk at the moment (I, for one, won't do this). Byteball need to grow much more so it can resist attacks as I think byteball's decentralized qualities will manifest themselves incrementally while it grows (I am currently learning and can not fully back this claim up, but I can sense witnesses may provide unheard levels of decentralization, much greater than many here acknowledge).
Besides, as far as I know, tonych can't do anything if economy decide to change some witness, apart from offering new version of the software (open source) which s0mehow enforce the witnesses he prefers.  But then, he has to convince everyone to update to his version (admittedly very easy now as I think he, for the foreseen future, has much trust of the economy).
I guess, this puts me in the "mindless cheerleaders" category then .

If by "centralized 'mechanism'" you mean the fact that tonych control all 12 witnesses I'd say I don't think the mechanism of changing witnesses is somehow deactivate 'till the distribution is over.
I think it's in full blow validity and someone who present a very compelling argument to be one of the twelve witnesses could assume the role.
Now, tonych may have any number of reasons to be in this role, but one would be: the network had to start securely somewhere, and the other being: no one's showed up yet with the needed reputation and credibility.

Could someone who knows how please ask https://coinmarketcap.com to increase Available Supply from 100,000 GBYTE to 117,610.194028342  GBYTE?
I think this will bring more visibility to byteball as market cap will increase.

I see your point, and can say I know some that have felt very conflicted about linking exactly for the reasons you mentioned.

I agree that byteball team is very much trusted here and most importantly strive to be trusted by new comers which will increasingly come everyday.
Trust was achieved by constantly being transparent and many other actions that we witnessed  , but it also can be lost in a wink.

About your concern I can not see a way out, except by constantly striving to keep your bitcoin and byteball anonymous all the time (very difficult, I know).
What I mean is that when both your bitcoin (difficult but doable) and your bytes (very easy) cannot be easily linked back to you, it becomes less of a concern if your bitcoin could be linked, in a certain point in time, to your bytes and vice-versa.

For byteball privacy I think it suffices to use something like whonix (see page 64 of this thread instructions on how to setup; it worked for me; please forget about "git clone" and just grab "source code zip" on https://github.com/byteball/byteball/releases of last byteball version, create /home/user/byteball directory and unzip content inside) which, before tonych finish implementing sock5/tor support in desktop wallet, can solve the problem of reveling your ip (I think this problem plagues almost all crypto currencies there are, it's not in any way about byteball exclusively). Even when we have tor support in byteball desktop wallet, some may still use whonix just to be (almost) sure of no licking (as we could recently see in a dependency (nw.js) which licked ip).
Besides of that, byteball privacy is still relatively easy, as you can still trade byteball without exposure to KYC/AML mechanisms (make sure to properly mix bitcoin you use to buy or receive for selling bytes, and use exchange via torbrowser).

I agree with everything you said. Thank you.

I don't think if you have many bitcoin addresses linked to many byteball addresses that you need to consolidate them in a unique byteball address in order to receive the corresponding blackbytes in the second distribution, nor that it would be more convenient to do so.

Am I correct tonych?

But even if I am correct why the transition  bot shows the many byteball linked addresses, their balances and then inform: "Move your bytes to one of the linked addresses in order to maximize the amount of blackbytes you receive"?
"Maximize" here means only account for some dust you won't receive because of rounding problems etc. or you risk loosing many of the blackbytes you'd otherwise receive if you'd consolidated in one of the linked byteball addresses?

edit: small correction near the end.

Let me add, and even more so if you use whonix.
I can attest it works.

Hi tonych,

Please, let us known if the following reasoning is correct.

Say there are N wallets running on the byteball network at a given time.
All of them have the same list of 12 witnesses, all them being the 12 witnesses services you currently run to bootstrap the network securely.
Now, imagine that each one of those N wallets change 1 of their witnesses to another one, but that every one change to a different one (I know that is not the way it's meant to occur in practice, but this is a theoretical reasoning).  I mean, now there are N different witnesses plus the 12 you run.
After this, is it possible for any wallet to change its list of 12 witnesses, at the same time, by any subset of 12 witnesses from the N witnesses set there are now at the network (not your 12 ones)?

Yes, I see. Thank you.

Certainly not , I meant "one seed per each asset class" within each wallet.

Thank you for all clarifications.
This whole thing increasingly looks like a solution in search of a problem now.

I feel now like wasting your time and rather go back to the white paper, but I'd like to clarify one last point: see below


I meant to say that when you receive the asset you receive all its past historic data, like today I think. You'd receive the whole thing unencrypted from the sender.
Then you'd encrypt it with a seed generated new key of yours  and save everything back as a payload in the public DAG (forget about compression as this data probably shouldn't compress well anyway, addresses, signatures, etc.).
When it comes time to send these tokens to someone, your wallet would have retrieved it from the DAG, unencrypt it with you key (calculated from your seed), maybe save it in your local database (which now function as a local cache) as it does today, generate the new transaction and send it to the counterpart using the same mechanism as it does today. Then the process would repeat all over again by the new receiver.
Note that after each transaction reaches finality state, the payload of the previous transaction could somehow be pruned as not needed. As today any owner of a token could only access previous history of it and wouldn"t be allowed to see future transactions.

The idea was to generate those encryption keys from the random generated seed.  When you need a random address for bytes you calculate/generate it from the seed.  Encryption keys could be generated from a seed too (one seed for each asset class maybe for security reasons, i.e. one for blackbytes, other for asset X and etc.). If they are generated from a seed, only the seed need to be saved (one time operation).
If you already generate private keys from a seed for each non spended asset (I don't really know), you could generate encryption keys from those pks by calculating some hash from them, not needing an extra seed only for the encryption keys.



Maybe my deficiency, but my understand is that we could retrieve (and only the owner could) the same data we have today locally (for blackbytes for instance) from the DAG to the wallet, and with this the new transaction could occur privately, as it is today, between the parts.  The receiver would than save the data in the DAG, instead of locally, using his own encryption keys generated from his own seeds.


Yes, this works but maybe not for all scenarios.
For high values and strict security models of some institutions (for instance, cold wallets) it's hard to imagine that your back-up depend on many devices on-line syncing between them. If the other idea works (which is unlikely cause it must have any number of flaws), only the seeds would need to be backed-up.

Please note that I am not even suggesting it to be implemented in Byteball.
It was only a thought exercise if you can find some time to teach.

Thank you for your reply.
I think I could understand your suggestions and they are interesting and have their own merits, but the point of my post was to have all this integrated into Byteball.
The goal was to make possible and automated that a mechanism like the one tonych offered today to recover all bytes balances and transactions of any wallet by just typing the seed would also work for assets (blackbytes included).
The idea was to use a generated random seed (not a human password or passphrase) not only to generate keys for assets but, via extra hashes of those keys, to generate a random encryption key for each transaction in order to break traceability of saved payloads.

Hi tonych,

Shower thought (almost certainly a stupid one as always happens when you don't exert deep thinking, as I haven't finished reading the white paper, and have no time right now to research feasibility):

Would it be possible to optionally (because it changes somewhat the privacy/anonymity model) save assets (including blackbytes) in the public DAG as a compressed and encrypted payload (not much differently of what is saved locally today) paying due commissions?
Maybe we could now use a different seed for each asset to generate private keys for them and some hash of these to encrypt assets payload after each transaction.
Wallets would scan the DAG trying to decrypt asset payloads to get balance and history (some optimizations may apply).
Somehow old saved payloads in the DAG could be pruned as assets carry their own history.

Pro:
- Massive improvement in usability, no need to back-up local assets after each transaction (simplicity is beauty).
Cons:
- Privacy model changes (thus to use it optionally) as now assets history only remains private as long as no one discover a way to decrypt the payload which is now publicly available.
- Increased storage requisites for the DAG (but it'd be optional and has costs)

Some have been arguing the necessity of sharing undistributed coins with others.  Please, consider not doing this.
I, obviously, represent only myself here, but maybe there are others that think alike.
My decision to invest in Byteball has came even before reading the white paper (which I haven't finished), by only reading the OP's summary, some pages of this thread and reading into the way tonych talk about this project and interact with people, knowledgeably and with conviction, kindly but firm, without circumventing any question but ignoring any provocation.
I am convinced tonych has Byteball at heart, but terrifies me to to have other people exert any control of it.
That's not to say that the situation with undistributed coins isn't bad.  It brings uncertainty and untruest.
There is the danger of someone gaining access to those coins, which is a serious concern for investors and sure is also for tonych even in a personal level, especially if price continue increasing.
I understand that tonych changed his initial distribution plain (fixed percentages, end soon) in order to maximize its effect obeying his criteria (my interpretation, obviously) of widespread distribution within strongly interested, highly experienced and hardened people, thus bitcoin.
The problem now is market uncertainty, not knowing how long it will take and in which pace.
I see this as a factor of untruest for long term investors.
I think Byteball will stand according to its own merits: technical, usability, privacy/anonymity, lucid leadership and etc., all this being solid foundation.  What is left is more decentralization (finishing distribution is part of it) and the test of time, being serious glitches free and enduring attacks.
I can only hope tonych's goal is to timely but decidedly release control in favor of decentralization but continue development being the lighthouse for the economy to follow.
Can you imagine how much decentralization this concept of 12 witness with anyone being able to designate a different one at the same time can elicit?
Imagine not depending of all those miners nor the relative energy spending?
I'm here for the long run and couldn't care less for daily fluctuations of price.
Pay an exchange to list byteball? Are you kidding me?
If Byteball has potential it'll be listed in as many exchanges as needed. tonich has already provided needed API.
Exchange https://cryptox.pl works really well for me.  It has fast deposits, instantaneous withdraws (of bytes, I've never sold nor withdrawn previously deposited bitcoins, so I can't tell), streamlined registration, no AML/KYC (granted, no fiat involved, but I've heard others have those even without fiat involved) implying privacy and clear interface.
The genie is already out of the bottle as we can cense by new people arriving every day.
PR is important and https://coinmarketcap.com is the best we have. Being in the forty range is surely attracting the attention of anyone that is serious about crypto currencies.
So I'm really content being patient as long as fundamentals continue moving in the right direction.

ps: just to give context it's written before today's price jump, which is nice but is not really that important.

I agree completely with this assessment.
Please tonich, don't do this. Keep control of this project till it can survive by itself.  This project need time for the best minds to learn its principles and can form a shield against all the deceivers that will pop up and try to take it over. I think this is the time for those that have the knowledge to help clarify all technical and design aspects of byteball. I know that now there is only a few advanced technical questions, but this soon will change. By the time technical discussions evolve, hopefully the economy will be able to choose direction based on wisdom of wise men ike you and others.
Please, keep politics out of it.

edit: forget some points

Thank you very much tonych for the detailed response.
I now understand that behaviour.
I can now procced with my original plan an I will succed.
Thanks

Complementing....

I've also noticed that when I press insert address button on transition bot it place there one of the previouslly generated ađresses  and not a newly generated one.

thanks

OK, that works and I've successfully build and run  livenet. Thank you.
Now, my security model imply, as a way to link byteball to bitcoins, that I sign byteball addresses offline.
So I've tried to generate a certain number of byteball address in order to create a file to take it offline to another computer and while there I would sign each byteball address with a bitcoin address and save the signed text.
Then I would bring that file back to the online computer start byteball again and inform to the linking bot those addresses and signed results and have everything linked.
So, to generate the byteball addresses I went to receive and press generate address button several times and then went to Preferences > Advanced > Wallet Information and at button copied the generated byteball addresses.
First thing I noticed was that it seems to only show the last about 6 generated addresses.
Never mind, I come back to receive and generate some more and go back to Walled Information and copy the new ones from there,
Then I noticed that after some time receive stop generating new addresses and every time that I press generate button it generates one of those already generated.
I tried to close and run again the wallet and the same thing happened
Is there a way around this?
Even thou I'm not being able to see all addresses can I be sure to have all them registered inside the wallet?
Thanks again