Topic: Obyte: Totally new consensus algorithm + private untraceable payments - page 827. (Read 1234271 times)

As I said you are a clinical case but if you are willing to put your money where your mouth is - let's do it. So?

Each user is allowed to make 1 change of the 12 witnesses.  

The topic has been discussed in this thread and the Whitepaper is a very good source. You should read it. And cry, that your own design is so complicated and shitty compared to this.

You can't live an hour without saying a lie. If every user selects own witnesses then the network will stop working properly. You are a clinical case, it seems...

Main developer cant force users to anything, aside from auto-updating all Android apps through Google Play store (but not those in coming F-Droid release, how is it coming along @portabella !?)

To be honest, I do not know what would happen if I ran a modified client today which said it has 15 witnesses, I guess it would just be dropped as invalid transaction.

If i wanted to I could start a new network, "a fork" with 15 witnesses, but its then only using the same software but not at all same.

The concept of forks is discussed in the whitepaper under the title Schisms - in Byteball it is necessary for a new network, a new Byteball in the cases when witnesses collude with each other or just loose trust by the majority users - they can then start their new network, with 13 witnesses or 12, and begin linking old bytes to the new network as is being done today from BTC to Bytes.

What I like about Byteball is that the users have so much power. Just by selecting what to use, which witness we trust. Simple.

EDIT: Just to be clear, there is weakness in Byteball in my opinion, though CfB is clearly off target by half a planet. So far its only a few developers who understand it, we need better documentation so more developers can join and begin developing apps.

Appreciate you elaborating on the material. Sounds pretty good to me, GO Byteball

See here https://en.wikipedia.org/wiki/ESP8266 it is used in many IoT products, and has great platform support, SDK is available in Python, Lua, JavaScript, Arduino-like C++, C. The module price is $2 a piece. Amazing isnt it!

Thinger supports it (https://thinger.io/) which then gives also lets your software run on similar things like TI CC3000 and other IoT chips/devices.

The best thing is, it just works! If your thing can make an HTTPS connection (ie it is internet...) than for certain it also has computing power to make transactions with Byteball!  

Now in the medical field you know those FitBit watches people wear? They collect health information which is given to FitBit (cloud) to analyze and sell to others, insurance companies etc. Wouldnt it be nice if you wear a health-watch which sells your health-data to anyone by the price you set?    

Thank you, and sorry if I am not clear enough. English is not my first language.
Who can decide on major protocol change? Is it possible, for example, for owner of byteball.org website to make a wallet with 15 witnesses in code and force users to run new version? Will network catch it and run with 15 witnesses? Who and how vote for consensus in situations like with BU - SegWit?

But not via compression, right?

1) Hardforks are inbuilt into DAG, kind of, depends on what you mean. See in Byteball, despite CfBs lies, and unlike Ethereum its possible to grow many "histories" many "chains" at the same time, on different nodes, and these will be part of the Main Chain - ordered according to when they are seen, and they will be included if they do not double-spend. Who decides this ordering and following of "do not double-spend"? Who "sees"? Witnesses! They only see transactions and post their own approvals, stamps.

2) A very efficient and secure Light Client exists. You can keep the DAG in memory today, is only 1.4GB, there is no pruning done, yet storage efficiency can be improved later.

3) Yes, very light, Android app is such by default.

4) 12 is a good selection, too many like 1200 would be difficult for humans to know and replace/talk-about, too little would be easy to collude together. This is one of the few "chosen by gut instincts" variables/constants in Byteball. Yes tx carry witness list, all 12, but can be smaller for efficiency in a witness_list_unit, when the same list is known previously, thus re-shared.

5) There is no proof-of-work and no generation of coins, all are existing and generated in genesis unit, form which distributions take place every full moon.

It is by now obvious for everybody, Come-from-Beyond is not here to "reveal my lies" and "protect the naive from scammer" but is here to spread FUD, fear, uncertainty, doubt about Byteball as technology and concept.

He is here to insinuate weaknesses in Byteball, example calling it a blockchain, not scale well, "has blockchain like database problem" etc etc. Latest low effort was to attack the BTC-Oracle example by his opinion of being "overkill".

IOTA investors, take note, this is how low your developer goes. Pull your BTC to safety, the motive of CfB is to claim more of your BTC as "investment" into a failed concept, (IoT does not mix with PoW, is like oil and water) by sneaky attacks on a perceived competitors working, simple yet elegant and marvelous solution.

for my cases it was about 1-2 hours.

how long do btc withraws from cryptox usally take?

@tonych, what is your plan regarding the distribution in these conditions: http://www.coindesk.com/bitcoin-exchanges-unveil-emergency-hard-fork-contingency-plan/ ?

I need some answers.
Please elaborate, this is a new technology and no one really know how byteball DAG works.
1) Who responsible for hardforks? Should witnesses vote on hardfork? Or it's only depends on developers and right repository?
2) Is there a way to prune old transactions from local database and build transactions on some fresh ones? Is it necessary to keep all DAG on a disk?
3) Is there a SPV  wallet? Is it possible to make SPV wallet?
4) Why 12 witnesses, not  1200? From technical point of view, not politics. Is every transaction should carry all witnesses list with it? So transactions will be bigger proportionally to list of witnesses? Or not, and there is no problem to do 1200, 12000 or 1200000 witnesses potentially?
5) Can witnesses change max supply of coins and generate 10000 tb more? If not, who can?

Right, I don't understand everything, but it can be a sign of a conceptual flaw, not of my "weak mind".

---

So what is the solution to the problem explained here:

---

I know, I'd like to know how the conversion of old addresses will be done.

---

Thx, I'll check that part.

---

What will happen during the transition? The network can't function in normal mode if several witnesses differ between transacting nodes.

Interesting! Not that I understand much of what you're saying

Yeah as expected, avoid the facts. What trash you are.

Just like IOTA, trash and a scam.

The prototype is on ESP8266, now we move to ESP32 especially for BluetoothLE on it. We have cooperation with a smart home/natural human lightening company to supply them with these connected things, they like the prototype. Next iteration is working with medical/old-people-care-center.

I probably missed something said by tonych. Let's check everything one by one?


The latest info I have is this:


Am I the only one who thinks that the answer is pretty vague because it assumes that Byteball is DAG which is not obvious? Technically he said that there is no a limit, so it would be handy to see how Byteball behaves at 10 TPS, 100 TPS and 1000 TPS. I believe there is no a problem to run a stress-test with plain transfers on the testnet.

So I suggest to do such the stress-test and then we'll move to point 2 and so on...

1. You fail to understand how Byteball works and especially the witnessing. People have tried to explain, a few pages back. Not our problem you have a weak mind.

2) Addressed in the whitepaper, compression works well today, price of data to store is price payed in bytes.

3) Quantum-proof is non-issue for hash-based signatures, when Bitcoin breaks, Byteball may break, the code supports different signature curve to be used even today, Whitepaper especially mentions NRU for this reason.

4) Whitepaper mentions the defined constants, 1 of which sets this limit, which is 100 I believe.

5) Organically, like is mentioned in the whitepaper and by many people in this thread.

Kisses.