|
If someone wants to alpha test purchasing a Subway gift card, please go to pool.biblepay.org | Help | Store | Buy.
The store is temporarily under 'help' until the buy process is debugged.
Note: We only support US orders at this time.
EDIT: Remember, you can now deposit funds into the pool by clicking Account | Deposit.
|
|
|
|
|
So our WalMart integration is about 90% complete.
We should be able to offer Subway gift cards within a day or so.
Ill invite some pool users who may be interested in Alpha testing ASAP.
You will need about $15 balance in the pool to buy a subway gift card, this should be very cool. I'm excited! BiblePay will have two use cases: Foot long subs And renting IPFS document storage!
|
|
|
|
any big exchange?
We are saving up for Cryptopia, they love us. See pool.biblepay.org New Exchange Fund. I don't think Cryptopia can come out and play any more... https://www.cryptopia.co.nz/It should come back... if not we have the funds set aside for another opportunity. On this kind of thing, we don't pay in BTC until we have it all saved and a firm commitment for integration to start. Therefore it wouldn't have been happening til ~ Christmas 2019, so we still have our money. I will add Cryptopia to my prayer list. I pray they were not actually hacked and they are not persecuted. |
|
|
|
I received a very nice blessing today from Cameroon One. Somehow during our initial meetup with Cameroon, we didn't receive Clodeth into our system. It is my great pleasure to inform everyone that we have sponsored a child born without arms, Clodeth, last May with Cameroon One and she is still on-board with us. Somehow she was never entered but she is now with us. God Bless Clodeth!  |
|
|
|
any big exchange?
We are saving up for Cryptopia, they love us. See pool.biblepay.org New Exchange Fund. |
|
|
|
olalolao masternode=1 
Rob 0.5 day is alive? Its out in the network, but since we didn't have a mandatory upgrade for the sancs, they are not all enforcing the setting (yet). |
|
|
|
Favor request: If anyone ever notices the POW leaderboard in pool.biblepay.org with less than 10 rows, please send me an e-mail : rob@biblepay.org so I can jump in and debug it. |
|
|
|
Hi biblepay team, The new masternode setup not sync block. Please advise. {
"version": 1010802,
"protocolversion": 70717,
"walletversion": 61000,
"wallet_fullversion": "1.1.8.2",
"balance": 0.00000000,
"privatesend_balance": 0.00000000,
"blocks": 0,
"timeoffset": 0,
"connections": 0,
"proxy": "",
"difficulty": 4.656542373906925e-10,
"testnet": false,
"keypoololdest": 1548091467,
"keypoolsize": 1001,
"paytxfee": 0.00000000,
"relayfee": 0.00010000,
"errors": ""
Hello, I have the same issue with 1.1.8.2 and also with the previous version already compiled, on linux (2 VM on two different PC and also in VPS Vultr). Windows is fine. Addnode add and retry does not help. Here is part of my debug.log, stuck there after start and left to run 40 min. Another coin on this VM could connect readily to the network. I tried to change (p2p) port to some number in the 8000 but it did not helps. RPCport return an error but I can connect to it with biblepay-cli. I started biblepayd at 20:54 and stopped it with biblepay-cli stop at 21:37. My clock is correctly adjusted with https://time.is/ at 0.9 sec GMT+1. 2019-01-22 20:54:38 Biblepay Core version 1.1.8.2 (2019-01-14 16:31:57 -0600)
2019-01-22 20:54:38 InitParameterInteraction: parameter interaction: -externalip set -> setting -discover=0
2019-01-22 20:54:38 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2019-01-22 20:54:38 ***************************************** BIBLEPAY ***************************************************
2019-01-22 20:54:38 ProdMode: Prod 1.000000Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
2019-01-22 20:54:38 BiblePayVersion 1.1.8.2 (2019-01-14 16:31:57 -0600)
2019-01-22 20:54:38 Using OpenSSL version OpenSSL 1.1.0g 2 Nov 2017
2019-01-22 20:54:38 Default data directory /home/yo/.biblepaycore
2019-01-22 20:54:38 Using data directory /home/yo/.biblepaycore
2019-01-22 20:54:38 Using config file /home/yo/.biblepaycore/biblepay.conf
2019-01-22 20:54:38 Using at most 256 connections (1024 file descriptors available)
2019-01-22 20:54:38 Using 16 threads for script verification
2019-01-22 20:54:38 scheduler thread start
2019-01-22 20:54:38 Binding RPC on address 0.0.0.0 port 9998 failed.
2019-01-22 20:54:38 HTTP: creating work queue of depth 16
2019-01-22 20:54:38 Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcuser for rpcauth auth generation.
2019-01-22 20:54:38 HTTP: starting 4 worker threads
2019-01-22 20:54:38 Creating backup of /home/yo/.biblepaycore/wallet.dat -> /home/yo/.biblepaycore/backups/wallet.dat.2019-01-22-20-54
2019-01-22 20:54:38 Using wallet wallet.dat
2019-01-22 20:54:38 init message: Verifying wallet...
2019-01-22 20:54:38 CDBEnv::Open: LogDir=/home/yo/.biblepaycore/database ErrorFile=/home/yo/.biblepaycore/db.log
2019-01-22 20:54:38 Bound to [::]:40000
2019-01-22 20:54:38 Bound to 0.0.0.0:40000
2019-01-22 20:54:38 init message: Loading KJV Bible...
2019-01-22 20:54:38 s1 e5aff8cff54256fe8ee133467eed3af0, s2 e409eb2ba6eb6801f52763ae370c350e
2019-01-22 20:54:38 Cache configuration:
2019-01-22 20:54:38 * Using 12.5MiB for block index database
2019-01-22 20:54:38 * Using 29.9MiB for chain state database
2019-01-22 20:54:38 * Using 57.6MiB for in-memory UTXO set
2019-01-22 20:54:38 init message: Loading block index...
2019-01-22 20:54:38 Opening LevelDB in /home/yo/.biblepaycore/blocks/index
2019-01-22 20:54:38 Opened LevelDB successfully
2019-01-22 20:54:38 Using obfuscation key for /home/yo/.biblepaycore/blocks/index: 0000000000000000
2019-01-22 20:54:38 Opening LevelDB in /home/yo/.biblepaycore/chainstate
2019-01-22 20:54:38 Opened LevelDB successfully
2019-01-22 20:54:38 Using obfuscation key for /home/yo/.biblepaycore/chainstate: 56fa850f323ca887
2019-01-22 20:54:38 LoadBlockIndexGuts 1548190478.000000 Last Checkpoint Height 63000 Finished 1548190478.000000 LoadBlockIndexDB: last block file = 0
2019-01-22 20:54:38 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=1, size=300, heights=0...0, time=2017-06-01...2017-06-01)
2019-01-22 20:54:38 Checking all blk files are present...
2019-01-22 20:54:38 LoadBlockIndexDB: transaction index enabled
2019-01-22 20:54:38 LoadBlockIndexDB: address index disabled
2019-01-22 20:54:38 LoadBlockIndexDB: timestamp index disabled
2019-01-22 20:54:38 LoadBlockIndexDB: spent index disabled
2019-01-22 20:54:38 Finished Loading Block Index 1548190478.000000 LoadBlockIndexDB: hashBestChain=3b4431310395638c0ed65b40ede4b110d8da70fcc0c2ed4a729fb8e4d78b4452 height=0 date=2017-06-01 20:10:44 progress=0.000001
2019-01-22 20:54:38 init message: Verifying blocks...
2019-01-22 20:54:38 block index 17ms
2019-01-22 20:54:38 init message: Loading wallet...
2019-01-22 20:54:38 nKeysLeftSinceAutoBackup: 1002
2019-01-22 20:54:38 nFileVersion = 1010802
2019-01-22 20:54:38 Keys: 1003 plaintext, 0 encrypted, 1003 w/ metadata, 1003 total
2019-01-22 20:54:38 wallet 28ms
2019-01-22 20:54:38 init message: Activating best chain...
2019-01-22 20:54:38 Using masternode config file /home/yo/.biblepaycore/masternode.conf
2019-01-22 20:54:38 fLiteMode 0
2019-01-22 20:54:38 fRetirementAccountsEnabled 0
2019-01-22 20:54:38 nInstantSendDepth 5
2019-01-22 20:54:38 PrivateSend rounds 2
2019-01-22 20:54:38 PrivateSend amount 25000
2019-01-22 20:54:38 init message: Loading masternode cache...
2019-01-22 20:54:38 Reading info from mncache.dat...
2019-01-22 20:54:38 Loaded info from mncache.dat 0ms
2019-01-22 20:54:38 Masternodes: 0, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 0, nDsqCount: 0
2019-01-22 20:54:38 Masternodes: 0, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 0, nDsqCount: 0
2019-01-22 20:54:38 init message: Masternode cache is empty, skipping payments and governance cache...
2019-01-22 20:54:38 init message: Loading fulfilled requests cache...
2019-01-22 20:54:38 Reading info from netfulfilled.dat...
2019-01-22 20:54:38 Loaded info from netfulfilled.dat 0ms
2019-01-22 20:54:38 Nodes with fulfilled requests: 0
2019-01-22 20:54:38 Nodes with fulfilled requests: 0
2019-01-22 20:54:38 init message: Memorizing Prayers...
2019-01-22 20:54:38 mapBlockIndex.size() = 2
2019-01-22 20:54:38 chainActive.Height() = 0
2019-01-22 20:54:38 setKeyPool.size() = 1002
2019-01-22 20:54:38 mapWallet.size() = 0
2019-01-22 20:54:38 mapAddressBook.size() = 1
2019-01-22 20:54:38 init message: Loading addresses...
2019-01-22 20:54:38 torcontrol thread start
2019-01-22 20:54:38 ERROR: Read: Failed to open file /home/yo/.biblepaycore/banlist.dat
2019-01-22 20:54:38 Invalid or missing banlist.dat; recreating
2019-01-22 20:54:38 Loaded 1 addresses from peers.dat 0ms
2019-01-22 20:54:38 dnsseed thread start
2019-01-22 20:54:38 net thread start
2019-01-22 20:54:38 addcon thread start
2019-01-22 20:54:38 mnbcon thread start
2019-01-22 20:54:38 opencon thread start
2019-01-22 20:54:38 msghand thread start
2019-01-22 20:54:38 Starting Thread #0.000000 with Bible #0.000000 BibleMiner -- started thread 0.000000
2019-01-22 20:54:38 MinerSleep 325.000000
2019-01-22 20:54:38 ** Started 1.000000 BibleMiner threads. **
2019-01-22 20:54:38 Genesis Hash 3b4431310395638c0ed65b40ede4b110d8da70fcc0c2ed4a729fb8e4d78b4452
2019-01-22 20:54:38 init message: Done loading
2019-01-22 20:54:49 Loading addresses from DNS seeds (could take a while)
2019-01-22 20:54:49 1 addresses found from DNS seeds
2019-01-22 20:54:49 dnsseed thread exit
2019-01-22 21:00:38 CheckingHealth... LastBlockAge 51842994, LastAcceptBlockAge 1548190838, Diff 0.000000 ...
HealthCheckup::Attempting Recovery method 1: Reprocessing 24 hours of blocks... Please wait...
2019-01-22 21:00:38 DisconnectBlocks -- Got command to replay 205 blocks
2019-01-22 21:00:38 ERROR: DisconnectBlock(): no undo data available
2019-01-22 21:00:38 ERROR: DisconnectTip(): DisconnectBlock 3b4431310395638c0ed65b40ede4b110d8da70fcc0c2ed4a729fb8e4d78b4452 failed
2019-01-22 21:37:47 tor: Thread interrupt
2019-01-22 21:37:47 torcontrol thread exit
2019-01-22 21:37:47 scheduler thread interrupt
2019-01-22 21:37:47 addcon thread interrupt
2019-01-22 21:37:47 mnbcon thread interrupt
2019-01-22 21:37:47 msghand thread interrupt
2019-01-22 21:37:47 net thread interrupt
2019-01-22 21:37:48 opencon thread interrupt
2019-01-22 21:37:48 PrepareShutdown: Prepare Shutdown In progress...
2019-01-22 21:37:48 Shutdown - renaming thread ...
2019-01-22 21:37:48 Stopped miner... stopping node
2019-01-22 21:37:48 StopNode()
2019-01-22 21:37:48
BiblepayMiner -- terminated
2019-01-22 21:37:48 stopped node...
2019-01-22 21:37:48 Verifying mncache.dat format...
2019-01-22 21:37:48 Loaded info from mncache.dat 0ms
2019-01-22 21:37:48 Masternodes: 0, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 0, nDsqCount: 0
2019-01-22 21:37:48 Writting info to mncache.dat...
2019-01-22 21:37:48 Written info to mncache.dat 0ms
2019-01-22 21:37:48 Masternodes: 0, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 0, nDsqCount: 0
2019-01-22 21:37:48 mncache.dat dump finished 0ms
2019-01-22 21:37:48 Verifying mnpayments.dat format...
2019-01-22 21:37:48 Loaded info from mnpayments.dat 0ms
2019-01-22 21:37:48 Votes: 0, Blocks: 0
2019-01-22 21:37:48 Writting info to mnpayments.dat...
2019-01-22 21:37:48 Written info to mnpayments.dat 0ms
2019-01-22 21:37:48 Votes: 0, Blocks: 0
2019-01-22 21:37:48 mnpayments.dat dump finished 0ms
2019-01-22 21:37:48 Verifying governance.dat format...
2019-01-22 21:37:48 Loaded info from governance.dat 0ms
2019-01-22 21:37:48 Governance Objects: 0 (Proposals: 0, Triggers: 0, Watchdogs: 0/0, Other: 0; Seen: 0), Votes: 0
2019-01-22 21:37:48 Writting info to governance.dat...
2019-01-22 21:37:48 Written info to governance.dat 0ms
2019-01-22 21:37:48 Governance Objects: 0 (Proposals: 0, Triggers: 0, Watchdogs: 0/0, Other: 0; Seen: 0), Votes: 0
2019-01-22 21:37:48 governance.dat dump finished 0ms
2019-01-22 21:37:48 Verifying netfulfilled.dat format...
2019-01-22 21:37:48 Loaded info from netfulfilled.dat 0ms
2019-01-22 21:37:48 Nodes with fulfilled requests: 0
2019-01-22 21:37:48 Writting info to netfulfilled.dat...
2019-01-22 21:37:48 Written info to netfulfilled.dat 0ms
2019-01-22 21:37:48 Nodes with fulfilled requests: 0
2019-01-22 21:37:48 netfulfilled.dat dump finished 1ms
2019-01-22 21:37:48 dumped database files ...
2019-01-22 21:37:48 Shutdown: done the biblepay.conf is as follows: rpcuser=user
rpcpassword=secret
rpcport=9998
rpcallowip=127.0.0.1
logtimestamps=1
daemon=1
server=1
listen=1
masternode=0
externalip=xx.yy.zz.ww
maxconnections=256
masternodeprivkey=************************************************ Thanks! Thanks, I think in your case its definitely not the clock then. (On a side note, just to see if I introduced something, I compiled and synced 1183 from block 0 and it synced, but its not quite ready to check in) so could we please try a couple more things first. Please : rm chainstate -r rm blocks -r rm gov*.dat rm mnp*.dat rm mnc*.dat Start wallet addnode 45.76.153.178 onetry (after starting) Let us know if it syncs to the top. If not I will prepare the next release. |
|
|
|
Crashed means the program ended unexpectedly. But - we have no reports of any crashes. Please upgrade and try again. |
|
|
|
Hi biblepay team, The new masternode setup not sync block. Please advise. {
"version": 1010802,
"protocolversion": 70717,
"walletversion": 61000,
"wallet_fullversion": "1.1.8.2",
"balance": 0.00000000,
"privatesend_balance": 0.00000000,
"blocks": 0,
"timeoffset": 0,
"connections": 0,
"proxy": "",
"difficulty": 4.656542373906925e-10,
"testnet": false,
"keypoololdest": 1548091467,
"keypoolsize": 1001,
"paytxfee": 0.00000000,
"relayfee": 0.00010000,
"errors": ""
Most of the time when we have 0 connections, its due to the clock. Please ensure your system time is correct within 10 seconds and also the timezone is correct, then rm banlist.dat and reboot the wallet. Hi i rebuild the VPS then complier again but it got same issue. Not sync.... ./biblepay-cli getblockchaininfo
{
"chain": "main",
"blocks": 0,
"headers": 0,
"bestblockhash": "3b4431310395638c0ed65b40ede4b110d8da70fcc0c2ed4a729fb8e4d78b4452",
"difficulty": 0,
"mediantime": 1496347844,
"verificationprogress": 6.841270015289746e-07,
"chainwork": "0000000000000000000000000000000000000000000000000000000000000002",
"pruned": false,
"softforks": [
{
"id": "bip34",
"version": 2,
"enforce": {
"status": false,
"found": 0,
"required": 750,
"window": 1000
},
"reject": {
"status": false,
"found": 0,
"required": 950,
"window": 1000
}
},
{
"id": "bip66",
"version": 3,
"enforce": {
"status": false,
"found": 0,
"required": 750,
"window": 1000
},
"reject": {
"status": false,
"found": 0,
"required": 950,
"window": 1000
}
},
{
"id": "bip65",
"version": 4,
"enforce": {
"status": false,
"found": 0,
"required": 750,
"window": 1000
},
"reject": {
"status": false,
"found": 0,
"required": 950,
"window": 1000
}
}
],
"bip9_softforks": [
{
"id": "csv",
"status": "defined"
}
]
}
I see statistics but nothing about the system time or timezone. Please read the debug.log after a fresh restart and post with |
|
|
|
whats this again?my podcupdates shows bullshits  is this correct setup? addnode=node.biblepay.org gen=1 genproclimit=4 minersleep=0 poolport=80 pool=https://pool.biblepay.org workerid=lesbiangay utxooverride=-1 Looking at the code it looks like when you use utxooverride=-1, you cannot send manual podc updates (which is very suprising). I just fixed this in the next version so you will be able to send force=true - It wont be out until tomorrow as we are building something for testnet today. For now, just remove the utxooverride, send the podcupdate manually then put it back in. I checked in 1183b which fixes this; it may be deployed for windows by tonight; in the mean time you can self compile if you want. |
|
|
|
Hi biblepay team, The new masternode setup not sync block. Please advise. {
"version": 1010802,
"protocolversion": 70717,
"walletversion": 61000,
"wallet_fullversion": "1.1.8.2",
"balance": 0.00000000,
"privatesend_balance": 0.00000000,
"blocks": 0,
"timeoffset": 0,
"connections": 0,
"proxy": "",
"difficulty": 4.656542373906925e-10,
"testnet": false,
"keypoololdest": 1548091467,
"keypoolsize": 1001,
"paytxfee": 0.00000000,
"relayfee": 0.00010000,
"errors": ""
Most of the time when we have 0 connections, its due to the clock. Please ensure your system time is correct within 10 seconds and also the timezone is correct, then rm banlist.dat and reboot the wallet. |
|
|
|
|
** POOL LETTER WRITING BOUNTY INCREASED **
We need letter writers in the pool; Bounty increased to 5962.
Also please vote on the outbound letters; bsnyde just wrote 5.
|
|
|
|
whats this again?my podcupdates shows bullshits is this correct setup? addnode=node.biblepay.org gen=1 genproclimit=4 minersleep=0 poolport=80 pool=https://pool.biblepay.org workerid=lesbiangay utxooverride=-1 Looking at the code it looks like when you use utxooverride=-1, you cannot send manual podc updates (which is very suprising). I just fixed this in the next version so you will be able to send force=true - It wont be out until tomorrow as we are building something for testnet today. For now, just remove the utxooverride, send the podcupdate manually then put it back in. |
|
|
|
The absolute highest setting would have to be 19 hours (IE 24 minus 4 minus 1 hour for padding), but that would be Very dangerous ; 12 hours is already imo dangerous  . Thanks for all your hard work. What if PoDC address had multiple tx? You just sweep to PoDC address but to new TX if cpid needs more stake. This way you know coin age of each TX. You calculate all the eligible (eligible = min coin age >= 1.5 day?) input & output for that address from block 1 and you know what their balance is. You'd only have to calculate the one PoDC address per miner, so it would hopefully be manageable by the sanctuaries? There is a function in the wallet (its something to the effect of GetAvgCoinAge) that uses the average age of the transaction, we use that in the calculation, so in PODC, its OK if they use multiple inputs in a PODC update - but in POG its not allowed - (POG requires one coin only to be used, so people cant game the average). I also wanted to mention on the theory behind 12 hours: If one of the nefarious users were to receive lent coins and spend it on a UTXO, when they send the coins back to the owner, remember the coins have lost the age - so please take that into account - that is part of the theory behind the 12 hours - 12 makes it very hard to have enough coin age even in the wallet to make a daily podc update let alone share it and receive it back and successfully make another one in the same day. |
|
|
|
I tried to cast my vote in the Emergency Election but all I get is:
"Voting Failed! Check that sanctuaries are registered in masternore.conf?"
Anyone know what I need to do to vote???
You need at least 1 sanctuary. If you have one, just put gobject vote-many 2a5c0805b0a026dd79898d50a27c49c4c2923b767c3735180e43e1dde9914bd2 funding yes into the debug console of your controller wallet. This should do the trick. (Don't make the mistake of checking with "gobject list" though; for BBP this is an endless list taking several minutes to load).  But also you have to ensure your sanc is registered with your home wallet. Is the sanc in your sanc list? And enabled? If not you have to enter the sanc in your masternode.conf file using the IP, name, private key and txid of the Sanc collateral. |
|
|
|
voted yes...... btw when somebody got 2M and have RAC 500 000, he needs staking 10M,right.But exists scam here is steps of example i have power 500 000 RAC x 20= 10 000 000 BBP for 100% rewards ill make 5 wallets (accounts) 5x100 000 RAC (example), every wallet needs for 100% staking 2M 2M 2M 2M 2M = 10M .. i can moving my 2M to 1.wallet,then wait for podcupdate,then transfer to 2nd wallet=wait for podcupdate and moving my 2M to all wallets for every day----etc 3 4 5 wallet, podcupdate manually every day.... this is legal SCAM and beating all of us Thanks, well just to let you know more of the details, when you reported this to TheSnat a while back he reported it to me, and I did add a feature into the wallet that requires our UTXO's to have a certain amount of coin-age (to mitigate this vector) and its been released (about 10 versions back) so its partially in our network. The issue is, it would require all of the sancs to have a mandatory upgrade to enforce this setting. We've been waiting on the sidelines for our next mandatory to enable the spork. I went ahead and enabled the spork to require a .50 day coin-age on UTXO's; however I'm not going to ask all the sancs to upgrade today as an emergency since we are so close to having a mandatory anyway. In the mean time lets vote on the poll and that should mitigate most of the problem (as TheSnat has observed none of the nefarious UTXO activity has occurred in Team Biblepay). On a side note everyone, I believe the mandatory is coming in approx. 14 days. Ill update more ASAP. 1/2 day coin-age does not sound enough to beat the possible scam - 24 / 48 / 72 hours better Regards PM I believe .5 is as high as we can go. No, I think it should resolve most of the problem, because if the coins were just transferred after being spent on a UTXO, they would not be able to create another UTXO for 12 hours. The Sanctuaries cant induct information that fast; they make agreements on the oldest UTXO data that they can all agree on (so going higher is risking that No one would be paid, IE lots of missing payments per day). Anyway the other thing you have to consider is most of the high UTXO requirements is everything they have; they are staking their entire balance to make the utxo. If we went longer, we would risk people not being able to come up with the daily stake. These contracts are once every 24 hours, and it takes up to 4 hours just to stake a utxo. The absolute highest setting would have to be 19 hours (IE 24 minus 4 minus 1 hour for padding), but that would be Very dangerous ; 12 hours is already imo dangerous . |
|
|
|
Just to let everyone know we have been working on pool.biblepay.org to try to address any concerns and make it nicer. Almost all of the issues are now resolved that were reported here: https://github.com/biblepay/BiblePayPool/issues(IE 90% of the tickets have been worked and deployed to prod). Now you can see the proposals in Proposals | List in either theme. The f5 key problem and backspace issue has been resolved. The smaller issues were resolved and addressed. (We are still working on the walmart integration project and its going very well). I think one thing that we might implement in the pool next is a Gantt chart for Current Projects. This will be instrumental in allowing the average user understand exactly what we are doing between roadmap targets. Id like to make it so the roadmap has an accurate set of high level milestones, but you can come to the pool and click on the Gantt to see the lower level things we are working on between mandatory releases. This might reduce the stress level on my part, because I feel people on the other end of the network do not understand how many small tasks we are working to make a bigger task a reality for everyone. |
|
|
|
voted yes...... btw when somebody got 2M and have RAC 500 000, he needs staking 10M,right.But exists scam here is steps of example i have power 500 000 RAC x 20= 10 000 000 BBP for 100% rewards ill make 5 wallets (accounts) 5x100 000 RAC (example), every wallet needs for 100% staking 2M 2M 2M 2M 2M = 10M .. i can moving my 2M to 1.wallet,then wait for podcupdate,then transfer to 2nd wallet=wait for podcupdate and moving my 2M to all wallets for every day----etc 3 4 5 wallet, podcupdate manually every day.... this is legal SCAM and beating all of us Thanks, well just to let you know more of the details, when you reported this to TheSnat a while back he reported it to me, and I did add a feature into the wallet that requires our UTXO's to have a certain amount of coin-age (to mitigate this vector) and its been released (about 10 versions back) so its partially in our network. The issue is, it would require all of the sancs to have a mandatory upgrade to enforce this setting. We've been waiting on the sidelines for our next mandatory to enable the spork. I went ahead and enabled the spork to require a .50 day coin-age on UTXO's; however I'm not going to ask all the sancs to upgrade today as an emergency since we are so close to having a mandatory anyway. In the mean time lets vote on the poll and that should mitigate most of the problem (as TheSnat has observed none of the nefarious UTXO activity has occurred in Team Biblepay). On a side note everyone, I believe the mandatory is coming in approx. 14 days. Ill update more ASAP. |
|
|
|
|
Show Posts
