Anyone know how to launch eg. bitcoin-qt with a URI? I know it's possible because you can click on a bitcoin URI in a browser and it works, but I can't find how the browser passes the URI to the client...  I'm looking for something like, 'bitcoin-qt --URI=<blah>' ...? |
|
|
|
I've been telling people for 18 months that a single crappy old celeron could handle the entire Bitcoin blockchain with ease, and probably that of every other active altcoin simultaneously. They look at me (or type at me anyway) like I'm crazy for thinking that anything under a petawatt's worth of compute power could possibly cope. Anyway, BCR's blockchain is currently humming along on a bit more than one crappy celeron, but not much - ("networkhashps" : 1,) - and I just squeezed over 300 txes into block 205593 and ... no issues, surprise. I shall be consolidating the rest of my BN payments shortly.  Competitive PoW is utterly fucking daft.  Also, it occurs to me that another aspect of BCR being, among other things, a (worlds first?) p2p hedge fund is that assuming the bid price follows to some extent the market price, any pumping will result in permanently locked in value. BCR is one of a very few (Xaurum, backed by gold?) cryptocurrencies that can't be dumped to zero, assuming any of the underlying assets still have market value. |
|
|
|
Do a git pull, i just fixed the standard key import.
Tested with hundreds of keys from all 3 prefixes.
It seems to work, I get a 'Rescanning' popup with progressbar, but no new BCR address or BCR.  Some old bids still in final.dat, maybe they haven't been 'processed?' |
|
|
|
core limitation is enforced in this update?
I'm not sure if we're BN-only mining yet but I've hit 4 blocks out of the last 23 with a quarter of my old laptop's i5. getmininginfo: { "blocks" : 204388, "currentblocksize" : 1000, "currentblocktx" : 0, "difficulty" : 0.00000002, "errors" : "", "genproclimit" : 1, "networkhashps" : 19, "pooledtx" : 0, "testnet" : false, "chain" : "main", "generate" : true, "hashespermin" : 4 } .. which puts me at a mighty 0.35% of the total hash if that's valid data. So, I have no idea.  |
|
|
|
|
17.1 (built on xubuntu 14.10) synced fine from scratch after I specified port=8878 in bitcredit.conf. (I had it set on another port previously.)
Sadly still can't redeem:
"Invalid private key encoding (code -5)"
edit: just closed he client and got this on stdout:
"before X....blah.....blah.......r after M......blah..... blah..........7" - where the before was the dash privkey.
Alas, trying to import the 'after' privkey also gave:
"Invalid private key encoding (code -5)" - BCR privkeys should begin with a 'K' ?
edit2: banknode up and mining on 1 core.
|
|
|
|
.Can you re-base your work on the latest master, i have changed how the values of the bids are represented in the bid file to ensure accurate payouts. Instead of fractions of BTC they are now represented as satoshis.
...
edit;- actually, get it from final.dat, it's getting updated every 5 minutes now so it's pretty accurate.
Suits me, one file to parse beats three. Will have another bout tomorrow, need sleep. BTW am I correct in thinking that if you bid from the same btc/ltc/dash address you should only need to do the importprivkey thing once? |
|
|
|
Hooked up most of this except the redemption bit:  As you can see, bit of a bargain currently. Clicking the bid addresses opens up your default browser and takes you to that address on blockr.io or dashpay.io, the 'Bid with' buttons will open up bitcredit-qt etc. on linux if the binaries are in your PATH, eg in /usr/bin - supposedly something similar should happen on Win but I can't test that. I've stuck with the official clients for now due to SPV privkey issues, but I can add an option in the conf to put the path to whatever btc/ltc/dash client you like and have it use that in the future. Bid calc works. Superblock countdown works. @bitcreditscc - I'm assuming that the btcbids/ltcbids/dashbids.dat files get wiped (or should do?) after each superblock? Or should I just get the current superblock numbers from final.dat instead? Or somewhere else? edit: I should get the current total asset backing and assured min value and stick it somewhere on there too, although maybe that could/should be added on the main page? |
|
|
|
ok, so we have two oprions, let the chain continue as is and issue an update that fixes things in a day or two or else halt the chain hard fork @ 202499 and proceed.
I'm all for the first option i';d like to start maintaining a policy of updates on the run, instead of halting. The update is going to do the following
1) Place checks against blocks to ensure that BN payments and Payouts are made
2) Activate IX
3) Ensure BN only mining (you can use a pool BN to mine if the owner is willing to share his key with you)
4) (Maybe) institute block # limits on BNs (this will result in 3 being invalidated and make the chain solo mining only
Anything that avoids BN owners stuffing their BN boxes with $500 GPUs. |
|
|
|
Offered for consideration and suggestions:  It's not functionally hooked up yet but that shouldn't be too hard, the bid amounts I can get straight out of the bidtracker directory files, the addresses will be hotlinks to the appropriate block explorers, the 'Bid with' buttons will open up bitcoin-qt etc. (with payment address set) if present. The Import button will need me to figure out some stuff, but hey it would be no fun if it was easy. Layout needs a bit more fine tuning, but is there anything I've missed that should be there, or anything there that doesn't need to be? |
|
|
|
When you send a bid, the bid tracker does a look up of the address you sent from, and then allocates the coins to that address converted to BCR address format.
So , when you want to redeem, you simply import the privkey of the address you used to send, and your coins should be there.
Not working for me, or I'm doing something wrong. I unlocked my DASH wallet, ran 'dumpprivkey <address-I-bid-from>', then unlocked my BCR wallet and ran 'importprivkey <privkey-for-DASH-address>' and got Invalid private key encoding (code -5) |
|
|
|
Proportional chunk is great, I thought it's highest bidder wins but I haven't been paying to close attention. How does the payout base the proportion of differently priced btc, dash, ltc?
LTC and DASH are converted to their BTC value and it gets calculated from there. Is there anything special needed to bid aside from pay those addresses? If there isn't a bid writeup can someone provide or link?
As a side note on those addresses..
BTC .001
Ltc .0299
Dash .31
Seems like a steal :p
I'm just sending some test bids, I'm unclear yet on the exact redemption process but when I've seen how the whole thing works I'll be working on in-wallet GUI streamlining of things. |
|
|
|
BCR is moving to low-wattage BN only mining to eliminate the kind of waste you are proposing! Better to invest in or bid for some BCR instead and earn service rewards for running a Banknode, while also backing the currency.  Bidding addresses are as follows, bid as much or as little as you please, current bids may be found in the bidtracker directory, although they will soon be updated and shown in the wallet... BTC: 16f5dJd4EHRrQwGGRMczA69qbJYs4msBQ5 LTC: Lc7ebfQPz6VJ8qmXYaaFxBYLpDz2XsDu7c DASH: Xypcx2iE8rCtC3tjw5M8sxpRzn4JuoSaBH (you can verify these addresses in bidtracker.cpp - https://github.com/bitcreditscc/bicreditsnew/blob/master/src/bidtracker.cpp) You get a proportional chunk of the 30000 BCR minted each superblock, every 900 blocks (appx. once a day.) For the cost of that GPU (never mind the running costs) you could own 6 or 7 Banknodes.  |
|
|
|
When's the next superblock? Chainz has the last one at 200700, but maybe that's beed forked off, was there one at 201600, and the next one at 202500? I submitted another test bid earlier this afternoon ( http://explorer.dashpay.io/address/Xypcx2iE8rCtC3tjw5M8sxpRzn4JuoSaBH ) and right now there are no other new BTC/LTC bids so unless someone else ponies up I expect to get a big pile of BCR. |
|
|
|
By my crude estimation, if the 6 million reserve BCR remain unburned and unbacked - worst case scenario IMO - and if BCR is on average bid for at only half the current market price, if the backing thus acquired only lends 20% of its actual value to the market price, it will take appx. 1 year for the Assured Minimum Value of BCR to match the market price it started at. After this, the AMV starts to exceed the starting market price rather rapidly. Holds true whatever the initial starting price is. eg, taking the current Bittrex bid price:  This is all pure conjecture, I'm just working from some simple initial conditions and extrapolating, and I'm using BTC as a yardstick because most people here have a feel for what BTC is 'worth' - I think we should be ditching most of the cryptofiat backing for something solid ASAP. Now more than ever world markets are volatile, the relative prices of anything could go any which way at short notice so even when some actual data is available to model from, long term price predictions are always going to be about as accurate as long term weather forecasts. Possibly slightly more accurate than 'Technical Analysis' chart voodoo though, which to me seems like driving your car forwards while staring only into the rear view mirror and believing that the past is telling you what's in the road ahead. One thing is certain though, for backing to happen we're going to have to attract buyers. I'm doubtful we'll convince many miners to just buy BCR instead of wasting electricity to acquire it. Miners are mostly just geeks hoping to get free shit. I suspect few miners are interested in actual investment rather than raw speculation or instadumping via BTC into fiat to buy more of whatever it is that they smoke that convinces them that what they're doing is a sensible use of their time and energy. Back to the attracting buyers bit... as bitcreditscc said a little while ago we're going to need outreach. I've done sales work and I hated it too, but we can learn from what other cryptocurrencies have done and avoid their mistakes. Sadly I don't think there are many successes to emulate, unless one counts the likes of the Ethereum, fools and their money etc. Top of my personal list of things to avoid is spending much - or any - money or effort within the crypto scene, it's filthy with dogma and broken thinking, and most of 'em are completely broke from all that pre-obsolete mining hardware, the electricity bills, and playing suicidal daytrader against whales and bots on the obviously crooked (all of them) exchanges. It's difficult to know where to direct efforts though without an idea of what the community sees as the longer term purpose of BCR. Before the bidding/backing thing got underway I think there was plenty of scope in the original vision of a p2p banking and financial services platform. When the backing system is fully running I hope bitcreditscc continues to develop that aspect of things, it's a big market. There are just so many ways that BCR could flourish, I'd be interested to hear what others see ahead, or would like to see in BCR - not short term technical stuff like wallets crashing on platform X, that stuff will get ironed out, but the bigger picture. Just ruminating here, and thought I'd post some more asset backing porn as the BCR price seems to have risen somewhat since I last did so. If this post has left any cryptognats unoffended, please tell me so I can include you in my sweeping and unflattering characterisations next time, I wouldn't want anyone to feel left out. |
|
|
|
If each BN needs 1 core then I'm out of luck ...
If there's a choice of BN collateral amounts (and proportional BN rewards) in a future update, I'll be going for some 250k+ BNs, I can realistically run 5 or so across the ISP connections I have available at home. I notice than BN payments are incoming now @ 10.35 BCR - this isn't far off half the previous 18.75 BCR payout... with BNs needing to run a CPU core all the time I think some upward revision might be justified. I've got some ideas for improving the bidding process and monitoring it from withing the UI, but I'll wait to see the whole process in action and working properly first so I have a better idea of how to make things simpler for the user. |
|
|
|
I'm not so lucky, my VPS and home wallets starts to sync to the last block and then it stops. After closing and opening again it does the same so I can't sync to start my BNs.
Did you remember to add these to your .conf and remove any previous ones? addnode=41.191.238.189 addnode=82.211.1.181:8877 addnode=91.230.123.101:8877 Delete peers.dat too, in fact delete everything except bitcredit.conf, your wallet.dat and backups, and dragos_bdi's blocks + chainstate directories. Then start with --reindex. (Apologies if you've already tried all this.) |
|
|
|
|
All seems good for me, built without issue and synced fine after a --reindex, started up one local BN for now, will fire up some more tonight.
Should I be running 1 core solo mining for each BN?
|
|
|
|
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. |
|
|
|
It's imperative that we ensure that bids are added to the block.
Say when, I'll chuck some more into the pot. |
|
|
|
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. |
|
|
|
|
Show Posts
