[ANN][ZANO] New Sources|1st ProgPowZ|PoW/PoS Hybrid|Scalable|Private|Contracting

[OrsonJ]

Hi,
Is there any plan to enhance the privacy of the node IP address ? Like by using Tor or I2P ? Also, is there any bounty open for such tasks, so third party dev' could implement them and being paid in Zano ?

I would like to understand how you will implement RingCT + PoS, because as far as I know the amount needs to be revealed to check that the 'weight' is indeed correct. I guess that you could include a range proof instead of revealing the exact amount, but it still is a big hint of the real UTXO amount. So how exactly do you plan to resolve this issue ?

Regards

Hi, thanks for the questions. An update to node privacy is already planned, but there's no bounty as the devs have already done some work on it and will move to finishing that up as soon as wrapped Zano is launched.

The exact implementation of PoS with hidden amounts is still being finalized, but once it's done there will be a technical paper with details of the scheme for public review.
I'm not aware of any bounties for dev work at the moment, but I'll double-check it.

[1715266425]

1715266425

[1715266425]

1715266425

[1715266425]

1715266425

[1715266425]

1715266425

[1715266425]

1715266425

[1715266425]

1715266425

[OrsonJ]

There are no other dev bounties at the moment, but if at any point that changes we'll announce it on the blog: https://medium.com/zano-news

[Derloda]

Hi, thanks for the questions. An update to node privacy is already planned, but there's no bounty as the devs have already done some work on it and will move to finishing that up as soon as wrapped Zano is launched.

The exact implementation of PoS with hidden amounts is still being finalized, but once it's done there will be a technical paper with details of the scheme for public review.
I'm not aware of any bounties for dev work at the moment, but I'll double-check it.

Ok, thanks for the clarifications. While I did see some work on RingCT in the Github repository, I didn't see anything regarding node privacy enhancement. As Zano use PoS, this is crucial : I could easily write a PoC which would associate an amount of Zano to an IP address, simply by observing how often an IP address would mint a new PoS block. This is a big threat to privacy, and could put any person owning a good amount of Zano and running a node from home in physical danger. I do understand that dev' time is not unlimited, and this is why I asked if any bounty was open, which could spare some time to official Zano developers, and benefits to the whole community.

Thanks again for the transparency, I'll read blog posts with attention.
Regards

[OrsonJ]

Hey all. Here's the latest Zano Bi-weekly Progress Report with news on Wrapped Zano, Val's Proof-of-Stake with hidden amounts scheme and a few other bits and pieces.

https://medium.com/zano-news/zano-bi-weekly-report-3rd-august-2021-27b3561d1169



Enjoy!

[sowle]

I would like to understand how you will implement RingCT + PoS, because as far as I know the amount needs to be revealed to check that the 'weight' is indeed correct. I guess that you could include a range proof instead of revealing the exact amount, but it still is a big hint of the real UTXO amount. So how exactly do you plan to resolve this issue ?

Thanks for the question! As OrsonJ said, we'd been working on a technical paper and released it recently: https://github.com/hyle-team/docs/tree/master/PoS/PoS_with_HA
I hope it will help to get the idea. Feel free to ask any questions. Any comments, thoughts and feedback are also much appreciated!
Here's the link to our reddit post where some valuable comments might also appear: https://www.reddit.com/r/Zano/comments/oz4bol/technical_discussion_a_proofofstake_scheme_for/

[Derloda]

@OrsonJ and @sowle, congratulation for the release of the technical paper ! My only interrogation would be about the part 3.2, where it is said that hf could be considered random, but the owner somewhat controls f : wouldn't it be possible for him to choose a f that gives him an advantage in the resolution of the inequation 3.2 ? For instance, if f = L, wouldn't hf always be 0 because of the modulo L ?

I was also wondering, is such scheme compatible with Cold Staking ? I couldn't find any info regarding this security feature on the roadmap, is this something that could be implemented in Zano in the future ?

