nanoprobe
Legendary
Offline
Activity: 980
Merit: 1000
Traveling in subspace
|
|
August 30, 2014, 12:56:10 AM |
|
strange it would say nothing in your log file.. did you look inside the log ? If it was orphaned it woudl say so eh..
Maybe I'm not looking in the right place. Are you looking for entries from the wallet debug log? If so it says accepted for that block. SetBestChain: new best=00000000008c01d090f258fbf20a420b29c94af201df3f298e2d522d01d5a2d4 height=668624 trust=52571696031737616 date=8/29/2014 21:24:02 Stake checkpoint: 653cb568 ProcessBlock: ACCEPTED
|
You'll never know what you're living for until you know what you're willing to die for. Never look back, something might be gaining on you.
|
|
|
coinits
Legendary
Offline
Activity: 1582
Merit: 1019
011110000110110101110010
|
|
August 30, 2014, 01:05:01 AM |
|
strange it would say nothing in your log file.. did you look inside the log ? If it was orphaned it woudl say so eh..
Maybe I'm not looking in the right place. Are you looking for entries from the wallet debug log? If so it says accepted for that block. SetBestChain: new best=00000000008c01d090f258fbf20a420b29c94af201df3f298e2d522d01d5a2d4 height=668624 trust=52571696031737616 date=8/29/2014 21:24:02 Stake checkpoint: 653cb568 ProcessBlock: ACCEPTEDWhat is in your conf file? No * references is there?
|
Jump you fuckers! | The thing about smart motherfuckers is they sound like crazy motherfuckers to dumb motherfuckers. | My sig space for rent for 0.01 btc per week.
|
|
|
nanoprobe
Legendary
Offline
Activity: 980
Merit: 1000
Traveling in subspace
|
|
August 30, 2014, 11:54:16 AM |
|
strange it would say nothing in your log file.. did you look inside the log ? If it was orphaned it woudl say so eh..
Maybe I'm not looking in the right place. Are you looking for entries from the wallet debug log? If so it says accepted for that block. SetBestChain: new best=00000000008c01d090f258fbf20a420b29c94af201df3f298e2d522d01d5a2d4 height=668624 trust=52571696031737616 date=8/29/2014 21:24:02 Stake checkpoint: 653cb568 ProcessBlock: ACCEPTEDWhat is in your conf file? No * references is there? Here's my conf file server=1 listen=1 daemon=1 gen=0 connection=1 maxconnections=6 rpcconnect=127.0.0.1 rpcuser=user rpcpassword=password rpcallowip=192.168.1.70 rpcport=15372 port=15371 maxconnections=6 addnode=90.155.222.162 addnode=66.176.62.63 addnode=93.233.79.195 addnode=98.193.2.154 addnode=5.250.177.28 addnode=24.13.164.246 addnode=74.90.54.187 addnode=76.168.111.3 addnode=110.255.149.5 addnode=85.102.226.187 addnode=46.39.240.53 addnode=154.20.19.46 addnode=186.59.181.76 addnode=74.33.230.204 addnode=107.202.133.56 addnode=75.150.145.65
|
You'll never know what you're living for until you know what you're willing to die for. Never look back, something might be gaining on you.
|
|
|
bee7
|
|
August 30, 2014, 12:04:20 PM |
|
@nanoprobe
your block have been orphaned by the PoS block as PoS blocks have more trust weight. Look into the log file: a few lines later you should see something like REORGANIZE: disconnect bla-bla-bla
|
|
|
|
nanoprobe
Legendary
Offline
Activity: 980
Merit: 1000
Traveling in subspace
|
|
August 30, 2014, 12:11:50 PM Last edit: August 30, 2014, 12:30:16 PM by nanoprobe |
|
@nanoprobe
your block have been orphaned by the PoS block as PoS blocks have more trust weight. Look into the log file: a few lines later you should see something like REORGANIZE: disconnect bla-bla-bla
It's there. Crap. Does this happen a lot? If so I'm not going to bother with the solo mining. Thanks for showing me what to look for. EDIT: I scrolled through the log file from the point of the block I found that was orphaned by PoS and found 10 more of the same kind of entries. Does that mean I found 10 more that were orphaned or is that from the entire network?
|
You'll never know what you're living for until you know what you're willing to die for. Never look back, something might be gaining on you.
|
|
|
see360
Member
Offline
Activity: 91
Merit: 10
|
|
August 30, 2014, 12:48:09 PM |
|
@nanoprobe
your block have been orphaned by the PoS block as PoS blocks have more trust weight. Look into the log file: a few lines later you should see something like REORGANIZE: disconnect bla-bla-bla
It's there. Crap. Does this happen a lot? If so I'm not going to bother with the solo mining. Orphans happen with any coin you mine. For example, even a large pool like 1gh.com shows 3 orphans on maxcoin right now. That might change by the time you check this, but orphans are a part of mining. Remember this, any time you hit a block that becomes part of the chain, there is a good chance that someone else submitted even moments before you that eventually became orphaned. I get an orphan block with JPC about every fourth block, which is a lot higher than for some coins, but I know that lots of others are having the same thing happen, so I figure it all averages out to me getting a fair share as a percentage of the total mining hash rate in the end.
|
|
|
|
Spoetnik
Legendary
Offline
Activity: 1540
Merit: 1011
FUD Philanthropist™
|
|
August 30, 2014, 03:58:46 PM |
|
you should be able to search for the keyword ORPHAN in the log file too (with a text editor) i don't care though.. i don't look 99% of the time. orphans happen there has been some random strangers popping up here randomly implying there is something broken on this coin i think just to stir up some drama and troll which has caused some people to go looking for a problem when none exists.. at least as far as i can tell.. i would advise people watch out for clever trolling from people who pop out of no where. the only guys who keep doing this here on this topic are not known to us and show up and say some shit and run off.. then a new account name comes along trying again.. almost on every page.. trying to FUD it up i guess. So i am saying listen to the guys who have been on this coin from day 1 (there is lots of us that have been here since the start on this coin) Although i am no coin networking pro.. i barley understand how POS works
|
FUD first & ask questions later™
|
|
|
antonio8
Legendary
Offline
Activity: 1400
Merit: 1000
|
|
August 30, 2014, 05:47:21 PM |
|
Is it just me or why does the 1.5 wallet take forever to load?
Also why does whenever I click on anything in the wallet it goes "not responsive" for minutes before becoming responsive again?
|
If you are going to leave your BTC on an exchange please send it to this address instead 1GH3ub3UUHbU5qDJW5u3E9jZ96ZEmzaXtG, I will at least use the money better than someone who steals it from the exchange. Thanks
|
|
|
bee7
|
|
August 30, 2014, 08:06:40 PM |
|
you should be able to search for the keyword ORPHAN in the log file too (with a text editor) i don't care though.. i don't look 99% of the time. orphans happen there has been some random strangers popping up here randomly implying there is something broken on this coin i think just to stir up some drama and troll which has caused some people to go looking for a problem when none exists.. at least as far as i can tell.. i would advise people watch out for clever trolling from people who pop out of no where. the only guys who keep doing this here on this topic are not known to us and show up and say some shit and run off.. then a new account name comes along trying again.. almost on every page.. trying to FUD it up i guess. So i am saying listen to the guys who have been on this coin from day 1 (there is lots of us that have been here since the start on this coin) Although i am no coin networking pro.. i barley understand how POS works The blocks that are reported as ORPHAN in the log file are the blocks that received from network and have no predecessor in the wallet's current block tree. The mined block may never be marked as orphan at submission time as it is constructed using previous block that exist in the wallet's block tree. In the best case it is SetBestChain'ed. Some times, when another block of the same height arrives before its submission it is just ACCEPTED. In the latter case most likely it never become a part of best chain as there are more chances that the already broadcast block gets its descendant earlier than your own block. Even when block is set as best chain at submission time there are chances that it may become aside chain when there is another block at the same height get an descendant faster, or when this another block has more trust weight as PoS block in PoW/PoS coins. As for your last comment, I hope you meant not me.
|
|
|
|
coinits
Legendary
Offline
Activity: 1582
Merit: 1019
011110000110110101110010
|
|
August 30, 2014, 08:19:40 PM |
|
you should be able to search for the keyword ORPHAN in the log file too (with a text editor) i don't care though.. i don't look 99% of the time. orphans happen there has been some random strangers popping up here randomly implying there is something broken on this coin i think just to stir up some drama and troll which has caused some people to go looking for a problem when none exists.. at least as far as i can tell.. i would advise people watch out for clever trolling from people who pop out of no where. the only guys who keep doing this here on this topic are not known to us and show up and say some shit and run off.. then a new account name comes along trying again.. almost on every page.. trying to FUD it up i guess. So i am saying listen to the guys who have been on this coin from day 1 (there is lots of us that have been here since the start on this coin) Although i am no coin networking pro.. i barley understand how POS works The blocks that are reported as ORPHAN in the log file are the blocks that received from network and have no predecessor in the wallet's current block tree. The mined block may never be marked as orphan at submission time as it is constructed using previous block that exist in the wallet's block tree. In the best case it is SetBestChain'ed. Some times, when another block of the same height arrives before its submission it is just ACCEPTED. In the latter case most likely it never become a part of best chain as there are more chances that the already broadcast block gets its descendant earlier than your own block. Even when block is set as best chain at submission time there are chances that it may become aside chain when there is another block at the same height get an descendant faster, or when this another block has more trust weight as PoS block in PoW/PoS coins. As for your last comment, I hope you meant not me.Don't worry. He spends a lot of time trolling everyone else calling them trolls. There is always the ignore button. As for your explanation...Thanks that explains a lot. I had the same thing happen to me without any indication of orphan (with another coin).
|
Jump you fuckers! | The thing about smart motherfuckers is they sound like crazy motherfuckers to dumb motherfuckers. | My sig space for rent for 0.01 btc per week.
|
|
|
bigreddmachine
|
|
August 31, 2014, 04:27:28 PM |
|
you should be able to search for the keyword ORPHAN in the log file too (with a text editor) i don't care though.. i don't look 99% of the time. orphans happen there has been some random strangers popping up here randomly implying there is something broken on this coin i think just to stir up some drama and troll which has caused some people to go looking for a problem when none exists.. at least as far as i can tell.. i would advise people watch out for clever trolling from people who pop out of no where. the only guys who keep doing this here on this topic are not known to us and show up and say some shit and run off.. then a new account name comes along trying again.. almost on every page.. trying to FUD it up i guess. So i am saying listen to the guys who have been on this coin from day 1 (there is lots of us that have been here since the start on this coin) Although i am no coin networking pro.. i barley understand how POS works The blocks that are reported as ORPHAN in the log file are the blocks that received from network and have no predecessor in the wallet's current block tree. The mined block may never be marked as orphan at submission time as it is constructed using previous block that exist in the wallet's block tree. In the best case it is SetBestChain'ed. Some times, when another block of the same height arrives before its submission it is just ACCEPTED. In the latter case most likely it never become a part of best chain as there are more chances that the already broadcast block gets its descendant earlier than your own block. Even when block is set as best chain at submission time there are chances that it may become aside chain when there is another block at the same height get an descendant faster, or when this another block has more trust weight as PoS block in PoW/PoS coins. As for your last comment, I hope you meant not me. He might have meant me a few days ago, though I certainly wasn't trying to troll... I asked two questions that were just flat out ignored, I guess because I was "trolling". I really was just trying to do due diligence on this coin because I had only just started looking into it, and wanted some clarification about a couple points...
|
|
|
|
Litoshi
|
|
August 31, 2014, 05:56:40 PM |
|
Bigredmachine:
To answer your question about 20 second block times producing more orphans than 60 second blocks:
The main cause of orphans is when two miners find the solution at the same time. Both miners then proceed to the next block, but one is now on a fork. This happens even if the block time is 20 minutes. The more numerous the blocks, the more numerous the orphans.
If there was only one pool mining a coin, and all the miners were on that pool, there would not be any orphans at all. But since there are several pools, and many solo miners, the chance of simultaneous solutions increases geometrically.
The reason for the short block times here, is to get more coins out there. There is no limit to the number of JPC coins. JPC has a 120 second block time
|
|
|
|
bigreddmachine
|
|
August 31, 2014, 06:18:03 PM |
|
Bigredmachine:
To answer your question about 20 second block times producing more orphans than 60 second blocks:
The main cause of orphans is when two miners find the solution at the same time. Both miners then proceed to the next block, but one is now on a fork. This happens even if the block time is 20 minutes. The more numerous the blocks, the more numerous the orphans.
If there was only one pool mining a coin, and all the miners were on that pool, there would not be any orphans at all. But since there are several pools, and many solo miners, the chance of simultaneous solutions increases geometrically.
The reason for the short block times here, is to get more coins out there. There is no limit to the number of JPC coins. JPC has a 120 second block time
Thanks for the reply! To clarify about orphans, what I meant by shorter times causing more orphans is this: - After a block is found, a non-negligible amount of time is spent propagating that block to all the nodes in the network.
- Assuming that this takes 5 seconds (my understanding is that it is closer to 10-12 seconds), 25% of a 20 second block time is spent without knowledge that the previous block has been found. If a block with the same height as the not-yet-known block is found during this small time, it will be orphaned (and rightfully so).
- This small time spent syncing the network is roughly the same regardless of block times.
- Again assuming 5 seconds to sync the network, a 60 second block time would have ~8% of the time spent searching by nodes occur during this sync-up time, and 92% of the time spent searching be useful time spent. A 2.5 minute block time would mean ~3% is wasted.
- In essence, as block time is decreased, the number of Orphans/Share is increased.
My questions then I suppose were really these (again, I am genuinely interested in an asnwer, and not trying to FUD): - What are the repercussions of the much higher rate of orphans? Are there repercussions?
- Can this result in more transactions being voided?
- And finally, since all PoS implementations rely on centralized checkpointing, this means that the operator of the central checkpoint and those nodes closest to that central checkpoint are able to sync much faster than other nodes. What advantages does this give to those nodes in terms of # of Orphans compared to slower-to-sync nodes farther away?
|
|
|
|
Dogeballs
Newbie
Offline
Activity: 18
Merit: 0
|
|
August 31, 2014, 07:09:59 PM |
|
Football season is in full effect...can we get some big sports betting site to start accepting jpc. We have gone down ever since it hit Mintpal...staking is not even an option with the insane network weight. We need to get something moving even if it means gambling my coins away doing what I like.
|
|
|
|
Spoetnik
Legendary
Offline
Activity: 1540
Merit: 1011
FUD Philanthropist™
|
|
August 31, 2014, 08:25:03 PM |
|
Football season is in full effect...can we get some big sports betting site to start accepting jpc. We have gone down ever since it hit Mintpal...staking is not even an option with the insane network weight. We need to get something moving even if it means gambling my coins away doing what I like.
ya not a bad idea ! i am still staking anyway but not getting very much also thanks for the detailed replies on how the POS works it all helps lol i have looked at working with miners but never even compiled a wallet before.. this shit is complicated under the hood i think
|
FUD first & ask questions later™
|
|
|
bee7
|
|
August 31, 2014, 08:34:11 PM |
|
this shit is complicated under the hood i think Not really. If you managed to build miners, then you definitely should succeed to build a wallet yourself.
|
|
|
|
see360
Member
Offline
Activity: 91
Merit: 10
|
|
August 31, 2014, 09:30:06 PM |
|
My questions then I suppose were really these (again, I am genuinely interested in an asnwer, and not trying to FUD): - What are the repercussions of the much higher rate of orphans? Are there repercussions?
- Can this result in more transactions being voided?
- And finally, since all PoS implementations rely on centralized checkpointing, this means that the operator of the central checkpoint and those nodes closest to that central checkpoint are able to sync much faster than other nodes. What advantages does this give to those nodes in terms of # of Orphans compared to slower-to-sync nodes farther away?
Repercussions... I'm no expert, I'm just a small amateur miner, but I think: 1. higher orphan rate is shared equally by all JPC miners if the network is balanced, so no one miner is at a disadvantage. The orphan rate might be increasingly unfair if one miner has over half the network hashrate, but then there's a bigger concern that all coins have in this scenario. 2. In my experience with over 100 JPC transactions, I have never had a send/receive transaction voided, but I do get a high orphan rate, which is different from voided transactions. Both the orphaned block and the accepted block that goes into the block chain in its place should have the same transactions, just a different block got the privilege of being recognized by the network. 3. I must have a misunderstanding of the PoS implementation if there is centralized checkpointing. Maybe someone else could address this question. In practice the short target block time intervals have resulted in extremely fast transactions (confirmations).
|
|
|
|
bee7
|
|
September 01, 2014, 12:10:10 AM |
|
My questions then I suppose were really these (again, I am genuinely interested in an asnwer, and not trying to FUD): - What are the repercussions of the much higher rate of orphans? Are there repercussions?
- Can this result in more transactions being voided?
- And finally, since all PoS implementations rely on centralized checkpointing, this means that the operator of the central checkpoint and those nodes closest to that central checkpoint are able to sync much faster than other nodes. What advantages does this give to those nodes in terms of # of Orphans compared to slower-to-sync nodes farther away?
Repercussions... I'm no expert, I'm just a small amateur miner, but I think: 1. higher orphan rate is shared equally by all JPC miners if the network is balanced, so no one miner is at a disadvantage. The orphan rate might be increasingly unfair if one miner has over half the network hashrate, but then there's a bigger concern that all coins have in this scenario. 2. In my experience with over 100 JPC transactions, I have never had a send/receive transaction voided, but I do get a high orphan rate, which is different from voided transactions. Both the orphaned block and the accepted block that goes into the block chain in its place should have the same transactions, just a different block got the privilege of being recognized by the network. 3. I must have a misunderstanding of the PoS implementation if there is centralized checkpointing. Maybe someone else could address this question. In practice the short target block time intervals have resulted in extremely fast transactions (confirmations). 2) Not necessarily the same set of txes: first, block is created with existing ATM of creation set of transactions, next it is mined by HW, then if the solution found it is submitted. Orphan txes appears on the network usually when aside chain exist and is mined. 3) centralized checkpointing exist for 51% pos/pow attack prevention to make it impossible to override very long sub-chain. It is not good idea to immediately sync-checkpoint the most recently found block as this leads to appearance of many forks. It is much better to checkpoint the blocks that are N deep in the chain and allow the usual way the longest chain to win. Please note, that the "longest" is not in terms of number of blocks: for PoW/PoS coins the cumulative block trust value is accounted for the chain, for PoW only coins the cumulative work is accounted.
|
|
|
|
Litoshi
|
|
September 01, 2014, 12:20:44 AM |
|
Bigredmachine:
To answer your question about 20 second block times producing more orphans than 60 second blocks:
The main cause of orphans is when two miners find the solution at the same time. Both miners then proceed to the next block, but one is now on a fork. This happens even if the block time is 20 minutes. The more numerous the blocks, the more numerous the orphans.
If there was only one pool mining a coin, and all the miners were on that pool, there would not be any orphans at all. But since there are several pools, and many solo miners, the chance of simultaneous solutions increases geometrically.
The reason for the short block times here, is to get more coins out there. There is no limit to the number of JPC coins. JPC has a 120 second block time
Thanks for the reply! To clarify about orphans, what I meant by shorter times causing more orphans is this: - After a block is found, a non-negligible amount of time is spent propagating that block to all the nodes in the network.
- Assuming that this takes 5 seconds (my understanding is that it is closer to 10-12 seconds), 25% of a 20 second block time is spent without knowledge that the previous block has been found. If a block with the same height as the not-yet-known block is found during this small time, it will be orphaned (and rightfully so).
- This small time spent syncing the network is roughly the same regardless of block times.
- Again assuming 5 seconds to sync the network, a 60 second block time would have ~8% of the time spent searching by nodes occur during this sync-up time, and 92% of the time spent searching be useful time spent. A 2.5 minute block time would mean ~3% is wasted.
- In essence, as block time is decreased, the number of Orphans/Share is increased.
My questions then I suppose were really these (again, I am genuinely interested in an asnwer, and not trying to FUD): - What are the repercussions of the much higher rate of orphans? Are there repercussions?
- Can this result in more transactions being voided?
- And finally, since all PoS implementations rely on centralized checkpointing, this means that the operator of the central checkpoint and those nodes closest to that central checkpoint are able to sync much faster than other nodes. What advantages does this give to those nodes in terms of # of Orphans compared to slower-to-sync nodes farther away?
I think you are combining orphans and rejected shares in your reasoning here. Orphans are formed when two miners of different pools find a solution nearly the same time, where as what you are describing with the lag time above, is the increased amount of rejected shares due to the miners still working on a block that has already been solved.
|
|
|
|
bigreddmachine
|
|
September 01, 2014, 06:46:44 PM |
|
I got a lot of replies to my questions, so I didn't want to quote everyone. But thank you to all that helped answer them! If anyone has any more information regarding any of them, please let me know.
Thanks!
|
|
|
|
|