Zsh completion path check broke upgrade

Bug report
Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to Homebrew again.

[x] ran brew update and can still reproduce the problem?
[x] ran brew doctor, fixed all issues and can still reproduce the problem?
[x] ran brew config and brew doctor and included their output with your issue?

What you were trying to do (and why)
I was trying to run brew upgrade, as i do daily, to upgrade installed software
What happened (include command output)
It hanged. Multiple times.

Command output

[maciejp:~] 2s % brew upgrade
Updating Homebrew...
==> Auto-updated Homebrew!
Updated Homebrew from de1afcbfc to 20af7ee11.
Updated 6 taps (puppetlabs/puppet, homebrew/cask-versions, homebrew/core, homebrew/cask, homebrew/cask-fonts and homebrew/cask-drivers).
==> New Formulae
docui
==> Updated Formulae
Updated 322 formulae.
==> New Casks
berrycast                                      font-castoro                                   pushplaylabs-sidekick
blackhole-16ch                                 font-langar                                    raze
blackhole-2ch                                  font-libre-barcode-ean13-text                  snipy
clocker                                        font-nerko-one                                 stems
coscreen                                       font-recursive-code                            unity-appletv-support-for-editor
font-andika-new-basic                          font-syne-mono                                 unity-linux-il2cpp-support-for-editor
font-ballet                                    font-syne-tactile                              unity-linux-support-for-editor
font-big-shoulders-inline-display              font-texturina                                 unity-macos-il2cpp-support-for-editor
font-big-shoulders-inline-text                 font-trispace                                  utm
font-big-shoulders-stencil-display             font-xanh-mono
font-big-shoulders-stencil-text                memory-clean-3
==> Updated Casks
caffeine ✔                         font-glow-sans-j-normal            liya                               sauerbraten
activedock                         font-glow-sans-j-wide              loading                            scapple
airtool                            font-glow-sans-sc-compressed       logitech-options                   screaming-frog-seo-spider
amadeus-pro                        font-glow-sans-sc-condensed        logmein-client                     screen
amorphousdiskmark                  font-glow-sans-sc-extended         loom                               scroll-reverser
android-studio-preview-canary      font-glow-sans-sc-normal           ltspice                            scrutiny
anydo                              font-glow-sans-sc-wide             lyx                                segger-embedded-studio-for-arm
anytrans                           font-glow-sans-tc-compressed       macbreakz                          segger-ozone
anzeigenchef                       font-glow-sans-tc-condensed        macclean                           sessionrestore
apptivate                          font-glow-sans-tc-extended         macgamestore                       sherlock
aqua-data-studio                   font-glow-sans-tc-normal           mactracker                         sigil
aria2d                             font-glow-sans-tc-wide             macx-video-converter-pro           sipgate-softphone
arq                                font-iosevka                       macx-youtube-downloader            sirimote
atlauncher                         font-iosevka-aile                  magicprefs                         sky-ticket
axe-edit-iii                       font-iosevka-curly                 mailmaster                         smooze
back-in-time                       font-iosevka-curly-slab            manictime                          snagit
balenaetcher                       font-iosevka-etoile                mediahuman-audio-converter         softorino-youtube-converter
bigsur-cache-cleaner               font-iosevka-slab                  medibangpaintpro                   sonarr
binary-ninja                       font-iosevka-sparkle               meshlab                            spideroak-share
birdfont                           font-iosevka-ss01                  meta                               srware-iron
blocs                              font-iosevka-ss02                  mic-drop                           stand
blu-ray-player-pro                 font-iosevka-ss03                  microsoft-edge-beta                stats
blueharvest                        font-iosevka-ss04                  middle                             subsurface
bluejeans                          font-iosevka-ss05                  miro                               superproductivity
boost-note                         font-iosevka-ss06                  mobirise                           surfeasy-vpn
box-sync                           font-iosevka-ss07                  modern-csv                         surfshark
brave-browser-dev                  font-iosevka-ss08                  monal                              swift-publisher
canon-eos-utility                  font-iosevka-ss09                  moneymoney                         syncovery
captin                             font-iosevka-ss10                  multitouch                         syntax-highlight
chatwork                           font-iosevka-ss11                  mweb                               tableplus
chromium                           font-iosevka-ss12                  nagbar                             teambition
chronicle                          font-iosevka-ss13                  name-mangler                       teamdrive
clash-for-windows                  font-iosevka-ss14                  netbeans                           techsmith-capture
clashx                             font-juliamono                     netron                             teensy
classicftp                         font-sarasa-gothic                 netxms-console                     tencent-meeting
cleanmymac                         font-source-han-sans               nifty                              texpad
cncnet                             font-tt2020                        nodeclipse                         texshop
coccoc                             fontlab                            noisy                              thonny-xxl
coin-wallet                        fork                               nordic-nrf-connect                 tiger-trade
command-tab-plus                   freeter                            nsregextester                      tigervpn
connectiq                          fsnotes                            odrive                             timer
continuity-activation-tool         fstream                            ondesoft-audiobook-converter       tofu
corsair-icue                       gameranger                         one-switch                         transcribe
daedalus-flight                    geomap                             openbazaar                         treesheets
daedalus-mainnet                   get-iplayer-automator              openphone                          tribler
dashlane                           get-lyrical                        opensesame                         trilium-notes
datagraph                          gitfox                             openxcom                           tutanota
datagrip                           githubpulse                        opera-developer                    twitch
dbeaver-enterprise                 globalmeet                         opera-neon                         tyme
dbkoda                             glyphs                             pagico                             ubersicht
dcv-viewer                         gns3                               pdf-expert                         ubiquiti-unifi-controller
deathtodsstore                     gog-galaxy                         pdf-expert-beta                    uc-one
deepl                              gopanda                            pdf-squeezer                       unified-remote
default-folder-x                   gotiengviet                        pdfelement                         unity
discord                            gqrx                               perimeter81                        unity-android-support-for-editor
disk-drill                         happymac                           phonebrowse                        unity-ios-support-for-editor
displaperture                      hazeover                           phoneclean                         unity-lumin-support-for-editor
djview                             hbuilderx                          phonetrans                         unity-webgl-support-for-editor
dmm-player                         hessenbox-da                       pitchperfect                       unity-windows-support-for-editor
docker-edge                        home-inventory                     popo                               vesta
dosbox                             hookshot                           porting-kit                        veusz
doubletwist                        houseparty                         praat                              videofusion
dropbox-beta                       hue-topia                          privatevpn                         vienna
edex-ui                            hype                               profind                            vipriser
elecom-mouse-assistant             icollections                       proxifier                          virtualhere
electrocrud                        iina-plus                          psychopy                           virtualhereserver
electrum                           inav-configurator                  puppet-bolt                        waves-central
element                            infoflow                           purevpn                            whatsapp
elgato-video-capture               insomnia                           qnap-external-raid-manager         whatsize
elgiganten-jotta                   insomnia-designer                  qobuz                              window-switch
elmedia-player                     install-disk-creator               qownnotes                          winx-hd-video-converter
eloston-chromium                   instasizer                         qqbrowser                          wowmatrix
elpass                             inxmail-professional               quickhue                           x-swiftformat
emailchemy                         iriunwebcam                        qutebrowser                        xnconvert
epichrome                          ishowu                             raiderio                           yakyak
eqmac                              iswiff                             raindropio                         yinxiangbiji
exodus                             jami                               rapidminer-studio                  yojimbo
expressvpn                         jandi                              recents                            youdaonote
feishu                             jedit-omega                        recordit                           youtube-to-mp3
figma                              jqbx                               rectangle                          zeitgeist
flickr-uploadr                     keeper-password-manager            refined-github-safari              zeplin
flipper                            klokki                             remember-the-milk                  zerotier-one
flow                               knock                              remote-buddy                       zettlr
folx                               latexdraw                          resxtreme                          zoc
font-anonymous-pro                 launchpad-manager                  rightfont                          zoho-docs
font-glow-sans-j-compressed        league-of-legends                  rocks-n-diamonds                   zoho-workdrive
font-glow-sans-j-condensed         lens                               rss
font-glow-sans-j-extended          liclipse                           rsyncosx
==> Deleted Casks
blackhole                   canary                      kiwi-for-g-suite            manuscripts                 noteplan
==> Upgrading 11 outdated packages:
nghttp2 1.42.0 -> 1.42.0_1
gtk+3 3.24.23 -> 3.24.24
awscli 2.1.5 -> 2.1.7
sqlite 3.33.0 -> 3.34.0
pcre2 10.35 -> 10.36
youtube-dl 2020.12.2 -> 2020.12.7
eslint 7.14.0 -> 7.15.0
pugixml 1.11 -> 1.11.1
pulumi 2.15.0 -> 2.15.1
poppler 20.11.0 -> 20.12.0
imagemagick 7.0.10-45 -> 7.0.10-46
==> Upgrading sqlite 3.33.0 -> 3.34.0
==> Downloading https://homebrew.bintray.com/bottles/sqlite-3.34.0.mojave.bottle.tar.gz
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/64729f1390a8379a9c7e6c8579dda0a0c450328868ebeb7e7e632aa448bda2d1?response-content
######################################################################## 100.0%
==> Pouring sqlite-3.34.0.mojave.bottle.tar.gz
==> Caveats
sqlite is keg-only, which means it was not symlinked into /usr/local,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.
If you need to have sqlite first in your PATH run:
echo 'export PATH="/usr/local/opt/sqlite/bin:$PATH"' >> ~/.zshrc
For compilers to find sqlite you may need to set:
export LDFLAGS="-L/usr/local/opt/sqlite/lib"
export CPPFLAGS="-I/usr/local/opt/sqlite/include"
For pkg-config to find sqlite you may need to set:
export PKG_CONFIG_PATH="/usr/local/opt/sqlite/lib/pkgconfig"
==> Summary
🍺  /usr/local/Cellar/sqlite/3.34.0: 11 files, 4MB
Removing: /usr/local/Cellar/sqlite/3.33.0... (11 files, 4MB)
Removing: /Users/maciejp/Library/Caches/Homebrew/sqlite--3.33.0.mojave.bottle.tar.gz... (2.0MB)
==> Upgrading gtk+3 3.24.23 -> 3.24.24
==> Downloading https://homebrew.bintray.com/bottles/gtk%2B3-3.24.24.mojave.bottle.tar.gz
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/798c425db2e840d23c95298fb44cadbd5b1d944240a3ccd0ae369386b3120ca9?response-content
######################################################################## 100.0%
==> Pouring gtk+3-3.24.24.mojave.bottle.tar.gz
==> /usr/local/opt/glib/bin/glib-compile-schemas /usr/local/share/glib-2.0/schemas
==> /usr/local/Cellar/gtk+3/3.24.24/bin/gtk3-update-icon-cache -f -t /usr/local/share/icons/hicolor
==> /usr/local/Cellar/gtk+3/3.24.24/bin/gtk-query-immodules-3.0 > /usr/local/lib/gtk-3.0/3.0.0/immodules.cache
🍺  /usr/local/Cellar/gtk+3/3.24.24: 716 files, 51MB
Removing: /usr/local/Cellar/gtk+3/3.24.23... (714 files, 51.0MB)
Removing: /Users/maciejp/Library/Caches/Homebrew/gtk+3--3.24.23.mojave.bottle.tar.gz... (14.5MB)
==> Upgrading awscli 2.1.5 -> 2.1.7
==> Downloading https://homebrew.bintray.com/bottles/awscli-2.1.7.mojave.bottle.tar.gz
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/1253c0cbd62bf978ad0a0f104b34a1d8a968053c14a8c19e5fbbf4b6e1fc5719?response-content
######################################################################## 100.0%
==> Pouring awscli-2.1.7.mojave.bottle.tar.gz

