Bitcoin Forum
June 05, 2023, 02:37:25 AM *
News: Latest Bitcoin Core release: 25.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Alternate cryptocurrencies / Altcoin Discussion / [SATIRE] How to design a CoinChoose-constantly-profitable coin? on: June 10, 2013, 08:59:09 PM
As logic is of absolutely no threat in dealing with CC hashwaves/pumpdumps, I've decided to switch sides to the demonstrative position, one of technological satire:

Since the supposed purpose of CC and Cryptoswitcher or other CC-etc-tracking pools was to show the ridiculousness of valuing all ALT coin based on its next block of  against a 0.5BTC-deep vapour-market (*or smaller!), I suggest a project to assist with the ultimate expression of this total stupidity.

A coinchoose-gaming, or compliant coin. Also known as CoinchooseCrapCoin, CCC.

This coin would somehow get the value off exchanges of the current coin's trades, and set the difficulty so that the coin would remain at some profitability. Perhaps something modest, so that people' dont realise it's a total joke (ie at 500%). I suggest something plausible, like 110%. Or even just 100.

The tricky part is to get this information into the blockchain reliably without being spoofed, and with forewarning Crypsty et al that they're about to be ddos'ed even harder for the uncreative hacker who doesnt just turn to spoofs. That's a real tricky problem: injecting external metrics into any coin.

If this problem is solved however, it benefits our communities hugely - external metrics reliably imported into coins behaviour would allow real world usefulness to increase. But this is possibly intractable. Hopefully not. Get your brain juices flowing.

I fear the only issue with such a project might be that the pricing drops to <1 ALToshi within a short time, thus nuking the coin. Perhaps this wont be the case though? Theorize!

* Please note that the forums-compliant SATIRE flag has been set on this thread, so be careful how you reply. The moderator may find you humourless and reject your postings.
2  Alternate cryptocurrencies / Altcoin Discussion / How to design a CoinChoose-resistant coin? on: June 09, 2013, 03:59:43 PM
The biggest threat to altcoins isnt ASIC mining BTC and just buying up lots of ALT for cheap, depressing the price anymore.

Coinchoose pretends that a 0.5BTC deep market represents the pricing value on 100s of BTC of several hours/days of mining by punters tracking most profitable coin. Punters think they can all mine 10000s of ALT then go to the market anytime and get full value by dumping 100x the coin volume of ALT ever traded. Ridiculous.

This creates an unnatural (and unattended!) hashing wave for new ALT, which pumps up the difficulty after a time, and then, like most coins, cause a 4x increase in diff, drops the price on the floor.

This isnt healthy for any coin, but the autominers tracking the bogus valuations on CC are a force to be watched, with 100-200MHs on scrypt, if not more.

It doesnt matter if someone DOS's CC again like yesterday, some dumbass site with some random valuation will appear, everyone will take its math as gospel, and point their miners at it (it DOES however provide some WONDERFUL price gaming opportunities, which are pretty hard to resist!) But that really fucks the market up.

So leave CC and clones as is, since there's nothing to be done about ignorance. The question is how to code a coin that resists such pump/dump waves.

Obviously a coin that retargs every block would be great, but then you have a static value vs radical change in difficulty issue, which results in TRC's yoyo difficulties.

ELC however values coins for the hashrate put in, which makes that yoyoing less effective. Unfortunately, ELC nInterval=2160 * 120s.  This mostly causes STALLCOIN (unrelated to STABLECOIN, actually, which is about horses I think), tho with ELC there's much less value loss to miners than most ALT because value ~ diff in ELC.

But ELC wont solve this, its subject to CCwaves just as much as any ALT.

I have a few ideas, but id like to get more opinions on CC's effect on ALT market first.

3  Alternate cryptocurrencies / Altcoin Discussion / [ANN] ELACOIN fork: retarg @19440 diff .3 |interval calc change? see page 11+ on: June 03, 2013, 06:49:52 AM
Elacoin: THE FAIR MINING COIN - reward ~= difficulty

Update #10 12/25: Still not dead. Find us on #elacoin on

Update #9 06/22 18:00Z: Not Dead Yet[tm] Still around after being busy on other stuff, going to get the difficulty retargetting fixed so we can deal with CoinChoose hashwaves. Everything else will be the same (valuation, threshold value at diff 1 = 1 still, etc etc.) So no major changes, just getting back to reasonable block times, and code to deal with yet another CC hashwave.

