I wonder if we can entice appkit users after JNI layer in ergo-lib is finished? 🙂
I 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
IThat’s great idea! Thanks 
will talk to their team
will talk to their teamGI'll do it tomorrow.
Mwow, if you do it tomorrow that is way faster than expected 
GI meant I'll make an issue detailing workflow and missing parts in appkit.
Mno problem 
Appreciate a spec showcasing how to use it then!
Appreciate a spec showcasing how to use it then!
AAH backend:
- Handling forks
- Now handles unconfirmed txs and avoids double biddings
- User sign in with wallet
- Collection standard implementation WIP
AH UI: - Minting artwork page is added
- New auction page is done
- Artwork specific page is done
- Nautilus is added
LGuapSwap:
- still working on whitepaper/tokenomics
- finished: token allocation, vesting schedule for devs, competitor analysis, main token use case, FIMO (fair initial mining offering) details with getblok, preliminary meeting with UI/UX designer for GuapSwap GUI
- in progress: exploring additional GUAP token use case with GuapSwap PAY and GuapSwap OASIS enabling a potential mechanism for adverting token price deflation via accepting service fees in GUAP and sending them back to the emission contract (i.e. somewhat analogously to how miner fees work)
- working on integrating landing page ui into actual frontend
- using docusaurus for landing page and docs website
- working with cheese to integrate babel fees support into appkit (necessary for guapswap and getblok)
- will be needed for token2token swaps
HExle Update
- Implemented reduced tx for proxy contracts
- Implemented V2 proxy contracts where boxes are created with registers -> This allows us to build a decentralized system
- Integrated a version of ErgoPay within exle to utilize the new reduced Tx
- Fixed up issues within LendBox, and Repayment Box
- Implemented Distribution Repayment Fix
HReally looking forward to this @kb
Do you also have token support on your roadmap? And if so will that include NFTs as collateral?
Do you also have token support on your roadmap? And if so will that include NFTs as collateral?
WWhy do many nodes report 169.254.x.x as IP? I believe when there is no declaredAddress, either the node which doesn't have it or a node that it connects to makes it up, but it looks like a bug to me
WThen again I'm not sure if
null169.254.x.x IPs are reserved
MTake a look in #ergo-watch
Tim trying to run a testnet node but it cant connect to any peers - im running v4.0.35 with
--testnet and a valid testnet.conf, it says Running in testnet network mode so i know its workingTdo i have to run a different branch to run the testnet? or should i be able to do it off of a normal release?
T/v2/info returns:
Zyou'll need to run 5.0 for testnet now
ZGitHub
5.0.0 RC1 release for testnet.
It has auto-voting for 5.0 soft-fork by default, starting from height 4,096.
Please note, from this release the node has 9021 port for p2p interactions for the testne...
It has auto-voting for 5.0 soft-fork by default, starting from height 4,096.
Please note, from this release the node has 9021 port for p2p interactions for the testne...
Tok is that compatible with v4.x.x? or is that breaking?
Tmostly for mining stuff but api definition etc