Messages

2896

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: September 02, 2018, 05:58:04 PM »

Windows should be out there now.  1.1.4.8.

Ill set up a sanc and then attempt to edit the OP with additional tests, etc.

2897

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: September 02, 2018, 05:51:10 PM »

Hmm... This is strange...

The IPFS seems to be installed without error, and also running, but this directory doesn't seem to exist.

Hi Jaap, please try
ipfs stats repo

The Repo path should be in there.
Then cd to it and nano config.

2898

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: September 02, 2018, 10:38:11 AM »

I just pushed 1.1.4.8, I'll explain some more after church.

Building Windows now.

2899

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: September 02, 2018, 09:19:59 AM »

Steps to edit IPFS config in order to expose your IPFS for Biblepay integration:

cd ~/.ipfs
nano config
scroll down to line 47 (the line reads:  "Gateway:" /ip4/127.0.0.1/tcp/8080)

Edit the line to be:
"Gateway": "/ip4/your_sanc_public_ip/tcp/8080"

Stop the daemon and restart the daemon.

Once ipfs is running again, verify you can pull a file from your sanc publically:

http://yor_sanc_ip:8080/ipfs/QmPVMkWe7976YH22quBotbrDMV9tP4qCz9P5tndveKdeGs/hi.txt

2900

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: September 02, 2018, 08:18:50 AM »

There seems to be an indication that there's a max storage you can configure:
https://github.com/ipfs/go-ipfs/pull/4388/commits/0d2cc04fa7691f04b899e0a6dede77db96356e68


For BBP & IPFS, you'd have to guarantee at least 6 months which is the whole point of attaching files within BBP right? If BBP checks that all documents are available to peer on each sanctuary, then these documents need to be "pinned" since garbage collection jeopardize document availability on a specific sanctuary.

Since we don't know the total storage required, some sanctuaries will likely perform the heavy lifting if they have the storage required. Other sanctuaries would likely make a best effort and let garbage collection remove the less accessed documents. I don't know what Rob is thinking about Proof of Document Storage (PoDS), but I could what percentage of the documents you can store on your sanctuary affecting how you are paid.

Since my sanctuary with 50GB storage can only store 50% of the required documents, I'm only eligible for 50% of the PoDS reward. But my other sanctuary with 100GB storage can host 100% of the required documents, is eligible for 100% PoDS reward. PoDS reward could be 10% (e.g. 3.85% of the monthly payouts) of the 38.5% Sanctuary. Initially, every sanctuary would get 100% PoDS reward, but if PoDS takes off, those with more storage can receive the full 100% payment over time.

Note that some of these things can be made into network adjustable sporks, so we can adapt to them.
On the comfortable hosting size per node, I personally think allocating 10-20 gig of storage should be enough, and Jaap, you can set a limit in the config file of ipfs so it does not overrun your drive.  I was thinking, BBP should be relatively cheap per K of storage, but we can probably charge quite a bit for a bigger file.  If its going to be hosted on 270 nodes, and available to the world, that file might be $5 per month.  We can discuss pricing later.  We also have to discuss how the sancs receive compensation for the attachment (currently I have it set as *penalization* if they dont participate in doc storage) but if there is a 1000 bbp fee on a transaction, right now it would go to the orphanage foundation.  This has to be well thought out and implemented for prod.

As far as Sanc penalization, heres how it is set currently:  We do have a spork that turns the PODS system on or off (podsmode=0 means its off in prod).  When it is on, we have a health check feature.  When a sanctuary is assessing proof-of-service, this is the activity of a current sanctuary looping through all known biblepay sancs, and checking if they are online (end-to-end verification), when the sanc assesses the state of another node to be healthy it stores a value of either "ENABLED" or "WATCHDOG_EXPIRED", enabled means the other sanc is online.  So with PODS, we add in an extra similar health check for IPFS.  If the foreign sanctuarys gateway port (8080) cannot serve the healthcheck.dat file properly, the sanc gets marked as "DOWN".  This would actually cause my sanc to not vote on the down sanc for regular sanc payment.    Meaning masternode winners votes would shrink - specifically with the downed sancs not being voted for payment.

However if the sanc is UP, if we have PODS in STRICT mode, it will then try to pull down a file that is paid for and leased in biblepay.  If that file is pulled successfully by hash (we check the actual downloaded files bytes length and the web servers stated byte length also) then we add that file to our own repo if it was missing, and we mark it as downloaded (this is so we dont keep asking for the same failed file), but if that sanc is not able to deliver that particular file, we mark that sanc as "DOWN".

