Presented like this it remind me of the pb with buffered io when the io is too slow downstream, and adding a buffer will just end up with the same blocked io latter with a bigger buffer. Buffered can just help smoothing the ups & down,  and it would be a bit like putting a time out on the write io, without really checking the all the data actually been sent at the end of the time out ;p knowing that most likely the throughput of LN is much higher than blockchain, it still lead to the question if the tx can be really processed on the chain before the lock expire,  and if the goal is to write them on chain at the end, if it's really going to do this faster.

Idk to me LN doesn't seem too bad in itself, but I just find there is something a bit askew with the mechanism of locking & parallel processing.

And also what would happen in this scenario if the locks on the main chain expire before the tx from LN can be pushed back to the main chain, it would be a bit like double spending issue no ?

For me the only real issue I would have with LN is the marking as locked which is misleading, as lock should mean "NAK" nothing going on with those bit coins, whereas it's more locked away in a parallel system, and they should be marked as such on the main chain.

That would clarify things more, and maybe it can avoid a bit the fractional reserve issue or make it easier to detect as the bitcoin value would be marked as undetermined on the blockchain as long as it's being used on LN, and the up to date state can be then fetched from LN if needed, or the state being undetermined , instead of marking them as locked and "nak". Or making the lock explicitly a full exclusive lock instead of just exclusive write lock.

Because there it still make the btc marked as locked, whereas in reality they are still being used. And then it start to look more like banks who do stuff with your money without saying it, as the fund are supposed to be locked on a bank account , but In fact they are not locked at all

Yeah i think LN is a good idea in the overall and is reasonable trade off that can have its advantage, but it has to be taken for that it is too, and not saying it has no impact on the way it's done vs regular bitcoin transaction and it doesn't give the same security and scrutiny than the global block chain with the proof of work.

And it doesn't have the mechanism to make it as transparent  and reliable as a cache.

It doesn't even really supposed to act as a cache at all.

And even if it was, it's far to be as simple as it's same if using a cache or not like the hd example.

Using cache in concurrent system is full of "tl;dr ignored" problem. One sure thing is it's more complicated than a 3 tweets issue. And even so, the effective gain dépend entierely on good management of data temporality otherwise it's either useless or unsafe.

The effect is not as dramatic as with browser cache & internet data because supposedly the people owning the key to the btc being locked on the LN already have more or less exclusive access to it, but if there was potentially several independent users using those same keys, it would make a difference.

Anyway saying LN is a caching solution is like saying it would be normal if a browser would lock down a picture for the whole internet because it need to use it locally.

LN miss many thing to be able to be called a true cache system.


Memory management with smp & pci bus is a very complex things, and architecture evolved with more instruction and better instructions pipelining, more functions coming with c11 & openmp,  but handling of cache with smp/pci/south bus is far from trivial.

The issues can be seen more clearly with arm architecture because the cpu architecture is much simpler and they dont have built in handling of these issue of cache and concurent access with south bus and memory bridge,memory space conversion etc.


https://en.m.wikipedia.org/wiki/Conventional_PCI#PCI_bus_bridges

Posted writes
Generally, when a bus bridge sees a transaction on one bus that must be forwarded to the other, the original transaction must wait until the forwarded transaction completes before a result is ready. One notable exception occurs in the case of memory writes. Here, the bridge may record the write data internally (if it has room) and signal completion of the write before the forwarded write has completed. Or, indeed, before it has begun. Such "sent but not yet arrived" writes are referred to as "posted writes", by analogy with a postal mail message. Although they offer great opportunity for performance gains, the rules governing what is permissible are somewhat intricate.

Caching help when it take in account temporality when multiple access on the same data are made , it can help skipping some likely useless long write, but it's still quite probabilistic.

