Topic: [ANN][YAC] YACoin ongoing development - page 28. (Read 379983 times)

I have no other choice, yac.erlog.pt is scam or has a big bug! i found today 3 blocks again over this pool and these blocks do not show in the transactions, rewards, history or somewhere. the blocks exists in the blockchain as no orphan. what is with the scrypt-jane coins? all over Problems, DDoS, Bugs ... bullshit  

this is one of them http://explore.grokonet.com/?blocknumber=1158827

Which pool?

I'm on http://yac.erlog.pt/ with less than 1% rejection rate. Scan-time 10, expiry 30, queue default, but I don't think those settings should matter.

Updated GetNextTargetRequired function, this one takes care of "resetting" difficulty after PoS blocks.
Also updated code for raising difficulty of overstepped PoW blocks. In color:

http://yacoin.net/NewPreventPosIgnore3.htm

any working config for gtx970 ?!

i will keep this coin for asset 

Thanks Ron, that looks much better than I expected. I hope this will get into new release.

I want to throw some hash at the new pool.

Got it all working but my amd gpus with yacminer have up to 30% rejects and that is on top of the pool having 20-30% orphans.

Since the orphan issue is beeing looked at code wise (wallet),

is there anything I can do to lower the rejects in yacminer?
I'm normally used to 1-3% but 30% ...

What have you guys set your values for

scan time
queue
expiry

?

Me neither   You will realize it when you see the code (lol)How about a silent video? http://lostabout.com/btc/yactest3.aviThe code is quite compatible already.  Some files compile with no changes at all.  Those two files are pretty much covered already in util.h and compat.h. I only included the MS  stdint.h in a few files when boost stuck its nose in trying to define stuff that was already defined!

The only recurring issue was that the MSC++ compiler found ambiguity with certain types, that I found easiest to resolve with a :: in the code.  The types were the same, but the compiler can't presume that.  That and a ton of warnings on what can only be called sloppy code was about it.  Notice that in the daemon make file makefile.mingw, that in CFLAGS there is the -w argument! Try making without that and see what falls out.  It looks like the qt compile output

All of the above goes for Bitcoin and other coins too, so YAcoin is not alone!! They all could use a Joel Spolsky rub a dub dub

Ron

instantiated only from CBlock::AddToBlockIndex()  is my comment - I've made it while I've been checking constructor usage. And I forgot to delete it. It has no higher purpose. Sorry.



If you mean pIndexBest - perhaps you also need to check current testing version source from github to make more sense. But yes, best chain is a valid one with highest chain trust.



Having nPoSBlockCount stored only with PoS blocks takes less disk space (10 times less PoS blocks now). Besides if ratio would be 9.9999 at PoS block (rounded down to 9 due integral type) and after long sequence of PoW blocks back to 10 - and after next PoS block 9 again - that I did not want - I was considering removing noTwoConsecutivePoSBlocks rule when ratio hits 3 and I did not want that to float back to 4. This is only theory anyway, I might have missed the point completely.



This value later dictates number of consequent PoW blocks after PoS block, after which difficulty jumps and trust falls.
Having it truncated also forces PoW blocks window to "shrink" a bit sooner than real ratio would, thereby stimulating PoS block inclusion.
Decimal value would cause unnecessary conversions in calculations later.




I wasn't sure what you get if you call GetLastBlockIndex( *, true ) before first PoS block or when a bug was present. I did not want to allow division with zero so I returned 0 before next step. GetPoWPoSRatio() should always be called only on PoS blocks. And not before we switch to new version. Feel free to advise on best correction.



Are you asking, why we need that ratio?
As you know PoS blocks can be ignored by PoW miners. My fix goes like this:

1. Take the current PoW/PoS block ratio
2. Count PoW blocks after PoS block and if it gets over that ratio, incrementally raise difficulty and lower trust.



I would not swap order. I would swap their content.
In my code, PoW block target moving average is now stored in PoS block nNonce (instead of current 0).
If it would be stored in PoS block nBits, we could later calculate approximate chaintrust from block headers only.
Currently PoS block nBits attribute holds PoS block difficulty and that would need to be moved and code changed. But moved where? nNonce is the only candidate left.


The problem is, you can only partly differentiate PoW block from PoS block if you do not have transaction data, only headers (because there are some PoW blocks with nNonce=0 and there are some PoS blocks with target < bnProofOfWorkLimit). And you can not mix and aggregate their targets (nBits) to arrive at final chaintrust value without knowing what "type" of nBits you are operating with.




Headers-only method has a well documented purpose. The need for it will be even more aparent with Yacoin than with Bitcoin.
There could be other and better solutions, that is why I wanted feedback.



