◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈

[bitcreditscc]

The results from the debug.log file running the BCR wallet-QT on a clean Windows 10 x64 Virtual Machine:

• First time starting wallet - CRASH: http://pastebin.com/FLTJXrTD
• Second time starting wallet - CRASH: http://pastebin.com/ngSf9n2i
• Third time starting wallet - WORKS: http://pastebin.com/MqHr8FfL

Inspection of the wallet yielded some results that will be evident in the update, due to the start-up process for QT being a single thread, it was too busy and some events were not being handled properly, to that effect, a lot of the math has been moved to the trust engine and to raw data extraction.

I'm glad you can get your wallet running now, albeit with some stumbling.

[bitcreditscc]

Why anyone runs Windows is beyond me, and if you think asking Win 10 politely to stop spying on you is really going to stop it spying on you...    Android and OSX/IOS should also be considered zero-privacy environments. Linux alone isn't going to protect you but it's a hell of a head start. The DASH crowd in particular are hilarious, running a privacy centric currency on proprietary black box OS's... idiots.  


Anyway, for purely comedic value I present some idiocy of my own, a crude, assumption-laden, and mathematically unsound little lunchbreak script; I was wondering what effect money being used to support BCR might have on the market price, instead of that money being pissed away on useless PoW...

Code:

#!/usr/bin/python

# BCR in circulation on day distribution by bidding starts
MoneySupply = 20000000  

# BCR price on day distribution by bidding starts		
MarketPrice = 0.000002  			

# total BCR minted per day
BCRTotalDistributedByBid = 40000

# appx. BCR minted per day that would have gone to miners
# we assume that the BN to total MoneySupply ratio remains steady
# currently there are ~100 BNs (5000000 BCR) against a MoneySupply of ~19000000 BCR
# ~ 25% of daily 40000 BCR minted
DistributedByBid = 30000

# we start with zero BTCBacking and thus zero AssuredMarketValue
BTCBacking = 0					 
AssuredMarketValue = 0				 
 
# we'll iterate through 365 days
n = 365

for x in range (1, n):
	
	print "Day " + str(x) + " : " + "MoneySupply = " + str(MoneySupply) + ", MarketPrice = " + str(MarketPrice)
	print "MarketCap = " + str(MoneySupply * MarketPrice)
	print "BTC Backing = " + str(BTCBacking)
	
	# each day the AssuredMarketValue (per BCR) rises a bit, we'll be pessimistic and assume
	# the DistributedByBid is bid for at 50% of the current MarketPrice
	AssuredMarketValue = AssuredMarketValue + (((DistributedByBid * MarketPrice) / MoneySupply) / 2)
	
	# we'll assume that the market value per BCR increases in proportion to the BTC backing
	# again we'll be pessimistic and assume it only lends half of it's actual value
	MarketPrice = (MarketPrice + (AssuredMarketValue / 2))
	
	# each day the money supply goes up by 40000
	MoneySupply = MoneySupply + BCRTotalDistributedByBid
	
	# we'll assume that each day the BTCBacking increases by 30000 BCR bid for at current market price
	# eg. 30000 BCR * 0.000002 = 0.06 BTC
	BTCBacking = BTCBacking + (DistributedByBid * MarketPrice)

I added the halvings at lines 31 and 35 because the initial results were frankly outrageous. As it is it yields this:

Code:

Day 364 : MoneySupply = 34520000, MarketPrice = 0.000493307694068 BTC
MarketCap = 17028.9815992 BTC
BTC Backing = 953.107444541 BTC

The glaring problem with this supersimplistic model is the discrepancy between MarketCap and BTC Backing, but then, BTC has a large (in cryptognat terms) Market Cap and exactly ZERO backing... and each US$ in existence is backed by $5000 or something of outright debt...

These numbers are not meant to be taken seriously, it doesn't take into account future supply curve reductions, and I certainly don't think all BCR assets should be held as Backed-By-Bugger-All-BTC, but I think it does help show just how much money is wasted on PoW, which could be backing the currency instead.

It will be even stronger with diversified backing. now would be the prime time to hoard gold.

As part of the extended toolkit , we can write a calculator for users

[LucD88]

Inspection of the wallet yielded some results that will be evident in the update, due to the start-up process for QT being a single thread, it was too busy and some events were not being handled properly, to that effect, a lot of the math has been moved to the trust engine and to raw data extraction.

I'm glad you can get your wallet running now, albeit with some stumbling.

