firetreeactual
Legendary
Offline
Activity: 952
Merit: 1003
|
|
January 07, 2017, 06:24:06 PM |
|
My guess is that Canaan is doing a first-batch burn-in on the 741...
Juvia's boyfriend GRAY has also joined in yesterday, 120 x A7s from Labrador Way to go, GRAY...so that's why Alan's been so busy...I luv it when a plan comes together.
|
To infinity and beyond...on two 741s and one of only 3...nope, make that 4...full nodes in Hawaii...on <30A. (I have other gear on the Hoth ice planet)
|
|
|
citronick
Legendary
Offline
Activity: 1834
Merit: 1080
---- winter*juvia -----
|
|
January 07, 2017, 06:36:32 PM |
|
My guess is that Canaan is doing a first-batch burn-in on the 741...
Juvia's boyfriend GRAY has also joined in yesterday, 120 x A7s from Labrador Way to go, GRAY...so that's why Alan's been so busy...I luv it when a plan comes together. It took awhile to get 6 fully loaded controllers setup and power distribution; to all the miners up and running. Juvia is still on S9v1 and will be on permanent vacation mining elsewhere until further notice. Who knows.... we could have a 2PH reunion soon.
|
If I provided you good and useful info or just a smile to your day, consider sending me merit points to further validate this Bitcointalk account ~ useful for future account recovery...
|
|
|
Newko
|
|
January 07, 2017, 06:39:15 PM |
|
My guess is that Canaan is doing a first-batch burn-in on the 741...
Juvia's boyfriend GRAY has also joined in yesterday, 120 x A7s from Labrador Way to go, GRAY...so that's why Alan's been so busy...I luv it when a plan comes together. It took awhile to get 6 fully loaded controllers setup and power distribution; to all the miners up and running. Juvia is still on S9v1 and will be on permanent vacation mining elsewhere until further notice. Who knows.... we could have a 2PH reunion soon. Would luv to see Juvia back in the near future She's a good luck girl!
|
|
|
|
blacksmithtm
Member
Offline
Activity: 87
Merit: 10
|
|
January 07, 2017, 06:47:18 PM |
|
Thank you. Do the pros outweigh the cons? In ckpool/ckdb we have a structure called the workinfo, that's the break down of the common data required for all stratum work sent to miners. One part of that is what we call coinbase2 - it's got a limit of 256 hex bytes. Since 1-Mar this year, in all work, coinbase2 has been 196 hex bytes. segwit has put coinbase2 over 256 hex bytes - more than 30% bigger ... How big of an issue is that? And i think the sidechain part is irrelevant. Who cares what people do with bitcoin? As long as they pay the fees to miners and dont ddos (In fact SegWit improves verification times afaik) etc. There are many benefits of SegWit and the cost and risks seem neglicible. Anyway im out. Peace.
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4606
Merit: 1851
Linux since 1997 RedHat 4
|
|
January 07, 2017, 11:15:21 PM |
|
Thank you. Do the pros outweigh the cons? In ckpool/ckdb we have a structure called the workinfo, that's the break down of the common data required for all stratum work sent to miners. One part of that is what we call coinbase2 - it's got a limit of 256 hex bytes. Since 1-Mar this year, in all work, coinbase2 has been 196 hex bytes. segwit has put coinbase2 over 256 hex bytes - more than 30% bigger ... How big of an issue is that? And i think the sidechain part is irrelevant. Who cares what people do with bitcoin? As long as they pay the fees to miners and dont ddos (In fact SegWit improves verification times afaik) etc. There are many benefits of SegWit and the cost and risks seem neglicible. Anyway im out. Peace. Well, there's also the hidden and avoided question of "Why segwit?" There is actually no problem with current standard transactions, and the malleability issue, though effectively no longer relevant, is fixed with a very minor change that's not part of segwit, but in the segwit change also, but I guess the devs don't want people to notice that. Segwit is a fix for maleability in P2SH (3xxxx transactions) When the bitcoin devs designed P2SH, they got it wrong, they added a faulty P2SH. Segwit is a fix for some of their mistakes. But it also forces everyone to use P2SH instead of standard transactions. So basically forcing everyone into whatever other problems there are with P2SH, and out of using standard 1xxxx transactions. All your 1xxxxx addresses will become a thing of the past if segwit activates (which it wont)
|
|
|
|
elokk
|
|
January 07, 2017, 11:32:19 PM |
|
So what exactly would happen with everyones current 1xxxx wallets that hold funds?
|
t.me/bitcoinasic
|
|
|
-ck
Legendary
Offline
Activity: 4284
Merit: 1645
Ruu \o/
|
|
January 07, 2017, 11:48:28 PM |
|
So what exactly would happen with everyones current 1xxxx wallets that hold funds?
Absolutely nothing. The existing 1x transactions work the way they always did, using the standard blockchain space and mechanism for transactions, signing, and verification.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
kano (OP)
Legendary
Offline
Activity: 4606
Merit: 1851
Linux since 1997 RedHat 4
|
|
January 08, 2017, 12:01:56 AM |
|
So what exactly would happen with everyones current 1xxxx wallets that hold funds?
Absolutely nothing. The existing 1x transactions work the way they always did, using the standard blockchain space and mechanism for transactions, signing, and verification. No. The txns that use 1xxxx addresses get weighted 4x using a 3xxxx address. So the cost of using 1xxxx addresses will effectively be 4x the cost of using a 3xxxx address if segwit activates.
|
|
|
|
Make-A-Buck
Newbie
Offline
Activity: 65
Merit: 0
|
|
January 08, 2017, 12:23:56 AM |
|
My guess is that Canaan is doing a first-batch burn-in on the 741...
Good guess. I noticed yesterday that canaan was @ more than DOUBLE the rate of his current rate (1,185.64THs) that he's at today.
|
|
|
|
oh337
Newbie
Offline
Activity: 10
Merit: 0
|
|
January 08, 2017, 03:17:38 AM Last edit: January 08, 2017, 03:27:43 AM by oh337 |
|
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4606
Merit: 1851
Linux since 1997 RedHat 4
|
|
January 08, 2017, 04:28:32 AM |
|
Oh, yes that's me You'll also see me in the Workers menu under K.Workers and K.Graph, which shows that I turn the miners on and off 'almost' randomly.
|
|
|
|
Make-A-Buck
Newbie
Offline
Activity: 65
Merit: 0
|
|
January 08, 2017, 06:21:13 AM |
|
My guess is that Canaan is doing a first-batch burn-in on the 741...
Good guess. I noticed yesterday that canaan was @ more than DOUBLE the rate of his current rate (1,185.64THs) that he's at today. There he is (canaan) back to 2,650.97THs Wow
|
|
|
|
n200UG
Newbie
Offline
Activity: 59
Merit: 0
|
|
January 08, 2017, 08:24:53 AM |
|
Thank you. Do the pros outweigh the cons? In ckpool/ckdb we have a structure called the workinfo, that's the break down of the common data required for all stratum work sent to miners. One part of that is what we call coinbase2 - it's got a limit of 256 hex bytes. Since 1-Mar this year, in all work, coinbase2 has been 196 hex bytes. segwit has put coinbase2 over 256 hex bytes - more than 30% bigger ... How big of an issue is that? And i think the sidechain part is irrelevant. Who cares what people do with bitcoin? As long as they pay the fees to miners and dont ddos (In fact SegWit improves verification times afaik) etc. There are many benefits of SegWit and the cost and risks seem neglicible. Anyway im out. Peace. Slush just pull 3 in-a-row I did not think this was still possible at the current worldwide hashing rate and difficulty. Question: When a block is found on the network, obliviously the pool that mined it is the first to know and first to mine a new block!. How long does it take for the other pool to be notified ? and is this a real factor
|
|
|
|
n200UG
Newbie
Offline
Activity: 59
Merit: 0
|
|
January 08, 2017, 08:27:48 AM |
|
My guess is that Canaan is doing a first-batch burn-in on the 741...
What are the known specs on this beast ?
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4606
Merit: 1851
Linux since 1997 RedHat 4
|
|
January 08, 2017, 08:40:30 AM |
|
... Question: When a block is found on the network, obliviously the pool that mined it is the first to know and first to mine a new block!. How long does it take for the other pool to be notified ? and is this a real factor
That depends on how well connected the pool is. The problem is actually if they are not well connected, they will get more orphans. So the smaller the time until every other pool knows about your block, the better. It is not to your advantage to hide or delay the fact you found a block ... Having 'extra' time to mine a block is not an advantage. That 'extra' time is very small ('should' be less than 1 second) but it's not 'extra' time as such, it's actually time for some other pool to get into an orphan race with you by finding a block at the same height, which is, of course, bad.
|
|
|
|
n200UG
Newbie
Offline
Activity: 59
Merit: 0
|
|
January 08, 2017, 08:44:53 AM |
|
... Question: When a block is found on the network, obliviously the pool that mined it is the first to know and first to mine a new block!. How long does it take for the other pool to be notified ? and is this a real factor
That depends on how well connected the pool is. The problem is actually if they are not well connected, they will get more orphans. So the smaller the time until every other pool knows about your block, the better. It is not to your advantage to hide or delay the fact you found a block ... Having 'extra' time to mine a block is not an advantage. That 'extra' time is very small ('should' be less than 1 second) but it's not 'extra' time as such, it's actually time for some other pool to get into an orphan race with you by finding a block at the same height, which is, of course, bad. Thanks Kano. Very interesting. So seeing pool pulling many block In-A-Row is just luck I guess.
|
|
|
|
philipma1957
Legendary
Offline
Activity: 4298
Merit: 8765
'The right to privacy matters'
|
|
January 08, 2017, 12:17:48 PM |
|
... Question: When a block is found on the network, obliviously the pool that mined it is the first to know and first to mine a new block!. How long does it take for the other pool to be notified ? and is this a real factor
That depends on how well connected the pool is. The problem is actually if they are not well connected, they will get more orphans. So the smaller the time until every other pool knows about your block, the better. It is not to your advantage to hide or delay the fact you found a block ... Having 'extra' time to mine a block is not an advantage. That 'extra' time is very small ('should' be less than 1 second) but it's not 'extra' time as such, it's actually time for some other pool to get into an orphan race with you by finding a block at the same height, which is, of course, bad. Thanks Kano. Very interesting. So seeing pool pulling many block In-A-Row is just luck I guess. yep and more hash = lower odds. if you have 1% of the worlds hash your odds are 1/100 x 1/100 or 10,000 to one of ever pulling 3 in a row if you have 1% of the worlds hash your odds are 1/100 x 1/100 x 1/100 or 1,000,000 of pulling the next 3 in a row
|
|
|
|
ComputerGenie
|
|
January 08, 2017, 01:55:15 PM Last edit: January 08, 2017, 04:44:17 PM by ComputerGenie |
|
yep and more hash = lower odds.
if you have 1% of the worlds hash your odds are 1/100 x 1/100 or 10,000 to one of ever pulling 3 in a row
if you have 1% of the worlds hash your odds are 1/100 x 1/100 x 1/100 or 1,000,000 of pulling the next 3 in a row
That needs an edit "Three in a row, ever" means: "I need to find one, then I need to find 2 more" "Three in a row, including this one" means: "I found one; now, I need to find 2 more" You do get how impossible it is to find "3 in a row" without ever finding the 1st one, right? I'm simply saying that to "find 3 in a row" is not grammatically, or mathematically, the same as "finding 2 more after you've found 1". (to which you prattle on about how many times we've for 2 in a row [which has nothing to do with 3 in a row])
|
If you have to ask "why?", you wouldn`t understand my answer. Always be on the look out, because you never know when you'll be stalked by hit-men that eat nothing but cream cheese....
|
|
|
kano (OP)
Legendary
Offline
Activity: 4606
Merit: 1851
Linux since 1997 RedHat 4
|
|
January 08, 2017, 01:59:50 PM Last edit: January 08, 2017, 03:34:04 PM by kano |
|
yep and more hash = lower odds.
if you have 1% of the worlds hash your odds are 1/100 x 1/100 or 10,000 to one of ever pulling 3 in a row
if you have 1% of the worlds hash your odds are 1/100 x 1/100 x 1/100 or 1,000,000 of pulling the next 3 in a row
That needs an edit Nope. It's correct. When you find a block, you've ... found a block already. In the first case, there's no requirements on finding the first block ... it's just some time in the future. Edit: to avoid littering the thread with garbage again: I'll step off the big numbers and give an example with smaller numbers. We'll use 2 instead of 3 ... What are the chances that a 1% pool will find 2 blocks in a row. 1/100 Why? Coz the assumption is that you can find one block. Once you've found one block you have specified something about finding a second block ... "It's in a row" i.e. "block 2" is the next block after "block 1" We didn't specify anything about "block 1", except the assumption that we can find a block. So this leads to the fact that, if we can find a block, then the probability of finding a block is ... 1 Now there's a minor adjustment to that: We may not find a block. However, since we've effectively been given infinite time to find a block, the probability is 'almost 1' So for the purpose of the question, it's assumed to be ... 1 So the chances of finding 2 blocks in a row is 1 x 1/100 = 1/100 Next: What are the chances that a 3% pool will find 2 blocks in a row. 3/100 or 1/33.333... Lets pretend I don't know what I'm talking about 1/33.333... x 1/33.333... = 1/1111.111... So that would say we really should have only maybe found 2 in a row, about once or twice, maybe three times if we were quite lucky. Checking the history of the pool ... OMG ... we've done it ... lotsa times! Not once or twice or thrice. To be exact it's ... 40 times! 340928 340929 348799 348800 386502 386503 391919 391920 397983 397984 398704 398705 399427 399428 399826 399827 400295 400296 405447 405448 407091 407092 407143 407144 407467 407468 407574 407575 409157 409158 410864 410865 414165 414166 414516 414517 414535 414536 414888 414889 415569 415570 415599 415600 416188 416189 416629 416630 417042 417043 418031 418032 418424 418425 419390 419391 420957 420958 421894 421895 421921 421922 422212 422213 423186 423187 427673 427674 428452 428453 428700 428701 430861 430862 432365 432366 438561 438562 439746 439747
Ego: something is wrong ... ah it's this: "Lets pretend I don't know what I'm talking about 1/33.333... x 1/33.333... = 1/1111.111..."
|
|
|
|
clgrissom3
Legendary
Offline
Activity: 1722
Merit: 1032
Carl, aka Sonny :)
|
|
January 08, 2017, 02:59:43 PM |
|
yep and more hash = lower odds.
if you have 1% of the worlds hash your odds are 1/100 x 1/100 or 10,000 to one of ever pulling 3 in a row
if you have 1% of the worlds hash your odds are 1/100 x 1/100 x 1/100 or 1,000,000 of pulling the next 3 in a row
That needs an edit Nope. It's correct. When you find a block, you've ... found a block already. In the first case, there's no requirements on finding the first block ... it's just some time in the future. Yea, I'll be happy with just the first one right about now
|
|
|
|
|