Topic: ◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈ - page 81. (Read 284526 times)

sync under the new rules is inconsistent, this is because i made the fatal mistake of relying on information that is not built into the database/blockchain, therefor making consensus an improbable task. I have 6 nodes @ 210005, 1 @ 210006 and two @ 210004. I've been trying to get a total of ten nodes to all sync from start, no dice.

That doesn't mean i give up though...rather (sorry guys), i'm atking another few hours to two days. I want to write a function that parses the chain and creates a new database, literally during sync, it will detect all nodes that have received 50K and calculate their current balance. So if an address balance > 50K, it is considered a valid miner, even if it is not an active BN. I know this is far from ideal , but i've been working on the earlier solution for + two days and can say with certainty that it has too many flaws to be deployed ina a way that a average user just fires up and goes.

Yes we can bootstrap everyone, but that is complicated and not ideal if we plan to have a user friendly system.

So, each node will build it's own database, this results in accurate data based off the chain. Another thing is that this now removes the strict active BN rule, meaning anyone with 50K can mine a block. To increase the cooperative measure of mining and remove incentive for competition, i will place a hard limit of 1/20 blocks. Meaning that a user who intends to dominate the network needs 550K BCR and enough hashpower to fight off the rest. considering this is the situation, if there is popular support we can raise the bar to 1/40, meaning a user needs minimum 1050000 BCR and a ton of hash to have >50% of the net.

This increases the size of the pool of miners without compromising security and our intended model of cooperative mining. It does likely reduce the likely hood of more BNs appearing unless someone wants to get both mining rewards and BN rewards.

Really sorry about the delay guys, but  i saw no point in releasing code that would leave average users scratching their heads trying to sync. I'll keep you posted

trying the last set of fresh syncs, QT and daemon. If it all comes out fine, i'll mine a block syncing all clients, then we can all move on. I'm hoping the iterative testing and different tests i've run have exposed all the bugs that would have prevented a smooth continuation.

My wallet synced up to 210004 blocks, but still says Last block was generated 39 hours ago. Is this normal for the new wallet?

How to disable non working nodes?

Thank you

actually running some tests on a VPS , yeah i thought about that, but i have to also consider a malicious multi-BN owner trying to do a time-warp like attack.

Btw...Bns don't rely on blocks passing to announce themselves.

so this will happen anytime there is an update?  it doesn't update the node list cause it won't sync...

is there a way you can tell it to relax some of the rules if the blocktime is to far out?  or are we going to have to hardfork?

I'm almost done, all that remains is resolving 2 conflicts that are happening during initial sync.

The BN requirement is preventing nodes from fully syncing @ start. I can';t just overlook with a switch because that opens up potential avenue for exploits. Neither can we just bootstrap, it has to sync fro start for it to be a viable solution.

  still working better than the test version that one was syncin with the highest blockchain.

this one isn;t direct hit from only good peers. one error with startup, but i didn;t check admin rights just started it, win7 compatibility mode neither,,
still second try started like a charm, or did also use my own wallet.dat file that is 40mb sized, with my own conf.file and mybanknodes.txt, and in total 20 files in my bitcredit folder.

think is syncin really fast as well. bid, back shows everything i guess, amount of blocks, not the bids,
if wan't to debug just /add /debug in your shortcut,. creates might create very big debug.log file inside your folder.

what is in options? advertised balance, what should i type there, just 1million?
how does it work?

thanks in advance guys

Transaction view isn't causing any probs on linux (never has) compiled from the latest master, but can't restart BN despite being synced up to 210004, "banknode start" and "banknode debug" give me:

"sync in process. Must wait until client is synced to start."

can confirm this, tried to setup a node. no dice. If the transaction view is causing this maybe we should separate it from the main view..or disable it until a user requests to see the list?

Your last 'test' build didn't crash a single time. This one does, not with a new fresh wallet.dat though.

runs and starts fine, used an olde blockchain copy from before 210000 it synced to 210000 real quick but hasnt gotten past it, ive tried the 18.3 nodes listed on chainz. no love

*edit i got it synced on 210004 had to remove then replace my wallet file and synce from before 210000 again.


PROBLEM===

the build linked above crashes any time i do setgenerate true 1
also in case it needs to be a banknode.. since the chain is so far behind, it wont let me start my banknode as its still "syncing"
so i guess hopefully someone solves a block :/

without block movement no more network or transfers... lol
i can't make the transfer required to setup a node... !!!
new wallet can't sync, even though it is... 210004!!! 27 hours behind
this is so much better than me getting blocks! LOL

doesntmatter

0.30.17.3
Windows 64bit - update commit 8b76deb82f

0.30.17.3.164bit-8b76deb82f.7z
https://mega.nz/#!bs0kDZKA!fMol_D_qPJJglLhVMwMZG7hSejBa6yqEgcCz_E0hskY

just give me a moment to give the all clear, im currently looking over the voting code again, i want to avoid further minor patches

Silly question as I am behind and just catching up.

Which is the current version of working wallet we should be using? Wallet Links  -- Current Version 0.30.17.2 from the OP or 0.30.17.2.-fixssl from the last version in the thread?

One of the issues that held me up all this time. I'm fairly confident we are fine now, though users who deviate from instructions will suffer forks.

Strange....i had two catastrophic crashes this weekend  HHDs screwed, lost 100K  BCR in the mining wallets.

To avoid being slowed down by my old hdds i'm gonna open up my private nodes top the public again.

After this we have a big issue to discuss.

Thanks.

Weirdly, after crashing my laptop earlier playing with Blender, I'm only able to sync back up to 210001...

There's no need to donwload the whole blockchain, I had used some chain before 210000 block.

In debug.log found out that some nodes even if are in official chainz Node List for /Section32:0.30.17.3/ are misbehaving , so I deleted them :


188.193.114.167
91.230.123.101:8877 (nodes on a a previous version and on wrong block)
91.230.123.11:8877

only left:
41.191..238.238.189 (looks like 2 first nodes are inactive)
82.211.1.181.:8877
146.90.136.80 (this is good)

This looks like state for now and can change in second, but I finally am in sync at block 210004  

ok ill just wait for the formal release (win binaries) to get running again.

It's quite alright. mining is not an issue right now, there was a problem with a premature pointer that has been resolved, so sync from the start is not an issue anymore, also since we had already slowed down i'm taking the time to try and find the causes of the many issues raised. IN a few hours the net will be moving smoothly again as diff has already adjusted down.