Pages:
Author

Topic: [ANN][ZANO] New Sources|1st ProgPowZ|PoW/PoS Hybrid|Scalable|Private|Contracting - page 2. (Read 36422 times)

hero member
Activity: 976
Merit: 646
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 Smiley (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
newbie
Activity: 21
Merit: 1
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 Smiley (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).

sr. member
Activity: 597
Merit: 253
... and the swarm is headed towards us
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.
newbie
Activity: 21
Merit: 1
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 !
hero member
Activity: 2422
Merit: 625
SRBMiner-Multi now supports 'progpow_zano' algorithm!

Mine with your AMD gpu's!

https://bitcointalksearch.org/topic/srbminer-multi-gpu-cpu-miner-094-5190081
sr. member
Activity: 597
Merit: 253
... and the swarm is headed towards us
sr. member
Activity: 597
Merit: 253
... and the swarm is headed towards us
sr. member
Activity: 597
Merit: 253
... and the swarm is headed towards us
sr. member
Activity: 597
Merit: 253
... and the swarm is headed towards us
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

newbie
Activity: 21
Merit: 1

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.
hero member
Activity: 976
Merit: 646
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).




newbie
Activity: 21
Merit: 1
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 ?
newbie
Activity: 20
Merit: 0
@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.
newbie
Activity: 21
Merit: 1
@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
newbie
Activity: 20
Merit: 0
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/
sr. member
Activity: 597
Merit: 253
... and the swarm is headed towards us
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!

newbie
Activity: 21
Merit: 1
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
sr. member
Activity: 597
Merit: 253
... and the swarm is headed towards us
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
sr. member
Activity: 597
Merit: 253
... and the swarm is headed towards us
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.
newbie
Activity: 21
Merit: 1
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
Pages:
Jump to: