Topic: [NSFW] Official Sexcoin Thread - New MANDATORY upgrade: KGW Timewarp attack FIX - page 16. (Read 307671 times)

yeah i will say that issues like you just described with maxconn inbound etc will work exactly like bitcoin with v.9.x i have working now. I know because the code .9 started as a github fork of bitcoin and I haven't changed anything to do with the connection scheme or logic.

I think it's safe to say that the behavior you described was added after bitcoin .5 or .6, wherever sexcoin was forked from. Sexcoin was never updated with really any features from bitcoin after the fork.... as far as I can tell.

That is one major goal with sexcoin-ng, it is a true "github fork" that you can easily compare and create pull requests via web interface.
We can rebase/merge and keep in sync with bitcoin or at least only slightly behind it.

I'm waiting to rebase what I have now in https://github.com/sxcer/sexcoin-ng until i finish a sexcoin-ng-qt branch(where i'm modding the qt client) and get it merged into master.

Another thing where SXC works differently than other Bitcoin-based altcoins is maxconnections command. With other wallets, maxoutboundconnections is hard-coded to
8 which means if maxconnections=8 and there are 8 outgoing connections established since wallet startup then it will not attempt to make any more nor it will accept
any incoming connections. If maxconnections=16 and there are already 8 outgoing connections then wallet will just accept up to 8 more incoming connections, it will not
attempt to connect to any more nodes. But with SXC it is different or it is a syntax error at getpeerinfo (namely "inbound" : false where it should be "inbound" : true),
in the scenario as above SXC wallet will connect to up to 16 nodes. That means up to 16 outgoing connections which leaves no room for any incoming connections.
I don't know the exact reasons for Bitcoin developers picking just 8 outgoing connections as maximum but it all seems to be working just fine (excluding the fact that
network which does not reconfigures itself frequently and constantly is an easy target for traffic analysis, see my previous post).

It would be great if user could specify any configuration via .conf file, for example:

maxconnections=16
maxoutboundconnections=4

or alternatively

maxconnections=16
maxinboundconnections=12

but neither maxoutboundconnections nor maxinboundconnections commands are available. Nonetheless, SXC should stop attempting to connect to more nodes once it
already established 8 outgoing connections.

it takes care of it and gives you a glimpse of how things could be.... until it fills back up with other coins peers that it learns from a node it connects to.

if we could get every node to delete peers.dat at the same instant, it would last longer, or forever.

This is where we may be able to improve the situation if we deprecate old versions.. and maybe in conjunction don't load addresses from some "less old" versions.

I'm running .9 with only the single new magic num in it, peers.dat fills up same as always.

The problem as I understand it is that peer addresses are exchanged pretty much at the begining of any new connection. If you delete peers.dat, you have now made all subsequent connections "new" since there is no history of last contact with any address. so your client seeds from IRC or dnsseed addnode= etc and rx's a peer list from each new connection. So unless each of those connections has deleted his peers.dat and started fresh, one or all of them has 50K peers with most bogus.... and you will accept them from him as you always have.

Its safe to delete your peers.dat.
Shut down your client, delete peers.dat, restart and let it rebuild.
That should take care of almost ALL of the old garbage.
You may be surprised how much better it runs.

I don't fully understand the logic or algorithm for selecting nodes to connect to, so I can't say much for sure.
Except, the nodes do try other ips randomly, and keep track of recently tried ones. As I understand it, once they have not been seen in some minimum interval, they are in the pool of "can be chosen to reconnect to".

the biggest problem we have and had was that the pool contains tens of thousands of nodes that DO reply with valid messages and message responses. At least up to a point. That was the purpose of blockheight limits, proto version limits, etc that were coded in, to try and reject nodes that were replying, but were not sexcoin nodes.

I dont disagree with your logic, but what we have a is a situation where the peer logic as coded is straight from bitcoin, we did not create the process by which nodes are retried, archived, graded etc. and I'm not inclined to alter that logic that works for bitcoin considering we haven't finished migrating to a single sxc-only magic.

It seems that with the new dedicated sxc-only magic we have greatly improved the situation and now what remains may very well be due to sxc client specific issue(s)... namely that peers.dat is 99% full of non-sxc nodes and keeps getting propagated from node to node on every connect, plus current clients accepting both magics which means they can still connect to non-sxc nodes enough to exchange peers with them

I, or we, need to read through the magic handing code and almost for sure create a client that does NOT accept old magic and infact has no knowledge of old magic etc. This may require either a conversion process for any preexisinting blockfiles on the client or a redownoad of the blockchain.


Anyway, the goal is to elminate all your concerns, which are shared by the devs, but we just havne't gotten it done.

Why bother with retrying the same connection when there are thousands other IPs available? For example, most Torrent P2P clients try just once and drop IP after 15
seconds or so of no reply. They will not attempt connection to already "pinged" IP again unless IP pool is used up and at that point they'll start all over again, randomly.

Perfect scenario would be to intentionaly drop some percentage of connections at random intervals, it would help against traffic analysis and strengthen the network.
Having all nodes "permanently" connected to other nodes makes it easy to monitor the traffic and create a list of transaction senders, all it takes is nodes at few key
locations within network. But if all user nodes drop some percentage of connections after every transaction sent or relayed then it is much harder to analyse traffic.

Or just give us a way to manualy "kill" connections, right now there is no such feature within SXC or other crypto wallets (addnode IP remove is not working properly).

like Nerull said, .9 will fix the coincontrol issue and the peers.dat reconnect issue should be improved.

The peers issue is actually alot more complicated due to using the same magic as litecoin. Our magic changed at block 680K. 6.4.6  (and back at least as far as 6.4.4) work with either magic basically.

Before the .9 release we are going to look into deprecating the old magic. We are 100% sure it can be done, we just haven't worked the exact process by which to deprecate it. The blockfiles contain the old magic written between blocks..... except if we redownload the blockchain.. it may be written with the new magic? I'm not sure and need to look into it.

.9 uses leveldb for block database and a new directory structure for blockfiles on disk, so it's a perfect chance to let .9 be "new magic" only and ensure blockfiles are written with only the new magic.

I think it's going to be pretty easy now that all clients on the network are using the new magic.... but we just need to step through the process and get the new client out. The key is that .9 will want to rewrite the blockfiles and blockdb, so we want to make sure we take advantage of that to deprecate the old magic entirely or at least as much as we can in .9 first release.

Of course coincontrol is in bitcoin .9.x so it will just "be there" for us.


I have noticed with the new magic enabled in the sexcoin-seeder app, that i had no need for filtering peers by port# (9560) to get rid of other coins... like I did when I first ported sexcoin-seeder (and it used the old magic). In that case the peers list included all ips that responded. They were tracked as "bad" and ultimately retried, eventually. I found that to truly ignore them I had to drop them from the peers db if their listening port didn't match 9560.

But, like i said, now that the magic changed I was able to update the magic in sexcoin-seeder and remove the code which filtered on listening port.
 
What we dont' fully understand is how long, or if ever, the non sxc peers will take to drop out of peers.dat. Clients which connect, exchange their known peers so the list sortof keeps propagating around containing non-sxc nodes.

In theory I think they will eventually be dropped out, but i am not familiar enough with the peers.dat logic in *coin.

When the clients exchange peers, the problem I found with sexcoin-seeder is that there was 50K or more litecoin or non-sexcoin nodes and less than 100 sexcoin nodes..... so as the local client chose a peer from db to retry every minute or two, odds are it would chose a non-sxc node.... which used the same magic, allowing an initial connection to succeed which caused the list of bad peers to be exchanged again, since one of the first things on connect was to exchange peers. (in fact like the only thing sexcoin-seeder did)

Another thing to point out about what we can do on the client end, is to update the version strings or values and reject older versions.. since 6.4.4 we've had at least 2 hardforks i think and no updates to the protocol version field or rejection logic. It may be that we introduce something there to help filter out these old nodes that are not on the current fork, but yet they have "new magic" code which allows them to look like they are current... sortof , until blockheight or blocks are exchanged.. which ithink may be or may sometimes be after peers are exchanged.


Overall, we want to incorporate all the above fix(es) and deprecation logic possible into the next release since at least every release I was involved in was a rush job that was needed ASAP with no time to really think about anything... even updating the dns seeding addresses or hardcoded nodes etc.

.9 and .6.4.7 (maybe we'll call it .6.5) are hopefully going to take advantage of all improvements and deprecate all old stuff that we can.

I believe that will be fixed when the .9 wallet comes out

I have observed a strange behaviour of newest SXC client v0.6.4.6 and also older versions. I'm using blacklist to ban nodes which are not on v0.6.4.6 and by
looking at log-file there it becomes obvious SXC client just don't want to give up attempting to connect to some nodes. It makes no sense to keep on trying
when peers.dat file is almost 900 kB big, there must be a ton of IP addresses inside yet SXC client stubornly sticks to a dozen or so. In effect, my SXC node is
connected to less than 8 other nodes even after being online for few hours. Any other cryptocoin client (have 15 of them) connects to 8 other nodes in few
minutes, especially clients with 500 kB or bigger peers.dat file.

Blacklisted SXC nodes:

SEX:23.94.28.23-23.94.28.23
SEX:24.42.16.97-24.42.16.97
SEX:78.30.139.91-78.30.139.91
SEX:118.208.94.238-118.208.94.238
SEX:119.194.155.229-119.194.155.229
SEX:184.172.109.21-184.172.109.21



Also, Coin Control would be a nice addition to client.

SlugMonkey Pool
Running new client 0.6.4.1
PROP 1% Mining Fee
http://sex.slugmonkeypool.net/

http://www.sexcoinforum.org/index.php or #sxcoin #sxcdev on freenode i where most of the talk about the current state  of affairs are.

Atm sxcer is busy working on the bitcoin .9 port (from the last page on here) and there are a few other various projects going on around the place. So if you have questions after having a browse over there im sure one of the devs or someone more knowledgeable then I could answer your questions.

There is ofc the Tiffany snow contest going on, everyone should enter!

Are there any news about this coin?

Is there a plan talking about future development of this coin?

We will add SexCoin to LitePaid tomorrow!

Buy Sexcoin!!

https://www.litebit.eu

DAMN!

As always with new services, be cautious

Hey everyone! For those of you who want to enter tiffany snow and the contest check out https://www.litebit.eu/coin/sxc/en/ to buy some sxc DIRECTLY for fiat currency!

Remember that its either 1 hour in her.. I mean in person with her or 90 mins of webcam time! You cant go wrong at have a go at those prices!

Good work everyone on getting us listed on coinwarz!

Respect.

http://www.coinwarz.com/voting

Sexcoin voted to nr.1 of coins to be added soon.

Not bad, good community.

Tiffany is about to offer some more sexy services that I think many people will like. Keep an eye out here and www.sxcladies.com for updates towards the end of the week