Bitcoin Forum
November 23, 2017, 08:07:42 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 [149] 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 »
  Print  
Author Topic: [ANN][YAC] YACoin ongoing development  (Read 349326 times)
NineEleven
Full Member
***
Offline Offline

Activity: 181


View Profile WWW
July 07, 2015, 08:40:45 AM
 #2961

Sory but NOMP payouts just dont work

its seems a know bug for POW/POS hybryd coins


But i dont give up

move the instalation to MPOS

http://yac.erlog.pt


lte's see if it works
ate leas i can see now the coins on the wallet

http://jornalbitcoin.pt/ , Noticias em Portugues
1511424462
Hero Member
*
Offline Offline

Posts: 1511424462

View Profile Personal Message (Offline)

Ignore
1511424462
Reply with quote  #2

1511424462
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511424462
Hero Member
*
Offline Offline

Posts: 1511424462

View Profile Personal Message (Offline)

Ignore
1511424462
Reply with quote  #2

1511424462
Report to moderator
1511424462
Hero Member
*
Offline Offline

Posts: 1511424462

View Profile Personal Message (Offline)

Ignore
1511424462
Reply with quote  #2

1511424462
Report to moderator
1511424462
Hero Member
*
Offline Offline

Posts: 1511424462

View Profile Personal Message (Offline)

Ignore
1511424462
Reply with quote  #2

1511424462
Report to moderator
fredeq
Legendary
*
Online Online

Activity: 1270


View Profile WWW
July 07, 2015, 09:51:36 AM
 #2962

Sory but NOMP payouts just dont work

its seems a know bug for POW/POS hybryd coins


But i dont give up

move the instalation to MPOS

http://yac.erlog.pt


lte's see if it works
ate leas i can see now the coins on the wallet


MPOS is the way to go, good choice
Wish I had a dozen of miners to help you with hashing.

https://whattomine.com - Check what to mine Smiley
fredeq
Legendary
*
Online Online

Activity: 1270


View Profile WWW
July 07, 2015, 10:10:26 AM
 #2963

Takes forever though to get a first share with 2x750ti @ 200h/s.
There should be a way to tweak starting diff.

https://whattomine.com - Check what to mine Smiley
NineEleven
Full Member
***
Offline Offline

Activity: 181


View Profile WWW
July 07, 2015, 12:33:12 PM
 #2964

We found 12 blocks

all confirmed and then all orphan


http://jornalbitcoin.pt/ , Noticias em Portugues
NineEleven
Full Member
***
Offline Offline

Activity: 181


View Profile WWW
July 07, 2015, 12:37:27 PM
 #2965

Account   Address   Category   Amount   Confirmations   Transaction ID   Time
Default      Orphan   80.31000000   0   abb81bbb...b0f68ad6   07/07/2015 21:59:20
Default      Orphan   80.32000000   0   85ea81d5...086e3c35   07/07/2015 22:05:47
Default      Orphan   80.32000000   0   82cac963...0967fffc   07/07/2015 22:06:06
Default      Orphan   80.32000000   0   b9e272fd...4c619d55   07/07/2015 22:15:34
Default      Orphan   80.31000000   0   b57fb656...b48e44b3   07/07/2015 23:05:06
Default      Orphan   80.33000000   0   e2c9332d...ab8afde7   07/07/2015 23:30:39
Default      Orphan   80.31000000   0   75c56d3c...9d34a5e4   07/07/2015 23:53:21
Default      Orphan   80.33000000   0   0dd06231...ec98f7de   07/08/2015 00:01:44
Default      Orphan   80.33000000   0   86ba11af...5bf9bc46   07/08/2015 00:04:29
Default      Orphan   80.34000000   0   653a433d...8e7653d0   07/08/2015 00:12:17

http://jornalbitcoin.pt/ , Noticias em Portugues
old c coder
Sr. Member
****
Offline Offline

Activity: 252



View Profile
July 07, 2015, 08:25:40 PM
 #2966

Yacoin needs several issues fixed. I've already mentioned them to Joe and Groko, ane some bits I've posted here. My hope is to get larger audience onboard.



During past couple of months I've been analyzing the code, brainstorming and putting together blueprints for a solution.
It can not be done without hard fork, because of both -  first and last issue. Fix for small PoS blocks can be rolled out incrementally.
Currently I am analyzing fix for chaintrust issue, because it underlies solution for others.
I will let you know about details in a day or two.

This will not prevent miner with 51% from capturing the chain, but fix for last issue will force PoW miners to include PoS blocks and fix for first issue should make PoS blocks get higher trust value. Consequently block reorganizations should not get deep as now and stakeholders should get their power back.