This is the point when it hanged. I looked at pstree what it was doing:

 |-+- 56107 maciejp alacritty
 | \-+= 56108 maciejp /usr/local/bin/zsh --login
 |   \-+= 56605 maciejp /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/current/bin/ruby -W0 --disable=gems,did_you_mean,rubyopt /usr/local/Homebrew/Library/Homebrew/brew.rb upgrade
 |     \--- 60956 maciejp /bin/zsh -ic echo $FPATH

Killing /bin/zsh made it continue and emit a caveat:

==> Caveats
The "examples" directory has been installed to:
  /usr/local/share/awscli/examples

zsh completions and functions have been installed to:
  /usr/local/share/zsh/site-functions

/usr/local/share/zsh/site-functions is not in your zsh FPATH!
Add it by following these steps:
  https://docs.brew.sh/Shell-Completion#configuring-completions-in-zsh
==> Summary
🍺  /usr/local/Cellar/awscli/2.1.7: 11,783 files, 87.4MB
Removing: /usr/local/Cellar/awscli/2.1.5... (12,340 files, 90.5MB)
Removing: /Users/maciejp/Library/Caches/Homebrew/awscli--2.1.5.mojave.bottle.tar.gz... (19.9MB)
==> Upgrading pcre2 10.35 -> 10.36
==> Downloading https://homebrew.bintray.com/bottles/pcre2-10.36.mojave.bottle.tar.gz
[…]

This repeated for every package that was installing ZSH completion functions.

What you expected to happen
I expected brew to run and upgrade my packages. I would be happy with an unnecessary notice about site-functions, or with no notice at all (even if it would be necessary), or with being able to turn the extra helpfulness off.
I expected brew not to run an "interactive" shell when it's not interactive, in a wrong version. Homebrew was started from a zsh session, in zsh that brew itself installed, first on $PATH, and with $SHELL set to /usr/local/bin/zsh. Homebrew really went out of its way to pick the wrong zsh.
I don't know if finding correct zsh would help. My .zshrc is complex, and interactive shells are supposed to be interactive. Maybe there would be a workaround, but it won't ever be universal, because I am allowed to put sleep 3600 in my .zshrc for no reason and it shouldn't break Homebrew.
Step-by-step reproduction instructions (by running brew commands)

have homebrew with #9404 applied
have something interesting in ~/.zshrc
run brew upgrade or brew install of a package that has ZSH completion
watch brew run zsh -i non-interactively using wrong zsh and get confused if zsh tries to be interactive

Output of brew config and brew doctor commands

[maciejp:~] 11m2s % brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: A newer Command Line Tools release is available.
Update them from Software Update in System Preferences or run:
  softwareupdate --all --install --force

If that doesn't show you an update run:
  sudo rm -rf /Library/Developer/CommandLineTools
  sudo xcode-select --install

Alternatively, manually download them from:
  https://developer.apple.com/download/more/.

Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
  terraform
  dash

Warning: Homebrew's sbin was not found in your PATH but you have installed
formulae that put executables in /usr/local/sbin.
Consider setting the PATH for example like so:
  echo 'export PATH="/usr/local/sbin:$PATH"' >> ~/.zshrc
[maciejp:~] 33s 1 % brew config
HOMEBREW_VERSION: 2.6.0-133-g20af7ee
ORIGIN: https://github.com/Homebrew/brew
HEAD: 20af7ee11fcf1b186eb5978ba4871a2dba984a3c
Last commit: 4 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 1a60e2e6309cd922b8dc50cd514472daa71b5fb2
Core tap last commit: 62 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: vim
HOMEBREW_MAKE_JOBS: 12
Homebrew Ruby: 2.6.3 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/bin/ruby
CPU: dodeca-core 64-bit kabylake
Clang: 11.0 build 1100
Git: 2.29.2 => /usr/local/bin/git
Curl: 7.54.0 => /usr/bin/curl
Java: 1.8.0_275
macOS: 10.14.6-x86_64
CLT: <IP_ADDRESS>.1.1562985497
Xcode: 11.3.1
[maciejp:~] 2s %

For the record, the following snippet on top of ~/.zshrc helps (by checking executable path and exiting early if it's /bin/zsh):
if [[ "$(lsof -p $$ | awk '$4 == "txt" && /\/zsh$/ { print $9 }')" == '/bin/zsh' ]]; then
    return
fi

How do you suggest that we query FPATH?

My approach would be not to query it at all because we can't predict what user has in their config (including a completely broken config because they don't run zsh and don't care). Just display a message that they might need to add site-functions directory to fpath. Then I'd make it possible to turn this message off when user already read and applied it (or knows they won't need it because they don't use zsh), something like "to never see this message again, run `brew dismiss zsh-completion-caveat"", which would be universally helpful for all kinds of messages.
If we try to check, it should be safeguarded with timeouts, exit status checks (which also don't seem to be there because homebrew didn't mind when I just killed the hanging zsh), stdin redirected from /dev/null to break most attempts at reading input from user (they still might hang in a retry loop if badly written, but it should catch most interaction attempts) and written with defensive programming matching the awareness that we literally execute arbitrary shell that might go wrong in all sorts of ways. Writing it defensively enough to be robust feels beyond my skill level – which is why my first instinct would be to find a way to avoid writing it at all.

I second this.
Experienced this very issue today.

I don't see an obvious reason why CI tests were skipped for #9404

@jottr They weren't.

My bad!
Thanks for the quick fix.

@jottr No worries, thanks for the kind words!


ActionState act function is not abstract

There shouldn't be a default act function for ActionState. Any ActionState should always need to define it's own act function.

Well for one (maybe only) counterexample, an IdleState does not want to do anything in act.

Right, but that isn't a default behavior. That should be defined in the idle action itself.

Yea this is an oversight by me I think. It should be abstract as anyone extending the ActionState should be forced to think about their act() function


How i can make a MakeReadOnly() field Editable again ?

I am facing this problem when using SPUtility.js inside my SP 2013 on-premises, now i want to do the following inside my sharepoint 2013 list forms:-

Set a Choice field as ReadOnly.
then chnage the value of the ReadOnly Choice field using SPUtility or pure JavaScript.

now to make my Choice field ReadOnly i use the following SPUtility method:-
SPUtility.GetSPFieldByInternalName('OrderStatus').MakeReadOnly();
but when i tired to change the value of the list after making it ReadOnly, as follow:-
SPUtility.GetSPFieldByInternalName('OrderStatus').SetValue("In Progress");
OR using pure javascript appraoch as follow:-
$('[id^="OrderStatus"]').val("In Progress");
i was unable to change the status value? so can anyone adivce how i can handle this problem? so i can change the value of a ReadOnly list?
second point, is there a way i can temporary remove the MakeReadOnly() effect on the field? if this is possible , then i can remove the ReadOnly effect on the Choice field, then set its value, then make it as ReadOnly again ?
Thanks

Hey John,
It should be able to set the value of the field even if it is read only so that is strange.
Have you tried SPUtility.GetSPFieldByInternalName('OrderStatus').MakeEditable(); ?
Thanks,
Kit

It should be able to set the value of the field even if it is read only so that is strange.

so what could be causing this issue in my case?

Could be a variety of things. The most common issue is the HTML that SPUtility.js is expecting has changed for some reason (custom modification, sharepoint upgrade, etc.).
Unfortunately, I'm not maintaining this project anymore but if you dig into the code you might be able to figure it out.


typo: Double word "search"

@nschonni : Thanks for your contribution! The author, @bradumbaugh, has been notified to review your proposed change.

@bradumbaugh is there anything to change for this or is is good to go?

Hi @nschonni, I've changed teams and don't have the necessary permissions to merge this, but I've emailed someone who should hopefully be able to help. Thanks for your contribution!

#sign-off

@MikeDodaro: I'm sorry - only the author of this article, @bradumbaugh, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

@bradumbaugh  Just type #sign-off in a comment to start review and get this merged.

@MikeDodaro: I'm sorry - only the author of this article, @bradumbaugh, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

#sign-off


Support for 2018 Lexus es 350

Can someone pull a request for 2018 Lexus es 350 so I can use my comma 3. Please and thank you!

Can you post your device's dongle ID?

My dongle ID is
7a31f030957b9c85

Looks like we don't support your platform at all! I'll get a branch ready for you to test soon.

Thank you!

Any updates?

@ErichMoraga want to do this car port? it should be pretty simple

@ShamGod100 Did you ever ask for help in the Discord #toyota-lexus channel?  Indeed it's curious we never got an ICE port for the pre-TSS2 ES Lexus vehicles.  If you don't know how to do a port, you can add me<EMAIL_ADDRESS>to your DongleID 7a31f030957b9c85 for access, etc.  I'm not sure Shane ever setup a branch for you, and is probably pretty busy too (hence him reaching out to me).
  ...
  LEXUS_ES = "LEXUS ES 2016" <--------- missing ICE port
  LEXUS_ESH = "LEXUS ES HYBRID 2018"
  LEXUS_ES_TSS2 = "LEXUS ES 2019"
  LEXUS_ESH_TSS2 = "LEXUS ES HYBRID 2019"
...
  LEXUS_NX = "LEXUS NX 2018"
  LEXUS_NXH = "LEXUS NX HYBRID 2018"
  LEXUS_NX_TSS2 = "LEXUS NX 2020"
  LEXUS_NXH_TSS2 = "LEXUS NX HYBRID 2020"
  ...

FWIW - I think support for the ES could've technically been extended back to 2016 per the Lexus Safety System+ introduction details in...
https://www.lexus.com/content/dam/lexus/documents/brochures/models/2016/My16-Lexus-ES-and-Lexus-ES-Hybrid-Brochure.pdf

No help on discord

Where is your Discord post?  You still haven't added me to your DongleID either.

I don’t know how to that.
I’m using my comma 3 on my 2019 honda pilot
So maybe can you walk me through how to do all that.
My discord
Shams#4982

@ShamGod100 are you still around? Made a PR to test: https://github.com/commaai/openpilot/pull/27683

Yes I’m here Can you send me a url ?Sent from my iPhoneOn Mar 24, 2023, at 7:59 PM, Shane Smiskol @.***> wrote:
@ShamGod100 are you still around? Made a PR to test: #27683
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

I tested it and it worked on 2018 lexus es 350
No ACC below 28 mph.

@ShamGod100 Nice, now we just need a test route. Since the route will be public, we recommend to find a public parking lot to start at (turn car off and back on), then drive for 5 minutes and park at another public parking lot. Then let me know once you've done this and we can merge your car!

Has it been merged?

@ShamGod100 Have you got the test route yet?

Yeah how do I send the test route to u

Yeah how do I send the test route to u

It's just the DongleID|route you can get from...
https://useradmin.comma.ai/
or
https://connect.comma.ai/  [then click the "More info" button]
@sshane This was his latest route...
7a31f030957b9c85|2023-03-29--14-51-26

7a31f030957b9c85|2023-04-01--14-03-45--7
Use this route

7a31f030957b9c85|2023-04-01--14-12-51--17
Use this route

@ShamGod100 your car is now supported in master!

Is their any good forks for this vehicle

Is their any good forks for this vehicle

You must be kidding, but if not, use Discord.

I unplugged the DSU and its giving cruise fault restart car and after restarting still getting cruise fault message

Is this it?
https://www.etsy.com/listing/915424718/sdsu-smartdsu-for-toyota-openpilot
These are the supported models
Supported Vehicles:
Most of Toyota Vehicles
Lexus:
RX350
RX450
ES300H

Is this it?

That one is in Canada.  If you're closer to the Chinese source (AliExpress, etc.), get it from there.  Also, use Discord for questions like that.  It's strange for you to continue using GitHub like this.  I will not be responding to additional questions via GitHub.


Kong open tracing plugin for Elastic APM

This feature is about developing a Kong plugin to instrument Kong to achieve open tracing with the Elastic APM.
The selected integration is agent-less and leveraging the intake API from Elastic.
See https://www.elastic.co/guide/en/apm/server/current/events-api.html
The implementation design is similar to approach taken by https://github.com/Kong/kong-plugin-zipkin
What is the process for me to contribute in this plugin, as I already have a proof-of-concept working ?

See open-tracing in action from the current PoC status.

@ludovic-pourrat Thank you for being interested in contributing.
I'd suggest reading the following docs to get you started.
https://github.com/Kong/kong/blob/master/DEVELOPER.md
https://github.com/Kong/kong/blob/master/CONTRIBUTING.md


Use latest CMS version for ddevapp CMS tests

Migrate away from only maintaining our own pinned versions of CMS artifacts to run ddev tests against. Automatically download and install the cutting edge releases of each CMS to ensure that new versions are supported and catch any surprises before releasing a new version of ddev into the wild.

This has been happening as time goes along.


Add contributing guidelines document

Add contributing guidelines document

xref: https://github.com/uscuni/sgeop/pull/44#issuecomment-2417197263
Should our contributing guidelines:

[ ] (a) go in the README.md
[ ] (b) go in a CONTRIBUTING.md
[ ] (c) go in both
[ ] (d) go somewhere else?

I think probably (c), but what's yall's thoughts @anastassiavybornova @martinfleis ?

I have two reasons for that. One is that I see ReadMe and contributing guide as document for different audience, where Readme is part of the user-facing documentation (hence no A). And second is that I dislike having the same information at two places at the same time as they will inevitably get out of sync in time (hence no C).

Agree with (b)! (and it will be linked in the README so no need for (c) )


Creating a Redhat Distro?

I realize that this not necessarily an "issue", but the information seems impossible to find.
I was on the Microsoft site and it looks like someone suggested creating a WSL forum, but it was decided to keep the discussion at Github... so I figured that I would try asking here...
Thanks in advance for your help (and possibly patience) :)

I would suggest downloading a tarball that contains the redhat user space binaries and importing the distribution via wsl.exe --import


[SP-6599]- Backport of Vulnerable Avro component changes.

:x: Build failed in 1m 50s
Build command:
mvn clean verify -B -e -Daudit -Djs.no.sandbox -pl \
plugins/avro-format/core

:exclamation: No tests found!
Errors:
Filtered log (click to expand)

script returned exit code 1

:information_source:  This is an automatic message

:x: Build failed in 1m 56s
Build command:
mvn clean verify -B -e -Daudit -Djs.no.sandbox -pl \
plugins/avro-format/core

:exclamation: No tests found!
Errors:
Filtered log (click to expand)

script returned exit code 1

:information_source:  This is an automatic message

:x: Build failed in 1m 49s
Build command:
mvn deploy -B -e -Daudit -U -Drelease -pl plugins/avro-format/core

:exclamation: No tests found!
Errors:
Filtered log (click to expand)

script returned exit code 1

:information_source:  This is an automatic message

:x: Build failed in 9m 13s
Build command:
mvn deploy -B -e -Daudit -U -Drelease -pl plugins/avro-format/core

:ok_hand: All tests passed!
Tests run: 41, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message

🐸 JFrog Frogbot

As this PR was inadvertently closed, I've recreated it: pentaho-kettle#9603


Add contact section

This PR has the following:

[ ] Added contact me section.
[ ] Added the user input and text area section.
[ ] Improved button functionality with the hover feature.
[ ] Styled the header with the position fixed property for better user experience.

This second review request has the following:

[ ] I have added a margin between the two user input fields to match the design.
[ ] I have edited the placeholder text colors to match the design template.


How to import hammer without using <script> tag

I'm using vanilla JS es6 (2015) and I'm trying to import hammer. I can't seem to find any documentation on how to use these modules instead of using the <script> tag. Is there any way to do this or is the <script> tag the only way?

Hammer supports Amd and requirejs styles too.
see here:-
so if you're already using say require.js(which i assume you are not) in your page,  you could var Hammer = require(['hammer.js']);
if you want to use \ import hammer as an ES6 module, the current distributed file is transpiled to ES5, so that wont really work.
Tl;DR:- for now, go with the script tag.

Thanks for the confirmation @arjunkathuria. I had looked at that export definition but I was not sure about it and I couldn't find any documentation anywhere else.
I actually can do the require version, but since I didn't see it on the npm package description, and being a bit frustrated by that point on attempting various permutations of module imports with spellings of hammer/Hammer/hammerjs/hammer.js/etc, I didn't explore the require version. After your feedback, I found the following works:
var Hammer = require(['hammerjs']);

NB that your version with the . does not work! :scream: Maybe a version thing :question:
Because it's so easy to get wrong, I would recommend that you could possibly add this to your npm page, since using npm often implies avoiding the <script> route...But it's easy for me to say when I don't have to do the work! :seat: :football:
But thanks for your prompt feedback without which, I might not have gotten it going! :+1:
Btw,

Tl;DR:- for now, go with the script tag.
This had me laughing :smile:

@bill-mybiz Glad you got it working 😉
cc: @arschmitz @runspired guess this one's okay to close.

Just FYI if you (or anyone reading this) are actually using vanilla Javascript, then you're only using modules on Chrome for Android, and maybe Edge with a flag turned on.
Oh, and you can't get away from the script tag :)
https://www.nczonline.net/blog/2016/04/es6-module-loading-more-complicated-than-you-think/

Just in case anybody else finds this - actually you can use Hammer as an ES6 module.
If it's installed via NPM, use:
import * as Hammer from 'hammerjs';
window.Hammer = Hammer.default;

Thereafter, from the same file you can use Hammer as window.Hammer, and in other files you can just use Hammer.

@looeee: Again, you cannot use this feature in web browsers reliably.
Please consult the following:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import
The only thing that has changed in the past 4 months is that Safari added support to a technology preview build.
You still can't use this feature on Chrome, Firefox, Internet Explorer, Opera, and iOS Safari

@BillyWM yes, you'll have to use some kind of build tool -  presumably all people at this point that are talking about using imports in the browser are doing so. I use Rollup.js with Babel. Alternatives are Browserify, Webpack, System.js, JSPM and probably others.

@BillyWM No one uses imports in browsers (even with polyfills) - the most common use case where imports are used is via Webpack where the imports are compiled via Babel (Or some other module bundler).
I believe that is what most people who would need imports use it with currently.

I am using Angular2, and for me
import 'hammerjs';

worked.

I am using Angular2, and for me
import 'hammerjs';

worked.

Thanks!!!

I am using Angular2, and for me
import 'hammerjs';

worked.

