Obyte: Totally new consensus algorithm + private untraceable payments

[seven.71]

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.

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.

market bear still occur small possibility there is big pump in market
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

[cointrader78]

somebody interested in doing the name attestation Kyc PM me so i send you free bytes 😝

[HCP]

Something weird happening since latest update... out of nowhere I've started getting this error:

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

[CosaNostra]

Hi guys! Network is working fine for ya?

[CryptKeeper]

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’

[jjacob]

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

[jwinterm]

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

[CryptKeeper]

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

[vlom]

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.

[bspus]

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

[CryptoRobert]

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

[muleroaa]

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

[CryptKeeper]

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:

most of the network is back online, steem attestations will resume after 12pm CET, will prepare a new release for full wallets

[funcho]

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

 

[alyssa85]

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

[Random-String-Symphony]

‘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:

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.

[slovakia]

any news about to resume the Byte distribution for WCG?

[Freefactomizer]

any news about to resume the Byte distribution for WCG?

It will happen very soon.

[Nippel66]

Joined Airdrop yesterday with my Steemit account. That was a good airdrop since i am over 60 in Rep

[weird123]

What is going on with cryptox.pl ? I know that admin is not anonymous person. What he say?