Search content
Sort by
Showing 20 of 23 results by rastiks
WOOF COIN
Since the beginning of the pandemic, pet surrendering rates have increased dramatically around the world. Waitlists for surrendering household pets have increased to a remarkable eight months as animal shelters and welfare organisations have seen an increase of 34% for animals needing help.
Typically, animal shelters are under resourced and under financed; relying heavily on donations and the volunteer efforts to assist animals.
This is where Woof Coin steps in. As avid lovers of dogs, we wanted to make a difference. Using the power of Proof of Work mining, weâve created a coin where miners are contributing to the donation of money to animal welfare shelters. These shelters initially include the ASPCA who already have a cryptocurrency donation mechanism but with intention to expand to the RSPCA and other organizations suggested by the community.
Our aim is to put animals first and we intend on developing ongoing relationships with pet shelters to help adoption.
Coins Specifications
21 billion supply
Block 2,100,000 halving (4 years estimated)
Algorithm: KawPOW
Proof of Work
Download Links:
https://github.com/WoofCoinMain/WoofCoin/releases/download/WoofCoin/WoofCoin.zip
Social
Coming soon!
Please reach out if you have any questions Smiley
Re: BiblePay✟CPU✟Governance✟Help Orphans✟PODC Cancer Mining✟Deflationary✟Masternodes
The only thing so far I dont like about the proposal is what West mentioned about 'double dipping'. I never did like that possibility.
If you have to stake BBP to earn PoDC rewards, it is not "double-dipping" for free. I'd argue that GridCoin users are the ideal crossover because they understand crypto already. Blacklisting the team gives them little incentive to join BiblePay.
+1. I would not ban them, I would actually invite them to double-dip BBP. Double-dipping BBP investors are much better than no BBP investors. Most of us are double dipping Byteball anyway (while still being part of the BBP team). To be fair, we should allow them to do the same in opposite direction.
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
Hi,
could somebody please check whether I am running on a fork or what has happened?
could somebody please check whether I am running on a fork or what has happened?
I imported your address as watch-only and see the right balance (the same seen on the explorer)
What wallet version do you have?
# biblepayd --version
Biblepay Core Daemon version 1.1.4.3
This version should be ok. It seems it's only counting the transactions from to 11th Aug onwards (which sum 55786) but not the previous ones.
Try to check if your machine finds this transaction (one of the missed ones)
getrawtransaction edcdb5a88e17a61d59b52e093f7535af00352faa4dc672a2517b048a9a343406 1
And also try to restart the daemon with -zapwallettxes=1 option to try to recover those unaccounted transactions.
-zapwallettxes=1 fixed that, thanks!
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
Hi,
could somebody please check whether I am running on a fork or what has happened?
could somebody please check whether I am running on a fork or what has happened?
I imported your address as watch-only and see the right balance (the same seen on the explorer)
What wallet version do you have?
# biblepayd --version
Biblepay Core Daemon version 1.1.4.3
This version should be ok. It seems it's only counting the transactions from to 11th Aug onwards (which sum 55786) but not the previous ones.
Try to check if your machine finds this transaction (one of the missed ones)
getrawtransaction edcdb5a88e17a61d59b52e093f7535af00352faa4dc672a2517b048a9a343406 1
And also try to restart the daemon with -zapwallettxes=1 option to try to recover those unaccounted transactions.
seems that it finds it:
Code:
# biblepay-cli getrawtransaction edcdb5a88e17a61d59b52e093f7535af00352faa4dc672a2517b048a9a343406 1
{
"hex": "0100000002e3e1858c62d9935b02c6bf9085f0793d5b81a447f8987e43d724d3f1e432934a010000006a473044022011ebd013828bb681ba5d9b4a2e5623a3edf13e92e0abf992bb047eb3f150eaf702201db0ac843c699ef0065853c355621d9d36dabde90e50d886119335d63f5431e701210222e14ceb34fdc5d82e232dccbbd7095b772db184450e8b713308d641d08ad62afeffffffe490fe749000514f5d10306e08c6c048abd1e80e123f85f1b0aa88ff8c4823bb000000006b483045022100a8b6c5fda2e2e7387d0306ff3e070dba80edd0d7d1fa5c58753be3320c33af1302200345d5439d5e7fba7933dab1210fd29b5285504df66a97bda5e7c11c0d2c418801210380782431516b5519d9f6681c74a97b121f90805c9e8999f881b7d0df28a9601cfeffffff024f68c300000000001976a9148ce37bb5100ebe036ebf2b9203581a90be7f534188ac123c6368616e67653e313c2f6368616e67653e00fedb16e7ef00001976a914e734c92cb5e5b2eb5340fc117e48b26370a64dd888acfd7c013c42434d3e3c4d543e504f44435f5550444154453c2f4d543e3c4d4b3e61623535396632636533366161623835346466353836303561613038623530633c2f4d4b3e3c504f44435f5441534b533e313032313031383733363d313533333838313634372c313032313031383733373d313533333838313634373c2f504f44435f5441534b533e3c637069647369673e61623535396632636533366161623835346466353836303561613038623530633b363430626162636534643836633436656662353535666632386363666432393339383663636566333734313662623265376466356637373832626162623463633b4252586177656f74464346633631326a584a6f6f4454575943506467704b3831466d3b483549505847454c4a567939596b4d6c4767797647507879776766705a73556d2f697779306d364f4f5244464f4f596b6e4c4c374537636c564c516a626d485634616b437831325565504f4b614759512f65486845486b3d3c2f637069647369673e3c2f42434d3e96f80000",
"txid": "edcdb5a88e17a61d59b52e093f7535af00352faa4dc672a2517b048a9a343406",
"size": 775,
"version": 1,
"locktime": 63638,
"vin": [
{
"txid": "4a9332e4f1d324d7437e98f847a4815b3d79f08590bfc6025b93d9628c85e1e3",
"vout": 1,
"scriptSig": {
"asm": "3044022011ebd013828bb681ba5d9b4a2e5623a3edf13e92e0abf992bb047eb3f150eaf702201db0ac843c699ef0065853c355621d9d36dabde90e50d886119335d63f5431e7[ALL] 0222e14ceb34fdc5d82e232dccbbd7095b772db184450e8b713308d641d08ad62a",
"hex": "473044022011ebd013828bb681ba5d9b4a2e5623a3edf13e92e0abf992bb047eb3f150eaf702201db0ac843c699ef0065853c355621d9d36dabde90e50d886119335d63f5431e701210222e14ceb34fdc5d82e232dccbbd7095b772db184450e8b713308d641d08ad62a"
},
"sequence": 4294967294
},
{
"txid": "bb23488cff88aab0f1853f120ee8d1ab48c0c6086e30105d4f51009074fe90e4",
"vout": 0,
"scriptSig": {
"asm": "3045022100a8b6c5fda2e2e7387d0306ff3e070dba80edd0d7d1fa5c58753be3320c33af1302200345d5439d5e7fba7933dab1210fd29b5285504df66a97bda5e7c11c0d2c4188[ALL] 0380782431516b5519d9f6681c74a97b121f90805c9e8999f881b7d0df28a9601c",
"hex": "483045022100a8b6c5fda2e2e7387d0306ff3e070dba80edd0d7d1fa5c58753be3320c33af1302200345d5439d5e7fba7933dab1210fd29b5285504df66a97bda5e7c11c0d2c418801210380782431516b5519d9f6681c74a97b121f90805c9e8999f881b7d0df28a9601c"
},
"sequence": 4294967294
}
],
"vout": [
{
"value": 0.12806223,
"valueSat": 12806223,
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 8ce37bb5100ebe036ebf2b9203581a90be7f5341 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9148ce37bb5100ebe036ebf2b9203581a90be7f534188ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"BHJ2jPDJS1KD6pV8G7UwYGRcA3zVmW9ff4"
]
},
"message": "1"
},
{
"value": 2637758.00000000,
"valueSat": 263775800000000,
"n": 1,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 e734c92cb5e5b2eb5340fc117e48b26370a64dd8 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914e734c92cb5e5b2eb5340fc117e48b26370a64dd888ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"BRXaweotFCFc612jXJooDTWYCPdgpK81Fm"
]
},
"message": "PODC_UPDATEab559f2ce36aab854df58605aa08b50c1021018736=1533881647,1021018737=1533881647ab559f2ce36aab854df58605aa08b50c;640babce4d86c46efb555ff28ccfd293986ccef37416bb2e7df5f7782babb4cc;BRXaweotFCFc612jXJooDTWYCPdgpK81Fm;H5IPXGELJVy9YkMlGgyvGPxywgfpZsUm/iwy0m6OORDFOOYknLL7E7clVLQjbmHV4akCx12UePOKaGYQ/eHhEHk="
}
],
"blockhash": "7b6a1d6e5fa05768a7a3aada438a5ca7210fa3c4930c67b77e8c7fc61070a017",
"height": 63639,
"confirmations": 687,
"time": 1533883188,
"blocktime": 1533883188
}
{
"hex": "0100000002e3e1858c62d9935b02c6bf9085f0793d5b81a447f8987e43d724d3f1e432934a010000006a473044022011ebd013828bb681ba5d9b4a2e5623a3edf13e92e0abf992bb047eb3f150eaf702201db0ac843c699ef0065853c355621d9d36dabde90e50d886119335d63f5431e701210222e14ceb34fdc5d82e232dccbbd7095b772db184450e8b713308d641d08ad62afeffffffe490fe749000514f5d10306e08c6c048abd1e80e123f85f1b0aa88ff8c4823bb000000006b483045022100a8b6c5fda2e2e7387d0306ff3e070dba80edd0d7d1fa5c58753be3320c33af1302200345d5439d5e7fba7933dab1210fd29b5285504df66a97bda5e7c11c0d2c418801210380782431516b5519d9f6681c74a97b121f90805c9e8999f881b7d0df28a9601cfeffffff024f68c300000000001976a9148ce37bb5100ebe036ebf2b9203581a90be7f534188ac123c6368616e67653e313c2f6368616e67653e00fedb16e7ef00001976a914e734c92cb5e5b2eb5340fc117e48b26370a64dd888acfd7c013c42434d3e3c4d543e504f44435f5550444154453c2f4d543e3c4d4b3e61623535396632636533366161623835346466353836303561613038623530633c2f4d4b3e3c504f44435f5441534b533e313032313031383733363d313533333838313634372c313032313031383733373d313533333838313634373c2f504f44435f5441534b533e3c637069647369673e61623535396632636533366161623835346466353836303561613038623530633b363430626162636534643836633436656662353535666632386363666432393339383663636566333734313662623265376466356637373832626162623463633b4252586177656f74464346633631326a584a6f6f4454575943506467704b3831466d3b483549505847454c4a567939596b4d6c4767797647507879776766705a73556d2f697779306d364f4f5244464f4f596b6e4c4c374537636c564c516a626d485634616b437831325565504f4b614759512f65486845486b3d3c2f637069647369673e3c2f42434d3e96f80000",
"txid": "edcdb5a88e17a61d59b52e093f7535af00352faa4dc672a2517b048a9a343406",
"size": 775,
"version": 1,
"locktime": 63638,
"vin": [
{
"txid": "4a9332e4f1d324d7437e98f847a4815b3d79f08590bfc6025b93d9628c85e1e3",
"vout": 1,
"scriptSig": {
"asm": "3044022011ebd013828bb681ba5d9b4a2e5623a3edf13e92e0abf992bb047eb3f150eaf702201db0ac843c699ef0065853c355621d9d36dabde90e50d886119335d63f5431e7[ALL] 0222e14ceb34fdc5d82e232dccbbd7095b772db184450e8b713308d641d08ad62a",
"hex": "473044022011ebd013828bb681ba5d9b4a2e5623a3edf13e92e0abf992bb047eb3f150eaf702201db0ac843c699ef0065853c355621d9d36dabde90e50d886119335d63f5431e701210222e14ceb34fdc5d82e232dccbbd7095b772db184450e8b713308d641d08ad62a"
},
"sequence": 4294967294
},
{
"txid": "bb23488cff88aab0f1853f120ee8d1ab48c0c6086e30105d4f51009074fe90e4",
"vout": 0,
"scriptSig": {
"asm": "3045022100a8b6c5fda2e2e7387d0306ff3e070dba80edd0d7d1fa5c58753be3320c33af1302200345d5439d5e7fba7933dab1210fd29b5285504df66a97bda5e7c11c0d2c4188[ALL] 0380782431516b5519d9f6681c74a97b121f90805c9e8999f881b7d0df28a9601c",
"hex": "483045022100a8b6c5fda2e2e7387d0306ff3e070dba80edd0d7d1fa5c58753be3320c33af1302200345d5439d5e7fba7933dab1210fd29b5285504df66a97bda5e7c11c0d2c418801210380782431516b5519d9f6681c74a97b121f90805c9e8999f881b7d0df28a9601c"
},
"sequence": 4294967294
}
],
"vout": [
{
"value": 0.12806223,
"valueSat": 12806223,
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 8ce37bb5100ebe036ebf2b9203581a90be7f5341 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9148ce37bb5100ebe036ebf2b9203581a90be7f534188ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"BHJ2jPDJS1KD6pV8G7UwYGRcA3zVmW9ff4"
]
},
"message": "1"
},
{
"value": 2637758.00000000,
"valueSat": 263775800000000,
"n": 1,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 e734c92cb5e5b2eb5340fc117e48b26370a64dd8 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914e734c92cb5e5b2eb5340fc117e48b26370a64dd888ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"BRXaweotFCFc612jXJooDTWYCPdgpK81Fm"
]
},
"message": "PODC_UPDATEab559f2ce36aab854df58605aa08b50c1021018736=1533881647,1021018737=1533881647ab559f2ce36aab854df58605aa08b50c;640babce4d86c46efb555ff28ccfd293986ccef37416bb2e7df5f7782babb4cc;BRXaweotFCFc612jXJooDTWYCPdgpK81Fm;H5IPXGELJVy9YkMlGgyvGPxywgfpZsUm/iwy0m6OORDFOOYknLL7E7clVLQjbmHV4akCx12UePOKaGYQ/eHhEHk="
}
],
"blockhash": "7b6a1d6e5fa05768a7a3aada438a5ca7210fa3c4930c67b77e8c7fc61070a017",
"height": 63639,
"confirmations": 687,
"time": 1533883188,
"blocktime": 1533883188
}
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
Hi,
could somebody please check whether I am running on a fork or what has happened?
could somebody please check whether I am running on a fork or what has happened?
I imported your address as watch-only and see the right balance (the same seen on the explorer)
What wallet version do you have?
# biblepayd --version
Biblepay Core Daemon version 1.1.4.3
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
Hi,
could somebody please check whether I am running on a fork or what has happened?
According to the explorer, I should own 2694815.91041965 BBP (which is true) http://explorer.biblepay.org:3001/address/BRXaweotFCFc612jXJooDTWYCPdgpK81Fm
But my wallet shows only 55786.61683641 (yesterday it was all OK). I have already rebuilt the blocks from scratch 2 times (wiped everything except from the wallet.dat), with no luck:
could somebody please check whether I am running on a fork or what has happened?
According to the explorer, I should own 2694815.91041965 BBP (which is true) http://explorer.biblepay.org:3001/address/BRXaweotFCFc612jXJooDTWYCPdgpK81Fm
But my wallet shows only 55786.61683641 (yesterday it was all OK). I have already rebuilt the blocks from scratch 2 times (wiped everything except from the wallet.dat), with no luck:
Code:
# biblepay-cli getwalletinfo
{
"walletversion": 61000,
"balance": 55786.61683641,
"retirement_account_balance": 0,
"unconfirmed_balance": 0.00000000,
"immature_balance": 0.00000000,
"txcount": 56,
"keypoololdest": 1533208791,
"keypoolsize": 1001,
"keys_left": 1005,
"paytxfee": 0.00000000
}
{
"walletversion": 61000,
"balance": 55786.61683641,
"retirement_account_balance": 0,
"unconfirmed_balance": 0.00000000,
"immature_balance": 0.00000000,
"txcount": 56,
"keypoololdest": 1533208791,
"keypoolsize": 1001,
"keys_left": 1005,
"paytxfee": 0.00000000
}
Code:
# biblepay-cli getblockchaininfo
{
"chain": "main",
"blocks": 64309,
"headers": 64309,
"bestblockhash": "82c0f814752ab5deffc7bf60d3b708cad066b829703a67098c8fa4fc91743d03",
"difficulty": 1572.61248850884,
"mediantime": 1534163700,
"verificationprogress": 0.9999932092824506,
"chainwork": "000000000000000000000000000000000000000000000000088815a364a4df3f",
"pruned": false,
"softforks": [
{
"id": "bip34",
"version": 2,
"enforce": {
"status": true,
"found": 1000,
"required": 750,
"window": 1000
},
"reject": {
"status": true,
"found": 1000,
"required": 950,
"window": 1000
}
},
{
"id": "bip66",
"version": 3,
"enforce": {
"status": true,
"found": 1000,
"required": 750,
"window": 1000
},
"reject": {
"status": true,
"found": 1000,
"required": 950,
"window": 1000
}
},
{
"id": "bip65",
"version": 4,
"enforce": {
"status": true,
"found": 1000,
"required": 750,
"window": 1000
},
"reject": {
"status": true,
"found": 1000,
"required": 950,
"window": 1000
}
}
],
"bip9_softforks": [
{
"id": "csv",
"status": "failed"
}
]
}
{
"chain": "main",
"blocks": 64309,
"headers": 64309,
"bestblockhash": "82c0f814752ab5deffc7bf60d3b708cad066b829703a67098c8fa4fc91743d03",
"difficulty": 1572.61248850884,
"mediantime": 1534163700,
"verificationprogress": 0.9999932092824506,
"chainwork": "000000000000000000000000000000000000000000000000088815a364a4df3f",
"pruned": false,
"softforks": [
{
"id": "bip34",
"version": 2,
"enforce": {
"status": true,
"found": 1000,
"required": 750,
"window": 1000
},
"reject": {
"status": true,
"found": 1000,
"required": 950,
"window": 1000
}
},
{
"id": "bip66",
"version": 3,
"enforce": {
"status": true,
"found": 1000,
"required": 750,
"window": 1000
},
"reject": {
"status": true,
"found": 1000,
"required": 950,
"window": 1000
}
},
{
"id": "bip65",
"version": 4,
"enforce": {
"status": true,
"found": 1000,
"required": 750,
"window": 1000
},
"reject": {
"status": true,
"found": 1000,
"required": 950,
"window": 1000
}
}
],
"bip9_softforks": [
{
"id": "csv",
"status": "failed"
}
]
}
Code:
# biblepay-cli listaddressgroupings
[
[
[
"B5nUax3CnE5dKFiByMqye1hSyPwegKhk3n",
0.00000000
],
[
"B6CDSA1w58XqBY4cUb9u4m8vC26neYPK6m",
0.00000000
],
[
"B6taiAU3UxdEmbKB12mK8DpMLEUWuHHmua",
0.00000000
],
[
"B6zvUd3tHj5XDqYX9n3pVb2T94jUqgJT6n",
0.03544319
],
[
"B8cXu8d6SUt4pzphoSvw5wBes2DdKNqprb",
0.00000000
],
[
"B9SJv35whgeZajfAw67F2H2yWne7eZ1oTk",
0.00000000
],
[
"BAQW9PWgGASUrPj45Y5zLGL34bUimMV8oF",
0.00000000
],
[
"BBnLucAEnEZZ69XAyM64QFnxyJCZzc9h7c",
0.00000000
],
[
"BEzrn9ZVSqUUFRYjaz8gV4SAkSpvTyTmgE",
0.00000000
],
[
"BFtRYoA1zped9FAHgkzAvxSexVjNb1EkTR",
0.00000000
],
[
"BGCofo4Sux63gGu3EBSnnGhf34EZ8vHQ87",
0.00000000
],
[
"BGozZmuWxecRpgBmJ8gX5R4Nbe3b9KXqtd",
0.00000000
],
[
"BGvzX6oKqykbtJJA2R6AsyNCHPUHn67Gxo",
0.00000000,
""
],
[
"BHJ2jPDJS1KD6pV8G7UwYGRcA3zVmW9ff4",
0.00000000
],
[
"BJFnYNRv7Qn5CHxtrNmMYzQibHJZcEpJ3g",
0.00000000
],
[
"BJxgnGwcFTreLDHSh2fits5K7VbT3sG1xf",
0.00000000
],
[
"BKxeAfXpEZtsRRfqZB4p4Nvjumv8tEqTfU",
0.00000000
],
[
"BMHYgDX7LWf8hqh48zi6En3svcXYZ31pyM",
0.00000000
],
[
"BNDqSZQrd5HhZAoS688P8PtG2CxebEZmYQ",
0.00000000,
""
],
[
"BQcwWeXwEJ1XGcQQrStQmcydX2DsYqafGJ",
0.39388021
],
[
"BQio9B71NjJsi2c4RYT8hJefpfCDLkf3Xv",
0.00000000,
""
],
[
"BR463rxQ5Y1cyM4tNSfA6tyXySS4VWpPLJ",
0.18729881
],
[
"BRTJJacNoxE9gDScim2oeMVHGnJSXLpyQM",
0.00000000
],
[
"BRXaweotFCFc612jXJooDTWYCPdgpK81Fm",
55786.00000000,
""
],
[
"BTMUqoEU5ifKRRfcZXJG5p7A1Dx9vuXsJx",
0.00000000
],
[
"BTUjqQpfXSH2ytmhuviFv7WBYtdDcXQDB8",
0.00000000
]
],
[
[
"BABiFX2pUgJXPS8JHh2uuVALDPxcmFy9hG",
0.00000000
]
]
]
[
[
[
"B5nUax3CnE5dKFiByMqye1hSyPwegKhk3n",
0.00000000
],
[
"B6CDSA1w58XqBY4cUb9u4m8vC26neYPK6m",
0.00000000
],
[
"B6taiAU3UxdEmbKB12mK8DpMLEUWuHHmua",
0.00000000
],
[
"B6zvUd3tHj5XDqYX9n3pVb2T94jUqgJT6n",
0.03544319
],
[
"B8cXu8d6SUt4pzphoSvw5wBes2DdKNqprb",
0.00000000
],
[
"B9SJv35whgeZajfAw67F2H2yWne7eZ1oTk",
0.00000000
],
[
"BAQW9PWgGASUrPj45Y5zLGL34bUimMV8oF",
0.00000000
],
[
"BBnLucAEnEZZ69XAyM64QFnxyJCZzc9h7c",
0.00000000
],
[
"BEzrn9ZVSqUUFRYjaz8gV4SAkSpvTyTmgE",
0.00000000
],
[
"BFtRYoA1zped9FAHgkzAvxSexVjNb1EkTR",
0.00000000
],
[
"BGCofo4Sux63gGu3EBSnnGhf34EZ8vHQ87",
0.00000000
],
[
"BGozZmuWxecRpgBmJ8gX5R4Nbe3b9KXqtd",
0.00000000
],
[
"BGvzX6oKqykbtJJA2R6AsyNCHPUHn67Gxo",
0.00000000,
""
],
[
"BHJ2jPDJS1KD6pV8G7UwYGRcA3zVmW9ff4",
0.00000000
],
[
"BJFnYNRv7Qn5CHxtrNmMYzQibHJZcEpJ3g",
0.00000000
],
[
"BJxgnGwcFTreLDHSh2fits5K7VbT3sG1xf",
0.00000000
],
[
"BKxeAfXpEZtsRRfqZB4p4Nvjumv8tEqTfU",
0.00000000
],
[
"BMHYgDX7LWf8hqh48zi6En3svcXYZ31pyM",
0.00000000
],
[
"BNDqSZQrd5HhZAoS688P8PtG2CxebEZmYQ",
0.00000000,
""
],
[
"BQcwWeXwEJ1XGcQQrStQmcydX2DsYqafGJ",
0.39388021
],
[
"BQio9B71NjJsi2c4RYT8hJefpfCDLkf3Xv",
0.00000000,
""
],
[
"BR463rxQ5Y1cyM4tNSfA6tyXySS4VWpPLJ",
0.18729881
],
[
"BRTJJacNoxE9gDScim2oeMVHGnJSXLpyQM",
0.00000000
],
[
"BRXaweotFCFc612jXJooDTWYCPdgpK81Fm",
55786.00000000,
""
],
[
"BTMUqoEU5ifKRRfcZXJG5p7A1Dx9vuXsJx",
0.00000000
],
[
"BTUjqQpfXSH2ytmhuviFv7WBYtdDcXQDB8",
0.00000000
]
],
[
[
"BABiFX2pUgJXPS8JHh2uuVALDPxcmFy9hG",
0.00000000
]
]
]
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
Rob, I tried migrating completely to WCG to test this last week and noticed my wallet stopped sending PODC updates after a week. I read through my log and discovered that after suspending Rosetta on each machine, the first number in my PODC Updates steadily decreased. It went from "PODCUpdate Processed (7) over 1 CPID(s) successfully" down to "PODCUpdate Processed (1) over 1 CPID(s) successfully." and then finally PODCUpdate Processed 0 tasks for CPID. At this point, my wallet transaction list no longer showed PODC updates. I tried manually running "exec podcupdate true" but it would fail and say Processed (0). Only until I took one of my machines and started crunching Rosetta again, was I able to get it to run PODC updates once again automatically.
Do you think you could explain this? Thanks!
Do you think you could explain this? Thanks!
I'm experiencing the same issue right now. Few days after I solved my last Rosetta task, I stopped receiving rewards - the wallet is not sending PODC updates.
"exec podcupdate true" it would fail and say Processed (0) tasks.
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
Helping miners won't do anything to raise the price of BBP. Miners don't help the price of a cryptocurrency, miners only introduce supply. All new supply of a cryptocurrency is introduced by miners. Lowering RAC is only an encouragement to introduce more supply.
The way to help the price of BBP is by encouraging buyers to buy BBP. But buyers are not encouraged to buy any alts right now as the price of BTC is decreasing. Since BBP is priced in BTC, no one is encouraged to buy BBP.
A way to encourage potential buyers to buy without regard to the future value of BBP is to encourage people to buy BBP in order to support orphans. Most of these people could be found in churches. Let them know the benefit of buying BBP versus giving to a conventional charity because they might actually realize a profit from their "gift of buying BBP" whereas giving to a traditional charity gives them no chance of realizing a profit.
EDIT
So in summary, I believe people are afraid to buy BBP because they are afraid of BTC continuing lower. I won't be surprised if BTC touches $4000. $4000 was the average price for 2017 and BTC has a history of reverting to the prior year's mean. There isn't much we can do about that. But we can encourage people to buy to support orphans with the chance of realizing a profit.
BBP tagline should be: Support orhphans and do good with the chance of realizing a profit.
The way to help the price of BBP is by encouraging buyers to buy BBP. But buyers are not encouraged to buy any alts right now as the price of BTC is decreasing. Since BBP is priced in BTC, no one is encouraged to buy BBP.
A way to encourage potential buyers to buy without regard to the future value of BBP is to encourage people to buy BBP in order to support orphans. Most of these people could be found in churches. Let them know the benefit of buying BBP versus giving to a conventional charity because they might actually realize a profit from their "gift of buying BBP" whereas giving to a traditional charity gives them no chance of realizing a profit.
EDIT
So in summary, I believe people are afraid to buy BBP because they are afraid of BTC continuing lower. I won't be surprised if BTC touches $4000. $4000 was the average price for 2017 and BTC has a history of reverting to the prior year's mean. There isn't much we can do about that. But we can encourage people to buy to support orphans with the chance of realizing a profit.
BBP tagline should be: Support orhphans and do good with the chance of realizing a profit.
+1, well put
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
@ Rob: Again, I don't think the WCG mags are diminished the way they should. I cannot see any changes for the last 3 superblocks now. 
I believe its working but its a day behind: I had approx 10K WCG RAC about 5 days ago- before the reduction I was receiving 15,000 WCG RAC in the superblock view report. Now my RAC on WCG is 9300, the factor was at .90 yesterday, today I am down to 9198.
The factor is now down to .70, but it wont hit until the next superblock.
So I believe the issue is that it is 1 day behind when it hits the sancs.
As per your original post, we should be on 0 on June 9th. Are we still on track with this (assuming it will hit sancs on June 10th), or will it be later?
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
Hi all. One of the Slovak guys messaged me with an issue he is having that I couldn't help with. Perhaps someone can give mesome ideas to help?
Basically:
1. On a Windows server, same machine as Linux boxes he owns, all his cpu stats are 100% on Rosetta. Or in other words, all of his processing power is BOINC-ing.
2. On Linux server, with WCG exactly the same, all cpu stats are 100%.
3. On Linux server, with Rosetta, some cpu cores are 100%, others are much lower.
He is on Ubuntu 16.04 LTS.
So for some reason Rosetta on Linux is not downloading enough tasks for his machine?
He tried reinstalling and restarting server but no luck.
Any suggestions?
Thanks
Basically:
1. On a Windows server, same machine as Linux boxes he owns, all his cpu stats are 100% on Rosetta. Or in other words, all of his processing power is BOINC-ing.
2. On Linux server, with WCG exactly the same, all cpu stats are 100%.
3. On Linux server, with Rosetta, some cpu cores are 100%, others are much lower.
He is on Ubuntu 16.04 LTS.
So for some reason Rosetta on Linux is not downloading enough tasks for his machine?
He tried reinstalling and restarting server but no luck.
Any suggestions?
Thanks
What is the RAM utilization on the Linux server? Rosetta is much more RAM demanding, it may be throttling the number of concurrent tasks because of the RAM limit.
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
I actually talked about BBP to some friends that were interested in mining it. I did a calculation according to my data for them - the fact that they would need to buy BBP for 1000 USD in order to be able to mine with the daily profit of ~8 USD minus electricity & HW costs discouraged all of them. Part of them couldn't even afford that, another part said that it would be too risky for them (given the market cap) :-(
I was thinking about a way how we could make mining less easy for big whales, where (I'm guessing) a single person controls large amount of some spare datacenter servers. I like the idea of writing letters to orphans and having this manual work needed in order to get mining rewards, but it brings challenges for non-native English speakers. But if there were also some other ways of supporting orphans, so that people could actually choose from multiple of them an get some points for that that would count in the reward formula, it could help the "average" miners.
Also, it seems that the big whales still use temporary servers (e.g. a server that is mining for few hours and then vanishes). As we saw when we run out of Rosetta tasks, it brings challenges to BOINC infrastructure, so perhaps we could penalize miners with many cancelled/unfinished tasks or with servers with "small age"?
I was thinking about a way how we could make mining less easy for big whales, where (I'm guessing) a single person controls large amount of some spare datacenter servers. I like the idea of writing letters to orphans and having this manual work needed in order to get mining rewards, but it brings challenges for non-native English speakers. But if there were also some other ways of supporting orphans, so that people could actually choose from multiple of them an get some points for that that would count in the reward formula, it could help the "average" miners.
Also, it seems that the big whales still use temporary servers (e.g. a server that is mining for few hours and then vanishes). As we saw when we run out of Rosetta tasks, it brings challenges to BOINC infrastructure, so perhaps we could penalize miners with many cancelled/unfinished tasks or with servers with "small age"?
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
is there any problem with rosetta tasks again? all my computers have insufficient tasks amount 
I've not noticed it on my end and while the available tasks are a bit below average on the server, https://boinc.bakerlab.org/rosetta/server_status.php shows 2026 unsent Rosetta tasks and 13234 Rosetta Mini tasks so you shouldn't be having an issue.
My test machines are supposed to arrive tomorrow and I'll split them evenly between WCG and R@h so in a few days should have a good baseline for what is to be expected between the two for determining a fair RAC equivalent. But in the meantime, you might consider throwing some power at WCG as a hedge. The R@h project we're tending to be in the 15% work performed range (we solved 13% of the work units overall yesterday), whereas if we did a comparable amount of work at WCG (roughly 5M RAC) we'd be around 3-5% (although right now we're less than 1%). That is to say the WCG project can handle the influx much better than R@h can.
Sadly, my instances were terminated before I could get any accurate data. I don't have any similar machines at my disposal anymore and sadly I cannot afford to start again at this point.
So far I've got 2 smaller machines that have been up for a week and are showing mid 2300 under host average credit (in BOINC), and the two identical machines to those were showing 3800 RAC.
I did fire up four identical heavier computers last night ,two on R@h and two on WCG, it will take until the end of the weekend to begin to get meaningful data from those.
Well, I can share some numbers too. I have a 12/24 core Xeon X5650 server which was running Rosetta tasks for ~30 days and during that period its maximum RAC climbed to 9612. Then I moved it to RAH:WCG in 50:50 ratio and about a week ago, I moved it to 100% WCG. The current RAC is:
$ boinccmd --get_project_status | grep host_expavg
host_expavg_credit: 2619.250212
host_expavg_credit: 6877.862939
2619 is for RAH, 6877 is for WCG. With * 1.5 factor for WCG, this particular server now produces RAC = 1.5 * 6877 + 2619 = 12934 copared to the 9612 when it was running Rosetta only (and I expect it to be even more as RAH decreases and WCG increases, I can update later). For this server, it seems that RAH RAC = WCG RAC.
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
Hi,
if anybody is interested in my seat in the shared masternode, contact me or joelles - I decided to leave.
I'm offering this week's earnings as a bonus if somebody joins until Thursday end of the day
if anybody is interested in my seat in the shared masternode, contact me or joelles - I decided to leave.
I'm offering this week's earnings as a bonus if somebody joins until Thursday end of the day
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
Hi,
so what is the working procedure to make my Rosetta and WCG cross-project IDs the same?
I registered in WCG with the same e-mail address as in Rosetta (and the same login too), already have been running both rosetta and WCG tasks on the same machine for 48 hours and they are still different.
so what is the working procedure to make my Rosetta and WCG cross-project IDs the same?
I registered in WCG with the same e-mail address as in Rosetta (and the same login too), already have been running both rosetta and WCG tasks on the same machine for 48 hours and they are still different.
Try to detach the WCG project from your boinc UI, the click Update on RAH, then reattach WCG, then click Update.
I went in to a few of my old accounts, and verified that the old ones where my email matches did update to my CPID, so this process should work for everyone.
Ensure the case is correct. You dont have any strange symbols in your e-mail address I assume.
Yeah, this procedure has helped, I've got finally the same ID! Thanks.
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
Hi,
so what is the working procedure to make my Rosetta and WCG cross-project IDs the same?
I registered in WCG with the same e-mail address as in Rosetta (and the same login too), already have been running both rosetta and WCG tasks on the same machine for 48 hours and they are still different.
so what is the working procedure to make my Rosetta and WCG cross-project IDs the same?
I registered in WCG with the same e-mail address as in Rosetta (and the same login too), already have been running both rosetta and WCG tasks on the same machine for 48 hours and they are still different.
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
I noticed that I have tasks on my home ryzen and my 10 watt cube PC. I wonder if the storm has passed with Rosetta or if some users still cant get tasks.
We are not completely without tasks, you can get some here and there. But you need to be lucky to get some.
Unless you see > 0 unsent tasks here (in Rosetta and Rosetta Mini projects), the storm is not over:
https://boinc.bakerlab.org/rosetta/server_status.php
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
BTW, thread discussing the lack of Rosetta tasks already taking 2 days: https://boinc.bakerlab.org/rosetta/forum_thread.php?id=12499
So far no statement from the Rosetta staff.
So far no statement from the Rosetta staff.
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
The only evidence we have is Rosetta ran out of tasks Once so far, on a weekend, and had the tasks queue back up within 12 hours on Monday.
Rob, I'm afraid that this hasn't been resolved yet. We are still out of tasks. There was a bunch of tasks available ~20 hours ago, there is few of them here and there, but you need to be extremely lucky to get them. I guess those are just orphaned tasks that slowly time out. Most of my computers still cannot get new tasks.
I guess we might be simply hitting the hardware limitation of rosetta? It seems we are now able to process much more than they can produce in time?
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
I forgot to post the link: http://boinc.berkeley.edu/wiki/How_BOINC_works
But what does it matter if it is sent out again then.
Well, even if each task is sent to multiple computers (2?), in case we have limited amount of tasks (as it seems to be happening now), machines that pull a lot of tasks and then vanish after processing few of them are blocking the rest of the reasearchers until the tasks time out.
I'm currently processing tasks that time out on 4th April, so the timeout seems to be about 1 week?
Re: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS
Finally what's the required utxoamount parameter in conf file? Can we leave empty and it takes all it can take? I would find it burdensome if we needed to change it everytime oir mag/rac changes.
If you leave it empty it uses 50,001 right now.
But I reccon you could overshoot it after the April 1st poll completes, IE by then you will know your average daily RAC, maybe overshoot it by 40% and keep an eye on it. But yes, this particular version of the client requires you to set it if 50,001 doesnt work.
We can look into better automation for our June mandatory release. I'm trying to shoot for quarterly mandatories to keep everyone happy.
What about an option to use 100% of the wallet amount to stake? I guess that would not require a mandatory?
If we switch over to 20 BBP per RAC (http://forum.biblepay.org/index.php?topic=127.0) I guess many miners will have less BBP than they would need for being at 100% UTXO, and will want to use their daily rewards to increase their staking amount. That means updating the config file every day.
Since 50,001 would not make much sense going forward (it would be enough only for RAC <= 2500, which is about one or two average PCs), perhaps using all of the wallet amount could be the new default?