LN would be a cache if it didn't lock the resources on the main chain, and would be able to detect with good ratio of success when the btc are only going to be used locally and keep the modification off chain on the "local cache" when it's most likely not to be used outside of the local channel, and only write it to the main chain when the state is more likely to be shared outside of the local cache shared by a limited number of participant , and it should always keep the local cache updated from the main chain when there is a modification in the on chain state. And anytime there is an access to the state of the chain outside of the local cache it should be wrote back to the main network as fast as possible or the request could not be processed before the state is fully synchronized. The efficiency of cache system dépend on how successful it is at guessing when the data is going to be used again in the local cache before a modification on it happen outside of the cache, otherwise there is zero gain.






https://en.m.wikipedia.org/wiki/Temporal_database

https://en.m.wikipedia.org/wiki/Locality_of_reference

Locality is merely one type of predictable behavior that occurs in computer systems. Systems that exhibit strong locality of reference are great candidates for performance optimization through the use of techniques such as the caching, prefetching for memory and advanced branch predictors at the pipelining stage of processor core

Temporal locality
If at one point a particular memory location is referenced, then it is likely that the same location will be referenced again in the near future. There is a temporal proximity between the adjacent references to the same memory location. In this case it is common to make efforts to store a copy of the referenced data in special memory storage, which can be accessed faster. Temporal locality is a special case of spatial locality, namely when the prospective location is identical to the present location.


it's this kind of problematic involved for efficient caching. With a prospective approach on how likely the data is to change in a certain time frame, which allow for faster cacheed access during this time frame.


With transaction it mean you need to predict if the state of the onchain input is going to be potentially accessed within the time frame when it's  used in the local cache. In case it's only going to be a accessed in the local cachenfor a certain period of time, it's worth keeping it in the cache, if the data is shared with other processes, and they need to read it or modify it during that time frame, the cache is useless and data need to be updated from/to the main chain for each operation.

To me the problem with LN is not LN itself, but that there should be no ambiguity on the fact that it's not the same than bitcoin network. It's more this confusion that i find disturbing, like saying writing data in a cache is "just the same" than writing the data disk but just much faster .. Well no it's not the same thing done faster, it's faster precisely because it doesn't do the thing that take the more time and give all the security to the data.

With LN it's a bit the same confusion saying it's just the same than bitcoin network but faster, or more scalable, yes it's faster, and it can scale processing of off chain transaction, but it's still not the same than the real bitcoin network, and it's faster precisely because it bypass the actual processing of the mining node and the global validation through distributed proof of work. And it doesn't solve anything of the actual bitcoin scaling issue. Just bypass it in condition that are still safe in most case, but the case where it matter should be more clear.

It's not even 'just like a system of cache', because if it was so, it would be totally transparent to all the application using the network, the bitcoin network and LN network should be all the time completely synchronized with each other, even if that involve synchronizing with off chain operation. If there is not 100% certainty that the state in the LN network is 100% synchronized all the time with the onchain data, and that operation in the LN network based on out of date data is invalidated, it's not acting like a simple system of cache. Because it can matter in certain case if the operation is happening inside of the LN network or onchain. The two not exactly equivalent. And there could be a difference between asking the balance of an address on the main network and inside of LN network.

But again i think there is room for LN like things, and i don't think 100% of all use of bitcoin need to happen onchain on a fully synchronized local application, and there is room for off chain things, but need to be no ambiguity that the two are completely different things, LN is not solving the true bitcoin scaling problem, and operations happening inside of LN do not provide the same level of security than true on chain operations, even if they are faster and scale better.

And i'm not sure the developers and team are making such a good job at making this clear, and the case where it can matter if the transaction is happening in LN or onchain. And more trying to make it look like it's the same thing but made faster, but it's faster precisely because it's not doing the same thing and bypass the part that actually take the more time.

Well as far as i understand, LN channels can be somehow shut down, via certain glitches or other, and in that case, what would remain of the operation made in that channel ?

And what validity would this journalizing have regarding on chain state if there are difference at the end ?

The problem with caching is not about HD crash, but if the controller is stopped before the cache is a actually wrote, even if the hard drive works well the data is still lost.