I managed to get it started on a freshly installed Virtual Machine running Windows 10 x64. But on my desktop running Windows 8.1 x64 it's still not opening, thus my coins remain on the exchanges. For me an updated wallet-QT can't come quick enough!

[thelonecrouton]

It will be even stronger with diversified backing. now would be the prime time to hoard gold.

Bidding changes the purchase dynamic significantly from the exchange model, where the spot price often doesn't mean much if you want to buy or sell in any volume. I suspect this will play out in our favour.

I've been playing with the model a bit, I'll see if I can knock up a little graphed projection utility if I get some free time this weekend. I think the view a little ways down the y axis will please early investors and hopefully help illustrate for others just what a difference direct backing is going to make.

[BarTeam]

Inspection of the wallet yielded some results that will be evident in the update, due to the start-up process for QT being a single thread, it was too busy and some events were not being handled properly, to that effect, a lot of the math has been moved to the trust engine and to raw data extraction.

I'm glad you can get your wallet running now, albeit with some stumbling.

I managed to get it started on a freshly installed Virtual Machine running Windows 10 x64. But on my desktop running Windows 8.1 x64 it's still not opening, thus my coins remain on the exchanges. For me an updated wallet-QT can't come quick enough!

If not running a QT server bank node.. you can run the win 10 wallet in lite mode... works for 24/7...

[bitcreditscc]

Working on IBTP, for now it will just be in listen mode. Once we can do so and interpret other chains' communication we can start interacting with them.

(theoretical)

Ever thought of a blockchain of blockchains? Once asset nodes go live, one can literally map other blockchains (highly pruned) onto the BCR chain, meaning that should a catastrophe happen, they can bootstrap from the BCR chain.

[bitcreditscc]

For us to have a smooth transition into BN based mining, we need the mining difficulty to be solo- friendly to that effect I have asked hack_ (pools) to start gradually increasing the fee, the intended effect is to slowly wean the chain from reliance on high powered miners and instead focus on solo mining.

Lower hash rate == lower diff == faster blocks. I am still trying to get people to comment on my idea to limit miners by preventing consecutive solving of blocks.

I want our security to rely more on cryptography and consensus rather than brute wasteful force. If it was feasible, i would have a dynamic system, that changes the # of blocks before one can solve another, based on the number of existing nodes. For example if there are 100 nodes, a Bn can only mine another block after ten have passed. This will really kill all sense of competitive mining that does not benefit the chain, because in order to mine in a seemingly competitive way, one would have to buy 50K BCR for a BN. Hopefully, one would be smart and bid for as much as they can then buy the rest of the markets. This benefits price, it benefits the network, it benefits security and makes BN runners more invested in keeping the chain secure, as well as incentivizes them to come up with unique and innovative business models to make their BNs profitable.

Anyway, back to work.

[proletariat]

Inspection of the wallet yielded some results that will be evident in the update, due to the start-up process for QT being a single thread, it was too busy and some events were not being handled properly, to that effect, a lot of the math has been moved to the trust engine and to raw data extraction.

I'm glad you can get your wallet running now, albeit with some stumbling.

I managed to get it started on a freshly installed Virtual Machine running Windows 10 x64. But on my desktop running Windows 8.1 x64 it's still not opening, thus my coins remain on the exchanges. For me an updated wallet-QT can't come quick enough!

Long shot but can you try with just deleting your debug.log? strange but that worked for me and i managed to replicate it apparently.

[bitcreditscc]

Inspection of the wallet yielded some results that will be evident in the update, due to the start-up process for QT being a single thread, it was too busy and some events were not being handled properly, to that effect, a lot of the math has been moved to the trust engine and to raw data extraction.

I'm glad you can get your wallet running now, albeit with some stumbling.

I managed to get it started on a freshly installed Virtual Machine running Windows 10 x64. But on my desktop running Windows 8.1 x64 it's still not opening, thus my coins remain on the exchanges. For me an updated wallet-QT can't come quick enough!

Long shot but can you try with just deleting your debug.log? strange but that worked for me and i managed to replicate it apparently.

Nice catch, was going add a debug removal line, tried it, it worked but then realized ht could obscure possible errors

[proletariat]

Inspection of the wallet yielded some results that will be evident in the update, due to the start-up process for QT being a single thread, it was too busy and some events were not being handled properly, to that effect, a lot of the math has been moved to the trust engine and to raw data extraction.

I'm glad you can get your wallet running now, albeit with some stumbling.

