Bitcoin Forum
March 29, 2024, 01:07:03 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 ... 180 »
  Print  
Author Topic: [ANN][YAC] YACoin ongoing development  (Read 379827 times)
Seth Otterstad
Sr. Member
****
Offline Offline

Activity: 328
Merit: 250



View Profile
May 30, 2013, 06:59:27 PM
 #401

Is TacoTime right about this?  Why are people saying GPU mining will become impossible in august?
Current GPU implementations stop working at Nfactor value due to be in august. IMHO it's unlikely that this can't be fixed. However, GPUs should be much slower by then, only slightly faster than a CPU (AFAIK).

EDIT: see https://bitcointalk.org/index.php?topic=206577.msg2162620#msg2162620

So I am to understand that when coblee asked for suggestions on how to prevent GPUs from taking over litecoin, all he had to do was change the N value to higher than 8192 and litecoin would have become way more GPU resistant?

Coblee's thread about GPU-mining and Litecoin:
https://bitcointalk.org/index.php?topic=64239.0

Seth Otterstad's Blog          @SethOtterstad on twitter          Seth on google+
1711674423
Hero Member
*
Offline Offline

Posts: 1711674423

View Profile Personal Message (Offline)

Ignore
1711674423
Reply with quote  #2

1711674423
Report to moderator
The forum strives to allow free discussion of any ideas. All policies are built around this principle. This doesn't mean you can post garbage, though: posts should actually contain ideas, and these ideas should be argued reasonably.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
sairon
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


One does not simply mine Bitcoins


View Profile
May 30, 2013, 07:14:43 PM
 #402

So I am to understand that when coblee asked for suggestions on how to prevent GPUs from taking over litecoin, all he had to do was change the N value to higher than 8192 and litecoin would have become way more GPU resistant?

Coblee's thread about GPU-mining and Litecoin:
https://bitcointalk.org/index.php?topic=64239.0

Well, the N factor increases memory requirements for computing a single hash (thus it's using more memory and memory bandwidth). Current GPUs will quickly run out-of-memory (or there's other GPU-specific constraint that prevents the code from running at higher N, dunno). However, it also affects CPUs really hard (around 40% hashrate decrease if I remember correctly).

GPG key ID: 5E4F108A || BTC: 1hoardyponb9AMWhyA28DZb5n5g2bRY8v
procrypto
Full Member
***
Offline Offline

Activity: 224
Merit: 100


Shitcoin Maximalist


View Profile
May 30, 2013, 07:31:27 PM
 #403

Apologies to WindMaster and the rest of the community, I haven't had enough time to dedicate to this as yet, as it happens to have coincided with ongoing drama and mayhem in my meatspace job. Personally still getting up to speed with cryptocurrencies in general (I'm a front end web developer by trade) so don't feel I can yet contribute a whole lot to core development yet, but I'm learning fast.

On #2, anyone have further thoughts on whether a third-party miner (cpuminer) should indeed be included in the main YACoin installer, or if that would be better divided into a 2nd, different installer?  Same for selecting which p2pools to sort of "endorse" as part of the installer, when we know that p2pools are going to be a fast-moving target and any that are selected might randomly disappear or misbehave in the future, causing basically broken shortcuts unless someone is constantly checking for new versions of the client installer.

On the first point, I'd rather it all be in a single installer. I think we should definitely aim to keep the whole process as simple as possible (i.e. one installer to run over two).

Agree with this, single installer would be far preferable for most users.

b. the script that launches the miner makes a web service call to a central service (on google appengine for example) that will feed back a "current" list of p2pool hostnames. From this, the command line arguments are constructed. Making such a web service would be trivial. The script could be created that a default, hardcoded list would be used if this webservice was down.

This seems like a great idea, updating the list of p2pools remotely would be much better than relying on a hardcoded list alone.

Guys, have you seen bitminter.com? Very neat pool.


Love this kind of interface, would be super user-friendly for the average desktop miner to operate.
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
May 30, 2013, 07:33:27 PM
 #404

So I am to understand that when coblee asked for suggestions on how to prevent GPUs from taking over litecoin, all he had to do was change the N value to higher than 8192 and litecoin would have become way more GPU resistant?

Coblee's thread about GPU-mining and Litecoin:
https://bitcointalk.org/index.php?topic=64239.0

Well, the N factor increases memory requirements for computing a single hash (thus it's using more memory and memory bandwidth). Current GPUs will quickly run out-of-memory (or there's other GPU-specific constraint that prevents the code from running at higher N, dunno). However, it also affects CPUs really hard (around 40% hashrate decrease if I remember correctly).

Nah, all you have to do is increase the lookup gap (via the previously published TMTO solution for scrypt from cgminer/reaper) and then you can compute the same hashes with less memory.

There's a probably bug in mtrlt's current code that doesn't allow calculation above N=4096, but it's possible that this particular TMTO implementation is not really optimized well for the GPU and that in the future with some hacking we'll see the gap further widen.

The further up the N value you get, the greater dependence on memory access speeds you typically observe (or at least, I observed using scrypt-jane on a CPU).  I wouldn't be surprised if eventually an implementation for GPUs came along that was optimized and destroyed CPUs for efficiency and speed.

BLAKE is used as an entropy source to randomize memory access too, I wouldn't be surprised if you looked at accesses to the lookup table and found that they end up being less than random as well due to consistent ordering of some types of data in the block header (thus also diminishing the amount of memory required).  I think pooler observed this when he was writing his CPU miner.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
Joe_Bauers
Hero Member
*****
Offline Offline

Activity: 802
Merit: 1003


GCVMMWH


View Profile
May 30, 2013, 08:04:46 PM
 #405

 I wouldn't be surprised if eventually an implementation for GPUs came along that was optimized and destroyed CPUs for efficiency and speed.

+1

There's no way to [proof] proof anything forever... Unless WM wants to spend the time/effort to constantly try to stay ahead of GPU implementations...

Personally, I don't see a reason why eventual mass GPU YACoin mining would do anything but strengthen YAC as it did for LTC. Besides, there are going to be "lots" of vid cards sitting around looking for something to do once ASIC's completely take over Bitcoin. 
theprofileth
Full Member
***
Offline Offline

Activity: 239
Merit: 100

Socialist Cryptocurrency Devote


View Profile
May 30, 2013, 08:12:51 PM
 #406

I wouldn't be surprised if eventually an implementation for GPUs came along that was optimized and destroyed CPUs for efficiency and speed.

+1

There's no way to [proof] proof anything forever... Unless WM wants to spend the time/effort to constantly try to stay ahead of GPU implementations...

Personally, I don't see a reason why eventual mass GPU YACoin mining would do anything but strengthen YAC as it did for LTC. Besides, there are going to be "lots" of vid cards sitting around looking for something to do once ASIC's completely take over Bitcoin. 
I am actually going to have to disagree. GPU mining means fpga's and asics can still function and thus dominate which is why YAC must be sure to keep it self safe from things such as this. Furthermore, GPU mining would only increase the difficulty and make my small supply of coins even smaller  Wink
No but really litecoin isn't that well off, sure it is better than YAC or most other alt coins but thats pretty much because it was first not because GPU mining has treated it well.
If need be while it would be painful I think that the N factor should be increased if gpu mining became a viable option lest people begin the process of pumping and dumping. If we want YAC to last we need to keep it CPU only. Because even if everyone is going slower it will at least be a network wide slowdown and hit everyone relatively evenly which is partly why the massive speed decreases arent that bad because it is only a speed decrease for the network and not just for you and these decreases help keep YAC slightly safer with each increment. What I think we need next TBH is a proper mining program with stratum support. That way we can capitalize on the hashrate we still have left and get better feedback and less stale shares.
Seth Otterstad
Sr. Member
****
Offline Offline

Activity: 328
Merit: 250



View Profile
May 30, 2013, 08:21:34 PM
 #407

The whole point of trying to make a GPU-hard coin is to get a more even initial coin distribution than bitcoin/litecoin did.  The number of people with CPUs is way higher than the number with good GPUs.  There is no point to making a new alt-coin to change the mining algorithm if it doesn't promote a wider distribution by cutting out the GPU farmers.  The algorithm doesn't have to last forever; it only has to last a few years until ASICs are developed.  Litecoin lost its whole purpose when it was taken over by GPUs.  If we knew a way to assign an equal amount of coins to everyone on the planet in a decentralized way, we would do that, but that technology is decades away.  Distributing it to everyone with a CPU is way less fair, but it is still vastly superior to giving it to everyone with a GPU.

