Yes, figuring out IP addresses with Tor is quite hard precisely because of the mitigations stated above, which don't exist in tor-connect. Hence my reluctance of the use of this new and quite experimental library.

There is also a misunderstanding of what is currently a threat with using exit nodes : it's not per-se the information exchanged, which as you stated is public, the real risk here is a DoS and a fragmentation of the network. There is more details of these attacks on the research I linked in a previous comment.

This is also why I asked if onion services will be enforced by default, because it mitigate all of these risks. Basically, using Tor without enforcing the use of onion services (for all platforms, mobile or desktop) will do more harm than good privacy and security wise. And even if enforced, the effectiveness of it will largerly depend on its 'good' implementation by the developers, Tor is all but a silver bullet and require a deep understanding of its functioning in order to be effective.

Using the official Tor code/library would be a huge gain of time, while simultaneously more private and secure. I do understand that it took (maybe a lot of) time to develop tor-connect, and that it feels annoying not to use it, but still going for it just for that reason would be a sunk cost fallacy as there isn't objectively any good reason to do so.

Awesome !


Oh, I wasn't expecting a full reimplementation of the Tor stack. Is there any particular technical reason I am missing ?
Because there's so much way it could go wrong : no padding, no guard rotation, no pluggable transport for censorship resilience, and 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 be done by other projects, maybe it would be more interesting to go that way than reinventing the wheel ?

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

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 !

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, 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 unlocked, 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.

Perfect, thank you very much !


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 ?

@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

Ok, thanks for the clarifications. While I did see some work on RingCT in the Github repository, I didn't see anything regarding any 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 watch blog posts with attention.
Regards

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 also would like to understand how you would 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

Currently it isn't possible to mine with mixed Hawaii/RX AMD cards, it would be cool to add support for being able to mine with them simultaneously

Seems a problem with the miner itself and not the configuration then

Any idea please ?

Any idea please ?

Hi,

I'm using the 15.0 miner version on Linux with 3 AMD cards, 2x R9 390X and 1x RX VEGA64, but it seems like the miner only recognize either the two R9 or only the RX, even if the three are recognized by the system ?

Is there a potential fix for this issue ?

Thanks in advance

Would like to see leaf support too

Hey, no matter what version is used (12.0.1 or 12.1.0) there's a lot of rejected share for the Beam algo (~20%, with no oc at all)
Also, it's impossible to use another pool that sparkpool for beam (tried with and without rig name) :

Nice, thank you !

Will Sapling be implemented anytime soon ?

On the wallet go under tools > debug > console and type "rewindchain 1000"

Try in the debug console the command :