Like comments witch description what was changed?
Like comments witch description what was changed?
KYeah, motivation and what is done
KIs ergonames design published? Could help with concurrency and frontrunning prevention
LYes all on chain, planning to build through operations/proof in context vars
LErgoPOS development update
- Merchant registration API completed.
- Merchant withdrawal submition API completed.
KSo now just wallet support is needed?
GWith the last Update Pool Box command implemented, we will have all the parts ready. Next is to test how it flies as a whole. 
I'll get back to launching and running an oracle pool on testnet as a smoke test after I finish with current urgent sigma-rust issues (token burn, dist sigs, etc.). After that and a few housekeeping tasks, I believe we will be ready for an open public test.
Here is what's left in our milestone - https://github.com/ergoplatform/oracle-core/milestone/1
I'll get back to launching and running an oracle pool on testnet as a smoke test after I finish with current urgent sigma-rust issues (token burn, dist sigs, etc.). After that and a few housekeeping tasks, I believe we will be ready for an open public test.Here is what's left in our milestone - https://github.com/ergoplatform/oracle-core/milestone/1
GitHub
Core off-chain component of Oracle Pools. Contribute to ergoplatform/oracle-core development by creating an account on GitHub.
KGood, as context vars can be pruned in future
GYes.
Mfor JVM wallets (Wallet app iOS/Android/desktop, satergo) and dapps building up on appkit we need support in appkit or ergo-wallet before we can do any integration
K@Cheese Enthusiast @Luivatra i think we can have plasma-or-rollup kind of design, where publisher is publishing state digests and update digests, and only in case of contestation publishing a rollup, against which it could be another contestation. So minimal plasma load in optimistic case, rollup in case of a dispute
GYeah, I should've emphasized it more in progress reports and in separate shout-outs.
K@mhs_sam @anon_real @anon2020s @haileypdll @pragmaxim @ApexTheory @kii @Cheese Enthusiast @Luca D'Angelo any updates?
GThe last missing piece for SPV API was p2p discovery via the REST in Chrome. @TimL did an awesome job, diving into it and effectively writing a separate code path of the whole discovery process for Chrome.
LWho is the publisher here? Could it be similar to oracle pool?
WLike in rollup, someone is publishing updates
LI need to read up on that
CThat's awesome, I'll start looking into it and bothering you with doubts for sure 
JNight Owl Weekly Dev Update [27/07/2022] 
Frontend
• 95% completed Games page (lists all games, directory)
• Added result notification with share to social media buttons
• Added randomized money sounds (6 sounds) when won a bet
• Bet warnings implemented (max bets, insufficient bet)
• Refactoring Roulette
• Bigger font added to Roulette table
• Loading animation for wallet connection
Backend
• Stand up staging instance for a more stable environment
• Final testing for Night Owl backend services v0.1.0, create a tag, make repo public, build, and deploy the release to dev and staging instances
• Completed all core platform smart contracts
Other
• Working on documentation, e.g., Getting Started, How to plays, etc
Frontend
• 95% completed Games page (lists all games, directory)
• Added result notification with share to social media buttons
• Added randomized money sounds (6 sounds) when won a bet
• Bet warnings implemented (max bets, insufficient bet)
• Refactoring Roulette
• Bigger font added to Roulette table
• Loading animation for wallet connection
Backend
• Stand up staging instance for a more stable environment
• Final testing for Night Owl backend services v0.1.0, create a tag, make repo public, build, and deploy the release to dev and staging instances
• Completed all core platform smart contracts
Other
• Working on documentation, e.g., Getting Started, How to plays, etc
GI wonder if we can entice appkit users after JNI layer in ergo-lib is finished?
PI made just a small improvement on Node, sending an invalid transaction through tx and wallet api now returns 400 instead of 200 : https://github.com/ergoplatform/ergo/pull/1779
GitHub
Closes #1768
P.S. I did the same for wallet API as there was a similar case
P.S. I did the same for wallet API as there was a similar case
MI think this may be a viable option, provided Appkit can continue working when ergo-lib is not properly configured or even entirely missed. So the the wallets and apps will continue working without special configuration as long as they don't call ergo-lib methods.
Jmaybe reach out to ergoPOS team for second bullet
Mfrom my experience native layer should be avoided if anyhow possible. using a native layer means that it has to be build for every platform and architecture targeting, which can quickly end up in an overgrowing deployment effort
K
duckpools update - All core platform smart contracts written
- Proxy contracts written for scaling
- UI integration with smart contracts complete for:
- Lend and withdraw ERG from ERG lending pool
- Borrow ERG from ERG lending Pool
- UI Stats complete for:
- Pool Utilisation
- Pool Interest Rate
- User position in pool
MCan someone please explain the significance of this?
CThis is a great idea, so essentially you have an optimistic rollup which can batch together transactions in worst case, while normal plasma security assumptions are assumed in best case. And both can be challenged in case of contestation.
GOne can check if the payment(box) is in the chain without access to a trusted node.
EDIT: I mean with access to untrusted nodes only.
EDIT: I mean with access to untrusted nodes only.
CGetBlok.io Updates:
SubPooling:
SubPooling:
- Working on ergopad emission contracts
- Integrating new ProxyPlasmaMap to help deal with unexpected errors while creating transactions (and before they are broadcasted)
- Created custom sync function to sync off-chain data with on-chain digest in case of db corruption
- Now on Plasma 0.0.8 (Still need to post this one on github)
- Added ProxyPlasmaMap, which essentially allows operations to be performed on temporary tree identical to one in persistent storage. Modifications are queued internally so that once ready, operations done on the temporary tree are written into persistent storage. This method feels a bit safer than using db rollbacks (which I found could sometimes cause db corruption).
- Working on write up for new plasma pool contracts that exist on mainnet. These contracts use chained transactions and separate contracts for different operations, making it easy to sync up with the current on-chain digest
- Thinking about more modifications and improvements in general. If you've used the Plasma library and found something you don't like, then let me know!
Dswamp audio:
-Work on mutual release agreement smart contract is ongoing, first milestone may have been reached but more on-chain tests are required to ensure we are on the right track.
-Met with developer to scope out the stack and process flow for users / artists portal - they are presently learning their way around Ergo (they have developed solutions for ETH platforms before so its not entirely new stuff to them)
-Discussed options with developer and settled on parsing markdown data as JSON, to optimally interface with Mosaik
-Taking place in Sigma Valley treasure hunt. Try to find the hidden word on our website
-Work on mutual release agreement smart contract is ongoing, first milestone may have been reached but more on-chain tests are required to ensure we are on the right track.
-Met with developer to scope out the stack and process flow for users / artists portal - they are presently learning their way around Ergo (they have developed solutions for ETH platforms before so its not entirely new stuff to them)
-Discussed options with developer and settled on parsing markdown data as JSON, to optimally interface with Mosaik
-Taking place in Sigma Valley treasure hunt. Try to find the hidden word on our website
Mwhat does one need to be connected to, in order to verify this?
TThe CI suite in
ergo-lib is extensive as it is. Rust-native, WASM (with browser and non-browser tests) and swift. User can just go in and look at how it's done and adapt it to their own purposes.GAny node.
MI don't know what that means, but I can list you all platform/architecture combinations we need for now. how is the JNI invocation layer generated?
GI actually mostly agree with @MrStahlfelge . Making binaries for all supported Android platforms would be a PITA.
GSo far, it's in PoC state covering less than 1% of the API and written by hand over the C layer.
TFor the platforms that I mentioned, there's already ready-made instructions to build on it, by inspecting how the CI does it.
TYeah I know very little about android. I can imagine it'll be painful
Mit is not only android (which would mean deploying appkit as an aar built by an own process), but also desktop (windows x86, arm, macos x86, arm, linux x86, arm64, arm32), ios x86/arm (x86 needed for the simulator) - this is 13 different targets, additionally some kind of automated JNI layer generator which is some kind of science on its own etc etc.
GWell, actually you don't need to be connected per se. You just ask a few random nodes some queries.
TRust mostly covers all of the desktop. We're not using any OS-native code to my knowledge. ios is swift-based, so it will span over x86 and arm automatically. JNI, I don't know anything about
GWell, in theory, we really need JNI for Android only. Every other platform could use ergo-lib either directly or via its designated layer (Wasm, Swift). I know it's not the point in this case.
Every other platform could use ergo-lib either directly or via its designated layer (Wasm, Swift). I know it's not the point in this case.Mwasm from a Java desktop app? How?
Our current iOS app is done by crosscompiling the Java bytecode. No swift support but cocoapods can be used.
Our current iOS app is done by crosscompiling the Java bytecode. No swift support but cocoapods can be used.
GMore to the point though. All the underlying machinery is already implemented in the node and sigmastate's code. Appkit is just lacking the API that'll tie it all together.
Myeah I think moving the code and exposing it is the far more easy solution for appkit clients but someone with the expertise has to do it
but someone with the expertise has to do itGOh no. I meant if we don't need to work on every platform through the JVM which is not our case. Otherwise, I fully agree with you.
Mgreat. my fear is, we have wallets ready to integrate nipopows but no one has the task assigned to add them to the sdk
my fear is, we have wallets ready to integrate nipopows but no one has the task assigned to add them to the sdkGGitHub
Using NiPoPoW described in KMZ17 Goal Prove that a payment (ERG and/or tokens) was made on the blockchain. EDIT: For a recent payment it would be faster to use UTXO proof described in #502 Step 1. ...
I[ErgoDEX]
- Decentralized matching protocol for ErgoDEX (https://github.com/ergolabs/ergo-dex/blob/de-match/protocols/DeMatch.md)
- Liquidity mining protocol for ErgoDEX (WIP)
- Started implementation of Spectrum Node (side-chain solution for scaling ErgoDEX)
- Fixed swap chart price display
- Swap chart depends on from/to fields now
- Added new ergo side history ui/ux
- Fixed manual refund tx status display
- Added Liquidity page mobile layout
- Fixed Modal window resize behavior
- Transactions queueing (chaining transactions from the UI)
MI would appreciate that a lot