--- Log opened Fri May 21 00:00:01 2021
01:22 < nubis> hi zoranc, sorry I can't help. But your comment caught my eye because by what you're mentioning I guess there's a VM for client validated state already. A quick search for RGB AluVM doesn't show anything interesting. could you share a link? thanks!
02:46 -!- nubis [~nubis@185.227.215.45] has quit [Ping timeout: 246 seconds]
02:49 -!- nubis [~nubis@185.227.215.45] has joined #lnp-bp
03:24 -!- zoranc [2e2f5857@gateway/web/cgi-irc/kiwiirc.com/ip.46.47.88.87] has joined #lnp-bp
04:53 -!- nubis [~nubis@185.227.215.45] has quit [Ping timeout: 240 seconds]
04:53 -!- nubis [~nubis@185.227.215.45] has joined #lnp-bp
05:21 < dr-orlovsky> zoranc: hi! Sorry, in business trip these days and rarely at notebook. The state transitions are not created by AluVM; they are created by other means. AluVM only validates the correctness of state changes in existing state transitions.
05:22 < dr-orlovsky> nubis: NTFs are covered by RGB21 standard, but no working code was released yet; it will take several months to get it working on my side, so probably we can't be in time with your client :(
05:23 < dr-orlovsky> was not familiar with EIP-712, will read it
05:23 < zoranc> dr-orlovsky: Thanks for the answer. That clarifies lot of things! It means both new and old state are read-only...
05:25 < zoranc> It means that abusing the AluVM for more complex computations would need to rely on "string" variables as kind of free use memory...
05:29 -!- nubis [~nubis@185.227.215.45] has quit [Ping timeout: 246 seconds]
05:32 -!- nubis [~nubis@185.227.215.45] has joined #lnp-bp
05:50 -!- nubis [~nubis@185.227.215.45] has quit [Ping timeout: 260 seconds]
05:54 -!- nubis [~nubis@185.227.215.45] has joined #lnp-bp
06:14 < dr-orlovsky> well, the main reason of not using AluVM for transition construction is the absence of a rationale for doing so :) VM is needed to deterministic verification independently from hardware. There is no need for "deterministic" state transition construction, and by using AluVM for that purpose we will just make devs live much harder without gaining anything
06:21 -!- nubis [~nubis@185.227.215.45] has quit [Ping timeout: 265 seconds]
06:31 -!- nubis [~nubis@185.227.215.45] has joined #lnp-bp
06:35 -!- nubis [~nubis@185.227.215.45] has quit [Ping timeout: 265 seconds]
06:35 -!- nubis [~nubis@185.227.215.45] has joined #lnp-bp
06:49 < zoranc> Thank for the clarification! I guess it all makes perfect sense in the context of the client side validated data.
06:49 -!- zoranc [2e2f5857@gateway/web/cgi-irc/kiwiirc.com/ip.46.47.88.87] has quit [Quit: Connection closed]
13:23 -!- zkao[m] is now known as zkao
14:53 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-tvrtepyvckaueaun] has quit [Read error: Connection reset by peer]
15:05 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-rvxlyimkilehipbh] has joined #lnp-bp
18:14 -!- zkao [~zkao@185.183.195.146] has quit [Ping timeout: 260 seconds]
18:14 -!- zkao [~zkao@185.183.195.146] has joined #lnp-bp
--- Log closed Sat May 22 00:00:02 2021