I managed to get it started on a freshly installed Virtual Machine running Windows 10 x64. But on my desktop running Windows 8.1 x64 it's still not opening, thus my coins remain on the exchanges. For me an updated wallet-QT can't come quick enough!

Long shot but can you try with just deleting your debug.log? strange but that worked for me and i managed to replicate it apparently.

Nice catch, was going add a debug removal line, tried it, it worked but then realized ht could obscure possible errors

Yeah that originally had me postponing creating my nodes. Today I tried deleting file by file and narrowed it down to mncache, debug and lock..... I think it is either of those maybe just coincidence.... donno but my nodes are online now 

[jasemoney]

For us to have a smooth transition into BN based mining, we need the mining difficulty to be solo- friendly to that effect I have asked hack_ (pools) to start gradually increasing the fee, the intended effect is to slowly wean the chain from reliance on high powered miners and instead focus on solo mining.

Lower hash rate == lower diff == faster blocks. I am still trying to get people to comment on my idea to limit miners by preventing consecutive solving of blocks.

I want our security to rely more on cryptography and consensus rather than brute wasteful force. If it was feasible, i would have a dynamic system, that changes the # of blocks before one can solve another, based on the number of existing nodes. For example if there are 100 nodes, a Bn can only mine another block after ten have passed. This will really kill all sense of competitive mining that does not benefit the chain, because in order to mine in a seemingly competitive way, one would have to buy 50K BCR for a BN. Hopefully, one would be smart and bid for as much as they can then buy the rest of the markets. This benefits price, it benefits the network, it benefits security and makes BN runners more invested in keeping the chain secure, as well as incentivizes them to come up with unique and innovative business models to make their BNs profitable.

Anyway, back to work.

can you TL;DR on how lower hash == lower diff == faster blocks? is it programmed to lower the diff disproportionately more for lower hash rate to cause the faster blocks? I was always under the assumption it strived to reach the targettime between blocks where if it was 1 hash or 1trillion on average a block would be found around the target time.

Also I hate to say it because it was such a giant scam that bothers me to this day, but Urocoin had an idea to try and accept lower diff blocks by submitting and consuming a stakeweight with the proof of work. it was named SPOW (Staked proof of work) There was some coding done towards it but no one knows how far along it got. If this is something youd like to know more about i can try and find the repo and whitepaper. otherwise forcing the hash through solo banknode operators sounds fine by me.

[statdude]

What are features of this coin? Similar to DASH?

[bitcreditscc]

For us to have a smooth transition into BN based mining, we need the mining difficulty to be solo- friendly to that effect I have asked hack_ (pools) to start gradually increasing the fee, the intended effect is to slowly wean the chain from reliance on high powered miners and instead focus on solo mining.

Lower hash rate == lower diff == faster blocks. I am still trying to get people to comment on my idea to limit miners by preventing consecutive solving of blocks.

I want our security to rely more on cryptography and consensus rather than brute wasteful force. If it was feasible, i would have a dynamic system, that changes the # of blocks before one can solve another, based on the number of existing nodes. For example if there are 100 nodes, a Bn can only mine another block after ten have passed. This will really kill all sense of competitive mining that does not benefit the chain, because in order to mine in a seemingly competitive way, one would have to buy 50K BCR for a BN. Hopefully, one would be smart and bid for as much as they can then buy the rest of the markets. This benefits price, it benefits the network, it benefits security and makes BN runners more invested in keeping the chain secure, as well as incentivizes them to come up with unique and innovative business models to make their BNs profitable.

Anyway, back to work.

can you TL;DR on how lower hash == lower diff == faster blocks? is it programmed to lower the diff disproportionately more for lower hash rate to cause the faster blocks? I was always under the assumption it strived to reach the targettime between blocks where if it was 1 hash or 1trillion on average a block would be found around the target time.

Also I hate to say it because it was such a giant scam that bothers me to this day, but Urocoin had an idea to try and accept lower diff blocks by submitting and consuming a stakeweight with the proof of work. it was named SPOW (Staked proof of work) There was some coding done towards it but no one knows how far along it got. If this is something youd like to know more about i can try and find the repo and whitepaper. otherwise forcing the hash through solo banknode operators sounds fine by me.

Hello,

Our diff adjustment algo places more emphasis on lowering the diff, this is to counter Momentum's tendency to quickly push up the diff and to encourage constant block flow. As a caveat it was meant to empower the average miner, however since the pools went online we have never reached the targeted 1 minute blocks, and solo mining has become impossible. These problems are apparently common in coins that use the momentum algorithm.

