Pages:
Author

Topic: 🤖[ANN][BIS]Bismuth 2.0 - Beyond DeFi - page 56. (Read 156192 times)

full member
Activity: 253
Merit: 101
They said it will not be less than 10,000 BIS.
full member
Activity: 546
Merit: 137
how many coins needed for collateral?

Is not yet knows man. They said will come out with all the details after launch.
member
Activity: 69
Merit: 10
how many coins needed for collateral?
member
Activity: 140
Merit: 30
Bismuth core dev & EggPool.net Operator.
I'm getting " wrong address format " what does it mean ? Help ??

Check you didn't paste an extra character, or capitalized the first char, or forgot some.
newbie
Activity: 156
Merit: 0
I'm getting " wrong address format " what does it mean ? Help ??
full member
Activity: 280
Merit: 105
But i think this depends or difficulty also, not sure what the right formula but its not like other coins.How far we are from bringing staking or masternode?
the difficulty seems to be 111 during the whole week or so. But I hate the idea of staking or MNs because that kills the mining part and we would have 20 rich ppl interested in this coin instead of several thousand miners Wink.
hero member
Activity: 756
Merit: 579
So, when is the first halving?   Tongue
Halving of mining rewards? The mining reward started at 15.0 at block 1 and gradually decreases by 0.000001 Bismuth for every block found.

The reward is currently 14.385832 Bismuth at block 614168.  (15 - 614168 * 0.0000001)

Interesting, I never noticed that type of reward reduction in any other coins. Cool Cool

But i think this depends or difficulty also, not sure what the right formula but its not like other coins.

How far we are from bringing staking or masternode?

The reward does not depend on the difficulty, the reward is set to decrease linearly from 15 at block 1 to 0 at block 10M. Or as @bizzzy said 0.0000015 every block.

About the masternode implementation the team is working on it, we can't say "when" for now.

Undecided It seems the node sometimes happens to report about some error in line 2436 though I'm not familliar with dat python thang to see the reason what's going on there https://image.ibb.co/n7r4mx/image.jpg but that was v4.2.3.9 so I gotta upgrade stuff
UPD that issue has been fixed with the latest version of the node Smiley

So it's ok now? Hard to say what it was but I'm glad it's fixed- might have been some invalid mempool data, I've seen some recently incoming
I got this error when I'm running the latest version

Quote
node.py 2655
node.py 2457


For any issue with the node or wallet please come to our Discord and ask in there, thanks!
full member
Activity: 893
Merit: 135
Bitcoin is not a currency or asset. Its a MOVEMENT
So, when is the first halving?   Tongue
Halving of mining rewards? The mining reward started at 15.0 at block 1 and gradually decreases by 0.000001 Bismuth for every block found.

The reward is currently 14.385832 Bismuth at block 614168.  (15 - 614168 * 0.0000001)

Interesting, I never noticed that type of reward reduction in any other coins. Cool Cool

But i think this depends or difficulty also, not sure what the right formula but its not like other coins.

How far we are from bringing staking or masternode?
sr. member
Activity: 371
Merit: 252
So, when is the first halving?   Tongue
Halving of mining rewards? The mining reward started at 15.0 at block 1 and gradually decreases by 0.000001 Bismuth for every block found.

The reward is currently 14.385832 Bismuth at block 614168.  (15 - 614168 * 0.0000001)

Interesting, I never noticed that type of reward reduction in any other coins. Cool Cool
newbie
Activity: 6
Merit: 1
So, when is the first halving?   Tongue
Halving of mining rewards? The mining reward started at 15.0 at block 1 and gradually decreases by 0.000001 Bismuth for every block found.

The reward is currently 14.385832 Bismuth at block 614168.  (15 - 614168 * 0.0000001)
legendary
Activity: 1932
Merit: 1273
Undecided It seems the node sometimes happens to report about some error in line 2436 though I'm not familliar with dat python thang to see the reason what's going on there https://image.ibb.co/n7r4mx/image.jpg but that was v4.2.3.9 so I gotta upgrade stuff
UPD that issue has been fixed with the latest version of the node Smiley

So it's ok now? Hard to say what it was but I'm glad it's fixed- might have been some invalid mempool data, I've seen some recently incoming
I got this error when I'm running the latest version

Quote
node.py 2655
node.py 2457

sr. member
Activity: 371
Merit: 252
So, when is the first halving?   Tongue
hero member
Activity: 756
Merit: 579

Latest release is 4.2.4.0
https://github.com/hclivess/Bismuth/releases


- Added requirements for non-Windows users: You need to python -m pip install matplotlib for this version and on
- Added JPEG support to wallet
- Introduced basic wallet theme
- Redesigned wallet interface
- Added complete block statistics to the wallet
- Rewrote variables in the difficulty function to make it more readable
- Modularized difficulty function
- Wallet now automatically reconnects on interrupted connection
- Fixed a bug with sending to aliases, which caused newer wallets/nodes to freeze
- Mempool merging in rollbacks moved past ledger operations not to interfere
- Ledger now waits for mempool merge to finish (addresses txs getting occasionally getting stuck in pool wallets)
- CSV wallet export
- Plug-and-play system for themes
- Windows will now show dialogs when elevated privilege is needed
newbie
Activity: 27
Merit: 0
But what i found weird at your pool, is that it shows a flat hash rate, same as reported in miner and pool speed should be calculated by shares found not by miner itself...