Seth Otterstad's Blog          @SethOtterstad on twitter          Seth on google+
Joe_Bauers
Hero Member
*****
Offline Offline

Activity: 802
Merit: 1003


GCVMMWH


View Profile
May 30, 2013, 08:26:14 PM
 #408

What I think we need next TBH is a proper mining program with stratum support. That way we can capitalize on the hashrate we still have left and get better feedback and less stale shares.

I looked at this very briefly a few days ago and it looks like it could be adapted to YACoin if someone has time to spend a few hours on it    https://github.com/CryptoManiac/stratum-mining
AGD
Legendary
*
Offline Offline

Activity: 2069
Merit: 1164


Keeper of the Private Key


View Profile
May 31, 2013, 07:17:03 AM
 #409

What is the advantage of Stratum mining?

Bitcoin is not a bubble, it's the pin!
+++ GPG Public key FFBD756C24B54962E6A772EA1C680D74DB714D40 +++ http://pgp.mit.edu/pks/lookup?op=get&search=0x1C680D74DB714D40
hanzac
Sr. Member
****
Offline Offline

Activity: 425
Merit: 262


View Profile
May 31, 2013, 07:30:38 AM
 #410

AMD's next gen APU with HSA will be very interesting, the unified memory addressing can be the boost for the scrypt or even scrypt jane. In next year, we can try Kaveri.
cycloid
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250



View Profile WWW
May 31, 2013, 07:57:24 AM
 #411

What is the advantage of Stratum mining?

More work is done on miners end resulting in less bandwidth needed for the pool server.

WindMaster (OP)
Sr. Member
****
Offline Offline

Activity: 347
Merit: 250


View Profile
May 31, 2013, 08:38:20 AM
Last edit: May 31, 2013, 08:51:42 AM by WindMaster
 #412

AMD's next gen APU with HSA will be very interesting, the unified memory addressing can be the boost for the scrypt or even scrypt jane. In next year, we can try Kaveri.

Note that scrypt-jane isn't a hashing algorithm, it's a generic scrypt library that supports many different variations of scrypt, including scrypt+salsa20/8 as used by Litecoin.  I've noticed quite a few people refer to the scrypt variant used by YAC as "scrypt-jane", but that's actually wrong.
theprofileth
Full Member
***
Offline Offline

Activity: 239
Merit: 100

Socialist Cryptocurrency Devote


View Profile
May 31, 2013, 11:15:17 AM
 #413

