[SXC][NSFW] Sexcoin - New Android Client Release!

[Timelord2067]

Yeah.. I wasn't going to mention that. As much as I appreciate them listing us, and their support..... wtf?

In the Troll box a few people seem to be having trouble withdrawing BitCoins from YoBit, so it's not just SXC unfortunately.

[1714068404]

1714068404

[1714068404]

1714068404

[1714068404]

1714068404

[1714068404]

1714068404

[sasa9]

I put an image and link on one of my adult sites to advertise the Sexcoin concept.

http://wildnightparties.com/

Those who own adult websites should consider advertising or promoting the coin.

Your site accepts payment Sexcoin ?

[ac0rnsoup]

My "sexcoin's next client" is almost done syncing

Just curious, has anyone been able to get it to compile on Ubuntu 17.04? Have tried with gcc 6.x, 5.x and 4.9 to no avail. I did, however, get it up and running in whonix, of all places. I haven't tried on Xenial yet. I followed both the documentation in the sexcoin repo for dependencies and the litecoin docs - but mostly the litecoin documentation. After it worked in whonix, I tried gcc 4.9 on 17.04. Pretty sure (not 100%) the error had something to do with boost, perhaps 1.6 had some breaking changes? My whonix install had 1.55

If it ends up failing on Xenial, I will open up a ticket at github with specific error and steps I took.

I got the client built on 16.04 by installing the individual packages via apt-get (boost, miniupnp, protobuf, BDB, etc), and using

Code:

./autogen.sh
./configure --with-incompatible-bdb
make

The /depends system won't built boost, at least out of the box. I'm looking into why that is. I suspect it has something to do with gcc 5.x OR c++11. Any help on this would be welcomed.
Haven't tried building the GUI.

Ubu 12.04 and 14.04 have worked like a charm.

Good to know. I think the issue on 17.04 may be different though. For my last attempt, I did the same thing that worked for me in whonix (where I have the GUI compiled as well.) I did a custom install of db 4.8.30 and set the appropriate variables for the compiler to know to use it. There are instructions for this in the litecoin docs directory. Actually there's a bash script you can use but I just followed along. db5 and 4 formats are incompatible and I wanted the ability to restore my wallet to an already built windows client if necessary, as I assume you'll be using a staticly linked db 4.8 for the windows client.

EDIT: this is the litecoin document I am referring to: https://github.com/litecoin-project/litecoin/blob/0.10/doc/build-unix.md
EDIT2: My bad, it seems the same instructions are in the sexcoin repo. I must have accidentally been reading master instead of the correct branch.

[ac0rnsoup]

So I'm trying to use my newly compiled 0.10.4.0 client to send sasa9 the tip I promised a few pages ago.
But when I paste in the address "SE7Yyb3MZvAr1aRyicjev4evnJHHm8rDp" as the destination address, the bar turns red as if it's failing address validation and I can't send. Any ideas? User error? I only have the new client set up and withdrawals from cryptopia last night went fine.

[lavajumper]

So I'm trying to use my newly compiled 0.10.4.0 client to send sasa9 the tip I promised a few pages ago.
But when I paste in the address "SE7Yyb3MZvAr1aRyicjev4evnJHHm8rDp" as the destination address, the bar turns red as if it's failing address validation and I can't send. Any ideas? User error? I only have the new client set up and withdrawals from cryptopia last night went fine.

I'm pretty sure her address is :

SE7Yyb3MZvAr1aRyicjev4evnJHHm8rDpM

Sasa9, can you confirm ( check your signature )

[sasa9]

This is my adress my Wallet installed on the computer
I did not run it for a long time
What happened ?
Last payment on June 27
http://blockexplorer.lavajumper.com/address/SE7Yyb3MZvAr1aRyicjev4evnJHHm8rDpM

[RatCoin]

Wow amazing picture

[CryptoCanary]

...
Last payment on June 27
...

If you are referring to faucet payouts, I see the last entry from that address was made on the 25th. Last paid on the 27th appears as to be expected, since round times have been inconstant as of late.

But, I am happy to inform you, I have made improvements to free-sx.com! You can enter every hour (24 max) now. Payouts will be processed daily and I will aim to do this at or around 0 GMT (8 PM EST) everyday. Payout is currently .069 SXC times # of your entries + bonuses for poll answers (be creative, make me laugh, or (ladies only) paste the URL of a nice pic). I am working on the referral bonuses still, but do expect those to be functional again in the near future also.

Do not be alarmed if you do not see the payout precisely at 0 GMT. I manually initiate the payout script. For many reasons (server, wallet, faucet abuse, taking time away from my desk), this might be delayed sometimes.

Enjoy, free-SX.Com

[ac0rnsoup]

I'm pretty sure her address is :

SE7Yyb3MZvAr1aRyicjev4evnJHHm8rDpM

Sasa9, can you confirm ( check your signature )

Temporary typo in signature. Of course

[lavajumper]

Just curious, has anyone been able to get it to compile on Ubuntu 17.04? Have tried with gcc 6.x, 5.x and 4.9 to no avail. I did, however, get it up and running in whonix, of all places. I haven't tried on Xenial yet. I followed both the documentation in the sexcoin repo for dependencies and the litecoin docs - but mostly the litecoin documentation. After it worked in whonix, I tried gcc 4.9 on 17.04. Pretty sure (not 100%) the error had something to do with boost, perhaps 1.6 had some breaking changes? My whonix install had 1.55

Did you get something like this?

Code:

/usr/include/qt5/QtCore/qglobal.h:1052:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)."
 #  error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\
    ^

Also, yes the official binaries will be against BDB4.8 .

[ac0rnsoup]

Just curious, has anyone been able to get it to compile on Ubuntu 17.04? Have tried with gcc 6.x, 5.x and 4.9 to no avail. I did, however, get it up and running in whonix, of all places. I haven't tried on Xenial yet. I followed both the documentation in the sexcoin repo for dependencies and the litecoin docs - but mostly the litecoin documentation. After it worked in whonix, I tried gcc 4.9 on 17.04. Pretty sure (not 100%) the error had something to do with boost, perhaps 1.6 had some breaking changes? My whonix install had 1.55

Did you get something like this?

Code:

/usr/include/qt5/QtCore/qglobal.h:1052:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)."
 #  error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\
    ^

Also, yes the official binaries will be against BDB4.8 .

Nope. I have next week off to mess around more but I'm happy with the GUI in whonix for now. I'm building a node (no GUI) on Xenial right now, will let you know how it goes. I am doing same as I did on whonix except for installing qt4 dependencies. If I run into compiler problems, I may install the gcc 4.9 packages available in Ubuntu's repos and set CC and CXX to use older version. I believe whonix has 4.9

When I configured DB4 on whonix, I did

Code:

../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX

and when I did sexcoin I did something like

Code:

./configure LDFLAGS="-L${BDB_PREFIX}/lib/" CPPFLAGS="-I${BDB_PREFIX}/include/" --disable-shared --with-pic

Where I set DBD_PREFIX to the location I installed db4.

On a side note, I stupidly set my age when I tried to send a transaction and it's been a while and still no confirmations. As I understand it, any miner running the older software will reject this transaction. Are there nodes I can hardcode to get this to go through or should I just leave it? I only have one peer running 0.6.x

EDIT: Sexcoin (without GUI) built fine on 16.04 with custom DB4 install using the default GCC 5.4. Maybe tomorrow night I can try getting GUI to build.

[ac0rnsoup]

Is there any place where I can see the transactions waiting in the mempool? I didn't see anything about the mempool at the block explorer. Wondering if I should just restore my wallet and resend transaction without the new feature set. I think doing that would invalidate any other transaction hanging around the mempool...think I'm going to try that. Use backup wallet, run sexcoin-qt -rescan, then send transaction with no age feature set.

EDIT: Yup, that did the trick. It's a good thing I know what I'm doing half of the time

[sasa9]

#Sexcoin



Welcome https://vk.com/sexcoin_ru   

Please give me Sexcoin  -   SE7Yyb3MZvAr1aRyicjev4evnJHHm8rDpM

[sasa9]

Who is the owner of this https://twitter.com/Sexcointeam

If you do not work
Give it to me,
  I will work !!!

If you know who owner of this https://twitter.com/Sexcointeam
Please tell him

[sasa9]

to send sasa9

All OK
Many thanks!!
http://blockexplorer.lavajumper.com/address/SE7Yyb3MZvAr1aRyicjev4evnJHHm8rDpM

[Nerull]

Is there any place where I can see the transactions waiting in the mempool? I didn't see anything about the mempool at the block explorer. Wondering if I should just restore my wallet and resend transaction without the new feature set. I think doing that would invalidate any other transaction hanging around the mempool...think I'm going to try that. Use backup wallet, run sexcoin-qt -rescan, then send transaction with no age feature set.

EDIT: Yup, that did the trick. It's a good thing I know what I'm doing half of the time

Lava is looking into a block explorer that allows that, however as you can imagine getting the release out smoothly is his main focus currently

[lavajumper]

Code:

./sexcoin-cli getrawmempool

More soon

Another handy trick,

Code:

./sexcoind -daemon -txindex

[lavajumper]

Very Important Information!!

Repost because these tend to get buried:

The new client is getting ready for release. Here are some of the nitty-gritty caveats and details.

There is the possibility of some pain points during this upgrade:

• Sexcoin has been vulnerable to transaction malleablity. This release addresses that issue. Once miners have updated, old clients will have a possibility (by our calculation about 5%) of creating transactions that will be completely rejected by the network. The way you know this has happened will be evident by this behavior:
  
  An old client sends a transaction which gets broadcast to the network. It is recorded in the wallet as usual, and you see a zero confirm transaction. Because it has been broadcast to the network, the recieving client  also shows an incoming, zero confirmed transaction. So now both the sender and receiver have transactions in their wallets, but with zero confirms. However, miners will reject the transaction and not include it in the blocks they assemble for processing. As time goes on, both wallets retain the record, waiting for it to confirm on the blockchain. This transaction will NEVER make it onto the blockchain. Old clients have marked these coins as 'unspendable' so the coins are tied up in the users wallet. The transaction at the receivers end will show as unconfirmed. This puts both sender and receiver in a unwanted position.
  
  On old wallets, restarting your wallet with the '--rescan' might clear the problem...but not always. The only way I've found to work 100% is to start a new wallet, import the private keys from the old wallet, then let the wallet rebuild with the information from the blockchain.
  
  On new wallets, you can restart the wallet with '--zapwallettxes=1' to clear unconfirmed transactions and free up the coins. This is much easier than having to import private keys, but still takes time.
  
  I have begun work on adapting pywallet to work with sexcoin so we have a tool to deal with this, but will not have it done for quite a while.
  
  IF THIS HAPPENS YOUR COINS HAVE NOT BEEN LOST! They are just inaccessible until your wallet is cleaned up. Its probably a good time to upgrade your wallet
  
  
• Sexcoin has age verification flags in the current transaction version field. The old client rejects any 'transaction version != 1'. ANY age verified transaction, picked up by an OLD miner, will reject the transaction as invalid. See the above scenario. YMMV in this scenario. IF a miner wins a block that is mining with the new client the transaction will be accepted to the blockchain.
  
  The remedy to this is to NOT USE AGE VERIFICATION (Set age verification to 'NONE' ) until a significant amount of miners have switched. This is why we are releasing to miners first.
  
  
• The next Android release will refuse to connect to old nodes. This is the primary reason we are delaying release of the Android client. Once the network has significantly updated, the new Android client will be available.
  

I think when you fully understand the different permutations involved, you can see why the release got delayed for so long. Is it better to get miners first, then users? Is it better to upgrade users first, and pray they don't set age verification? Should we simply release and have everyone explode? Is there some way to code in a solution? This last question is what has taken the longest amount of time. We've attempted code solutions, but at the end of the day, the only effective changes that mitigate lie in changing the code in the old client, which obviously is stupid, if we're releasing a new client.

[sasa9]

#Sexcoin
https://sexcoinforum.com/

[synan]

Hey guys ! So we can't mine this coin with AMD GPU ?