Well, I have to disagree. Hashrate is constant, depends on the gpu and settings only, does not depend on luck. So it's a stable metric for the miner software, when calculated in a fair way.
How is it weird to report what the miner effectively computes? Every fair miner does that.
On the pool side, found shares are what counts, and this metrics is shown on the pool, with historical graphs for each miner address.

So, I don't get the "transparent" thing. I do report both accurate hash from the miner and accurate shares from the pool.
All data is there, raw, for everyone. It's not on others.

So when in some rounds i found very few shares(low speed at pool), lots of blocks where found. And rounds i found more shares(higher speed calculated) less blocks where found.. This could be solved by 2 hour rounds to even it out better, or maybe lower pool difficulty. It is more dependent with luck at current state of diff and rounds i believe, and not a 100% fair distribution of blocks found. As this happens a lot... I might be wrong man , not to old in this game but to me it looks unfair and luck are involved at payouts for each round..  But when in some rounds 12 shares found and other up to 24 its a lot with up to 50 % different for each round in shares found, would like to hear you opinion of this..  With lower diff the % would be way less if more shares where found..

So, here you're talking luck and variance.
Yes, there is a large variance from round to round (1 round = 1 hour).

This variance is caused by 2 things :


- network variance (I added the graph of the net variance on the dashboard a few weeks ago). When netdiff varies, so do the blocks per hours for the whole net.
- your personal variance. The more hash you have, the less variance you'll experience. On average, you may be unlucky on some rounds, but then more lucky than average on others. On average, everyone luck is the same, so in the long run you can't loose every time.

I do agree that
- Lowering pool diff
- having rounds longer than 1 hour
would make the luck factor less visible.
I may lower the pool diff later on, but my priority it to have a stable and reliable pool, and I have somehow to adjust to the global net hashrate and to the average miner hash.
So yes, small miners see the luck factor more. But on average, it's the same.

I do not see a transparency issue there. The shares are what they are, I report what the miner sends, I can't influence your miner on sending less shares on a good round Cheesy.
pool shows graphs and share counts, miner has logs with found shares, all is transparent. Some others pools do not even provide that data.
I think I'm the pool providing the most data.
On the other pool, you don't even have the historical data to compare and see your luck from hour to hour...

You could also lower your fees

I could, but this is no transparency issue. Pool fees are displayed on the pool website.
They are not on the one you say is "most transparent".

I also got significant improvment on other pools due to my main hash is AMD cards which your miner isn't very good at.

Bis-pool miner may indeed be better suited for Amds and computes the hashrate in the miner the same way, so can be compared to EggPool.
The other one does not compute the hash rate in the same way, so the hashrate improvement you saw is not a real one. You were not comparing the same metric.
(Not a transparency issue neither from Eggpool: I say how the hashrate is computed - number of tested solutions per second - coinsaurus computes a different thing and does not say what nor how)


So, I do understand your concerns, mainly Amd efficiency and variance because of low hash.
I get it that another pool may give better results for your case (but do your tests again, I'm 100% sure it's not the one you believe it is) and that's ok with me.

Honestly, I just don't get the lack of transparency you hold against EggPool , and why you say the other pool, the most opaque one, is the "most transparent".

Its not a huge deal, all pools lack some info, on coinosaurus i can atleast see my average pool speed for 1, I know what speed i have in miners. i think you put a lot of weight in to that transparency thing, and i think all pools lack some info about how much % you get of each block or your hash rate average graph. But i do think you would solve some issue at your pool with just lower diff.

And still encourage miner to test different pools...
jr. member
Activity: 34
Merit: 2
Helping the blockchain world build secure++ stuff!
That's quite a bit of new code for this project, rapid releases and all. Writing it in Python over C/C++ gives you quite a bit of advantages for not having to deal with casting, native memory allocations, etc.

Have you all had a audit of the code base, fuzzing or other security testing to shake out some bugs eg. in the daemon?
member
Activity: 140
Merit: 30
Bismuth core dev & EggPool.net Operator.
But what i found weird at your pool, is that it shows a flat hash rate, same as reported in miner and pool speed should be calculated by shares found not by miner itself...

Well, I have to disagree. Hashrate is constant, depends on the gpu and settings only, does not depend on luck. So it's a stable metric for the miner software, when calculated in a fair way.
How is it weird to report what the miner effectively computes? Every fair miner does that.
On the pool side, found shares are what counts, and this metrics is shown on the pool, with historical graphs for each miner address.

So, I don't get the "transparent" thing. I do report both accurate hash from the miner and accurate shares from the pool.
All data is there, raw, for everyone. It's not on others.

