Bible Pay

Recent Posts

Pages: [1] 2 3 4 5 6 7 8 ... 10
1
It is more almost 20 hours since I hid my PCs but nothing has changed till now. My taskweight and UTXO are the same. PoC payment was decreased (but it is caused my UTXO fell to 75 before). And my magnitude is still rising. You were writting that it should change after approx. 8 hours, but nothing happens till now. Is it OK?

Lets wait the full 24 hours to see your magnitude go to zero.
I see exec leaderboard still shows your 04fb* CPID to have a magnitude of 37.1, and my sanctuary shows you with a UTXO weight of 75 and taskweight of 100.  Id like to see those show as zero before you change your settings to unhide the machines.

In the mean time can you give us the blocknumber that your PODC update was sent out on?  You can see it in the transaction list.

EDIT:  The 8 hours is when the client tries to send more updates (thats called a PODC Update).  The 24 hours is when the network loses your records.  Lets try to make distinctions between those things.
2
Yes, could you please be our guinea pig?  Lets just leave it hidden til you reach 0 reward and let us know when that happens (how many hours it took) then unhide it and watch it go back up.
It is more almost 20 hours since I hid my PCs but nothing has changed till now. My taskweight and UTXO are the same. PoC payment was decreased (but it is caused my UTXO fell to 75 before). And my magnitude is still rising. You were writting that it should change after approx. 8 hours, but nothing happens till now. Is it OK?
3
When we are talking about visual. I don't know if it is only my problem, but I'm not able to reduce wallet window size below some px (It is approx 90% of my screen height) And in testnet I'm unable to reduce it below maybe 110% of screen size, so I'm unable to see status bar and I must maximize my window to see everything. I have Win10. It is only my problem or it is common? Is possible to solve it?
I think, that I've found the cause of my problem. I'm using biblepay-taditional as interface theme. When i change interface theme it is no problem to change (decrease) window size. But it is impossible for me to decrease it in biblepay-taditional.
4
Great! I must say beforehand: Both AMD rigs I was telling you about were using the windows wallet. Looking back, could it be possible that the windows wallet (pre 1094c) wasn't using the 250ms setting yet?

Because just now I tested the new wallet on my linux rig, and out of the box (250ms) the cpu usage is already much lower than before. When I set it to 0ms it's back up to it's old values again.

I now set it to 500ms, and I'm able to get BOINC running along nicely while also mining (it's a véry slow AMD E-450 laptop) . I think it's great to have a 'one-go-solution' to tweaking the settings so that BOINC and one-thread-mining can go hand in hand, because I can imagine that a lot of people will be using only one computer to generate BBP.

Great on the improved results!

Yes, before it was definitely true both win & linux were not sleeping the full default value, primarily because the nonce break didnt allow the wallet to sleep when it was told to.  Now in 1094c+, the windows wallet looks for its &HFF nonce break (thats about 256 hashes) and does what it is programmed to.

Yes, I agree I think if we can make some intelligent decisions then using biblepay will be more like using an iPhone.  My old boss used to say Oh that was a developer decision (implying that it was a horrible decision).  I agree that there are a lot of brainless decision out there that creep in from crazy PR discussions.

5

But to answer your question more specifically, since you left podcupdates off, which is good so we can see the effects of it, you were asking why is my magnitude still 8 in getboincinfo?  Its because getboincinfo takes the last 7 days of magnitude-payments and averages them to be your Last 7 Day mag.

However your exec leaderboard should show you dropped out of the leaderboard with 0 mag. 

Also your exec getboincinfo  Last superblock payment should be 0.  <- Thats a good test, please see if you missed out on a research payment in a block where others have received research payments?


I think Ill add 24 hour magnitude and 7 day magnitude in exec getboincinfo, to make this clear.

The UI shows the 7 day magnitude value, for smoothing.

Then the user will see trends more clearly.

6
I know this is going to sound a little complicated.. and Im thinking of ways to simplify this but with advanced system comes some advanced business logic:

The getboinc info values are current as of right now, so this is what Your client feels your RAC and your UTXOWeight and your TaskWeight are right now.  However, it takes a while for those to propagate through into the Sancs memory.  Because the Sanc has to allow 6 confirms for utxo weight in order to trust it and memorize it (it memorizes each cpids utxo weight into memory with a global key, called CPID_UTXOWeight_ with a 24 hour deadline on the timestamp, where new stamps erase old stamps, so its a complicated thing to explain).  This way all sancs are memorizing the utxo weight and task weight at the same time - all their memories should be equal.  They actually vote on what *they* agree on.

Now the Magnitude in getboincinfo is actually your reverse engineered magnitude over 7 days period. 
Your Superblock magnitude however , seen in exec leaderboard, is actually your "realized" mag as of the last superblock.

So from a cosmetic point of view, Im working on homogenizing this to just give the average biblepay-qt user a few numbers to look at on the GUI.

For the techies though, this means:  Your getboinc info is current debug info, but what the sancs vote on (they are always voting on the Next contract) is slightly different, as their memories are lagging slightly.

To see what a sanc *will* be voting on, go to one of your sancs and type exec testvote.  That particular contract can be dissected to see what they see about the network.


But to answer your question more specifically, since you left podcupdates off, which is good so we can see the effects of it, you were asking why is my magnitude still 8 in getboincinfo?  Its because getboincinfo takes the last 7 days of magnitude-payments and averages them to be your Last 7 Day mag.

However your exec leaderboard should show you dropped out of the leaderboard with 0 mag. 

Also your exec getboincinfo  Last superblock payment should be 0.  <- Thats a good test, please see if you missed out on a research payment in a block where others have received research payments?

