Topic: ◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈ - page 102. (Read 284545 times)

Should only be an few minutes to 2-3 hours until we can verify the results (if it's just the two of us), do you wish to join in and help speed things up?

Myself and hack_ are @ block 201763 , we want to observe behavior @ block 201795. If we are satisfied that bids are being updated every 95 blocks we will upload the final set of changes and hack will provide you with nodes to sync from. This allows a 5 block interlude before any %900==0 payout block.

When we start building the network we hope people will help us with SOLO mining only till we pass the first payout block so we can also observe payout inclusion, if we succeed then there will be one minor update afterwards that will re-instate some of the stricter BN rules as well as a new rule set that

1) Ensures BN only mining (may be a bit slow until i get time to consult with fellow developers)
2) Ensures NO one BN can dominate the network (still trying to decide on dynamic limits, within reason )

How many one masternode can earn per day?

Expecting the source ...

So, is it safe to use now new git binaries and use to 201600 chain ? If blockchain is moving so I will be able to start my BNs ?

Want to know this because now I can manage it, but soon I will have no advance access for a few days.

Quite true,

Bitcoin solved quite a few issues, but it's design as is, is extremely primitive and not in any way suited to today's highly complex financial system. The concepts of supply, control and authority are not even considered by everyday users, that is all technical....when one sees how the world of finance is changing on a global scale , especially corporate and personal finance, one realizes that existing
solutions are ill equipped to deal with the increasingly specific and realtime demands of customers. So we need to have the final product being an easy to use , universally accepted , global/cross platform solution.

Fun read, albeit not necessarily for all the right reasons. For a moment smooth seemed uncharacteristically semi-rational:
But maintaining a grasp on reality proved too taxing to keep up:

Some classic g j higgins in that thread too...  



BCR is taking two crucial steps beyond aiming for better and more efficient consensus apparatus though - firstly, separation of distribution from transaction verification, and consequentially, by the method of that separation (bid, buy, back) , funnelling investment directly into the currency itself, instead of orthogonally (at best) into hardware and utility companies.

At the risk of sounding mental.. I guess of you were not seeing a node that would be winning if you recieved a block your node could validate it based on seeing that the coins are in place under the masternode pubkey. Might be some forks but pos is the same way. You'd have to be online to submit a solved block otherwise be skipped like dpos. A banknode realizes it will win the next block based on what it sees, and compiles the transactions for submission. If it gets orphan ed by another node with a higher (or lower?) Then oh well?

Say when, I'll chuck some more into the pot.

Blockchain has been moving for a while now, going to try mine 95 blocks and see if bids get updated (tlc made a bid) then i'll ask a group of people to slowly rebuild the network with me, massive emphasis on there not being a single point of failure in the network, we should not have to rely on seed nodes, this is where some forking problems are coming from user connects to seed nodes and leaves it that...you need to be connected to at least 3 or 4 different peers, that way if one goes off the rails, your node continues on the longest chain. 70009 nodes are being used to sync up to 201600 then you start getting the new blocks. The reason old client will not be able to process these blocks is that i have extended the period of leniency to BN payments , this allows users time (about 2 days) to spin up BNs. Also hopefully, we can quickly mine our way to a payout block and observe the situation.

It's imperative that we ensure that bids are added to the block.

Highly interesting take on how to deal with this. We need to come up with a dynamic structure that determines how long until a BN until a BN must produce at least one block......without invalidating valid blocks........Your node may report a BN count of 67 and mine could report a total of 68.... if the extra node produces a block your node will reject it even though it's perfectly valid.

Need to design it in a way that each node can even try verify a block produced by a node it does not reflect as a BN yet....maybe add an extra field to blocks...BN signs with key of 50K input....and points to input location.

Meanwhile, eyes are slowly being opened

This is an idea out of left field but.. could the banknode winner selection process be tweaked to secure the network by itself? Burst does hard drive mining by storing nonce in the prefix of storage space available. Could we use the bank node pub key as a closest to zero match that currently finds the next banknote to get rewarded to just statically know which one would get the next block then run a hash include TX and the network could all easily see and compare from the list of active banknotes that the winner was active for x ammt of time, and had not solved a block in a certain period of time. In a system like this you could set an almost exact black time. And most nodes would already know the result since they can see all the banknkdes. Anyways just a completely random idea. You could still pay into the bid system reserve as normal.

*edit please excuse any misuse of tech jargon.

no, i mean this one, quete of yours:
"Also if you have noticed, there's over 800 nodes running the old wallet version that just popped up out of nowhere."

Much the same issue i hope we can resolve. very delicate stuff though, I am trying to formulate a form of dynamic consensus over block produced by BNs...

A node has to be a BN....and only eligible to produce 1 in every 5 blocks if the Bn count is higher than 5.....all the while the look up must be inexpensive (computationally)

I was not envisioning a large increase, as this would diminish the amount of BCR being bid for and thus decrease backing, but a token extra, maybe 18 -> 20 for example. It's not a big deal to me, and believe me I do appreciate there are more urgent matters, just thought it was worth airing the notion.


There are different messaging categories, I think the currency-wide stuff should be verifiable at least. I have no issues with going closed source* as long as the blockchain and associated machinery remains transparent where it needs to be, but I can obviously see uses for private comms capability. I think the messaging can be subject to ongoing review, but I like the idea of a tx-like fee (going to The Great BCR Barbarous Relic Stash of course) if it's adding bytes to the chain and infrastructure costs.



System as it stands is fine by me, I'm just tinkering with asset backing projections.





*I could go on about this but the tl;dr version is, "NOBODY CARES, except cryptognats, and this is the cunning bunch running supposedly privacy-centric apps on proprietary OSes while blathering about how decentralised their pool-mined currency is."    

eg. DASH:

Blockchain security right there    - and it's been this bad for well over a year, with 3 pools owning 90% of the hash.

@bitcreditscc

Maybe I could try to help with a little hash soloing to get past the fork.... should I just mine it and that would help?

You said my code did not work for you, but it works here in BCR.... Every single block since i instated the new consensus rule has contained a BN payment, the reason that our chain stalled recently is partly because someone was producing blocks without BN payments , which are ultimately and inviolately invalid.

just add this :- to your connect block function

did you solve the problem to populate network with masternodes without funds?

Interesting idea, we can put it on the docket....man we have a long list of to-dos

As for upping the BN portion... I am not averse to the idea but we need to

1) Fully justify it and
2) Choose a reasonable number

This of course will have to be implemented in the next update, i already have 6 of my work horse machines trying to solo some blocks so we get past the current fork. Unless we delay the update until Monday (allows me time to also consider some of the changes i have in mind)

Just so you know, i am struggling with the logic behind service messaging, my problem is as follows and i would like some input:-

Should i attach messages to transactions and store them on the blockchain or maintain a side channel? Should they be in the clear or encrypted? Should i reduce the length the the exact max for msg formatting or allow messages and small pieces of data to be added to the chain (one click fashion) ? Should i mandate a cost for sending messages thereby monetizing Base nodes that only offer tx and message relay service?

To soothe the nerves of some of our users , the next update may have to be a UI only update.

Also I am thinking we should go closed source after this for a while.... anyone object? What would be the best software license to use? Should I craft a new one ?

Block reward halvings...i removed those in favour of the new distribution method..... do you think i should re-instate them? Or should we cme up with something more customized to suit our new distribution model?

Are there future block reward halvings / emission reductions?

main.cpp:1483-1499 doesn't indicate any, where else should I look?