Topic: [ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000 - page 582. (Read 2171059 times)

your miner submit this :


pool reply with this :


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)

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

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!

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.

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

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.

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.


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.


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.


What address?

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

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!

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...

The public key is needed. It's just like old nxt, where u don't need to provide it before ur first outgoing tx. I believe it may be like reserving the rs? Like then the network sees the hash from ur passphrase, and matches it to the rs...and therefore a public key prevented people from opening every account with every possible rs, and then as soon as incoming tx. the accounts gets signed with the hackers passphrase. Not sure tho, not a dev Just my little conclusion

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

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?

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.

Are you sure? I thought that the account is protected only by a 64-bit hash and is mineable until first outgoing transaction is made / public key appears on the network, like in NXT. Then it will become 256-bit hash which cannot be bruteforced in reasonable time. Setting reward recipient is also outgoing transaction btw. AFAIK this was made on purpose to allow retrieving early accounts in NXT. Probably not needed in Burst, but Burst inherited this. So, coins transferred to account without a public key should arrive, but the account should be secured as soon as possible.

This is how I understand it, is it correct?

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.

My bad!  burstcoin cleared this up for me.. Burst does have protection against this.. there were Nxt clones at some point that didn't though

Erm......20 mins l8r and the top tx. ain't confirming......


EDIT: confirmed , and all the others showing correct amount of confirms

Yeah, it should

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