I don't know how to quickly and repeatedly get PoW/PoS ratio now without scanning and processing ever growing now 1M+ items long hash map. Please let me know.



We'd like that to change one day. Wouldn't we?



No, you are not different. This is just not industry anymore. I am learning C++ while fixing yacoin. Imagine how much I am getting paid for extensive analysis design and documentation.

Thanks for your input. You are welcome to elaborate.

Regarding your version with integrated explorer: I do not have QT installed and haven't programmed with it ever. Would you mind posting a screenshot or two?
Another thing I wanted to ask - why not use http://msinttypes.googlecode.com/svn/trunk/ in MSVC release? Wouldn't that cut down number of ifdefs and make a code more compatible?

Hello Senj,

Inline below are  a few questions and thoughts

I have looked at the code at both links.

First, since the original code (Bitcoin 0.7.4 aka Yacoin) is/was poorly documented, obscurely coded, unintentionally I'm sure, and written in a language (C++) that is more than opaque (1400 pages to "explain" the latest 4th incarnation of C++!!!!  Come on) I find that it is difficult squared reading the source for true "grokness" 

So since I don't understand things like why the special ctor CBlockIndex::CBlockIndex(unsigned int nFileIn, unsigned int nBlockPosIn, CBlock& block) is only called/instantiated by CBlock::AddToBlockIndex(), it is hard to see much deeper into the code.

Maybe I'm just different, but when I worked in the industry, we had a (much) higher standard of code "readability" and documentation.

Looking at your new CBlockIndex method GetPoWPoSRatio(), what is the intent of the integral nature of its return value?  It seems to me that it (the return value), since the code is doing an integral division, will be 0, 1, 2,...

How is that to be interpreted? 

Also is the "best chain" whatever that is (!?) what the code is using?  The first if() seems to be returning the number of PoW blocks / number of PoS blocks, only if the current block is PoS.  Why isn't the return the same if it isn't?  I'm missing something here too! 

Does the
if ( ppos->nPosBlockCount == 0 )   // should never happen
    return 0;
should never happen comment mean that two consecutive PoW blocks were just found??  And what does the return 0 mean/signify/imply?  Is it good? Is it bad?  Is it immaterial?  Is it boolean? 

I would at least like NEVER to see a magic number as a return value.  One can always in C++, define a meaningful name to be 0, thereby denoting and connoting the meaning/intent/context of the return value.

I would suggest an old C  #define if nothing else!  Perhaps a C++  const unsigned int variable or even a C++ enum.  They all are equivalent after any compiler digests it, and the code is the same, just as fast, but much more readable.

It is my reading that you are proposing adding a 32 bit unsigned int count of PoS blocks to the CBlockIndex class definition, to make some calculation faster/easier? 

I can't go much deeper until I can understand the things mentioned above.

I would be curious what other coders have to say about these things, or am I alone in the wilderness?
Looking at main.h, the CBlockHeader  class's last members are the unsigned ints nBits and nNonce.  I do not get the reason/purpose/intent of swapping their order?  I must be missing some other piece(s) of information, but it seems to me that it is immaterial which is first?  Similarly with nTime, the unsigned int before them?

I feel that there must be some (more) undocumented code that depends/relies upon the order of the members that I am not aware of?  If it is just undocumented magic number offsets in some code, for example, the definition of nBlockNonce in BitcoinMiner() in main.cpp, then I think we should fix those undocumented items first!

I don't see what "headers first method" (what ever that is!) has to do with the header being ordered slightly differently?
Isn't a full node all ready in possession of the whole block chain?  Or am I missing something in your logic?  And as I said previously, doesn't that full node already scan all the blocks in its possession at start up, so that it (the node) "knows" all there is to know,  PoW/PoS counts, ratios, last few block types, etc.?  And it's not like the blocks are really that much bigger than their headers.  Most have only the creation transaction, very few actual transactions, at least lately from what I have seen.

Again, am I missing something hidden/not stated here?I am generally 'fer' it not 'agin' it, in principle.  But whether I understand what the code is intending and how it is accomplishing it, or what the code is actually doing and whether that is what was intended, I can't say!  I can't even say what the current code is intending, nor what it is doing and whether they are the same.

I come from the postion that if one wants open source code to be understood by the widest possible audience, then the code has to be edited much as a literary editor edits a book (fiction or non-fiction).  layout (formatting) is important too, much like a book.

I think that if the code was much more transparent as opposed to being opaque, we might find that there are minds out there, that can see more deeply into the code and come up with insights that elude the "geek mind" that reads code through a constant filter (internal symbol table) in their own head, that memorizes and translates all the abbreviations, name-contractions, magic numbers,  greater than 200 character lines, ... and then has to paraphrase every line, method, class, template, macro, file,... in the program to state what is going on.