Just to push analogy with cache to show certain caveeat, with smp system and cpu cache, there are certain case when the memory is shared with other chips with dma, or virtual pagination, in system with high concurency on the data, cpu cache can become "out of date", even with sse2 there are certain thing to help dealing with this, but as far as i know, most os disable caching on certain shared memory because of all the issues with cache, and instruction reordering etc When having access to up to date data in concurent system is more important than fast access to potentially out of date data.

If LN is to be seen as a cache system , it doesn't look like they are taking all the precautions for it to be really safe.

Cache  are easily safe when all the write access to the data are made throught the same interface doing the caching, which is not the case with bitcoin & LN.

With hard drive it works because all the access goes throught the same controller doing the caching.

But anyway as LN locks the bitcoin on the main chain, it's not even really a true cache system, because the principle of a cache system is to fasten multiple access on the same data, as the bitcoin are locked, the channel have exclusive access to it, and so it's not really to be seen as a true system of blockchain caching.

You know it's not real "on disk" operations when the computer crash or power short age and the filesystem end up corrupted :p otherwise you would just keep all the data on ram disk and just write on the HD on shut down how safe would that really look Write cache aren't not all that fud free

Now with journalized filesystem it mitigiate the possible damage, but having reliable decentralized journalizing on LN would mostly ruin the concept. And in this context having only private journalizing is not changing much.

I also wanted to clear out a certain number of misconception relative to the issue of distribution and scaling.

I see many people speaking about scaling on this forum, but very few seem to really understand what scaling mean.

What is commonly meant by "scaling" is "linear scaling", which mean that a process speed will "scale linearly" with the number of processor on which it can execute. If process scale linearly, if it take one second to process on one cpu, it will take 0.5 sec on 2 two cpu, 0.1 sec on 10 cpu, etc, the processing speed "scale linearly" with the number of processor.

Typically the kind of process that will scale linearly are process that need to process large number of elements who are independent from each others, such as rays in a raytracer, or vertex and polygones, where a unique linear process has to be applied to a certain number of constant elements, the elements can be distributed across different core and processed in parallele which effectively scale linearly the processing speed with the number of processor.

But 95% of application logic doesn't scale linearly, because one task need the result of another task as input first, or it doesn't dépend that much on processing power on a large number of independent elements.

Blockchain tends naturally toward distributed application, like typically web wallets, exchanges, and most of the use are not made entierely throught a local application with all the data and component on the local machine. There are some machine who run nodes and certain part of wallet data caching, and other machines who run the front end via a browser,  so it's already a form of distributed application.

But it doesn't mean processing speed linearly scale with the number of node on the network. The website wont load 1 million time faster if there are 1 millions nodes on the network. It only dépend on the local processing speed of the machine you are connected to, for processing the website content, and keep the blockchain data synchronized with the network.

Blockchain ecosystem is distributed, it doesn't mean all the processing required to run any application that use the blockchain will scale linearly with the number of node on the network.

The way blockchain works it scale close to 0%, all the real processing power needed to process a block transaction is made by a single machine, mostly on a single core, for the whole network. Only the processing of the proof of work actually scale.

And need to see that distribution of application is not necessarily distributed computing, and distributed computing doesn't mean computing that scale linearly.

There are other motive than linearly scaling computing for distributed application, including case of blockchain it's mostly because not all user want to download the whole chain and wallet and all application on their machine to use it, distributed application it can be because certain resources are not available symetrically between different machines on the network, and some component are executed remotely, but again it doesn't necessarily mean the global processing speed of the application scale linearly.

To make a real efficient use of linearly scaling distributed computing in an everyday application, it needs already application that are designed specially to exploit this, that can handle a certain form of pipelined processing that can be efficiently distributed on different processor.

With the approach with modules and dynamic data tree, it's where I want to get at, it allow component to expose an api, and exchange data with other application/modules based on dynamic data type, via json/rpc and js, it provide what is needed to make application that exploit distribution to a degree.

