--- Log opened Wed Nov 17 00:00:35 2021
03:27 -!- marco_jardim_ [sid501829@uxbridge.irccloud.com] has quit [Ping timeout: 264 seconds]
03:31 -!- marco_jardim_ [sid501829@uxbridge.irccloud.com] has joined #lnp-bp
18:50 -!- dpc[m] [~dpcmatrix@2001:470:69fc:105::1:2020] has joined #lnp-bp
18:52 < dpc[m]> Hi. I was going through videos on the YT channel, and after hours of watching I feel like I know a lot of stuff high and low level, except how RGB works in principle. Anyone can recommend what should I read/watch to actually get a good gist of it?
20:45 < dpc[m]> I guess the fundamental question I have is - how does RGB enforce anything. There is no consensus. So what are these smart contracts event doing? Who runs them really? Custodian of an asset underlying given token and users of this token? 
23:00 < dr-orlovsky> The consensus on which state transition is valid is delegated to the layers above: bitcoin transaction finality, coming from either the fact that transaction is mined in the longest chain - or from the fact that it is part of lightning channel where the party is participating (i.e. controlling channel updates). No other consensus enforements here
23:00 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has joined #lnp-bp
23:00 -!- lederstrumpf[m] [~lederstru@2001:470:69fc:105::bc8] has joined #lnp-bp
23:01 < dr-orlovsky> As for the internal state validity, it is enforced by the owners of that state: it is validated locally (that's why it is a client-side-validation) and if it is invalid for you, you are just not accepting it
23:01 < dr-orlovsky> only parties of the contract need to validate, and validate the parts of the contract that concerns them
23:02 < dr-orlovsky> it is just the case of blockchain that everybody is a party of the contract, but you may think of RGB state validation as a form of UASF enforcement with no of users equal to contract participants and much less than in blockchain
23:29 < dpc[m]> "Owners of the state" is too abstract to me at the moment. I'm trying to map these abstractions into some example real-life-like scenario.
23:29 < dpc[m]> Let's say a game issues an NFT representing some armors, swords and other stuff in the game.
23:30 < dpc[m]> So they create a contract, and then all owners of these swords and armors keep proofs of how they were changing hands?
23:32 < dpc[m]> And then present current valid proof that they own it, when they want to show the game that they are the current owner?
23:33 < dpc[m]> Maybe it is somewhere in the videos I haven't watched, but in the stuff I went through I couldn't spot examples like that. "This actor runs this, this validates that, so it proofs this" and so on.
23:35 < dpc[m]> Also, it's unclear to me how such smart contracts would have any ... yyyy... side-effects? Like - we lock some bitcoins in a multisig, and then it gets released if something happened (or didn't), etc.
23:38 < dpc[m]> I guess they can't because blockchain layer is not aware of these, so stuff like this would always have to happen through some kind of custodians, maybe DLCs?
23:38 < dr-orlovsky> you need to study/understand concept of single-use-seal. Pls refer to:
23:38 < dr-orlovsky> https://www.youtube.com/watch?v=gGPLYfWOb_8&t=1s
23:38 < dpc[m]> I think I do understand single-use-seal. That one was explained multiple times. :)
23:39 < dr-orlovsky> So that is the unit that both defines ownership concept: the owner of UTXO defined as a single-use-seal is the owner of the state linked to it
23:39 < dr-orlovsky> single-use-seals also prevent double-spending and structure "consensus enforcement"
23:39 < dpc[m]> Sure, I get that, but "owning state" is very abstract.
23:39 < dr-orlovsky> owning state meaning having the right to update it
23:40 < dr-orlovsky> in which way? In a way that is defined by the contract creators
23:40 < dr-orlovsky> contract creators use RGB schema to define that rules and all possible forms of state transitions (state changes/updates)
23:42 < dpc[m]> And then users valida state transitions against such a schema?
23:47 < dr-orlovsky> correct
23:47 < dr-orlovsky> verification consists of two part: (1) verifying history of single-use-seals closings (2) verifying state transitions against schema
23:47 < dpc[m]> Is there any room for interactivity between contract schemas here? What would be best mechanism for eg. swapping items from two different games (different schemas) between users?
23:48 < dr-orlovsky> atomic swaps or lightning channels. Currently there is no interaction between contracts on the level of RGB. Theoretically it can be added to the design (and we are doing research on this topic), but it will introduce tremendous attack surfices and just replicate mistakes of Ethereum approach
23:49 < dr-orlovsky> so we are looking & researching provably secure contracts composability (using also category theory)
23:49 < dpc[m]> In the original https://www.youtube.com/watch?v=1U-1xkhJeEo it seemed like ownership history keeps growing with every state change (each use of a single-use-seal). Is that still the case?
23:49 < dr-orlovsky> it is
23:49 < dr-orlovsky> but (a) not over lightning network (where you just update the recent state transition with the new one, like with transactions)
23:50 < dpc[m]> So after 10 years of trading some game item, it might have a rather huge state history...
23:50 < dr-orlovsky> and (b) if you have a centralized issuer it may provide service of re-issuing asset & clearning history
23:50 < dpc[m]> Oh. OK. 
23:50 < dr-orlovsky> > So after 10 years of trading some game item, it might have a rather huge state history...
23:50 < dpc[m]> That's one part that I don't understand on the technical level. How does LN enforce single close of a single use seals. Which video would be the best to watch to understand it?
23:50 < dr-orlovsky> still orders of magnitude smaller than the size of blockchain of any other smart contract system
23:51 < dpc[m]> > re-issuing asset & clearning history
23:51 < dpc[m]> Oh. OK. That works, I guess.
23:51 < dr-orlovsky> LN does not enforces single-use-seal closing. Instead, when it updates channel state from one commitment transaction to another, it also updates/replaces all single-use-seals associated with it (automatically, since they are linked to the commitment transaction)
23:52 < dr-orlovsky> and the single-use-seals just follow the destiny of the commitment transaction enforcement
23:52 < dr-orlovsky> in terms of single-use-seals / consensus enforcements / double spending / immutability we just piggy-back to blockchain and lightning security through single-use-seals link
23:53 < dpc[m]> My mind is twisted here...
23:53 < dr-orlovsky> you can spend UTXO only once, right? Even in lightning, right?
23:54 < dr-orlovsky> so the state linked to that UTXO can be changed only once, both in bitcoin onchain and in lightning
23:54 < dpc[m]> An owner of UTXO on blockchain can't go back and change how it was spent. But on LN ... how can other people trust in "commitment" in a tx that didn't hit the blockchain?
23:55 < dr-orlovsky> well, this is a question about how lightning work, and there is a plenty of material on that topic. This is unrelated to RGB, we assume that lightning is secure (it can be proved btw, but I do not see why I should repeat stuff written million times before by people much better in explaining than me)
23:56 < dpc[m]> > Even in lightning, right?
23:56 < dpc[m]> My mental model is that utxos are not being spent. They are locked in a channel (multisig) and participants have a protocol to update not yet broadcasted transactions that return the funds where they should go.
23:56 < dpc[m]> So ... participants in such a LN channel would also have to verify RGB contracts in it every time they sign an update for the other person?
23:57 < dr-orlovsky> yes
23:57 < dpc[m]> Ok... I guess my mind untwisted a bit. Thanks.
23:57 < dpc[m]> No multip-hops are involved here, right?
23:58 < dr-orlovsky> thank you for your interest! It took about a year of my time to finally understand concept of Peter Todd on single-use-seals, so yes, that is twisted :)
--- Log closed Thu Nov 18 00:00:39 2021