So when in some rounds i found very few shares(low speed at pool), lots of blocks where found. And rounds i found more shares(higher speed calculated) less blocks where found.. This could be solved by 2 hour rounds to even it out better, or maybe lower pool difficulty. It is more dependent with luck at current state of diff and rounds i believe, and not a 100% fair distribution of blocks found. As this happens a lot... I might be wrong man , not to old in this game but to me it looks unfair and luck are involved at payouts for each round..  But when in some rounds 12 shares found and other up to 24 its a lot with up to 50 % different for each round in shares found, would like to hear you opinion of this..  With lower diff the % would be way less if more shares where found..

So, here you're talking luck and variance.
Yes, there is a large variance from round to round (1 round = 1 hour).

This variance is caused by 2 things :
- network variance (I added the graph of the net variance on the dashboard a few weeks ago). When netdiff varies, so do the blocks per hours for the whole net.
- your personal variance. The more hash you have, the less variance you'll experience. On average, you may be unlucky on some rounds, but then more lucky than average on others. On average, everyone luck is the same, so in the long run you can't loose every time.

I do agree that
- Lowering pool diff
- having rounds longer than 1 hour
would make the luck factor less visible.
I may lower the pool diff later on, but my priority it to have a stable and reliable pool, and I have somehow to adjust to the global net hashrate and to the average miner hash.
So yes, small miners see the luck factor more. But on average, it's the same.

I do not see a transparency issue there. The shares are what they are, I report what the miner sends, I can't influence your miner on sending less shares on a good round Cheesy.
pool shows graphs and share counts, miner has logs with found shares, all is transparent. Some others pools do not even provide that data.
I think I'm the pool providing the most data.
On the other pool, you don't even have the historical data to compare and see your luck from hour to hour...

You could also lower your fees

I could, but this is no transparency issue. Pool fees are displayed on the pool website.
They are not on the one you say is "most transparent".

I also got significant improvment on other pools due to my main hash is AMD cards which your miner isn't very good at.

Bis-pool miner may indeed be better suited for Amds and computes the hashrate in the miner the same way, so can be compared to EggPool.
The other one does not compute the hash rate in the same way, so the hashrate improvement you saw is not a real one. You were not comparing the same metric.
(Not a transparency issue neither from Eggpool: I say how the hashrate is computed - number of tested solutions per second - coinsaurus computes a different thing and does not say what nor how)


So, I do understand your concerns, mainly Amd efficiency and variance because of low hash.
I get it that another pool may give better results for your case (but do your tests again, I'm 100% sure it's not the one you believe it is) and that's ok with me.

Honestly, I just don't get the lack of transparency you hold against EggPool , and why you say the other pool, the most opaque one, is the "most transparent".
member
Activity: 84
Merit: 10
How to send funds to cryptopia.co using message?
newbie
Activity: 126
Merit: 0
Any more detailed explanation of this project?
full member
Activity: 280
Merit: 105
This might be a stupid question, but what does 'custom implementation' actually mean? is it that Bismuth was created from scratch and it's not a clone?
new algo, wallet and node made in Python, I'll bet you won't see anything like that on Earth. Really unique stuff to the point of each pool having its own custom miner. I've noticed yet another pool http://bis-pool.net/ and they have their own miner of course so that makes three
newbie
Activity: 27
Merit: 0
Thanks for the review!

I'd like to point a few things:

2 pools with 10% fee and coinosaurus with 5% accused of taking 8% by the other pools
This is no more accurate. Coinsaurus now publicly admits to have 8% fees built in the miner, via randomly diverted shares.
Those were not accusation by the other pools, but facts checked by the bismuth team.

I might be wrong in my review, but as miners you should run your own tests. And tune miners at best possible way..

Agreed.
Your tests may not reflect the current state of the pools rentability. Don't take a single test, done at different times, as a stable comparison.
If you really compare again, you'll see that your results now will be very very different from what you report.


Also, what do you mean by "most transparent"? What is not transparent in Eggpool, what could I improve?

I know you are working hard with miner and pool.. But what i found weird at your pool, is that it shows a flat hash rate, same as reported in miner and pool speed should be calculated by shares found not by miner itself... So when in some rounds i found very few shares(low speed at pool), lots of blocks where found. And rounds i found more shares(higher speed calculated) less blocks where found.. This could be solved by 2 hour rounds to even it out better, or maybe lower pool difficulty. It is more dependent with luck at current state of diff and rounds i believe, and not a 100% fair distribution of blocks found. As this happens a lot... I might be wrong man , not to old in this game but to me it looks unfair and luck are involved at payouts for each round..  But when in some rounds 12 shares found and other up to 24 its a lot with up to 50 % different for each round in shares found, would like to hear you opinion of this..  With lower diff the % would be way less if more shares where found..
You could also lower your fees
I also got significant improvment on other pools due to my main hash is AMD cards which your miner isn't very good at.
Pages:
Jump to: