[TESTNET]Bismuth - New Language, Interpretation Engines, DAPPs

[HCLivess]

have a bug, fixing

[1713278189]

1713278189

[HCLivess]

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

bugfix for stuck rollback (wrong txhash data exchanged)
you cannot force nodes to rollback unless you own 51% of the network or more

new testnet protocol version, so please do update, otherwise your node will be rejected

[Deff]

My bismuth is not where it all. Block Height - 12102
 

[HCLivess]

sent to all (I hope)
 

[kahir]

wooh it worked

Send me coin plss my wallet is empty 

05f304c1a4ff283d2f44c90d746b7d05e2be0897465634568312e2d2

sent

[raetsch]

wooh it worked

Send me coin plss my wallet is empty 

05f304c1a4ff283d2f44c90d746b7d05e2be0897465634568312e2d2

sent

i have sent you some, but have only one external connection. did they arrive?

[HCLivess]

Greetings, my friends. We have successfully stabilized the network around block 12787

[Deff]

Yes stabilized - 12959

[HCLivess]

Haven't seen such consensus since we started. Beautiful.

2016-08-11 23:13:39,003 consensus_add(301) Consensus IP list:['127.0.0.1', '62.153.176.78', '46.37.194.32', '62.210.161.232', '133.130.112.228', '196.217.88.95', '90.222.119.117', '175.126.37.125', '98.108.241.22', '93.157.47.12', '94.113.207.67', '114.6.27.87', '70.188.42.244']
2016-08-11 23:13:39,003 consensus_add(302) Consensus opinion list:[13073, 13073, 13073, 13073, 13073, 13073, 13073, 13073, 13073, 13073, 13073, 13073, 13073]

[HCLivess]

I'm having negotiations with programmers in real life (3 best I know), who have professionally worked on large corporate projects, to join our cause.
They would be paid from the Clarity crowdfunding, but Bismuth would be the first to benefit from it.

[Karbovme]

ETA for bitsmuth main net?

[HCLivess]

ETA for bitsmuth main net?

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

[HCLivess]

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.

[HCLivess]

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.

[HCLivess]

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

[HCLivess]

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

[HCLivess]

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

Confirmation handling reworked
All new transactions now require at least 5 confirmations for the previous block before added to the ledger
Nodes which are no longer active are now purged on startup
Nodes which send out too many rollback request will now decrease confirmations for their latest blocks and roll back
Typo fixes

Some GUI optimisations are still needed

[coinmenace]

is there any exchange which this coin is already added?

[HCLivess]

is there any exchange which this coin is already added?

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

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

Rollback from future fork against majority fixed

[HCLivess]

Version 0.931 confirmed stable... for now