7
No wonder I was so confused!  I made the assumption the code was still working the way it was when I tested it last week.
So anyway when I added the podcupdate feature, it broke a couple of the return codes (or circumstances) inside the 'éxec  associate' feature.  So those are now fixed, and now people will see "ALREADY_IN_CHAIN" or "INVALID_CREDENTIALS" during the proper circumstances, in the next version.

Im checking in 1.0.9.4d now for linux if anyone wants to test that tonight.   Starting windows build over.

Lets check this out tomorrow when we have a chance to ensure reassociation works now.

Thanks for pointing out this bug!
1.0.9.4d for windows is now out there, if anyone was experiencing the Invalid Credentials bug or the miner-cpu-usage issue.

8
If Taskweight and UXTOweight are zero, should my magnitude be zero? I forgot to turn PoBH on.
Code: [Select]
"version": 1000904,
  "protocolversion": 70715,
  "walletversion": 61000,
  "wallet_fullversion": "1.0.9.4",
  "balance": 14328660.49245012,
  "privatesend_balance": 0.00000000,
  "retirement_balance": 0,
  "blocks": 6700,
  "timeoffset": 0,
  "connections": 12,
  "proxy": "",
  "difficulty": 0.2833186345714879,
  "testnet": true,
  "keypoololdest": 1518115544,
  "keypoolsize": 1001,
  "paytxfee": 0.00000000,
  "relayfee": 0.00010000,
  "errors": ""

"Command": "getboincinfo",
  "CPID": "4fd1bf6c6900d92b226e16c6a6935661",
  "Address": "yWQfYmBCAQrcn9RkjM9DJwWGfgjHdvpZwn",
  "CPIDS": "4fd1bf6c6900d92b226e16c6a6935661;",
  "CPID-Age (hours)": 422068,
  "NextSuperblockHeight": 6732,
  "NextSuperblockBudget": 1359680,
  "4fd1bf6c6900d92b226e16c6a6935661_RAC": 820.6,
  "4fd1bf6c6900d92b226e16c6a6935661_TEAM": 15044,
  "4fd1bf6c6900d92b226e16c6a6935661_TaskWeight": 0,
  "4fd1bf6c6900d92b226e16c6a6935661_UTXOWeight": 0,
  "Total_RAC": 820.6,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 546564,
  "Total Budget (One Day)": 13700330,
  "Total Budget (One Week)": 67535384,
  "Superblock Count (One Week)": 63,
  "Superblock Hit Count (One Week)": 49,
  "Superblock List": "6633,6534,6435,6336,6237,6138,6039,5940,5841,5742,5643,5544,5445,5346,5247,4653,4554,4257,4059,3861,3762,3267,3069,2970,2871,2772,2673,2574,2475,2376,2277,2178,2079,1980,1881,1782,1683,1584,1485,1386,1287,1188,1089,990,891,792,693,594,495",
  "Last Superblock Height": 6633,
  "Last Superblock Budget": 1359680,
  "Last Superblock Payment": 0,
  "Magnitude": 8.09300203283067

I know this is going to sound a little complicated.. and Im thinking of ways to simplify this but with advanced system comes some advanced business logic:

The getboinc info values are current as of right now, so this is what Your client feels your RAC and your UTXOWeight and your TaskWeight are right now.  However, it takes a while for those to propagate through into the Sancs memory.  Because the Sanc has to allow 6 confirms for utxo weight in order to trust it and memorize it (it memorizes each cpids utxo weight into memory with a global key, called CPID_UTXOWeight_ with a 24 hour deadline on the timestamp, where new stamps erase old stamps, so its a complicated thing to explain).  This way all sancs are memorizing the utxo weight and task weight at the same time - all their memories should be equal.  They actually vote on what *they* agree on.

Now the Magnitude in getboincinfo is actually your reverse engineered magnitude over 7 days period. 
Your Superblock magnitude however , seen in exec leaderboard, is actually your "realized" mag as of the last superblock.

So from a cosmetic point of view, Im working on homogenizing this to just give the average biblepay-qt user a few numbers to look at on the GUI.

For the techies though, this means:  Your getboinc info is current debug info, but what the sancs vote on (they are always voting on the Next contract) is slightly different, as their memories are lagging slightly.

To see what a sanc *will* be voting on, go to one of your sancs and type exec testvote.  That particular contract can be dissected to see what they see about the network.

9
Mining - General / Re: Purepool Biblepay Pool
« Last post by Lichtsucher on Today at 04:42:52 am »
As promised, I just released the source code of the Purepool Biblepay Pool:

https://github.com/Lichtsucher/purepool

Important: The software is designed to be easy to use for the miners and the pool admins, BUT the pool admin still needs to be an experienced linux admin.

The software is written in python and is based on the django framework. It was tested on Ubuntu 16.04. Everybody who wants to install and run it needs knowledge in the topics: Apache, Python, MySQL, Linux, RabbitMQ, Celery, Memcache (or at least must be able to dive into these topics).

There is currently no step-by-step installation guide, but the README will guide most linux admin in installing the pool.

Small note: The README only talks about the standard installation on multiple servers. You can install it on one server, I simply won't advice you to do that.

And yes, I'm aware that the pool might not be required with PoDC, but it might still be useful for a short time, or the base for some future development :)
10
Mining - General / Re: Solo mining ..anyone still doing this?
« Last post by Lichtsucher on Today at 04:42:05 am »
I'm pretty sure that was my worst run of luck and really outside what had been statistically normal in January where I was averaging about a block every two and a half days .

Same here. In Januar, 1 Block every 2 days, but now it took up to 9 days to hit a block.
Just look at my pool (https://www.purepool.org), it took a whole weak to find a block with multiple miners. Wow. It is really hard now to find a block.
I think solo-mining isn't working for a lot of people anymore. PoDC might be here at the perfect time.
Pages: [1] 2 3 4 5 6 7 8 ... 10