But in the case the distribution is mostly to be able to run complex application in the browser  without having to install anything on the local computer, and having the data and certain part of the processing executed on remote computers, controlled via json/rpc ajax request, more than to have mass scaling.

For 3d rendering the distributed computing is very interesting because lot of the processing actually scale linearly, but for most application logic it's not necessarily the processing power that limit application performance in a way that it can easily scale on the network.

With blockchain principle of having all the data replicated on the network identically with good degree of security, that can still call for mass scalable computing

But with the system of purenode it can create new blockchain easily, so can imagine tokens based application with their own public chain which could make things somehow more scalable if differents applications need to access blockchain in the same time, but for operatïons on bitcoin blockchain or others alt coin, it would not scale the processing speed of the transactions.

But distributed application framework is not all about distributing processing power on different cpu to make it scale, but also making certain resources available on the network through an api, with different requirement regarding digital property and proof of ownership, and different degree of privacy and right control through crypto.

Golem I just read the whitepapper, need to see if there is something that actually works and can be tested.

But to be honest I have very little faith on ethereum approch with smart contract. There are some article on the multichain website that explain all the pb with it, i completly agree with their analysis.

To me smart contract like ethereum is not such a good idea, it looks like a bad compromise to increase the chain complexity compared to bitcore script, without giving a true solid framework to program distributed application, including asynchronous requests, and true application framework.

With purenode being in C, it can make fast vector math, use sse/simd, all kernel api etc better than sandboxed script language, and leave the blockchain logic simple without bloating it with smart contract logic, and keep application logic performant and light, and allow for big number crunching.

And not all application logic is under the form of smart contract.

I would like to see the performance of a raytracer made with go or how well it can exploit graphic card processor or true parallelisation.

I dont want to look pessimistic but a super computer made in smart contract with go it doesn't sound like a good idea at all. With the price of gas who wouldnt look otherwise than something only made to go up, and general scaling issue, id rather use my pocket calculator :p

In the raytracing, float data is loaded from the node into a texture to be processed with glsl, it can be exploited also for other purpose than 3d rendering, which deal with the only issue of js with fast computation of vector data. The most obvious use is 3d rendering, but it can be used to make application who can deal with float computation in the browser.

Javascript still does well with computing most application logic, it can hold a camera or certain number things, but with the glsl it directly boost computational power.

It's not only rendering in the absolute any computation or application logic can be distributed like this with modules, in the spirit like corba or dcom, or e language, but there is already the modules to deal with scene hierarchy, physic computation , and rendering who can work in parallele so it can be distributed easily, specially in case of on chain static data . Even the node could output png fragment and the browser would get the rendered picture via http request on the node without javascript instead of rendering it locally with webgl. Or more of the application logic & rendering can be done with javascript & html5 in the browser.

But for the moment the 3d part is not necessarily the main priority unless there is true demand for it, for the moment the priority is more with tools that revolve around coins based chains.

The other platform I didn't really test, but I dont think there is much framework / platform who fit what I seek to do currently

The only thing I saw who look similar in the idea is e language, they are working on good things, like a system of e cash and smart contract, based on crypto and object relationship but it's not based on blockchain. More like capacity permission system. And more coming from banking sector I believe, so not digging too much on decentralisation/horizontal systems.

http://erights.org/smart-contracts/index.html

It's a bit similar, but using blockchain can simplify this schema for many cases. As the game rule is already hardcoded in the node with built in e cash. Especially with in browser signing, the private key never have to leave the browser in clear useable form , and it doesn't have to be shared with a remote node to sign transaction or other things. And all the node are synchronized and have consensus on blockchain state.

We have a slack channel, iadix.slack.com

It should be a matter of days before a first version of the new site is released, with a rethought design more oriented on blockchain interaction  and in browser key manipulation, to demonstrate html5 feature and security, with a responsive layout, and the bounty campain should be able to start soon after this.

We are still reviewing the options for escrow, also considering going throught a formal lawyer or someone who is in tune with all the legal aspect and term, or picking an operator specialized in icos. Not sure which is best yet, but we need to decide this soon