Great! Thanks! It works with Vue2 too.
With eslint, I had to add /* eslint-disable-next-line */
    /* eslint-disable-next-line */
    const hammertime = new Hammer(this.$refs.webglCanvas, {});
    /* eslint-disable-next-line */
    hammertime.get('swipe').set({ direction: Hammer.DIRECTION_VERTICAL });

Any good solution? ( I don't want to turn off eslint no-undef )


Change table padding to match favourites card and new requirements

Does what it says on the box
Description

See JENKINS-41833.

Submitter checklist

[X] Link to JIRA ticket in description, if appropriate.
[ ] Change is code complete and matches issue description
[ ] Appropriate unit or acceptance tests or explanation to why this change has no tests

Reviewer checklist

[ ] Run the changes and verified the change matches the issue description
[ ] Reviewed the code
[ ] Verified that the appropriate tests have been written or valid explanation given

@reviewbybees

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

Looking good.
Looks like there a few things off.

Right stars should be inset by 24px.
Should we expand PR to "Pull Request"?

@brody

This change is unrelated to the contents of the tables, so no need to address the headers here.
Originally it was 24px on the table which can be seen in the diff. When I updated the fav cards I noticed they had 16px so it didn't line up. Last time I checked a few days ago, you said it was 16px ( https://projects.invisionapp.com/share/Q2A110KM9#/screens/217973314_Dashboard_-_Search_1_Redline ). If these things are going to keep changing that's fine, but we need some sort of notice to be posted to the Jira tickets.

@sophistifunk

NP re the header.
Dang it! The mockups in the Jira ticket and Zeplin were correct. I didn't think to update Invision as it wasn't linked to in the Jira ticket. I forgot that the table and favs are independent of each other, so fixing the inset to 24px is bigger than a table tweak.

So we want it 24px for tables (inc border) and for fav cards?

@sophistifunk That would be perfect. 👍

I've added some fixes for an issue with missing children that was giving me guff in the Dashboard actions screen, since I had this PR open already.

code seems nice, as much as I am qualified... some good fixes in there.

:bee:


Support Container Instance as a deployment target for AML

Is your feature request related to a problem? Please describe.
AKS deployment and maintenance is quite complicated compared to Azure Container Instances
Describe the solution you'd like
Support Azure Container Instance as a deployment target for AML in the ML landing zone

@hudua - We've chatted about supporting App Service in the past as the model runtime for AML.  How feasible is ACI in the ML archetype?

Yes, ACI is a good idea for the ML archetype. For Azure Container Instance, the preferred route would be deploy to virtual network: https://docs.microsoft.com/en-us/azure/container-instances/container-instances-vnet. Since deployment of ACI requires an image and image source, I would suggest we address this issue as an integration test scenario. Thought?

Please stay tuned...

I'm working on integration test scripts and automation scripts for ML archetype to enable deployment to app service (instead of container instance). There is a well-known limitation that container instance cannot pull from container registry with private endpoint.

We would need to get this limitation lifted before integration.  Do you want to open a technical feedback for ACI engineering to address?

Microsoft internal ticket submitted for this feedback. Focus for now will be to deploy model to App service

d

Edited - re-opened due to accidental user error...

Will close this issue for now. ACI now supports ACR with private endpoint using managed identity, but this doesn't work for ACI inside vnet so not fully supported for the ML landing zone.
Deploy container image from Azure Container Registry using a managed identity - Azure Container Instances | Microsoft Docs


Range Error: Array buffer allocation failed

Hi, something went wrong after the last patch:

Have you turned on the backup by calling external file archiver?

I'm blind...
Thank you!

Glad to help you😉


Added informative information about bad patches.

Also fixed it crashing when one was encountered.
On a side note I have no idea when the gitignore keeps the .project file from eclipse....
A reference to the new way vs the old way (Used in Capiscum). New way: https://pastebin.com/aucJd2XT Old way: https://pastebin.com/jLe6F4SK

Why add the .project! Please remove it.

So I need to change your .gitignore? (You have it set to include the .project file)

Rip the name of the commit...

All fixed.


Suggestions and Changes That Should be Done To Make this Index More Dynamic

[ ]  1 move from Dplayer To Playr -- cuz Dplayer base repo Stuck on 2020 while Plyr is updated once/twice in a Week

[ ]  2 add icons for video audio document pdf docs etc etc like Bhadoos index

[ ]  3 Add service account support

[ ]  4 fix themes

[ ]  5 If Possible Add support for TMDB and Anilist api support for movies, tv-series and anime

[ ]  6 Add the ability to set whether google drive videos will be transcoded or not (by deault it transcoded i guess)

You can check Bhadoos repo and Libdrive Repo for the suggestions i said above
thank you

First three suggestions are already in the todo list. Since I'm not familiar with any movie database api like TMDB, I cannot say it will be implemented soon.
Even though I'm interested with the 6th suggestion, it seems like the official API doesn't support that feature. But I found that calling docs.google.com/get_video_info?docid=FILE_ID returns a file which includes links to the videos in different resolutions. And probably it may be the same method that Libdrive uses. Since It doesn’t seem to be actually documented anywhere, I have to go through the source code of the repos which have mentioned the feature including the repo you have mentioned. So, it will take some time.
And also I would like to know which kind of things should be fixed when it comes to themes.

First three suggestions are already in the todo list. Since I'm not familiar with any movie database api like TMDB, I cannot say it will be implemented soon.
Even though I'm interested with the 6th suggestion, it seems like the official API doesn't support that feature. But I found that calling docs.google.com/get_video_info?docid=FILE_ID returns a file which includes links to the videos in different resolutions. And probably it may be the same method that Libdrive uses. Since It doesn’t seem to be actually documented anywhere, I have to go through the source code of the repos which have mentioned the feature including the repo you have mentioned. So, it will take some time.
And also I would like to know which kind of things should be fixed when it comes to themes.

@cheems  yes You are correct resolution selection removes the transcoding But The Main  definition of transcoding Is To Make almost all  video Playable in website But with lower resolution and Bad Codecs...But i think Transcoding is not needed as People Can Use External players to Play the Unaplayable Video But You shall Remove Transcoding and Add Resoultion Selection If possible....
Also For themes I think you Should Not follow Bhadoos Repo Instead I want Themes Like Tks-gindex-v4 themes etc... Which has Netflix Like Theme and also gives a Netflix feeling....
and for tmdb i think You shall Follow Tksgindex-v4 it might be easier for you ...Idk for anilist But anilist is on libdrive/server repo....


dhcp6c server additions

These additions are to be used for testing the updated dhcp6c serverv6 function, where dhcp6c now generates an ENV VAR containing the address of the server that gave out the lease(s). This can be used where RTSOLD gets no response. Much testing is needed, but on systems where I have disabled rtsdold this works.
ref https://github.com/opnsense/dhcp6c/pull/22

I would rather treat it was the substitute router. Either it works or it doesn't. We do not need to track more 1-off state variables.

OK, whichever way you want to play it. I was going for the safety approach that we use the time honoured RTSOLD method, if that fails then check to see if there's a dhcp6c server address, which I guess there has to be.

We simply check if a file exists and if it does we do not taint it, otherwise we write the only probably address. I'm not sure this works for all ISPs, but it is worth a try.

Erm, hold hard. Not sure I follow. If the RTSOLD file exists then I use that, if it does not I check for the dhcp6c file, if that does not exist then it falls back to the existing no file method. What do you mean by             'check if a file exists and if it does we do not taint it', that's really what is happening.

Yes, but without the redirect through serverv6. We write routerv6 directly if we don't have any.

Ah.. I see said the blind man - So just check for the existence of routerv6 in the dhcp6c script, if not there then write the dhcp6c address to it?

Yup :)

OK, closing and deleting this, I'll go play with that method.


[QUESTION] Db2 for i: what determines if column names are lowercase or uppercase?

Hey!
I have a table defined like this:
CREATE  TABLE idp_users (
  idp_id VARCHAR(255) NOT NULL DEFAULT '',
  idp_user_id VARCHAR(120) NOT NULL DEFAULT '',
  usr CHAR(60) NOT NULL DEFAULT ''
) RCDFMT idusrrec;

I fetch rows using this sql:
SELECT * FROM idp_users
  WHERE idp_id = ?
  AND idp_user_id = ?

All returned rows/objects have their fields in uppercase. Like this:
{
IDP_ID: 'abc',
IDP_USER_ID: '123',
USR: 'Test'
}

This makes a huge difference in JS where variables are case sensitive. How can I make them lowercase?

You need a delimited identifier!:

Thank you, that solved my problem! I'm closing the issue.


Starting QLC+ on Mac (M2 Pro) hangs at MidiEnumeratorPrivate::MidiEnumeratorPrivate(MidiEnumerator *)

Describe the bug
When I start QLC+, it takes ages to load and hangs at "Starte Q Light Conrtoller plus - Loopback".
I have tried the Debug Build of 2.12.8 GIT from the forum and there I get some logs in the terminal.
The last Log before it hangs is
MidiEnumeratorPrivate::MidiEnumeratorPrivate(MidiEnumerator *)

To Reproduce
Steps to reproduce the behavior:
Every time I start the application (tested with 2.12.8, 2.13.1 and 3. something) on my Macbook Pro M2 Pro,
the startup of the application hangs. the 2.x versions show "Loopback" in the loading window.
Sometimes it finally loads after a few minutes
Expected behavior
The application should start within at least 1 minute, ideally would be a few seconds.
Screenshots

Desktop (please complete the following information):

OS: Mac OS 14.6.1
QLC+ Version Multiple
Macbook Pro M2 Pro

Additional context
Got a lot Midi decives connected, but currectly turned off (so should not make any problem)

Edit: Now it's open. Took me 12 Minutes to load. CPU at 0%, nothing else of relevance running

Since this is not a developer report, please report to the forums to get some help.
QLC+ versions 2.12.x don't even exist.
Your issue might be related to corrupted settings file. Please remove it and start from scratch.
Closing.

Sorry, mixed it up. its 4.12.8, 4.13.1 and 5.0.0 Beta 3.
I didn't click developer report when selecting what kind of issue it is, I selected bug report and it nowhere said anything about any forum.


(80, -3) simple-npc

[ ] Dialogue with the robot dialogue doesn't show interactions (E or F) in Godot.

