Tari Protocol Discussion 37

18:09 <Hansie>  Hi there
18:10 <Hansie>  We have not discussed VN registration in a long time
18:11 <Hansie>  That would be `RFC-0322: Validator Node Registration`
18:11 <Hansie>  Anyone care to discuss?
18:12 <simian_za>  Sho, it has been a while. I suppose it will be worth revisiting now that we have spent more time on the base layer stuff
18:12 <Hansie>  Yip
18:13 <simian_za>  So the goal of the registration was to tie a VNs identity to a base layer transaction with a cost that mitigates Sybil attacks right?
18:14 <Hansie>  Yes, that sounds about right.
18:14 <neonknight64>  and to obtain a node ID for the communication layer
18:14 <simian_za>  We didn't want the registration fee to be paid to anyone in particular, we just wanted to tie it up so it cannot be spent for a certain period
18:16 <Hansie>  So let us continue with `Assumptions - VN Registration: `, then `Assumptions - Game theory` and lastly `Use cases:`. Is that a plan?
18:16 <neonknight64>  we also need a mechanism to allow the registration to be renewed.
18:16 <stanimal>  How long would that be locked up for?
18:17 <Hansie>  We previously had suggestions of fixed term (e.g. 6 months)
18:18 <simian_za>  And this registration can be used for the VN to participate in multiple assets?
18:20 <Hansie>  Yes, I think so. The amount and time-lock period could be confirmed with modelling  -  'Network Analysis'
18:21 <stanimal>  I would say so, that would allow them on the network and allow them to be discoverable
18:22 <simian_za>  Cool, well if it allows for reuse then 6 months seems reasonable
18:22 <stanimal>  ^ Join the network as a VN, they would still be able to join the network (as a wallet?) to pay the registration fee presumably
18:23 <simian_za>  What do you mean by wallet? We can't expect end-users with asset wallets to have to register in this way?
18:24 <simian_za>  Hansie: I feel it might be more useful to start with the `Use cases` so why know what functionality we need this process to serve
18:25 <neonknight64>  Stanimal, I believe the wallet will be a separate entity with its own node id,  but the wallet can pay the registration fees on behalf of the VN allowing the VN to join with the registered node id
18:25 <stanimal>  Well it's a bit of a chicken and egg situation, in order to obtain your NodeID to be a VN on the network, you'll need some way to pay the registration and claim your NodeID
18:26 <simian_za>  but the payment happens on the base layer where NodeIDs can be chosen by the wallets?
18:26 <stanimal>  Yup, guess this could be part of the VN software
18:27 <neonknight64>  Wallets do not propagate messages and can derive a node id from the its identification public key
18:28 <neonknight64>  no base layer registration needed
18:28 <simian_za>  Ok, so the purpose of VNs registering in this way is to secure a NodeID for use on the second layer that is not chosen or derived by their wallet but by the base layer network making it much more secure
18:29 <simian_za>  they need this kind of NodeID if they want to participate in DAN committees
18:29 <stanimal>  Join as a wallet, pay the registration, obtain the NodeId and rejoin with the new NodeId - correct, the base layer is a random oracle
18:31 <simian_za>  So that's really the main use case here, is to make sure that the NodeID that they are using when accepting and sending messages as part of an Asset committee comes from a NodeID that was fairly chosen by the random oracle
18:31 <Hansie>  Makes sense
18:32 <Blackwolfsa>  It's only the VNs that need that random ID right? 
18:32 <simian_za>  it needs to cost something so that its expensive to try "mine" a NodeID for malicious purposes
18:33 <Hansie>  I would say properly registered and identifiable, not really 'fairly chosen by the random oracle'
18:33 <stanimal>  Exactly, prevent adaptive join/leave attacks and help randomize network topology - which benefits the network as a whole (base layer included)
18:33 <simian_za>  well it is though, maybe not fairly but it was produced by the random oracle. Thus the NodeID they receive will be "random"
18:34 <simian_za>  so nix the word "fairly"
18:34 <Hansie>  Ok, understood
18:34 <Hansie>  Blackwolfsa: What else could need the random ID?
18:35 <simian_za>  I can't think of another entity right now that would need the random NodeID
18:35 <neonknight64>  Blackwolf.. Wallets, Token Wallets, Base Nodes and Validator Nodes need random ids
18:35 <neonknight64>  but only VNs need to register for them
18:35 <Blackwolfsa>  Why would they need random ID? 
18:35 <Blackwolfsa>  They could chose their own ids they just need to be unique? 
18:36 <stanimal>  However, all except VNs are currently trusted to create a random ID
18:36 <simian_za>  the registration process is the only way to ensure the NodeID is properly random. It would be ideal for them all to properly random though but can't really be enforeced
18:37 <stanimal>  Ye without some kind of enforceable distributed RNG
18:37 <simian_za>  Blackwolfsa: an attacker can chose NodeIDs in a malicious way to do things like eclipse a victim but ja can't really be enforced. The VNs are actually our best defense against this
18:37 <neonknight64>  I think every entity should have an identification key pair and a node id derived from this key pair or obtained from registering
18:38 <Hansie>  So the registration UTXO will be time-locked and mined in the base layer... and that process will be used to identify/create the VN ID?
18:38 <simian_za>  Hansie: Yes
18:38 <Hansie>  So what happens when the lock expires?
18:38 <stanimal>  neonknight64 That would mean a cost for anyone joining the network?
18:39 <Blackwolfsa>  I think we need to allow them to extend the registration 
18:40 <Blackwolfsa>  But if that expires they should be seen as unregistered 
18:40 <stanimal>  oh nm, reread your comment - keypair OR registration ;)
18:40 <simian_za>  I guess they can spend that UTXO, how will they be able to maintain their registration to keep their NodeID?
18:40 <simian_za>  Maybe we should define what metadata the UTXO has? It is not just a plain mimblewimble UTXO
18:41 <Hansie>  Yes. Maybe the registration UTXO can be spent only if it is a re-commitment to an increased term; any other spend will not be allowed. If it lapses the VN is out of action.
18:43 <neonknight64>  Can that be done using some for of consensus rule or script?
18:43 <Hansie>  neonknight64: Can the VN ID be determined before the Tx is mined?
18:43 <neonknight64>  form*
18:44 <neonknight64>  hansie, do you mean NodeID? No the NodeID cannot be determined before the time
18:44 <neonknight64>  it must be mined
18:44 <simian_za>  Hansie: that is a good point...the NodeID will need to be derived from some data involved in mining the transaction
18:44 <simian_za>  so how can it be included in the metadata?
18:45 <Hansie>  Great, so the VN nodeID cannot be part of the meta data :-)
18:46 <simian_za>  hmm that's tricky. We can't reference the first tx if we try extend the timelock because of tx pruning...
18:46 <neonknight64>  I original NodeID could maybe be in the metadata when the registration is renewed as the new block will produce a different NodeID
18:46 <simian_za>  How will someone be able to verify the NodeID if the original tx gets pruned?
18:48 <neonknight64>  Not sure, but an invalid renewal should not appear in the base layer if the NodeID transfer is incorrect.
18:48 <Hansie>  So we can have (a) time-lock (b) type=VN registration (c) counter for consecutive registrations (d) previous nodeID (e) ...
18:48 <Blackwolfsa>  Yes but we need to be able to verify that
18:50 <Hansie>  A registration UTXO can only be spent/renewed by the owner as the only person that can open that commitment
18:51 <Hansie>  Miners can validate the counter and link to the previous UTXO
18:51 <simian_za>  Ok so another aspect of the UTXO will also be that a 3rd party needs to be able to verify the amount that is locked up
18:52 <simian_za>  Hanise, but the previous UTXO will be pruned eventually
18:52 <Hansie>  That one is potentially tricky
18:53 <Hansie>  Yes, so the current UTXO identifies the previous UTXO and times the registration has been carried forward
18:55 <simian_za>  Hmmm, going to have to ponder this some more
18:57 <Hansie>  Agreed
18:57 <simian_za>  Obviously, we could just ensure that these kind of TXs are not pruned but that is not ideal at all
19:01 <Blackwolfsa>  But I think we should try out at best to avoid that
19:05 <stanimal>  This may be dumb, but couldn't you hash the kernel for the nodeID - since there will be a base layer fee the miners choose the blinding factor making the kernel random each time (i.e not chosen by the VN)
19:09 <Blackwolfsa>  But then it changes every time if I understand you correctly 
19:10 <simian_za>  Could reference the first kernel some how, that doesn't get pruned
19:11 <Blackwolfsa>  That could work..