Here are two drafts/outlines. Ask if something is not understandable.
And feel free to criticize or better suggest corrections and improvements:

fix trust
fix ignoring PoS blocks

And to those who have hijacked the chain: I am having thoughts about having block range validations hardcoded.
Are you aware that everything you PoW mine can be made nonspendable with next release. You greedy assholes. What are you, a bankers?
Hello Senj,

Not that I can understand the code Smiley, but what if, for some unusual reason, there is not one PoS block broadcast at  some minute(s), just after a PoW block or blocks have been broadcast.  I bolded the area in question above. Will all the miners have to wait for a PoS block?  Do we know that there are enough YACs out there to make a one (or two minute) stream of PoS blocks if all those wallets with YACs were minting?  Just thinking...

And isn't it curious about miners and Bitcoin!  Another well thought out change by those that knew that the miner's were cutting block verification corners for speed (means $).  You would've thought the developers could have predicted this and not let it happen?  Maybe they ain't so bright?  I'm sure that they will have well crafted slippery teflon phrases that offer protection for their hides.  I hear that some miners lost relatively big bucks.  Three blocks, is that 75 BTCs?

Ron

BTC: 1DPvP6WoZzaNQ9Nxzd64hjYad1kyQzTTbx YAC: Y3ZggXDvnRJaRwtVGyGJwt6DMLN3EPQpQf 
The day is coming when a single carrot, freshly observed, will set off a revolution.  Paul Cezanne
old c coder
Sr. Member
****
Offline Offline

Activity: 252



View Profile
July 07, 2015, 09:00:39 PM
 #2967

Hello Senj,

In your http://yacoin.net/NewPreventPosIgnore.htm section you ask:
Quote
The later would mean we need to recalculate those values on reorganize (and at some other times perhaps?), therefore it would be more complex to implement.

How about calculating the PoW/PoS or is it the other way, ratio by just counting at startup in the load the guts code (db.cpp -> CTxDB::LoadBlockIndexGuts()), that just plows through the blocks anyway!? There's this cryptic, at least to me, PPC code there anyway, that is:

// ppcoin: build setStakeSeen
                if (pindexNew->IsProofOfStake())
                    setStakeSeen.insert(make_pair(pindexNew->prevoutStake, pindexNew->nStakeTime));


Ron

BTC: 1DPvP6WoZzaNQ9Nxzd64hjYad1kyQzTTbx YAC: Y3ZggXDvnRJaRwtVGyGJwt6DMLN3EPQpQf 
The day is coming when a single carrot, freshly observed, will set off a revolution.  Paul Cezanne
senj
Member
**
Offline Offline

Activity: 118


View Profile
July 07, 2015, 09:10:43 PM
 #2968

Yacoin needs several issues fixed. I've already mentioned them to Joe and Groko, ane some bits I've posted here. My hope is to get larger audience onboard.



During past couple of months I've been analyzing the code, brainstorming and putting together blueprints for a solution.
It can not be done without hard fork, because of both -  first and last issue. Fix for small PoS blocks can be rolled out incrementally.
Currently I am analyzing fix for chaintrust issue, because it underlies solution for others.
I will let you know about details in a day or two.

This will not prevent miner with 51% from capturing the chain, but fix for last issue will force PoW miners to include PoS blocks and fix for first issue should make PoS blocks get higher trust value. Consequently block reorganizations should not get deep as now and stakeholders should get their power back.

Here are two drafts/outlines. Ask if something is not understandable.
And feel free to criticize or better suggest corrections and improvements:

fix trust
fix ignoring PoS blocks

And to those who have hijacked the chain: I am having thoughts about having block range validations hardcoded.
Are you aware that everything you PoW mine can be made nonspendable with next release. You greedy assholes. What are you, a bankers?
Hello Senj,

Not that I can understand the code Smiley, but what if, for some unusual reason, there is not one PoS block broadcast at  some minute(s), just after a PoW block or blocks have been broadcast.  I bolded the area in question above. Will all the miners have to wait for a PoS block?  Do we know that there are enough YACs out there to make a one (or two minute) stream of PoS blocks if all those wallets with YACs were minting?  Just thinking...

And isn't it curious about miners and Bitcoin!  Another well thought out change by those that knew that the miner's were cutting block verification corners for speed (means $).  You would've thought the developers could have predicted this and not let it happen?  Maybe they ain't so bright?  I'm sure that they will have well crafted slippery teflon phrases that offer protection for their hides.  I hear that some miners lost relatively big bucks.  Three blocks, is that 75 BTCs?

Ron

