The full Accelerator-Z proposal can be found here at ledger-app-zenon/az.md at main · hypercore-one/ledger-app-zenon · GitHub
11 Likes
Wow. This is a super exciting and needed project. I’m happy to help in any way possible. I suspect an audit would cost more (a lot more) than the bridge. Maybe I can work with some other pillars to get together the funds to pay for an audit in the future. So maybe that can be our contribution when the time comes.
Also happy to help with any project management / coordination type activities.
4 Likes
Congrats on the project. I will temporarily move it to ╰ Funding | Staging and once you submit it on-chain we will move it back to ╰ Funding | Submissions.
1 Like
Thanks.
@0x3639 Not sure what pricing we’re talking about yet, will try to find out some estimates and include it in the final proposal. One of the requirements for auditing a developer release is that the coin needs to be in the top 600 on CMC. Not that much of an issue the way we’re currently going (rank #692). More on the conditions can be found here.
1 Like
Hardware wallet support is important for the masses.
I’ve already started working on an implementation for the Syrius ↔ Ledger connection.
The Ledger device should only sign the final accountBlock and Syrius will populate all required fields including generating Plasma via PoW, if necessary.
We need someone that has in-depth Rust knowledge to code the embedded app. I think it’s both easier and safer than using plain old C.
Examples of Ledger apps in Rust:
Other resources:
But first I need to finish all other projects 
5 Likes
Ledger support would be incredible, especially for all of us long term holders.
Do keep in mind that full support will likely require some changes not only to Syrius itself, but probably also to the APIs, and possibly also to some of the internal contracts. A couple of examples:
- For complete support we will need a way to move pillars/sentinels from one address to another without dismantling them (and re-burning QSR, etc). Without this all existing pillars/sentinels will forever stay in “hot” wallets.
- To receive “unreceived” transfers, does Syrius need to implicitly sign something? If so, then likely a UI change will be needed to show unreceived transactions and ask the user to sign them on the ledger. It’s a bit less convenient, but at least it gives more control and I’m not sure there is any way around it anyway.
4 Likes
Thanks for the resources @aliencoder
Rust is indeed an easier and safer option. The sdk for rust seems to lack behind the official sdk a bit, but it will probably be enough for our requirements. I’ll make sure to include it in the proposal.
Exactly, although creating another address would be the least desired option. Wouldn’t it be possible to use the same BIP-39 24-word mnemonic to create the master seed for the Ledger device.
You need to sign to receive unreceived transactions. I believe this was already on the list of s y r i u s improvements. The ability to automatic/manual receive transactions. Whatever the case, the UI will need to able to handle both cases. The file based wallet implementation of the SDK’s will need a layer of abstraction. This way s y r i u s can just use the abstract interface for interacting with the wallet.
This is likely possible, but imo it’s not an acceptable solution. The whole point of using a ledger is that your private key (and seed) were never shared in a digital form. When you created the syrius wallet and got the seed it was already on your PC (or wherever you created it). Moving it to a ledger is pointless even if you delete it from your PC. Once it was there this could no longer be considered a cold wallet and will never be as secure as such…
So to do it right I see no way around it other than allowing migration of pillars/sentinels to new addresses.
1 Like
You’re right, valid points and having the ability to migrate pillars/sentinels is a useful feature no matter the application. The consequences of a change of address will have to be thoroughly investigated. Although it is certainly useful to have this functionality, I don’t consider it a requirement for the Hardware wallet. Maybe this is something for the go-zenon devs to pick up on?
1 Like
Agreed - would consider it an independent feature (that would be very valuable once we have ledger support).
1 Like
I’ve worked out the proposal and would like to ask the community for a final round of feedback before submitting the proposal.
The full Accelerator-Z proposal can be found here at ledger-app-zenon/az.md at main · hypercore-one/ledger-app-zenon · GitHub
@aliencoder you have indicated that you are working on the implementation of the Syirus ↔ Ledger link. Can you give more details about what exactly you are working on, how you plan to make it and why you started with the implementation of the connection?
1 Like
Basically the communication between Syrius (Dart code) and the Ledger device. I plan to use existing libraries and open source code. I’ve started with the implementation of the connection because it’s the most basic thing that we can start with:
- Detect the Ledger device in Syrius
- Open a port (via USB) on the Ledger device (Nano Ledger S and X)
- Send raw bytes to the Ledger device (account block with Plasma computed by Syrius)
- Listen to the raw bytes (account block signed)
- Publish the account block and propagate it into the network
I want to mention that the connection to the Syrius desktop wallet will be available over an USB port.
Only Nano Ledger X supports Bluetooth. It’s suitable for the mobile apps integration.
1 Like
Not owning your own keys anymore huh!
Thanks for the update @mr.ztark
The feature seems to be optional and only for Ledger Nano X devices, but still definitely a step in the wrong direction if you ask me.
They’ll have to revert I imagine, the added revenue from the recovery subscription likely won’t offset lost sales/customers who are impacted by this change
1 Like
The worst part is that they set a precedent. Basically they publicly admitted that they can “manage” your private keys OTA. They literally shitted on their security model (private keys don’t leave the device). I won’t trust them from now on with any of their products.
1 Like
They might not have that option. If the only 2 options were leak private keys OR shut down the service, they probably chose the 2nd one so they can continue to “milk” the business.
Otherwise I don’t see how a business could misunderstand its own product at such a level.
I’ll do a poll to gauge the community interest in developing a Ledger implementation given the (bad) news.
- Go ahead with Ledger
- Ledger can be considered compromised
- Other hardware wallet implementation
0
voters
Pretty sure that the majority of users won’t care or are even glad to have a backup option. Dont forget why so many people would pay to hold crypto at a bank. Only few are so dogmatic about self custody. We need multi hw and sw wallet support anyway.
2 Likes