Also we checkpointed block 21980, update your src's, WIN-QT is coming soon to github, stay tuned.

Update #8 06/10 02:40Z: Checkpoint 21600 (the 10th nInterval), retarg'd to .888 diff. Coinchoose is back up and causing stupidity. Update clients (src and .exe's updated, MAC soon is up now 06/10 05:17Z).

Update #7 06/09 06:45Z: Checkpoint 20940. Retarg'd at 19440 to .31 diff as expected. Hashing continues apace, this time without CoinChoose's disruptive influence, cuz it's down right now. next retarg at 21600, < 600 blocks

Update #6 06/07 07:21Z: MOAR checkpointz! update your clients: checkpoints.cpp: block 19400 hash: ce70abf9c0930d5cdcff555ceec6e6777f70f3a8bbc4b1efc9ac5c49a3b6c8e6

Update #6 06/06 21:15Z: update your clients plz: checkpoints.cpp: block 19350 hash: c6c725fb3c376a2cc4a0796ab4aa04af1ff472628c8e82ece55657b60b3150a5

Update #5 06/05 18:10Z: new checkpoint in the code, update your clients for all our mutual benefits. (was for block 19200)

Update #4 06/05 05:17Z: minor brainfart: 19440 is the next retarg. 2160 * 9.

Update #3 06/04 21:27Z: pool working fine. Use that for now. Idea for a lottery give away for mining on it, base reward for mining + more for hashpower so everyone gets a chance. Ideas on parameters? Smiley Just want to keep things going to 19400 so we maintain a viable coin & value.

COMMENT: Next natural retarg is at 9*2160 = 19400th block. Diff now is 1.25, and max factor is /4. 1.25/4 = .3125. Profitability will increase by 4x. Worth sticking around for to get to 19400.

GIVEAWAY UPDATE: Done with the giveaway, but considering to give bounties for mining Smiley

UPDATE #2: fixed their reporting bug. Elacoinpool should be soon. No shares are lost, and all will be paid out.

UPDATE: All pools were updated and are serving shares. However there is a reporting bug. Shares will be paid out properly, but blocks are not being reported in stats. Pool owners have been notified. Continue mining, you will receive shares. This is a bug in pushpool.

There will be a hard fork at #17820.

We have updated ELC clients at

We have a WinQT binary at GitHub. Additionally a compile guide for WinQT (see orig thread linked below).

Please see the original thread here for details on the changes:

- base reward = difficulty. This means you always get the same reward for the same hashing power, factored by the 270day scaling factor. No worrying about 10x the hashrate giving you 1/10th the coins.