Here is the idea:
Let's say every 10th block on average is PoS. Once there are 9 PoW blocks one after another, PoW difficulty readjusts to two minute target. If another PoW block comes difficulty adjusts to 3 minutes. And so on. Beave reminded me (good catch Beave) that higher difficulty also affects PoW reward, that means whoever will insist on PoW only chain will have to work harder and also make less profit.
I will need to make refactoring of code - whenever that happens nActualSpacing in GetNextTargetRequired() will need to be set to "min( 60,nActualSpacing )", simulating blocks were max 1 minute apart. We would not want difficulty to drop because PoW blocks were intentionally pushed apart.
Perhaps even GetBlockTrust() will need to take that into account - if one mines PoW only chain too long it's difficulty will skyrocket, but his chaintrust must not.

EDIT - answer2:

In your http://yacoin.net/NewPreventPosIgnore.htm section you ask:
Quote
The later would mean we need to recalculate those values on reorganize (and at some other times perhaps?), therefore it would be more complex to implement.

How about calculating the PoW/PoS or is it the other way, ratio by just counting at startup in the load the guts code (db.cpp -> CTxDB::LoadBlockIndexGuts()), that just plows through the blocks anyway!? There's this cryptic, at least to me, PPC code there anyway, that is:

// ppcoin: build setStakeSeen
                if (pindexNew->IsProofOfStake())
                    setStakeSeen.insert(make_pair(pindexNew->prevoutStake, pindexNew->nStakeTime));


Ron

That get's called at startup. You also need to count PoS blocks while being online and minting or receiving new blocks. And what about that big painfull REORGANIZE when all PoS blocks get trashed?



YAC: YGZRDNuey8MnN6GHVR1x7D3UY5TjDz2HCL
old c coder
Sr. Member
****
Offline Offline

Activity: 252



View Profile
July 08, 2015, 04:11:25 AM
 #2969

Yacoin needs several issues fixed. I've already mentioned them to Joe and Groko, ane some bits I've posted here. My hope is to get larger audience onboard.



During past couple of months I've been analyzing the code, brainstorming and putting together blueprints for a solution.
It can not be done without hard fork, because of both -  first and last issue. Fix for small PoS blocks can be rolled out incrementally.
Currently I am analyzing fix for chaintrust issue, because it underlies solution for others.
I will let you know about details in a day or two.

This will not prevent miner with 51% from capturing the chain, but fix for last issue will force PoW miners to include PoS blocks and fix for first issue should make PoS blocks get higher trust value. Consequently block reorganizations should not get deep as now and stakeholders should get their power back.

Here are two drafts/outlines. Ask if something is not understandable.
And feel free to criticize or better suggest corrections and improvements:

fix trust
fix ignoring PoS blocks
...
...

Here is the idea:
Let's say every 10th block on average is PoS. Once there are 9 PoW blocks one after another, PoW difficulty readjusts to two minute target. If another PoW block comes difficulty adjusts to 3 minutes. And so on. Beave reminded me (good catch Beave) that higher difficulty also affects PoW reward, that means whoever will insist on PoW only chain will have to work harder and also make less profit.
I will need to make refactoring of code - whenever that happens nActualSpacing in GetNextTargetRequired() will need to be set to "min( 60,nActualSpacing )", simulating blocks were max 1 minute apart. We would not want difficulty to drop because PoW blocks were intentionally pushed apart.
Perhaps even GetBlockTrust() will need to take that into account - if one mines PoW only chain too long it's difficulty will skyrocket, but his chaintrust must not.

EDIT - answer2:

In your http://yacoin.net/NewPreventPosIgnore.htm section you ask:
Quote
The later would mean we need to recalculate those values on reorganize (and at some other times perhaps?), therefore it would be more complex to implement.

How about calculating the PoW/PoS or is it the other way, ratio by just counting at startup in the load the guts code (db.cpp -> CTxDB::LoadBlockIndexGuts()), that just plows through the blocks anyway!? There's this cryptic, at least to me, PPC code there anyway, that is:

// ppcoin: build setStakeSeen
                if (pindexNew->IsProofOfStake())
                    setStakeSeen.insert(make_pair(pindexNew->prevoutStake, pindexNew->nStakeTime));


Ron

That get's called at startup. You also need to count PoS blocks while being online and minting or receiving new blocks. And what about that big painfull REORGANIZE when all PoS blocks get trashed?
Hello Senj,

I just thought you were interested in the 1,129,123 blocks before Tue Jul 7 23:28:55 2015 EDT?  In addition to what for me will be future blocks.  I must have misunderstood your desire for some past block information?

In any event, when you say above,
Quote
Here is the idea:
Let's say every 10th block on average is PoS. Once there are 9 PoW blocks one after another, PoW difficulty readjusts to two minute target. If another PoW block comes difficulty adjusts to 3 minutes. And so on. Beave reminded me (good catch Beave) that higher difficulty also affects PoW reward, that means whoever will insist on PoW only chain will have to work harder and also make less profit.
I will need to make refactoring of code - whenever that happens nActualSpacing in GetNextTargetRequired() will need to be set to "min( 60,nActualSpacing )", simulating blocks were max 1 minute apart. We would not want difficulty to drop because PoW blocks were intentionally pushed apart.
Perhaps even GetBlockTrust() will need to take that into account - if one mines PoW only chain too long it's difficulty will skyrocket, but his chaintrust must not.

The average block period is being adjusted now according to the past actual block periods and the PoW difficulty is in some sense inversely related to the block period.  That is, short past periods get higher difficulty.  At least that is my impression?  This is to "smooth" out the block period "fluctuations" around the desired one minute average.
Now your statement:  PoW difficulty readjusts to two minute target  seems to be at odds with the overall desire of YAC to maintain a one minute average block period?


And the function min( 60,nActualSpacing) can be much less than one minute if nActualSpacing is?

And  We would not want difficulty to drop because PoW blocks were intentionally pushed apart.  Seems to be getting more and more difficult to do this modification, and hence be able to understand the side effects?  It seems one should look for a simpler approach, at least to start with, that won't have so many conflicting effects on the basic operation of the code.

Your first link on chain trust speaks of other coins using the chain length in considering/calculating the chain trust.  And YAC does not!  Perhaps we could take a page from NVC's book?  Isn't that what Joe is trying to do?  In any event,  I have no definition or even a clear idea what the terms chain trust and chain length are in the context above.  I would need good definitions in order to even be able to think about, much less opine on any solutions.

Ron

BTC: 1DPvP6WoZzaNQ9Nxzd64hjYad1kyQzTTbx YAC: Y3ZggXDvnRJaRwtVGyGJwt6DMLN3EPQpQf 
The day is coming when a single carrot, freshly observed, will set off a revolution.  Paul Cezanne
Beave162
Hero Member
*****
Offline Offline

Activity: 701



View Profile
July 08, 2015, 05:09:58 AM
 #2970

Here is the idea:
Let's say every 10th block on average is PoS. Once there are 9 PoW blocks one after another, PoW difficulty readjusts to two minute target. If another PoW block comes difficulty adjusts to 3 minutes. And so on. Beave reminded me (good catch Beave) that higher difficulty also affects PoW reward, that means whoever will insist on PoW only chain will have to work harder and also make less profit.
I will need to make refactoring of code - whenever that happens nActualSpacing in GetNextTargetRequired() will need to be set to "min( 60,nActualSpacing )", simulating blocks were max 1 minute apart. We would not want difficulty to drop because PoW blocks were intentionally pushed apart.
Perhaps even GetBlockTrust() will need to take that into account - if one mines PoW only chain too long it's difficulty will skyrocket, but his chaintrust must not.

A few thoughts...

I like the idea of 'forcing' (perhaps 'strongly incentivising' is a better way to put it) PoS to be included in the chain; meanwhile the no-consecutive-PoS-rule, in itself, protects PoW.

senj, when you say "work harder," you actually (practically) mean work longer as difficulty increases. That sounds like a great idea, but allowing the block rewards to decrease with increasing difficulty makes me cringe (refer to centralized manipulation point). At the same time, I'm wondering how drastic the block rewards would change. I also think to myself that it should never happen anyway because PoS should never be ignored.

I'm still confused on the ratio, and how it could be enforced. Reading previous conversations, sairon said the ratio is 10:1 PoW:PoS. What determines that? Can you make it 1:1? Should you make it 1:1? Obviously, I am very code illiterate.

senj, I admire how you look long-term and strategically as well. YACoin/Bitcoin is a system, and as is the case with every system, there will always be people trying to 'game' the system at the expense of others. I think we need to examine more what will happen long-term in terms of PoS...

