Bible Pay

Read 93200 times

  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Welcome to the BiblePay Testnet thread for IPFS!

To install the latest version for testnet:
Please upgrade to v1.1.4.7+



  • Test attaching a document to a new QT Send Transaction
  • Test double clicking the transaction list and viewing the attached IPFS file hash
  • Test Opening the IPFS document link
  • Test the fee charged for BiblePay storage
  • Assess exact root cause of IPFS instability; when ipfs.io goes down, check to see if reliability is 100% when using our gateway (IE files are still always retrievable and instability is always gateway instability), we need to determine the quality level of IPFS itself

How to install IPFS on a Sanctuary (Ubuntu 64 instructions):
https://raw.githubusercontent.com/biblepay/biblepay/master/InstallingIPFS_Ubuntu64.md

How to launch biblepay-qt in testnet:
./biblepay-qt -testnet -listen=0 -masternode=0

(The listen and masternode flags are only required if you want to run Testnet side-by-side your Prod sanctuary)

Synced Verification Info:

getblockhash 53930
45aa03a87251d06b867e4fbb5e24d87970e18176d1739e609366156423a847fb


To help us isolate and assess any instability I started a gateway server (similar to ipfs.io except http:// and running on 8080):
http://ipfs.biblepay.org:8080/ipfs/QmPVMkWe7976YH22quBotbrDMV9tP4qCz9P5tndveKdeGs/hi.txt
We may want to change the biblepay links to go through this gateway to remove instability.


« Last Edit: August 28, 2018, 12:03:56 PM by Rob A. »


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Going forward does the QT wallet also run a IPFS daemon? Or is this specifically tied to masternode holders? Or participation is a separate configuration? Can't wait to try out the new build! :)

Curious your thoughts on content control/censorship. Say someone uploads copyright material, x-rated videos, etc. Can we vote down, or do we work with IPFS directly to censor this material?

So, Ive been thinking about the topology, and I think it will be a nightmare if we build IPFS code into the regular user build (IE the non sanc build), one because of the code volatility, two most users will not set the IPFS firewall up correctly, it makes our normal user process much more complicated, the files will probably be over-stored on every user machine.  So I wanted to start by looking at this from the Sanc perspective.  If we require Sancs to run IPFS, that would give us approx. 250~ nodes of storage for biblepay, and those guys are usually running in the cloud where the firewall config is easy, and they would be the ones paid for proof-of-storage.  (We can talk about Mining for proof-of-storage later), Im considering this topology for :  Jumpstarting biblepay with IPFS, integration with DAHF, and proof-of-document-storage.

As far as durability, Im thinking each Sanctuary that runs IPFS will scan the active transactionids with attachments, and verify the amount was Paid for storage.  If paid, it will verify it has the file in the local repo (by doing an ipfs get if its not there). 
As far as proof-of-document-storage, we need a way to enforce that the sanc itself is doing its job.  Sort of a system where one sanc picks a random active document and checks to see if its actually available on 10 sancs.  Any sanc that has the document missing is somehow flagged as a bad actor.
Maybe we withhold payments to sancs who are bad actors (IE they lose their position in the sanc queue for sanc payments).
In this way we could just split the document fees among all the sancs (or give the document fee to the next sanc in line for payment, for efficiency reasons), but hit the sanctuary with a hard penalty if they stop running ipfs.

As far as X-Rated content, Im big into ensure they dont store that!  I am so big against this and viruses, that maybe the answer is we do not store unencrypted documents on our system!  Maybe we need to enforce encryption, so only the sender and receiver can actually do anything with the file.  Of course that hoses up our vision of storing our wiki and web site in our own file system.

We have to also consider what ipfs says about restricted content (lets say its an unreleased movie).  Someone uploads an unreleased movie into the ipfs biblepay storage.  Their stance is its not a copyright violation because its stored as a merkle-dag, I believe.  But that isnt good enough for us, as I dont want any x-rated files in our chain, or a copy of a virus.

« Last Edit: August 28, 2018, 09:50:44 AM by Rob A. »


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
A couple more important notes about IPFS:

Unreliability:
Since https://ipfs.io/ipfs is a free public service gateway, I've noticed that its up and down.  This morning during testing I couldnt download any files (it hangs).  Other times, it works great.  So obviously we will need to create our own.  In this first version for biblepay the gateway is hardcoded in as "ipfs.io" so expect the hiccups to occur.  We can offer a separate download link directly from IPFS (IE going around the web resolution) to see if its specifically the gateway web server or not.

MIMEs:
In this first version, we take the IPFS hash of the file, and provide url's that end with the IPFS hash of the file.  This works for most things as the browser detects the mime type.  In the future it is possible for us to create a directory shell for the file and provide the file name and extension and still be IPFS compliant.  This will allow the link to be opened with a file extension like this:
ipfs.io/ipfs/directory_hash/file_name.file_extension  (This may be helpful for us when we are writing a web site or wiki etc).



  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
One thing we might be able to do to be DMCA compliant (I'm creating a term here for the sake of the discussion, called DMCA compliant which means: we refuse to store x-rated or illegal files, we refuse to store copyrighted works), and calling it DMCA compliance. 
Maybe we refuse uploads into our repository that are not encrypted with a key found in the biblepay.conf file (IE documentkey), and it must not be blank. 
Then if an organization uses us for storage they can give that key to their customer (for decryption), but to us, we are just storing merkle-dag blocks of encrypted data.
For the biblepay-foundation web site and DAHF:  we can share those two keys with everyone, then people can click on the website and the DAHF links and it will find the key to decrypt those without doing additional user work.  I suppose we will need a 'keyring'.
« Last Edit: August 28, 2018, 10:15:42 AM by Rob A. »


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Please test this gateway with a file uploaded outside of biblepay into IPFS:

http://ipfs.biblepay.org:8080/ipfs/QmPVMkWe7976YH22quBotbrDMV9tP4qCz9P5tndveKdeGs/hi.txt


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
I see there is a version of IPFS available on .NET:
https://github.com/richardschneider/net-ipfs-api

Not sure how good it is, but thats exciting to know.



  • T-Mike
  • Sr. Member

    • 375


    • 2
    • February 06, 2018, 06:12:58 PM
    more
Installing now. What do you want me to test? I'm using headless by the way.



« Last Edit: August 28, 2018, 12:21:36 PM by Rob A. »


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Installing now. What do you want me to test? I'm using headless by the way.

Everything in the OP post.  The tests are primarily for QT.

On headless you can only test one command: exec ipfsadd documentname.

This version is a proof-of-concept to show that a user can attach a document to a transaction and the receiver (or anyone in this case can open that from IPFS).


  • T-Mike
  • Sr. Member

    • 375


    • 2
    • February 06, 2018, 06:12:58 PM
    more
Everything in the OP post.  The tests are primarily for QT.

On headless you can only test one command: exec ipfsadd documentname.

This version is a proof-of-concept to show that a user can attach a document to a transaction and the receiver (or anyone in this case can open that from IPFS).

Ah yes, sorry. I actually read it then forgot.


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Windows 1.1.4.7 is out there now!



  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
I forgot to mention guys:  To add an attachment,  from QT, click the Send Tab, populate the address (or click donate to foundation), and click the "Attach File" button (which  happens to be transparent, which is a bug - will be fixed soon).  Pick a file from the picker then it will add it to the transaction.

Once its actually Sent, it will be added to IPFS; if it fails to go to IPFS you will see "transaction create failed" and your money will not be deducted or burned and the tx will be cancelled.

Then after you sent it successfully, go to the QT transaction list and double click the Transaction.  You can either click Open Attachment, or you can scrape the link out of the description and check for the document in IPFS.  You should be able to modify the link with the biblepay IPFS gateway and see the same doc from our gateway.

« Last Edit: August 28, 2018, 04:17:27 PM by Rob A. »


  • MIP
  • Sr. Member

    • 365


    • 47
    • February 13, 2018, 11:55:52 AM
    more

MacOS testnet version is available in
https://www.biblepay.org/biblepaycore-testnet.dmg


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
So here is one idea we could potentially compete in the proof-of-document storage business:

1) All docs uploaded into the biblepay network must be encrypted; most likely we enforce an encryption mechanism based on a keypair before we store the file in IPFS.  Our stance would be only the uploader or (shared key recipient) can actually decrypt and use the file.  This should pass DMCA compliance.

2) To enforce Sanctuary compliance and document Quality-of-service, we modify the Sanctuary voting process to do the following:  Currently sanctuaries vote for each other (for proof-of-service) to be paid when they prove another node is online (thats how masternode winners gets populated, the vote count next to the sanc shows the winners for that block).  We modify this process to pull actual document hashes from the chain (from leased docs), and we verify N (maybe 10) documents actually exist on the target sanc (by checking the merkle-dag tree on the foreign sanc using IPFS) and then we vote for payment.  Any sanc that fails even one merkle-dag check means we do not vote for that sanc for payment - meaning it should fall off the payment list if its either not running IPFS or not maintaing a directory.