[ ] Dog doesn't show any dialogue when the character interacts in Godot.

Fixed


Delist Microtick

The Microtick chain has been stopped by governance for the move to Ethereum as the rebranding to DiscoveryDEX (Microtick v.2).

There is still TICK out there. Delisting it from the info site would make it more difficult to find data on it. Not sure that it should be delisted from the info site just yet...

Ok I only wanted to inform that chain is halted forever.
Thanks 😉

Thanks


Build git version into image on boot.

I don't see any git info in my development image. When I attempt to access git using DevelopmentSessionManager, I get an error and it appears that there is an invalid STARTUPINFO {STARTUPINFO does not understand #dwSize}.
Also, why is git info limited to the development image? It seems that it would be useful in other images as well.

Can you post a walkback for:

DevelopmentSessionManager git: 'describe'

when the current directory is set to the boot directory. Do you have git on your path?

Ah, no, I do not have git on the path. I had avoided that requirement in my cmd file.


Serial GPS(RY835AI) not reconnecting

Stratux version:

Stratux config:
SDR

[ ] single
[ X ] dual

GPS

[ X ] yes
[ ] no
type:

AHRS

[ X ] yes
[ ] no

power source:
ANKER 20800 and 3amp wallwart
usb cable:
22awg portapow

EFB app and version: (e.g., WingX Pro7 8.6.2)
IFLY
EFB platform: (e.g., iOS 9.2)
EFB hardware: (e.g., iPad Mini 2)

Description of your issue:

If possible, enable "Replay Logs", reproduce the problem, and provide a copy of the logs in http://<IP_ADDRESS>/logs/stratux/ and http://<IP_ADDRESS>/logs/stratux.log.
The GPS(RY835AI) will not reconnect after "service stratux stop | service stratux start" or switching the GPS off and on again in the webUI.
 Fixed with https://github.com/cyoung/stratux/pull/464.

@peepsnet --  /boot/cmdline.txt assigned /dev/ttyAMA0 as a console device on recent images. This will cause the serial connection to time out.
#464 updated the .sh installer scripts, but the makefile doesn't touch /boot/cmdline.txt... in other words, if you're building from source and make installing, this might still be an issue.
TL;DR: Open /boot/cmdline.txt and see if it contains console=ttyAMA0,115200. If so, delete that text, save, and reboot. See if that resolved the connectivity issues.

/boot/cmdline.txt contains
dwc_otg.lpm_enable=0
console=tty1
root=/dev/mmcblk0p2
rootfstype=ext4
elevator=deadline
fsck.repair=yes
rootwait

OK now its not doing it!!!


Relax upper bounds on aeson and http-client

I've tested this in a small yesod application, authenticating against Google.  (I compiled it with GHC 8 and used stackage nightly-2016-11-12.)
These bounds are currently blocking this package in stackage nightly, and, when released, I am quite happy to submit a PR to re-enable it.

I can't see why the test failed.  The example builds on my system with the "official" stack.yaml, admittedly allowing a newer minor version of GHC, but I doubt if that makes any difference, ie I used: `stack build --flag yesod-auth-oauth2:example --compiler ghc-7.10.3
(That example doesn't build on GHC 8 at the moment because of https://ghc.haskell.org/trac/ghc/ticket/12130.)

The test failure isn't anything to with my change, AFAIK.  Is there anything else which needs to be addressed?

@jferris - if you're the right person - is there anything I can do to help with pushing this along?  I think the test just needs to be re-run.

Thank you 👍


LRC-7 - Blockswap Economics and Reward Structure

Hey everyone,
It’s that time again — a review of the Loki block reward, and how we can shape it to bring the best outcomes to the Loki Network and its products.
This LRC is primarily about Loki’s latest proposition, Blockswap. This comes at an interesting time for Loki, as we move rapidly towards the PoS Pulse upgrade, which will drop the mining reward entirely — something agreed upon when we last discussed block reward restructures with you. I’ve been doing lots of modelling to try and come up with a design for the Loki block reward that can support Blockswap, while still granting the network the same level of Sybil resistance for Session and Lokinet.
Adding a second node layer to the network is a really interesting challenge. As discussed last time, we’ve got even more data on realistic staking equilibriums, and we can now more accurately predict the lockup ratios of the existing Service Node network. Adding this second layer, if incentivized correctly, could send the lockup ratio of Loki far beyond the 45% ratio we have now. Even if that new lockup is being used to secure collateral in Blockswap, it still isn’t liquid — so it can’t be used in a Sybil attack on the network. So the additional lockup brought about by the introduction of Blockswap should result in increased protection for the entire network.
The Requirements
Vault nodes must be collateralized sufficiently to prevent ransom attacks and outward theft by a supermajority. Intuitively, one might expect that to adequately protect $1m of liquidity, vault nodes would need significantly more than $1m of collateral to protect that liquidity from being stolen by a malicious attacker with enough vault nodes to form a supermajority. In this instance, if the attacker was able to run $660k worth of nodes in a network with a total collateralization of $1m, they could form a supermajority and steal the vault’s $1m without penalty.
With that in mind, you might be led to believe that Blockswap will need heavy overcollateralization to be considered secure. But in fact, there are some clever design tricks we can use to secure vaults of an equal or larger value than the collateral associated with the vault nodes operating them. The two methods we’ll employ to achieve this are:

Vault splitting, which involves deterministically shuffling members of a given vault and splitting them up so each vault node has custody of as few vaults simultaneously as possible, but in such a way that the system cannot be influenced to drive a given actor’s nodes into one particular vault. This way, even if the attacker controls two thirds of the nodes, it is very unlikely that they would be able to form a supermajority in any one vault. By slowing down the intervals of vault reshuffles, the attacker must wait an impractically long time before random chance will work in their favour. And even if this did occur, it’s likely they would only gain a supermajority in one vault, so the other vaults would remain protected from that theft.

Slashing, which involves any instance of theft from the vaults (ie. unexpected transactions) to cause the offending vault nodes to have their Loki collateral deducted from their wallet, effectively neutralising the benefit of stealing any amount of cryptocurrency worth the same or less than that of the collateral they have already gained.

To illustrate this, let’s look at a scenario where there are 100 active vault nodes, 90 of which are participating in vaults, and where there are 3 vaults with the following balances:
Loki: $2m (30 nodes)
Eth: $1m (30 nodes)
Btc: $1m (30 nodes)
10 active but out of rotation
In this scenario, the attacker must own at least 20 nodes to have any chance of a successful attack. However, the chances that all of the attacker’s nodes will be randomly selected to become a part of the same vault is practically zero. We ran simulations on the effectiveness of vault splitting, using a probability calculation called a hypergeometric distribution, and here’s some R code and some results. Because Blockswap vault iterations only occur every 2-4 weeks, the amount of time an attacker would need to pull off a theft that overcomes vault splitting is substantially higher than if all vaults were run by the same group of nodes.
If that attacker owns 33 nodes, they'd have a chance of 0.02% every year on average of forming a supermajority in a vault. Looking at a more dangerous scenario, if the attacker had 45 nodes, or just under half the network (which as I’ll show later, is going to cost a lot), and there were three active vaults which rotated at a period of 4 weeks, the chance that they’d achieve control over a single vault is a 15.1% chance over a year. However, in this instance, they only control one of the 3 vaults, at most $2m, but more likely $1m. Still, this could mean the attacker could walk away with $1-2m if they owned half the network and were extremely patient.
This is where slashing comes in. Because of the nature of the quoting system, any unexpected transaction leaving the vault (i.e. a theft) would be noticeable to all other network participants. Seeing as the offending nodes in the vault must sign this transaction, depending on the vault type, they can be identified immediately, or if not, the entire vault can be considered bad. If an offending transaction is created, the Service Node network can slash the collateral of all of those nodes. This means that a thief must also factor in the cost of the collateral they have used in the attack. In the case where a whole vault gets slashed, even if there are some honest nodes in there, this may seem inequitable. However, because of this penalty in place, the attack should never occur.
In this scenario, the attacker gets lucky and controls 50 nodes and randomly wins a supermajority of 20 in the Loki ($2m) pool. Instead of being able to control the entire $4m of liquidity in the system, the attacker only gains control over $2m. If the stake of the 20 nodes is worth as much or more than $2m, the attack is pointless, as the collateral they have will be slashed. It becomes even more pointless considering that the remaining collateral they have and the Loki they have just stolen will now likely be worth less as the market panics. If they gain control of a smaller vault instead of the Loki vault, the attack is even less viable.
By splitting the vaults and slashing bad actors, Blockswap can rely on vault nodes even when they are not substantially overcollateralized. There is no hard limit to what would be considered an ‘acceptable’ collateralization — the greater the collateralization, the less likely an attack of this type is possible. But given the extreme costs of owning large percentages of the circulating supply, the low iteration speed on vault rotations, the splitting of vaults into randomly selected groups of nodes, and the slashing of collateral upon a theft, an attack of this kind would not be viable. That is, unless the value of the liquidity of the nodes exceeds that of the total value of all of the vault nodes in operation. That being said, the total value could exceed the collateralization to a moderate extent without greatly impacting the security of the system. Thus, I argue that we should target Blockswap vault nodes to be collateralized for as much liquidity as we intend Blockswap to hold.
Target Liquidity
UniSwap holds an extraordinary $150m in liquidity, but for most of its history has held much less than that, at around the $30m mark. This is a very high amount of liquidity, but considering it is able to capture the entire ERC20/ETH market, this is no real surprise.
In designing the economics for Blockswap, we must decide how much liquidity we are aiming to support. The more liquidity, the lower the fees for traders, and the greater volume of trades will be passed through the system. More trades will result in more Loki burned in fees, and greater rewards for liquidity providers.
In setting an initial liquidity target, we are not defining the ultimate hard limit of what is possible on Blockswap, but what our initial target is for the first steps in decentralized cross-chain swaps. The number we select is fairly arbitrary, because of course, the more the better. I believe that setting an initial liquidity target of $7 million is sufficient for the purposes of initializing this product.
Granted, this target is sufficiently less than what is currently available on UniSwap. However, this target can be revised over time, and as I’ll explore, it isn’t a good idea to simply ramp up the target liquidity to compete directly with the size of liquidity Uniswap has reached after 2 years of development and widespread adoption.
Creating the Incentive
To convince node operators to lock up 7 million dollars worth of Loki, we must create an incentive structure that sufficiently rewards node operators for locking up their capital and behaving correctly on the network.
The reality is that the incentive for vault nodes comes at a network cost in the form of emission. Given that this cost is realised programmatically and not in accordance with how much liquidity is actually in the system (at least initially), we must limit the amount of rewards given to vault nodes. As discovered in our last exploration of this topic, the velocity of money is dramatically reduced with the introduction of staking, so the emission created amongst the vault nodes is not something that is going to be immediately paid for on the market. However emission does have an effect on the overall value of each token on the network over extended time frames, so we should avoid adding emissions wherever possible.
That being said, if Blockswap is a successful product, there will be lots of Loki being used and burned in each swap. If done in sufficiently large numbers, this will be able to offset the newly created coins awarded to the vault node operators.
After running the Loki Service Node network for nearly 2 years, we now have lots of data on how real world node operators behave. We’ve written about, modelled, and predicted the likely behaviour of Service Node operators and their staking habits, and now have a really good data set to use in our modelling for vault nodes.
One of the key concepts we explored in our last discussion was that of the staking equilibrium. That is, what is the minimum amount of returns available to stakers before there are as many people unstaking as there are new entrants staking into the network? I predicted that over time the staking equilibrium would in fact decrease. As Loki becomes a more stable and mature product, I had assumed people would be more likely to tolerate a lower amount of returns, and risk locking up their coins in staked nodes in order to earn returns on a more stable ecosystem.
What seems to be the case is that the staking equilibrium is slightly higher than I predicted, and I believe the reason for that is because of the relatively low Service Node staking requirement.  When the Service Node network first launched, Service Node operators required a whopping 45,000 Loki in order to start a new Service Node. This was done to ensure that the cost of operating a node would not discourage people from seeking those returns. However, as the staking requirement has decreased towards 15,000 Loki, it seems that because of the relatively low collateral amount, and the relative difficulty of operating a large number of Service Nodes, larger Loki holders have found it difficult to maintain a stake in the Loki ecosystem.
Blockswap could be a great solution to this problem, as node operators will now have two options - one being a relatively inexpensive node that operates Proof-of-Stake and the other Loki Services, and another class of node that has a higher operating cost, but allows for lots of Loki to be staked in one transaction. This means for larger holders there is less hassle involved with operating nodes, and an entirely new subset of emission to compete to earn rewards from.
I therefore estimate that although our current staking equilibrium seems to be about 20-24%, the staking equilibrium for vault node operators could in fact be lower than this. However, for the purposes of the modelling, I will stick to an average of 20% for the staking equilibrium. In other words, in order to attract $7m worth of collateral to the vault nodes, the vault nodes should be earning enough Loki to have an annualized return rate of 20% where there is $7m of collateral in the vault nodes.
So What Do The Numbers Say?
The numbers really depend on how much Loki is worth at a given time. Obviously, price performance has been quite good lately, and there's probably still quite a bit of room to go. Unfortunately, it's hard to put a concrete answer on what will be sufficient and what will not be sufficient, due to the price volatility.
I've modelled this at a range of prices, all the way from 40 cents up to several dollars. A conservative estimate would have the best modelling conducted at the lower range of these boundaries. The final number that I have arrived at is that they will have to be awarded 10 Loki per block. For context, the miners currently on the network receive 22% of the emissions, which is 6 Loki per block.
If you want to read more about the modelling that I've done, see the spreadsheets, and play around with them yourself, I have attached a workbook for you to look at. It accurately models the emission rate in the current scheme, and also looks at different price outcomes and different staking requirements for a set of 100 vault nodes.
How Do We Do That?
Proof-of-stake is coming up. Once the Pulse upgrade is in, which isn't that far away, miners will no longer receive 6 Loki per block. The obvious thing to do is to give that 6 Loki per block to the vault node operators. However, that 6 Loki will be insufficient to attract enough collateral to those vault nodes to provide the target liquidity that we want in most conservative price scenarios.
As such, we need to agree on the course of action that we are going to take to support Blockswap. We could either agree to increase the overall emission rate once vault nodes are required, or we can take some of the rewards from the existing Service Node network. Personally, I don't mind which way the community decides to do it, I think there are good arguments both ways. Creating new emissions will likely result in a greater overall lockup given that there are more rewards available, however, I also think the Service Node network can tolerate a slight reduction in rewards, especially considering many of the current Service Node operators are likely to switch to the larger node size with vault nodes anyway.
A Further Idea
From looking at development timelines, it doesn't look like vault nodes will launch before Pulse.  There's a further issue of seeding liquidity pools that I haven't yet discussed. I think that this is an important step in bootstrapping Blockswap to be a very successful product. While we must attract liquidity to the vault nodes, we must also attract liquidity to the vaults themselves. If there is no Loki or ETH to swap with, traders cannot use Blockswap. In order to encourage early provision of liquidity into these pools, I propose that a fund for pool seeding be created. This fund will be used to inject small amounts of Loki into the vaults, guaranteeing early liquidity providers at least some benefit from staking. The attraction of these rewards should create enough liquidity for traders to find it a viable option to swap assets across chains. Once the traders have appeared in sufficient volumes, seeding will no longer be necessary.
My proposition is that the 6 Loki per block that is currently being rewarded to miners, instead of being outwardly destroyed at the upcoming pulse hard fork, instead be directed to a Loki Foundation controlled wallet, and then be used to seed Blockswap liquidity pools and bootstrap the incentives for liquidity provision. This will get the liquidity pools off the ground and make it much more likely that this product will be successful.
In order to limit this fund, I also propose that a timeout be built in to this redirection of the block reward. The hard fork that enables the vault nodes will remove this funding from the block reward, or if that hasn't occurred after 6 months, the fund will expire and no further Loki will be generated for this purpose.
TL;DR
At the Pulse upgrade, send the 6 Loki per block to a Blockswap liquidity fund (6 month expiry), then when the vault node upgrade comes out, remove the liquidity fund and either:
Add an additional 10 Loki per block to the emission schedule;
Cut 4 Loki per block from the Service Nodes and grant it and the current mining rewards to the vault nodes, or;
Some blend of the two.
Conclusion
Hopefully you’ve been able to gain some insight into the economics of Blockswap and can critically analyze this proposal with us. Please keep your feedback constructive and civil. Hopefully we can come to a consensus on the best way forward.

My opinion would be 16.5 for the service nodes and 12.5 for the vault nodes would fix it based on my own calculations. I dont think we should lower the amount from the service nodes as that would break the social contract. However I feel there isnt enough from the 6 for vault nodes. I honestly also feel there isnt enough liquidity.  I think 29 loki per block would be a good ratio personally.

For now I'm going to agree with @SomethingGettingWrong
I also agree with diverting the 6 loki per block for 6 months into a Blockswap liquidity pools seed fund.

I like the pool use idea, but I would say after the 6 months if the deadline hasnt been met and the pool still exists, any loki in the pool should be burnt out of circulation.
I somewhat agree with @SomethingGettingWrong, but I dont think those reward amounts are including the 5% loki foundation part of block reward, which I  think was meant to be changing to 10% after pulse? Is that still the case or not for this new proposed reward shake down?
So you would be looking at 29 loki emission plus loki teams 5-10% slice of the pie. 1 loki to dev is not needed when that is the whole point around the foundations portion of the block reward.

"If done in sufficiently large numbers, this will be able to offset the newly created coins awarded to the vault node operators."
If the goal is zero emissions added to the system by vault node operators, and their rewards are created at each block, couldn't the fee for each transaction be (the average of the last 5 blocks) per transaction?
So if we knew there would be 100 transactions in the block that this transaction is included in, then we'd charge 6/100.  Since this cannot be known, but the last 5 blocks had 500 total transactions, we could charge 6/100 and programmatically (effectively) zero out the emissions.
If the emissions created are burned by code, then the SNops and LF ratios can be left, and changed by the normal process in the future.  In other words, they don't need to be accounted for in economics of the coin, since they are effectively nullified.

So you would be looking at 29 loki emission plus loki teams 5-10% slice of the pie. 1 loki to dev is not needed when that is the whole point around the foundations portion of the block reward.

yes, you are correct but i was more referring to at least 1 loki of the 5-10 slice  out of every block should be set aside and converted to USD everyday for a dev.. where as teh other portion of the loki foundations amount wouldnt be converted but instead held. I would like to have the FUNDS avaialble for at least 1 permenent deve..  In this way at least 1 loki per block is a "known" and is always being converted and therefore there will always be dev funds.
The only reason I mention it is that in the future  there will not be any more block reward changes and such a change needs to happen now.

If the goal is zero emissions added to the system by vault node operators, and their rewards are created at each block, couldn't the fee for each transaction be (the average of the last 5 blocks) per transaction?

Yes, although I think that the average of the last 5 is probably much too noisy: a rolling average over the last 1-2 days would probably work better.  There's also no reason that it needs to break even -- we could set a negative target so that blockswap emissions = burn amount (averaged over the last 2 days) - 5.  This would give some predictability, and offset coins emissions from the (regular) service node side.
But this is a longer term target that requires the system be operational and being used; much of the discussion here is about how to bootstrap that process.

You can't set a dynamic reward, at least not at the start. vaults have to stable, lasting at least 4 weeks at a time, and cost a fair bit to run. The fees burned at the time of swapping are going to vary greatly depending on prevailing market conditions and that volatility needs to be kept isolated from vault nodes. By giving them a fixed reward from the emissions schedule, we acheive exactly that. If more rewards are needed, we can decide on how and when to do that as a community.
We already receive 10% of the block reward as the foundation, and let me tell you, dumping an extra 1% would not help much at all. We've been pretty good at managing the funds so far. If your concern is that there isnt always going to be 'something' - there will be, but your proposal neglects to consider we're already over 20+ full time staff, and dumping 1% of the block reward doesnt even offset a single developer. We're much better off holding on the the Loki and selling it in bulk at a high price off the market, rather than providing this constant downward pressure.

Yeah as much as I dislike the current emission rate of loki, and was hoping pulse would help control this a bit more by giving service node ops more to lock up, I dont think at this point in time if you want the blockswap side to work a negative target isnt feasible on initialisation. I am still with @SomethingGettingWrong method, minus the 1 loki. For the record loki foundation at 10% is fine as long as they are keeping it off the market.
Good to see a healthy discussion.

All things here discussed are directionally correct. My position is:

Service Nodes receive payment for validating blockchain and servicing lokinet
Vault nodes receive payment for securing Blockswap
LPs receive payment for providing liquidity
LF receives long term funding support

Not having long-term incentives for LPs won't be competitive when stacked up to Ethereum DeFi, or THORChain, which pays 33% of incentives to LPs.
Suggestion, if 100 units is the Block Reward:
Service Nodes: 40 units (they validate the blockchain - most important job)
Vault Nodes: 35 units (they secure assets - second most important)
LPs: 15 units (must pay LPs to be competitive and drive capital formation
LF: 10 units
Total: 100 units

I think it's important to be competitive with other projects that want to attract liquidity.
How do we do this and reduce the and burn enough loki to offset emissions?

changing the block reward to 100 would frankly make me dump all my Loki to be truthful that is much to far from the original social contract.  Whatever the number of the blockreward... each time we change it massively... it changes sybill resistance. servicenodes need the majority!!!!!!!!
16.5 is what they are now. Forget the 1 loki per block i mentioend earlier for a permenent dev.
IF the servicenode reward was 16.5 then valut nodes and everything else underneath it needs to be less then 16.5

@SomethingGettingWrong I think JP was using 100 as an example so people can see the percentages better in his explanation.

@SomethingGettingWrong I think JP was using 100 as an example so people can see the percentages better in his explanation.

Yes, but prior to that Simon said they already receive 10 percent through Loki foundation and that 1 percent wouldn't take care of a developer at all. That would only make since on a 100 block reward.  Prior to that i had suggested 1 Loki out of each block with the respect to the current block reward and at current prices that would be 720 Loki a day at 60 cents which is over 300 bucks a day.  So it makes me tend to think they already are looking at 100 as a block reward as that would make 1 Loki of the block reward equal 1 percent. Maybe he thought i meant 1 percent from the beginning?
Either way I feel going to such a large block amount would cause all previous emitted loki  to lose value a the same ratio the block reward grows.
Lets pretend for a second he did which would be fine.
The reason 100  reward would doesnt make since to me is because the social contract started at 45k and went down to 15k and the reward was 16.5.
So cross dividing 40/16.5 to get a multiple.. it would equal 2.4242.  Then 2.4242* 15,000 = 36,363 service node requirement to keep the social contract the same. but then people that have say 4200 loki and were 1/4 a node cant stake... unless they allowed  ahigher multiple then 1/4   say 1/9 which would be 4,040.33. Then the person is only getting 1/9the the block reward instead of 1/4th.  . so 100 is not a good blockreward number.
It needs to go up by a common factor of 2 which is the minimum stake requirement when determinign the block reward... .other wise the social contract is busted....
so double the amount
33 for service nodes.
24.87 for Vault Nodes
16.375 for Loki Pool
8.25  for Loki foundation
82.495 block reward.
This allows for 10 percent loki foundation. It allows for a multiple of the orignal service node social contract.  It allows for a good ratio for vault nodes and a large enough number i think for the loki pool.  While at the same time allowing service node operators to shrink the number of nodes that are too much too handle and are on the same Virtual private server to begin with by a factor of 2... which would also keep the cost ratio of purchasing power the same... since the nodes rewards would doulbe from 16.5 to 33 but the nodes themselves would go from 15k to 30k each at a minimum. This would also make rewards come 2x as often and then we change the stakign allowance from 1/4 to 1/8th which would naturally allow those that recieved a set amount for 1/4th an node at 16.5 to now recieve 1/8th at 33  which is 4.125 loki.
16.5/4= 4.125
33/8= 4.125
So basically in this way the block reward receives a different increment. but purchasing power is evenly divided from the old social contract.

"Even if that new lockup is being used to secure collateral in Blockswap, it still isn’t liquid — so it can’t be used in a Sybil attack on the network. "
If the attacker simply buys all the loki in all the vaults with BTC, does the price quoted rise exponentially as it would on an exchange?  Otherwise, how is this Loki still protecting the network?

I agree that we need incentives to attract liquidity.
I propose a new design for blockswap that will increase the security and incentivise liquidity providers to contribute.
Instead of creating a new type of node (vault nodes) we use the already existing service nodes to create Vault quorums. A vault quorum will consist of 10 service nodes and each service node can only be in one vault quorum at a time. These vault quorums will perform the functions of a single Vault nodes as already defined by the loki team and require a supermajority of 7 out of 10 service. To summarise each vault will consist of a quorum of Vault quorums and require a supermajority not only within each vault quorum but also within the quorum of Vault quorums (making them more secure)
As service nodes already have a block reward designated to them this allows us to use the block reward that is planned for vault nodes to go to incentivising liquidity providers instead.
If service nodes don't want to participate in vault quorums they can opt out for a reduced block reward for a reduced reward from 16.5 to 10.5.
Additionally we could also still have vault nodes alongside vault quorums (as I understand one of the suggested benefits of Vault node is that if large holders don't have to manage lots of service nodes they will be more likely to lock up their Loki too). If vault nodes are also implemented they could be limited to a maximum of 50% when creating a vault with the remaining vault consisting of Vault quorums. As Vault nodes don't perform all the functions service nodes do they could be paid less than service nodes. Let's say a vault node requires x10 the amount of loki that service nodes require, then they could be put in the reward queue 6 or 7 times, less work and easier management for a lesser reward.

Whatever you do don't increase emissions. Cut sn rewards but do not increase emission.

Block reward was originally 45.00
Why not set the stake requirment on future service nodes to be 45,000 again. this keeps an incentive not to unstake 15,000 service nodes... are any currently staked servicenode...
Put block reward back at 45.00 in this way the increased emission per loki staked is the same and an increase blockreward doesnt result in an increase in emission on new service nodes.
Block reward (22.50) for all new service nodes and old staked nodes that dont unstake. New requirment is 45,000 again.
Remember orgianlly the 6.00 from miners was gonna go to the 16.5 we have now and that would equal 22.50 ANYWAY.. so the servicenode reward was gonna go to 22.50 there about..
Why not.
22.5 for service nodes.
10.00 for vault nodes
8 for Loki Pool
4.5 for loki foundation.

@SomethingGettingWrong how about using the service nodes we already have instead of creating a new type of node? The current mining fee can go into incentivising liquidity providers.
You're always saying how loki has a liquidity problem and this seems like it would solve that.

At current prices we have $28M MC, $7M is 25% of MC.  45% is locked up, so price goes up significantly and/or the node count drops significantly.
Miners only account for 800K loki over 6 months, so there's a severe liquidity problem even when this hits mainstream, even if we're listed on all the major exchanges.
I think there needs to be an incentive program for people to add to the liquidity pool during the six month funding startup window.  Maybe a reward bonus upon actual product launch.
i.e.  If you are part of the initial liquidity providers, 75% of the first 6 months of fees (or a guaranteed ROI) are paid to a fund that pays out proportionally to the initial providers.  SN operators can direct rewards to the fund / and / or designate some of their locked coins to the fund (since these coins still protect the network, according to the LRC.)

@SomethingGettingWrong how about using the service nodes we already have instead of creating a new type of node?

This feels more like a SNapp on top of the network of SNs.  I think severability of the vault nodes if this program doesn't work should be maintained.  Also allowing people who don't want to run a SN, but do want to run a vault node would attract more people.
It could be another app on the same node, so SN operators could run it concurrently, or a vault node operator could get a vps for solely this purpose.  That would provide for the most flexibility.

"Even if that new lockup is being used to secure collateral in Blockswap, it still isn’t liquid — so it can’t be used in a Sybil attack on the network. "
If the attacker simply buys all the loki in all the vaults with BTC, does the price quoted rise exponentially as it would on an exchange? Otherwise, how is this Loki still protecting the network?

The collateral staked into vault nodes is not the same as the liqudity in the pools. Collateral in the vault nodes is illiquid.
As for the second part of your question, yes, the fees that the buyer would pay rise exponentially as they consume more and more of one side of the pool's liqudity.
As for @Lucifer1903 and the idea of using the existing service node network, there are some limitations on the way we want to do vaults that prevent 'multisig on multisig' operations that would make it possible for service nodes to sign vault transactions at a large enough scale to make it secure. Service nodes are too numerous, under collateralized, too low powered, and not reliable enough to do the work of a vault node. It makes much more sense to get the vault nodes operating as a seperate class of node, who have to be aware of multiple blockchains, operate a side chain, be extremely fast at MPC and peer communication, and have excellent reliability.
If the concern is that we're spending too much emission on SNs, then why not advocate for the SN rewards to be redirected to vault nodes?

@Haafingar my main issue that no one seems to be answering is; given the option of providing liquidity to blockswap vs another similar project that pays out part of their block reward, why would a liquidity provider put their liquidity in loki's blockswap when they can earn more money with a different project?
If you don't see having low liquidity as a problem then let me ask you, why would someone make an exchange on blockswap when it causes the price to swing and they pay more in fees than if they used another option?
Sure privacy is a benefit, everyone knows session needs to be free or the majority of people won't use it, blockswap need to be competitive in fees with other projects or the majority of people will go elsewhere.
I rambled on a bit. Basically please explain why would a liquidity provider choose blockswap when they earn less? And why would a user exchange coins on blockswap when it costs more in slippage?

I never said I thought liquidity wasnt a concern. This is why I suggest we use the 6 Loki per block to create a seed fund to create early incetives for liqudity provision.
However, the system has got to stand on its own two feet. Systems that rely on printing tokens to give to liquidity providers are essentially funding the system at the expense of token price. COMP, BAL, etc are going to zero on a long enough time frame.
Blockswap won't have to do this long term if the product is good and people are actually using it to swap coins. Its the only solution that allows for generic cross-chain swaps with no special wallets - if we had to permentantly pay LPs, that to me says we don't have a unique selling point. LPs stake to earn trading fees - that's the whole premise of AMM. Trading fees will come through Blockswap because no other pool of this type exists for swapping between BTC, ETH, Polkadot, etc seamlessly. There's no point for competing over USDT/ETH pools for example, we'll never win that liqudity, we're better off just hooking into uniswap for that.

At the Pulse upgrade, send the 6 Loki per block to a Blockswap liquidity fund (6 month expiry), then when the vault node upgrade comes out, remove the liquidity fund and either:
Cut 4 Loki per block from the Service Nodes and grant it and the current mining rewards to the vault nodes,
I favor this.

I hope some anti-dump mechanism is introduced. Say for example 250k Loki get slashed for some odd reason, instead of doing the typical fee payout to a specific "miner", dilute it so the entire network benefits and less of a chance of a market dump
For ex: match 1:1 block rewards until the slashed Loki are consumed, or similar mechanism.

I think reducing the service node block reward to make up for the vault node reward is the best option. A lower reward for service nodes will incentivise operators to move to vault nodes. As operators move from SNs to VNs the SN reward will will be split between less nodes so the profitably of SNs shouldn't change too much.

I've felt like for a long time that the emissions are too great and the market has to swallow the emissions limiting the value of the coin. Loki has great features already that are very marketable. The tech team has done exceedingly well in generating these products. I feel that these new proposals wouldnt be so scary in the way of inflation if the token had a price that reflected the progress achieved. At some point we as a community are going to have to agree to take a risk in which we wont be relying on the ability to mass print tokens to incentivise our service providers. If the value of the coin is great, you rely less and less on having to provide large emissions to achieve these services.
My point is, let's also not get too caught up in the new stuff and forget about what we have already achieved. Market the token and you wont have to run numbers on the lower end between 40c to $7.

I'm not sure why so many people are talking about what happens to slashed funds. The answer is easy: They get burned. Ideally no one ever gets slashed, it should only be reserved for activley malicious nodes, and the existence of the penalty should prevent it from ever having to be used.
Ineteresting to see the consensus leaning towards cutting SN rewards to fund VNs!

@Haafingar would it make sense for VNs to not disclose IP address? If a hacker knows all the IP address for the VNs that are making up a Vault then they know exactly which IP address they need to attack to either gain funds or DDoS a Vault.
It would be good if they were hidden behind lokinet and when it's time to create a new vault the nodes selected for said vault connect to each other over lokinet and share their real IP address for a faster connection.

VNs very likely will have their IPs exposed just as SNs do. VNs will need to take their security more seriously than a typical SN, but your run-of-the-mill debian server isn't that easy to crack if set up using best practices. Routing VNs through Lokinet would cause a significant slowdown to vault signing ceremonies which involve 7 rounds of communication using GG20. Latency needs to be kept to a minimum.
DDoS is a legitmate problem until you consider that VNs only have to talk to Quoters and SNs, both of which have their IPs registered on the blockchain. Effectivley, VNs can easily firewall themselves off from anyone not whitelisted on the Loki blockchain.

@Haafingar can't IP address be shared between Vnode only after they have been selected into a quorum? After they privately share their IP address they can connect to each other directly for all vault quorum tasks such as signing ceremonies without any slowdown.

VNs very likely will have their IPs exposed just as SNs do. VNs will need to take their security more seriously than a typical SN, but your run-of-the-mill debian server isn't that easy to crack if set up using best practices. Routing VNs through Lokinet would cause a significant slowdown to vault signing ceremonies which involve 7 rounds of communication using GG20. Latency needs to be kept to a minimum.
DDoS is a legitmate problem until you consider that VNs only have to talk to Quoters and SNs, both of which have their IPs registered on the blockchain. Effectivley, VNs can easily firewall themselves off from anyone not whitelisted on the Loki blockchain.

Routing VNs through Lokinet would cause a significant slowdown to vault signing ceremonies which involve 7 rounds of communication using GG20. Latency needs to be kept to a minimum.

One potential idea here is that the only public info would a .loki address, then VNs would connect to each other there, authenticate that they are talking to a valid vault node, then exchange public IPs and reconnect through that.  Then you get the low latency of a direct IP connection, but don't have to expose the IP address publicly.

@jagerman thank you for saying what I wanted to with better words haha

The other day I was extremely "wordy" and not very clear in what i was trying to say the other day. I have finished the necessery data to show easier what I was trying to say.
While the number Service Nodes are Vault Nodes are un-kown what is known is that they will find balance on ROI. The service nodes will un-stake into vault nodes and the vault nodes will un-stake into service nodes until ROI is equal on the chosen block rewards.
I have created a calculator to input the various staking requirements and block rewards along with inputs to an unknown quorum size and penalty slash amount and filled them with 80 percent and 30 for quorm. Although these dont have anything to do with the high lighted calculations.
The point I was trying to easily say the other day is that the confusion was that I was saying the block reward wouldn't balance out are that it was somehow wrong. Any block reward and node count is gonna find balance. I have a calculation for finding balance depending on the nodes entered at the various settings. At 100 percent the Emission for each individually staked LOKI in both nodes ROI is equal! This is where the free market will most likely land. The nodes will fill until they find that equilibrium.
The problem isn't the amounts but the amounts relative to one another that I have issue with. While they can find balance and as you will see i will put in different node counts and balance them to 100 percent.  The ROI will change. You will also notice "The vault nodes can purchase a service node and a service node can purchase a vault node calculations."
Below is a few sample images. To point out something I believe is being overlooked. Sybil Resistance.  How long before the vault node owners can buy all the service nodes faster then the service nodes can buy vault nodes matters based on input!
While this is not an issue if New money comes in I just merely want to point out if its the same node owners un-staking and buying vault nodes. Then these vault nodes continuously stake they will eventually overtake the service node owners emission if they choose to only run a service node. I get this is an amazing and ample opportunity. I just wanted to input a few examples to show the variance of years. Its not the block reward number itself that matters as to me as much as the time frame we have before approaching 51 percent of vault node owners taking all their emission and re-staking into service-nodes faster then old service-node owners can re*stake into service nodes.
At 800 service Nodes at 16.5 block reward and 111 vault nodes at 10 block reward the vault nodes will be able to re-stake all rewards and own over 50 percent of the service nodes in  4.75 years with ROI being 4.376 years on vault nodes and servicenodes at 100.40% equal emission per loki staked.

At 800 service Nodes at 12.5 block reward and 146 vault nodes at 10 block reward the vault nodes will be able to re-stake all rewards and own over 50 percent of the service nodes in  2.74 years with ROI being 4.376 years on vault nodes and servicenodes at 100.05% equal emission per loki staked.

I dont think 2.74 years is enough time.
thats why i think we should start out at 6 blockreward and increment up to 10 block reward over 2.74 years instead! That way we can achieve the 10 block reward while at the same time not overpaying new nodes! Just look at if there was 1 node online the entire 7200 emission (720blocks*10breward) would be his.

basicly I think 12.5 and 100 will be okay.. but we can extend the time period by starting the block rewards at 16.5 on servicenodes and counting down over a period of time to 12.5 and starting the vault nodes out at 6 block reward and counting up to 10 block reward over that same period of time per block over the time period the team thinks the vault nodes and loki nodes will take to balance! 3 months?

Thanks for that Patrick. Glad to see that you've made some adjustments.
You're saying that Sybil resistance has been overlooked, but as long as we assume that the initial set of Service Node operators are reasonably diverse (which they are) and vault nodes follow a similar even distribution between honest actors, the scenario you are describing will never happen. There will always be some level of new money entering and old money leaving, and the situation you are describing would imply that all Service node and vault node operators are colluding and trying to Sybil attack the other.  It isn't a realistic scenario.
I have argued, and maintain, that adding Vault nodes increases Sybil resistance from a malicious actor that doesn't already have a large stake in SNs. The VNs will cause more of the circulating supply to be locked up, making it even more expensive for new actors to arrive and attempt to take over the network.
If you believe current operators aren't honest and the Loki network is corrupt, then that would be a different story. I think we can all agree that the distribution of operators is currently fine, and given that fact, the addition of VNs will only serve to bolster the entire network (both blockswap vaults and PoS/Session/Lokinet) and its safety against Sybil attacks.

The problem is  the system is setup to incentive all vault nodes to put rewards into staked service nodes so they can gather those as well. vault nodes always receive more then service nodes with same ROI per staked loki... then their is no need for bad actors.. and no need for old vault nodes to  restake into vault nodes since they would just be competing against vault node reward competition agains thier own nodes only the richest can purchase a full vault node.
Everyone will do what makes them profit the most which would be to stake vault node emissions into service nodes. which means that the first few vault node owners that control majority of emission now will give up their position of having a larger number of nodes then most people as they unstake to stake into vault nodes which will allow enough emission to slowly reclaim thier postion with a larger number of nodes back into service nodes again.
This is just how it is I get that. Im just hoping the nodes come online Extremely fast otherwise we are going to have an opportunity for new money to actually buy into vault nodes and then later control service nodes even though the total amount sybill resistance goes up with each staked loki.
Im hoping their can be partial node stakes like on service nodes? This will allow old money of good actors thats been around since the beginning of the network to actually be able to buy into the vault nodes.

Last calls for comments on LRC 7 before a conclusion is drawn! I'll leave it open for another few days just in case anyone else wants to weigh in after they've had a chance to review the full Blockswap paper released by team

Conclusion:
At the Pulse upgrade,  redirect the 6 Loki per block mining reward to a Blockswap liquidity fund (6 month expiry). If the liquidity fund reaches it's expiry time, the network will simply stop producing it and scale back LF rewards so that it is still 10% of the reward.
At the next upgrade that includes Vault Nodes, this 6 Loki per block can be combined with a 4 Loki per block cut from the SN reward pool and will be granted to Vault nodes.
We may open a new LRC before that upgrade as a confirmatory exercise in this token economics plan.
BRING ON PULSE!