Ive never seen that , so it probably has something to do with invalid cached boinc credentials.
Could you try installing "boincmgr" (the boinc gui) on your box, and launching it?  It should reveal any errors and also allow you to see your RAC per project visually.

Hi All,

We are ready to test baby step 1 for IPFS integration, if you are interested in helping us in testnet please join us here:

https://forum.biblepay.org/index.php?topic=244.msg4098#msg4098


Windows is compiling now.

Ok, I see it, this will be fixed in the leisure later today.

You can work with Znffal on this since Im feverishly trying to jumpstart ipfs. 

I dont think we need anymore exchanges currently anyway (til we get a top 20).  Were still talking to cryptopia however, as they like us and respectable.

Thanks Kismar, that was a good post.

2018-08-28 06:49:21
 ERROR: Found chain with blocks marked invalid
2018-08-28 06:49:21 ERROR: AcceptBlockHeader: block is marked invalid
2018-08-28 06:49:21 ERROR: invalid header received 846ef0d0c305f54a821ec9061af34a4cca1319cc84654b2e2e4f777039d6a38f
2018-08-28 06:49:21 tor: Thread interrupt
2018-08-28 06:49:21 torcontrol thread exit
2018-08-28 06:49:21 Cleaning sockets...
2018-08-28 06:49:22 PrepareShutdown: Prepare Shutdown In progress...
2018-08-28 06:49:22  Shutdown - renaming thread ...
2018-08-28 06:49:22 runCommand error: system(./biblepayd -erasechain) returned 32512


So it is revealing.  On my end I need to take a look at something - it appears we do sort of jump the gun in the "Found chain with blocks marked invalid".  We supposedly attempt to replay the last 205 blocks when that happens, but on your node it appears we jumped down and tried to restart it with -erasechain (see last line in the log) and that command returned an error (error 32512).

So on your end, if you are starting biblepay from an absolute path, (like from a script) that would explain 32512.  Ill take a look at this.  If you want autorecover to work, you could modify your script to :  unalias cd && cd ~/biblepay/src/qt && ./biblepayd     when it starts and then it should recover when this happens.  But this is just for the time being as we make this fullproof and resilient.

Yes, it works because the browser knows the mime type of a jpg.  You can run this command on your local node to see how many nodes its cached on:

ipfs dht findprovs QmarQqpoAz8Sg2mjm318UeiF3EAKZSBQGGpjm9dsRsYTGF

Im seeing about 6+ so far.

Sweet.

Well so far, Im very, very impressed with IPFS.  There are a couple pitfalls, such as how the software will run if you dont have the ports exposed, but I think the guys at IPFS have made a breakthrough in a certain area (in a lot of areas also).  If people can grasp the concept of "cost, quality, and fast development", those are 3 dimensions of software development (not authoritatively, as an example), where you usually have to sacrifice one dimension to gain another.  I believe the tenet achieved in IPFS is this one:  No one has been able to decentralize file sharing with fast IO, durability, and cheap storage before. It always required centralization or slow transfer.  One of their functional requirements was speed.  So IPFS is really a pleasure to test IF you know its set up correctly and it is pretty easy to setup.  I think so easy that we will be able to add IPFS to our sanctuary guide in the future and make it a requirement that our sancs also run IPFS. 

Im also impressed with IPFS's ability to spider other hosts and create their own ecosystem very similar to crypto peers.  After running for one night, I already have 100 peers, my bandwidth is being used by about 10%, and my biblepay cake jpg is now stored on 4 hosts already.

So, as far as biblepay being easy to use, Im working 24/7 as a top priority to release a testnet version that lets us upload attachments in our QT's Send Transaction UI using IPFS.  We can also install IPFS and test the links in testnet.

I suppose we can change the banner to say this above (even though I kind of like Orphans more than Charity) but I suppose they can find out about the orphans later.

Anyway, what are the exact changes (IE the text we want to add to the body) that we want to make to the first page?  Slovakia writes an ambiguous post.

This is just an idea, depending on how well IPFS works.  I see burst coin uses proof of capacity, but they currently store empty data on the hard drives, correct?  No real docs yet.

Here is an example of sort of what a decentralized web link would look like when clicked inside the wallet:

https://ipfs.io/ipfs/QmPQsL9CCgACauTJW9mgWcLdm5L8Mn7rF1thWV7BfB8Fii

IPFS also has ways of decentralizing DNS, but I think we need to go in baby steps first and prove the decentralized web site works.

Thanks!  Yeah, I did notice that filecoin was not live yet, and 250 million $ has been invested into the ideas ICO.  So this is definitely something we should have for our users so we can provide real value from our chain (to store some data in exchange for BBP).  And also for the novelty factor of clicking on decentralized web links.  We should make a version of our web site hosted on decentralized links when we're done also.

It also opens up the possibility for an alternative to heat mining in the future:  removing POW and using proof-of-document-storage etc. 

Thats a great idea!  A perfect use case for our own file system would be orphan receipt records/PDFs, accountability stuff.  Then we dont have to worry about bloating the chain with it!

I was thinking of a similar thing at church but more for tax purposes.  I was thinking once the foundation gets started when it starts storing tax records, if we lose the pool, we lose the entire SQL server (which has one record for each expense and one for each receivable), in this case we can also use it for DR to store a backup of the tax records, etc. 

I was working on one of the features in the DAHF, and while writing the block syncer, I came to the conclusion that we need to tackle the distributed file system problem first before going further in testnet with the analyzer (in order to sync financial blocks).

In light of this I am looking at possibly integrating IPFS (IP File System) into BiblePay (Testnet) - for Sanctuaries:
https://blockonomi.com/interplanetary-file-system/

From a very high level, let me explain what the initial goal would be and where BiblePay would receive a value-add:
To give the end-user the ability to upload a file via the wallet to be hosted on the BiblePay IPFS (right before sending a transaction).  This is basically the ability to attach a file to a transaction being sent.
BiblePay can charge a Fee for this, to lease the storage space on our Sanctuary network for a given lease time (Most likely this will be 6 months with an expiration date on the txid- explained later what the reasoning for this is).
The file would be uploaded into IPFS and hashed.  The hash would be stored on the txid.
The Sanctuaries would swarm around the file and each would host a copy of the file on their own local repository (IE the SAN directory) of each sanc, for durability.  The Sanc would honor the Expiration Date and store the file until the expiration date passes.
The Sancs who store the file will split the reward that the lessor paid during the send of the txid.
Another user, who double clicks on the TXID in the QT txlist will have the ability to download the file from IPFS, and, if the file is not encrypted view it.  Optionally it may be encrypted with the senders biblepay keypair, and only the recipient or sender can view it.
In DAHF, a file can be retrieved by its hash.
One huge side benefit of this, is this IPFS protocol allows the build-out of the new decentralized web.  IE you can click browser links in the future based on files stored in BiblePay.  (That feature might add large value to BBP in the future).

No you can run boinc 1 hour a day and get payment, you just have to have an associated CPID, and the correct amount staked in the chain.

You can run it on a rented AWS and stop it and you will get some RAC until it diminishes again (not much as it takes time for RAC to build up) but on a supercomputer that RAC would hit pretty fast and stick around for 14 days on the CPID.

Hmm, I think your OK on the first error, that means it tried to clean the chain and couldn't so it tried to reboot (and couldnt because it was launched from an absolute path).
On the 2nd error however, someone will need to run that version in valgrind and give me the line # of the 'double free or corruption'.

EDIT: On #2: I believe I just reproduced the error.  Please upgrade to 1146h.

Not correct - someone asked where the info was for Revenue because they only saw the expense; You have to have common sense to understand the records since two menus exist - revenue and expense.  Everything has been and is transparent, there is nothing you cant figure out here.  It always has been the case that your mind is clouded.

We are offering to add an enhancement to allow a user to donate to Compassion on behalf of biblepay, I wouldnt call it a 'change in business practices'.  Its an additional way to donate to our orphans.  Someone should call them at compassion and ask them if its OK first.

You know we have April from BLOOM (orphandefender) here working on professional PR with Jaap?  This endeavor isn't even past the intro phase yet, have patience, our PR phase hasn't started.

I was going to say the same thing:  Its illegal for an entity to help trade crypto for dollars especially since our foundation is based in the US. 
We are regulated by FINRA and Anti-money-laundering-laws, and the KYC law is in effect, and exchanges must determine if a coin passes the Howey test when it is listed.
Exchanges have a lot of responsibility to meet regulatory compliance or they can be shut down.

However, I do like the idea about being able to donate directly to the compassion account.
I think we could make a deal, where if an investor were to donate fiat to the BiblePay Foundation Compassion Account #, we could reimburse you at the coinmarketcap rate with BiblePay coins, when the superblock emits the Compassion coins, if I am given a receipt and then I can double check in the account before sending the coins, and log that as part of our monthly liquidation paperwork.  I could see that as a nice way to get more BiblePay and help us at the same time.

The other way to donate to compassion is to send BiblePay from your wallet to the foundation by clicking "Donate to Foundation" checkbox.  This always gets liquidated as part of the monthly compassion liquidation.  However in this case you are Giving a gift to the foundation.

Please take your spirit of Ahab back to the cross, and let us pray that Slovakias demons are expunged in the name of Jesus! 

Squeal!

Thats a cool gauge, its kind of like the VIX for the stock market, wild.

I don't know on the DAHF.  I've never personally tried to develop crypto trading strategies or had enough confidence (in crypto trading) to say one way or another.

Its certainly the wild west still, which means crypto is rife with opportunities, large spreads, lots of inefficiencies and those things are good for profits, if you can figure it out.
You have to overcome the commissions, the overhead of transmitting in and out, the fact there are no margin agreements, maybe some exchange risk (will an exchange go belly up while you have half in positions), no TIMS, no PM leverage, etc.  However Im sure there are some crypto-exchange arbs available (buy one exchange sell @ another while hitting the prices - inter-exchange arb), but do realize it has to be treated as cash (meaning the margin requirement is 200% to do that) etc, but we can talk more about it over there if anyone has any proven working strategies, wants to write a back test and feels confident of the idea.