Working Nodes:
addnode "91.230.123.101:9999" add
addnode "91.230.123.101:8877" add
Thanks, that got me to block 85002, 13hrs behind, but I am stuck there. No bitcredit client has ever connected to more than 1 peer for me. Currently getpeerinfo shows only 91.230.123.101:9999. the current block IS 85002. addnode "91.13.108.10:8877" add Hurrah, now have 2 peers!  Still on 85002 though which seems to be taking a godawful time to move. The block explorer in the OP is frozen at 85020 and must be on some other fork, and the qt client thinks I'm 14 hrs behind, so I was a bit confused. Heh, qt has just crashed with: === Bitcredit Client ===
Is (85003) a grant block? : Yes
=== Bitcredit Client ===
Is (85003) a grant block? : Yes
=== Grant Database Block Height -1 ===
=== Bitcredit Client: Making sure that Grant Database is up to date. ===
=== Required Height of Database: 85001, Height requested from: 85003 ===
=== Bitcredit Client ===
De-Serialize Grant Info Database
Max Blocks Wanted: 85001
Could not load Grant Info Database from /home/stu/.bitcredit/blocks/grantdb.dat, Max Wanted: 85001
=== Bitcredit Client ===
Processing the Next Block into the Grant Database for Block: 0
Segmentation fault (core dumped)
|
|
|
|
Working Nodes:
addnode "91.230.123.101:9999" add
addnode "91.230.123.101:8877" add
Thanks, that got me to block 85002, 13hrs behind, but I am stuck there. No bitcredit client has ever connected to more than 1 peer for me. Currently getpeerinfo shows only 91.230.123.101:9999. |
|
|
|
Compiled v0.30.16.5-c1dc563-dirty but all alone, no peers to sync from...  2015-04-10 19:13:42 3 addresses found from DNS seeds
2015-04-10 19:13:42 dnsseed thread exit
2015-04-10 19:13:42 GUI: PaymentServer::LoadRootCAs : Loaded 175 root certificates
2015-04-10 19:13:42 GUI: QObject::connect: No such signal WalletModel::balanceChanged(CAmount,CAmount,CAmount,CAmount,CAmount,CAmount,CAmount) in qt/overviewpage.cpp:268
2015-04-10 19:13:42 GUI: QObject::connect: (receiver name: 'OverviewPage')
2015-04-10 19:13:42 GUI: QObject::connect: No such signal WalletModel::balanceChanged(CAmount,CAmount,CAmount,CAmount,CAmount,CAmount,CAmount) in qt/sendcoinsdialog.cpp:145
2015-04-10 19:13:42 GUI: QObject::connect: (receiver name: 'SendCoinsDialog')
2015-04-10 19:13:43 connect() to 198.52.160.64:8877 failed after select(): Connection refused (111)
2015-04-10 19:13:43 connect() to 198.52.160.60:8877 failed after select(): Connection refused (111)
2015-04-10 19:13:44 connect() to 198.52.160.59:8877 failed after select(): Connection refused (111)
2015-04-10 19:13:45 connect() to 198.52.160.64:8877 failed after select(): Connection refused (111)
2015-04-10 19:13:46 connect() to 198.52.160.64:8877 failed after select(): Connection refused (111)
2015-04-10 19:13:47 connect() to 198.52.160.60:8877 failed after select(): Connection refused (111)
2015-04-10 19:13:48 connect() to 198.52.160.59:8877 failed after select(): Connection refused (111)
2015-04-10 19:13:48 connect() to 198.52.160.59:8877 failed after select(): Connection refused (111)
2015-04-10 19:13:49 connect() to 198.52.160.60:8877 failed after select(): Connection refused (111)...etc
Also shown here is the balance-changed issue I'm having - it won't update without a client restart. |
|
|
|
There's definitely something screwy with the overviewpage. (30.16.04 / linux 64) Just made a withdrawal from bittrex, got the local wallet notification straight away, getinfo and listtransactions showed the incoming tx, but the balances on the overview wouldn't update until I closed and restarted the client. I don't know if it's related, but I'm getting a lot of stdout like this: Warning: Peer buckets matched in the future: 1428275752.
Either this node or the peer node has the incorrect time set.
|
|
|
|
Just compiled from git and there's a (hopefully) cosmetic bug in the overviewpage - my entire balance is showing as unconfirmed. (Available: 0.00000000) Resync'd the blockchain, same thing. getinfo seems to report the correct balance (I assume it would only show confirmed?) and listtransactions show all incoming txes as having thousands of confirmations. Send tab lists the correct balance (I assume it would only show confirmed?) when I uncheck Darksend. Please fix, it is unnerving me!  how much do you have and how much is it set to mix around? I'm not mixing...  How much I have = not quite enough for a BN.  edit: nevermind, it fixed itself after a restart. |
|
|
|
Just compiled from git and there's a (hopefully) cosmetic bug in the overviewpage - my entire balance is showing as unconfirmed. (Available: 0.00000000) Resync'd the blockchain, same thing. getinfo seems to report the correct balance (I assume it would only show confirmed?) and listtransactions show all incoming txes as having thousands of confirmations. Send tab lists the correct balance (I assume it would only show confirmed?) when I uncheck Darksend. Please fix, it is unnerving me! |
|
|
|
Just to give you something to chew on ... this is a very rough sketch of a thought experiment for an automated lottery that I don't yet know how to implement:
1. A global burn address is created and hard-coded into the app.
2. Wallet owners can send max(one) coin to the burn address, where it is irrecoverably lost.
3. Entrants are the list of the sending addresses of coins burned since the last draw.
4. Drawing occurs when prevBlock.nHeight mod 1440 == 0
5. Winners are the owners of the n addresses that are hex-within(prevblock.merklehash +/- a calculated range)
7. An amount of totalburnedcoins is added to the block reward.
8. totalburnedcoins - commission coins are paid to winning addresses in amounts according to a predetermined scale.
9. The house receives the predefined commission.
Even something as drop-dead simple as this is infeasible. As a distributed open source app, its cryptography is inherently pellucid, i.e. there's no opaque locus in which to vest control of a private key. It may be possible to model an opaque locus via a complex cryptography gavotte performed by Alice and Bob (and maybe Charles, if you're into that kind of thing). Or maybe the solution lies in recruiting the services of an oracle to take advantage of the opacity it provides --- at the cost of introducing potential exploit scenarios and of losing the protection provided by a 100% cryptography solution.
Cheers
Graham
Forgive me if I'm being dense, but there is no need surely to make the whole shebang decentralised. Could the example you gave be achieved by using the MN network as a consensus mechanism for choosing the locus/loci, then let that selected MN/those selected MNs do the things that need a central control point? Much like Darksend - it's not really decentralised in terms of parallelism, it's just a method of sequential MN subset selection, the MNs selected do their bit discretely, the code for which they all possess and the data for which gets pulled from the network, then pass the process onwards until the result is achieved and subsequently broadcast to everyone. The processing doesn't need to be completely distributed. |
|
|
|
Sub-Ether: What are you trying to say?
Bitcoin is shit, would be my guess. At least when it comes to real world transactional use, it's... well, pretty much completely bloody useless. Exactly, how did you know ?  We need to step back and think about things... Pretend for a moment you know nothing about crypto. Then try selling this cunning plan to yourself: Current BTC hashrate = 368 PH/s = 368 * 10^15 H/s ~ 4.784 * 10^20 32 bit operations/sec. * Consuming christ knows how many megawatts of power. To obtain network consensus on a theoretical maximum of 7 transactions per minute.LOL, right? Can you think of any other system, at all, in the known universe, which is as ludicrously inefficient as this? (And survives?) Store of value? Don't make me laugh. As long as all these numpties go on spending fortunes on electricity... the minute they stop the whole thing becomes worthless. It's even dafter than the debt slavery we currently all enjoy. *source: Ngzhang says above that there are about 1300 32-bit operations (in one bitcoin hash) which sounds about right. So one 1GH/s would be equal to 1,300,000,000,000 operations per second.
|
|
|
|
Sub-Ether: What are you trying to say?
Bitcoin is shit, would be my guess. At least when it comes to real world transactional use, it's... well, pretty much completely bloody useless. |
|
|
|
After getting a MN running you can send coins from other wallets to the MN address without breaking the MN right?
Yes. You'll only break if it if you send some of/from the 1000 DRK lump, so use coin control to select inputs other than that one when sending out. Anything incoming doesn't matter. |
|
|
|
Ok silly me. That whole masternode voting stuff ( Yey and Nej ), what on earth does it do? Cant find anything to read about it  I just updated my node to 0.11.2.17. Does it require some voting command to get paid or something? Bit confused here  It's all about skirts. |
|
|
|
************ Dash Release Update : 11.2.17 ************************ - Fixed the "locking up" issue that would cause masternodes to go offline and general instability - Masternode list changes - Udjin - Better icon images - Crowning - Improved Chinese Translation https://www.dashpay.io/downloads/Mandatory? Protocol bump? No and no. |
|
|
|
Is anyone going to operate their bank node on a raspberri pi?
Doubt that you succeed in compile it on ARM ... let me know if you done it It can be run on a Pi2: https://dashtalk.org/threads/masternode-on-raspberry-pi-2-model-b.4083/ - but an old Pi1 isn't going to cut it. Seems like a lot of bother to me when a better connected and more reliable VPS can be had for a few $/£/€ a month but if you already have a Pi2 then why not I suppose. |
|
|
|
How do you check MN logs?
Have you tried reading them?  |
|
|
|
So I did some research on decentralization. My starting point was Wikipedia, https://en.wikipedia.org/wiki/Decentralized_system. That page has a very good description right at the beginning that I want to paste for you. 'A centralised system is one in which a central controller exercises control over the lower-level components of the system directly or through the use of a power hierarchy (such as instructing a middle level component to instruct a lower level component).' Doesn't that sound like MasterNodes? I know your answer is going to be that MasterNodes don't 'exercise control' but they do. You've just said that they are going to influence performance, which is exercising control. And we definitely know that they act on behalf of Dash users when they are mixing. By that definition the Dash network is 'centralized' and I don't think it's right to argue it any other way. The Wikipedia article continues, and I think its important to go over some of the sentences and contrast it with Dash and Bitcoin/Monero, because this is a Dash vs Monero thread. 'A decentralised system, on the other hand, is one in which complex behaviour emerges through the work of lower level components operating on local information, not the instructions of any commanding influence.' In Dash the lower level components (nodes) don't operate on local information. They rely on the MasterNodes to exert control and provide information and provide structure. 'This form of control is known as distributed control, or control in which each component of the system is equally responsible for contributing to the global, complex behaviour by acting on local information in the appropriate manner.' This is the clearest indication, for me, where we see that Dash is centralized. The components in Dash are not equal. MasterNodes have way more power than ordinary nodes, and that means they are controlling things. There are other excellent points in that Wikipedia article but I think the point is clear, and that is that Dash is centralized, Bitcoin and Monero are not. LOL, I swear some of these people have the IQ of dog food. This is pure idiot-babble. Masternodes are the only credibly decentralised infrastructure model in crypto. |
|
|
|
|
Don't all the miners need to be updated for the BN payments to work?
|
|
|
|
What does it mean the message " ... could not connect to ... "
Seems that I can't pass this ...
Port 9999 needs to open to TCP traffic. @bitcreditscc - does your implementation need a static IP address for any reason? SPR didn't. DRK does, but it's an artificial requirement to encourage use of well connected VPS instances. |
|
|
|
|
Show Posts
