Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rob Andrews

Pages: 1 ... 186 187 188 189 190 191 192 [193] 194 195 196 197 198 199 200 ... 264
2881
I works!  ;D Thanks Rob.

This is my home IPFS:
http://84.29.208.33:8080/ipfs/QmPVMkWe7976YH22quBotbrDMV9tP4qCz9P5tndveKdeGs/hi.txt

And this is the AWS IPFS:
http://18.222.48.73:8080/ipfs/QmPVMkWe7976YH22quBotbrDMV9tP4qCz9P5tndveKdeGs/hi.txt

Question: I'm accessing AWS via Putty. But if I close my putty session, I think that will also terminate the IPFS, or am I mistaken in this? I tried my home IPFS, but that one terminates when I close the window.

There are some commands that let you fork a command to run in bash (in its own session), but the better way I think is to add the 'ipfs daemon' command to the machine startup script - I believe if you : nano /etc/rc.local and add it in there somewhere before the 'exit 0' line.


2882
Okay, got the AWS Sanc up an running. Same issue with the IPFS :(

Copy-past of firewall, IPFS and telnet attempt:
Code: [Select]
ubuntu@ip-172-31-37-125:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
8080/tcp                   ALLOW       Anywhere
22/tcp                     LIMIT       Anywhere
40000/tcp                  ALLOW       Anywhere
40001/tcp                  ALLOW       Anywhere
9998/tcp                   ALLOW       Anywhere
8080/tcp (v6)              ALLOW       Anywhere (v6)
22/tcp (v6)                LIMIT       Anywhere (v6)
40000/tcp (v6)             ALLOW       Anywhere (v6)
40001/tcp (v6)             ALLOW       Anywhere (v6)
9998/tcp (v6)              ALLOW       Anywhere (v6)

ubuntu@ip-172-31-37-125:~$ ipfs daemon
Initializing daemon...
Successfully raised file descriptor limit to 2048.
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/172.31.37.125/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit/ipfs/QmS25G9JVn9SJ7HpmK5JKehQBSU4LAT8YY2Fkb8RT68UgW
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip4/172.31.37.125/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
Error: serveHTTPGateway: manet.Listen(/ip4/18.222.48.73/tcp/8080) failed: listen tcp4 18.222.48.73:8080: bind: cannot assign requested address
ubuntu@ip-172-31-37-125:~$ telnet localhost 8080
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

I don't understand why, when I telnet the localhost port, I get a 'connection refused' error. Nothing is running on there except the wallet.

 >:(

I see the problem.  This should fix the home issue also.  In vultr, the public ip of the node is the actual bound ip of the node - so the firewall rules are simple:  just listen on the public internet IP.

On the home machine, its behind a router, and you have your port port forwarded to the machines LAN ip.  On AWS, I see this is the same; you are behind a router.  Your machine IP is 172.31.37.125 and your sanc ip is 18.222.48.73.  So what we need to do is listen on:  LAN IP : 8080 (not external ip 8080) and then forward the traffic To the machine on 8080.  So just try binding your 8080 to your LAN IP.    (IE On your AWS instance, change the binding for the gateway to :      172.31.37.125:8080 and see if it comes up)....

Ill try this on my home IPFS also later when I can reboot the machine.


NOTE TO ALL TESTERS:
Im working on a new version so we can test the Non-biblepay-team percentage feature, so we will need to all upgrade testnet.


2883
This is my boincinfo. I've joined team Gridcoin and don't seem to be receiving any payments :)

Code: [Select]
12:18:30

exec getboincinfo


12:18:33

{
  "Command": "getboincinfo",
  "CPID": "c852da1a620ad630b70c8ec1ccdee366",
  "Address": "yb3AGeCR9xDge8chVwi6TuDtxuMy7w4DD7",
  "CPIDS": "c852da1a620ad630b70c8ec1ccdee366;",
  "CPID-Age (hours)": 426706,
  "NextSuperblockHeight": 56836,
  "NextSuperblockBudget": 542174,
  "c852da1a620ad630b70c8ec1ccdee366_ADDRESS": "yb3AGeCR9xDge8chVwi6TuDtxuMy7w4DD7",
  "c852da1a620ad630b70c8ec1ccdee366_RAC": 100.02,
  "c852da1a620ad630b70c8ec1ccdee366_TEAM": 12575,
  "c852da1a620ad630b70c8ec1ccdee366_WCGRAC": 0,
  "c852da1a620ad630b70c8ec1ccdee366_TaskWeight": 100,
  "c852da1a620ad630b70c8ec1ccdee366_UTXOWeight": 423,
  "Total_RAC": 100.02,
  "Total Payments (One Day)": 9424,
  "Total Payments (One Week)": 28416,
  "Total Budget (One Day)": 1626522,
  "Total Budget (One Week)": 2168696,
  "Superblock Count (One Week)": 93,
  "Superblock Hit Count (One Week)": 5,
  "Superblock List": "56539,56143,56044,55747,47629",
  "Last Superblock Height": 56737,
  "Last Superblock Budget": 542174,
  "Last Superblock Payment": -1,
  "Magnitude (One-Day)": 5.793957905272723,
  "Magnitude (One-Week)": 13.10280463467448
}

Excellent, double checking your info on my testnet sanc3, I believe it is working properly - as far as the team blacklist.  I received my boinc reward on sanc3 properly also (being in team biblepay).  Now for sanity, lets have you switch from Gridcoin to a random team please?  Lets see if payments start? 

Btw Jaap, did adding an attachment to a transaction work for you properly and you can view it on the gateway URL?



2884
Archived Proposals / September Recurring orphanage premiums due - Compassion
« on: September 05, 2018, 08:09:18 AM »
Each month we sponsor approximately 309 children at compassion.com.

Rob, the lead dev pays the expense and keeps a copy of the receipt. 

The expenses can be viewed by navigating to Accountability.biblepay.org | Expenses and viewing the PDF.


All funds raised by this endeavor are spent at compassion.com, with any excess going to prepayments for the future (the prepaid amount is stored at compassion in the biblepay.org account).

To see the amounts we raised in the past by selling BBP for bitcoin see this page:
 See accountability.biblepay.org | Orphans | Orphan Fundraisers.  You can audit the total by finding the sum of all fundraisers.


I am requesting  7,000,000 bbp (which is 25% of what we need.).

Due to our low price we will need to terminate approximately half of the sponsorships later this month.
They will be covered by Compassions continued-sponsor-insurance program.




2885
I can recommend HostBRZ - $12/yr: https://lowendbox.com/blog/hostbrz-vps-shared-reseller-hosting-from-2-year/

Vultr too pricey especially just for testnet.

25GB should be enough for BBP blockchain (production) and IPFS storage.


I tried port forwarding at home, but masternode status still doesn't like it... so I'll attempt a VPS as well. I've got a few I can add bbp testnet on to.

Id be wary to recommend anything other than ubuntu64 on vultr which is only $5 per month - but if you guys have actual experience with it maybe its good.


2886
Yes :)

