Topic: [TESTNET]Bismuth - New Language, Interpretation Engines, DAPPs - page 19. (Read 49748 times)

3 days of mining and I do not get.only in the first 4 hours I got 50 coins.why?is it hard to mining these coins?

any algo can be both cpu and gpu ... what really count would it be efficient on gpu ... some algo are not like xmr

This coin will be CPU only, or it will have GPU miner at launch for win and linux?

yes, you mined.
miner.exe is counting up the attempts.

how to start mining?


I mined or not

Just found this project, do not know where the advantages of your coins in it? How to install this coin mining, the new wallet, but not mine! Could you give me some coins, I will test! My wallet address 15d1230781b3803f60d400354d8090459e9193b8b3fe2082e377bc09

I tried to re/sync with an active node from a lower block and it appears somewhat problematic. Not sure if more active nodes would fix it, but I think some concepts need to be redesigned.

Hi, the competition is higher these days for the blocks, but you should get lucky eventually

Hi, little question about mining, so i leaved stable version for few days mining and no reward, its ok or just bad luck?))

Hi, that's because it got reshuffled, there was a different peer who had a higher block fork at that moment. That's why we need transaction grouping like every other coin has

Yep, running smooth but why do I have a block posted some minutes later.

Version 0.931 confirmed stable... for now

Not yet, it is still in a testing phase
and here, have a new version

https://github.com/hclivess/Bismuth/releases/tag/0.931

is there any exchange which this coin is already added?

New version is out, let's see whether the threads get clogged on incoming transactions or not

https://github.com/hclivess/Bismuth/releases/tag/0.93

I needed to revert the latest version
I'll do it differently

Idea for an improvement: pick the most frequent signature from mempool as the next transaction to reduce friction. Now it's handled by timestamp if I remember correctly.

EDIT: Timestamp organization will be just as effective in shared global mempool, and should improve timestamp progression with the additions in the upcoming version

I appears that the fork has been resolved, because the lower network majority (51%+) disconnected and by the time they reconnected, the higher peer was already 51%+ of the network (probably converted peers to the fork in a 1v1 and perhaps 1v2 situations). No code has been put in place to prevent such forks yet, although optimizations in confirmation mechanisms are still being contemplated.


Code adjustment proposal:

a, You will need a block to be the most occuring in the consensus pool in order to add a confirmation, such implementation should not be very difficult, but I need to handle the pool purging first, so that there are no leftover peer opinions after disconnects.

It is completely feasible to expect that few active nodes would prevent a fork situation in the future, but more testing needs to be done.

b, Perhaps another solution would be not to allow nodes add new transactions without a certain number of local confirmations (3?), so the first transaction has time to sink in the network across multiple nodes. This rule needs to be implemented inside nodes and triggger after receiving the transaction, so the malicious nodes have no advantages.

This appears to be the more reasonable way to go, since it does not rely on not so optimized consensus pool and only requires delay implementation between mempool.db and ledger.db in the digest_mempool() function

Impact analysis of b:
Malicious nodes will still be able to set up a fork by creating a pool of nodes isolated from the majority of the network. However, their fork will be rejected by the 51% rule upon rejoining the network, as long as the majority does not swing to their side. In conclusion, this adjustment makes network reward obedient nodes for cooperation. The negatives are an obvious (but necessary) slowdown of the transaction flow, while still evading the Bitcoin model of PoW.

I think that the anti-rollback rules are set too tight now. I will do a few experiments and do according changes.
EDIT: there is a node of lower block height who does not roll back, investigating

@block 13592

It looks like nodes decided to reject the higher peer on a different fork by confirming each other in consensus. So while one person might have block 13751, all others have agreed on 13592.
The higher peer just does not have enough power to to convince others to rollback, because everyone made it to block 13592 of the 13592 chain, but noone is at block 13592 of 13751 chain.
Can you confirm that your 13592 hash is 1f8d8aa3e8f8bd44d7c8fa9dc7101e03ae305b8e355ae5b3deee72a9?

This is basically intended, but I need to add a mechanism for non-malicious higher block peer to roll back to consensus and start resubmitting blocks on the majority chain

This will make the 51% rule more powerful and we will become the first non-pow coin with such feature and security advantages.

Hi, not yet, but I will work on variable mining difficulty now