So in this way all sancs who are up and host all the files are fully paid, sancs who are up and only host half the files should technically receive about 50% of the winning blocks still, because they will still receive some UP votes from other sancs who happen to be checking the files that *are* present.  So another words, I think we might want to KISS, and allow payment to be :
SANC REWARD * PERCENT OF FILES SHARED = SANC REWARD * PERCENT OF VOTES = THEORETICAL EQUAL PAYMENT
In practice, if this does not work, we will need to add an affinity of file hashes to votes, but I really would rather resist adding complexity if possible.
(This is how it is programmed now - sancs vote for you if you have the file the sanc is checking for at the time it is ready to vote and you are up).  Sancs do keep a list of what files were checked in memory and loop through different files automatically.

In this next version each sanc has to run ipfs, and in the ipfs config file (see ipfs stats for the location of config) you must edit the config and change the "127.0.0.1:8080" binding to "your_sanc_ip:8080" - this is so you can host a public file gateway.  Note that by default your IPFS does not run a gateway, so this has to be manually changed by everyone.  I have not investigated automating ipfs installs yet etc.

Please try to edit your ipfs configs and restart the daemon, and see if you all can pull a file from:

http://yor_sanc_ip:8080/ipfs/testhash

Once you get that working your sanc is ready to be ipfs enabled.

2901

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: September 02, 2018, 07:54:28 AM »

Just to update everyone waiting for the release:  It should be ready within a couple hours.  It's running a little late due to some of the debugging required for ipfs.

2902

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: September 01, 2018, 09:45:50 AM »

macOS wallet worked fine. Uploaded an image without having to make any adjusts to the file name in the form field.


Good article on using IPFS to share documents where it is only available to the recipient (encrypted with their public key) as one use case:
https://medium.com/@mycoralhealth/learn-to-securely-share-files-on-the-blockchain-with-ipfs-219ee47df54c

Hey all, with our recent drop in price I believe we need a huge end of September release.

Please keep eyes peeled for the next testnet version.
Im working on merging in a spork to give us the ability to test PODC with NO TEAM requirement, and we really need a few cpids to verify this works properly.
We also need to test the blacklist spork, to ensure if a team is changed to a blacklisted team, the payment stops in the superblock.

I'm adding in IPFS integration now, to provide proof-of-document-storage (I suppose we can call this PODS).  Ill explain the spork settings later today.  But in PODS, the next version will provide Durability for the data (meaning for the life of the lease, you can download the file from the gateway).  It will also enforce sanctuary payment by requiring Sancs to host the files that are paid for in the chain (otherwise the sanc loses the sanctuary payment).

Regarding the encryption method, yes, I like that idea for one-to-one transfers, and Im on the fence as to if we should Require that when we go live with PODS, or allow the docs to be downloaded as we have them now (through the gateway).  I understand both sides of the argument- usability for future decentralized websites vs privacy.  The IPFS system is storing the files as blocks, so currently the data is not encrypted.  But we should consider encrypting everything before we go to prod with the feature.

2903

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: August 31, 2018, 09:13:17 AM »

Do you know where the file spam is Rob?
My testnet machine is at 99% disk usage again haha, I closed biblepay for now until next update,

I appreciate all your hard work Rob! and thank you to everyone helping test

UPDATE: Thanks sunk818, it was the debug.log in ~/.biblepaycore/testnet3

Thanks Togo!

Yeah, for now if you could delete testnet3\debug.log after its running. 

2904

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: August 31, 2018, 09:06:11 AM »

Open attachment button in transaction details is visible whether an attachment exists or not.

Do you think Open Attachment button should be hidden when there is no attachment?

Yes, I meant to do that, and forgot about that!  Doing now....

2905

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: August 30, 2018, 11:13:01 AM »

Ok, so in the next version you should be able to see the attachment icon (right now its two pieces of paper but we can have Marcus take a look at possibly changing to a paperclip later),  fixed the filepicker to fix the disk path on windows and unix, added the newline between the rows,
and a biggie in testnet:  Something was filling up the drives with spam - I found the root cause and modified the miner to require the signed cpid in order to mine and that fixed the spam.

Im still working on some other issues so I wont release this version yet.

2906

Archived Proposals / Re: BiblePay-Removing the BOINC Team Requirement for possible future Sustainability

« on: August 30, 2018, 10:15:44 AM »

Maybe we should consider doing one thing at a time and keeping the UTXO requirement but remove the team only for now.

I'll update the proposal to reflect removing the team only, but leaving in the UTXO.

This way as people come over from BOINC, they will have to buy BBP to mine.

2907

Archived Proposals / Re: BiblePay-Removing the BOINC Team Requirement for possible future Sustainability

« on: August 30, 2018, 07:29:59 AM »

