gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
February 08, 2015, 03:30:59 AM |
|
I can confirm that the vanilla wallet compiles without problems on Ubuntu 14.04 at least.
I think we can do better than that ... I've configured Travis CI to track changes to https://github.com/gjhiggins/SLIMCoin. The continuous integration script clones and compiles the coin afresh, each time the code repository receives a commit or a push. Currently, the vanilla “slimcoin” branch Qt and CLI apps are both compiling successfully: https://travis-ci.org/gjhiggins/SLIMCoin(I've got plans to extend the CI coverage to include executing the (rather limited) test suite.) Cheers Graham
|
|
|
|
Mr E
Newbie
Offline
Activity: 21
Merit: 0
|
|
February 08, 2015, 04:37:13 AM |
|
I've been doing some integration work on the quiet. I intended to do more testing before announcing the results of my efforts but contemporaneity trumps caution. I've been hacking around with the PPCoin git repos and (with a bit of judicious conflict resolution) have been able to retrofit SLIMCoin as a branch , thereby recruiting the full PPCoin commit history as the base for “John Smith’s” SLM initial commit and subsequent commit history. I was able to merge all the way up to the latest commit of the standard PPCoin master (not the more extensive “develop” branch tho' which is a shame because it integrates the 0.8.6 codebase, leveldb, coincontrol and all). I've also integrated all the contributions from the recent changes in the three extant forks https://github.com/gjhiggins/SLIMCoin http://i61.tinypic.com/23kc239.jpgThat's awesome. It's pretty much what I wanted to do next, except am not expert enough with Git to do properly. When I get a chance, I'll check it out and see if I can build it, then test it for a while. A forum would be good but I bet most people would look here first for any important updates.
Obviously this thread would continue to be an important communication channel. But a forum enables to coordinate development, marketing etc. much better. I remember the experience of Peercoin: Before they got a forum (Peercointalk) it was more-or-less a one-man project. When the forum opened, soon there emerged discussions about future developments and a marketing team was formed, which drove attention to the coin and made it a top-5 coin for most of 2013 and 2014. Indeed, this thread is rather awkward for discussing more than one topic at a time; a separate forum would be nice if things start happening faster. I have currently syncing problems at block 228116. Somebody knows what to do? The last block seems to be on the main chain, at least it has the same block hash as 228116 on the bchain.info block explorer. Have redownloaded blockchain from an earlier snapshot three times now, without luck. Looking at debug.log I see a "Check proof-of-burn error", probably caused by an orphan block. I'm not sure. I'm at block 235487 with no errors right now. I could try to zip up my copy of the blockchain for you, if anyone knows whether that will work? Another option is you could try starting from an old snapshot again with a limited peer list of nodes you know have the good blockchain... I'm not sure the cause of this, but if it's a problem with handling orphan blocks then that's not good. Can't have users getting stuck on random points of the blockchain... I seem to have gotten rid of the slimcoin-qt crashes by compiling a version which is more aggressive at banning 'old version' clients (ones that keep spamming getblocks requests). This suggests that the crash is due to dealing with large numbers of requests in close proximity or something similar - which would be consistent with what I've seen where the memory usage suddenly spikes upwards before a crash. I'm just not sure about pushing that pach out widely, since I don't know what the chances are of it banning a legitimate node by accident. I am still showing 27 active connections, though, which suggests it hasn't banned everyone (yet?).
I don't know if slimcoin on linux has the same problem; as far as I know, I'm the only one reporting issues with this and I'm mainly running the Windows client. (I should try running a linux one too and see how it goes.) I'm running the linux version (without gui) and I get the errors and crashes only when I run it with too low memory / swap space (512 MB seems to be too low, for example). But here I can't help you because I'm not so much of a techie ... Interesting, it's possible that it could be a memory-related crash that is triggered by the large quantity of requests, or something. At any rate, my slimcoin has been running stable for the last week or so and I haven't dropped any more nodes (currently at 28 connections), so I'm cautiously ok with the change for now.
|
|
|
|
3429z781678124
Newbie
Offline
Activity: 11
Merit: 0
|
|
February 08, 2015, 07:28:04 AM |
|
I can confirm that the vanilla wallet compiles without problems on Ubuntu 14.04 at least. Yes!!! Thank you very much. I'm happy. I can confirm that the wallet compiles and works without problems on Lubuntu 14.04 ARM. But only on a existing data directory. By trying a clean install from scratch I got a error by loading "blkindex.dat" - Genesis Block not accepted.
|
|
|
|
gjhiggins
Legendary
Offline
Activity: 2254
Merit: 1290
|
|
February 08, 2015, 08:55:45 AM |
|
By trying a clean install from scratch I got a error by loading "blkindex.dat" - Genesis Block not accepted.
Thanks for the report. I've added this as an issue: https://github.com/gjhiggins/SLIMCoin/issues/1, so's I don't forget. Cheers Graham
|
|
|
|
d5000
Legendary
Offline
Activity: 4074
Merit: 7392
Decentralization Maximalist
|
|
February 08, 2015, 11:11:15 AM Last edit: February 08, 2015, 12:50:22 PM by d5000 |
|
I'm not sure. I'm at block 235487 with no errors right now. I could try to zip up my copy of the blockchain for you, if anyone knows whether that will work? Another option is you could try starting from an old snapshot again with a limited peer list of nodes you know have the good blockchain... If you could upload a blockchain snapshot that would be awesome (I have already used snapshots, it works, needed files are, if I remember right, addr.dat, blk0001.dat, blkindex.dat and the database folder). Obviously even better would be if we manage to really solve the issue. I have already tried going back to block 205xxx (the last snapshot I have) and start slimcoin connecting only to the block explorer with -listen=0. Will try out BitcoinFX's new node now. What I don't have done still is revising the peer list in slimcoin.conf for bad nodes, will do this too and then tell you if I had success. I'm not sure the cause of this, but if it's a problem with handling orphan blocks then that's not good. Can't have users getting stuck on random points of the blockchain... Agree, the client is WAY more stable now that some months ago, but this bug is really annoying.
|
|
|
|
BitcoinFX
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
|
February 08, 2015, 01:33:31 PM |
|
... I have already tried going back to block 205xxx (the last snapshot I have) and start slimcoin connecting only to the block explorer with -listen=0. Will try out BitcoinFX's new node now. What I don't have done still is revising the peer list in slimcoin.conf for bad nodes, will do this too and then tell you if I had success. I'm not sure the cause of this, but if it's a problem with handling orphan blocks then that's not good. Can't have users getting stuck on random points of the blockchain... Agree, the client is WAY more stable now that some months ago, but this bug is really annoying. Node is running v.0.3.2.1-alpha on win server. I also used the snapshot from slimcoin.club and got fully synced in under 3 hours, without adding / changing any .conf settings. Try syncing with a fresh wallet.dat and then replacing it with your main wallet once synced, if your not already doing that. Anyway this new node seems to be very stable and the provider seems to have a good and fast network upstream. Number of connections is > 20 currently. I will try to compiled and run a new windows version when we know its stable. Cheers!
|
|
|
|
d5000
Legendary
Offline
Activity: 4074
Merit: 7392
Decentralization Maximalist
|
|
February 09, 2015, 03:33:53 AM |
|
Thanks BitcoinFX for your suggestions! Unfortunately, even with a fresh wallet I was unable to sync. I always got stuck at block 228116. Now http://slimcoin.club has uploaded a new snapshot at 236000 that allowed me to sync again. Doesn't this mean that a123 is reading here and is active again? That would be great news!
|
|
|
|
Superxfast
|
|
February 13, 2015, 04:31:05 AM |
|
Dear all
I have 10 servers, can i mine with 10 minerd on 10 servers and only one wallet, how?
Or any pool?
|
|
|
|
|
|
BitcoinFX
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
|
February 13, 2015, 07:04:14 PM |
|
...
Doesn't this mean that a123 is reading here and is active again? That would be great news!
Glad that you got synced with the latest client. Certainly some updates to the slimcoin.club website - so unless their is a 2nd admin. I guess a123 is still active. We could do with fixing the pool and or getting a new one running if possible. Perhaps getting Slimcoin listed on coinmarketcap.com and another exchange will help to facilitate just that. ... It's still remarkable that Slimcoin doesn't have a more active following. Slimcoin is now one of the only ' CPU only' coins potentially worth mining - after Magi.
|
|
|
|
BitcoinFX
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
|
February 13, 2015, 07:12:15 PM |
|
From the OP: "New Block Generation through Proof-of-Burn
Even a Raspberry Pi can competitively mine, fast hardware offers no advantage"- http://www.raspberrypi.org/raspberry-pi-2-on-sale/- Slimcoin - #Futurist !
|
|
|
|
jonnylatte
Member
Offline
Activity: 60
Merit: 10
|
|
February 13, 2015, 09:31:15 PM |
|
I am mostly a peercoiner but slimcoin has gotten my attention because of it being the first proof of burn currency, at first that was a slight curiosity but after trying it out I noticed one thing. Slimcoin has a much better incentive to keep a node online all the time than peercoin, in fact since I burned some coins my node has pretty much stayed up constantly. I dont want to turn it off because I would miss out on collecting (these admittedly almost worthless) tokens. Although I have a peerbox (raspberry pi setup as a peercoin node that you can just download the image for and have a reasonable amount of confidence its secure) I use that as a kind of charity to have a node on the peercoin network but my minting machine almost never comes online: a few days every couple of months. This will change at some point when peercoin adopts a proof of stake model that is more like slimcoin's proof of burn: same block reward for anyone who gets a block but an increased chance of finding one if you have more stake. Anyway, I was thinking of ways to increase adoption of slimcoin, not just to have people buying a few as a speculation but to actually have them burn some and become part of the network. My idea is this: change the protocol so that when you burn coins you can specify the burned coins to be associated with a different address instead of the one you burned from. This would allow me to send someone burned coins but it would not allow for the trading of burned coins. A faucet and reddit tip bot could be setup for people who would like to try minting with slimcoin and you could actually give people a decedent amount without worrying that they would immediately sell for their favorite currency.
|
|
|
|
d5000
Legendary
Offline
Activity: 4074
Merit: 7392
Decentralization Maximalist
|
|
February 14, 2015, 04:13:51 PM |
|
Perhaps it would be useful to tell them in the "more information" section that the "Total Coins" value on slimcoin.club is the value of the "usable supply" (total coins minus total burnt coins minus burnt transaction fees), not the total coins generated. So they can be sure that this number is effectively what they need to calculate the market cap. Also, the value of "Burned Coins" on slimcoin.club is a bit unclear: The value displayed there is nEffectiveBurnCoins (all coins "effectively" participating in the proof-of-burn process (not counting "decayed" coins)) and not the total burned coins. Total burnt coins - the balance of SfSLMCoinMainNetworkBurnAddr1DeTK5 - are actually about 611.000, plus the burnt transaction fees. (@a123, if you are reading here: It would be cool to change the title of the parameter to "Effective Burned Coins". Perhaps you could add "Total Burned Coins" too. Thanks!)
|
|
|
|
BitcoinFX
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
|
February 14, 2015, 04:59:50 PM |
|
Perhaps it would be useful to tell them in the "more information" section that the "Total Coins" value on slimcoin.club is the value of the "usable supply" (total coins minus total burnt coins minus burnt transaction fees), not the total coins generated. So they can be sure that this number is effectively what they need to calculate the market cap. Also, the value of "Burned Coins" on slimcoin.club is a bit unclear: The value displayed there is nEffectiveBurnCoins (all coins "effectively" participating in the proof-of-burn process (not counting "decayed" coins)) and not the total burned coins. Total burnt coins - the balance of SfSLMCoinMainNetworkBurnAddr1DeTK5 - are actually about 611.000, plus the burnt transaction fees. (@a123, if you are reading here: It would be cool to change the title of the parameter to "Effective Burned Coins". Perhaps you could add "Total Burned Coins" too. Thanks!) All correct. This was simply the only available 'real time' stats. link for Slimcoin that I'm currently aware of. Have submitted it anyway.
|
|
|
|
d5000
Legendary
Offline
Activity: 4074
Merit: 7392
Decentralization Maximalist
|
|
February 14, 2015, 07:24:39 PM Last edit: February 14, 2015, 08:05:53 PM by d5000 |
|
Good! Being listed on Coinmarketcap surely should attract new users, as CMC has developed into the "rating agency" of the altcoin world. Well, market cap still is tiny (about 12.000 USD) but bids are slowly growing. It certainly could attract purely speculative capital too, but this is not too bad as so BTER would be able to collect some fees from trading. And maybe other exchanges considering to add it. (Regarding pools, unfortunately I have no technical knowledge about that.) I am mostly a peercoiner but slimcoin has gotten my attention because of it being the first proof of burn currency, at first that was a slight curiosity but after trying it out I noticed one thing. Slimcoin has a much better incentive to keep a node online all the time than peercoin, That's true - I come from Peercoin too, but this is an advantage of Proof of Burn. The problem is if you apply this model to Proof of stake, it would be a "rich getting richer" game, as large holders probably will get much more rewards than today. In Slimcoin's Proof-of-burn, not the rich but the people which take most risk are being rewarded, so the reward structure is good in the way it was implemented. (ot: That's why I would oppose this change in Peercoin, although I admit that I will have to recheck the math of this reward structure. What can be done there is to encourage the users to send higher transaction fees (e.g. changing the "burned fee" from 0.01 to 0.008 and encourage the users to complete the 0.01 fee via the standard value of the client, so 0.002 would be sent to the minter).)Anyway, I was thinking of ways to increase adoption of slimcoin, not just to have people buying a few as a speculation but to actually have them burn some and become part of the network. My idea is this: change the protocol so that when you burn coins you can specify the burned coins to be associated with a different address instead of the one you burned from. This would allow me to send someone burned coins but it would not allow for the trading of burned coins. That's a very good idea ... burnt tips! I have no idea though if this is technically feasible. From my layman's point of view there should be a way to do this, but it would need a new transaction type, I guess. ( it should have to automatically transfer from address a (donator) -> address b (beneficiary) -> burn address, without the donator having to know the beneficiary's private key)
|
|
|
|
rfcdejong
|
|
February 14, 2015, 09:57:09 PM |
|
Nice volume today, nearly 0.4 BTC being bought from the thin sell book, the value can easily triple or quadriple... 0.4 BTC is not much, but it is more than past months
|
|
|
|
jonnylatte
Member
Offline
Activity: 60
Merit: 10
|
|
February 14, 2015, 11:44:58 PM |
|
The problem is if you apply this model to Proof of stake, it would be a "rich getting richer" game, as large holders probably will get much more rewards than today. In Slimcoin's Proof-of-burn, not the rich but the people which take most risk are being rewarded, so the reward structure is good in the way it was implemented.
The way I see it the PoS rewards would be the same (1%pa) if every one mints as the probability of finding a block would be weighted by your stake/coin-age to make it so. The big difference would be that if a large holder stops minting then their blocks would be found by someone else where as in the current model they keep accumulating coinage and so their chances go up and so does their reward. I don't really know the technical details as it is something Sunny King just mentioned he is thinking about and I didnt think much of it until trying out slimcoin. That's a very good idea ... burnt tips! I have no idea though if this is technically feasible. From my layman's point of view there should be a way to do this, but it would need a new transaction type, I guess. ( it should have to automatically transfer from address a (donator) -> address b (beneficiary) -> burn address, without the donator having to know the beneficiary's private key)
I think you could use OP_RETURN to specify the beneficiary's public key hash I don't think anything needs to change for the transaction to happen (other than adding an interface in the clients) but the code that checks to see if a PoB block is valid would need to change to incorporate the change: invalidating PoB blocks that point to burn transactions that have a specified beneficiary but are signed by the sender and considering the ones valid that are signed by the beneficiary as valid. No need for the beneficiary's private key, you would just need their address to get the public key hash. You would also need a way for clients to know they have received burned coins. Its a bit clunky I admit.
|
|
|
|
rfcdejong
|
|
February 15, 2015, 08:10:15 PM |
|
bter got hacked it seems, now there is no exchange for trading SLM for the moment
|
|
|
|
BitcoinFX
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
|
February 15, 2015, 08:14:25 PM |
|
bter got hacked it seems, now there is no exchange for trading SLM for the moment Seems so. Won't help much with getting added to coinmarketcap.com either.
|
|
|
|
|