philipma1957
Legendary
Online
Activity: 4284
Merit: 8684
'The right to privacy matters'
|
|
April 01, 2017, 02:44:17 PM |
|
Meh the random April 1 alt-coin tags got me wrong If anything I'd be LTC ... I drew the winning LTC logo but was overturned coz coblee wanted the one drawn by a pr0n site owner What's up with these random alt-coin tags? I just noticed them... Aprils fool bro
|
|
|
|
SA Bitcoin Brothers
Member
Offline
Activity: 112
Merit: 18
|
|
April 01, 2017, 05:55:49 PM |
|
Back online. Upgraded from 85TH/s to 115TH/s. Let's get a block! Have a great weekend
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
April 01, 2017, 09:43:43 PM |
|
... The stolen shares are, in most cases, far above.. NOT below the current difficulty. Think about it. If you found a share that was hundreds of times the current difficulty, wouldn't you want to save it ? ...
Lulz no idea what you been smoking to confuse you, but a share is only worth the value of the work it was generated for, and a valid block share is only worth a block no matter what difficulty it is (as long as it's a block). ... and if a block is not submitted immediately, it's worth nothing if someone else finds a block while you procrastinate, so no you wouldn't save it - that's stupid. If a share is worse than the requested work difficulty, it's worth nothing. If a share is better than or equal to the requested work difficulty, it's only worth the requested work difficulty.
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
April 01, 2017, 10:20:55 PM |
|
I'll be upgrading the SG and JP mining nodes in about 17 and 17 1/2 hours at:
SG 1-Apr 23:00 UTC JP 1-Apr 23:30 UTC
The web site shows this now also.
The expected outage is less than 5 minutes for each node.
I've separated the update by 30mins in case anyone is mining to them both as primary and backup - they won't need to change anything. If you only mine to one Kano node and it's one of those two nodes, make sure you also have a secondary backup Kano node.
No other mining will be affected - only SG and JP.
Reminder - this is in 40 minutes for SG and then 30 minutes after that for JP
|
|
|
|
Sr.Urbanist
|
|
April 01, 2017, 10:28:28 PM |
|
I'll be upgrading the SG and JP mining nodes in about 17 and 17 1/2 hours at:
SG 1-Apr 23:00 UTC JP 1-Apr 23:30 UTC
The web site shows this now also.
The expected outage is less than 5 minutes for each node.
I've separated the update by 30mins in case anyone is mining to them both as primary and backup - they won't need to change anything. If you only mine to one Kano node and it's one of those two nodes, make sure you also have a secondary backup Kano node.
No other mining will be affected - only SG and JP.
Reminder - this is in 40 minutes for SG and then 30 minutes after that for JP Anything to do with the "grand compromise", which sounds like BIP100? https://www.cryptocoinsnews.com/bitcoin-reaches-a-grand-compromise-on-the-scalability-debate/EDIT: My sticker should be Litecoin. I am bull, bull, bull on litecoin. #LTC50
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
April 01, 2017, 10:30:09 PM |
|
I'll be upgrading the SG and JP mining nodes in about 17 and 17 1/2 hours at:
SG 1-Apr 23:00 UTC JP 1-Apr 23:30 UTC
The web site shows this now also.
The expected outage is less than 5 minutes for each node.
I've separated the update by 30mins in case anyone is mining to them both as primary and backup - they won't need to change anything. If you only mine to one Kano node and it's one of those two nodes, make sure you also have a secondary backup Kano node.
No other mining will be affected - only SG and JP.
Reminder - this is in 40 minutes for SG and then 30 minutes after that for JP Anything to do with the "grand compromise", which sounds like BIP100? https://www.cryptocoinsnews.com/bitcoin-reaches-a-grand-compromise-on-the-scalability-debate/Nope, just as I said here: https://bitcointalk.org/index.php?topic=789369.msg18387922#msg18387922It's doubling the ram on each server.
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
April 01, 2017, 11:19:05 PM Last edit: April 01, 2017, 11:50:31 PM by kano |
|
I'll be upgrading the SG and JP mining nodes in about 17 and 17 1/2 hours at:
SG 1-Apr 23:00 UTC JP 1-Apr 23:30 UTC
The web site shows this now also.
The expected outage is less than 5 minutes for each node.
I've separated the update by 30mins in case anyone is mining to them both as primary and backup - they won't need to change anything. If you only mine to one Kano node and it's one of those two nodes, make sure you also have a secondary backup Kano node.
No other mining will be affected - only SG and JP.
Reminder - this is in 40 minutes for SG and then 30 minutes after that for JP SG upgrade completed as expected. I stopped the node connections at 23:00:06 UTC Node upgrade was completed, bitcoin restarted, then node accepting connections at 23:04:31 UTC JP next in 11 minutes. Edit: JP upgrade completed as expected also. I stopped the node connections at 23:30:08 UTC Node upgrade was completed, bitcoin restarted, then node accepting connections at 23:34:14 UTC -- FYI next will be NL and DE in the next few days. This will be done very differently and take a number of hours since it will be switching miners between the 2 two nodes via DNS and back again using disconnects. The redirect function of ckpool ignores the port the connection was made on, so I won't be using that. Thus it will appear as a simple disconnect/reconnect a couple of times on each node during the upgrades, but no actual outages.
|
|
|
|
NotFuzzyWarm
Legendary
Offline
Activity: 3794
Merit: 2689
Evil beware: We have waffles!
|
|
April 02, 2017, 01:16:15 AM |
|
You did read the last 2 paragraphs right? Here's the first one: If only this had been written on a different day than April’s fools. In truth, bitcoin is more divided than it has ever been. Revolting political censorship continues to be applied. The hashpower may soon fork despite the objection of some Blockstream employees. Eth is nearing a $5 billion market cap with its transaction numbers nearing 100,000 a day. Even litecoin, that boring forgotten thing, is moving. The last para starts with stronger reference to what today is: April 1st, eg. April Fool's Day....
|
|
|
|
Sr.Urbanist
|
|
April 02, 2017, 01:54:12 AM |
|
You did read the last 2 paragraphs right? Here's the first one: If only this had been written on a different day than April’s fools. In truth, bitcoin is more divided than it has ever been ... Jaja ... It'd be nice though, right? I'm not too concerned though because I think recent SegWit discussions on LiteCoin may help ease pressure on BTC for a while. I guess I just don't fully understand SegWit ... Cool. I went back, but not far enough to see that post.
|
|
|
|
os2sam
Legendary
Offline
Activity: 3586
Merit: 1098
Think for yourself
|
|
April 02, 2017, 03:24:19 AM |
|
I'm not too concerned though because I think recent SegWit discussions on LiteCoin may help ease pressure on BTC for a while. I guess I just don't fully understand SegWit ...
Segregated Witness is to correct a screw up they made when implementing the P2SH changes. Did LiteCoin make the same mistakes the Bitcoin devs did?
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
April 02, 2017, 12:53:39 PM Last edit: April 02, 2017, 01:10:43 PM by kano |
|
Block! by cobramining A7v2 and 2 payouts Looks like the txn fees are finally falling - that was a 2 minute block, but still not a lot of fees, unlike usual. Edit: actually it was only 239,216 bytes due to there only being that many chosen by bitcoind. I don't affect the "segwit" 13.1 code's decision to choose transactions except for the smaller (88,888) size on the block change and the reorg of transactions to fit in a 'few extra' bytes when it's close to full.
|
|
|
|
clgrissom3
Legendary
Offline
Activity: 1722
Merit: 1032
Carl, aka Sonny :)
|
|
April 02, 2017, 12:55:45 PM |
|
Block! by cobramining A7v2 and 2 payouts Good start!
|
|
|
|
GWhisper
|
|
April 03, 2017, 05:29:18 AM |
|
Any reason for the last payout without a new block?
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
April 03, 2017, 05:51:42 AM |
|
Any reason for the last payout without a new block?
That's funny As I've always said, I do actually (almost always) send out the payout 1 minute after it matures. That of course actually means that the payout transaction is out there on the net for anyone to accept and confirm. The problem is that it's a zero fee transaction so I'd never expect anyone else to actually confirm it. I force it to be in our work by prioritising it with a ridiculously high value. In this case it was confirmed in another pool's block: 460168 I guess the reason is that the transaction count has gone down a lot, and some pools are actually confirming free transactions when they can't fill the block.
|
|
|
|
elokk
|
|
April 03, 2017, 06:09:27 AM |
|
Any reason for the last payout without a new block?
That's funny As I've always said, I do actually (almost always) send out the payout 1 minute after it matures. That of course actually means that the payout transaction is out there on the net for anyone to accept and confirm. The problem is that it's a zero fee transaction so I'd never expect anyone else to actually confirm it. I force it to be in our work by prioritising it with a ridiculously high value. In this case it was confirmed in another pool's block: 460168 I guess the reason is that the transaction count has gone down a lot, and some pools are actually confirming free transactions when they can't fill the block. "....but bitcoin doesn't work anymore because blocks are full"
|
t.me/bitcoinasic
|
|
|
agentcash
Newbie
Offline
Activity: 49
Merit: 0
|
|
April 03, 2017, 06:12:05 AM |
|
... The stolen shares are, in most cases, far above.. NOT below the current difficulty. Think about it. If you found a share that was hundreds of times the current difficulty, wouldn't you want to save it ? ...
Lulz no idea what you been smoking to confuse you, but a share is only worth the value of the work it was generated for, and a valid block share is only worth a block no matter what difficulty it is (as long as it's a block). ... and if a block is not submitted immediately, it's worth nothing if someone else finds a block while you procrastinate, so no you wouldn't save it - that's stupid. If a share is worse than the requested work difficulty, it's worth nothing. If a share is better than or equal to the requested work difficulty, it's only worth the requested work difficulty. I didn't see his full post, but what is to stop someone from opening multiple connections and submitting shares just above the work diff? Say you have a miner that avgs 10k diff, open two more connections to submit all work from 5k-9999 and four more connections for all work from 2.5k-4,999, etc. This miner would be making the same as an honest miner, in addition to all the proceeds from submitting his lower shares on the other connections. Seems even easier to take advantage of on pools that allow you to set your own difficulty. Open up a bunch of ranges and get paid huge amounts for rarer high hashes, while still getting paid on as low hashes as your connection speed allows. I asked about this before, but I think I confused the issue previously by asking about connection 'cookies' or individual connection nonces to try to prevent this. It would be obvious from statistics of course, but it still seems ripe for exploit on pools that don't pay much attention.
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
April 03, 2017, 06:15:24 AM |
|
... The stolen shares are, in most cases, far above.. NOT below the current difficulty. Think about it. If you found a share that was hundreds of times the current difficulty, wouldn't you want to save it ? ...
Lulz no idea what you been smoking to confuse you, but a share is only worth the value of the work it was generated for, and a valid block share is only worth a block no matter what difficulty it is (as long as it's a block). ... and if a block is not submitted immediately, it's worth nothing if someone else finds a block while you procrastinate, so no you wouldn't save it - that's stupid. If a share is worse than the requested work difficulty, it's worth nothing. If a share is better than or equal to the requested work difficulty, it's only worth the requested work difficulty. I didn't see his full post, but what is to stop someone from opening multiple connections and submitting shares just above the work diff? Say you have a miner that avgs 10k diff, open two more connections to submit all work from 5k-9999 and four more connections for all work from 2.5k-4,999, etc. This miner would be making the same as an honest miner, in addition to all the proceeds from submitting his lower shares on the other connections. Seems even easier to take advantage of on pools that allow you to set your own difficulty. Open up a bunch of ranges and get paid huge amounts for rarer high hashes, while still getting paid on as low hashes as your connection speed allows. I asked about this before, but I think I confused the issue previously by asking about connection 'cookies' or individual connection nonces to try to prevent this. It would be obvious from statistics of course, but it still seems ripe for exploit on pools that don't pay much attention. You can't. A share is associated with a work item - and it can't pretend to be associated with a different one. That work item has a difficulty that the pool assigns. The work item is of course also unique per 'worker'. Edit: and by 'worker' I mean a connection to the pool (which may be a miner or a proxy)
|
|
|
|
agentcash
Newbie
Offline
Activity: 49
Merit: 0
|
|
April 03, 2017, 06:19:13 AM |
|
You can't.
A share is associated with a work item - and it can't pretend to be associated with a different one. That work item has a difficulty that the pool assigns. The work item is of course also unique per 'worker'.
Ah, I see. That's what I was wondering before, if there was something in the work items that was unique per connection/difficulty. Thanks.
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
April 03, 2017, 06:33:35 AM |
|
You can't.
A share is associated with a work item - and it can't pretend to be associated with a different one. That work item has a difficulty that the pool assigns. The work item is of course also unique per 'worker'.
Ah, I see. That's what I was wondering before, if there was something in the work items that was unique per connection/difficulty. Thanks. Well it's effectively unique, but by reference rather than being part of the work. Yeah that is actually a 'bug' in stratum that I argued with Slush about in the stratum thread (and others mentioned but didn't care too much about it) Slush's answer was it was too hard for him to code it ... ... crappy programmers everywhere you look ... A workaround was put into effect rather than actually fixing it properly. The fix was of course to make the difficulty part of the actual work, the problem was the pool sends out the difficulty as a separate message to the work and it doesn't specify which work it is associated with either, it's simply a "difficulty change" message. The workaround is in the stratum spec about how a difficulty change is associated with what work. ... but no you can't game it.
|
|
|
|
NomadGroup
|
|
April 03, 2017, 06:43:26 AM |
|
Hey Kano, I received the payment for the last block without us finding a new one about an hour ago. Perfectly fine with me I just was wondering why, I believe that it's a first time I see this happen. Thanks!
|
|
|
|
|