Trading become much like gambling now days   with just a layer of pseudo expert added to it :p

The only difference with true trading is that there is notion of trading something of value, the good trading is about increasing the perceived value of what you have to sell. Or decrease the value of what you have to buy.

If it become just like making supposition on the value or deciding what it "should worth" entierely subjectively, without the thing being traded having any inherent value at all, it becomes just like poker, and playing on psychology rather than on the estimation of the trading value of something.

Yes, from the moment you put your tokens on the roulette carpet, without true fundation on how the value is supposed to increase  you must be ready to loose it. If you cant afford to loose it, dont put it on the roulette carpet and cry when it doesn't go as you expect .

And true assets who can really take value quickly are very rare. It always take lot of time and effort to create something with true value. Expecting  huge return on investment without real fundation on what make up the actual value is fantasy , scam, ponzi, p&d, inside trading, you name it.

Maybe if you re Lucky enough you can get the good coin at the good moment it's being taken in some kind of trading scheme that make it gain worth quickly, but otherwise that's just the same than gambling.

If you are ready to throw it up once it drop a bit, meaning you are just there for the market profit, and you have no clue of why the value might increase or not, you might have to question your motivation.

And if you know what influence the value on the big line, then you know when to sell or buy. And if you dont,  then dont expect much profits from it. Because it's very rare something take real consitent value without good reason and work behind (aka 2nd law of thermodynamics).

I guess it's all about having solid information on what make the value of the assets, and what can influence it. As coins value has no solid logic behind, it evolve with the trend, media campain, and pump to artificially increase the value on the market, it makes it hard to really predict anything unless you know before what the string pullers are up to.

But regarding the psychological aspect, anyway anything you own you are going to loose it one day, nothing is eternal, is it really worth to loose your serenity over this, need to see the bargain between taking risk and adding stress to yourself, vs what it really bring you.

As it has been said, if something is so vital to you that you cant afford to loose it, dont play it on the stock market on uncertain coins with nothing to back his value up.

If you are on a true logic of having huge funds to manage and invest like big investors, with a view of investing in promising project with risk management on a global view with statistics like insurance companies, it's not the same logic than trying to make a few extra buck on your short pay check. Not the same view and same interest either.

There is terrorism when there is state oppression, it has been eta with franco before, or anarchist/red faction, daesh is same kind of pb, issued from the same lie fabric targeting hopeless people. The baku conférence in the 20's settled the matter for "reds" & jihadism in the
Same time to advance their interest throught civil war and propaganda operation.

The raytracer is in different part, there is the webgl rendering on the demo page, but the data from the scene data is read from the node with the api, only the camera is controlled in the browser, but with better api more interzction can be integrated in the browser app, it's part of the concept of distributed application that not all the code of the application is located on the same machine there are version of the renderer also in software sse multi thread on server/node side, and opengl. ( which can become local if you run the node locally , blockchain make server/client architecture confusing :p)

Originally I dont come from the blockchain world, I started to get into it ~1year ago, but I have experience in video streaming and distributed data, and made a framework oriented around json/rpc and module, but blockchain are very useful to solve one of the pb of distributed application which is data integrity, blockchain can store data on chain and verify it's ownership, and with the system of transactional database can allow for dynamic data too.



The purpose of raytracer is to demonstrate and test capacity to distribute application part and computation on different machine synchronized in real time on the same data. Raytracing rendering also has big advantage to rely on little data, and scale easily, so it's good candidate as example of distributed computing based on blockchain data.

Plus it's pretty and full of physics and vectorial stuff so it's cool :p

Hope that answer your questions

We are currently refunding the website with html5 responsive layout, with the social media bounty and more tool for web promotion and reward

The new version should be online in a few days, thanks for your interest and patience

We are currently refunding our website, with html5 responsive layout, which will include the social media bounty interface also It will possibly be online in the next week, i hope, it's going good for the moment, and will look much better than the current one

Thanks for your patience

It's not always the case