151
TestNet Discussion Archive / Re: BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)
« on: March 05, 2018, 07:03:14 PM »
Is there a version we have to upgrade to tonight?
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Weve got a wild situation forming here, take a look at the legacy chain difficulty :
running this from the *new* wallet:
exec podcdifficulty 33120
Diff is about 24000.... So that explains why we are having issues solving block 33153.
So what happens is the block becomes 90% easier after 30 minutes - meaning that a 24000 diff is like a 2400 diff! Thats crazy high for us little fish in this new pond. We are going to have to recommend setgenerate 10 - we need to try to brute force 33153 together....
I just enabled 1 miner.
EDIT: Yes Jaap just read your comment, exactly, but we have evaded this situation because of our late block rule above. But whats strange is this 24000 diff is Way higher than normal! We pissed someone off right before the fork started.
So,
linux 1101, clean install, synced to block 33152 and my balance is still 0
THANK YOU ALL FOR TESTING PODC
WE ARE MAKING A DIFFERENCE IN THE WORLD, we are creating a Sanctuary Economy for the benefit of the Orphans!
https://www.biblepay.org/#downloads
Ok got a Windows Wallet updated to 1.0.9.9 in Production,
I have 1 connection, I didnt clean any folders or .dat files,
Should I move forward with updating Sanctuary?
2018-03-05 20:32:17 Invalid or missing peers.dat; recreating
2018-03-05 20:32:17 ERROR: Read: Failed to open file /home/biblepay/.biblepaycore/banlist.dat
2018-03-05 20:32:17 Invalid or missing banlist.dat; recreating
2018-03-05 20:32:17 Loaded 0 addresses from peers.dat 0ms
2018-03-05 20:32:17 Starting Thread #0.000000 with Bible #0.000000 torcontrol thread start
2018-03-05 20:32:17 opencon thread start
2018-03-05 20:32:17 mnbcon thread start
2018-03-05 20:32:17 msghand thread start
2018-03-05 20:32:17 BibleMiner -- started thread 0.000000
2018-03-05 20:32:17 addcon thread start
2018-03-05 20:32:17 net thread start
2018-03-05 20:32:17 dnsseed thread start
2018-03-05 20:32:17 Loading addresses from DNS seeds (could take a while)
2018-03-05 20:32:17 ** Started 1.000000 BibleMiner threads. **
2018-03-05 20:32:17 Genesis Hash 3b4431310395638c0ed65b40ede4b110d8da70fcc0c2ed4a729fb8e4d78b4452
2018-03-05 20:32:17 init message: Done loading
2018-03-05 20:32:17 36 addresses found from DNS seeds
2018-03-05 20:32:17 dnsseed thread exit
Mike-
In testnet your e94 CPID has a 100 weight as of a few hours ago: E94C1704C75F731F8BFDE303F08408EE (03-05-2018 12:31:08)": "100
(exec datalist utxoweight) alluding to the fact that since you have multiple cpids, you probably didnt leave the controller wallet on long enough to send 5 UTXO's out. Each CPID requires a separate UTXO. So it might have looped through 4 of your CPIDS and Failed to send the 5th until you manually triggered it a few hours ago...
This is a good reason in Prod we should have One cpid, of course for testing, I realize this is why we have multiple CPIDs.
exec getboincinfo
{
"Command": "getboincinfo",
"CPID": "e94c1704c75f731f8bfde303f08408ee",
"Address": "BTTa9qDMsX6zEQcYJPNu1KptscotKMbPfN",
"CPIDS": "e94c1704c75f731f8bfde303f08408ee;",
"CPID-Age (hours)": 422298,
"NextSuperblockHeight": 33620,
"NextSuperblockBudget": 760165,
"e94c1704c75f731f8bfde303f08408ee_RAC": 5117.84,
"e94c1704c75f731f8bfde303f08408ee_TEAM": 15044,
"e94c1704c75f731f8bfde303f08408ee_TaskWeight": 100,
"e94c1704c75f731f8bfde303f08408ee_UTXOWeight": 0,
"Total_RAC": 5117.84,
"Total Payments (One Day)": 0,
"Total Payments (One Week)": 0,
"Total Budget (One Day)": 0,
"Total Budget (One Week)": 0,
"Superblock Count (One Week)": 0,
"Superblock Hit Count (One Week)": 0,
"Superblock List": "",
"Last Superblock Height": 0,
"Last Superblock Budget": 0,
"Last Superblock Payment": -1,
"Magnitude (One-Day)": 0,
"Magnitude (One-Week)": 0
}
exec podcupdate
{
"Command": "podcupdate",
"PODCUpdate": true
}
exec datalist dcc
{
"DataList": "DCC",
"04FBA56D89A5EB38B1B82F8A6240132C (03-05-2018 08:37:48)": "04fba56d89a5eb38b1b82f8a6240132c;BQJeuW9czNp7XJGFE11sDxqifaYsKSHmGa;BQJeuW9czNp7XJGFE11sDxqifaYsKSHmGa;1981529;INQ84/j9PlIAiksMlIWytRUWeT1Oy1IUearmIBEQwhSGPyv91yrspBm6SoYXiLQ3g5XTKXBNWBQcrs+GQfLbuzI=;0",
"1E7184E17377549D5A7D7A2EDFB51017 (03-05-2018 17:58:54)": "1e7184e17377549d5a7d7a2edfb51017;B7AZbMPwtCNejwiLktZteGKuSgdmUkzq4m;B7AZbMPwtCNejwiLktZteGKuSgdmUkzq4m;1982314;H1xGyUiI2Tpbw7TSUZ8wEymzPo4kbb2sHsy6Fn4WyqesOCMS1JxWqrdnqUo0wC4YwhC4lQEiOH7epkNycltZTfc=;0",
"6785DED1F65063EF8F01F42DEB31CF1D (03-04-2018 23:17:49)": "6785ded1f65063ef8f01f42deb31cf1d;BT9R3ELM81r3uS8aMnKzPq2Mm49mDAVx5j;BT9R3ELM81r3uS8aMnKzPq2Mm49mDAVx5j;1981965;IHbjBdincaH8YS/XL7k6VR9n8dHysachVwo63vwZk732SkG4+Q4qx/qObz2VsYPdBL8RtBpxv5pv3/gmmqtGFPY=;0",
"8791A036B545F35E9EBD9333922738AC (03-04-2018 20:56:07)": "8791a036b545f35e9ebd9333922738ac;BSfnH2uxp8zm8cCmdxVLji7paJz6zNPd7J;BSfnH2uxp8zm8cCmdxVLji7paJz6zNPd7J;1986929;IH0X/f06jDB7DGrsuew6YOgCwq5DPEcPZjW1hvd11BmvbNlPVOo/O6/RNYi028zk6i2pef0hh4dSMw9j3rqpFYU=",
"8F273B30F8E0A298ED26E242762DF701 (03-05-2018 02:22:28)": "8f273b30f8e0a298ed26e242762df701;BLLmyTDgsCtD2gC4dxpSXnFHnpVVewkEiq;BLLmyTDgsCtD2gC4dxpSXnFHnpVVewkEiq;1981270;IN1loec110Y97Y9OILSxtkY1e5o1C9V/xOlrmfqwyD1IS9LA8yczMyFAgRa5nN/KQt+JxU+icBIQpKyJT7UsNUA=;0",
"CA895B47AACFFBDBF906201821AF2F9F (03-05-2018 13:27:33)": "ca895b47aacffbdbf906201821af2f9f;BSw7JZ9r2cFLgLL7tg6oDKDWicGGGzXf4J;BSw7JZ9r2cFLgLL7tg6oDKDWicGGGzXf4J;475629;H1QQr77z7khrCeX3CJn6iUAQRqmqRZyIAl1CJdfeJx3oG9wfeJknjhmBvuokvJSUhqC+3+nzWhsr7T3MOkSoFqg=;0",
"D9B22FCCFAE5582D4EE7838883AAA3CF (03-05-2018 17:58:54)": "d9b22fccfae5582d4ee7838883aaa3cf;BSqcLcFLYt3bKvoUaZ5rGURW75xgjJdQoD;BSqcLcFLYt3bKvoUaZ5rGURW75xgjJdQoD;1981615;IO9jRoYdWOO9iSFJ+yBLrlIqAhzyxKAv16jrpLrB3sqfEBhHuO+Tu8UWNQISXmp1cUePVOKJm8TBvY8gN8DsVuY=;0",
"E94C1704C75F731F8BFDE303F08408EE (03-05-2018 02:22:28)": "e94c1704c75f731f8bfde303f08408ee;BTTa9qDMsX6zEQcYJPNu1KptscotKMbPfN;BTTa9qDMsX6zEQcYJPNu1KptscotKMbPfN;1981209;IG2r+VxRlr+3ceKJhbLnldsMVoZv/uoKgx4SukL9Z+bJdIjpjCMaoceE1Aog7hFOSGJd70eU6bgLJM56hCRwV1k=;0"
}
exec getboincinfo
{
"Command": "getboincinfo",
"CPID": "e94c1704c75f731f8bfde303f08408ee",
"Address": "BTTa9qDMsX6zEQcYJPNu1KptscotKMbPfN",
"CPIDS": "e94c1704c75f731f8bfde303f08408ee;",
"CPID-Age (hours)": 422293,
"NextSuperblockHeight": 33620,
"NextSuperblockBudget": 760165,
"e94c1704c75f731f8bfde303f08408ee_RAC": 4746.2,
"e94c1704c75f731f8bfde303f08408ee_TEAM": 15044,
"e94c1704c75f731f8bfde303f08408ee_TaskWeight": 100,
"e94c1704c75f731f8bfde303f08408ee_UTXOWeight": 0,
"Total_RAC": 4746.2,
"Total Payments (One Day)": 0,
"Total Payments (One Week)": 0,
"Total Budget (One Day)": 0,
"Total Budget (One Week)": 0,
"Superblock Count (One Week)": 0,
"Superblock Hit Count (One Week)": 0,
"Superblock List": "",
"Last Superblock Height": 0,
"Last Superblock Budget": 0,
"Last Superblock Payment": -1,
"Magnitude (One-Day)": 0,
"Magnitude (One-Week)": 0
}
exec datalist dcc
{
"DataList": "DCC",
"04FBA56D89A5EB38B1B82F8A6240132C (03-05-2018 08:37:48)": "04fba56d89a5eb38b1b82f8a6240132c;BQJeuW9czNp7XJGFE11sDxqifaYsKSHmGa;BQJeuW9czNp7XJGFE11sDxqifaYsKSHmGa;1981529;INQ84/j9PlIAiksMlIWytRUWeT1Oy1IUearmIBEQwhSGPyv91yrspBm6SoYXiLQ3g5XTKXBNWBQcrs+GQfLbuzI=;0",
"6785DED1F65063EF8F01F42DEB31CF1D (03-04-2018 23:17:49)": "6785ded1f65063ef8f01f42deb31cf1d;BT9R3ELM81r3uS8aMnKzPq2Mm49mDAVx5j;BT9R3ELM81r3uS8aMnKzPq2Mm49mDAVx5j;1981965;IHbjBdincaH8YS/XL7k6VR9n8dHysachVwo63vwZk732SkG4+Q4qx/qObz2VsYPdBL8RtBpxv5pv3/gmmqtGFPY=;0",
"8791A036B545F35E9EBD9333922738AC (03-04-2018 20:56:07)": "8791a036b545f35e9ebd9333922738ac;BSfnH2uxp8zm8cCmdxVLji7paJz6zNPd7J;BSfnH2uxp8zm8cCmdxVLji7paJz6zNPd7J;1986929;IH0X/f06jDB7DGrsuew6YOgCwq5DPEcPZjW1hvd11BmvbNlPVOo/O6/RNYi028zk6i2pef0hh4dSMw9j3rqpFYU=",
"8F273B30F8E0A298ED26E242762DF701 (03-05-2018 02:22:28)": "8f273b30f8e0a298ed26e242762df701;BLLmyTDgsCtD2gC4dxpSXnFHnpVVewkEiq;BLLmyTDgsCtD2gC4dxpSXnFHnpVVewkEiq;1981270;IN1loec110Y97Y9OILSxtkY1e5o1C9V/xOlrmfqwyD1IS9LA8yczMyFAgRa5nN/KQt+JxU+icBIQpKyJT7UsNUA=;0",
"CA895B47AACFFBDBF906201821AF2F9F (03-05-2018 13:27:33)": "ca895b47aacffbdbf906201821af2f9f;BSw7JZ9r2cFLgLL7tg6oDKDWicGGGzXf4J;BSw7JZ9r2cFLgLL7tg6oDKDWicGGGzXf4J;475629;H1QQr77z7khrCeX3CJn6iUAQRqmqRZyIAl1CJdfeJx3oG9wfeJknjhmBvuokvJSUhqC+3+nzWhsr7T3MOkSoFqg=;0",
"D9B22FCCFAE5582D4EE7838883AAA3CF (03-05-2018 13:22:45)": "d9b22fccfae5582d4ee7838883aaa3cf;BSqcLcFLYt3bKvoUaZ5rGURW75xgjJdQoD;BSqcLcFLYt3bKvoUaZ5rGURW75xgjJdQoD;1981615;IO9jRoYdWOO9iSFJ+yBLrlIqAhzyxKAv16jrpLrB3sqfEBhHuO+Tu8UWNQISXmp1cUePVOKJm8TBvY8gN8DsVuY=;0",
"E94C1704C75F731F8BFDE303F08408EE (03-05-2018 02:22:28)": "e94c1704c75f731f8bfde303f08408ee;BTTa9qDMsX6zEQcYJPNu1KptscotKMbPfN;BTTa9qDMsX6zEQcYJPNu1KptscotKMbPfN;1981209;IG2r+VxRlr+3ceKJhbLnldsMVoZv/uoKgx4SukL9Z+bJdIjpjCMaoceE1Aog7hFOSGJd70eU6bgLJM56hCRwV1k=;0"
}
On walletbackups, the dash subsystem does create a copy of wallet.dat once per boot and copies this file into \backups. Something like mmddyyyy.dat.
I recommend keeping a copy of a good wallet offsite - maybe on a CD and USB flash if possible in a safe.
Anyway regarding the necessity to make constant backups: There is truth to both sides but let me explain this nuance.
It is true, that if you only have one plain vanilla address with all your BBP allocated to that address, no matter how big the physical wallet.dat file gets, you can always get back all your bbp, if you had a backup of that original small file somewhere. The wallet will expand in size as you resync the chain and you will gain all your BBP back.
The specific issue that requires you to back your wallet more often is this: If you *add* a receiving address to the wallet, it comes with 1000 keys, if you have been mining for a while, if the action of creating a new address (doing that creates a keypair - a private key and a public wallet address), if that resulted in creating a new keypair that was *not* in the original backup, *and* you send BBP from somewhere to that new address, now that part of your balance is *not* in the original wallet. Now you need a new backup.
So you either have to cognizently re-send your BBP periodically to your *original* address, and then you are fine, *or* keep backing it up.
Btw, an easy way to understand this is if you loop through your addresses and balances, if you were to type:
dumpprivkey publicbbpaddress
For each address with a balance, you could print those keys out to a printer and have a way to gain access to the BBP if you ever lost the cold wallet backup...
Its also beneficial to consolidate your wallet as the core will run faster, but it also risks a loss of privacy. The reason the devs made so many keys it to obfuscate your identity. If you dont care about anonymity, by all means send it all back to one address. If you do care about anonymity let it bloat and keep backing it up on a regular basis.
I haven't voted yet because I think we should talk more about the details before I can say 'yes' or 'no'.
But I like your last post. I'd really like to have a group that audits new charities and shares their results with the community. And I also like the idea to have some reserves to survive the meager months. Obviously, the reserves have to be handled by someone (or a group), but any proposal eventually comes down on trusting the person that proposed it. So, as long as the fund is not mega-large (say, the size of one monthly charity budget), I wouldn't have much problems with it.
But I don't know what to think about the masternode-idea at this point of time, especially when there will be multitude of them. Power corrupts, and that's why I like the idea of as much decentralization as possible in the first place, so there is no room for temptation.
Or course, it all comes down to economics in the end: would you invest in a coin which continually dumps half its generated coins on the open market? Maybe we can generate more money in the long run if we keep the charity budget at 10%. Of course, the charity budget is fixed, but I mean that in the scenario where half the masternodes are owned by a group that sells almost everything they generate, this will lessen the coins value (I think).
That is not necessarily true. As far as I know, the wallet creates a new batch of keys after a certain number have been used (I think it's default number is 1000?), so if you do a lot of transactions, you have to redo your updates.
Also, if you have an unencrypted wallet.dat, and you encrypt it, you have to make a new backup, because the old wallet.dat becomes unusable as I understand it.
thanks