Still can't get IPFS to work though >:(

And about the feature in general: the original reason for it's conception is to use it for DAHF right? And the ability  for other users to store data is a - welcome - side-effect, right?

The main reason for implementing this short-term is to add value to the coin, but we really should explain to all the users how this is also one of the building blocks for DAHF. At least, I hope to use this angle for marketing.

Or am I mistaken in this?
Hi Jaap,
It might be easier - if you already rent one node somewhere - to get testnet sanc and ipfs running there first, then circle back to the house and try googling the issue as maybe the cloud vps will be revealing.  Id try to offer assistance, but IPFS is not working for me at home either, and since our sancs require a public IP anyway with watchman, to me its more straightforward to recommend you run testnet side by side a running prod sanc with ipfs.  (unless you dont have a cloud vps).

Anyway, Yes, originally IPFS was added to solve the block-sync issue to ensure DAHF could be decentralized properly.  However, this turned into a pretty strong value-add feature for our coin.  We can potentially say:  We have side-chain document storage, with 200* redundancy.  (The ipfs merkle dag *is* a side chain of blocks and a filehash *is* related to one of our txids on-chain).  Thats a pretty strong feature.  If we can guarantee that the document is available for the life of the lease, that is a great value add for biblepay.  We rent document storage for a fee.  I added the feature last night that quotes and charges:  When you make an attachment, we quote a price and it appears in the confirm fee dialog as a separate PODS fee now.  The fee is tithed to the orphan foundation.  Sancs only poll and verify Paid for non-expired docs in the next version.

So I think from a PR perspective, we can say we are offering PODS (proof-of-document-storage) and side-chain file storage.  We should not try to claim we offer hard drive space as I feel thats too competetive.  And yes we do need to ensure we have at least 1 gig of space for DAHF, as I feel we will have the ability to sync financial blocks in the future.


2887
I was speaking from an average consumer that'd not looking to host files that may be deleted or censored. That seems like an edge case unlikely to happen to 99% of common users. For all intents and purposes, I'm not concerned as consumer how a file is distributed (centralized or decentralized). I just care that the URL works when I need access to it.

Is the marketing plan to encourage uploads that is likely to be censored elsewhere? That seems very risky and controversial. If you're expecting $5/mo premium, then I suppose that has to be the group of people we target? If files are on the ipfs.biblepay.org:8080, does that make files censorship proof? Or biblepay would be ultimate authority on what lives and dies on IPFS?