It would be interesting to evaluate how much benefit this would provide biblepay.



  • togoshigekata
  • Hero Member

    • 527


    • 31
    • September 01, 2017, 10:21:10 AM
    • USA
    more
Ive updated, cleaned and reindexed my testnet server, v1.1.4.7

Code: [Select]
getblockhash 53960
fe0857f5************c1b13f8

Old notes on setting up Testnet Masternode:
https://forum.biblepay.org/index.php?topic=190.msg3701#msg3701

Ive installed ipfs in /home and have the daemon running

Masternode says PRE-ENABLED state, but I just started it again anyways,
"masternode list" shows all other masternodes as NEW_START_REQUIRED?

UPDATE: Masternode ENABLED now

Do we need multiple masternodes enabled to test?

===

Please test this gateway with a file uploaded outside of biblepay into IPFS:
http://ipfs.biblepay.org:8080/ipfs/QmPVMkWe7976YH22quBotbrDMV9tP4qCz9P5tndveKdeGs/hi.txt

Code: [Select]
This site can’t be reached
ipfs.biblepay.org took too long to respond.
Search Google for ipfs biblepay org 8080
ERR_CONNECTION_TIMED_OUT
« Last Edit: August 28, 2018, 08:53:51 PM by togoshigekata »


  • sunk818
  • Global Moderator

    • 521


    • 36
    • April 24, 2018, 02:02:20 PM
    more