Congrats again for the release,
Regards

[sowle]

@OrsonJ and @sowle, congratulation for the release of the technical paper ! My only interrogation would be about the part 3.2, where it is said that hf could be considered random, but the owner somewhat controls f : wouldn't it be possible for him to choose a f that gives him an advantage in the resolution of the inequation 3.2 ? For instance, if f = L, wouldn't hf always be 0 because of the modulo L ?

Thank you too much!
This is a very good question! Indeed, if f = L an adversary may stake very easily as L mod L = 0 and thus hf = 0 too. This is why I added f != 0 (mod L) requirement to section 3.3. And there's an easy way to ensure f != 0 for commitments without additional data. I'm going to cover this in the next paper update.

I was also wondering, is such scheme compatible with Cold Staking ? I couldn't find any info regarding this security feature on the roadmap, is this something that could be implemented in Zano in the future ?

We at Zano don't favor cold staking much because we believe it creates incentives that favor centralization.

[Derloda]

This is why I added f != 0 (mod L) requirement to section 3.3. And there's an easy way to ensure f != 0 for commitments without additional data. I'm going to cover this in the next paper update.

Perfect, thank you very much !

We at Zano don't favor cold staking much because we believe it creates incentives that favor centralization.

Mhh, I don't know if we are talking about the same implementation of cold staking : I was referring to the ability to stake with funds secured in a Hardware Wallet. So, even if someone succeed to compromise my computer, my funds would still be safe. This is imho an important security feature. I share your concerns regarding an implementation that allows the creation of "Staking Pools", I also do not like this type of centralization and this is not what I was referring to. So my exact question would rather be, is staking with funds secured in a hardware wallet something that Zano could do in the future ?

[crypto_zoidberg]

This is why I added f != 0 (mod L) requirement to section 3.3. And there's an easy way to ensure f != 0 for commitments without additional data. I'm going to cover this in the next paper update.

Perfect, thank you very much !

We at Zano don't favor cold staking much because we believe it creates incentives that favor centralization.

Mhh, I don't know if we are talking about the same implementation of cold staking : I was referring to the ability to stake with funds secured in a Hardware Wallet. So, even if someone succeed to compromise my computer, my funds would still be safe. This is imho an important security feature. I share your concerns regarding an implementation that allows the creation of "Staking Pools", I also do not like this type of centralization and this is not what I was referring to. So my exact question would rather be, is staking with funds secured in a hardware wallet something that Zano could do in the future ?

Hi, thank you for the question.
From that perspective it is possible theoretically, but only if there will be a hardware wallet that will be able to provide necessary information for staking algo (such as key images), and also it should be capable to perform signing of generated blocks without user interaction(which is not considered as a weakness, since it can't lead to unauthorised transfer of coins if properly implemented).

[Derloda]

Hi, thank you for the question.
From that perspective it is possible theoretically, but only if there will be a hardware wallet that will be able to provide necessary information for staking algo (such as key images), and also it should be capable to perform signing of generated blocks without user interaction(which is not considered as a weakness, since it can't lead to unauthorised transfer of coins if properly implemented).

I don't think this kind of implementation would be the right way to do it : hardware wallet are not powerful devices, it should not be up to them to perform the signing of generated blocks, or any operation where execution speed actually matters not to submit a stale block. They are also highly limited by storage, so storing key images is also not an option. Because of these limitations, the Monero client for instance ask for view key export each time the client is opened, and let the client do the scanning. Finally, by signing without user interaction, it means such devices would need to be left in unlocked state, which is a weakness.

There should be a better way, by letting the Zano client doing these operations in standalone mode (after 'unlocking' it for staking with the hardware wallet). Requiring interaction with the hardware wallet upon opening, and/or locking staking only to the user address should be sufficient not to allow the creation of staking pool while keeping the system just as efficient and far more secure.

[OrsonJ]

Time for the latest Zano Bi-weekly Report. It's been a busy couple weeks, I recommend you read it.

https://medium.com/zano-news/zano-bi-weekly-report-23rd-august-2021-a797ce4b7179

[OrsonJ]

Wrapped ZANO — Bridging Privacy and Ethereum



https://medium.com/zano-news/wrapped-zano-bridging-privacy-and-ethereum-2e8af76f07c7

[OrsonJ]

Zano Evolving: New Look, New Blog, Same Mission



https://blog.zano.org/new-blog-new-look-same-mission/

[OrsonJ]

Zano Bi-weekly Report (19th October 2021)



https://blog.zano.org/zano-bi-weekly-report-19th-october-2021/

Enjoy!

[doktor83]

SRBMiner-Multi now supports 'progpow_zano' algorithm!

Mine with your AMD gpu's!

https://bitcointalk.org/index.php?topic=5190081.0

[Derloda]

Hi @OrsonJ, thanks for the report article. The report state that there is work ongoing on privacy and PoS+HA upgrade, what does it mean (for the privacy part) ? I suppose that this include HA for all transactions, but does that also include work regarding nodes privacy (hiding their IP addresses) ? If so, what has been decided : Tor, I2P, something else ? Thanks !

[OrsonJ]

Hi @OrsonJ, thanks for the report article. The report state that there is work ongoing on privacy and PoS+HA upgrade, what does it mean (for the privacy part) ? I suppose that this include HA for all transactions, but does that also include work regarding nodes privacy (hiding their IP addresses) ? If so, what has been decided : Tor, I2P, something else ? Thanks !

Hey, we've decided to go with Tor. Afaik the library is ready and it's just a matter of integrating it.

[Derloda]

Hey, we've decided to go with Tor. Afaik the library is ready and it's just a matter of integrating it.

That's a great news !
Yes, Tor is a solid choice : ZCash for instance also chose it, and is funding a rust implementation named 'Arti', which is quite exciting (Let's just hope that it won't have the same ending as Kovri...)

I have a question regarding the implementation : will the use of Tor Hidden Services be enforced by default ? I personally hope so, as privacy should always be the default (or there isn't any privacy at all). And in the specific case of Tor, it eliminates the risk of malicious exit nodes (as Hidden Services don't use them), which also matters in terms of security : https://www.researchgate.net/publication/305053676_Bitcoin_over_Tor_isn%27t_a_Good_Idea (not 100% applicable to Zano, just an example of what type of attacks could be used).

[crypto_zoidberg]

Hey, we've decided to go with Tor. Afaik the library is ready and it's just a matter of integrating it.

That's a great news !
Yes, Tor is a solid choice : ZCash for instance also chose it, and is funding a rust implementation named 'Arti', which is quite exciting (Let's just hope that it won't have the same ending as Kovri...)

I have a question regarding the implementation : will the use of Tor Hidden Services be enforced by default ? I personally hope so, as privacy should always be the default (or there isn't any privacy at all). And in the specific case of Tor, it eliminates the risk of malicious exit nodes (as Hidden Services don't use them), which also matters in terms of security : https://www.researchgate.net/publication/305053676_Bitcoin_over_Tor_isn%27t_a_Good_Idea (not 100% applicable to Zano, just an example of what type of attacks could be used).

Yes, it will be enabled by default.
We already got thin TOR library, you can take a look into it if you wish: https://github.com/hyle-team/tor-connect

[Derloda]

Yes, it will be enabled by default.

Awesome !

We already got thin TOR library, you can take a look into it if you wish: https://github.com/hyle-team/tor-connect

Oh, I wasn't expecting a full reimplementation of the Tor stack. Is there any particular technical reason to do so that I am missing ?
Because there's so many ways it could go wrong : no padding, no guard rotation, no stream isolation, no pluggable transport for censorship resilience, nor every other crucial security/privacy features that Tor have implemented over time.

If this is only a matter of porting the Tor build process to CMake, which I believe has already been done by other projects, maybe it would be more interesting to go that way than reinventing the wheel ?