Yes, I am a member now. (Mark Metson aka knotwork.)

Why do you need our coin address here, isn't kind of a lot of the whole point of their site(s) that they make it possible and hopefully even easy/convenient to give people coins and such? Thus shouldn't I be able to tell their site(s) an address and you be able to send me coins through their site without even maybe needing to see or know my address?

Hmm I tried adding TAG and BTC accounts in the tagbank pane, but it just created accounts without asking me for addresses to associate with them.

Hmm. So no place yet it seems for me to tell their system that TAG coins sent to me should be sent to TQPDRtwborernRJBuayobY7h2jNoEWxqML ...

-MarkM-

Okay I did that, I tried to join the community, but so far am not seeign any email verification email. I presumably already verified it to tagbond themselves, is that all you need or does your community also verify it to get me onto their mailing list or something?

-MarkM-

Okay so in the address part or the bio part we put "on bitcointalk forum I am known as _____" in there? As their + button does not seem to be for adding new fields/sites to the list of sites for which you get to say what your username or ID there is. (A pity, as + seemed naturally / logically to be expected to let me add just such fields to the list...

Maybe we can campaign to have them add bitcointalk to the list of such sites?

-MarkM-

It is a pity that DeVCoin does not seem yet to have taken hold or taken root as it was intended to, because the kind of useful, innovative new code proposed is just the kind of thing that DeVCoin was supposed to make possible.

Basically a coder such as the described anonymous developer, being a person who already naturally contributes good useful code to good useful projects, should be on the DeVCoin recipient list, receiving DeVCoins automagically so long as they continue their lifestyle of being a habitual lifestyle free open source code developer working on good useful free open source code.

Thus what was supposed to happen was people who want good free open source code such as the stuff in this shopping list of features to be develioped would be buying DeVCoins, which would make the DeVCoins all the lifestyle free open source developers automagically receive be worth more, which would enable and encourage them to spend more of their time working on free open source projects, hopefully resulting in a snowball so that this anonymous developer would have no need to go through this project proposal this thread is about because their steady stream of DeVCoins they would already be receiving due to their lifestyle of naturally contributing good work to good free open source projects would be going up and up in value as more and more good work such as that proposed in this thread was implemented by such "tenured developers"...

I hope that at least the anonymous developer referred to in this thread is already a "tenured developer" in the DeVCoin system if they are as it seems already a lifestyle contributor to worthwhile free open source projects...

In short, such developers should not have to come begging for financing of some specific project outlined in advance like this, instead they should already be well paid simply by the DeVCoins they naturally receive already anyway, having already been recognised to be a lifestyle free open source contributor that puts out good stuff. Putting out good stuff like the stuff proposed ought simply be the kind of thing such developers naturally do just because it is what they do,  without worry about money because they already get DeVCoins steadily and DeVCoins naturally keep going up and up in value as the community of such developers keeps putting out more and more good stuff thus motivating supporters of good free open source stuff to buy more and more DeVCoins thus motivating more and more lifestyle contributors to free open source projects...

Notice in the original post the implication that this stuff is stuff the developer wants to do. DeVCoin's idea is/was basically to provide stipends for such people just because they are such people and thus naturally produce such great stuff thus should be freed from needing to worry about how they will get paid to do such things so they can just go ahead and do them without wasting time energy effort worry etc etc on all this campaigning and politicking and such simply to be "permitted" to go about their lifestyle of freely contributing great free open source stuff to the world.

-MarkM-

TagBond seems to have used my email address for login, so what do you mean by username as in use same username as I use here? Tagbond seems email address oriented not username oriented though it did let me tell it my codes/usernames/whatever from various social sites.

-MarkM-

Good for you. I was thinking of posting that maybe you'd get lucky and find the address had been in your clipboard because it was an address of your own you had given to someone to send you coins, but figured if it had shown right back up at your wallet you would already have noticed. Glad it did turn out that was the kind of thing that had happened though.

-MarkM-

Seems likely it is same problem I have: running out of RAM. The handler for that chooses something to kill and does nto always kill cgminer, last time mine had that it was something to do with the web page that was killed so instead of a working web page saying the miner was stopped I had a not-working web page. Actually maybe even a cannot be pinged machine. I powered down and back up to get it running again.

I think we need a new "firmware" upgrade that gets rid of any RAM usage that isn't absolutely system-critical, as software bloat seems to have hit the limits of the beaglebone's RAM or some item of software in there has a memory leak.

-MarkM-

My 8-core (likely four cores with two hardware threads each) remote servers finally started getting some blocks so likely it was just random luck that had been making it look suspiciously like such servers were not really at least twice as good as my home machines like their hashes per minute figures were claiming.

One of them got two blocks one got one another got none.

Meanwhile a two core here at home, probably a duo, shows in listtransactions three blocks then one orphan then another three blocks, with less than half the hashes per minute of the remote servers; and another has three blocks. So it does seem likely it is mostly just a lottery aka variance.

-MarkM-

Not being able to boot, even if it is hard drive's fault, often does not make drive un-readable, for example often it is just the boot sector is trashed, all the data might be fine.

I have a bunch of ancient hard drives whose boot sectors don't work so they cannot be made bootable, yet the data, or at least most of it, is still there.

-MarkM-

Yet those same people will have no trouble coming up with a "pythagorean triple" to buy lunch with?

-MarkM-

Last night my miner got stopped again after only a few hours. So apparently it no longer takes a day or two to run out of RAM...

-MarkM-

There is no hurry. There are seven coins merged mined alongside bitcoin and gradually over time they all are going to get their code updated like happened first to I0Coin.

The longer that takes for any particular coin the longer people have to pick it up at low difficulty due to most pools not bothering to include it in their merge or to buy it cheap either on an exchange or, for those that aren't even on an exchange yet, from someone who is pessimistic and wants to dump.

The longer a particular coin stays low difficulty / low price the more time there is for people capable of doing the code updates to pick themselves up enough of a hoard of a particular coin to make it seem to them to be worthwhile to get around to doing the update.

It thus might even make more sense to update GeistGeld and CoiLedCoin long before getting around to IXCoin simply because they are much lower difficulty so one can pick up a lot more of them a lot faster whereas IXCoin it takes a long long time to accumulate them as part of one's merge when mining.

-MarkM-

I have three dedicated servers out at third party datacentres on good bandwidth with eight cores each, or maybe four real cores appearing as two each; each such box gets two or more times as many hashes per timespan as any of my machines here at home on my much less bandwidth; home is Halifax NS Canada, third party machines are around Germany or Denmark type of region. (Forta Trust dedicated servers.)

Not one of the third party machines has a block, I have been running them since an hour or two after mining started. Getting my home machines running took a little longer but some of them found blocks almost as soon as I got them running, one of them has found three blocks and one orphan block and two more blocks.

So either variance is skewing this or merely having high hashing power on good bandwidth isn't all it takes to get a block?

The machines at home are mostly core 2 duo type of things, all only have two cores. (Old Dell  755's for example with 8 or 4 gigs of RAM). A couple have 16 gigs of RAM. The third party machines might only have four real cores with two simulated cores/threads/whatever each. They are using setgenerate true 7 so as to leave a thread/core for what the boxes normally are used for. Two of them have 16 gigs of RAM one has 24. Could their hyperthreads or whatever it is they have two of per core be interfering with each other or something ending up making the machines unable to find any blocks at all or something?

-MarkM-

I'd prefer not to start cluttering up my miner like it was a development box, hopefully if --lowmem and a stripped cgminer are good the next official upgrade will have them...

-MarkM-

The miner has installers and such? What do you mean by install strip command?  yum install strip or apt-get install strip or apt install strip type of thing?

I figured off the cuff, wild assed guess, that if strip isn't there likely things like package managers / installers likely aren't either...

What is that recipe for? Cross-compiling on some other machine? Or you run that on your miner?

-MarkM-

The price maybe dates back to before the feeding frenzy of the usual pump and dump folks got underway with all the rented by the hour servers and such, likely most miners over the next 20 hours or whatever will be the usual folk who are only here for a quick dump...

-MarkM-

I am using the executable ckolivas most recently posted about, supposedly 3.7.1

I don't have an ARM development machine nor know a thing about cross-compiling on Fedora 17 or 19 for ARM machines.

I have run over 48 hours before dying  sometimes, even over 72 maybe. Actually maybe it didn't die like this until they released a release that had a ckolivas version in it, hmm I wonder if that one is/was stripped? Hmm... I am not sure when I first encountered this "mystery dying" problem, seems liek it ran quite a few days originally.

I killed it to try running strip on it on the beaglebone, that is how I discovered they dont' seem to have strip on that. But now it shows in web page as 282 so maybe its not goign to lose much by using --lowmem option afterall. I do wonder how much RAM the debugging symbols are consuming though...

-MarkM-

I grabbed the ckolivas one because it was said to possibly fix cases where mining stops completely. which is what I had been seeing from the official release.

I hoped that this problem of mining being stopped completely according to the web page, which has turned out to be due to an out of memory condition, was the mining stopping completely problem that the wget grabbed version hoped to fix.

In other words, I didn't have a working version in the sense of one that did not mysteriously die after a day or two or few and hoped the wget would get me one that would not thusly die.

I am trying the latest wget with --lowmem now hopefully that won't die...

But it seems to be settling at 278 GHashes whereas I had been getting usually 283, so maybe putting another stick of RAM or larger stick of RAM in the damn beaglebone might be better if --lowmem loses hashing power. I wonder if the damn beaglebones can handle more RAM? Maybe KnC skimped on RAM too quickly without considering that software tends to get bigger all the time...

Or maybe I should kill the stupid webserver, if I can ssh what for do I need a webserver on the thing anyway? Hmm...

Also, I looked at the file I had used wget to get with "file" command on an X86_64 , and that claims its an ARM executable that is not stripped. Wouldn't it maybe use less RAM if it were stripped? Does it make much sense to use a not-stripped executable on an "imbedded device" type thing like this where RAM is at a premium and no debugger is installed? Any chance of a stripped version, ckolivas? (My X86_64 strip doesn't even recognise the thing as an executable and the miner does not have strip installed...)

-MarkM-

Yep it was out of memory, dmesg shows:


-MarkM-

Rise VS does not mean worth more than.

If bitshares are worth $100 each and bitUSD rise from $1 each to $2 each, they have risen VS bitshares, but are still not worth more than bitshares.

In fact, to create $1 worth of bitUSD requires $2 worth of bitshares, so unless there are twice as many bitshares as there are bitUSD, bitshares should tend to be worth more than bitUSD.

Bear in mind also there will need to be twice as much "worth" of bitshares as there are "worth" of bit gold, bitsilver, bitpoop, bitwhatzits, bitwierds, bitwhatevers, bitwhateverelses etc etc all put together.

So hey if I hold a shit-load of bitshares and using some of them to create some bitUSD would increase the value of bitshares why wouldn't I use a few of my bitshares to do that so the massive majority of my bitshares will increase in perceived value thanks to the usefulness and convenience of the bitUSD that I used a few of them to bring into existence?

-MarkM-