So, if sender & recipient can view attachment only... is this like an extension of signed messages? Does that mean public content will be hosted via IPFS but not required to be peers by BiblePay sanctuaries? M
aking attachments only visible to sender & recipient is very low utility and limited use case don't you think?

IPFS handles illegal content by blocking the hash. I think people will use attachment feature more if content has option to be public. Maybe a checkbox to opt-in making attachment private & encrypted, so only sender & recipient can view. I think if we have issues with illegal content due to higher adoption, this is a good issue to have and can be dealt with if we ever cross that bridge. For now, getting people to join BBP due to innovative feature is important for BBP's survival...

I can't reach the site either, but I was able to see your hi.txt containing hello by using ipfs directly.

Quote
C:\>ipfs ls /ipfs/QmPVMkWe7976YH22quBotbrDMV9tP4qCz9P5tndveKdeGs/
QmSkYzY65dGXo8q6kjrsj1erH4bLZmyQoHDd8wwoAKpG8V 15 hi.txt

C:\>ipfs cat /ipfs/QmPVMkWe7976YH22quBotbrDMV9tP4qCz9P5tndveKdeGs/hi.txt
hello
« Last Edit: August 28, 2018, 08:38:11 PM by sunk818 »
BH6oxjLkyz3z8FYpvU3ZR7PTZ31Xt9DkXZ