How about posting some Adsense stats like views, clicks, upcoming revenue payouts, etc..?
That will be coming in a newsletter! Could you please add a link to the block explorer, a link to the GitHub repository and a direct download link for the wallets to the OP? Makes finding those a lot easier. Thanks! |
|
|
|
You, dear sir, are being lied too.
There are no lies in source code. |
|
|
|
We have come up with a way to prove that we do indeed have ownership of the Twitter accounts without revealing the handles. We will provide proof this coming monday when we release our weekly newsletter.
Great!
Boxxa can't even fix a wallet bug.. it proves that he's not a real dev. scam after scam after scam. They probably lost all the ico funds on OKcoin.
You, dear Sir, are a moron. Check the latest GitHub commits of earlier that day. |
|
|
|
To be honest, real disapointment in this project. To long development cycle for cryptocoin. Devs had to make something prior to ICO, then make announcement. Sadly, sadly!
Btw, I don't want cheap coins and I haven't sold even a single SMAC.
ICO funds are used to acquire revenue basis. So ICO has to come first. I'm wondering if there will be somekind of buyback program? If the coin is getting cheaper and cheaper then it make sense for DEV to use some money. Maybe launch some great news and it jump to the moon. Look at GSM, jump by 800%.
Everything is in the hands of DEV. What will he do with all those BTCs, how long will he allow his coin to drop. Will he not start buying?
First buyback is scheduled for April 27th according to twitter: https://twitter.com/SMACteam/status/575793388127019008?lang=en-gbI like the buyback program, but in altcoin world 27th of April is a long time. On twitter they are talking about accounts that 500k followers etc, but i don't see any prove. It would be nice that they can post some prove of it. Everybody can say, now we bought account worth of .... but where are the proves? If they post proves then i'm pretty sure that this coin will not trade at 8k sats but at 800k sats. Now it is just wording, a screenshot doesn't take too much, no? Lol seriously? This will trade at maybe 800 sat by that time. A month is a year in the alt world, we've seen many coin die much quicker than that. By that time, the amount of coins that would need to be bought to bring price to ipo would be remarkable. Longer the buy backs take = less likely investors will not make back original investment. Nor trying to fud just telling you boys the absolute truth. Hopefully devs realize this or this will turn into another fail coin very very quickly, mark my words. Let's be real about this and not joke to ourselves. To buy back coins with revenues you would need those revenues first, right? If revenues for march get paid out at the end of april then the first buyback will happen then. From there on it should happen on a monthly basis. Regarding PoS fix: I created a merge-pull request with fixing stuff @ GitHub. |
|
|
|
i am not able to download the windows walllet from the website.. help please
The download works. Try a different browser. |
|
|
|
I don't understand the supposed bug enough to know if it harm me or not.
All can I say is since March 10th I receive about a number really close to 1% of interest per day for staking.
The wallet connects sync fast and run it since 11 days with no problem.
So where's the bug?
Short version: If you have more than 253 SMAC in one stake (also happens with less SMAC if the coinage is > min coinage required for staking) you hit a buffer overflow in PoS reward calculation which results in a way too low reward. Since nStakeCombineThreshold is set to 1000, splitting coins into smaller transactions when sending them to your wallet doesn't help - those transactions would be added up when creating stakes due to that threshold. |
|
|
|
Good News! A community member and I are in the works of getting a tri richlist listed at chainz.cryptoid.info  10 TRI to Nightmare and Wurstgelee for efforts on TRIder and Wallet! Cheers! btw for some reason the messages that i send encrypted under tor shows on the receiving end but i cannot see messages. any clue? I have beta 3  Try the following: - close the wallet - make a backup of %appdata%\triangles (just in case - backups are nice to have!) - delete smsg.ini and the folders smsgDB and smsgStore in %appdata%\triangles - start the wallet again Do you see the messages now? Oh, and thanks a lot for the TRI!  hmmm friends public key used to pop up automatically... i'm gonna restart qt ... let you know if i still have issue. Tkz You won't see older messages that way - but new messages will appear. If you want all messages, you would have to fully resync the wallet afterwards. Issuing "smsgscanchain" in the debug console might help but I don't feel like resyncing just to verify that.  |
|
|
|
I wrote some lines with boxxa earlier. The fix is being worked on, expect news soon. |
|
|
|
I'm wondering if there will be somekind of buyback program? If the coin is getting cheaper and cheaper then it make sense for DEV to use some money. Maybe launch some great news and it jump to the moon. Look at GSM, jump by 800%.
Everything is in the hands of DEV. What will he do with all those BTCs, how long will he allow his coin to drop. Will he not start buying?
First buyback is scheduled for April 27th according to twitter: https://twitter.com/SMACteam/status/575793388127019008?lang=en-gb |
|
|
|
Wurst, you should create a feature header and put "Able to stake without creating more than a certain number of inputs" or something along those lines in the ANN. It's very useful and keeps the wallet snappy without maintenance. Maybe add, "This allows you to stake as much as you want without your wallet getting bogged down by thousands of inputs and crashing when trying to send large transactions, a problem that plagues many other wallets." I'm not even sure if another coin has that feature, although I haven't checked up on many recently.
Also, put "encrypted messaging over TOR in wallet" or something as well under the same header.
Well, it was a problem of variables which prevented stakes from being combined. This is supposed to work for all PoS coins if they have reasonable values set - so thats not really a feature. Secure messaging is mentioned @ "Specs" - isn't it? |
|
|
|
Good News! A community member and I are in the works of getting a tri richlist listed at chainz.cryptoid.info 10 TRI to Nightmare and Wurstgelee for efforts on TRIder and Wallet! Cheers! btw for some reason the messages that i send encrypted under tor shows on the receiving end but i cannot see messages. any clue? I have beta 3 Try the following: - close the wallet - make a backup of %appdata%\triangles (just in case - backups are nice to have!) - delete smsg.ini and the folders smsgDB and smsgStore in %appdata%\triangles - start the wallet again Do you see the messages now? Oh, and thanks a lot for the TRI! |
|
|
|
good morning friends.. just got TRI added to https://chainz.cryptoid.info/tri/#!wallets richlist and distribution = https://chainz.cryptoid.info/tri/#!rich if you can please donate BTC here > 15wUyp6ERKgxhzfBEja2hQkfs9KmAcmUKw and or please donate TRI here > TRikQSFYGgqoeKrVLHT8PV4QgiVAzhyXUf donations will be used to help pay for upkeep of richlist, supernode, and explorer.. thanks all and keep on staking! Holy shit....Awesome! Who pays for that? You? And how much is it? Are those your or fairglu's (the guy who hosts the explorer?) addresses? Edit: Oh, the distribution is better than I expected. |
|
|
|
So anyway, there's a buffer overflow in the Proof of Stake implementation which I've mentioned before but I guess I'm getting ignored. This basically means if you are staking a block of 253 or more coins, you won't receive a full Proof of Stake payout based on 365% interest. Here's some simulation code based on staking 300 coins. #include <stdio.h>
#include <sys/types.h>
int main(void) {
// SMAC
int64_t nDays = 1;
int64_t nCoins = 300;
int64_t CENT = 1000000;
int64_t COIN = 100000000;
int64_t MAX_MINT_PROOF_OF_STAKE = 1 * CENT;
int64_t nRewardCoinYear = 365 * MAX_MINT_PROOF_OF_STAKE; // Month 1 - 365% interest
int64_t nCoinAge = nDays * nCoins * COIN;
int64_t nSubsidy = nCoinAge * nRewardCoinYear / 365 / COIN; // SMAC code
printf("nSubsidy= %lld\n", nSubsidy);
}
So that is a buffer overflow. Result is: nSubsidy = -205390248 Actual result should be: nSubsidy = 300000000 Or 3 SMAC. So if you can find a block which has paid out more than 3 SMAC in Proof of Stake interest during the 365% interest period, you can prove me wrong. Well to be exact, if you can find a PoS payment of more than 2.53 SMAC during the 365% interest period, you can prove me wrong. The worst case scenario is for people staking more. I feel bad for those people as their investment isn't fully paying out. For example with 3000 SMAC, staking for 1 day you should receive 30 SMAC. For 30000 SMAC, staking for 1 day you should receive 300 SMAC.... So yes, 1% per day since minimum stake age is 1 day. Even simpler, only change one line of code: Instead of int64_t nSubsidy = nCoinAge * nRewardCoinYear / 365 / COIN; // SMAC code do int64_t nSubsidy = (nCoinAge/COIN) * (RewardCoinYear / 365); // SMAC code C++ isn't exactly my area of expertise so if someone with that expertise is reading this: Please verify! (I can't imagine why those brackets wouldn't be calculated first though) |
|
|
|
A single PoS block minting 365 coins is rare with our small supply but obviously we will implement the fix. Changes like this submitted with a fix are rewarded from the buy back fund as outlined in the ANN for contributions which is why the code fix is being paid.
Well if that's the policy fair enough. Might be a good idea to allow additional donations to the fund to ensure there is always enough to pay out. I also think it might be useful to reward people separately for pointing out errors and providing fixes. This would encourage full transparency as some errors may take time to be fixed but that should not act as a barrier to them being sought out and reported. +1 Otherwise people might refrain from reporting bugs until they have fixed it on their own - which might take longer than it would take if they reported it at once. |
|
|
|
Thank you for the contribution to this. I don't think we have seen a wallet this bug but will submit the change to our repo and have the wallet updates for this.
This is the great community effort to submit a fix to a seen problem in open source code.
DM me your wallet address for some SMAC.
I appreciate the generous offer but I agree with Soul_eater_123 here: At least 50% should go to Julian for spotting the issue - the fix itself is rather simple. I will DM my address. Thanks! Edit: A single PoS block minting 365 coins is rare with our small supply but obviously we will implement the fix. Changes like this submitted with a fix are rewarded from the buy back fund as outlined in the ANN for contributions which is why the code fix is being paid from my input. Not sure what the SMAC team think and can do as they wish.
Well...no. As soon as you send one transaction with 300 SMAC to your wallet you will create a 300 SMAC stake once these coins mature. |
|
|
|
|
I reconsidered.
OH NOES! ABANDON SHIP! DUMP DUMP DUMP! oO
:p
|
|
|
|
How can there be a buffer overflow? 64 bit integer max val is 9223372036854775807.
Or is there any other function overflowing this stack position? i must writing on the most significant bit hens the negative number.
The result of nCoinAge * nRewardCoinYear for 300 coins is 10950000000000000000 (or higher depending on coinage). Buffer overflow. Easy fix though: #include <stdio.h>
#include <sys/types.h>
int main(void) {
// SMAC
int64_t nDays = 1;
int64_t nCoins = 300;
int64_t CENT = 1000000;
int64_t COIN = 100000000;
int64_t MAX_MINT_PROOF_OF_STAKE = 1 * CENT ;
int64_t nRewardCoinYear = 365 * MAX_MINT_PROOF_OF_STAKE; // Month 1 - 365% interest
int64_t nCoinAge = nDays * nCoins; //MODIFIED CODE
int64_t nSubsidy = nCoinAge * nRewardCoinYear / 365; // SMAC code - MODIFIED CODE
printf("nSubsidy= %lld\n", nSubsidy);
}
Problem solved.
Those it matter? If the same rule applies to everybody then it really doesn't matter at all, less coins, so value is higher. Maybe less staking but more trading, is that bad? Of course not.
Jesus. Of course it fucking matters. Yes, it does. Fixing needed asap. |
|
|
|
I just installed TRIder and am now testing thoroughly. |
|
|
|
Update on TRIder: The application is already in the store. However currently only available for a testing group. This means you can not find it until I publish it to the public. Wurstgelee got now an updated version and if there are no major flaws, I will release it for the community in the coming days.  Note about the amount of needed TRI: If you want to trade on other markets than BTC-TRI you need a specific amount of TRI in your balance. As long as the amount is not reached you have only the possibility to trade on the TRI market until you have the amount. After that you have access to all the markets. The amount is calculated as following: Amount = ceil(<BTC value of open orders> / 0.05 )*0.5 + 4.5 TRI For example you have open orders with a total value of 0.132 BTC You will need (0.132/0.05)*0.5 + 4.5 = 6 TRI So a big trader needs more TRI than a small one. ...
Mar 09 23:12:40.372 [err] tor_assertion_failed_(): Bug: src/tor/memarea.c:127: alloc_chunk: Assertion realign_pointer(res->next_mem) == res->next_mem failed; aborting.
Mar 09 23:12:40.373 [err] Bug: Assertion realign_pointer(res->next_mem) == res->next_mem failed in alloc_chunk at src/tor/memarea.c:127. Stack trace:
...
These are similar errors which I got on my Raspberry Pi. Sadly I did not find the reason for the assertion exception. \o/ \o/ \o/ OMG OMG OMG |
|
|
|
The wallet should compile anyways though - even with current GitHub sources. Which error message do you get?
wb@whalebone:~/triangles$ ./triangles-qtMar 09 23:12:40.372 [err] tor_assertion_failed_(): Bug: src/tor/memarea.c:127: alloc_chunk: Assertion realign_pointer(res->next_mem) == res->next_mem failed; aborting. Mar 09 23:12:40.373 [err] Bug: Assertion realign_pointer(res->next_mem) == res->next_mem failed in alloc_chunk at src/tor/memarea.c:127. Stack trace: Mar 09 23:12:40.373 [err] Bug: ./triangles-qt() [0x815eb08] Mar 09 23:12:40.373 [err] Bug: ./triangles-qt() [0x82538b5] Mar 09 23:12:40.373 [err] Bug: ./triangles-qt() [0x81fd3f4] Mar 09 23:12:40.373 [err] Bug: ./triangles-qt() [0x81fd4fd] Mar 09 23:12:40.373 [err] Bug: ./triangles-qt() [0x824b2c5] Mar 09 23:12:40.373 [err] Bug: ./triangles-qt() [0x821511e] Mar 09 23:12:40.373 [err] Bug: ./triangles-qt() [0x821529a] Mar 09 23:12:40.373 [err] Bug: ./triangles-qt() [0x82157c8] Mar 09 23:12:40.373 [err] Bug: ./triangles-qt() [0x8215905] Mar 09 23:12:40.373 [err] Bug: ./triangles-qt() [0x8192feb] Mar 09 23:12:40.374 [err] Bug: ./triangles-qt() [0x8197fcf] Mar 09 23:12:40.374 [err] Bug: ./triangles-qt() [0x8198325] Mar 09 23:12:40.374 [err] Bug: ./triangles-qt() [0x820ee62] Mar 09 23:12:40.374 [err] Bug: ./triangles-qt() [0x8210019] Mar 09 23:12:40.374 [err] Bug: ./triangles-qt() [0x830ae03] Mar 09 23:12:40.374 [err] Bug: ./triangles-qt() [0x82984f3] Mar 09 23:12:40.374 [err] Bug: /usr/lib/i386-linux-gnu/libboost_thread.so.1.54.0(+0x9681) [0xb71fa681] Mar 09 23:12:40.374 [err] Bug: /lib/i386-linux-gnu/libpthread.so.0(+0x6f70) [0xb62caf70] Mar 09 23:12:40.374 [err] Bug: /lib/i386-linux-gnu/libc.so.6(clone+0x5e) [0xb60b4bee] Aborted (core dumped) Mh.... could you try installing libboost 1.48 and compile it again (or try to compile it)? |
|
|
|
|
Show Posts