A few weeks ago, one of the heavy weight pool miners reduced his significant  hashrate enough that the network hiccuped, after the recovery we noticed a converse relationship between the hashrate and the number of blocks per day. This got me thinking so i continued to observe and realized that lower hashrate has less push on the diff, resulting in more low diff blocks, each lower diff block required less work to be done to solve the block.... hence low hashrate == lower diff == faster blocks. So far we have seen a ~30% increase in number of blocks per day along with a 75% drop in hashrate.

Previously we expected anywhere between 600 and 850 blocks , now we expect 900 -1000 (save for the days someone notices the steady increasing price and tries opportunistic mining). I believe we will soon find a sweet spot were blocks are as close as possible to the target time while maintaining a sustainable , green footprint.

Thanks for the suggestion , i would be very thankful if you can point it out to me, i am always researching how best to secure our chain. However accepting lower diff blocks coupled with coinage sounds great on first thought, but it seems very risky because i think it opens up an attack vector that would be difficult to close...

PoS works on coinage      ------->
PoW works on workdone  ====>
PoW/PoS                        ===-->
PoS/PoW                        ------=>

Which do we give priority we we have 4 possible channels? Two with each in their pure form and two with them alternating the position of strength ? I'd expect to see massive uncontrollable forking in such a system. But if it was solved, it would be a great technical feat!!!

[bitcreditscc]

While we are on the topic:-

Bank node / Masternodes are a more active form of Proof of Stake. In traditional PoS users mint coins as a reward for producing a block that proves they are invested in the coin and enhancing security of the chain. Whereas in the dual tier system, 2nd tier nodes are rewarded  for actively supporting the chain by providing a service, stabilizing network connectivity and reducing relay times. My proposal to switch to Bn only mining moves the security component to BNs by having them produce a Proof of Activity block similar in many ways to a PoS block.

The block proves the BN exists and is actively working to secure the chain by producing blocks and signing them, all this aside for it's other duties and services. The "stake" in our scenario is the 50K BN fee.

With the current PoW arms race, the money spent @ Amazon or buying/renting rigs, never gets into the ecosystem and usually for most coins, miners are selling at a loss. In the new system, your "mining rig" will be your 50K BCR, which you can run off an everyday PC or off a r-pi, with the purchase cost going into securing the value of your investment.

[thelonecrouton]

What are features of this coin? Similar to DASH?

BCR was forked from the DASH code base but is heading in a very different direction.


The reasons I'm a supporter...

PoW is an inadequate security mechanism, pooled mining completely circumvents the whole point of distributed hash. PoW is enormously wasteful. PoW does not directly benefit the currency in any way, miners sink money into the power company and hardware manufacturers instead. It's also horribly exclusionary, anyone without (geek skills + expensive hardware + ability to pay the electricity bill) need not apply.

BCR is addressing these issues by moving toward a co-operative rather than competetitive consensus mechanism, thus eliminating the wasteful hardware arms race, offering improved blockchain security and seperating the security process from the distribution of new mintage by offering newly minted BCR on the open market for direct purchase by tender. The proceeds from these ongoing sales will be used to back the currency with a portfolio of real assets, offering users and investors a rising, assured minimum value for their BCR holdings. Those assets will be gatekept by Banknode operators with a multisig system, so no one person can run off with the loot.

Think blockchain hedge fund, with cheap p2p transfer of assets, no expensive brokers and middlemen.

Banknodes will also offer p2p lending and other financial services to users, including user-issued blockchain assets (coloured coins), offering further earnings potential for Banknode operators. The software isn't necessarily going to provide you with an automatic income by itself (although Banknodes do accrue reward for services to the network), as with any real business the Banknode ops will have to put a little work in, but the tools will be evolving to make it as easy as possible to connect real world enterprise to the underlying blockchain technology.

This is an ambitious project, the next release is going to include a lot of new features as well as the underlying code foundation for many more.

Coding speaks louder than words though - take a look at the developer's git: https://github.com/bitcreditscc?tab=activity  -  if this guy could work 48 hours a day he would.

[bitcreditscc]

What are features of this coin? Similar to DASH?

BCR was forked from the DASH code base but is heading in a very different direction.


The reasons I'm a supporter...

PoW is an inadequate security mechanism, pooled mining completely circumvents the whole point of distributed hash. PoW is enormously wasteful. PoW does not directly benefit the currency in any way, miners sink money into the power company and hardware manufacturers instead. It's also horribly exclusionary, anyone without (geek skills + expensive hardware + ability to pay the electricity bill) need not apply.