"That's my two cents. I believe God is backing up this project and Lord Jesus will not let it fall but I also believe that economical side of the project needs to be properly adjusted and sound from broader perspective. And sorry I went little bit further from the main topic here."

Amen brother.

2908

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: August 30, 2018, 07:16:43 AM »

There is a third possibility isn't there besides accepts it or rejects it... and that is... it accepts it, processes the upload, but the transaction ID doesn't include the ipfs hash in the transaction details? I wish I was smart enough to understand my 2.4MB file works, but not a 4MB file. 4mb jpeg - can you try to attach this file and see if you can replicate what I've been saying? This is the file: https://upload.wikimedia.org/wikipedia/commons/1/1e/Caerte_van_Oostlant_4MB.jpg

So, I was able to upload a 2.4MB file:

but this one 4mb jpeg doesn't show the ipfs hash in transaction details.

Ok, Sorry I was getting 'code defensive' there, its a new day!  Hang on.

First on the 2meg video you uploaded:
https://ipfs.io/ipfs/QmceXVXDjork9aT2MoVnroYRc3RxLXdJY8UA9872y8o9FV

Its working, so thats nice and exciting.  Thanks.


On the 4mb jpeg, great news, I reproduced:  Your right- I dont see the ipfs hash and it is a 3rd condition! Thanks.    Checking....

Ok the 4mb jpeg issue is resolved.  It had to do with the base64 conversion setting, its fixed, now you can upload it, and now you should see any errors appear in biblepay that have to do with attaching problems bubble on the screen.

Here is the link to the one I just uploaded:
http://ipfs.biblepay.org:8080/ipfs/QmawtK1eHmjUcF4z87bEg7819hk6FE9cPTsG7HKcLCBZ5x


Please try again...

2909

TestNet Discussion Archive / Re: TestNet Testing Thread - Test IPFS Integration (Decentralized IP File System)

« on: August 29, 2018, 09:44:35 PM »

> Wow, a 21 meg file, thats cool, lets see if it plays from our gateway link, can you paste the link?

File uploaded I think (maybe it is in your hash list), but it doesn't show up in transaction details. Also tried 10 meg jpeg and doesn't show up.

I think ipfs has js wrapper to play videos, but not sure if they play outright. Maybe it is browser dependent.

I tried the following and I seem to be peered with you now:

ipfs pin add QmcbKYZRFGYsmBiEhqjQ4J7uoGY5DSHqs5uQg7fqsW7J1r

That doesnt make sense; the code either accepts it or rejects it.  I do not think you tested it properly; can you Upload the file into the transaction and double click it, and then paste it, and that means the Single test was performed?  (In contrast to uploading it and forgetting to check on the transaction list message). 

If something fails, you can just post the entire error message here, since this is an atomic test.

So far, I see no flaws in the system except user error and the ipfs gateway going up-down at random times.

2910

Archived Proposals / Re: BiblePay-Removing the BOINC Team Requirement for possible future Sustainability

« on: August 29, 2018, 09:20:20 PM »

The biggest impact is removing Team BiblePay requirement. This change brings in more miners, but are they going to stake or sell BBP? GridCoin miners seem the most logical to register their CPID. I feel they will sell BBP & ByteBall. BBP is a Christian crypto niche: highly targeted with a loyal demographic. Others in it for distributed computing will likely not stake BBP. So, it feels like a net loss to me. You lose advertising benefit of highly ranked team on Rosetta@Home/WCG and still have liquidation issues because GridCoin miners sell their BBP.

Your current magnitude will plummet due to influx of GridCoin miners. 10 000 RAC for 1 MAG could easily become 30 000 RAC for 1 MAG.

Email registration on Rosetta@Home and WCG is extremely easy.

If I don't have to stake, it'd be easy enough to create multiple instances with separate CPID on one machine:
* datadir to current directory
* biblepay.conf with unique port & rpcport

You can easily run 20 instances on a single machine.

I just created another instance of BBP on my machine just now.

Why would you need to check stats? Wouldn't PoDC payment be enough (assuming you had the same hardware for each machine). Certainly, there's some upfront configuration time, but once everything is set up, there'd be very little intervention involved. I don't think there'd be that much abuse... just saying it'd be easy to do.

Im not saying thats its not possible, and Im not saying it wont be done, what Im saying is a large percentage of people who use boinc have an affinity to keep ONE CPID and like to keep their stats intact.

And time is worth money and it does cost this person time to manage multiple accounts.    Especially to manage 20 biblepay controller wallets. 

The RAC threshhold requirement for UTXO would still be better to have in to keep the boinc whales from jumping in and destroying the small miners rewards.  If a whale wants to split the cpids, so be it, but for the most part the end user would be protected moreso with the utxo requirement than without it.