- difficulty retarg will occur at 17820 and again 270, 540 and 1080 blocks later before returning to every 2160 blocks. Estimated next diff .15 ish (40x easier than current way high diff) WILL BE 0.27 (due to the code's max /16 retarg divider) but min reward is based on diff = 1, so high benefit for mining diff < 1.

Additionally we have properly implemented the original ideas behind the coin, fixing up some of the code to get rid of side effects and produce as well a smooth scaling feature uncommon in other coins to avoid a violent 'halving' event situation like with BTC.

As you can see we have kept this coin alive through hard work and commitment of the community. This is not a pump and dump coin or opportunity. There is no < 0.001 difficulty opportunity here. This should be attractive to lower end miners, and trouble big rig farmers who count on blocktimes faster than network diameter to ensure orphan dominance. Sorry. Everyone will get rewards equal to their hashpower, regardless of how many new miners join the effort.

  • Pools: (all 3 updated, scryptmining has been working fine the whole time since fork!)
  • Homepage
  • Exchange: - to be updated by Vern shortly.
  • Profitability tracker: -- needs updating talked to SAL002
  • Block explorer: coming soon
  • Irc channel:
  • Fountain: *soon*
  • Games: 100 ELC bounty available for 1st, 50 for 2nd, 25 for 3rd
  • Coin giveaway: reply to this thread for 1 ELC to first 100 replies!

Please discuss ELACOIN in the original thread linked above, as this thread will be a giveaway thread.
4  Other / Beginners & Help / I've met the 4 hr+ and 5 post limit but still cant post - what gives? on: May 13, 2013, 05:01:27 PM
As per topic, i bet others are experiencing this.

Do  I need a mod's intervention?

"Total time logged in: 4 hours and 7 minutes."

"Newbie Restrictions:
You can only post in the Newbie and Local sub-forums till you have 5 posts and at least 4 hours on the forum. "
5  Other / Beginners & Help / trouble scrypt mining on linux - 0 accepted/0 rejected, no shares at all on: May 06, 2013, 07:46:54 PM
Having an impossible time scrypt mining on linux. I have compiled BOTH bfg-3.0.2 and cgminer 3.1.0 on my box here. Both of them act totally wierd on multiple different AMD/ATI cards. I have zero problems SHA256 mining.

If i mine CNC solo on 7970, i get 56MH/s reported and never find any blocks. If I mine CNC pooled, iget 26MH/s reported and no shares. At least the block difficulty is reported ok.

On cgminer the block difficulty for CNC and FTC is like 60,000x higher than the actual network block diffs (which are in the 100s range, they report 12M for ftc for eg). And I either get 1Kh/s on CNC pool, or multiple MH/s reported.

I switched to solo FTC and get a reasonable hashrate with a 5830 (600Kh/s?) but never anything found - for a faster test check, i moved to featherpool and still getting 570-600KH/s for a 5830 (which seems a bit fast, tho), but the GPU stats in BFG show 20-30% usage and temp 40C (much lower than the 80C i usually get with my 40% fan tolerable noise level setting). Still 0 accepted, and 0 rejected at all times. Ie no work traffic at all.

Pretty sure none of it is working right.

Here's a bit of the debug output from bfg on featherpool

[2013-05-06 15:43:15] [thread 0: 604672 hashes, 601.8 khash/sec]
 [2013-05-06 15:43:15] 1s:592.9 avg:577.3 u:  0.0 kh/s | A:0 R:0 S:0 HW:0 U:0.0/m BS:0
 [2013-05-06 15:43:16] OCL 0: Popping work from get queue to get work
 [2013-05-06 15:43:16] OCL 0: Got work from get queue to get work for thread 0
 [2013-05-06 15:43:16] Successfully rolled time header in work
 [2013-05-06 15:43:16] Successfully rolled time header in work
 [2013-05-06 15:43:16] Pushing cloned available work to stage thread
 [2013-05-06 15:43:16] Pushing work from pool 1 to hash queue
 [2013-05-06 15:43:16] Cloned getwork work
 [2013-05-06 15:43:16] [thread 0: 570880 hashes, 567.9 khash/sec]
 [2013-05-06 15:43:16] 1s:584.0 avg:577.3 u:  0.0 kh/s | A:0 R:0 S:0 HW:0 U:0.0/m BS:0
 [2013-05-06 15:43:17] Temperature below target, increasing clock speed
 [2013-05-06 15:43:17] 46.0 C  F: 41%(1601RPM)  E: 600MHz  M: 222MHz  V: 1.063V  A: 29%  P: 0%
 [2013-05-06 15:43:17] [thread 0: 558592 hashes, 555.9 khash/sec]
 [2013-05-06 15:43:17] 1s:573.9 avg:577.3 u:  0.0 kh/s | A:0 R:0 S:0 HW:0 U:0.0/m BS:0
 [2013-05-06 15:43:18] [thread 0: 607104 hashes, 605.3 khash/sec]
 [2013-05-06 15:43:18] 1s:585.5 avg:577.3 u:  0.0 kh/s | A:0 R:0 S:0 HW:0 U:0.0/m BS:0
 [2013-05-06 15:43:19] [thread 0: 606720 hashes, 604.2 khash/sec]
 [2013-05-06 15:43:19] 1s:592.6 avg:577.3 u:  0.0 kh/s | A:0 R:0 S:0 HW:0 U:0.0/m BS:0
 [2013-05-06 15:43:20] Temperature below target, increasing clock speed
 [2013-05-06 15:43:20] 45.0 C  F: 41%(1606RPM)  E: 600MHz  M: 222MHz  V: 1.063V  A: 29%  P: 0%
 [2013-05-06 15:43:20] [thread 0: 569088 hashes, 567.0 khash/sec]
 [2013-05-06 15:43:20] 1s:583.2 avg:577.3 u:  0.0 kh/s | A:0 R:0 S:0 HW:0 U:0.0/m BS:0
 [2013-05-06 15:43:21] [thread 0: 564736 hashes, 561.9 khash/sec]
 [2013-05-06 15:43:21] 1s:575.7 avg:577.3 u:  0.0 kh/s | A:0 R:0 S:0 HW:0 U:0.0/m BS:0
 [2013-05-06 15:43:22] OCL 0: Popping work from get queue to get work
 [2013-05-06 15:43:22] OCL 0: Got work from get queue to get work for thread 0
 [2013-05-06 15:43:22] DBG: sending get RPC call: {"method": "getwork", "params": [], "id":0}

 [2013-05-06 15:43:22] JSON protocol request:
{"method": "getwork", "params": [], "id":0}

 [2013-05-06 15:43:22] Pool 1: Found bundle for host 0xe687c0
 [2013-05-06 15:43:22] Pool 1: Connection 36 seems to be dead!
 [2013-05-06 15:43:22] Pool 1: Closing connection 36
 [2013-05-06 15:43:22] Pool 1: About to connect() to port 9999 (#37)
 [2013-05-06 15:43:22] Pool 1:   Trying
 [2013-05-06 15:43:22] Pool 1: TCP_NODELAY set
 [2013-05-06 15:43:22] Pool 1: Adding handle: conn: 0x7ffbf40353a0
 [2013-05-06 15:43:22] Pool 1: Adding handle: send: 0
 [2013-05-06 15:43:22] Pool 1: Adding handle: recv: 0
 [2013-05-06 15:43:22] Pool 1: Curl_addHandleToPipeline: length: 1
 [2013-05-06 15:43:22] Pool 1: - Conn 37 (0x7ffbf40353a0) send_pipe: 1, recv_pipe: 0
 [2013-05-06 15:43:22] Pool 1: Connected to ( port 9999 (#37)
 [2013-05-06 15:43:22] Pool 1: Server auth using Basic with user 'clarpfog.c5830-2'
 [2013-05-06 15:43:22] HTTP hdr(Content-Type): application/json
 [2013-05-06 15:43:22] HTTP hdr(X-Long-Polling): /LP
 [2013-05-06 15:43:22] HTTP hdr(X-Roll-NTime): expire=120
 [2013-05-06 15:43:22] X-Roll-Ntime expiry set to 120
 [2013-05-06 15:43:22] HTTP hdr(Date): Mon, 06 May 2013 19:42:42 GMT
 [2013-05-06 15:43:22] HTTP hdr(Content-Length): 621
 [2013-05-06 15:43:22] Pool 1: Connection #37 to host left intact
 [2013-05-06 15:43:22] JSON protocol response:
   "id": 0,
   "result": {
      "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff070000",
      "midstate": "9d6716bef1503d539a8922ddc69d6119c13dc7cffa6d41c27d329b20160ba85a",
      "hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
      "data": "0000000158fc81cc4ec71fb4428f3d6b0e4357714cb142e93fe48e10353058204e5a775098394f647e7b73fb19b71f783ecf36970205d5d6c22aacfa28d8bded54864d24518807bb1c015c3d00000000000000800000000
      "algorithm": "scrypt:1024,1,1"
   "error": null
 [2013-05-06 15:43:22] Generated getwork work
 [2013-05-06 15:43:22] Pushing work from pool 1 to hash queue
 [2013-05-06 15:43:23] [thread 0: 598528 hashes, 596.0 khash/sec]
 [2013-05-06 15:43:23] 1s:583.3 avg:577.3 u:  0.0 kh/s | A:0 R:0 S:0 HW:0 U:0.0/m BS:0
 [2013-05-06 15:43:23] Temperature below target, increasing clock speed
 [2013-05-06 15:43:23] 45.0 C  F: 41%(1604RPM)  E: 600MHz  M: 222MHz  V: 1.063V  A: 31%  P: 0%
 [2013-05-06 15:43:24] [thread 0: 574080 hashes, 572.0 khash/sec]
 [2013-05-06 15:43:24] 1s:579.2 avg:577.3 u:  0.0 kh/s | A:0 R:0 S:0 HW:0 U:0.0/m BS:0
 [2013-05-06 15:43:25] [thread 0: 583808 hashes, 580.5 khash/sec]

anyone (luke-jr? lol.) got a hint there? compiled totally wrong? this is debian sid with all the right libraries (jansson, etc etc).

Are there any debian packages for cg or bfg out there?

Ive actually tried someone else's binary build of bfg-3.0.0 (debian wheezy compile), same issues. Is it my AMD libraries or something? Why would SHA256 work then?

Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!