BCR is addressing these issues by moving toward a co-operative rather than competetitive consensus mechanism, thus eliminating the wasteful hardware arms race, offering improved blockchain security and seperating the security process from the distribution of new mintage by offering newly minted BCR on the open market for direct purchase by tender. The proceeds from these ongoing sales will be used to back the currency with a portfolio of real assets, offering users and investors a rising, assured minimum value for their BCR holdings. Those assets will be gatekept by Banknode operators with a multisig system, so no one person can run off with the loot.

Think blockchain hedge fund, with cheap p2p transfer of assets, no expensive brokers and middlemen.

Banknodes will also offer p2p lending and other financial services to users, including user-issued blockchain assets (coloured coins), offering further earnings potential for Banknode operators. The software isn't necessarily going to provide you with an automatic income by itself (although Banknodes do accrue reward for services to the network), as with any real business the Banknode ops will have to put a little work in, but the tools will be evolving to make it as easy as possible to connect real world enterprise to the underlying blockchain technology.

This is an ambitious project, the next release is going to include a lot of new features as well as the underlying code foundation for many more.

Coding speaks louder than words though - take a look at the developer's git: https://github.com/bitcreditscc?tab=activity  -  if this guy could work 48 hours a day he would.

Well I'm happy you like my work ethic.  Just finished compiling the IBTP stuff, though i have temporarily left it only focused on BCR. I've made provision for listening in on BTC, LTC and DASH chains. This will be put into active mode when i have completed studying some of the nuances.

I am currently waiting on my local node to complete compiling the cross platform environment so i can offer a windows testing binary.

Quick list of Updates, new features and improvements

Bid based distribution
Escrow Nodes
Basic IBTP listening
Checklocktime opcodes for delayed transactions
Expanded statistics report
Faster start up time

For those who are unaware, we already hiked our blocksize to avoid future debate, while it is not a complete solution to what is happening to BTC, it is a first step in a three point plan to scale BCR to the 10K tx per second target. Current BCR tx per sec is 1050 if you subscribe to the bitcoin 7 tx per second calculation.

[LucD88]

Long shot but can you try with just deleting your debug.log? strange but that worked for me and i managed to replicate it apparently.

I deleted the debug.log, db.log and .lock files, the wallet crashed the first and second time opening it. But the third time it miraculously opened..

...

I am currently waiting on my local node to complete compiling the cross platform environment so i can offer a windows testing binary.

Quick list of Updates, new features and improvements

Bid based distribution
Escrow Nodes
Basic IBTP listening
Checklocktime opcodes for delayed transactions
Expanded statistics report
Faster start up time

For those who are unaware, we already hiked our blocksize to avoid future debate, while it is not a complete solution to what is happening to BTC, it is a first step in a three point plan to scale BCR to the 10K tx per second target. Current BCR tx per sec is 1050 if you subscribe to the bitcoin 7 tx per second calculation.

You're pushing out new updates, features and improvements like there's no tomorrow.. That's the definition of a hard worker, I'm seriously impressed! Really curious to see the impact this coin will have in the next few months. Keep up the amazing work you're doing here.. KUDUS to the whole team!

Are you and lonecrouton the only two actively developing? This is what GitHub Member page shows me:
@bitcreditscc / bicreditsnew
@dragosbdi dragosbdi / bicreditsnew
@gjhiggins gjhiggins / bicreditsnew
@JoshuaAmsden JoshuaAmsden / bicreditsnew
@NaN-git NaN-git / bicreditsnew
@retroman retroman / bicreditsnew
@thelonecrouton thelonecrouton / bicreditsnew

And the GitHub Contributors page shows:


Ever thought about expanding the team?

[bitcreditscc]

The thing i dislike the most about windows is that it just tries to fight me at every turn. Using back-up environment to build, the one that used to work so well now i refuses to cooperate. Anyone else got a windows build environment?

[thelonecrouton]

Ever thought about expanding the team?

It's an open source project, anyone is welcome to contribute in whatever way they can. 

I think when the bidding system goes live and BCR holders start accruing real backing for their BCR, more people will become interested.

[bitcreditscc]

Ever thought about expanding the team?

It's an open source project, anyone is welcome to contribute in whatever way they can. 

I think when the bidding system goes live and BCR holders start accruing real backing for their BCR, more people will become interested.

Yeah, we'd appreciate all the help we can get!!