I HOPE this block that is still at 100 confirmations remaining is ours and not someone else's.

That's the only reason I can think that it still has 100 confirmations.

Please be our block!

EDIT: The more I watch it, the more it looks like none of the blocks we found are continuing their confirmation count down.

Each new block on the network counts as one confirmation. There hasn't been a new block found by anyone in the last 40 minutes, hence no more confirmations.

Have you NOT noticed the confirmation count down on the blocks found have yet to move since that block was found?

Also, sometimes there is argument between pools as to whom found a particular block first. That's why I was wondering why that recent block found was still at 100.

After watching longer, NONE of the blocks found are counting down to being cofirmed. I'm sure they are; it's just we are not seeing it on the beta.

EDIT:

There we go, they are counting down now.

No, they weren't counting down at all because they weren't supposed to be counting down. The confirmations listed by Slush is basically the number of blocks built on top of the block in question. IE, for block 331733, Slush will consider that confirmed and pay out for it after the network all together finds another 100 blocks. After 331733, no blocks were found for 40 minutes, and that's why it stayed as 100 confirmations required, and none of the other blocks were counting down either.

As a point, until a block has at least one built on top of it there's always the chance it can get orphaned, but it would actually be very unlikely for even the last block to be orphaned after a couple minutes or so. You get orphan races when two blocks are found within usually a couple seconds of each other, but after a minute everyone who's not running broken software would have been mining on our block, and not the preceeding one.

I HOPE this block that is still at 100 confirmations remaining is ours and not someone else's.

That's the only reason I can think that it still has 100 confirmations.

Please be our block!

EDIT: The more I watch it, the more it looks like none of the blocks we found are continuing their confirmation count down.

Each new block on the network counts as one confirmation. There hasn't been a new block found by anyone in the last 40 minutes, hence no more confirmations.

Have you NOT noticed the confirmation count down on the blocks found have yet to move since that block was found?

Also, sometimes there is argument between pools as to whom found a particular block first. That's why I was wondering why that recent block found was still at 100.

After watching longer, NONE of the blocks found are counting down to being cofirmed. I'm sure they are; it's just we are not seeing it on the beta.

EDIT:

There we go, they are counting down now.

No, they weren't counting down at all because they weren't supposed to be counting down. The confirmations listed by Slush is basically the number of blocks built on top of the block in question. IE, for block 331733, Slush will consider that confirmed and pay out for it after the network all together finds another 100 blocks. After 331733, no blocks were found for 40 minutes, and that's why it stayed as 100 confirmations required, and none of the other blocks were counting down either.

As a point, until a block has at least one built on top of it there's always the chance it can get orphaned, but it would actually be very unlikely for even the last block to be orphaned after a couple minutes or so. You get orphan races when two blocks are found within usually a couple seconds of each other, but after a minute everyone who's not running broken software would have been mining on our block, and not the preceeding one.

Thanks for taking the time to explain that to me, Mr Teal. I know you didn't have to but I appreciate it. Learn something all the time.

...No, they weren't counting down at all because they weren't supposed to be counting down. The confirmations listed by Slush is basically the number of blocks built on top of the block in question. IE, for block 331733 (https://blockchain.info/block/00000000000000000d85f2d73089f2420d3f71d4a614139ace6bab56888adbc1?site=slush), Slush will consider that confirmed and pay out for it after the network all together finds another 100 blocks. After 331733, no blocks were found for 40 minutes, and that's why it stayed as 100 confirmations required, and none of the other blocks were counting down either.

As a point, until a block has at least one built on top of it there's always the chance it can get orphaned, but it would actually be very unlikely for even the last block to be orphaned after a couple minutes or so. You get orphan races when two blocks are found within usually a couple seconds of each other, but after a minute everyone who's not running broken software would have been mining on our block, and not the preceeding one.

Just a couple of points.

In the current bitcoin-qt it's 101 blocks When I added that to the ckdb code I was surprised to see it is actually 101 not 100 (as I also thought it was 100)But that's also due to the confusion that when a block is found it is considered 1 confirm, not 0 confirms.

Although an orphan race is usually obvious, if someone finds a block after most people on the network know about another block, they can keep mining off their own block and win if they are very lucky.Of course they would have to not send out their late block, thus the network wouldn't know about it at all.But if they are lucky enough to build on their own block before anyone find a block to build on the network block, and they send out both, they will actually win the previous orphan race and their 2 blocks will become the network blocks.

So yes, even I look at the 'known' blocks when my pool finds a block and am usually pretty sure after a few minutes, but it's still not certain.Of course, if you are looking at blockchain and not in your bitcoind debug.log the losing block may be on the network and you just can't see it in blockchain.That's rare but it can happen.

The normal thing that happens on an orphan race is that part of the network will be mining on one and another part of the network on the other.It's then purely up to which part of the network finds the next block, that decides the orphan race (though it can in rare circumstances be longer than 1 block to decide it)So it just depends on who has seen both blocks, to know that the orphan race is even happening - but normally everyone has seen both and chosen the one they saw first, to mine on.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!

...No, they weren't counting down at all because they weren't supposed to be counting down. The confirmations listed by Slush is basically the number of blocks built on top of the block in question. IE, for block 331733 (https://blockchain.info/block/00000000000000000d85f2d73089f2420d3f71d4a614139ace6bab56888adbc1?site=slush), Slush will consider that confirmed and pay out for it after the network all together finds another 100 blocks. After 331733, no blocks were found for 40 minutes, and that's why it stayed as 100 confirmations required, and none of the other blocks were counting down either.

As a point, until a block has at least one built on top of it there's always the chance it can get orphaned, but it would actually be very unlikely for even the last block to be orphaned after a couple minutes or so. You get orphan races when two blocks are found within usually a couple seconds of each other, but after a minute everyone who's not running broken software would have been mining on our block, and not the preceeding one.

Just a couple of points.

In the current bitcoin-qt it's 101 blocks When I added that to the ckdb code I was surprised to see it is actually 101 not 100 (as I also thought it was 100)But that's also due to the confusion that when a block is found it is considered 1 confirm, not 0 confirms.

Although an orphan race is usually obvious, if someone finds a block after most people on the network know about another block, they can keep mining off their own block and win if they are very lucky.Of course they would have to not send out their late block, thus the network wouldn't know about it at all.But if they are lucky enough to build on their own block before anyone find a block to build on the network block, and they send out both, they will actually win the previous orphan race and their 2 blocks will become the network blocks.

So yes, even I look at the 'known' blocks when my pool finds a block and am usually pretty sure after a few minutes, but it's still not certain.Of course, if you are looking at blockchain and not in your bitcoind debug.log the losing block may be on the network and you just can't see it in blockchain.That's rare but it can happen.

The normal thing that happens on an orphan race is that part of the network will be mining on one and another part of the network on the other.It's then purely up to which part of the network finds the next block, that decides the orphan race (though it can in rare circumstances be longer than 1 block to decide it)So it just depends on who has seen both blocks, to know that the orphan race is even happening - but normally everyone has seen both and chosen the one they saw first, to mine on.

In the bolded part, are you saying that if you are the last one to find a block on the network and after you've submitted it a couple minutes goes by without another block (to your knowledge) you've still had that block orphaned?

Barring block withholding, my understanding of how that would happen is that prior to 01:00, the network is at height (say) 200. That's actual UTC, not timestamps. You find block 201 at 01:00, and broadcast it, but either due to poor connections or the miner's choice some miners continue to mine on block 200. A couple minutes later at 01:02, one of those miners finds block 201 and submits it, creating the orphan race. After that, those miners continue mining on their block 201, while those who had been mining on your block 201 either continue to do so or switch to the block 201 submitted at 01:02. Some time after that, someone builds a block on the later block 201 and you lose the race.

Is that how something like that would work? It seems to be unlikely unless you are very poorly connected or someone else is poorly connected and has a lot of hashing power, but I'd be interested if it could happen another way.

...No, they weren't counting down at all because they weren't supposed to be counting down. The confirmations listed by Slush is basically the number of blocks built on top of the block in question. IE, for block 331733 (https://blockchain.info/block/00000000000000000d85f2d73089f2420d3f71d4a614139ace6bab56888adbc1?site=slush), Slush will consider that confirmed and pay out for it after the network all together finds another 100 blocks. After 331733, no blocks were found for 40 minutes, and that's why it stayed as 100 confirmations required, and none of the other blocks were counting down either.

As a point, until a block has at least one built on top of it there's always the chance it can get orphaned, but it would actually be very unlikely for even the last block to be orphaned after a couple minutes or so. You get orphan races when two blocks are found within usually a couple seconds of each other, but after a minute everyone who's not running broken software would have been mining on our block, and not the preceeding one.

Just a couple of points.

In the current bitcoin-qt it's 101 blocks When I added that to the ckdb code I was surprised to see it is actually 101 not 100 (as I also thought it was 100)But that's also due to the confusion that when a block is found it is considered 1 confirm, not 0 confirms.

Although an orphan race is usually obvious, if someone finds a block after most people on the network know about another block, they can keep mining off their own block and win if they are very lucky.Of course they would have to not send out their late block, thus the network wouldn't know about it at all.But if they are lucky enough to build on their own block before anyone find a block to build on the network block, and they send out both, they will actually win the previous orphan race and their 2 blocks will become the network blocks.

So yes, even I look at the 'known' blocks when my pool finds a block and am usually pretty sure after a few minutes, but it's still not certain.Of course, if you are looking at blockchain and not in your bitcoind debug.log the losing block may be on the network and you just can't see it in blockchain.That's rare but it can happen.

The normal thing that happens on an orphan race is that part of the network will be mining on one and another part of the network on the other.It's then purely up to which part of the network finds the next block, that decides the orphan race (though it can in rare circumstances be longer than 1 block to decide it)So it just depends on who has seen both blocks, to know that the orphan race is even happening - but normally everyone has seen both and chosen the one they saw first, to mine on.

In the bolded part, are you saying that if you are the last one to find a block on the network and after you've submitted it a couple minutes goes by without another block (to your knowledge) you've still had that block orphaned?

Barring block withholding, my understanding of how that would happen is that prior to 01:00, the network is at height (say) 200. That's actual UTC, not timestamps. You find block 201 at 01:00, and broadcast it, but either due to poor connections or the miner's choice some miners continue to mine on block 200. A couple minutes later at 01:02, one of those miners finds block 201 and submits it, creating the orphan race. After that, those miners continue mining on their block 201, while those who had been mining on your block 201 either continue to do so or switch to the block 201 submitted at 01:02. Some time after that, someone builds a block on the later block 201 and you lose the race.

Is that how something like that would work? It seems to be unlikely unless you are very poorly connected or someone else is poorly connected and has a lot of hashing power, but I'd be interested if it could happen another way.

Firstly, bitcoind will never 'switch' to a different block at the same level, it stays on the one it sees first.bitcoind keeps track of the other forks so that when the "next level" block arrives, it will switch to whichever fork it was built on - or stay on it's current one if the new block builds on it's current one.i.e. it all simply depends on the level change for each new block - another block at the same level will not cause a switch - since that would be making a late block win an orphan battle rather than the first one bitcoind sees.

My example of when you could unexpectedly lose is either due to a "losing" block withholding by someone else, or the software you are using to see the orphan race not always working properly and not always seeing the race - so yes it would be rare.I only mention that second option because with bitcoind you'd have to pay close attention to the block messages in the debug.log file but I've also seen blockchain not show blocks correctly, so making an assumption on what blockchain says is certainly not advisable Some pools have all sorts of edits and changes they make to the standard bitcoind (or use some other software) to do things the way they want, so you can never be quite sure about blocks until a few confirms have happened.(In my pool's case we don't change anything but the block size, with the standard bitcoind options, to ~850k )

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!

I'm at a bit of a loss as to how blockchain would have seen the block at 11:54 and GHash wouldn't have seen it several minutes later, or chose to not mine that block.

Edit: Nevermind. It just appears that the received time field at blockchain isn't actually the time they receive it, and they just set it equal to the timestamp.

Yes, that's a real PITA that they show the block header timestamp.It's next to meaningless and causes confusion.Again, you'd need to look in the bitcoind debug.log to find out when you saw each block (and each orphan)

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!

I'm at a bit of a loss as to how blockchain would have seen the block at 11:54 and GHash wouldn't have seen it several minutes later, or chose to not mine that block.

Edit: Nevermind. It just appears that the received time field at blockchain isn't actually the time they receive it, and they just set it equal to the timestamp.

Yes, that's a real PITA that they show the block header timestamp.It's next to meaningless and causes confusion.Again, you'd need to look in the bitcoind debug.log to find out when you saw each block (and each orphan)

Especially since they have separate fields for received by and the block timestamp. Blocktrail shows the orphaned block 330268 being seen at 12:13:26, which is after the GHash.IO one that won the race.

I am in BC Canada and I would have to say bitmain would be the best bet for Canada shipment, I know there is duty fees, but probably the cheapest and definitely the most reliable.

Yea thats so far What I have kept coming back to. Bitmain being the cheapest possibility. Thats the only thing. oyu bay like 1.2BTC to 2 S3s so its a bomb diggity deal. But than the import charges u pay.... thats when u getscrewed.. Not like i have money to pay for that.

Bitcoins = my only source of income during Schoool : P: P: P: P

And im trying to work my way up to buying materials to build a shack in m backyard for a nice little/big mining farm.

I am in BC Canada and I would have to say bitmain would be the best bet for Canada shipment, I know there is duty fees, but probably the cheapest and definitely the most reliable.

Yea thats so far What I have kept coming back to. Bitmain being the cheapest possibility. Thats the only thing. oyu bay like 1.2BTC to 2 S3s so its a bomb diggity deal. But than the import charges u pay.... thats when u getscrewed.. Not like i have money to pay for that.

Bitcoins = my only source of income during Schoool : P: P: P: P

And im trying to work my way up to buying materials to build a shack in m backyard for a nice little/big mining farm.

If you are using bitcoin to purchase, bitmaintech.com is DEFINITELY the place to purchase; even with shipping costs. Give me your user name at bitmaintech.com and I will send you a $50.00 coupon for 1 S3. I'm sure someone else has a coupon for an S3 if you want another. All I have is one coupon for S3.

If you are using bitcoin to purchase, bitmaintech.com is DEFINITELY the place to purchase; even with shipping costs. Give me your user name at bitmaintech.com and I will send you a $50.00 coupon for 1 S3. I'm sure someone else has a coupon for an S3 if you want another. All I have is one coupon for S3.

Oh jeez. Thanks man I really appreciate that more than anything. I dont know if this is correct... But my username/user id. is flamer962@gmail.com according to the userid on bitmaintech website.

PS. I just changed m username to bladedshard userid is flamer962@gmail.com userNAME is bladedshard.

It would be nice to get say 1-2 more coupons... I would like love you all and give u a big hug if you all helped me out.