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
Topic: [ANN][YAC] YACoin ongoing development - page 32. (Read 379983 times)
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.
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 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.
- Flawed chaintrust calculation
- PoS blocks with small stake posing security risk
- PoW miners ignoring PoS blocks to maximize profits (also happening right now)
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:
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
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?
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.
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
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.
- Flawed chaintrust calculation
- PoS blocks with small stake posing security risk
- PoW miners ignoring PoS blocks to maximize profits (also happening right now)
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?
Not that I can understand the code
, 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:
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
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,
In your http://yacoin.net/NewPreventPosIgnore.htm section you ask:
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
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
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.
- Flawed chaintrust calculation
- PoS blocks with small stake posing security risk
- PoW miners ignoring PoS blocks to maximize profits (also happening right now)
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?
Not that I can understand the code
, 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
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
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
We found 12 blocks
all confirmed and then all orphan
all confirmed and then all orphan
Takes forever though to get a first share with 2x750ti @ 200h/s.
There should be a way to tweak starting diff.
There should be a way to tweak starting diff.
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
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.
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
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
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.
- Flawed chaintrust calculation
- PoS blocks with small stake posing security risk
- PoW miners ignoring PoS blocks to maximize profits (also happening right now)
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?
Guess what!
Bitcoin chain fork. I was just talking about the possibility a few days ago
https://bitcointalksearch.org/topic/blockchain-split-of-4-july-2015-1108304
Bitcoin chain fork. I was just talking about the possibility a few days ago
https://bitcointalksearch.org/topic/blockchain-split-of-4-july-2015-1108304
Glad you pointed that out...
http://www.reddit.com/r/Bitcoin/comments/3c2cfd/psa_f2pool_is_mining_invalid_blocks/
"A large % of the hashing power (not just f2pool) is was "SPV mining" where they mine on top of headers from blocks that they haven't actually verified. They do this because in most cases you earn more money doing it - latency matters a lot and even 1MB blocks take long enough to propagate that you lose a significant amount of money by waiting for full propagation."
Could I say SPV is a blockchain trust issue? Could I say senj's idea to fix it addresses a similar problem? So it seems that even bitcoin, with a 10 minute block time, is (was) vulnerable to the problems that I have previously mentioned regarding time to propagate through the network and selfish mining.
I believe the second issue is the risk of hard forks. The biggest support of scrypt-chacha, in terms of resources, seems to come from Chinese-speaking people. We hope they will monitor yacoin.org. A new wallet can be released here, but nothing really ensures that the exchanges, the miners, the stakers will update their wallets. That is why any discussions, opinions, consensus matters. It is why there needs to be a REALLY good reason for a hard fork.
Luckily, the new wallet has some absolutely amazing features, which will have people wanting to update their wallets for that reason alone. It also helps that YAC has attracted the best and brightest people even in supporting functions: fredeq, Groko looks to have already fixed the explorer. And in case someone didn't already know, fredeq runs the very best mining profitability site in existence whattomine.com. And we already know how amazing feeleep has been operating the long-running pool coinmine.pl. I think most will be all over a new wallet version.
Joe_Bauers, any update to the timeframe of the new wallet release?
I think i found the pool problem
we found this block
http://explore.grokonet.com/?txnhash=25ce8378e5cbc99992d1a7ca13bcc5a8ae6bed31f25f5f7ff9e4850a73da9780
00000294ef0b472ba0b306ed7f5840bca810894713baa33d8f8d2836673d6d89
{
"txid" : "25ce8378e5cbc99992d1a7ca13bcc5a8ae6bed31f25f5f7ff9e4850a73da9780",
"vin" : [
{
"coinbase" : "03013311062f503253482f04ad3e9a550827fffff0000000000d2f6e6f64655374726174756d2f"
}
],
"vout" : [
{
"value" : 78.28780000,
"n" : 0,
"scriptPubKey" : {
"addresses" : [
"YLURyDUfPowAgDnvuFnkXA1PxTNPqWQGWU"
]
}
},
{
"value" : 1.19220000,
"n" : 1,
"scriptPubKey" : {
"addresses" : [
"YEFnVt3f6YTtYyxEVEJFx2NUNri9UsZGpL"
]
}
}
],
"blockhash" : "00000294ef0b472ba0b306ed7f5840bca810894713baa33d8f8d2836673d6d89",
"confirmations" : 297,
"time" : "07/06/15 08:39:09"
}
as you can see there are two transactions
one to the address and the other to thee fee adress
nopm gives this error
2015-07-06 09:39:24 [Pool] [yacoin] (Thread 1) We thought a block was found but it was rejected by the daemon, share data: {"job":"11","ip":"10.0.21.233","port":3032,"worker":"YKL5qhpF6e9ZW7HWkD7TpVZ1NAYFstpxmH","height":1127169,"blockReward":79480000,"difficulty":1,"shareDiff":"99.15517014","blockDiff":63.472861184,"blockDiffActual":0.000968519,"blockHash":"cc383a2b2bb74a0800ab038ef9c60fe8f5852ffabd59fae0e0299d96e1ae7857"}
if i read the code correctly
nom is tring to verify a diferent blockhas then the one tat wass accepted
is this possible? how? why?
i receceived both transaction
on the mining wallet
and on my personal wallet ( the fee)
any clues?
we found this block
http://explore.grokonet.com/?txnhash=25ce8378e5cbc99992d1a7ca13bcc5a8ae6bed31f25f5f7ff9e4850a73da9780
00000294ef0b472ba0b306ed7f5840bca810894713baa33d8f8d2836673d6d89
{
"txid" : "25ce8378e5cbc99992d1a7ca13bcc5a8ae6bed31f25f5f7ff9e4850a73da9780",
"vin" : [
{
"coinbase" : "03013311062f503253482f04ad3e9a550827fffff0000000000d2f6e6f64655374726174756d2f"
}
],
"vout" : [
{
"value" : 78.28780000,
"n" : 0,
"scriptPubKey" : {
"addresses" : [
"YLURyDUfPowAgDnvuFnkXA1PxTNPqWQGWU"
]
}
},
{
"value" : 1.19220000,
"n" : 1,
"scriptPubKey" : {
"addresses" : [
"YEFnVt3f6YTtYyxEVEJFx2NUNri9UsZGpL"
]
}
}
],
"blockhash" : "00000294ef0b472ba0b306ed7f5840bca810894713baa33d8f8d2836673d6d89",
"confirmations" : 297,
"time" : "07/06/15 08:39:09"
}
as you can see there are two transactions
one to the address and the other to thee fee adress
nopm gives this error
2015-07-06 09:39:24 [Pool] [yacoin] (Thread 1) We thought a block was found but it was rejected by the daemon, share data: {"job":"11","ip":"10.0.21.233","port":3032,"worker":"YKL5qhpF6e9ZW7HWkD7TpVZ1NAYFstpxmH","height":1127169,"blockReward":79480000,"difficulty":1,"shareDiff":"99.15517014","blockDiff":63.472861184,"blockDiffActual":0.000968519,"blockHash":"cc383a2b2bb74a0800ab038ef9c60fe8f5852ffabd59fae0e0299d96e1ae7857"}
if i read the code correctly
nom is tring to verify a diferent blockhas then the one tat wass accepted
is this possible? how? why?
i receceived both transaction
on the mining wallet
and on my personal wallet ( the fee)
any clues?
I send the few coins confirmed to miners found on teh console log
I have manually calculated the proportion and send then.
Still wue are founding blocks but nomp logs this
2015-07-06 09:50:31 [Pool] [yacoin] (Thread 4) We thought a block was found but it was rejected by the daemon, share data: {"job":"5","ip":"91.154.39.160","port":3032,"worker":"Y16jSqBD95tCGBWurYfdchFPSy6PKaPWp9","height":1127185,"blockReward":79480000,"difficulty":1,"shareDiff":"79.61784448","blockDiff":63.47096064,"blockDiffActual":0.00096849,"blockHash":"cfdbf925c3c3b2d2b489ea255e044b956181551f484cfa6c4cd0068f73c2f5f8"}
i-m getting crazy whit this
I have manually calculated the proportion and send then.
Still wue are founding blocks but nomp logs this
2015-07-06 09:50:31 [Pool] [yacoin] (Thread 4) We thought a block was found but it was rejected by the daemon, share data: {"job":"5","ip":"91.154.39.160","port":3032,"worker":"Y16jSqBD95tCGBWurYfdchFPSy6PKaPWp9","height":1127185,"blockReward":79480000,"difficulty":1,"shareDiff":"79.61784448","blockDiff":63.47096064,"blockDiffActual":0.00096849,"blockHash":"cfdbf925c3c3b2d2b489ea255e044b956181551f484cfa6c4cd0068f73c2f5f8"}
i-m getting crazy whit this
Again, did you check yacoin daemon debug.log?
I have to suspend YAC for now, cant find any stats source.
Was scraping grokos explorer, but it went down
Was scraping grokos explorer, but it went down
Guess what!
Bitcoin chain fork. I was just talking about the possibility a few days ago
https://bitcointalksearch.org/topic/blockchain-split-of-4-july-2015-1108304
Seems like my increasing rewards idea just got a lot better.
Bitcoin chain fork. I was just talking about the possibility a few days ago
https://bitcointalksearch.org/topic/blockchain-split-of-4-july-2015-1108304
Seems like my increasing rewards idea just got a lot better.
I send the few coins confirmed to miners found on teh console log
I have manually calculated the proportion and send then.
Still wue are founding blocks but nomp logs this
2015-07-06 09:50:31 [Pool] [yacoin] (Thread 4) We thought a block was found but it was rejected by the daemon, share data: {"job":"5","ip":"91.154.39.160","port":3032,"worker":"Y16jSqBD95tCGBWurYfdchFPSy6PKaPWp9","height":1127185,"blockReward":79480000,"difficulty":1,"shareDiff":"79.61784448","blockDiff":63.47096064,"blockDiffActual":0.00096849,"blockHash":"cfdbf925c3c3b2d2b489ea255e044b956181551f484cfa6c4cd0068f73c2f5f8"}
i-m getting crazy whit this
I have manually calculated the proportion and send then.
Still wue are founding blocks but nomp logs this
2015-07-06 09:50:31 [Pool] [yacoin] (Thread 4) We thought a block was found but it was rejected by the daemon, share data: {"job":"5","ip":"91.154.39.160","port":3032,"worker":"Y16jSqBD95tCGBWurYfdchFPSy6PKaPWp9","height":1127185,"blockReward":79480000,"difficulty":1,"shareDiff":"79.61784448","blockDiff":63.47096064,"blockDiffActual":0.00096849,"blockHash":"cfdbf925c3c3b2d2b489ea255e044b956181551f484cfa6c4cd0068f73c2f5f8"}
i-m getting crazy whit this
was not translated very well, so I will be more clear:
Why not be part of the Yacoin dev effort instead? == Assuming that you have some coding skills to work on another coin, since you seem to have an interest in Yacoin, why not use your presumed talents to assist in the community Yacoin development effort, rather than be like everyone else and start your own pump/dump coin to make a quick profit?
Does that clear things up at all?
Why not be part of the Yacoin dev effort instead? == Assuming that you have some coding skills to work on another coin, since you seem to have an interest in Yacoin, why not use your presumed talents to assist in the community Yacoin development effort, rather than be like everyone else and start your own pump/dump coin to make a quick profit?
Does that clear things up at all?
to begin with, how is yac not a pump and dump? no usefulness whatsoever.
I did give you the solution to your problem, you don't want to hear it.
case closed
was not translated very well, so I will be more clear:
Why not be part of the Yacoin dev effort instead? == Assuming that you have some coding skills to work on another coin, since you seem to have an interest in Yacoin, why not use your presumed talents to assist in the community Yacoin development effort, rather than be like everyone else and start your own pump/dump coin to make a quick profit?
Does that clear things up at all?
Why not be part of the Yacoin dev effort instead? == Assuming that you have some coding skills to work on another coin, since you seem to have an interest in Yacoin, why not use your presumed talents to assist in the community Yacoin development effort, rather than be like everyone else and start your own pump/dump coin to make a quick profit?
Does that clear things up at all?
Joe_Bauers,
I assumed that's what you meant.
I think everyone involved with YAC understands my point about centralized manipulation.
Since the beginning of YACoin, over two years ago, the algorithm hasn't changed, the NFactor schedule hasn't changed, the block rewards haven't changed. It is amazing really considering the drastic impact the NFactor changes had on the marketcap, price in the beginning. That really means a lot to me, and I believe it will mean a lot to potential investors. How many other coins--which have been around over two years, still has an active 'community', and has seen the kinds of lows that YAC has had--can say that? I love that most people here recognize a low (relative) price as a great opportunity to buy and to get involved as opposed to a reason to make fundamental changes. I'll remind people the price is up 6 times what it was only a few months ago.
The future of YACoin is looking very bright to say the least.
Jump to: