Messages

2911

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.

2912

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

« on: August 29, 2018, 04:58:03 PM »

1MAG= 10 000 RAC=1 dedicated server= 20 new accounts= free mining w/staking

And 20 CPIDS and 20 BoincStats accounts to check and 20 biblepay addresses and 20 wallets, right ?  Thats a lot of usernames and passwords to maintain... 

2913

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

« on: August 29, 2018, 04:56:23 PM »

Fair enough.   With POBH being lower (been averaging 500kh-1mh) we should retain some security.

Hmm interesting thought,  I could see some folks abusing it..  If you're looking for pure profit and have a mining shed of 100 machines one time boinc account creation is no big deal.

Currently mag <1 is somewhere between 8-10k RAC

Though if we get flooded with new researchers,  then it could increase drastically(but less payout per)

Just to clarify, I would not propose to do something with Low security.  I feel DGW + the signed cpid + prior 2 or 3 rule is very high security.  I took a look at the code, and I think we can keep our current prod rule (requiring cpid to have not solved the N-1 through N-4).  The main change is to remove the rule where we require the cpid to be in a superblock with a payment; thats not only the biggest hassle for them but the biggest fork risk.

I updated the proposal to consider a RAC threshhold < 15000 to be our zero UTXO  requirement (IE we moved to a rac threshhold instead of magnitude based on Capulo's suggestion).

2914

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

« on: August 29, 2018, 04:32:48 PM »

sunk Remove the UTXO stake requirement for magnitudes less than ONE ... yes i can make 100 new machines for free= super,i agree 

Naaaa, its not that easy to maintain 100 boinc accounts cpids.  So yes, we thought of that already.    Those boinc guys dont like having multiple cpids; what would be the use of having stats??

Its to prevent a boinc superuser who is not on our team yet from roaming in and taking over the superblock budget. 

2915

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

« on: August 29, 2018, 04:31:29 PM »

I'm on the fence about the team removal,  I do see benefits (now folks could double-dip mining on gridcoin + bbp for example..  Definately would open more people to the coin)

As for the 4-block heat-mining cpid restrictions...  This I have some concerns over, perhaps lower it to 2 instead?

During the monthly superblock issues we were having,  heat mining was impacted drastically by allowing multiple consecutive winners.

Yes, I agree with you - to clarify, Im all for making the code fork-free, and as long as we can do this in a hard deterministic way (IE check for duplicate CPID in block-1 , Im for keeping that part in).  Ill double check this asap.  So to clarify, you can heat mine with a signed CPID that has RAC > 100, but does not need to be in prior superblock, but - this cpid could not have solved the prior block (pending my analysis for fork prevention).

2916

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

« on: August 29, 2018, 02:48:27 PM »

All,

  We have 329 orphans sitting at risk currently with a questionable future.  I not only want to avoid attrition, I want to see growth! 

So heres an idea.  I really think we need to consider removing all the roadblocks inside Biblepay (IE Opening the Floodgates) for cancer mining.  We can consider doing this by:  Removing the Boinc team requirement (being the first cryptocurrency to not require a team for boinc), and making it easier to heat-mine.  (IE doing away with the last 4 block rule).  (We can leave in the signed by CPID rule as a lateral move preserving heat-mining security).

I feel with this change, we can test the theory that more miners = more adoption = higher price = more monthly orphan sponsorships.

Also, as Noxpost suggested, I dont see why we cant write our own boincstats report (as we will still have records of our Biblepay participating CPIDs, RAC, TotalRAC etc).  So we really only lose the "BiblePay BOINC Team" statistics in boincstats, but instead we have our own stats page.  Maybe that internal stats website is something T-Mike would like to take on for us?

So, as you can see I'm pretty zealous for success here, and want us to make a comeback.  Therefore I believe its in our best interests to vote on this change.

Proposed Changes:

- Remove Boinc Team Requirement for users participating in BiblePay PODC (this compensates users for Rosetta or World Community Grid on ANY team)
- Refactor Heat Mining Block acceptor to help minimize the possibility of forks
- Still require signed cpid per block, and CPID must not be within 3 solved blocks
- Remove the rule requiring CPID to be in the last superblock
- Work with a team member to help create our own stats report for a website and/or the pool
- Leave in UTXO requirement for Boinc Miners

Desired Outcome:

- A new boinc user who is crunching for XYZ discovers they can be compensated for Rosetta cancer mining through Biblepay.
 The new user loads our wallet, syncs, and associates their XYZ cpid with our wallet. 
(The new user still must have a required balance shown in exec totalrac to PODC mine).

- The user is able to heat mine with the signed cpid immediately, as long as the CPID has RAC > 100.

This removes most of the strange pool errors in pool.biblepay.org and purepool.


One notion is that in general, I assume BOINC users to have enough disposable income to afford expensive computers for volunteer computing, therefore I come to the conclusion they may become biblepay investors through this process.

And, to counter the theory that we are "giving away free money", consider the fact that the ones who do not become investors will sell off the coins cheap on the market and make us more rare.  So imo, this is an economic decision worth considering.

If the idea is a success, all credit to Jesus.

2917

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

« on: August 29, 2018, 02:13:32 PM »

ok just sent another transaction,
in transaction details I see green "IPFS Document:" hyperlink "Navigate to document Q*"
Open Attachment button works now, it opened up the image in Firefox

https://ipfs.io/ipfs/QmcbKYZRFGYsmBiEhqjQ4J7uoGY5DSHqs5uQg7fqsW7J1r

1 confirmation so far

Its working I see it!

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

So our gateway is working also, good.

2918

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

« on: August 29, 2018, 02:11:43 PM »

need i BBP for testing this?

yfhc5FdNSyAYyB4Fx4aJ2x4KoXiGuXxhyH

A little bit yes, so you can send some tx to yourself.

The purpose of attaching an IPFS document to a transaction is to make biblepay useful without bloating the blockchain (with the bytes of the document).

Sent 200K (as I only have 1 mil on my dev machine right now).

2919

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

« on: August 29, 2018, 12:19:31 PM »

Im unable to duplicate it, but I believe the confusion stemmed from the Attached File field being missing the first time I was using the Send tab after upgrading, and then it showed up on the Add Recipient. It shows up every time now.

I also had no idea there was a multiple recipient feature LOL

=

When I click "Open Attachment", no action occurs,
Im using Lubuntu with just Firefox installed

I composed the link above as a guess

Transaction ID: 51bf312343f303c1ca9234f2515b8947738a0303fd8742b4b7d4aa377620cbf0-000

XML:
{PACK} {MT}MESSAGE{/MT} {MK}OUT_TX{/MK} {MV}  {/MV} {/PACK} {PACK} {MT}ATTACHMENT{/MT} {MK}OUT_TX{/MK}{MK}{/MV}{ipfshash}{/ipfsash}{/PACK} ...

Im unable to copy paste from Vultr Console / Lubuntu (nor know how to change resolution)
(What Linux GUIs do you guys use in Testnet?)

Oh I think I see whats going on; OK so on the copy-paste.  Im using debian 7-64 on my dev machine and it has copy-paste, but my vultr nodes do not, but you can get around this by doing a 'showblock blocknumber' then 'getrawtransaction txid' after you send it from your VM (if you want to scrape it from your windows box).  Yeah I dont know of a way to get copy-paste working in vultr. 

So that tx you pasted above looks like nothing worked on it; thats OK, I think we need to start over.
(I can see because the ipfshash is empty above in the XML).

So just try attaching a file from the beginning, and ensure the attachment textbox is populated and no error results after sending.
Then double click the transaction  from the transaction list and see if the Link in it is populated (in blue).  If its not, that explains why the Open Attachment button does not work.

Then once that opens for you, then from another machine try to get the txid then we will pull the data out of it and Ill try it from the gateway address to see if its replicating.

2920

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

« on: August 29, 2018, 11:04:19 AM »

I had to upgrade my server, was freezing up, 100% disk usage, couldnt pinpoint the issue, didnt see anything big in ~/.biblepaycore hmmm

===

I clicked the Add Recipient button in the Send tab,
It opened a 2nd set of duplicate inputs with an extra Attached File field
I had already filled out the first set of inputs, and filled 2nd with same info,
I clicked send and it said I couldnt have the same address in both,
I got confused b/c I wasnt sure why I needed 2 different addresses, put in a diff one and sent

I think this is the correct link format? (address file attached to and filename):
http://ipfs.biblepay.org:8080/ipfs/yLoLPque5vWgYJLmZjYJzicYPDphUP2HdT/BiblePay_Logo_Transparent_3000x1000.png

Code: [Select]

invalid ipfs path: selected encoding not supported
Transaction only has 1 confirmation so far

So no you dont have to click Add recipient to the send transaction.  You can just click Send, and click Add File (not add recipient).

Yeah the UI wont let you send two transactions to the same person; you would have to send one to the foundation, one to yourself for example (but , you only need to send one transaction, not two so thats moot point).

The link you pasted seems like something you made up, could you paste the one from the double click of the transaction?  It should end in a hash.

2921

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

« on: August 29, 2018, 09:52:19 AM »

Ok good, and Sun was asking if this gateway link could be https, Yes, I already bought a certificate but for a long drawn out technical reason, the IPFS is not working in HTTPS mode yet (I think those guys have it in a tunnel over there) so eventually Yes, we will crack this if this gets to prod.  Its not one of those easy things to turn on.

So do we have any other docs to click on yet?

Heres one I sent to myself this morning:

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

2922

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

« on: August 29, 2018, 09:45:51 AM »

Tested again, I see "hello"!

Ok good, and Sun was asking if this gateway link could be https, Yes, I already bought a certificate but for a long drawn out technical reason, the IPFS is not working in HTTPS mode yet (I think those guys have it in a tunnel over there) so eventually Yes, we will crack this if this gets to prod.  Its not one of those easy things to turn on.

So do we have any other docs to click on yet?

2923

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

« on: August 29, 2018, 08:12:45 AM »

win 1147- testnet ... peerlist is empty and i cant synching

I see the problem; node.biblepay.org is not resolving.  I made a couple DNS changes.
It should resolve itself in an hour.

In the mean time try from the RPC:
addnode dns2.biblepay.org
addnode testnet.biblepay.org

And see if it comes up.

This should not require a config change for new users in one hour.

2924

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

« on: August 29, 2018, 07:51:03 AM »

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? Making 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.

I do think you make very good points, although before I delve into the nuances of this, I checked out your link for 'blocking the hash' at ipfs and came to a different conclusion.  I believe IPFS' position on this is not that they will create a blacklist, nor a whilelist, nor a blocked hash blacklist, but instead that IPFS is a protocol and not a store.  Their position is that it is the users responsibility who owns the hardware to determine if they should host a hash.  Meaning that if Im joe six pack, I should be smart enough to not navigate to an x-rated link, but if I do, its up to me to delete that file quickly from my store as I dont want it hosted.

The IPFS architecture is set in a way that if you pull a file from (the IPFS decentralized host network) and do not delete it from your IPFS local store, you are now hosting it-as its now in your repo.  If you dont want copyrighted moves hosted you should not "get" them in the first place.

So my argument here is biblepay is not capable of policing what we store.

Before delving into this, my position by default is that we should not provide a service where one can upload a virus (imagine Not-Petya), or Porn, or an unreleased Movie, into biblepays store (of sancs) unencrypted, in a way where the world at large can download these three things from an association from one of our blocks transactions.  It is simply unresponsible for us to take the position that "oh maybe it wont happen", I feel like we have to be vigilant and set a precedent of quality here so the world knows we are Christian (IE our light is shining).

I do understand your view that what use or utility are you if every file is encrypted?  You want me to pay 5000 bbp to host my web site files with you for 6 months, but you dont even let me view them without a decryption key?  LOL.  On the other end of the spectrum we have a real estate lease, where they want to put the PDF in and its just one document for a business transaction, that person may not mind transmitting the key via email to the customer.  But I do realize, the revenue cut would be dramatic.

So, my initial design idea to tackle this would be to require encryption, but support an on-the-fly decryption if the consumer has the key.  For example if the gateway supported this feature
ipfs.io/ipfs/hash/myfile.pdf?key=blah

Then the file is decrypted and served using the key blah.  I realize it looks pretty lame and weak, but it technically takes the responsibility off of biblepay (as to what we are hosting) and allows the file to be useful in a website etc.

2925

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

« on: August 29, 2018, 07:39:00 AM »

Wow, it actually works pretty good.
Windows 10 64-bit.
> Test attaching a document to a new QT Send Transaction
Looks like c:\ is prefixed to the URL.
For example, if I want to upload a file located in --
C:\temp\GatewayArchNP_EN-US13744808809_1366x768.jpg , QT actually looks for
c:\c:\temp/GatewayArchNP_EN-US13744808809_1366x768.jpg
When I attach file, the URL is file:///C:/temp/GatewayArchNP_EN-US13744808809_1366x768.jpg

QT wallet responds with IPFS Attachment Failed. IPFS File not found.
If I remove c:/ then the send button works: file:///temp/GatewayArchNP_EN-US13744808809_1366x768.jpg
I don't know code, but found the error message in src/rpcblockchain.cpp , around line 6400 , something about sPath...
Also, if we if attach file from non C: drive, what will happen. Will need to test again (e.g. attachment is from e: drive)
~~~

I uploaded a 21MB video. BiblePay took the file, but there was no progress indicator.
> Test double clicking the transaction list and viewing the attached IPFS file hash
Works with no checkboxes ticked on.

Is there a file size limit or file type restriction? I tried uploading 21MB video. It uploaded okay it seems, but doesn't show up in Transaction Details.

If after ipfs.exe uploads the file, what happens to the file if I decide to not send the transaction. Is the file deleted on the server? Worried about DDoS type of issue where files are uploaded, but no transaction sent.

> Test Opening the IPFS document link

IPFS Document: Navigate to document QmanVaVYE1phtQeQqp23SZk6FM5nWBRu2KD9d6eaGZHV1P 
Transaction ID: ce930cf4b4794964ca69129c7ef51ba99601ba588f055b717036645c34cf2869-000

IPFS Document: Navigate to document QmcUr2WpiEg6ZWwTdHRDfxNVZzwpns7pdoYSQyt46wMHyX 
Transaction ID: 45d826b3e6f24da2dd6379fedf10413dc9dab9132b0b1c390110fe6a7667861e-000

* Make blue link clickable as well under Transaction Details?
* Make a newline so Transaction ID is in its own line after IPFS document
* Maybe instead of blue checkmark icon on left column (for confirmed), have a clickable paper clip icon to indicate there is attachment with transaction?

> Test the fee charged for BiblePay storage

What fee?> Assess exact root cause of IPFS instability; IPFS.io links are down right now, but ipfs.biblepay.org worked. Are you going to make ipfs.biblepay.org HTTPS?

Good morning all...

"Looks like c:\ is prefixed to the URL."
So on this issue, during programming I was testing against linux and hadn't got into the quirks on windows yet.  So it looks like QT changes backslash to forward slash and prepends with the "file:\\\".  The C, D, E drive prefix is not a problem (thats there because the file picker does support picking from various hard drives).  Really the whole problem can be eliminted in this version if you do this:  After picking the file, remove the "file:\\\" (note the three slashes here).  Thats all the code needs to do on win & linux to get it to work.   YAY!

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

As far a limit I have it set to 90 Megs right now.  Its not a limit in IPFS.  So we can go higher.
As far as doing whats called 'garbage collection', this is the activity of deleting files that users didnt pay for, I did think of that, and I think we can handle that in this way:  The sancs maintain a directory of files that are paid for.  The rest get garbage collected.

As far as clicking on the link to navigate to the doc from inside the view window:  I originally planned this to work-but due to a limitation in QT the textedit wont let you click external links  (Great) meaning in order to get it to work we have to upgrade the viewport to be like our prayer view page (I think its a rich edit box) and I dont feel like breaking anything yet, so thats why I added the Open Attachment button, .    So yes this needs to be on our enhancement list. (You can copy the link btw and manually open it).

Newline after txid: OK will do

Paperclip idea to show attachment is preset:  Good idea

So Ill make a new release today with the fix to the file picker, but guys, now that you know the workaround this should not be a showstopper.