Why even discuss it if we dont agree on "Im not concerned as a consumer how a file is distributed (centralized or not)".  Because in this case, if you aren't concerned that we are working on blockchain technology, then why discuss it.  As that is a night and day difference.

I feel we are making a mistake to not encrypt the files.  No, they will not be censored or deleted if they are encrypted.  If they are not encrypted, they could be censored, deleted, taken down by government request, etc.

The fee is currently set at .0002 bbp per K of filesize uploaded.  We can potentially lower it after we know the system works properly, but it would be doubtful that it should be lowered so low that it fills up 10 gigs of each of our sanc drives.  But I would lower it incrementally so that we receive some moderate usage by the network.

2888
You show as UP on my nodes.  Let me see why I dont show as UP on your node.

Im *.*.88.12, and the problem was I was running watchman in PROD mode, update to testnet mode - now I see myself as ENABLED, Jaap do you see me as enabled now?


2889
84.29.208.33

You show as UP on my nodes.  Let me see why I dont show as UP on your node.


2890
I hope you're not realistically thinking $5/mo is appropriate fee because Google Drive is $1.99/mo for 100GB of storage. It is a commodity service so realistically, you should expect pennies to store attachments or not even charge at all. $5/mo is a pipe dream is extremely unrealistic.

Whatever fee you collect and have it go to orphan fund is a good idea. Every little bit helps and hopefully the service will scale over time.

Still having some issues with bigger attachments. Tried a 45MB video but I don't see it in the transaction.

Its not smart to compare apples to oranges; we're renting files on a blockchain, not space on a centralized server.  Not sure why you would consider a decentralized chain less valuable than a centralized company who can delete your account at any time, or decide what news is important for us. 

Nah, it shouldnt necessarily be pennies.  It takes what, 20% of a sanctuary to run ipfs?  With that logic why run ipfs at all.  (I wouldnt participate if I was only getting $1 total per month for hosting ipfs).

Anyway we are storing 250 copies of a file while the cloud servers are using RAID or storing across 20 machines for durability, so we are also doing 10* the work per file.


2891
Hmmm... Can't get it to work.

When I use the localhost ip the deamon starts, when I use the external Ip it doesn't...

So whats your IP Jaap, Id like to see if your sanc is enabled on my node?


2892
Hmmm...

This is strange.... I'll just post the entire startup proces here (and delete it later).
The firewall on that rig is disabled and the port was already forwarded to that rig in my router.

When I telnet it (making sure the daemon is off) it says 'telnet: Unable to connect to remote host: Connection refused' so I guess there is nothing else running on that port.


Code: [Select]
jaap@jaap-HP-Pavilion-dm1-Notebook-PC:~/.ipfs$ ipfs daemon
Initializing daemon...
Successfully raised file descriptor limit to 2048.
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/192.168.1.149/tcp/4001
Swarm listening on /ip4/192.168.1.183/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /ip6/fdbe:33bf:560:0:1703:2523:7b47:8758/tcp/4001
Swarm listening on /ip6/fdbe:33bf:560:0:3868:73f5:7c0f:da76/tcp/4001
Swarm listening on /ip6/fdbe:33bf:560:0:4366:95b0:9e9c:d91d/tcp/4001
Swarm listening on /ip6/fdbe:33bf:560:0:8c52:a032:7b4a:f626/tcp/4001
Swarm listening on /ip6/fdbe:33bf:560::25e/tcp/4001
Swarm listening on /ip6/fdbe:33bf:560::595/tcp/4001
Swarm listening on /p2p-circuit/ipfs/QmeUCRZ8edAvqojUZgWBsQ69XaSdWozhwHK39UMrskfYky
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip4/192.168.1.149/tcp/4001
Swarm announcing /ip4/192.168.1.183/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
Swarm announcing /ip6/fdbe:33bf:560:0:1703:2523:7b47:8758/tcp/4001
Swarm announcing /ip6/fdbe:33bf:560:0:3868:73f5:7c0f:da76/tcp/4001
Swarm announcing /ip6/fdbe:33bf:560:0:4366:95b0:9e9c:d91d/tcp/4001
Swarm announcing /ip6/fdbe:33bf:560:0:8c52:a032:7b4a:f626/tcp/4001
Swarm announcing /ip6/fdbe:33bf:560::25e/tcp/4001
Swarm announcing /ip6/fdbe:33bf:560::595/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
Error: serveHTTPGateway: manet.Listen(/ip4/84.29.208.33/tcp/8080) failed: listen tcp4 84.29.208.33:8080: bind: cannot assign requested address
Received interrupt signal, shutting down...