No paraphrasing should be necessary.

The editing of the source, that leaves the executable identical, byte for byte, but increases the readability, should have been done to the first or very early versions of the Bitcoin source.  Then all the coins wouldn't be in the state they are in.

We are six years into the life of Bitcoin, and there are functions, methods, names,... that haven't changed from the first versions. That is pure laziness, since editing is a very difficult but necessary job.   See Joel Spolsky's rub a dub dub:
http://www.joelonsoftware.com/articles/fog0000000348.html

A friend tells me that every 5 versions, where he works, they stop and do that, a cleanup, etc. of the code.  Hard to justify to a "bean counter" manager/corporation that a no change to the executable pause should occur in the process.  But since Bitcoin was/is not a private business thing, it should have been cleaned up, over and over again, from 0.3.1 to 0.11.0,  but I see no evidence of it.  Bad habits or the lack of ever having been exposed to good habits or laziness are the only explanations I can come up with.

Well, there's my 2centz

Ron

Speaking of new code:
I updated GetBlockTrust and added GetNextTargetRequired changes.

That encompasses two (out of three) major changes we need to patch yacoin.

What I would like to do next is talk about my next goal: Before these changes go in effect, I would like to do more refactoring (prepare, this might hurt a bit) and swap PoS block nNonce and nBits.
And the reason has to do with what I believe will be one of next major yacoin issues - future implementation of Headers-first method. Hard fork is the only right time to do such things. This way we can make it possible to determine chain trust from headers only (once you understand the changes I linked to), otherwise all clients will need to download and process full blockchain. This will become very time and resource consuming with each next block - and yacoin system generates a lot of them.

However, before I start,  I need some feedback from community - do I have your support? Will I get any help? Opposition?
And please check out two links above.

Yes, few consecutive PoS blocks got so much trust together they could overwrite hours of PoW blocks if they were not released immediately. But that only because each PoS block got a lot of trust in a first place.


I wasn't describing that, although I think it wouldn't be bad if we'd get rid of this rule eventually. Besides, new code does not prevent them.

I just want to point out that YACoin is still profitable to mine even with a 30% orphan rate on my i7.

I thought Sairon's fix was the no-consecutive PoS block rule?

I don't understand... Are you proposing to get rid of the no-consecutive PoS rule? I admit I don't how one would go about doing what you describe.


That is an important point. The only 'gaming' of the 'system' should rely solely on more resources, more technology, more efficiency--and large stake on the PoS side of things. If there is some way to take advantage of a 'loophole' in some cunning way and essentially steal from others, it will surely occur in the distant future if not the near future.

Remember that unreasonably high PoS block trust value was the reason why we needed Sairon's fix.
I thing it should be higher than now (prevPoWBlockTrust+1), but less than 2*prevPoWBlockTrust.
If higher, then mischievous PoS miner can withold each block, wait for receival of two new PoW blocks and then broadcast his with certainty that it would kick out both of them. That by itself is a small weakness.
But PoW after PoS block should keep it's trust doubled as it is now. This amplifies previous PoS block value in more "democratic" way.

I have been thinking a lot about this and my conclusion is that the more we try to award particular block/combination, bigger the chance someone will abuse it in his favor.

Here is more completed new functionality:
http://yacoin.net/NewGetBlockTrust2.htm

Hi Joe,

I looked at and tried the SOCKET "connect stuff" in net.cpp and netbase.cpp and nothing seemed to work reliably?  So I used some old Windows code, and it works very well!  I presume one could (and that means not me ) guard the Windows code in the constructor of the CdoSocket class and add some appropriate code for other OSs.

Ron

Let me know when your pool is ready and I will promote it on the website and twitter.

@Ron - Thanks for the pull request, I am looking at it now. I would like to see if we can get it working for all clients though. Maybe we can find a universal class for the RAII socket connect?

Due to the constant DDoS-attacks I have to temporarily shut down the stratum server. I hope to solve the problem in the near future.

Withdrawal from the pool is working.

Yes, in-between two of your posts, in response to one of yours.  Thanks for using the "reading" skill (/sarcasm)

https://bitcointalksearch.org/topic/m.11883061

Thirtybird: did you mention the new AMD GPUs?

I only just found out about these today when researching to find out what AMDs answer to HMC is.

The AMD R9 300 series with High-Bandwidth Memory (HBM)

My understanding is that these are only recently released and probably not tested with Yacoin yet. I might be able to run one of these in my current machine.
I would very well buy it for gaming and VR anyway but could also use it to mine some YAC.