I would love to maximize my PoS rewards as much as possible. It seems the best way to ensure I will get my 'interest' compounded optimally will be to consolidate all my coins on one input, so they stake right at the minimum of 30 days. There will be a risk for some doing that because if the price skyrockets, and one wants to sell even just a few coins, he will destroy a lot of coinage to do it, but he could miss the high price point (think Certificate of Deposit ladder). Either way, splitting my coins into as many inputs as possible will be best for the network but usually not best for my own self-interest. At the same time, the best of the network is in my own self-interest, and it seems we run into game theory's 'Prisoner's delemma' (https://en.wikipedia.org/wiki/Prisoner's_dilemma).

So how would we fix this issue of making sure PoS is healthy despite a possible opposing incentive to maximize profit. I'll throw out a crazy idea that would surely take advanced coding (although we do have Joe_Bauers, old c coder, senj, Groko): put limit on the amount of coins per input. The limit could be calculated based on the total coin supply. So assuming 60,000,000 YACoins (60,000,000/30 days/24 hours/60 minutes x 2), 2,777 YACoin would be the limit per input for PoS, and it would adjust as the total supply continues to rise, assuming 2 minutes per PoS block ideal. I'm sure I'm missing something that would make such a feature impossible, but please let me know!

Those are my ramblings for now...

YaCoin: YL5kf54wPPXKsXd5T18xCaNkyUsS1DgY7z 
BitCoin: 14PFbLyUdTyxZg3V8hnvj5VXkx3dhthmDj
NineEleven
Full Member
***
Offline Offline

Activity: 181


View Profile WWW
July 08, 2015, 07:57:54 AM
 #2971

I just to tel you that i finally get the pool right

Blocks are found , and accounted correctly

Unfortunately most of the orphan but thats another problem

It would be nice if the pool adress can go to the OP

Regards


http://jornalbitcoin.pt/ , Noticias em Portugues
senj
Member
**
Offline Offline

Activity: 118


View Profile
July 08, 2015, 08:08:49 AM
 #2972

...
I just thought you were interested in the 1,129,123 blocks before Tue Jul 7 23:28:55 2015 EDT?  In addition to what for me will be future blocks.  I must have misunderstood your desire for some past block information?

I wasn't thinking about throwing away that 1 million + blocks. I don't know how you got that idea.
But you shouldn't count on them, if chaintrust issue remains intact.


...
The average block period is being adjusted now according to the past actual block periods and the PoW difficulty is in some sense inversely related to the block period.  That is, short past periods get higher difficulty.  At least that is my impression?  This is to "smooth" out the block period "fluctuations" around the desired one minute average.
Now your statement:  PoW difficulty readjusts to two minute target  seems to be at odds with the overall desire of YAC to maintain a one minute average block period?

My primary goal is to fix critical issues. Another goal is to keep PoS blocks in the chain and have them spaced apart at 1 minute and if we need to occasionally increase PoW block spacing in order to achieve that -  I have no problems with that.

And the function min( 60,nActualSpacing) can be much less than one minute if nActualSpacing is?

Yes, if blocks get to close, we still need to raise difficulty.

And  We would not want difficulty to drop because PoW blocks were intentionally pushed apart.  Seems to be getting more and more difficult to do this modification, and hence be able to understand the side effects?  It seems one should look for a simpler approach, at least to start with, that won't have so many conflicting effects on the basic operation of the code.

We've had two simple solutions that did not work. I wouldn't want another one like that. Especially if it requires a hard fork.
Complexity should be addressed with revisions, testing and simulation. But if you have a simple solution and it doesn't come with major shortcomings, I would love to hear about it.

Your first link on chain trust speaks of other coins using the chain length in considering/calculating the chain trust.  And YAC does not!  Perhaps we could take a page from NVC's book?  Isn't that what Joe is trying to do?  In any event,  I have no definition or even a clear idea what the terms chain trust and chain length are in the context above.  I would need good definitions in order to even be able to think about, much less opine on any solutions.

Chain trust is sum of GetBlockTrust() values for each branch. Branch with highest chaintrust is the main one. Follow first link pointing to peercoin wiki in document mentioned.
NVC's solution is not so strong as I'd wish. They give hybrid chain more trust (and perhaps higher rewards too). Sairon also acknowledged that some time ago.

YAC: YGZRDNuey8MnN6GHVR1x7D3UY5TjDz2HCL
senj
Member
**
Offline Offline

Activity: 118


View Profile
July 08, 2015, 08:43:08 AM
 #2973

...
senj, when you say "work harder," you actually (practically) mean work longer as difficulty increases. That sounds like a great idea, but allowing the block rewards to decrease with increasing difficulty makes me cringe (refer to centralized manipulation point). At the same time, I'm wondering how drastic the block rewards would change. ...

We have block rewards decreasing with increased difficulty right now. That is how it works.
Rewards do not matter here. They are a side effect of fix. Chain that does not ignore PoS blocks will be most rewarded.

I'm still confused on the ratio, and how it could be enforced. Reading previous conversations, sairon said the ratio is 10:1 PoW:PoS. What determines that? Can you make it 1:1? Should you make it 1:1? Obviously, I am very code illiterate.

Did you not see my reply (in your messages):

As you can see, nbits value is directly set from GetNextTargetRequired function.


Looking at sources from peercoin, novacoin and original yacoin, you will notice similarity:

One parameter used differs though:

https://github.com/novacoin-project/novacoin/blob/master/src/main.cpp#L47
https://github.com/ppcoin/ppcoin/blob/master/src/main.h#L44
https://github.com/pocopoco/yacoin/blob/master/src/main.cpp#L42

I think sairon's mistake had to do with comments left from Novacoin source.

PoW difficulty after PoS block should fall back to "1 minute". My draft would probably need to be revised.






And while we are at confusion. I haven't received an answer to one of my previous questions. I wonder if anyone knows it:

Looking at code it seems that block reward calculation goes like the this:

Code:
nSubsidy = 100 / (diff ^ 1/6)

but wiki and other sites say it is like this:

Code:
nSubsidy = 25 / (diff ^ 1/6)

Here for example
https://yacoin.org/tech.html
http://coinwik.org/YaCoin
http://coinwiki.info/en/Yacoin


I can not figure out where did 25 came from. Can someone explain this or at least point me in right direction please?


As for the rest, soon I will put up my draft for fixing remaining security issue - small PoS blocks. In part it will resonate with what you write here.

YAC: YGZRDNuey8MnN6GHVR1x7D3UY5TjDz2HCL
NineEleven
Full Member
***
Offline Offline

Activity: 181


View Profile WWW
July 08, 2015, 06:01:10 PM
 #2974

in the last 4 hours
the orphan block disapear
Smiley

http://jornalbitcoin.pt/ , Noticias em Portugues
old c coder
Sr. Member
****
Offline Offline

Activity: 252



View Profile
July 08, 2015, 06:18:42 PM
 #2975

As you can see, nbits value is directly set from GetNextTargetRequired function.
Looking at sources from peercoin, novacoin and original yacoin, you will notice similarity:

One parameter used differs though:

https://github.com/novacoin-project/novacoin/blob/master/src/main.cpp#L47
https://github.com/ppcoin/ppcoin/blob/master/src/main.h#L44
https://github.com/pocopoco/yacoin/blob/master/src/main.cpp#L42

I think sairon's mistake had to do with comments left from Novacoin source.

PoW difficulty after PoS block should fall back to "1 minute". My draft would probably need to be revised.
And while we are at confusion. I haven't received an answer to one of my previous questions. I wonder if anyone knows it:
Looking at code it seems that block reward calculation goes like the this:
Code:
nSubsidy = 100 / (diff ^ 1/6)
but wiki and other sites say it is like this:
Code:
nSubsidy = 25 / (diff ^ 1/6)

Here for example
https://yacoin.org/tech.html
http://coinwik.org/YaCoin
http://coinwiki.info/en/Yacoin
I can not figure out where did 25 came from. Can someone explain this or at least point me in right direction please?
As for the rest, soon I will put up my draft for fixing remaining security issue - small PoS blocks. In part it will resonate with what you write here.
Hello Senj,

The "code"
Code:
nSubsidy = 100 / (diff ^ 1/6)
is seen in YAC 0.4.4 source, in main.cpp => GetProofOfWorkReward()

And it is Pseudo-code in a comment!  Nevertheless, it brings up points that I have made over and over again, for more than 30 years!

Whenever a MAGIC NUMBER (out of the blue, undocumented) appears in code, it brings understanding to a crashing halt.

Is it a REQUIRED value?  Is it ARBITRARY?  Is it DEPENDENT  upon some other value elsewhere in the program??  Is it a WILD ASS GUESS?

You get the idea.  Well, we have two (or three) in this pseudo code snippet!

Upon looking at the code (with the help of MSVC++ in Visual Studio) I found that the 100 actually was a constant!

There are literally hundreds of "naked" numbers in the YACoin (and Bitcoin  and all the others) sources.

Until every one is replaced by a MEANINGFUL name that truly represents what it is, no real understanding and improvement can come to this or any "open source" project, since the "open source" is so obfuscated by lack of clarity it is impossible to understand how the code is interrelated, etc. etc.

And it's worse.  Method/function names are so bad they may as well be numbers!  Ditto for properties/variables.

There has been no excuse for cryptic, short, vowel challenged, abbreviated names for classes, structures, methods, properties, etc. etc. since the 1980s, when memory and disk storage was expensive, and we had 32 character or less restrictions on names in C (back then).

Now students and adults today have studied from books and authors who came from that past and have perpetuated this ugliness of language in their books, and so it continues for another generation.

You shouldn't have to translate literally every word you see in a line of code, in your head, in order to understand it!  But the myth continues that that is how it must be.  I don't buy it, never have, never will.  In a commercial professional environment, one was required to write much clearer code.  And document it too!  Seems today, it is get it done fast, no documents, no nothing.

If you want to bring fresh eyes to a problem, the code must be clear, more clear, beyond clear.  No tricks, no assumptions...

The C++ compiler will optimize out everything anyway, so there is no point in trying to be "cute".

Here is the original:
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);
}
Study that for a while and notice that it raises more questions than it answers.  Long lines are stupid too, for many reasons.
Here is what I wrote for myself, in my MSVC++ project, and it is only a first pass:
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
    // 64 = 2 to the 6th power
   
    // A reasonably continuous curve is used to avoid shock to market
    // (nSubsidyLimit / nSubsidy) ** 6 == bnProofOfWorkLimit / bnTarget
    // what are these terms and how do they relate to the discussion, exactly??????
         
    //
    // Human readable form:
    //
    // nSubsidy = 100 / (diff ^ 1/6)

    // again, but worse!!!  Undefined magic numbers.  I think that 100 is the
    // maximum subsidy in COINs ???????????
    // diff is ??????????????
    // 1/6 is 0 if we are talking integer divide, so obviously we are not?????????????
    // So what are we talking???????????????????
    // is ^ from GWBASIC??????????????
    // Do we mean power?????????????????

    // even so, after all of that, what does this code below actually do?????????

    CBigNum
        bnLowerBound = CENT;            // this is 0.01 * COIN

    CBigNum
        bnUpperBound = bnSubsidyLimit;  // seems that this is just 100* COIN

    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);
}
I just formatted it so I could read it!!  Can you swear that that while loop, with a test in an if statement is doing what the comment says?  I can't!  I think it is doing more but I haven't analyzed it, yet.

I have said this, in many Bitcoin forums, and more, but my words do not resonate with people who don't care about communicating their coding ideas clearly.  They most probably never took any writing or English courses, and have never read Joel Spolsky Grin

Dismounting from high horse now...

Ron

BTC: 1DPvP6WoZzaNQ9Nxzd64hjYad1kyQzTTbx YAC: Y3ZggXDvnRJaRwtVGyGJwt6DMLN3EPQpQf 
The day is coming when a single carrot, freshly observed, will set off a revolution.  Paul Cezanne
Beave162
Hero Member
*****
Offline Offline

Activity: 701



View Profile
July 08, 2015, 08:07:26 PM
 #2976

We have block rewards decreasing with increased difficulty right now. That is how it works.
Rewards do not matter here. They are a side effect of fix. Chain that does not ignore PoS blocks will be most rewarded.

I'm not sure why you iterated something I already know, and you know I already know. You didn't address my concern, but that is ok. I'm still debating it in my head and hoping for others to opine...

I'm still confused on the ratio, and how it could be enforced. Reading previous conversations, sairon said the ratio is 10:1 PoW:PoS. What determines that? Can you make it 1:1? Should you make it 1:1? Obviously, I am very code illiterate.

Did you not see my reply (in your messages):

As you can see, nbits value is directly set from GetNextTargetRequired function.


Looking at sources from peercoin, novacoin and original yacoin, you will notice similarity:

One parameter used differs though:

https://github.com/novacoin-project/novacoin/blob/master/src/main.cpp#L47
https://github.com/ppcoin/ppcoin/blob/master/src/main.h#L44
https://github.com/pocopoco/yacoin/blob/master/src/main.cpp#L42

I think sairon's mistake had to do with comments left from Novacoin source.

PoW difficulty after PoS block should fall back to "1 minute". My draft would probably need to be revised.

I saw your reply, and I went through your links, but I still don't understand. Perhaps, someone else can explain in 'simpler' terms on this thread...

As for the rest, soon I will put up my draft for fixing remaining security issue - small PoS blocks. In part it will resonate with what you write here.

My point was not about small PoS blocks--the opposite really. But yes we can have that discussion at a later time.

Ron, I love your point.
Quote
There has been no excuse for cryptic, short, vowel challenged, abbreviated names for classes, structures, methods, properties, etc. etc. since the 1980s, when memory and disk storage was expensive, and we had 32 character or less restrictions on names in C (back then).

It reminds me of useless acronyms used in many organizations where some acronyms have more syllables than the original phrase, and there are acronyms that could mean different things in the same context. I know it gives some people a sense of confidence by sounding 'cool' or 'smart'. Really, it is often a sign of an arrogant lack of intelligence and inability to communicate. YACoin can be a leader in this area of more transparent code.

Anyway, hopefully we can get more opinions on senj's proposed changes, and I hopefully I can get answers to my questions...

YaCoin: YL5kf54wPPXKsXd5T18xCaNkyUsS1DgY7z 
BitCoin: 14PFbLyUdTyxZg3V8hnvj5VXkx3dhthmDj
senj
Member
**
Offline Offline

Activity: 118


View Profile
July 09, 2015, 07:24:43 AM
 #2977

...
If you want to bring fresh eyes to a problem, the code must be clear, more clear, beyond clear.  No tricks, no assumptions...
...

Ron, I share your frustrations regarding code readability. I guess you don't know where that 25 came from either:)
To find out what is going on, I help myself with wikis, forums, documentation sites, blogs, you name it ...

I am not sure it would be even possible to put all this information in code, but I agree 100% it should be more readable.
Perhaps one day someone brave will create libyacoin with design principles taken from libbitcoinSmiley


...
I'm not sure why you iterated something I already know, and you know I already know. ...
...

I misread your message. Sorry. I know now.

...
I saw your reply, and I went through your links, but I still don't understand. Perhaps, someone else can explain in 'simpler' terms on this thread...

That would be most welcome for all of us, and also for future yacoin developers. Perhaps I will put something together ....




YAC: YGZRDNuey8MnN6GHVR1x7D3UY5TjDz2HCL
Joe_Bauers
Hero Member
*****
Offline Offline

Activity: 783


GCVMMWH


View Profile
July 10, 2015, 02:16:25 AM
 #2978

Perhaps one day someone brave will create libyacoin with design principles taken from libbitcoinSmiley

Yes!  I actually spent an hour or two a while ago seeing how much work that would be Wink
 
Quote from: Beave162
Joe_Bauers, any update to the timeframe of the new wallet release?

Depends on all the items we're trying to work out over the past few pages.  There are 2 options as I see them. We could move to 0.4.5 now (soon) as it is, which is a refactoring to latest NovaCoin code, along with some enhancements that I added. As it moves us to LevelDB, it would require downloading the block-chain from 1, either doing the old fashioned way (this will take days!) or by downloading and importing a bootstrap.dat file that I would release. This will take about 12 hours. I've tested and run this client on the general network and it seems to work great. I did not test staking, and POW mining would need to be done using ThirtyBird's miner. Anyone not using this now anyway is losing out.  I would want some of you to test as well though, before releasing. Then for 0.4.6, we would have the hard fork required changes that Senj has proposed.   

Other option is to do everything for 0.4.5  This seems more risky to me, but is a little less of a pain I suppose because you get everything in one version.





alenevaa
Sr. Member
****
Offline Offline

Activity: 288



View Profile WWW
July 10, 2015, 07:52:12 AM
 #2979

I vote for step by step changes.

First - 0.4.5 release
Second - new version (0.5.1) with hard fork

██████████████████████
████████████████████████
████████████████████████
████████████████████████
███████████████████████
█████████████████████
████████████████████████
████████████████████████
██████████████████████
██████████████████████
███████████████████████
████████████████████████
████████████████████████
████████████████████████
███████████████████████
██████████████████████
|
WINGS           
Where DAO Unicorns are born
|
.
1st Bitcoin & Ethereum DAO for DAOs
1st Decentralized Chatbot to Smart Contracts Interaction System

|
.
Wings Bounties Earn Eggs
X-Blockchain DAO

Beave162
Hero Member
*****
Offline Offline

Activity: 701



View Profile
July 10, 2015, 09:07:46 AM
 #2980

It's just a different kind of distribution.

YACoin is not widely used, it is still in distribution stage.

The issue as I see it is, someone with a LOT of resources is mining the shit out of YAC to make a profit.

Rewards do not matter here. They are a side effect of fix.

There is a recurring theme with these comments, and I agree with it. The block reward is meaningful only under the assumption of having value.

The changes/fork can be looked at, in one way, as a fresh release with a ~60M YACoin premine. The block reward structure may vary but only because of the tie to difficulty. I believe the reward aspect is insignificant--as implied by the comments quoted above--and is indeed an side effect as you said, senj.

The way I understand it, this fix of senj's will encourage those who are 'mining' to also be 'minting', and I think that is key for a PoW/PoS hybrid system.

If there isn't a release for the wallet soon, I'm afraid the price will continue to drop. But for what it's worth, my opinion is to do whatever makes senj's fixes happen quickest, which may be 'Option 2'. The issue with PoS inputs (small, large, whatever) can be fixed later as I don't think it will be a significant problem in the immediate future.

YaCoin: YL5kf54wPPXKsXd5T18xCaNkyUsS1DgY7z 
BitCoin: 14PFbLyUdTyxZg3V8hnvj5VXkx3dhthmDj
Pages: « 1 ... 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 [149] 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!