The adjusted line in my config is:
Code: [Select]
"Gateway": "/ip4/84.29.208.33/tcp/8080"
The rule on my router is:
Code: [Select]
8080 test
IPv4-TCP, UDP
From any host in wan
Via any router IP at port 8080
IP 192.168.1.149, port 8080 in lan

I triple-checked the external-ip.

Btw, I don't think I had problems running Sanctuaries in testnet this way before. The necessary ports are open, and the external IP almost never changes (only sometimes after a reset of the providers modem). My Sanctuary is:
Code: [Select]
71c44d1cc7e3f29aac6b0c8e9ade3c43cc79da3d0c22f183439d8e440c6a7d3e
I will try and restart the rig. See if that helps.
EDIT: restarting didn't help :(

Hi Jaap,

Looking at my vultr node when I bring up ipfs daemon, I see in my case, the line that says "swarm listening on" with the port of 4001:  Mine is listening on the External IP, looks like you have two adapters, and it binds one to one internal ip and another to another internal IP on yours.  Could you try binding 4001 to your external IP (I think you have to edit the config to change that), and also point the 4001 port to that machine in the firewall then restart the daemon and see if it changes the behavior of 8080.

Btw, on your Sanc, does it actually flip over to ENABLED eventually?  Edit:  Your sanc address should start with a "y", I cant see your status on my node.

EDIT 2:  Btw Jaap its really easy to run a sanc side-by-side your running prod sanc - do you have one on vultr?  If you have a lot of problems, it might be easier to do that.





2893
Trying to figure out how to set up masternode for the first time. Getting close I hope.

Anyway, uploaded 21MB video. Plays right away on Chrome on ipfs.biblepay.org ... ipfs.io was initially spinning but retried after 4 min and the video played finally.

Is the default for Open Attachment ipfs.io or ipfs.biblepay.org ? I'm getting better results with ipfs.biblepay.org on the immediate request.

http://ipfs.biblepay.org:8080/ipfs/QmdMBtPQvuqPyCJgnczh5RcVeS5mi5UJydLzeVvcGcccd4

Thats great!  Yeah, maybe we should make the default open behavior biblepay.org, sounds good.
I had that pausing issue with ipfs.io also - I can imagine they are probably being pounded by tons of 'free' traffic from every direction.

So today Im going to look into adding a fee to the attachment.  For now its just basically a fee per K being attached, and I think we should start by enforcing that it goes to the orphan foundation otherwise the transaction commit fails.  I will also add a process that pins docs that are legitimate and
 have paid PODS fees. 





2894
Thanks! I looked into it and the path is correct now. I adjusted the config and tried to start the daemon. Got this error message:

Code: [Select]
Error: serveHTTPGateway: manet.Listen(/ip4/MYIP/tcp/8080) failed: listen tcp4 MYIP:8080: bind: cannot assign requested address
Also, I have joined team Gridcoin (teamid=12575) and have connected my wallet to Rosetta@home :)
Jaap, sounds like you are close.
This is a guess, but could you double check the IP and format you typed into the config?  I would first go to your host, and check your public IP address, and make sure it matches.  Also you can type 'ipfs daemon' (after stopping the daemon) and check to see the lines it prints out that it is binding your IP address to other ports; write down the IP that is the public one- see that it matches your host (is your host vultr?) if it does you may just have an error on your gateway entry; it may be case sensitive also, compare the original entry from another node before changing it to the new entry?

One other thing to see: maybe you are already running a service on 8080.  Try to stop the ipfs daemon first, then type 'telnet localhost 8080', see if it replies.  If it does you are running something else on the box, maybe another type of web server.  You would have to stop that other thing first, then start the 'ipfs daemon'.


EDIT:  I just saw your post above that you run the linux rig hot at home; thats probably the issue; if running from the house, you would need to open up the firewall port 8080 and forward it to the linux rig, then it should bind the port.  One side issue with running at home:  check to see if your sanc says ENABLED in our list - the new PODS enforcer requires a sanc to be ENABLED to check its PODS quality.




2895
So far so good, at this point all please upgrade to 1.1.4.8, set up a sanc, verify we are synced, and lets regroup when the sancs say "ENABLED" (we must have some enabled to test ipfs).

I just brought two up, one is enabled now and one is enabling.

The sporks are ready so for now we can use Togo's account as our non biblepay team guinea pig, my CPID as a biblepay guinea pig and we still need a volunteer to set the team as Gridcoin to test the blacklist.

Please set up your IPFS gateway and test with a file from the public IP (as shown in the example above) and then we will regroup.



Pages: 1 ... 186 187 188 189 190 191 192 [193] 194 195 196 197 198 199 200 ... 264