Just to give you a little more insight in the podc auto-unlock and how it works for heat miners:
When you boot biblepay with an encrypted wallet, a pop-up modal dialog appears and asks for optional password. We store this in an encrypted-memory-protected securestring (its a c++ object designed to prevent hackers from reading that area of memory on a live executable).
Then when your heat miner starts - we check to see if we have the populated string in memory (only if your wallet is encrypted and locked), and when we need to Sign a CPID we do this ONCE while creating a new block:
- We unlock the wallet
- We sign the cpid
- We create the block
- We lock the wallet
This happens every time the Transaction list in the memory pool changes, so yes, it could happen 10 times per second, (unlock - sign - lock) but the overhead is not that bad considering that our miners run pretty slow now that blocks have to be signed.
Thanks for the insight, that sounds quite reasonable so far. However, the pop-up dialog only exists on the GUI version, not on the biblepayd version (linux terminal). I remember there was a special exec command in plans for transferring this pop-up function to the headless wallets in linux, but did this ever make its way into the prod versions? If so, could you please remind me of what this command looked like? :-D |
|
|
|
my rac with 3 machines is currently ~8000 at 20 bbp/rac that is 160k this means I will get less than 10% reward and will never be able to catch up.. .
I do not have the resources to buy 160k bbp( or any crypto really...). Currently i have 15k from mining
I like the project, and whats behind it. I see consolidation of money in the sanctuaries, most of the rewards from mining already go to others before the "miners" get a cut.
I may have to stop or greatly cut back my mining activities if the 20bbp/rac goes through.
Well, I was a big fan of the BBP/RAC staking requirement instead of BBP/MAG, but 20 definitely seems too high (50k/mag on the other hand is way too low...). Before Rosetta crumbled down I managed to achieve a RAC of approx. 50k. That means I would need a whopping million BBP to maintain my utxoweight.  Even if I somehow managed to (someday) collect this amount of BBP, I would feel VERY uncomfortable to leave those coins in a hot wallet permanently connecting to the internet. Even worse, I need this wallet on my tiny ARM machines for "heat mining", where it is permanently unlocked! (I think there was a workaround for linux wallets without GUI to get the "on-demand-unlock", but this never worked for me; maybe I gotta try it once again after Easter Holidays). Will there at least be a workaround, let's say your actual PODC controller wallet doesn't hold all these coins, but transmits a (unique) BBP address that does? what are you talking about? You checking our passwords? Shit secure for BBP then
What are YOU talking about? Calm down and read/think before you write!  |
|
|
|
I think we have to be patient with Rosetta@home. You have to understand that this is a research project, calculating actual scientific jobs. That means that not only do they need many many scientists to create these jobs (i.e. develop a mechanism, create an initial guess structure, create the job-files etc.), but most importantly they need the manpower to evaluate and interpret the results. Otherwise the whole purpose would be lost. Over the last couple of weeks our contribution created a large spike in their network's hashpower (as some of you already mentioned correctly). I know from experience that in the scientific world NOTHING major happens over the course of a couple of days or weeks! Enlarging a certain research project takes at least several weeks, if not months, because this depends largely on the scientific coworkers this project can pay for. I bet all these guys worked overtime the last couple of days, and still couldn't keep up. So maybe it would really be useful to have a backup project (or several ones). That being said it would also surely help if we didn't have guys with huge amounts of small to tiny machines starting several thousand jobs, not being able to finish them, and then blocking them and crippling the whole project.... On another note: since yesterday I cannot withdraw any BBP from the main pool anymore. It sends out the email with the link, but the linked page is just a blank page and nothing happens. Also the balance on the pool account doesn't change, so that's good.  |
|
|
|
at least 30 min stuck on 36079? whats wrong?
Maybe the superblock at 36080 is having some problems? On the main pool all (heat) miners are gone, my windows wallet also doesn't really do anything when set to "setgenerate true 8" (normally this would block the CPU completely). Let's keep calm and let the blockchain do it's thing. |
|
|
|
To help alleviate questions about your next estimated PODC Research payment, you can now paste your CPID in the pool in Account Settings, and the Home page will give you CPID information from the next superblock, such as UTXO weight, Magnitude, Estimated Next Payment, and Task Weight.
Sweet feature!  One question regarding the next superblock: How come the budget suddenly went from 2.7 million to 1.2 million? Of course it has to degrade sometimes, but a sudden decrease by 60% seems a bit harsh. |
|
|
|
The first two things that came into my mind when reading this were:
1. Biblepay is a project with a religious connotation, and I don't know if research groups would want to publicly attach themselves to a project like ours by buying our coins (because I assume they want to keep things like politics and religion separate from their - public - work).
2. Isn't the computational power we give to Rosetta@home really specific, in the sense that we are using algorithms that can't be applied in general computing applications?
1. Ah yes, I know what you mean and I think you're right about that. Paying - even small amounts - of money to a somewhat religious organisation would definitely raise questions and for some might even be impossible. This could indeed be the major problem. 2. I'm not quite sure what you mean by that. I don't think that the Rosetta packages we solve differ in any aspect from any other Rosetta packages being solved. In the end maybe we wouldn't even have to limit ourselves to Rosetta if there are other good projects dedicated to healing etc. |
|
|
|
Hey guys, I just had an idea how to potentially raise the value of BBP. Maybe it's too early or too tricky to implement right now, but here it is: Over the last couple of days our team quickly ploughed through the Rosetta teams and it won't be long until we are the number one team there. Maybe in the not so far future we will even provide the supermajority of the hash power for Rosetta@home. Researchers are used to pay quite a lot of money for computational ressources (I know that because our research group does...). I don't know how it works for the groups using the Rosetta hash power (or BOINC in general), but how about (once we have a majority) we somehow "charge" small sums for our hash power? Here's how this could work: a research team rents (maybe monthly or biannually) a certain, guaranteed amount of computational ressources from rosetta@home. It does so by buying BBP on an exchange and immediately burning those coins. This way we could 1) increase the knowledge about BBP, 2) increase the inherent value of the coin. The best "side effect" would be that every time this happens the funded children will get more (FIAT) money and it should in general be easier for Rob to obtain the dollars necessary for funding (since there will from time to time be larger sums in the bid). I'm not sure if this is even possible to get working, of course the charged sums also should'nt really be high, but this just came to my mind. What do you all think about this? |
|
|
|
Let's look at this a different way. Let's say I go to Prestonwood Baptist church, and I say to people, "Hey why don't ya'll buy some biblepay that I'm mining. It will help support orphans." They might ask,"Are you buying it?" I'd have to say, "No, I'm just mining the pea-wodding out of it. It has a limited supply, but so do the other 1550 and increasing other coins available." They would feel like suckers being taken advantage of.
But! If we have stake based on RAC, and I say to people, "Hey why don't ya'll buy some biblepay that I'm mining. It will help support orphans." And they ask,"Are you buying it?" I have to say, "Yes! For every computer I add that does crunching, I have to either hold or buy biblepay." (With magnitude based staking, the amount I have to stake should decrease as the network grows: MAGSHARE=MAG/USERBASE as user base expands, my share of the MAG becomes smaller.) Then they might say, "Oh, it sounds like a good idea if you are buying and holding right alongside me, even though I'm not that interested in crunching." And I could say, "Yep, go for it!"
Honestly I think either will work, RAC or magnitude. I just like magnitude because it scales with the network size. But either or will do for me. The simplest way I look at is, Do you want a static aggregate stake amount or a growing stake amount? Unless I missed something Total MAG always is 1000. So 1000*50000=50 million. Always, even when supply is 3 Billion. For RAC our current RAC is 1.3M So if we do 20 BBP per RAC that is 26 million lockup. If we have a 10 million RAC with x larger supply that is a 200 million lockup. Woo-hoo! We just engineered ourselves higher prices at a fraction of the cost of a masternode, important especially when masternodes become unaffordable. It is important to consistently seek some way to keep mopping up supply. This coin has a lot of supply on the front end. It will take time for the supply to consolidate. If bitcoin goes way up, we will still have a high effusion rate, people won't be able to afford to buy as much biblepay. If we keep growing the stake amount with the RAC of the network, we do something to give buyers confidence that the coin won't collapse. Buyers are the ones who truly support the orphans, not miners and crunchers. Even when the exchanges are out of maintenance, take some time to read the tape when the prices suddenly go up. Prices go up by surprise because liquidity dried up and people are willing to pay higher and higher prices. They take out those standing limit offers. Then the miners start to come in when they realize prices just got higher. At first, they put out limits on the offer. When those stop getting hit, they start to get desperate and start hitting the bid, soaking up liquidity the other way. Then prices come back down. It would help to have a consistent way to soak up supply and we would engineer higher prices much in the way companies buy back their own stock. Miners are part of the company. Miners accumulating bbp as the network grows helps prices to appreciate. For reference the current masternode lockup has 262 million bpp. And since the start of masternodes we are consistently 20 or more satoshi higher. So more lockup should mean higher prices, and more orphans supported. A win for everybody. Finally someone analyzing this from the economic/trading side. I think you make a very valid and excellent point. On the long run this coin will have to gain value and thus market cap to be taken seriously. This will never happen without generating incentives for people to buy it. The sancs were a very good start to that, as you already explained. Now the goal should definitely be to get miners "hooked" and convince them to hold instead of filling up the ask on every exchange. Requiring staked amounts proportional to the individual's wealth AND the general supply should guarantee this. Edit: Apparently we have a new visitor from china: https://boinc.bakerlab.org/rosetta/show_user.php?userid=1988192. However, he has his computers hidden (he's currently on RAC 19k). As I recall it, there was some kind of rule stating that you have to have your machines visible in order to get paid, is this rule still intact? |
|
|
|
@Lichtsucher: There's something strange happening with the block shares on your pool. For some reason several users (including me) haven't received any piece of the pie for the blocks from march 10, 11. I've run 1 machine on your pool for the last 3 days, but my last transaction is "Share for block 33498" from march 9th (I'm B6fo...). Hi I just looked into the database, the first solutions for your miner are logged for March 10th are found at 10:44 UTC ^^ So you will be part of all blocks after that time. You should see the first shares for the blocks after that very soon Edit: The first block after 10:44 yesterday was found at 12:47 Thx for your quick response. Oh well, I might have taken a break in between and the returned to your pool. However, judging by the statistics table all the blocks from march 10th and 11th have been divided between your address and some others, but e. g. number 2 and 3 in the list (and also others) have their last share at march 9th, so this is what confused me. btw: the next superblock went through, congrats everyone and good job! Now let's see if we can get the dynamic stake requirement in, to give more incentive for holding (or buying) coins rather than mining and dumping them as quickly as possible. |
|
|
|
AND WE NEED NO LINEAR MAG,UTXO system but EXPONENCIAL
MAG1= 1000 BBP
MAG2= 2000 BBP
MAG3= 5000 BBP
MAG4= 9000 BBP
That's actually a pretty good idea. Why not make the required stake amount something like 1000*(mag)² or 1000*(mag)^1.75? This should be as easy to implement as the linear formula. Are there any news concerning the Magnitude of new users not showing up at all? My friend still sits on mag=0 and his BBP address doesn't show up in exec testvote... @Lichtsucher: There's something strange happening with the block shares on your pool. For some reason several users (including me) haven't received any piece of the pie for the blocks from march 10, 11. I've run 1 machine on your pool for the last 3 days, but my last transaction is "Share for block 33498" from march 9th (I'm B6fo...). |
|
|
|
Hello,
I have some PCs running BOINC.
On 1 PC I have installed biblepaycore.
I associated this PC with Roseta.
After 3 days (Thursday till today) I get the following result:
"Command": "getboincinfo",
"CPID": "fa5062d1c29baf2e298b674f40ee59b7",
"Address": My_Walletaddress,
"CPIDS": "fa5062d1c29baf2e298b674f40ee59b7;",
"CPID-Age (hours)": 422416,
"NextSuperblockHeight": 34030,
"NextSuperblockBudget": 2660579,
"fa5062d1c29baf2e298b674f40ee59b7_ADDRESS": My Wallet Address,
"fa5062d1c29baf2e298b674f40ee59b7_RAC": 7972.06,
"fa5062d1c29baf2e298b674f40ee59b7_TEAM": 15044,
"fa5062d1c29baf2e298b674f40ee59b7_TaskWeight": 100,
"fa5062d1c29baf2e298b674f40ee59b7_UTXOWeight": 75,
"Total_RAC": 7972.06,
"Total Payments (One Day)": 0,
"Total Payments (One Week)": 0,
"Total Budget (One Day)": 2660579,
"Total Budget (One Week)": 5321158,
"Superblock Count (One Week)": 2,
"Superblock Hit Count (One Week)": 2,
"Superblock List": "33825,33620",
"Last Superblock Height": 33825,
"Last Superblock Budget": 2660579,
"Last Superblock Payment": 0,
"Magnitude (One-Day)": 0,
"Magnitude (One-Week)": 0
}
and I keep getting negative payment.
Is this OK?
Hi, You probably have negative payments for PODC Update - that is fine. The system is reporting to PODC your data. The payment for rosetta work will come once per day on the superblock - next one is 34030. To see if you are included in the next superblock see this post: https://bitcointalk.org/index.php?topic=2388064.msg31969170#msg31969170If your address is not in the superblock 34030 check it again after this block and I am sure your address will be there. Best regards, Simon Actually a friend of mine has the exact same problem. He's "BOINCing" for several days with a correctly associated CPID, but his magnitude is still zero. His RAC should be somewhere around 2-3k and his PODC update transactions went through without problems. I don't think this is OK, why would it take several days for the magnitude to rise above zero? On another note: are there new findings regarding the utxo being only 75% despite having staked enough BBP? On yet another note: I managed to run my 2 raspberries and 1 Tinker Board on the main pool with an "unlocked" copy of my main wallet. This works so far, the pool already found some nice blocks. However I would appreciate it if there was some different method than to have a permanently unlocked wallet (for security reasons...). |
|
|
|
My magnitude showed as 0 until I received a payment from my first superblock. The BOINC servers export a list of RAC in XML format which I think is grabbed by the sanctuaries and then they vote on paying out those who have a magnitude greater than 0 (i.e. if they've done work). Chances are, if you just started mining in the last 24 hours, the exported file probably did not contain any RAC for you. Give it another 24 hours and I think that the next contract that is voted on should have your wallet address in it.
How to know if you'll be paid in the next superblock.
If you want to confirm that you're in the next superblock, go into the debug console and type "exec testvote." If the sanctuaries don't have the XML from BOINC, nothing will show up. However, if there's an active contract, you'll see the upcoming payments. So for example, this is the copy/paste of the proposed payments from the last superblock at 33825. You'll notice that it contains destination Addresses and the corresponding amounts.
"Addresses": "BSw7JZ9r2cFLgLL7tg6oDKDWicGGGzXf4J|BTjJENmWrQudFHEaqEpFg7ZeCA8HK2HwLW|BSVMHp2GMF2jag6yoididitrwJPoZaP1JK|BSeaxWTddQmLmVCGZBe1TtCeydNygp3yzs|B6n6DympbZKD5GoE6EX4uW8Rvrg6QeP9R4|BP9dc2XhBahAmwRcvtawSdYm7HcGEeWwCm|BSmfm3rQBHAkceJiNxUVDHeuVCgQbTJRx8|BQJeuW9czNp7XJGFE11sDxqifaYsKSHmGa|BSqcLcFLYt3bKvoUaZ5rGURW75xgjJdQoD|BRnJcUe3fCusEX9Q961zpwNJ8jMtRJj4Mx|BSLBCAbR38vwvqBpPn14YCaQSndiKPScjF|BNetxsZfjyNfW73Kvsh5AYLHENpEHcR3qh|BT9R3ELM81r3uS8aMnKzPq2Mm49mDAVx5j|BEaJRPoHfQsu6i8sxAtNApiaYg7eXmBS1M|BLSRauiWZ1oZSXv5Xus9zRJtNQ9vu4Q8ug|BMbjbaYRyiAvcokJ8iZytBt5sF8SRNdmfo|BNSsnhkb4bAmAoYETTByoA6GQCsy4vC5M7|BBkphVpdEdJSvzGEeGRkQr4PkGMKdBmBqm|BKDezDVAwB8vYvaEWcgxLpuuYqbSaDqmVp|BP4mCwRzoLa5rQk4uhL3FKCy3uFWhDrLsN|BHT42KnVpQpAzYgnVJuVEqBz2pp1JfTGYk|BLHdoH8D9EVpTw1Z9DYWSkLmQeLYD1gmQS|BNejpU22sgMv3QcGytVtqeefgaAmTz4JCu|BKae7QM69ATZYkhtkDewLmuJqt94zFj3Lg|BJYgcpTtZvmNYWFkjMzopCBjXMdT4WqgYJ|BQxWRv1inJ4RuNbDWthopNmq1UKptkFcW3|BLUBwujSx8wZHbuEgWZMrqSENecNVjyhz7|BRAFeGxh8NWZrCVzKoTyqvNLxDGxoZ7JzG|BQ4EMSriFXYt4pD3jxD2FiM8tL7nshSUkB|BANBGPPCg4ceXjTkACsxoZqQMKggeTrgeE|BPmMSUh9ZhGpzA2aMWJQmfE498NLxodC4r|BPac8R98z8gxSTZBLU9JzSVYDtWvQQJjPH|BTcGHuJxTBpAAhJLiE4aimosFVyqzmU1ar|BRoSYvPVkEDaFxZg25xCmcnqy9VvqDERtU|BJ9tBR7QdNuxNxy6mpMh8Uggb4UWT7C684|BLznh3qPXHpwPwCybgWHVYuQde9E9o92eq|BGD8b68UergXPdqeR4qRgYZV8r6FWDvTrZ|BT7dgEyWXpZtEnAJkQRF7sNJ6CxYM6dEzn|BRuq4ADYxzyxeAVdvQzRqLqDg4tMQfBCLn|BQmqNxXhEJ9rWGo4isynCpyNFHdKBL2Bzu|BLFtzp4Di5WebqaAyY97PMkgYLV5JxtQ2Q",
"Amounts": "108787.27|464714.33|30709.52|628853.25|273165.70|13625.02|176779.32|37069.64|81510.62|40396.06|2341.80|33264.21|8435.80|337458.76|14716.09|90691.54|42152.41|43642.64|6253.67|745.12|13598.41|638.67|59423.19|984.62|78743.04|239.50|25174.35|5801.28|878.18|53.22|558.84|904.79|15860.38|106.45|186.28|15487.82|266.11|1037.84|558.84|4444.10|319.34",
Copy and paste this into Excel with addresses on the first row, and then amounts on the second row. Then use Text to Columns under the Data tab and choose delimit by the "|" character. This will separate all of the addresses and place the corresponding payment into the row below. Then do a Find on your BBP address linked to your CPID and you will see exactly what you will be paid in the upcoming superblock in the second row below your address (if your RAC made it into the file the sanctuaries are voting on). If you don't find your address, it means you're not scheduled to be paid in the superblock. Hopefully that helps. Perhaps there's a more elegant way to do this, but that's all I know how to do at the moment.
Hopefully that helps
Man, that's awesome, thanks alot. Judging by that it seems I received the full amount from the last superblock (with utxo 100%), but my NEXT payment will be only at 75%, although I didn't change anything... |
|
|
|
So the next superblock went through, which is nice. However, I just realized that my stake amount is bugged. I did not change anything since yesterday, but getboincinfo now somehow shows "UTXOWeight 75" (despite utxoamount=50001). Does that mean I lost 25% of the PODC payout over that bug?  How can I fix it? My balance is definitely sufficient, so this cannot be the problem. Btw: I really like your planned update on making the staked amount proportional to the RAC, this sounds just like the logical thing to do. I don't have an account on the other forums, but please add 1 vote from me for the 10k BBP/mag variant. Edit: I also realized: in the controller wallet there are different transaction types for the podc update: one is called "Type: PODC Update" and it is outgoing to the address "PODC update" and the other one is "Type: Payment to yourself". When I do "exec podcupdate true" it generates the second type of transaction instead of the "PODC update" transaction. Is this how it should perform? |
|
|
|
Hi anyone willing to send a few bbp my way as I can’t start mining without associating my cpid
My wallet address is BJSBdopV39xMtHJvYgzMuCPrWN2D79gn3D
Ps Rob this is very frustrating for new miners to get going, as they will not yet have any coins in their wallet.
Thanks
I'm currently not on a computer with a BBP wallet, but I sent you 1BBP via the Faucet. I think this should be enough to pay for the association burn tx. That doesn't look like a botnet to me, more like a person with his own server room. |
|
|
|
WOW, congrats everyone, that block performed smooth as silk. One (not really serious) question though: was the payment supposed to be THAT big? Togoshi should have received something around 700k BBP with that. I wanted to - just for fun - keep my Rapsberry Pi(s) pool mining on the main pool. But I just realized that this is not possible right now, because I would need to either get an extra CPID for every device or copy my wallet.dat to those machines, right? That's a bit of a shame, since those raspis are now useless for BBP. (For whatever reason Rosetta@home only has packages for ARM on Android, not on Linux...). If you cant get rosetta tasks to run on them, you can copy the wallet.dat with the associated CPID over to the pi's and heat mine against the pool. Yes, the payment looks large but its based on 205 blocks of low difficulty (IE 15000 per block) * the DC budget percentage. Well, I tried exactly that, but it didn't work. I still have the pool error "Failed to sign CPID signature (Address does not refer to key)?; Failed to sign CPID signature (Address does not refer to key)?; " and none of the PIs shows up in my leaderboard. Do I have to perform something like podcupdate on those machines also? Or do they need an unlocked wallet as well? This would be my least favourite option... btw: I'm really glad we are helping with performing useful computations now. I've been involved in Folding@Home for years (unfortunately without using FLDC or CURE...) and I think this is the perfect combination of maintaining a crypto currency while not purely generating heat. On this note: have you made some predictions whether the huge downsizing of hash power on the POBH network will impact the performance of transactions etc.? This would be quite interesting to see, since once we are growing and the number of tx/sec grows, the network will have to have some serious computational power behind it. Since this is now not adequately rewarded anymore, in the future we might have to give some new incentive for people directing their hash power towards the network. |
|
|
|
WOW, congrats everyone, that block performed smooth as silk. One (not really serious) question though: was the payment supposed to be THAT big? Togoshi should have received something around 700k BBP with that. I wanted to - just for fun - keep my Rapsberry Pi(s) pool mining on the main pool. But I just realized that this is not possible right now, because I would need to either get an extra CPID for every device or copy my wallet.dat to those machines, right? That's a bit of a shame, since those raspis are now useless for BBP. (For whatever reason Rosetta@home only has packages for ARM on Android, not on Linux...). |
|
|
|
I can some of your questions. -Mined blocks need 102 confirmations before they are available to spend. -These mined blocks are separate from your getboincinfo information. That only concerns cancer-research payouts, and not POW payouts. -The need for wallet-pw to unlock is because the wallet needs to be able to send PODC updates, it will use the password to be able to send those. -You can check the amount of BBP that is staked with the command 'exec stakebalance'. By default 10% of your BBP is staked every 12 hours. If you want to change that percentage, you can add this line to your biblepay.conf: 'polpercentage=NUMBER', where NUMBER stands for the percentage that you want to stake (e.g. 'polpercentage=40'). Please stick with a maximum of 90 for the moment, while we do some more testing. I like your suggestions about being able to select the BBP address to associate your CPID with. And it would indeed be handy to see if your password was correct, but I don't know if that is technically possible, because of the way the password is stored, but I guess Rob needs to answer that question. I can't comment on the rest, but I'm sure others can Thanks for your answers so far. So I understand I mixed up "mined blocks with a CPID" with "CPID cancer research payout". Apparently what I received are payouts for blocks by (what was formerly known as) "solo mining", but with an associated CPID? So it was just a big coincidence that my controller wallet "found" 3 of those blocks? How is this calculated probability-wise? Normally I wouldn't find a single block in weeks or months going solo, so are CPID-associated wallets preferred in finding blocks? Regarding the cancer research payout (which is dependant on my RAC): so this will (for the first time) occur on block 33620, and only THEN will I receive the payment on the associated BBP address, right? Sorry for asking this many questions, but as a scientist myself I like to get a certain understanding of the things I'm involved in. |
|
|
|
Great news, block 33460 & 33461 were both signed by CPIDS!
CPID 7c9264559fef3c1c689ee9fc3ff42494 was awarded for our first PODC - CPID heat payment: 555 BBP! Congrats!
Wow that's my CPID, so thanks (I guess?)! To be honest, I have no idea what's going on right now with the technicals in the PODC payout, but I guess I managed to configure it correctly. I just checked my wallet and it shows 3 (unconfirmed) payments for approx. 555 BBP each. Is it supposed to be that way, or is this still some effect of the forked chains? My "exec getboincinfo" now shows the correct CPID etc., but "total payments" and "magnitude" still sits on 0. :/ (I double checked to be on the "correct" chain with the block hash of 33450.) showblock 33460 to see the blocks CPID info.
Sorry, what do you mean by that? Where do I find any information about the CPID payment in this block info? This just seems like a general description of the technicals and contents of the block. I realized some minor points of improvement in the whole process. First of all while performing the burn tx for the CPID association my wallet (seemingly) picked some random receive address for this. Would it be possible to specify the address associating (or tell it to create a new one for this purpose?). Or would this address matter at all? Secondly the new wallet upon startup asks for the wallet-pw to unlock. I still haven't quite understood what this is needed for (I guess it's for the auto-payments sent to interact with PODC?), but this doesn't work for me. There is no message whether you put in the correct pw or not, and even if I DO use the correct pw, it doesn't unlock. When I choose settings->unlock wallet it works perfectly. Thanks for all your efforts over the last few days and for managing the transition to PODC to go quite smoothly. Awesome work by all of you. P.S.: last question: From my understanding the controller wallet is required to stake BBP AND mine (on 1 thread minimum). Where can I check, if the system recognizes my controller wallet to perform that way and how many BBP are staked at the moment? |
|
|
|
it seem had 3 fork line... A Fork - Block:33356 B Fork - Block:33379 C Fork - Block:33403 Got from Pool status , is it bug? I'm not exactly sure what you mean by that but there's definitely some hickup with the pool. It says in "pool history" that it found blocks 33362, 33369, 33374 but they were all apparently skipped at the payout. The "distribution history" only mentions blocks 33356 and 33403, nothing in between. Also on the home page the "height" is off (showing 33357 right now). EDIT: lol, I just realized that purepool is going in reverse mode. Maybe 2 hours ago "getinfo" showed 33375, now it's 33355. Main pool says 33381.... |
|
|
|
Hello everyone, it seems I'm having trouble with my CPID association in prod. I tried PODC in testnet couple of weeks ago and it worked perfectly. Yesterday I associated my CPID to my main wallet, the transaction was completed and the wallet said "successful". However it doesn't seem to have worked. My exec getboincinfo still looks like this: {
"Command": "getboincinfo",
"CPID": "",
"Address": "",
"CPIDS": "",
"CPID-Age (hours)": 422322,
"NextSuperblockHeight": 33620,
"NextSuperblockBudget": 760165,
"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": -2,
"Magnitude (One-Day)": 0,
"Magnitude (One-Week)": 0
}I tried to just associate again, but the wallet just returns "Unable to sign CPID 7c9264559fef3c1c689ee9fc3ff42494". Usually it should take about 6 blocks only to let the CPID show up, correct? Could it be I associated it on a fork, since yesterday I think I still used 1.0.9.x? |
|
|
|
|
Show Posts
