◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈

[tombcoin]

Nevertheless we need a running blockchain. Without blockchain we will do nothing.
lg t.

[cisahasa]

i will still follow this one..
chain problem has been solved for hxx.
we did forks all the time..
but still at info i now have we will do a coin swap.

[bitcreditscc]

Hello all, i'm sure we'll have the blockchain running in a few hours, but i'd rather not be rushed. We are now in virgin territory using bespoke code that is largely untested and while the logic behind our actions is sound and our attempts at coding it are moving forward you must make allowances for mistakes and slow downs. We do not have a large team or even any code reviewers.

What i am trying to say is that (you may have noticed) I re-labeled Bitcredit as an ALPHA project, this was in anticipation of the complex problems i rightly guessed we would face. Right now we have a problem of serial forking as a result of issues in getblocktemplate. I believe i may have found the solution, but that remains to be seen. Give me roo and space to work and i figure things out eventually.

Already some users (i prefer if you reported on github..make documenting and referencing easier) have reported some of the issues they faced so i work based off that and what i also observe.

As for windows, i'm sorry to hear that there are problems again. I know full well that we need to resolve that, as well as simplifying and enhancing the UI, it's on the books , but once again i am one man. Perhaps if this was my full time job we could see a bit more work squeezed in every day, but like most of you, i need to earn, and this has been exacerbated by recent life events. Please be patient, i am working as well as i  can.

[hack_]

i'd caution against hounding an already stressed man, i talk to him regularly, he's probably more worried about BCR than the rest.

just my 3.8 credits

btw, please stay off the git for a few more hours, we are using the master branch to speed up the code sharing process as such you may bump into errors. wait a while and we'll let you know when it's all clear

[thelonecrouton]

Suggestion: when mining is BN only, can all tx fees get added to the asset backing?

Reasoning: individual BN ops aren't going to be greatly affected, they are already paid their share of the block reward, but a steady trickle of fees over time will help the currency's backed %, making it that bit more appealing to investors.


I don't know if this would complicate what's currently being worked on, and it's not anything urgent, just a suggestion for some time in the future maybe.


On the subject of BN reward though, since BNs will in future be using presumably ~100x more CPU each, is there a case for upping the BN % a little to cover running costs? Running multiple BNs on $2/month VPS instances is no longer going to be an option.

[thelonecrouton]

Are there future block reward halvings / emission reductions?

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

Code:

CAmount GetBlockValue(int nHeight, const CAmount& nFees)
{
    CAmount nSubsidy = 50 * COIN;
    int halvings = nHeight / Params().SubsidyHalvingInterval();
	if (nHeight< 4000){ nSubsidy = 5* COIN;}
	if (nHeight> 20999 && nHeight <30000 ){ nSubsidy = 25* COIN;}
    // Force block reward to zero when right shift is undefined.
    if (nHeight > 200000){ 
		nSubsidy = 18* COIN;
		if (nHeight%900==0)
		{
			nSubsidy = 30000* COIN;
		}
		
		}
    return nSubsidy + nFees;
}

[bitcreditscc]

Suggestion: when mining is BN only, can all tx fees get added to the asset backing?

Reasoning: individual BN ops aren't going to be greatly affected, they are already paid their share of the block reward, but a steady trickle of fees over time will help the currency's backed %, making it that bit more appealing to investors.


I don't know if this would complicate what's currently being worked on, and it's not anything urgent, just a suggestion for some time in the future maybe.


On the subject of BN reward though, since BNs will in future be using presumably ~100x more CPU each, is there a case for upping the BN % a little to cover running costs? Running multiple BNs on $2/month VPS instances is no longer going to be an option.

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?

[cisahasa]

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

[bitcreditscc]

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

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

Code:

	if (pindex->nHeight>???????){
		
		int64_t bnsubsidy = GetBanknodePayment(pindex->nHeight, block.vtx[0].GetValueOut());
		bool foundPaymentAmount = false;
	
		for (unsigned int i = 0; i < block.vtx[0].vout.size(); i++){
		  if(block.vtx[0].vout[i].nValue == bnsubsidy)
              foundPaymentAmount = true;
		}
	
		if (!foundPaymentAmount)
			return state.DoS(100, error("ConnectBlock() : no banknode payment ( required=%d)", bnsubsidy));	
	}	

[proletariat]

@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?

[thelonecrouton]

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

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.

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 ?

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.

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?

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]

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.

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)

[cisahasa]

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

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

Code:

	if (pindex->nHeight>???????){
		
		int64_t bnsubsidy = GetBanknodePayment(pindex->nHeight, block.vtx[0].GetValueOut());
		bool foundPaymentAmount = false;
	
		for (unsigned int i = 0; i < block.vtx[0].vout.size(); i++){
		  if(block.vtx[0].vout[i].nValue == bnsubsidy)
              foundPaymentAmount = true;
		}
	
		if (!foundPaymentAmount)
			return state.DoS(100, error("ConnectBlock() : no banknode payment ( required=%d)", bnsubsidy));	
	}	

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."

