Is there a new wallet out that calculates POS in a different manner than the original wallet. I have noticed that in the past, PPCoin and YACoin would generate a POS by splitting the original coinage into two and adding the new coin amount minted in the POS to the two halves. Lately I have noticed that there is a new type of POS minting that does not split the coinage in half, or into two. Where can I get a wallet like that? It would be great cause it would not split up my coins anymore when POS is generated. Thank you all, Love you YAC!!!!
The wallet also joins coins, not only splits them.  Also, splitting is good when you actually want to USE your coins (so you don't waste much coin-age when you have 100k YAC and want to send just 1 YAC somewhere). |
|
|
|
|
And we have another winner!
YG51oDsMKUyKJK5aAWuJqnEAPt1S4S4L3a just got 3957.93 YAC!
|
|
|
|
EDIT: Right now there's one participant with 99 tickets and a 25 YAC bonus to the winner (total reward 124 YAC!). Don't let him win, get some tickets!
LET M... ehm HIM WIN, U BETTER SELL ALL YOUR COINS ON CRYPTSY INSTEAD. Hehe  Only 45 minutes left and still just one participant. The bonus has also raised to 34.95 YAC! Only 1 day left and still just one participant.The bonus has also raised to 54.95 YAC! I see what you did there  |
|
|
|
EDIT: Right now there's one participant with 99 tickets and a 25 YAC bonus to the winner (total reward 124 YAC!). Don't let him win, get some tickets!
LET M... ehm HIM WIN, U BETTER SELL ALL YOUR COINS ON CRYPTSY INSTEAD. Hehe Only 45 minutes left and still just one participant. The bonus has also raised to 34.95 YAC! |
|
|
|
So, I was kinda bored and made this (hope it will work as intended) http://yacexplorer.tk/raffle.htmlIt's a standard cryptocurrency raffle-style lottery where each stake recieves a number of tickets equal to floor(stake). Each ticket has an equal chance of winning. Those tickets are constructed by concatenating a few strings unique to your stake + the server's secret for a given day and then hashing all that. The winner is determined by the ticket with the lowest hash (more detailed explanation on the raffle page). Simple, huh? There is no cut for the lottery operator (me) - the whole pot is given to the winner. The lottery occurs each day at midnight UTC (server time). Everything is transparent and cryptographically verifiable. The first lottery draw is in 11 hours from now! Hope it will bring some fun into the YAC community.  EDIT: Right now there's one participant with 99 tickets and a 25 YAC bonus to the winner (total reward 124 YAC!). Don't let him win, get some tickets! |
|
|
|
Damn dooglus that is mad, would you mind releasing a zip of his roles?
09:17:09 (1) <dooglus> wokehaha: do you mind if I publish a list of your bets? people want to see how you did it 09:17:27 (239632) <wokehaha> sure no problem about that https://just-dice.com/239632.txt.bz2is that a virus? that file won't open on my computer!  Try 7zip (assuming windows) |
|
|
|
No mention about the free service you used to actually achieve any of this ? Shame.
Good point, thanks! Will correct this ASAP. EDIT: fixed. |
|
|
|
|
Reminder: only 5 days left to next Nfactor change!
|
|
|
|
EDIT: I emailed Cryptsy - YAC trading has been resumed. Nice, thanks! No clue about the OSX version though. Maybe try recompiling (with "make clean" first)? |
|
|
|
Has anyone been able to replicate this issue?
Not me. Is the YACoin with Coin Control still working? I would love to download it and start to use but do not know if this has been stable and developed/tested? Please let me know if there is a link with the latest build. The binary in the OP is the latest I've built. |
|
|
|
Quite easy. Wouldn't that be better to do with CC from one single adress? Sure, but not with CC as it can not be easily automated. The best way I can think of is setting an account for the address you want to send from (in yacoin-qt debug window console for example): setaccount <bitcoinaddress> <account>
Give it some nice account name. Then instead of "sendtoaddress" use "sendfrom" (replace fromaccount by the name of the newly created account): sendfrom <fromaccount> <tobitcoinaddress> <amount>
|
|
|
|
Don't get me bad ideas ...
Actually it does piss me off that people can now buy YACs so much cheaper than I had paid. I wouldn't even have to actually fight many POWs since I ask the miners for a little donation. It would be a shame if something happend to your block. Since I would still kill a lot of blocks there would be far less supply for the exchanges.
In fact I can't stop people from selling cheap at the exchanges, but if I punish all miners for to low prices I can somewhat stabilize the market. I do have the coins, the money to buy significant on the exchanges to prevent a panic and my morals ain't that good either.
On a total different subject, how can I automatically split up a big wallet into a few small ones. Let's say about 10.000 adresses?
Something like: 1) create new wallet.dat 2) generate and save 10000 addresses via RPC command 3) switch to your old wallet.dat 4) send X YAC to each of these 10k addresses you just generated 5)  6) Profit! Some BASH code for step 2: for i in $(seq 1 10000) ; do yacoind getnewaddress >> addresses.txt ; done
And for step 4: for address in $(cat addresses.txt) ; do yacoind sendtoaddress ${address} <AMOUNT> ; done
Replace <AMOUNT> by the amount of YACs you want to send to each address. Quite easy. |
|
|
|
I don't think it's about XPM replacing YAC, but I think there's mainly 2 things that are putting in danger YAC and preventing its raise:
- The sudden, N increases. I don't know if it's possible to 'smoothen' the effects without a hard-fork, but it would be worth considering. The average foe is probably not OK with their hashrate halving overnight and difficulty taking 5-6 days to adjust. Since the N concept probably has to stay this way as it's 'the concept' of the coin, I guess the change should come with difficulty reacting faster after a N change.
Yes, that's impossible without a hard fork. EDIT: However, as YAC has PoS mining, the PoW difficulty/Nfactor changes are not important. PoW should only be used for the initial distribution of coins. PoS will eventually overtake PoW and then invalidate it altogether as PoS blocks have much larger "trust" value assigned to them compared to PoW blocks which have a trust of 1 (just look at NVC). Also, it's quite easy to supress PoW entirely if any large YAC holder wanted to do so - just hold onto your coins and when you see a PoW block on the network, ignore it and quickly make one PoS block linking to the previous block (not the new PoW block). The other peers will happily orphan the PoW block. You will need to make some code changes to your client first, but it's not that difficult and IMHO worth it for the lulz. Just imagine all the YAC pools getting nothing but orphans. Now I hope you see the futility of PoW mining a coin that has PoS. So hashrate/N changes/whatever is not an issue for YAC in the long run (when there are many coins participating in proof of stake). END EDIT. - The lack of development news (not blaming the dev(s), I understand you can't do miracles with few numbers, but it's an issue from outside).
Currently we're trying to improve the client start-up time. Not much success so far (moved to LevelDB), but I've got an idea. (Make a bounty!  ) If these 2 things are tackled I don't see why YAC couldn't become more widespread. If nothing changes, well, I'm afraid we'll all have a good amount of very cheap coins.
They're already quite cheap. Time to buy! |
|
|
|
I'm envisioning the ability for one to input YACoin hashrate (the best and smartest way may mean people will have to start mining at least for a couple minutes to truly know this information), and then reverse calculate for LiteCoin or even input LiteCoin hashrate.
Genius. ^^ This would be the simplest and most accurate method to implement (although it will require users to test their mining speed for both scrypt variants). |
|
|
|
...
Agreed, but we lack a benchmark for a sufficient number of GPUs. I said that the data was highly innacurate, but even if it's half the profitability IRL it's still in the TOP 3 profitable scrypt coins when compared to LTC. EDIT: So far I've implemented getNormalizedDifficulty API call on my block explorer. Now I only need to write getBlockReward and we have all it takes to add YAC on coinchoose.com if they agree. (And possibly tweak some parameters or build a GPU benchmark chart.) |
|
|
|
Well, it's a nice idea and I'm all for it, but there is a slight problem. As the profitability is based (among other things) on hashrate/difficulty comparison, how do we compare scrypt-chacha (or however you want to call it) with plain scrypt or even sha256? As you can see on my graphs page, simply normalizing the YAC hashrate (by "hashrate / (0.5 ** (Nfactor - 9))" based on Nfactor doesn't yield acceptable data:  To be clear, this graph thing *could* be caused by some miners leaving after the Nfactor change, but I doubt there are so many to make such a difference in net hashrate. However, the change has an amplified effect on GPUs as they're getting *less* than half their hashrate after each change. Dunno about CPUs, but even the L3 caches might be already used up on most of them. If we consider this data to be correct for a while, I can compute the profitability compared to LTC. The values we need are: difficulty ratio, price ratio and block reward ratio. Current normalized YAC hashrate is just slightly below 40 Mh/s. This translates to an LTC-compatible difficulty of 0.55, which is ~1802.27 times lower than LTC at the moment. So far so good. Now for the price comparison: LTC is worth 1 LTC a piece (who would have thought...) and YAC 0.0025 (sell price from bter, buy is at 0.0036). So the YAC is worth around 1/400th of LTC. The last thing we need to take into account is the number of coins generated per block. LTC has stable 50 and YAC is currently at 49.69. Dividing YAC by LTC gives us another value: 0.9392. Now multiply these three numbers and we get ~4.23. Multiply by 100 to get a % value: YAC has 423% profitability of LTC. Please, do check my math. How to compute diff: diff = hashrate / 2^32 * 60 Hashrate is in hashes per second (not kh/s or Mh/s!), 2^32 is constant for scrypt and 60 the block interval target. |
|
|
|
|
Show Posts
