Topic: Obyte: Totally new consensus algorithm + private untraceable payments - page 153. (Read 1234271 times)
July 17, 2018, 03:41:30 AM
Joined Airdrop yesterday with my Steemit account. That was a good airdrop since i am over 60 in Rep
July 17, 2018, 01:14:18 AM
any news about to resume the Byte distribution for WCG?
It will happen very soon.
July 17, 2018, 01:06:32 AM
any news about to resume the Byte distribution for WCG?
July 16, 2018, 09:54:25 AM
‘the graph is very complex now, which makes validation very slow, and it is still performed in sql. So large complex graph became possible after we allowed spending unconfirmed funds. Trying to do urgent performance improvements now’
Wasn't the scalability of DAG supposed to be much, much better than blockchain? I thought that was the selling point of Byteball and other cryptocurrencies based on DAG. But if validation becomes slower as the graph becomes more complex, then we really don't have a competitive advantage in using DAG,.
That’s a valid concern but please mind that we have mostly unoptimised code here. IMO the underlying SQL server is the bottleneck here, there’s no flaw in the DAG scalability. This was already discussed several times but the optimization of the database functions was postponed because other improvements seemed to be more urgent.
What about now though, will more emphasis be placed towards optimizing database functions? It appears to have quite some impact.
They'll have to - this latest episode has exposed that they can't handle large volumes of transactions yet.
Byteball might not be able to handle large volumes of tx yet, but that's not what this latest episode was about. See this statement from Tony on Slack:
Quote
tonych [2:32 PM]what happened:
- on Friday (the 13th) 10 out of 12 witnesses crashed due to a bug. The 2 surviving were recently updated and didn't have the bug
- among the 2 surviving witnesses, was the steem attestation bot which continued to post transactions very fast, and since it didn't have to wait for confirmations, nothing could stop it and the unconfirmed tail of the DAG has grown very large
- the 10 witnesses updated and restarted but they started adding their units to the old part of the DAG they last witnessed, which caused massive rebuilds of the main chain each time a new unit was added. This made validation of new units very slow.
- I had to urgently find and apply a few optimizations that matter only when the DAG takes such unusual form. They made validation faster but still way slower than usual
- when the optimizations were ready, another issue popped up: calculation of stability point gave unexpected result. I had to investigate the new issue, which took another day, and found a mistake in the algo. The fix breaks compatibility with the old (flawed) algo, and makes the update mandatory for all full nodes.
tonych [2:43 PM]
there were other performance improvements we've ben working on for the past several months, they affect a lot of code and any small mistake could cause a consensus split, and i didn't feel it is right to roll them out in such unprepared manner.
- on Friday (the 13th) 10 out of 12 witnesses crashed due to a bug. The 2 surviving were recently updated and didn't have the bug
- among the 2 surviving witnesses, was the steem attestation bot which continued to post transactions very fast, and since it didn't have to wait for confirmations, nothing could stop it and the unconfirmed tail of the DAG has grown very large
- the 10 witnesses updated and restarted but they started adding their units to the old part of the DAG they last witnessed, which caused massive rebuilds of the main chain each time a new unit was added. This made validation of new units very slow.
- I had to urgently find and apply a few optimizations that matter only when the DAG takes such unusual form. They made validation faster but still way slower than usual
- when the optimizations were ready, another issue popped up: calculation of stability point gave unexpected result. I had to investigate the new issue, which took another day, and found a mistake in the algo. The fix breaks compatibility with the old (flawed) algo, and makes the update mandatory for all full nodes.
tonych [2:43 PM]
there were other performance improvements we've ben working on for the past several months, they affect a lot of code and any small mistake could cause a consensus split, and i didn't feel it is right to roll them out in such unprepared manner.
July 16, 2018, 07:46:50 AM
‘the graph is very complex now, which makes validation very slow, and it is still performed in sql. So large complex graph became possible after we allowed spending unconfirmed funds. Trying to do urgent performance improvements now’
Wasn't the scalability of DAG supposed to be much, much better than blockchain? I thought that was the selling point of Byteball and other cryptocurrencies based on DAG. But if validation becomes slower as the graph becomes more complex, then we really don't have a competitive advantage in using DAG,.
That’s a valid concern but please mind that we have mostly unoptimised code here. IMO the underlying SQL server is the bottleneck here, there’s no flaw in the DAG scalability. This was already discussed several times but the optimization of the database functions was postponed because other improvements seemed to be more urgent.
What about now though, will more emphasis be placed towards optimizing database functions? It appears to have quite some impact.
They'll have to - this latest episode has exposed that they can't handle large volumes of transactions yet.
July 16, 2018, 02:00:46 AM
trying to send a 1 byte payment to ZLJY3IYWL6BA6WSS5IZYTR3AUF37DE6N
in android
error message / syncing for 1minute then internal connection closed regardless of qr code or manual enter
windows wallet same / timeout
in android
error message / syncing for 1minute then internal connection closed regardless of qr code or manual enter
windows wallet same / timeout
July 16, 2018, 01:15:56 AM
Hi guys! Network is working fine for ya?
No, the Byteball network is in maintenance mode. The chief developer posted this on our Slack:
‘the graph is very complex now, which makes validation very slow, and it is still performed in sql. So large complex graph became possible after we allowed spending unconfirmed funds. Trying to do urgent performance improvements now’
The chief developer posted an update:
Quote
most of the network is back online, steem attestations will resume after 12pm CET, will prepare a new release for full wallets
July 15, 2018, 04:48:36 PM
‘the graph is very complex now, which makes validation very slow, and it is still performed in sql. So large complex graph became possible after we allowed spending unconfirmed funds. Trying to do urgent performance improvements now’
Wasn't the scalability of DAG supposed to be much, much better than blockchain? I thought that was the selling point of Byteball and other cryptocurrencies based on DAG. But if validation becomes slower as the graph becomes more complex, then we really don't have a competitive advantage in using DAG,.
That’s a valid concern but please mind that we have mostly unoptimised code here. IMO the underlying SQL server is the bottleneck here, there’s no flaw in the DAG scalability. This was already discussed several times but the optimization of the database functions was postponed because other improvements seemed to be more urgent.
What about now though, will more emphasis be placed towards optimizing database functions? It appears to have quite some impact.
July 15, 2018, 04:00:51 PM
‘the graph is very complex now, which makes validation very slow, and it is still performed in sql. So large complex graph became possible after we allowed spending unconfirmed funds. Trying to do urgent performance improvements now’
Wasn't the scalability of DAG supposed to be much, much better than blockchain? I thought that was the selling point of Byteball and other cryptocurrencies based on DAG. But if validation becomes slower as the graph becomes more complex, then we really don't have a competitive advantage in using DAG,.
That’s a valid concern but please mind that we have mostly unoptimised code here. IMO the underlying SQL server is the bottleneck here, there’s no flaw in the DAG scalability. This was already discussed several times but the optimization of the database functions was postponed because other improvements seemed to be more urgent.
As long as it is a choice and not a flaw, I see no problem there. However, it would be nice if the wallet would have the capability to display a message of maintainence status.
July 15, 2018, 01:50:43 PM
‘the graph is very complex now, which makes validation very slow, and it is still performed in sql. So large complex graph became possible after we allowed spending unconfirmed funds. Trying to do urgent performance improvements now’
Wasn't the scalability of DAG supposed to be much, much better than blockchain? I thought that was the selling point of Byteball and other cryptocurrencies based on DAG. But if validation becomes slower as the graph becomes more complex, then we really don't have a competitive advantage in using DAG,.
That’s a valid concern but please mind that we have mostly unoptimised code here. IMO the underlying SQL server is the bottleneck here, there’s no flaw in the DAG scalability. This was already discussed several times but the optimization of the database functions was postponed because other improvements seemed to be more urgent.
Since most people are encouraged to run the wallet in light mode anyway, would it make sense for the full nodes to use a full capability DBMS? Assuming the performance benefits would be that significant and thinking about long term future.
July 15, 2018, 01:03:04 PM
Hi guys! Network is working fine for ya?
No, the Byteball network is in maintenance mode. The chief developer posted this on our Slack:
‘the graph is very complex now, which makes validation very slow, and it is still performed in sql. So large complex graph became possible after we allowed spending unconfirmed funds. Trying to do urgent performance improvements now’
does this mean it is not possible to make transactions?
and if the is important to all users thatthe Byteball network is in maintenance mode then the wallet should show a message after startup.
July 15, 2018, 11:46:00 AM
‘the graph is very complex now, which makes validation very slow, and it is still performed in sql. So large complex graph became possible after we allowed spending unconfirmed funds. Trying to do urgent performance improvements now’
Wasn't the scalability of DAG supposed to be much, much better than blockchain? I thought that was the selling point of Byteball and other cryptocurrencies based on DAG. But if validation becomes slower as the graph becomes more complex, then we really don't have a competitive advantage in using DAG,.
That’s a valid concern but please mind that we have mostly unoptimised code here. IMO the underlying SQL server is the bottleneck here, there’s no flaw in the DAG scalability. This was already discussed several times but the optimization of the database functions was postponed because other improvements seemed to be more urgent.
July 15, 2018, 11:43:07 AM
‘the graph is very complex now, which makes validation very slow, and it is still performed in sql. So large complex graph became possible after we allowed spending unconfirmed funds. Trying to do urgent performance improvements now’
Wasn't the scalability of DAG supposed to be much, much better than blockchain? I thought that was the selling point of Byteball and other cryptocurrencies based on DAG. But if validation becomes slower as the graph becomes more complex, then we really don't have a competitive advantage in using DAG,.
I think the immediate issue is the original design decision to use sqlite for db - it is just a single file database that isn't intended for much beyond like a single small website or data storage in lab or something. Howard Chu says, "shoulda used LMDB."
July 15, 2018, 11:33:52 AM
‘the graph is very complex now, which makes validation very slow, and it is still performed in sql. So large complex graph became possible after we allowed spending unconfirmed funds. Trying to do urgent performance improvements now’
Wasn't the scalability of DAG supposed to be much, much better than blockchain? I thought that was the selling point of Byteball and other cryptocurrencies based on DAG. But if validation becomes slower as the graph becomes more complex, then we really don't have a competitive advantage in using DAG,.
July 15, 2018, 06:12:26 AM
Hi guys! Network is working fine for ya?
No, the Byteball network is in maintenance mode. The chief developer posted this on our Slack:
‘the graph is very complex now, which makes validation very slow, and it is still performed in sql. So large complex graph became possible after we allowed spending unconfirmed funds. Trying to do urgent performance improvements now’
July 15, 2018, 04:38:42 AM
Hi guys! Network is working fine for ya?
July 14, 2018, 09:22:46 PM
Something weird happening since latest update... out of nowhere I've started getting this error:
Because the error message is longer than the wallet window, there is no "OK" or "Cancel" button available to press... so the wallet is basically usuable
Quote
Uncaught exception: Error: Error: SQLITE_ERROR: too many SQL variables SELECT unit, level, latest_included_mc_index, main_chain_index, is_on_main_chain FROM parenthoods JOIN units ON parent_unit=unit WHERE child_unit IN(?) YA/nY0OfioVfSn3YQT6dq6k/7Io6f55syrtakNDFJ3g=, 2+u6D6Y6Owr5BLDmT0xs/gKvF0xWbyY8G36no4nwfKo=,
Because the error message is longer than the wallet window, there is no "OK" or "Cancel" button available to press... so the wallet is basically usuable
July 14, 2018, 08:01:52 PM
somebody interested in doing the name attestation Kyc PM me so i send you free bytes 
😝
😝 
July 14, 2018, 07:10:32 PM
What do you think after looking at the following chart?
https://coinmarketcap.com/currencies/byteball/
Is it stimulating your greedy instinct a bit?
of course, each investor has personal glance, and different decision, I have simply gave you a hint on Byteball price chart.
https://coinmarketcap.com/currencies/byteball/
Is it stimulating your greedy instinct a bit?
of course, each investor has personal glance, and different decision, I have simply gave you a hint on Byteball price chart.
It does look like there is potential. But almost all altcoins are trading at levels way below their all time highs. A lot of people believe that Byteball has potential; it definitely has seen a lot of development, but for some reason the price just doesn't take off.
I guess that the main reason is that the distribution is not completed yet. In this phase whales are probably slowly accumulating, but they wouldn't pump the price with so many indistributed coins in dev's hands. Generally speaking, big speculations over coins not entirely distributed could turn out being more dangerous than with fully distributed coins. Just my humble guess.
although from the chart it looks beautiful for the input into the bag more but very risky because there is no sign BTC rise significantly
July 14, 2018, 06:58:57 PM
What do you think after looking at the following chart?
https://coinmarketcap.com/currencies/byteball/
Is it stimulating your greedy instinct a bit?
of course, each investor has personal glance, and different decision, I have simply gave you a hint on Byteball price chart.
https://coinmarketcap.com/currencies/byteball/
Is it stimulating your greedy instinct a bit?
of course, each investor has personal glance, and different decision, I have simply gave you a hint on Byteball price chart.
It does look like there is potential. But almost all altcoins are trading at levels way below their all time highs. A lot of people believe that Byteball has potential; it definitely has seen a lot of development, but for some reason the price just doesn't take off.
I guess that the main reason is that the distribution is not completed yet. In this phase whales are probably slowly accumulating, but they wouldn't pump the price with so many indistributed coins in dev's hands. Generally speaking, big speculations over coins not entirely distributed could turn out being more dangerous than with fully distributed coins. Just my humble guess.
Jump to: