[ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000

[Craige288]

Thanks.  I did contact Poloniex support and they said 'Sorry, can't help, transaction already on the blockchain'.

Just tried the faucet and it didn't have any public key entry either.  I'll see if I have any Burst when I get home.  If I do have some does that mean the first deposit is done and I can continue as normal with Poloniex etc?

No public key needed for burst.

Oh that's right.. forgot about that. Public key does unlock things but not needed for normal transactions. Nice

OK, so the coin should come through  Maybe the message should be removed from the Burst Wallet then!

Yeah, it should

Just got home and nothing in the wallet   If public key isn't needed for the first deposit then why hasn't it come through?  I guess it's lost....  Not very happy with this coin so far!  Even nothing from the faucet!

[majere]

Just got home and nothing in the wallet   If public key isn't needed for the first deposit then why hasn't it come through?  I guess it's lost....  Not very happy with this coin so far!  Even nothing from the faucet!

Could you check if passphrase is giving the same BURST-... id you used on faucet & exchange?

[burstcoin]

The issue is let's say someone started working on a Proof of Work fork.  If they wanted to fake a fork that was 100 blocks long, they would have to remove 50% of the mining power from the main chain to create this fork, this would take 100 blocks to complete however.. by which point in time the network would be 100 blocks into the future, so they'd constantly be playing catch up.

The question is, can you occasionally say fake a fork like this in say 5 minutes with a large enough percentage of network resources that the network accepts and uses to overwrite the 10 confirmations of a blockchain which cheats the system and overrides that calculation?

This is not "Nothing At Stake."  That is an attack which can only work on a Proof of Stake currency (I know NXT has some defense against this.)  The idea is that since the mining process verifying the blockchain only requires a commitment of the currency the blockchain is tracking, it costs you nothing to mine on all current forks, giving a forking attack a substantial advantage.  That can't happen in a mining process which requires an economic commitment external to the blockchain.  Buterin is the guy to read about this.

This isn't really a nothing at stake question, but more about the cost required to attempt a 51% attack if you have sufficient or close to sufficient hashrate. When attempting that, constructing an alternate chain starting from an earlier point in time can be done quickly since there is no need to actually wait out the deadlines.

Also, how much does Burst have to worry about 'Nothing at Stake'?  Basically you can try to mine on every fork you see?  If someone gets over 50% of the storage, then he can create a separate fork with very little effort that looks correct?  There is one way to sort of get around this but it can't be used to prevent new miners joining the network from joining the wrong fork. So, theoretically, given what is currently implemented.

It is no different than any other algorithm that has 50% value to determine the correct fork. If you own >50% of the Network power (or storage here), you can mine your own fork and publish it once it's ahead of the other fork. Nothing can prevent this in a decentralized system of this kind where the "majority" is right.

The issue is let's say someone started working on a Proof of Work fork.  If they wanted to fake a fork that was 100 blocks long, they would have to remove 50% of the mining power from the main chain to create this fork, this would take 100 blocks to complete however.. by which point in time the network would be 100 blocks into the future, so they'd constantly be playing catch up.

The question is, can you occasionally say fake a fork like this in say 5 minutes with a large enough percentage of network resources that the network accepts and uses to overwrite the 10 confirmations of a blockchain which cheats the system and overrides that calculation?

You are correct, a fake fork could be constructed in less time catching up to the current time starting from a block farther back than mining the real one took Considering the reading time for many user's plot files, you could probably construct the fake one in about 1.5 minutes/block. In order to achieve at least the same cumulative difficulty without running into the future(which would cause the chain to get rejected), the fake chain would still have to have a higher hashrate than the real one. In the case of semi-honest miners on both chains, catching up would probably be slower, as miners would be reading different data for each chain, so 3 minutes/block for creating a fake chain would be more likely, making catchup still faster, but not by as much.

Thanks for mentioning this, I'll certainly be keeping it in mind.

Going back in time and try to overwrite the current chain is actually an interesting attack. On my machine I can get get scanning down to 3s/tb, that is 1TiB and an entire machine (but still something we should protect against if possible). That said, you still need significantly more than 50% of the network capacity for this attack to be exploitable at will, so I really do not see this as a problem. Question remains, what is the probability of a successful attack of this kind for 20%-80% of the network capacity, and for 1-100 blocks - that should give us a very good idea of what a "safe" number of confirmations would be.

Where does your "significantly more than 50%" figure come from? If anything I would think it could lower the amount slightly for small forks(2-3 block attacks), since 51% is a statistical expectation, not an absolute, and if the cost to attempt the attack is low enough, an attacker can more easily try more times, allowing more chances for variance to help out enough to make it work. For longer forks, I would still expect it >51% to be needed.

EDIT: And if it's actually an error then the pool is getting less blocks then it should. This will give an answer to the question why I'm getting less then 1/2 of what I should get according to the calculator. Are there privileged miners getting twice what they should?

Never really tested it out or tried to calculate it, but I've always guessed that under uray's system, more smaller addresses work better. I figure that since it only takes one deadline per id per block, for any given scenario, if part of plots it is using were plotted to another id, you'd get credit for an additional deadline in addition to the same one as earler, leading to more segmentation always yielding more credit. This is why my pools take have target deadlines, and take all deadlines under it, although people generally don't seem to like deadline limits that well.

Just got home and nothing in the wallet   If public key isn't needed for the first deposit then why hasn't it come through?  I guess it's lost....  Not very happy with this coin so far!  Even nothing from the faucet!

What address?

[110110101]

Hi,

Does the Burst calculator (https://bchain.info/BURST/tools/calculator) the correct value ?

I have 10TB of plot files, using the calculator I should earn 4894 BTC per day, my last days was:

2014-11-10 = 3046.74180549 BURST or 0.005 BTC or 1.67 USD or 80 RUR
2014-11-09 = 3568.72379273 BURST or 0.005 BTC or 1.95 USD or 93 RUR
2014-11-08 = 2948.54032659 BURST or 0.004 BTC or 1.61 USD or 77 RUR
2014-11-07 = 1237.77490467 BURST or 0.002 BTC or 0.68 USD or 32 RUR
2014-11-06 = 3209.12890279 BURST or 0.005 BTC or 1.76 USD or 84 RUR
2014-11-05 = 2498.09233920 BURST or 0.004 BTC or 1.37 USD or 65 RUR

where is the problem ?

Thanks

the problem is you see it wrong, its BURST, not BTC

I'm sorry I write wrong thing the calculator for 10TB show me the 4894 BURST not BTC as I wrote.

Why so different from what I earned ?

the average is between 2500-3500 BURST per day instead 4894 ! Is a big difference, Can this depend from USB3 disk and NFS share ?

I have 8TB on 5 USB3 disk (3+3+1+1+0,5TB) and 2.5TB on 2 NAS on NFS share (2+0.5 TB).

Thanks

Fabrizio

I have been mining BURST for a while and I have never had payouts that match the calculated prediction in the calculator. My belief is that your earnings are OK, so there are no problems with NFS or so. My own earnings are in the 50% range of what the calculator predicts.

[unsoindovo]

Hi,

Does the Burst calculator (https://bchain.info/BURST/tools/calculator) the correct value ?

I have 10TB of plot files, using the calculator I should earn 4894 BTC per day, my last days was:

2014-11-10 = 3046.74180549 BURST or 0.005 BTC or 1.67 USD or 80 RUR
2014-11-09 = 3568.72379273 BURST or 0.005 BTC or 1.95 USD or 93 RUR
2014-11-08 = 2948.54032659 BURST or 0.004 BTC or 1.61 USD or 77 RUR
2014-11-07 = 1237.77490467 BURST or 0.002 BTC or 0.68 USD or 32 RUR
2014-11-06 = 3209.12890279 BURST or 0.005 BTC or 1.76 USD or 84 RUR
2014-11-05 = 2498.09233920 BURST or 0.004 BTC or 1.37 USD or 65 RUR

where is the problem ?

Thanks

the problem is you see it wrong, its BURST, not BTC

I'm sorry I write wrong thing the calculator for 10TB show me the 4894 BURST not BTC as I wrote.

Why so different from what I earned ?

the average is between 2500-3500 BURST per day instead 4894 ! Is a big difference, Can this depend from USB3 disk and NFS share ?

I have 8TB on 5 USB3 disk (3+3+1+1+0,5TB) and 2.5TB on 2 NAS on NFS share (2+0.5 TB).

Thanks

Fabrizio

I have been mining BURST for a while and I have never had payouts that match the calculated prediction in the calculator. My belief is that your earnings are OK, so there are no problems with NFS or so. My own earnings are in the 50% range of what the calculator predicts.

the profit calculator are approximate calculations...
are average...
do not forget this!!!

[hvidgaard]

Going back in time and try to overwrite the current chain is actually an interesting attack. On my machine I can get get scanning down to 3s/tb, that is 1TiB and an entire machine (but still something we should protect against if possible). That said, you still need significantly more than 50% of the network capacity for this attack to be exploitable at will, so I really do not see this as a problem. Question remains, what is the probability of a successful attack of this kind for 20%-80% of the network capacity, and for 1-100 blocks - that should give us a very good idea of what a "safe" number of confirmations would be.

Where does your "significantly more than 50%" figure come from? If anything I would think it could lower the amount slightly for small forks(2-3 block attacks), since 51% is a statistical expectation, not an absolute, and if the cost to attempt the attack is low enough, an attacker can more easily try more times, allowing more chances for variance to help out enough to make it work. For longer forks, I would still expect it >51% to be needed.

Note that I said "at will", which I said to mean that you decide that now you are going to do something that you will "undo" after 10 confirmations, e.g. transfer coins to an exchange and sell it off - once the BTC is on it's way out you want to undo the initial transaction. If you only hold 51% the statistical probability isn't high, though eventually you are likely to succeed.

What I propose, but lack the theoretical knowledge to calculate (well, I learned it during my statistical math classes, but it's long forgotten):

* assume that calculating an n-block long private chain is instant
* calculate the probability to successfully fork the last n blocks, where n is 1-100, with p 10..99 % of the network capacity.

I assume that finding deadlines is instant, such that any advance in technology will not render the result invalid, because it is now faster.

[Craige288]

The issue is let's say someone started working on a Proof of Work fork.  If they wanted to fake a fork that was 100 blocks long, they would have to remove 50% of the mining power from the main chain to create this fork, this would take 100 blocks to complete however.. by which point in time the network would be 100 blocks into the future, so they'd constantly be playing catch up.

The question is, can you occasionally say fake a fork like this in say 5 minutes with a large enough percentage of network resources that the network accepts and uses to overwrite the 10 confirmations of a blockchain which cheats the system and overrides that calculation?

This is not "Nothing At Stake."  That is an attack which can only work on a Proof of Stake currency (I know NXT has some defense against this.)  The idea is that since the mining process verifying the blockchain only requires a commitment of the currency the blockchain is tracking, it costs you nothing to mine on all current forks, giving a forking attack a substantial advantage.  That can't happen in a mining process which requires an economic commitment external to the blockchain.  Buterin is the guy to read about this.

This isn't really a nothing at stake question, but more about the cost required to attempt a 51% attack if you have sufficient or close to sufficient hashrate. When attempting that, constructing an alternate chain starting from an earlier point in time can be done quickly since there is no need to actually wait out the deadlines.

Also, how much does Burst have to worry about 'Nothing at Stake'?  Basically you can try to mine on every fork you see?  If someone gets over 50% of the storage, then he can create a separate fork with very little effort that looks correct?  There is one way to sort of get around this but it can't be used to prevent new miners joining the network from joining the wrong fork. So, theoretically, given what is currently implemented.

It is no different than any other algorithm that has 50% value to determine the correct fork. If you own >50% of the Network power (or storage here), you can mine your own fork and publish it once it's ahead of the other fork. Nothing can prevent this in a decentralized system of this kind where the "majority" is right.

The issue is let's say someone started working on a Proof of Work fork.  If they wanted to fake a fork that was 100 blocks long, they would have to remove 50% of the mining power from the main chain to create this fork, this would take 100 blocks to complete however.. by which point in time the network would be 100 blocks into the future, so they'd constantly be playing catch up.

The question is, can you occasionally say fake a fork like this in say 5 minutes with a large enough percentage of network resources that the network accepts and uses to overwrite the 10 confirmations of a blockchain which cheats the system and overrides that calculation?

You are correct, a fake fork could be constructed in less time catching up to the current time starting from a block farther back than mining the real one took Considering the reading time for many user's plot files, you could probably construct the fake one in about 1.5 minutes/block. In order to achieve at least the same cumulative difficulty without running into the future(which would cause the chain to get rejected), the fake chain would still have to have a higher hashrate than the real one. In the case of semi-honest miners on both chains, catching up would probably be slower, as miners would be reading different data for each chain, so 3 minutes/block for creating a fake chain would be more likely, making catchup still faster, but not by as much.

Thanks for mentioning this, I'll certainly be keeping it in mind.

Going back in time and try to overwrite the current chain is actually an interesting attack. On my machine I can get get scanning down to 3s/tb, that is 1TiB and an entire machine (but still something we should protect against if possible). That said, you still need significantly more than 50% of the network capacity for this attack to be exploitable at will, so I really do not see this as a problem. Question remains, what is the probability of a successful attack of this kind for 20%-80% of the network capacity, and for 1-100 blocks - that should give us a very good idea of what a "safe" number of confirmations would be.

Where does your "significantly more than 50%" figure come from? If anything I would think it could lower the amount slightly for small forks(2-3 block attacks), since 51% is a statistical expectation, not an absolute, and if the cost to attempt the attack is low enough, an attacker can more easily try more times, allowing more chances for variance to help out enough to make it work. For longer forks, I would still expect it >51% to be needed.

EDIT: And if it's actually an error then the pool is getting less blocks then it should. This will give an answer to the question why I'm getting less then 1/2 of what I should get according to the calculator. Are there privileged miners getting twice what they should?

Never really tested it out or tried to calculate it, but I've always guessed that under uray's system, more smaller addresses work better. I figure that since it only takes one deadline per id per block, for any given scenario, if part of plots it is using were plotted to another id, you'd get credit for an additional deadline in addition to the same one as earler, leading to more segmentation always yielding more credit. This is why my pools take have target deadlines, and take all deadlines under it, although people generally don't seem to like deadline limits that well.

Just got home and nothing in the wallet   If public key isn't needed for the first deposit then why hasn't it come through?  I guess it's lost....  Not very happy with this coin so far!  Even nothing from the faucet!

What address?

LOL !!!  Just realised it's the wrong wallet address.  Restarted wallet and put pass phrase in again and there ya go!  All coins in place   Must have entered the wrong pass phrase.  Thanks for all your help everyone!

[roccia]

i think it is a bit optimistic...
with 12Tb it say 7000 coins/ day....
i'm doing 5000/6000 day...

with 13800Gb i'm doing 8500/9500 burst/day but i mine in solo

[uray]

Is this a serious bug in the uray's v2 pool code or I just don't understand how it works? Sometimes my current round BEST deadline is counted in the pool as thousands of years, but it's actually a day or 7 hours. If it's an error how it's possible to stay unnoticed for so long. Almost each round I have much better deadline then the pool confirms.

block#32841 s#:2156 bt:3256928 90af85ce164f1b479a8375e2fa314f5ec83b2b7ed1a938596
8caf12672bf9efc
...
XXXX-XXXX-XXXX-XXXXX dl:58 days 16:01:39 n:8098078
XXXX-XXXX-XXXX-XXXXX dl:21 days 04:00:49 n:10204459
XXXX-XXXX-XXXX-XXXXX dl:12 days 12:01:59 n:8787052
plot read done. XXXXXXXXXXXXXXXX_10000001_952000_8000 = 960000 nonces
submitting nonce 8787052 for XXXX-XXXX-XXXX-XXXXX
{"result": "success","deadline": 1080119,"targetDeadline": 1080119}
confirmed dl. for XXXX-XXXX-XXXX-XXXXX : 12 days 12:01:59
XXXX-XXXX-XXXX-XXXXX dl:10 days 01:42:09 n:1578278
plot read done. XXXXXXXXXXXXXXXX_8000001_1904000_8000 = 1912000 nonces
submitting nonce 1578278 for XXXX-XXXX-XXXX-XXXXX
{"result": "success","deadline": 4803144336493,"targetDeadline": 1080119}
No confirm dl. here, so in the pool my Current Round Best Deadline is 12 days instead of 10 days.
submitting nonce 1578278 for XXXX-XXXX-XXXX-XXXXX
{"result": "success","deadline": 4803144336493,"targetDeadline": 1080119}
plot read done. XXXXXXXXXXXXXXXX_4000001_3624000_8000 = 3632000 nonces
plot read done. XXXXXXXXXXXXXXXX_1_4000000_8000 = 4008000 nonces
submitting nonce 1578278 for XXXX-XXXX-XXXX-XXXXX
{"result": "success","deadline": 4803144336493,"targetDeadline": 1080119}
....

EDIT: And if it's actually an error then the pool is getting less blocks then it should. This will give an answer to the question why I'm getting less then 1/2 of what I should get according to the calculator. Are there privileged miners getting twice what they should?

In the current block I have better best dl then the whole pool and it's not counted:

block#32848 s#:427 bt:3941683 db8cbd6f3b4347af33b6c5dbd014e88886b1534c471ba44379
58111360a83697
XXXX-XXXX-XXXX-XXXXX dl:43377706 days 07:34:36 n:10000001
XXXX-XXXX-XXXX-XXXXX dl:30498843 days 14:39:55 n:10000003
XXXX-XXXX-XXXX-XXXXX dl:16280478 days 08:12:47 n:10000004
XXXX-XXXX-XXXX-XXXXX dl:10770849 days 02:47:49 n:10000007
XXXX-XXXX-XXXX-XXXXX dl:3161699 days 08:04:42 n:10000008
XXXX-XXXX-XXXX-XXXXX dl:2639299 days 10:49:14 n:10000025
XXXX-XXXX-XXXX-XXXXX dl:728431 days 11:16:32 n:10000026
XXXX-XXXX-XXXX-XXXXX dl:412278 days 10:25:49 n:10000111
XXXX-XXXX-XXXX-XXXXX dl:82368 days 11:02:34 n:10000160
XXXX-XXXX-XXXX-XXXXX dl:33784 days 04:49:14 n:10000642
XXXX-XXXX-XXXX-XXXXX dl:29179 days 04:12:27 n:10001703
XXXX-XXXX-XXXX-XXXXX dl:27550 days 14:29:12 n:10002832
XXXX-XXXX-XXXX-XXXXX dl:5362 days 14:13:56 n:10002979
XXXX-XXXX-XXXX-XXXXX dl:2021 days 19:42:54 n:10004065
XXXX-XXXX-XXXX-XXXXX dl:955 days 16:41:03 n:8005403
XXXX-XXXX-XXXX-XXXXX dl:35 days 12:32:56 n:4003615
submitting nonce 4003615 for XXXX-XXXX-XXXX-XXXXX
{"result": "success","deadline": 3069176,"targetDeadline": 3069176}
confirmed dl. for XXXX-XXXX-XXXX-XXXXX : 35 days 12:32:56
XXXX-XXXX-XXXX-XXXXX dl:6 days 09:57:57 n:4534359
plot read done. XXXXXXXXXXXXXXXX_10000001_952000_8000 = 960000 nonces
XXXX-XXXX-XXXX-XXXXX dl:5 days 03:53:01 n:5097447
submitting nonce 5097447 for XXXX-XXXX-XXXX-XXXXX
{"result": "success","deadline": 1833348656611,"targetDeadline": 3069176}
submitting nonce 5097447 for XXXX-XXXX-XXXX-XXXXX
XXXX-XXXX-XXXX-XXXXX dl:4 days 00:42:39 n:5726669
{"result": "success","deadline": 1833348656611,"targetDeadline": 3069176}
plot read done. XXXXXXXXXXXXXXXX_8000001_1904000_8000 = 1912000 nonces
XXXX-XXXX-XXXX-XXXXX dl:0 days 00:26:27 n:5889794
submitting nonce 5889794 for XXXX-XXXX-XXXX-XXXXX
{"result": "success","deadline": 4318310545714,"targetDeadline": 3069176}
No confirm dl. here, so in the pool my Current Round Best Deadline is 35 days instead of 26 minutes.
submitting nonce 5889794 for XXXX-XXXX-XXXX-XXXXX
{"result": "success","deadline": 4318310545714,"targetDeadline": 3069176}

Pool best deadline is 33+ minutes and I have a 26 minutes share...

your miner submit this :

Code:

XXXX-XXXX-XXXX-XXXXX dl:0 days 00:26:27 n:5889794
submitting nonce 5889794 for XXXX-XXXX-XXXX-XXXXX

pool reply with this :

Code:

{"result": "success","deadline": 1833348656611,"targetDeadline": 3069176}

so the result is different, when your miner say that nonce could result in 0 days deadline
after pool replot it with your submitted nocne and account id, it did not result in 0 days of deadline,
so its unconfirmed deadline

it could be because your plot is different than pool plot, some issue like this was happened because of plot optimizer or corrupted plot, and also because miner and pool check the nonce against different gensig due to different block height

i have more than 10 miners scattered around the world on my vps, mining at my own pool but never have this unconfirmed deadlime, i would love to investigate this, but i can't reproduce it, when you encounter this can you give me:
1. your accountId
2. nonce that has unconfirmed deadline and
3. scoop number and baseTarget when this problem occured (or exact block height)

[equipoise]

^PM sent.

[KeyShare]

Burst just pumped up to 35st on CoinGecko ranking guys!

http://puu.sh/cMeAu/532afae7ae.png

AD MAIORA!

Just to make some latin  

[uray]

^PM sent.

and also you can check the result by using this API :

http://compute.burstcoin.io:8109/burst?requestType=getDeadline&accountId=YourAccountNum&nonce=5889794&height=32848&target=3941683&scoop=427&gensig=db8cbd6f3b4347af33b6c5dbd014e88886b1534c471ba4437958111360a83697

since you dont provides your accountNum, replace the "...accountId=YourAccountNum..."

this API will re-create the plot from scratch based on the information you provided (just like on OP diagram), and then return the deadline

[uray]

...

Never really tested it out or tried to calculate it, but I've always guessed that under uray's system, more smaller addresses work better. I figure that since it only takes one deadline per id per block, for any given scenario, if part of plots it is using were plotted to another id, you'd get credit for an additional deadline in addition to the same one as earler, leading to more segmentation always yielding more credit. This is why my pools take have target deadlines, and take all deadlines under it, although people generally don't seem to like deadline limits that well.

you might be correct, and also note that reward does not linear to the best deadline submitted on my system, and also reward distribution is "skewed", thats why it has different curve between US, EU and SG each of them tuned to favor different type of miners capacity.

on SG pool you might be get less payout if u are using 1000 accounts each of 1GB capacity instead of 1 account of 1 TB capacity, but on US pool its yet to be checked does thousands of small account result to better payout, while on EU pool you might not get payout at all by using 1000 accounts each with 1GB size

i dont see this as disadvantage for miners, because it give them options to choose pool, each pool can have unlimited different characteristic instead of just PPLNS, PPS or Prop like on conventional pool

[lootz]

What is the easiest fastest way to get this set up guys. I have an I7, 2 r90 Gpu's, 16gig ram, about 9TB combines in HDD space. Irontiga helped me alot by switching to linux but I am still having no luck. Is there an easy guide to get this done. I am new to the burst scene, I just wanna get hdd mining for now using windows if possible because then I get get my gpu's mining along with my asics. I appreciate the help. I am very active in the crypto community and can do webdev if the coin needs anything.

[equipoise]

^PM sent.

and also you can check the result by using this API :

http://compute.burstcoin.io:8109/burst?requestType=getDeadline&accountId=YourAccountNum&nonce=5889794&height=32848&target=3941683&scoop=427&gensig=db8cbd6f3b4347af33b6c5dbd014e88886b1534c471ba4437958111360a83697

since you dont provides your accountNum, replace the "...accountId=YourAccountNum..."

this API will re-create the plot from scratch based on the information you provided (just like on OP diagram), and then return the deadline

OK. Thank you. I'll calculate all my plots again. Maybe they are corrupted. I'm using Janror's cpu plotter V1.16.

[burstcoin]

...

Never really tested it out or tried to calculate it, but I've always guessed that under uray's system, more smaller addresses work better. I figure that since it only takes one deadline per id per block, for any given scenario, if part of plots it is using were plotted to another id, you'd get credit for an additional deadline in addition to the same one as earler, leading to more segmentation always yielding more credit. This is why my pools take have target deadlines, and take all deadlines under it, although people generally don't seem to like deadline limits that well.

you might be correct, and also note that reward does not linear to the best deadline submitted on my system, and also reward distribution is "skewed", thats why it has different curve between US, EU and SG each of them tuned to favor different type of miners capacity.

on SG pool you might be get less payout if u are using 1000 accounts each of 1GB capacity instead of 1 account of 1 TB capacity, but on US pool its yet to be checked does thousands of small account result to better payout, while on EU pool you might not get payout at all by using 1000 accounts each with 1GB size

i dont see this as disadvantage for miners, because it give them options to choose pool, each pool can have unlimited different characteristic instead of just PPLNS, PPS or Prop like on conventional pool

Yes I've seen the curves. I'm not trying to say that more but lower quality deadlines would yield more, but that your best deadline on average would still be of the same quality regardless of how much you segment things out. Your best deadline on average for a 1TB plot file to one account should be on average the same as your single best deadline for 1TB made of 10 plots to different ids of 100GB each, and on normal solo mining both scenarios should be able to mine the same amount of blocks. The difference only comes into play when using a pool that takes 1 best deadline for each id, since the single best deadline for each scenario should be of the same quality, but the segmented setup allows 9 extras to be tacked on along with it.

[bobafett]

Hi,
i´, using a pool.

can anybody explain me the following rows on urays pool?

CR.Deadline
CR.Shares
AR.Deadline
AR.Shares

Best Regards.
boba

[hashes4.me]

Hi,
i´, using a pool.

can anybody explain me the following rows on urays pool?

CR.Deadline
CR.Shares
AR.Deadline
AR.Shares

Best Regards.
boba

Just move your mouse over the tabs.
CR.Deadline = Current Round Best Deadline
CR.Shares = Current Round Share Value
AR.Deadline = All Round Best Deadline
AR.Shares = All Round Share Value

[bobafett]

ok, thanks,
but what means this in detail.

For example:
CR.Shares
What is a share?
How do i increase this value? On what depends this?
....

Best Regars.
boba

[mafostedu]

...

Never really tested it out or tried to calculate it, but I've always guessed that under uray's system, more smaller addresses work better. I figure that since it only takes one deadline per id per block, for any given scenario, if part of plots it is using were plotted to another id, you'd get credit for an additional deadline in addition to the same one as earler, leading to more segmentation always yielding more credit. This is why my pools take have target deadlines, and take all deadlines under it, although people generally don't seem to like deadline limits that well.

you might be correct, and also note that reward does not linear to the best deadline submitted on my system, and also reward distribution is "skewed", thats why it has different curve between US, EU and SG each of them tuned to favor different type of miners capacity.

on SG pool you might be get less payout if u are using 1000 accounts each of 1GB capacity instead of 1 account of 1 TB capacity, but on US pool its yet to be checked does thousands of small account result to better payout, while on EU pool you might not get payout at all by using 1000 accounts each with 1GB size

i dont see this as disadvantage for miners, because it give them options to choose pool, each pool can have unlimited different characteristic instead of just PPLNS, PPS or Prop like on conventional pool

So say if I have 100 TB space for mining, which one is good for SG pool ? 50-50 TB with 2 different accounts or 100 TB with single account ?

BTW, how to get customized burst ID ? Just noticed your burst ID in sig starting with BURST-URAY-xxxx