http://i61.tinypic.com/23kc239.jpg
That'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.


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'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...

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.

Ditto that. I've been buying the odd SLM here and there when the price is low, mainly because it's a really interesting concept and I hope to see it grow. And if it does grow, then the price will (hopefully?) go up... so kind of like investing in a start-up company in the hope that it will become popular. (And, of course, I need actual coins to burn in order to try out PoB.)

Heh, I'm not sure I know exactly how it works just yet, but the source code is right there, and there's a lot of information back in this thread if you have the time to read through it (look for posts from 'slimcoin', the original dev). The principle is not that complicated -- burn coins to 'buy' virtual burn-mining 'hardware', and then keep your client running to mint coins -- but how that interacts with Proof of Work and Proof of Stake seems to have caused some issues in the past.


Even in the absence of a main dev right now, I'm confident the network's stable enough to keep running as long as there are people who still want to run it.

That's good to hear. Did you pull my whole github fork, or just make the change I gave to a123's version?

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.)


Yes, it was changed so by default it has a 'reserve balance' of like 10,000,000 or something, so it won't stake coins unless you have more than that. But PoS blocks are still accepted, and you can still re-enable staking in the debug console (by setting 'reservebalance false'), which I've done and haven't seen any problems so far. If I have time, I should go back and look over the old posts to try and figure out what exactly the problem was... (or someone else could if they're feeling bored!)

Same here; I've manually re-enabled staking when I run slimcoin and haven't had any major problems. (There is the fact that it crashes every so often, but it does that regardless of whether staking is enabled.)


-----
@d5000, I've pulled a123's latest changes to my own fork and got it to compile with one change:
Without that change, my build failed with an error along the lines of "type conversion is ambiguous".

I've got my fork compiling for both linux and win32, using Gitian with the descriptor files located in slimcoin/contrib/gitian-descriptors/*. (Though I've made a lot of changes to them to get it working; I don't think it was being used for quite a while in Slimcoin, and maybe Peercoin too.)

If a123 shows up, I'll send him a pull request to integrate it all back into his copy (as long as someone can check it builds ok for them too!).

I agree; whether on not PoS is kept will I think mainly determine which one we end up following.

I can't help you with that currently, as my build is based on an earlier (21 Oct) fork -- but I'll try merging in the changes and see what happens. I've currently got a successful build working for Windows; I still need to see if it will build for Linux too (and fix it when it doesn't....)

Btw, can you give details on the errors when you tried to compile? There seemed to be a couple of changes along with the new passphrase function, so it would help to know which bit is likely at fault.


I also would like to keep the 3-way generation if possible, but I need to make sure I understand what the issue with PoS was first. If I've got it right, the problem was that stake transactions would end up creating a whole bunch of small credits, and then each one of those would be a candidate for future staking which led to too much processing (searching a huge stack of transactions constantly). If that's the case, then I'll need to understand better how staking actually works to know whether it's fixable or not.

I'm not at all familiar with Peercoin, but I can't help thinking -- did they have this problem? Did they solve it? 

Yay. 
I would say that a123 was doing a good job as developer before the end of the year came around -- perhaps he'll show up again as the new year starts rolling. Here's hoping...

I've been thinking about this while trying to get the build working, and I wholeheartedly agree -- it would be ideal if we can rebase our code off either the latest bitcoin, or peercoin if they're reasonably up-to-date with bitcoin-core. Perhaps I can look at how much work that will be, once I get the current version building...

Hi all. I am now back from my Christmas break and back to attempting to get a build environment working for Slimcoin. I'm by no means a candidate for a 'main dev' (nor am I really a publicity person either!), but I'm hoping that if a123 or another dev picks up the project again, I can contribute testing and bug/feature patches.

