Topic: IOTA - page 753. (Read 1471689 times)

Agreed. Best to you. Hopefully my feedback helped in some small way.

Indeed, my role is management and marketing, not the code. Re: your proposal of collaboration, we have finalized the design of iota at this point and are in full development. This means that unless there is found to be some flaw in our design or your solutions would be truly revolutionary, (which would require that you have a whitepaper available within a few days) we will respectfully decline.

Okay let the idea for collaboration die on the vine. Neither of us need more drama to slow us down.

I was hoping you (Come-from-Beyond) were the only person I had to coordinate with. My guess is "David" is more of the marketing guy. Too many different personalities to harmonize with while we are trying to rush development, thus sounds like a potential recipe for disaster.

Best.

Thank you, I hope we'll share it with you.

Wish every success to this project btw (it does not need my wishes of course, it will be a sure success).

I'll ask David to invite you into the convo.

TPTB talking with David? I wanna see this...

Contact iotatoken instead of me, please. I'm just a programmer who happened to know some stuff because of necessity to implement it in the code.

They key advantage I see for DAG tangle form of consensus versus a block chain, my ClickzSync design, and Lightning Networks, is that appending your transaction into the DAG tangle is autonomous and permission-less (notwithstanding you probably want to see as much of the breadth of the tree as possible thus need a reasonably powerful server and internet connection, or delegate to one)! That is a very profound distinction!

This means that any user can append their transaction to the consensus network and can't be censored per se. Now their transaction might not get included in any other branches of the tree if there is 100% censorship of that transaction, but this isn't very likely. It isn't a 51% all-or-nothing control as in Bitcoin and the conceptual reason is because a DAG tangle has multiple branches of consensus! And even if the probability of double-spend is high on a transaction that has been censored by a large % of the network (not included in their branches), the transaction still has a record in the DAG tangle and so the recipient can still accept the funds if they so choose to take that risk. In other words, the consensus network can multifurcate to route around censorship.

Having said this, the most optimum design for block scaling is not DAG tangles alone, but integrated with my ClickzSync design. And then also supporting the necessary opcodes so LN can also run on the system (because LN has the least overhead but has some drawbacks that an Iota+ClickzSync design would offer alternatives to). In other words, these 3 designs all address a slightly different aspect of the consensus scaling network optimization. The Iota design is going to need some tweaking any way, because I see some issues.

Thus I will open private discussions with the Iota team (apparently mthcl and Come-from-Beyond only?) now to see if they are interested in collaborating.

We are at a momentous point where (if I am not mistaken on the myriad of technical details) Iota+ClickzSync could radically overhaul crypto consensus network scaling, security, and TX/s. I hope they are interested to attempt it along with me if the parameters work for both of us.

I have some optimism because Come-from-Beyond is apparently programming to the Java Virtual Machine as I am as well. We seemed to have (very limited) amicable and agreeable forum discussion in the recent month or so.

Need some time to read this but I will follow, legendary dev's ftw

Thanks for the link, reading it now.

https://medium.com/quantum-bits/how-secure-will-our-data-be-in-the-post-quantum-era-6a7f444ce7d5

But it's not impossible to buy an older one without, wait for project ara or worst case scenario: crush the camera lens.

If there is a genuine demand in the future for 'dumb fridges', then they will still be produced.

It's a general case analysis, a special case (for a particular implementation) may give average time not dependent on some or all these parameters.

A question on the whitepaper.
Why does h - the average time a device needs to do the calculations necessary to issue a transaction depend on L - the total number of tips and N - the total number of transactions? That "total number of transactions" is it the total number of transactions incorporated in the DAG (probably unknown to the device) or what?

No, it is not that simple. It's impossible for example to buy a new smartphone not equipped with a camera nowadays.

Correct.

Probably yes, should be matter of seconds (in the regime where there is a reasonable flow of tx's already).


As far as I remember, there are no tx fees (CfB?..). The nodes invest only PoW.

In the event when the attacker's node is the only one who sees that two branches, yes.  I'm not sure that would be a recurrent situation, though.

Okay so qualitatively we just need to wait for some chain of subsequent TXs to reference the DAG node for our TX, and as long as the attacker's capacity to generate TXs is sufficiently low (perhaps similar to Bitcoin at less than 25 - 33% for selfish mining), then the double-spend probability will also be practically very low for tangles consensus. Indeed Bitcoin has similar probabilistic risk of double-spend:

https://bitcoil.co.il/Doublespend.pdf

Three observations:

• Confirmation is not instant, as it can be in other designs such as Lightning Networks (and also my design). Yet it will also be much faster then Bitcoin's block period. You are probably estimating at a few seconds at most assuming attacker's power is sufficiently low?
• The attacker's power is given by his ability to incur TX fees relative to the total TX fees being paid for TXs. This is qualitatively different situation than PoW block chains, because in a tangle every payer has to incur the cost of security by paying higher TX fees (which I assume be burned so the coin is deflationary to 0 supply, unless you burn PoW hashes instead which is what I would advise). In Bitcoin all users pay the cost of mining security as well though either through debasement or TX fees, so it seems about the same. A potential advantage for a tangle is if you burn PoW hashes as I suggest, then every user is mining, unless they delegate this hash to a server. However appears neither tangle nor traditional PoW block chain can be immune to a 51% attack, whereas in my block chain scaling design I do claim this immunity (sorry to plug my work here but is necessary in order to point out relative strengths and weaknesses of all designs available to the crypto community).
• No way to prevent double-spends in partitions of the network (no fault tolerance to network partitioning). I claim to solve this in my design and I think perhaps Lightning Network is also.

So overall I think this DAG stuff is an improvement over traditional PoW block chains in general, not just for IoT. But I do think I may have a superior design, but I am still analyzing to see what attributes the DAG might have that are superior. The elimination of the blocks and the aliasing error of chain reorganizations perhaps, but seems there are analogous issues in the DAG.

Please do not take my post as desiring to rain on your thread. I won't belabor my points. I am just trying to see where for example we might even collaborate if at all. Looking with an open mind. Cheers.

P.S. to the mathematician, kudos on working out all that math. I haven't made a decision to wrap my head around it yet. So pressed for time.

It's just a parameter set by the user.