Hmm someone should put a bounty up for proper software or better yet integration into cgminer (which is much more likely than BFGminer due to lukejr's view on alt coins)
I'd be willing to throw a couple coins in to get a bounty up. (by coins I mean both YAC and BTC)
hanzac
Sr. Member
****
Offline Offline

Activity: 425
Merit: 262


View Profile
May 31, 2013, 02:27:57 PM
 #414

Note that scrypt-jane isn't a hashing algorithm, it's a generic scrypt library that supports many different variations of scrypt, including scrypt+salsa20/8 as used by Litecoin.  I've noticed quite a few people refer to the scrypt variant used by YAC as "scrypt-jane", but that's actually wrong.

So what's the name for it? Roll Eyes We shall give it a name, scrypt-chacha?
dragon2nd
Member
**
Offline Offline

Activity: 94
Merit: 10


View Profile
May 31, 2013, 02:41:11 PM
 #415

Quote
{
    "blocks" : 76185,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 1.48652633,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "hashespersec" : 150811,
    "networkhashps" : 89660601,
    "pooledtx" : 0,
    "testnet" : false,
    "Nfactor" : 8,
    "N" : 512,
    "powreward" : 23.40000000
}

I've noticed a huge increase in network hashrate. It is now 600x my own hashrate, while it was still 300x two days ago.
sairon
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


One does not simply mine Bitcoins


View Profile
May 31, 2013, 02:46:50 PM
 #416

I've noticed a huge increase in network hashrate. It is now 600x my own hashrate, while it was still 300x two days ago.

The client sometimes reports garbage, take a look at these graphs, they're averaged over 144 blocks (10 blocks for 24h graphs).
Network hashrate actually decreased on the 29th due to the Nfactor change.
http://yacexplorer.tk/graphs.htm

GPG key ID: 5E4F108A || BTC: 1hoardyponb9AMWhyA28DZb5n5g2bRY8v
JahPowerBit
Sr. Member
****
Offline Offline

Activity: 335
Merit: 255


Counterparty Developer


View Profile
May 31, 2013, 03:44:54 PM
 #417

I think it's very important to see YAC on sites like http://www.coinchoose.com/

I found this post with formula for BTC : https://bitcointalk.org/index.php?topic=63273.msg743237#msg743237

But i have no idea how we can integrate N in this formula.. someone have an idea ?
sairon
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


One does not simply mine Bitcoins


View Profile
May 31, 2013, 03:55:50 PM
Last edit: May 31, 2013, 04:07:18 PM by sairon
 #418

I think it's very important to see YAC on sites like http://www.coinchoose.com/

I found this post with formula for BTC : https://bitcointalk.org/index.php?topic=63273.msg743237#msg743237

But i have no idea how we can integrate N in this formula.. someone have an idea ?

You need a formula for the block reward, Nfactor affects only difficulty.

EDIT: from the source:
Code:
int64 GetProofOfWorkReward(unsigned int nBits)
{
    CBigNum bnSubsidyLimit = MAX_MINT_PROOF_OF_WORK;
    CBigNum bnTarget;
    bnTarget.SetCompact(nBits);
    CBigNum bnTargetLimit = bnProofOfWorkLimit;
    bnTargetLimit.SetCompact(bnTargetLimit.GetCompact());

    // ppcoin: subsidy is cut in half every 64x multiply of difficulty
    // A reasonably continuous curve is used to avoid shock to market
    // (nSubsidyLimit / nSubsidy) ** 6 == bnProofOfWorkLimit / bnTarget
    //
    // Human readable form:
    //
    // nSubsidy = 100 / (diff ^ 1/6)
    CBigNum bnLowerBound = CENT;
    CBigNum bnUpperBound = bnSubsidyLimit;
    while (bnLowerBound + CENT <= bnUpperBound)
    {
        CBigNum bnMidValue = (bnLowerBound + bnUpperBound) / 2;
        if (fDebug && GetBoolArg("-printcreation"))
            printf("GetProofOfWorkReward() : lower=%"PRI64d" upper=%"PRI64d" mid=%"PRI64d"\n", bnLowerBound.getuint64(), bnUpperBound.getuint64(), bnMidValue.getuint64());
        if (bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnTargetLimit > bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnTarget)
            bnUpperBound = bnMidValue;
        else
            bnLowerBound = bnMidValue;
    }

    int64 nSubsidy = bnUpperBound.getuint64();
    nSubsidy = (nSubsidy / CENT) * CENT;
    if (fDebug && GetBoolArg("-printcreation"))
        printf("GetProofOfWorkReward() : create=%s nBits=0x%08x nSubsidy=%"PRI64d"\n", FormatMoney(nSubsidy).c_str(), nBits, nSubsidy);

    return min(nSubsidy, MAX_MINT_PROOF_OF_WORK);
}

GPG key ID: 5E4F108A || BTC: 1hoardyponb9AMWhyA28DZb5n5g2bRY8v
Sahtor
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile WWW
May 31, 2013, 06:25:35 PM
 #419

Suggestion for official Yacoin currency symbol Ɏ or U+024E   

Symbol: Ɏ
Unicode name: Latin Capital Letter Y with stroke
Code: U+024E
Decimal:
Code:
&#590;

https://en.wikipedia.org/wiki/List_of_Unicode_characters
https://en.wikipedia.org/wiki/Unicode_input
bitdwarf
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


The cryptocoin watcher


View Profile
May 31, 2013, 06:28:12 PM
 #420

Sounds good. I don't think the Igorot people in the Philippines will mind. http://en.wikipedia.org/wiki/Y_with_stroke

𝖄𝖆𝖈: YF3feU4PNLHrjwa1zV63BcCdWVk5z6DAh5 · 𝕭𝖙𝖈: 12F78M4oaNmyGE5C25ZixarG2Nk6UBEqme
Ɏ: "the altcoin for the everyman, where the sweat on one's brow can be used to cool one's overheating CPU" -- theprofileth
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 ... 180 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!