[jasemoney]

*image

..... " 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) "

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.

[bitcreditscc]

*image

..... " 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) "

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.

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

A common complaint of DPoS is that it can't be decentralized because it has the word "delegated" in the title, yet anyone mining with a pool in PoW is doing the exact same thing.  Satoshi made the claim of one CPU, one vote, yet you're delegating your vote to the pool owner in PoW pool mining.  Some argue you are not delegating in PoW because you can solo mine.  While this statement would be technically correct, the miniscule portion of the Bitcoin userbase able to do so makes it functionally infeasible.  It's only a question of what percent of the hash rate is being delegated at any given time.

[bitcreditscc]

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.

[thelonecrouton]

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

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

[jasemoney]

*image

..... " 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) "

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.

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

A common complaint of DPoS is that it can't be decentralized because it has the word "delegated" in the title, yet anyone mining with a pool in PoW is doing the exact same thing.  Satoshi made the claim of one CPU, one vote, yet you're delegating your vote to the pool owner in PoW pool mining.  Some argue you are not delegating in PoW because you can solo mine.  While this statement would be technically correct, the miniscule portion of the Bitcoin userbase able to do so makes it functionally infeasible.  It's only a question of what percent of the hash rate is being delegated at any given time.

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?

[thelonecrouton]

Meanwhile, eyes are slowly being opened

A common complaint of DPoS is that it can't be decentralized because it has the word "delegated" in the title, yet anyone mining with a pool in PoW is doing the exact same thing.  Satoshi made the claim of one CPU, one vote, yet you're delegating your vote to the pool owner in PoW pool mining.  Some argue you are not delegating in PoW because you can solo mine.  While this statement would be technically correct, the miniscule portion of the Bitcoin userbase able to do so makes it functionally infeasible.  It's only a question of what percent of the hash rate is being delegated at any given time.

Fun read, albeit not necessarily for all the right reasons. For a moment smooth seemed uncharacteristically semi-rational:

The bigger question behind all this in my mind is whether crypto actually solves any useful problem that anyone cares about. Outside of gold bugs and some anti-Fed zealots no one really cares about "fixed supply" and all that stuff. The existing banking system works pretty well for swipe-your-card-and-pump-gas. Likewise for e-commerce. With Paypal, Swipe, etc. even ordinary people can do convenient payments via the existing banking systems. Where is the compelling use case for crypto coins? I'm not sure it exists

But maintaining a grasp on reality proved too taxing to keep up:

I disagree with this analysis. In analyzing incentives it is often important to have an option to do something even if that option in rarely exercised in practice. For one thing, it puts a cap on the degree of abuse that can be performed by those who can be opted out. Now you can vote out particular delegates in DPoS but you can't opt out of the delegate system, you can only do a "meet the new boss same as the old boss" switch. If the abuses are inherent in the power structure, then replacing Boss Alice with Boss Bob will not fix them.

However, in Bitcoin if the pool system were to be became sufficiently abusive (but it likely won't by the argument in the third sentence of the previous paragraph), miners really could just opt out entirely and solo mine. It would have a cost, but the cost is bounded and even measurable.

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.

[bitcreditscc]

Meanwhile, eyes are slowly being opened

A common complaint of DPoS is that it can't be decentralized because it has the word "delegated" in the title, yet anyone mining with a pool in PoW is doing the exact same thing.  Satoshi made the claim of one CPU, one vote, yet you're delegating your vote to the pool owner in PoW pool mining.  Some argue you are not delegating in PoW because you can solo mine.  While this statement would be technically correct, the miniscule portion of the Bitcoin userbase able to do so makes it functionally infeasible.  It's only a question of what percent of the hash rate is being delegated at any given time.

Fun read, albeit not necessarily for all the right reasons. For a moment smooth seemed uncharacteristically semi-rational:

The bigger question behind all this in my mind is whether crypto actually solves any useful problem that anyone cares about. Outside of gold bugs and some anti-Fed zealots no one really cares about "fixed supply" and all that stuff. The existing banking system works pretty well for swipe-your-card-and-pump-gas. Likewise for e-commerce. With Paypal, Swipe, etc. even ordinary people can do convenient payments via the existing banking systems. Where is the compelling use case for crypto coins? I'm not sure it exists

But maintaining a grasp on reality proved too taxing to keep up:

I disagree with this analysis. In analyzing incentives it is often important to have an option to do something even if that option in rarely exercised in practice. For one thing, it puts a cap on the degree of abuse that can be performed by those who can be opted out. Now you can vote out particular delegates in DPoS but you can't opt out of the delegate system, you can only do a "meet the new boss same as the old boss" switch. If the abuses are inherent in the power structure, then replacing Boss Alice with Boss Bob will not fix them.

However, in Bitcoin if the pool system were to be became sufficiently abusive (but it likely won't by the argument in the third sentence of the previous paragraph), miners really could just opt out entirely and solo mine. It would have a cost, but the cost is bounded and even measurable.

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.

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.