In particular, I want to implement the 'coin control' options that are in the current Bitcoin Core, as I like to be able to select old transactions and merge them into a new single, larger one. (I'm OCD like that  ) Plus, I'm still getting occasional random crashes with 'St9badalloc' in the windows GUI client, which I want to debug.


Still haven't completed a successful build yet, but I'm getting closer -- all the dependencies build except for qt-win32, which I'm in the middle of recompiling right now to see if it works this time...

Well, for what it's worth, I'm hoping to work on implementing the 'coin control' features from the current bitcoin core into slimcoin as time permits. Don't expect it in a hurry, though, as I'm still wrestling with getting my build environment to work properly.

I don't know anything about what a123 is working on.

Well, it sounds around the right size. With the standard GUI client, I get around ~ 0.5khash/sec per core on a 3GHz core2.



PS - so my slimcoin-qt has been stable for the last few days; and I haven't been using that computer a lot over that time. Coincidence?    guess I'll find out over the weekend, since I'll be using it more again.

Yes, I just downloaded it again and confirmed that the files are identical, so that's the version I've been running.
I've got 8GB of RAM, but also a number of other things running at the same time, so memory could be the issue. In particular I have noticed a couple of times it crashed right at the moment I launched another program (in one case a VM, in the other, Minecraft).

I might try a few more experiments along this line and see what happens...

So, I have had the slimcoin windows QT client crashing again. The specific error is:


Immediately before this, there were a very large number of messages of "likely old client, incrementing misbehaviour count", and quite a few "connection timeout" messages. I'm not sure if this is normal or not.

Let me know if you have any suggestions I can try to troubleshoot further.

Just a quick post to note my success with the new R-Box:

I was able to get it working with BFGMiner easily enough, but wouldn't get more than around 85-90 GH/s, no matter how I tweaked the clock settings.

Switching to CGMiner, I am getting around 110-120GH/s at a clock of 330.

So I would have to recommend using CGMiner for the R-Box.

(BFGminer gives nice per-chip stats, though. )

Yeah, I've been solo mining and the reward is <10SLM total per block, compared to 12-14 per burn block at the moment. And burn blocks don't tie up my CPU... plus I get stacks more of them (around 10x more at the moment).

This has got me thinking that Slimcoin is going the right way with discouraging PoW-mining already, though still that a different algorithm might be better than dcrypt.

.... aaaand, still good. Well, now I'm confused, but happy enough.

Still running without a crash so far, I'll let it go a while longer and see... maybe it was just random.

I would prefer keeping the PoW, whatever algorithm we end up deciding, because having PoW protects against 51%-of-burned-coins attacks (at least of some types, such as censorship attempts). However, PoW should be tweaked to make it become unprofitable quickly, because one of the main points of Slimcoin is to discourage power-hungry PoW mining. (This would probably then reduce the incentive to develop GPU / ASIC miners because of the limited profits, but no doubt they would still be built eventually. Just thinking about the risk of 'secret' GPU algorithm, if it has a big advantage, possibly leading to 51% attacks? I would support going to a different well-established CPU-based algorithm given how easily dcrypt seems to be optimised. Of course, then there's still the botnet risk...  )



Can't find them in the log any more, so I'm just firing it up again now, and we'll see what happens. It seemed to be the same or similar crash message as the older version was giving before you fixed it, though.

+1, I think the idea of using dcrypt is to discourage intensive mining, partly since the point of Slimcoin is to require less 'wasted' power in mining by encouraging proof-of-burn to be more significant than proof-of-work. I would favor an algorithm that's going to be hard to accelerate, for that reason.

(PS -- I downloaded the 0.3.2.1 Windows build from the Git releases, and it was crashing again like the old wallet did. I've had to go back to 0.3.2.0 for the time being. )

I think PoB will help with some kinds of 51% attack. For starters, it will mitigate >50% censorship attempts as long as a reasonable amount of PoB'ers are honest. Although the attacker with >50% hashrate can plausibly create a longer chain of PoW blocks and exclude disapproved transactions from them, honest PoB clients will continue to mine burn blocks which include those transactions, so unless the attacker has much greater than 50% hashrate, he will not be able to create a chain that is longer than the sum of ( honest PoW miners difficulty + honest PoB miners difficulty ), which would be required for a successful censorship attack.

In the same way, an attacker with 51% could create a fork from an earlier block to attempt a double-spend, but would require a large proportion of the burnt coins in the network in addition to hashpower in order to get the fork accepted -- otherwise the length of the combined honest ( < 50% hashrate + >> 50% burn ) would always result in a longer (higher-difficulty) chain compared to the dishonest ( > 50% hashrate + << 50% burn ) chain, especially considering the fraudulent chain is starting at some earlier point and has to 'catch up' to the legitimate chain first before it can exceed it.

Finally, regarding the "nothing at stake" problem -- yes, as far as I can tell there's nothing to stop users from collecting PoB blocks on both chains, although this would usually require a deliberate effort to make this happen (since, if they have only a single wallet running, it will fork into one or other of the chains, and not mint PoB on the other one). I can't immediately think of an elegant solution that would discourage this...

Yay, it worked.

I still have an OCD compulsion to go back in and tidy it up to use a function on the transaction class, instead of a boolean flag passed to the transaction-parsing function.  I might try doing that once I have the build environment set up...


P.S.
Mr T, eh? I like that.

I believe I've managed to chase down the bug causing transactions to show up as "Mint by burn" when they actually weren't.

The code that did up the transaction list checked whether the transaction was in a PoB block, but forgot to check whether it was the coinbase transaction, with the result that all transactions in PoB blocks would show up as "Mint by burn". I'm not quite sure why the incorrect amount appeared in the list -- but try my patch and see if it fixes the GUI bug. (Or if you don't have a gui environment to test it on, I can do it if you compile an updated windows client. Haven't got a build environment of my own yet...)

(BTW, it looks like even the check for PoB block is kind of hacky -- the check for PoS blocks calls a wtx.IsCoinStake() function, but the check for PoB is implemented as a boolean flag passed in to the function by the caller... kind of ugly...)

Thanks a123, I just got into Slimcoin after reading about PoB 'mining' and being fascinated by the concept. So glad to see the coin being resurrected now. And your updated wallet seems to use so much less CPU -- previously I had two generate threads maxing out my CPU (quad-core), whereas now they only take it to about 80-85%. (Including other things running besides slimcoin.)

One thing though, it seems the version number in the 'about slimcoin-qt' still displays 0.3.2.0?

Finally: I have some dev experience, and am happy to help out with a bit of testing / debugging if anything comes up, though I can't promise to have a lot of time for it. But so far you seem to be on top of things anyway.

If this continues to go well, when I have some time I might try to look at building a wallet that can run in the background in a FreeNAS server jail, since I've got one of those running anyway...


Edit: So clearly the GUI 'fake mint-by-burn' bug hasn't been fixed so far. I just requested 0.01slm from multifaucet, and it appeared in my transaction tab as a +193slm mint-by-burn. (However the correct details show when I double-click it for details or do listtransactions.)