Anyone able to access the deposit or withdrawal menus right now on cryptox.pl?
everything is fine herethere were some problems earlier, but now – everything works fine.
Topic: Obyte: Totally new consensus algorithm + private untraceable payments - page 907. (Read 1234271 times)
February 06, 2017, 03:00:27 PM
there were some problems earlier, but now – everything works fine.
February 06, 2017, 02:59:50 PM
Anyone able to access the deposit or withdrawal menus right now on cryptox.pl?
I just login and yes everything is working fine 
February 06, 2017, 02:58:25 PM
Anyone able to access the deposit or withdrawal menus right now on cryptox.pl?
everything is fine here 
February 06, 2017, 02:57:27 PM
Anyone able to access the deposit or withdrawal menus right now on cryptox.pl?
February 06, 2017, 02:31:45 PM
I'm not really a fan of byteball consensus model, but I think there is a problem with your mining pool argument in favor of BTC consensus model: Bitmain produces almost all of the mining hardware used to mine, and there is speculation that not only antpool is a Bitmain in house mining pool, but that f2pool, viabtc, gbminers, and BTC.top are all basically just Bitmain mining with their own hardware under the guise of decentralization. This is only speculation, except for the bit about Bitmain producing almost all the hardware which is fact, but if true there is really a single entity dominating the Bitcoin network.
February 06, 2017, 01:08:56 PM
Witnesses are the single point of failure of the system. They essentially control the network and there are only 12 of them. You can imagine that if the rogue government (bankers or whoever) wants to take down the byteball system all they have to do is to take controll over 12 computers running witnesses nodes. This seems to be rather easy to do, especially at gunpoint. Moreover - this can be done without the rest of the network to even notice - if witnesses after being taken over by the rogue party are operated without interruption. Anybody who controls the 12 witnesses can do whatever he wants with the network - for example censor certain type of transactions. All of this is a contradiction to censor resistant trustless network that bitcoin is.
I can follow your arguments and respect your opinion. Bitcoin was created as a decentralized platform and that was a great invention - in the old days when everybody could easily take part in the consenus with their CPU or GPU miners, this system was still intact. But nowadays bitcoin has become a total different thing. Expensive asic miners drive bitcoin to centralization and the need for low energy costs favor some countries.
I will ask you a question: how many mining pools do you need to cross the 50% consensus barrier in bitcoin? I guess it's a lot less than 12.
It's not so simple as you imply. Mining pools does not necessarily decide about the state of the network (that power lies in miners hands). Let's assume that a rogue party took control over mining pools controlling +51% of the hashrate. If these mining pools would try to impose their will over miners (e.g. implementing changes to the protocol not supported by miners) miners would quickly drop those pools and switch to other ones which would lead to the rogue party loosing control over 51% of the hashrate. The bottom line is - to take over bitcoin the rogue party would have to take control over 51% of miners calculated as hashrate. It's not the same as 51% of mining pools as mining pools are not the same as miners. For example F2pool one of the biggest mining pools does not have its own mining hardware - it only facilitates mining for hardware operators (miners). Consequently it's much more difficult to control bitcoin because miners are more dispersed than mining pools. There are many more miners than mining pools. Definitely more than 12.
February 06, 2017, 12:29:33 PM
an other connection. this one if funny a tiny picture.
i.ytimg.com
i will no stop reporting. because i think it is clear that nwjs thing is the reason. dev will know what to do.
i.ytimg.com
Quote
wants to connect to i.ytimg.com on TCP port 443 (https)
IP Address 172.217.22.174
Reverse DNS Name arn09s11-in-f14.1e100.net
Established by /Applications/Byteball.app/Contents/MacOS/nwjs
Process ID 3668
something googelish according the IP
IP Address 172.217.22.174
Reverse DNS Name arn09s11-in-f14.1e100.net
Established by /Applications/Byteball.app/Contents/MacOS/nwjs
Process ID 3668
something googelish according the IP
i will no stop reporting. because i think it is clear that nwjs thing is the reason. dev will know what to do.
Thanks for reporting. As other people said here and in a few github issues, it is some (supposedly dead) code in nwjs making connections to google properties. These connections will be blocked in the next release. If you want to block them now, edit your package.json by adding this proxy setting:
https://github.com/byteball/byteball/commit/dfdd00808e3ac8f3268e7e346c2009bb403260f5
The location of package.json on Mac is /Applications/Byteball.app/Contents/Resources/app.nw/package.json.
February 06, 2017, 11:01:34 AM
Hi tonych,
Please, let us known if the following reasoning is correct.
Say there are N wallets running on the byteball network at a given time.
All of them have the same list of 12 witnesses, all them being the 12 witnesses services you currently run to bootstrap the network securely.
Now, imagine that each one of those N wallets change 1 of their witnesses to another one, but that every one change to a different one (I know that is not the way it's meant to occur in practice, but this is a theoretical reasoning). I mean, now there are N different witnesses plus the 12 you run.
After this, is it possible for any wallet to change its list of 12 witnesses, at the same time, by any subset of 12 witnesses from the N witnesses set there are now at the network (not your 12 ones)?
Please, let us known if the following reasoning is correct.
Say there are N wallets running on the byteball network at a given time.
All of them have the same list of 12 witnesses, all them being the 12 witnesses services you currently run to bootstrap the network securely.
Now, imagine that each one of those N wallets change 1 of their witnesses to another one, but that every one change to a different one (I know that is not the way it's meant to occur in practice, but this is a theoretical reasoning). I mean, now there are N different witnesses plus the 12 you run.
After this, is it possible for any wallet to change its list of 12 witnesses, at the same time, by any subset of 12 witnesses from the N witnesses set there are now at the network (not your 12 ones)?
When changing your witness list you remove one old witness and replace it with a new one. If the removed witness is the same on all nodes (which is more likely in practice, e.g. if negative information about a witness is released), all nodes stay compatible: only one mutation relative to the old list and relative to each other. The nodes can perform more changes as long as their new lists stay compatible.
February 06, 2017, 09:56:38 AM
Yeah, guys you can avoid the desktop wallet contacting clients1.google.com by starting it like this
$ export https_proxy=http://127.8.8.8
$ export http_proxy=http://127.7.7.7
$ ./Byteball
That is, nw.js respects the environment variables https_proxy and http_proxy, so you can achieve
the same effect when setting a fake proxy in your System settings, if you arent comfortable starting apps from command line.
In waiting for better solution this will do.
$ export https_proxy=http://127.8.8.8
$ export http_proxy=http://127.7.7.7
$ ./Byteball
That is, nw.js respects the environment variables https_proxy and http_proxy, so you can achieve
the same effect when setting a fake proxy in your System settings, if you arent comfortable starting apps from command line.
In waiting for better solution this will do.
February 06, 2017, 09:53:22 AM
I read those sections, but (the way I understand it at least) at some point the network still relies on trusted nodes to function, leaving it wide open to sybil attacks.
Could you be more specific please, how would you sybil attack?
Dev:
Code:
Could not sent payment:know bad
Why send is so unstable,It have a lot of bugs.yes of course he can be more specific who is giving such knowledge all of us.
February 06, 2017, 07:58:11 AM
How do you guys think the future price? Will it go much lower than now? The supply in circulation will be much more. I doubt the price will be dropping hard or not?
i think that some dump is predictable (esp after the circulation rising).
but also we can expect the rise after goin' into the top 20.
February 06, 2017, 07:55:51 AM
How do you guys think the future price? Will it go much lower than now? The supply in circulation will be much more. I doubt the price will be dropping hard or not?
February 06, 2017, 07:16:11 AM
an other connection. this one if funny a tiny picture.
i.ytimg.com
i will no stop reporting. because i think it is clear that nwjs thing is the reason. dev will no what to do.
Dont stop reporting, curiously, this one is very weird, now Im gonna see if this happens on Linux wallets, will report back.i.ytimg.com
Quote
wants to connect to i.ytimg.com on TCP port 443 (https)
IP Address 172.217.22.174
Reverse DNS Name arn09s11-in-f14.1e100.net
Established by /Applications/Byteball.app/Contents/MacOS/nwjs
Process ID 3668
something googelish according the IP
IP Address 172.217.22.174
Reverse DNS Name arn09s11-in-f14.1e100.net
Established by /Applications/Byteball.app/Contents/MacOS/nwjs
Process ID 3668
something googelish according the IP
i will no stop reporting. because i think it is clear that nwjs thing is the reason. dev will no what to do.
Until then, just maybe, you have some kind of virus/malware on your MacOS which would also cause this.
EDIT: Yes, mine too is talking to clients1.google.com and arn09s10-in-f142.1e100.net on startup. Thats the y.img you see too. clients.l.google.com also resolves to it.
February 06, 2017, 07:15:09 AM
an other connection. this one if funny a tiny picture.
i.ytimg.com
i will no stop reporting. because i think it is clear that nwjs thing is the reason. dev will no what to do.
i.ytimg.com
Quote
wants to connect to i.ytimg.com on TCP port 443 (https)
IP Address 172.217.22.174
Reverse DNS Name arn09s11-in-f14.1e100.net
Established by /Applications/Byteball.app/Contents/MacOS/nwjs
Process ID 3668
something googelish according the IP
IP Address 172.217.22.174
Reverse DNS Name arn09s11-in-f14.1e100.net
Established by /Applications/Byteball.app/Contents/MacOS/nwjs
Process ID 3668
something googelish according the IP
i will no stop reporting. because i think it is clear that nwjs thing is the reason. dev will no what to do.
good job but don't go paranoid.
just collect the all issues and make gathered report, it would be better than separate posts.
February 06, 2017, 06:52:47 AM
an other connection. this one if funny a tiny picture.
i.ytimg.com
i will no stop reporting. because i think it is clear that nwjs thing is the reason. dev will know what to do.
i.ytimg.com
Quote
wants to connect to i.ytimg.com on TCP port 443 (https)
IP Address 172.217.22.174
Reverse DNS Name arn09s11-in-f14.1e100.net
Established by /Applications/Byteball.app/Contents/MacOS/nwjs
Process ID 3668
something googelish according the IP
IP Address 172.217.22.174
Reverse DNS Name arn09s11-in-f14.1e100.net
Established by /Applications/Byteball.app/Contents/MacOS/nwjs
Process ID 3668
something googelish according the IP
i will no stop reporting. because i think it is clear that nwjs thing is the reason. dev will know what to do.
February 06, 2017, 06:17:15 AM
thank you for the bytes and thanks for the explanation concerning the connections through TOR.
i will try to find out what exactly is send to google. or do you already know this.
I do not know, its difficult to find out since its TLS 443.i will try to find out what exactly is send to google. or do you already know this.
You can also block it by saying in your /etc/hosts 127.1.2.3 plus.google.com google.com but that will block for all other programs too.
To reveal what it is requesting is, if on Linux, run it with strace with filter on file/read/write and network system-calls.
February 06, 2017, 06:12:43 AM
why does the OS X app try to connect to google?
plus.google.com TCP-Port 443 (https)
plus.google.com TCP-Port 443 (https)
What makes you think so?
There are no references to any sites (except the default hub) in the source code.
because little snitch tells my that the app wants to connect.
Google is known for adding a bunch of shit in every source-code they touch to "resolve" something on their servers. This could be information leakage, especially when using it over Tor - who knows what it sends to Google even if it is the hostname and datetime its too much.
@tonych, maybe see if there is a default option which has to be turned off when importing/using nwjs?
edit: https://github.com/nwjs/nw.js/issues/5343 just one issue, expect 100 more "accidents" by google. edit2: if using the chromiu-args proxy workaround, make it something else than 127.0.0.1, like 127.6.6.6 to avoid more other problems.
everyone how is happy that i posted this can send my some bytes. i still don't have any.
ZLQAYBCCZT2DBBD6KSLXJYCYR6QMU2VK
thank you very much.
i am not sure if this is a security problem if you use a VPN.
but with tor? if not every connections is torified then this could really leak your IP.
i don't want to fud. i am just concerned about privacy. and i am not a hardcore techie.
If wallet is torified/socksify/proxychains-ng, the call to google will also go over Tor. Will not leak your public IP, but still not good.
Let me add, and even more so if you use whonix.
I can attest it works.
February 06, 2017, 06:04:18 AM
thank you for the bytes and thanks for the explanation concerning the connections through TOR.
i will try to find out what exactly is send to google. or do you already know this.
i will try to find out what exactly is send to google. or do you already know this.
February 06, 2017, 06:01:14 AM
why does the OS X app try to connect to google?
plus.google.com TCP-Port 443 (https)
plus.google.com TCP-Port 443 (https)
What makes you think so?
There are no references to any sites (except the default hub) in the source code.
because little snitch tells my that the app wants to connect.
Google is known for adding a bunch of shit in every source-code they touch to "resolve" something on their servers. This could be information leakage, especially when using it over Tor - who knows what it sends to Google even if it is the hostname and datetime its too much.
@tonych, maybe see if there is a default option which has to be turned off when importing/using nwjs?
edit: https://github.com/nwjs/nw.js/issues/5343 just one issue, expect 100 more "accidents" by google. edit2: if using the chromiu-args proxy workaround, make it something else than 127.0.0.1, like 127.6.6.6 to avoid more other problems.
everyone how is happy that i posted this can send my some bytes. i still don't have any.
ZLQAYBCCZT2DBBD6KSLXJYCYR6QMU2VK
thank you very much.
i am not sure if this is a security problem if you use a VPN.
but with tor? if not every connections is torified then this could really leak your IP.
i don't want to fud. i am just concerned about privacy. and i am not a hardcore techie.
If wallet is torified/socksify/proxychains-ng, the call to google will also go over Tor. Will not leak your public IP, but still not good.
February 06, 2017, 05:52:00 AM
Hi tonych,
Please, let us known if the following reasoning is correct.
Say there are N wallets running on the byteball network at a given time.
All of them have the same list of 12 witnesses, all them being the 12 witnesses services you currently run to bootstrap the network securely.
Now, imagine that each one of those N wallets change 1 of their witnesses to another one, but that every one change to a different one (I know that is not the way it's meant to occur in practice, but this is a theoretical reasoning). I mean, now there are N different witnesses plus the 12 you run.
After this, is it possible for any wallet to change its list of 12 witnesses, at the same time, by any subset of 12 witnesses from the N witnesses set there are now at the network (not your 12 ones)?
Please, let us known if the following reasoning is correct.
Say there are N wallets running on the byteball network at a given time.
All of them have the same list of 12 witnesses, all them being the 12 witnesses services you currently run to bootstrap the network securely.
Now, imagine that each one of those N wallets change 1 of their witnesses to another one, but that every one change to a different one (I know that is not the way it's meant to occur in practice, but this is a theoretical reasoning). I mean, now there are N different witnesses plus the 12 you run.
After this, is it possible for any wallet to change its list of 12 witnesses, at the same time, by any subset of 12 witnesses from the N witnesses set there are now at the network (not your 12 ones)?
Jump to: