Quote from: FoldingTime on August 10, 2014, 07:15:16 AM

Quote from: CryptoGretzky on August 10, 2014, 06:50:37 AM

Quote from: holyprofit on August 10, 2014, 06:47:48 AM

Quote from: CryptoGretzky on August 10, 2014, 06:15:12 AM

Quote from: holyprofit on August 10, 2014, 04:30:32 AM

Quote from: adhitthana on August 09, 2014, 11:07:59 PM

Quote from: oblox on August 09, 2014, 10:11:47 PM

Dan's seen both my router's ports open and my firewall exceptions to not only the program but also ports specific to the program. Correct me if I am wrong, but didn't you say it doesn't work for you either due to being on a university network? Regardless, it doesn't work for everyone and whether all the bugs are suppose to be out by 2.5 or 3.0, it should still be something to focus attention on for mass adoption. Hell, if it doesn't work on university networks, a large portion of the demographic (18-35) interested in crypto could have issues.

If it was human error, then it should have been something extremely easy to fix on any number of the remote sessions Dan and I had. The end result is private transfers do not go out to the network/nodes but regular incoming/outgoing is fine. Whether it does nothing due to having it set as unlock for staking only and entering passphrase on sends or unlocking completely before initiating and getting the error 101, it doesn't work. Dan said it definitely shouldn't be doing the 101 error.

To truly say it's working should mean works for everyone. 99% is not 100%, especially as more and more users are downloading wallets and wanting to try out features. Any regular Joe should be able to download the wallet and send anon transfers and that simply isn't the case in its current state.

Thanks

Even bitcoin-qt won't sync on a university network due to the firewall. I never found a way around that although I tried pretty hard - with a real live version of Dan. I imagine there would be issues with encryption and tor as well. (I'm afraid 18-35 year olds may have to pay for their own internet). I should add that depending on your network it may automatically flag peer-to-peer stuff as suspicious unless you add an exception. You should probably check. (Anyway I wouldn't class getting your crypto to work over university networks as regular Joe level.)

Edit: on the other hand if Dan can get the XC wallet to work automatically behind university firewalls - which maybe he can - then that would be big bonus.

I wonder if we can make a regular http port 80 type block sync where it just download the blockchain regularly without using any special RPC type call? It won't necessarily work for private transaction immediately nor XChat, but at least you can get the latest blockchain info?

That might work so you could at least have the wallet functioning regardless of firewalls. That would be a big plus - I was imagining for the private stuff to behave like firefox when it adds exceptions - i.e. it figures out there's a firewall blocking it and brings up an option to add an exception. No idea if this is possible generally even - it would have to be able to access the relevant info about your system.

Unless... private transaction when it's multipath, can be packaged as non blockchain data that can be sent out through port 80 to nodes that other XNodes wallets can then download and relay it out as RPC?!?? Then... all wallets can be used regardless of if it's behind a firewall. Of course, you will need XNodes that are not behind firewall to get those encrypted non RPC data and relay those out as RPC? So, non firewalled XNode wallets can always help out those that are behind firewall (non http port 80 blocked of course).

This sounds like a good solution, however, I would opt to go out on 443 as that would usually be open if 80 is open. Tunnelling out on 443 is usually a good way to bypass firewalls.

Ok, maybe I shouldn't have said port 80 for announcing a transaction, but all the common ports that usually won't be blocked, as long as we can send out that encrypted packet to the nodes.