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 ... 178 179 180 181 182 183 184 [185] 186 187 188 189 190 191 192 ... 263
2761
TestNet Discussion Archive / Re: Testnet - Test Proof of Giving
« on: December 08, 2018, 10:11:06 AM »
So initial thoughts:

Setup is ok,  I don't see auto-tithes yet (sent manual to be included in pool).


Currently a 2nd "new" wallet is unable to tithe, "Unable to locate coins older than minimum_tithe_coin_age"
With the most of the current tiers empty, I don't see the "plug and play" idea. 

"pog_difficulty": 286.012457168394,
  "pog_min_coin_age": 0.26,
  "pog_min_coin_amount": 110,
  "pog_max_tithe_amount": 298.7

The new wallet is failing the .26,   I think we need a more clear display (.26 day = 6.24 hours old)

I would also add a suggestion for the "coin control" window, adding coin age there would be helpful for those curious.

On the plug & play, its still plug & play because you receive your coins from the faucet (or buy some) and you mine as a heat miner until you have coin-age, and when they age the POG background thread will auto tithe for you.  (We have to have this difficulty to prevent gaming the system).

I increased auto-tithe freq in testnet to 1 hour last night, need to see if its doing it.

So we need a way to see why you cant tithe on the UI.

Btw, to see if you can tithe manually, you should type 'exec getdimensionalbalance' with the same params as 'getmininginfo' shows on the screen.  Today  I will look into automating that for the user, and think of a way to put something on the UI showing why you cant tithe right now.

EDIT: Btw, its OK if all tiers or most are empty in POG2 since they are just payment tiers.  But empty tiers mean Huge profits for pog2 miners - if they stay empty, a 100 bbp tithe = something like 40,000 bbp reward.




2762
TestNet Discussion Archive / Re: Testnet - Test Proof of Giving
« on: December 07, 2018, 04:13:48 PM »
1.1.6.2e - BiblePay - TestNet
Mandatory Upgrade for TestNet


POG2 is ready for testing!

Please, optionally set your nickname= in the config files.



PS - you should not need an addnode (testnet.biblepay.org) is compiled in the client.

PS II - We will need to bring some sanctuaries online also for later phases of testing - this is because to test all test cases, we must cover Sanc payments that have POG pool payments piggybacked in.  (IE the client has one code path for Missed sanc payments and another for Sanc payments).  Both of these have POG pool payments.  Superblocks are not as important (although we need to test them) but Im confident superblocks wont pay the POG recipients as Snat and I went through this recently for a different reason (superblocks pay the reaper only the entire heat reward).


*** WINDOWS HAS BEEN RELEASED ***


2763
TestNet Discussion Archive / Re: Testnet - Test Proof of Giving
« on: December 07, 2018, 04:11:11 PM »
Can I change your validation rules and compile a new wallet to game pog? What counter measures exist to prevent this?

TheSnat is correct.

To expand on that, you cannot.  Why?  Because if you change the validation rules by .01 bbp, the pool will not agree with the other clients and you will fork onto your own chain.  (See InductLegalTithe).


You can try to game the system as a whale though, but I just added exec bankroll, so I dont think you will get very far in that endeavor.

Its almost ready, it passed the LAN test.


2764
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 07, 2018, 03:57:09 PM »
Also, what happens to the rest of the month, if someone donates the entire monthly ceiling on the first day via PoG? Or say they donate 90% in the first day, how does difficulty play out? Does this kick the coin_age requirement up so newcomers can not participate?

What happens if you donate to the foundation (using the wallet address not PoG) for the entire ceiling?

Great questions!

So first on donating the entire monthly ceiling on the first day, what would actually happen in the market microstructure, is as the original "pig" is trying to over-tithe, since we have a tithe_max of about 300 initially per tithe, after they donate about 5K lets say, the difficulty would skyrocket to something like 32000, and that would stop them (or slow them down) because now the max_tithe is only 30, so this person would not get very far.

As far as diff dropping, in the latter half of the day the diff would drop again.

You can get around the controls and donate directly to the foundation but if the tithe is not legal, the network wallet rules will not "induct" those tithes.  IE if someone tithes 10,000 by doing a sendmoney transaction it wont even be put in the pool.

You can type exec pogpool to see the exact mechanics as we go.

EDIT: Testnet is ready.



2765
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 07, 2018, 03:51:55 PM »
https://wiki.biblepay.org/Proof-of-Giving-II

What is min_coin_amount ? I understand max_tithe_amount but is min_coin_amount the change address needs to be in order to send the max_tithe_amount?

also, you mention default proclimit = 1 . Does this mean, this can be increased?

What happens if someone has a beefy computer with 128 threads. Can they use all 128 threads to mine? How does this affect the outcome? Won't they be the likely person to win the 20% and get a piece of the 80%?

Trying to understand how this is more green than PoDC?

min_coin_amount is the minimum coin value that can be used for a tithe out of your coins.  If you go to coin control and take a look at your coins, pick one of higher value than min_coin_amount.

Change amount or change address doesnt come into play.

On genproclimit its set to 1 by default (as is now for POBH), but it can be increased if you want to be a reaper.  This is basically a solo miner with more threads.  Remember the reaper only gets 20% of the block however. 

On 128 threads, yes, except they will probably be competing against more pcs and laptops in this game (IE more exposure to the world), and also remember that its self defating to go higher in threads than 95% of your processor power (IE 20 threads probably gives you that utiliz. level).

Its more green than PODC like this:  With PODC,  We have 1 controller doing POBH per PODC user, and the equiv of 2000 (not exadurating) PCs out there doing PODC (I did the math on rac in POOM).  With POG, we have just 1 controller doing 1 thread per POG *user*, so its less energy per person, and in addition, we have some POG users only as sowers (not running as reapers).  I could have made it much greener with tier sleep levels, but I decided I wanted to error on the safe side (for anti 51% attacks) and let us go with beefier POW security so all POG users using the default genproclimit 1 actually mine right now.


2766
TestNet Discussion Archive / Re: Testnet - Test Proof of Giving
« on: December 07, 2018, 01:56:26 PM »
Regarding the coexistence of PODC + POG, where Thesnat raised the issue that PODC updates will spend the coin-age and consolidate the wallet:

I have one solution so far - this may not be the most elegant but I think it works for v1.0.  We will mark the bill denominations created in 'exec bankroll' with a suffix of ".000000001" (IE a 1milli_bbp suffix).  This suffix can be used in PODC_Update to determine if it should skip by those bills - and that saves   them for tithing.


2767
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 07, 2018, 10:59:17 AM »
I'm not asking for credit, I don't brag about my contributions to the coin.  I'm not trying to goad you into an argument.   I acknowledge your skills and have consistently done so.  I have never asked to be a clone of any existing coin, if you misread that, then here is what I was saying.  It's far easier to bring an existing system into a coin than it is to code it from scratch and  vet all the possible scenarios that exist in the logic.

The questions I asked were in my view at times exposing short falls in the system.  I still see several loopholes (and have stated a few of them) and don't agree with your assessment that we will be able to sufficiently test a brand new system as I feel we'd need a ten or more fold increase in testers which would mean nearly half our active users would need to test.   The issue is you seem to believe we will see a sudden influx of both testers and users.  If you have knowledge of a contingency waiting to come, the community would benefit from that knowledge.  However, I don't see the path to such increases.  Finally, I stand by my position that even the best programmer won't be able to test for conditions they've not thought of.

Thank you West for this and I want to say that I want to work with you closely on  identifying and mitigating any potential issues you might see in POG, for the greater good. 

I'm glad to know that you agree that this is not about either me or you being the smartest or first analyst to discover a flaw, its about us making a solid product for BiblePay, and even if it means that we discover the product not ready, so be it, I wont have my feelings hurt.

I think I have quite a different perspective of the POG vulnerabilities from the code standpoint and I think it will be very valuable for us to try to see each others perspective over in testnet.

So lets meet over there and try to come up with any attack vectors.

Currently from my standpoint I view POG as solid- I only know of one type of attack vector (the ability for a whale to cash out a sanc, create a bankroll of 300 5000' bills manually) and use that as a POG tithe edge over others, however this particular attack is going to be mitigated - the user will have a new command available (exec bankroll), empowering them to do the same thing as a feature - and diff will rise above the min_coin_amount during this whale attack making it useless until diff drops (another words by empowering the user with the same feature - no one has an edge). 

  After this - from my standpoint I cannot see any potential attack, from any scenario covering 1 wallet to multiwallets, or whales to small fish, and thats what we need to cover in testnet.

The code is not ready yet but should be ready by the evening - Ill make a post on the main forum then lets all meet there.

 

2768
TestNet Discussion Archive / Re: Testnet - Test Proof of Giving
« on: December 07, 2018, 10:34:54 AM »
Will download & install today.

I don't know that we should use the same "tithe" button,  what if someone isn't mining and just wants to donate coin?


Sorry guys - didn't mean to get everyone riled up - I didn't post it yet cause its "not quite ready"-
I'm testing this on my LAN now, (I checked it in so I can get it predeployed and preverified),
should be ready very soon, then I will make a post on the forum.

I need to add an exec bankroll option today, then I think it might be ready.

On the Tithe button, I think we can definitely add either an Are you Sure prompt, or another checkbox.  Ill add this issue to the punchlist for next week.  For now when you tithe from the UI, it tries to make it a Sower Tithe or it fails.  You can only donate to the foundation now by manually pasting the address in (if its more than the difficulty max).




2769
Archived Proposals / Re: Use Discourse as Main Forum
« on: December 07, 2018, 10:29:04 AM »
So I'm looking at this proposal, and I know the younger generation likes eye candy and wants change, and note that I'm not against change, I'm for what is technically better and also better for our PR, but whoa nelly, lets consider the implications of this step by step.

Could I potentially receive a little help in researching a couple items?

#1.  Could we investigate, out of the top 20 coins out there, which of them use discourse?  And while we are at it, could we have an opinion on the "supermajority"  - IE what is the common forum software the top 20 likes the most?   (The reason I mention this is I caution us to jump into discourse if there is a reason that the top 20 dislikes it, then we would need to find that reason first).

#2.  Since discourse is written in javascript I was a little afraid that our content would not be searchable (SEO, Google indexing, PR).  However I feel that discourse has solved this by copying the metadata out - so you can ignore answering this  - I will leave it here for intelligence processes.

#3.  This proposal itself forces an IT change, but - offers very little in exchange - please lets not start a new fight about this - let me try to explain that when it comes to business, I say these things in a succinct way to allow you to realize we are TACKLING a problem (I dont say this in a mean spirit way).  In this case this is an entire IT integration (from forum.biblepay to discourse, and a DNS change and configuration change - 3 tickets).  So lets get our stakeholder on board - TheSnat is our administrator currently.  For #3, let me ask TheSnat, could you please do some due diligence and tell us here If you like the change to Discourse (A), and (B) Would you be willing to do the conversion technologically from an IT standpoint.  If you want tell me from 1-10 how much you desire to do it now, or if you want to maybe put it off a year just let us know.  I think TheSnats weight on his reply should dictate how us Sanctuaries vote for this.   (Its not fair to put IT through 80 hours of work in reaction to one community member proposal, :) 


Thanks guys.

Rob


2770
Archived Proposals / Re: Use Togo's Bitcointalk ANN Redesign
« on: December 07, 2018, 09:49:37 AM »
So I took a look at this forum site, and so far I just see a couple problems I want to ask about first before we consider merging the content:

#1.  I see a 'butt hurt' comment from a mean spirited poster.  And it is still there along with its reply.  If you are "doing great moderation that Rob doesn't do' why havent you deleted this comment yet?

#2.  Please change the name of the OP post to include "SUPPORTER SITE" as it is not our main forum site.


2771
TestNet Discussion Archive / Testnet - Test Proof of Giving
« on: December 06, 2018, 01:00:46 PM »
Welcome to the dedicated testing thread for Proof-of-Giving II (POG).

POG is a mining algorithm based on POW, POBH, Tithing to the foundation, an integrated mining pool, and some elements of POS.

Please see the following technical description:

https://wiki.biblepay.org/Proof-of-Giving-II

And the summary for beginners:
https://wiki.biblepay.org/Proof-of-Giving-for-Beginners

In summary, POG is integrated in the wallet, it is a mixed mining pool with 20% of the reward to the miner/80% reward split between the integrated pool recipients.  The pool participants are based on those who tithed to the foundation (helping our monthly orphan sponsorships) in the last 24 hours.  The tithe_weight for each user drives the pool block reward.

The Proof-of-giving difficulty level will be available in the wallet.
It will display:
min_coin_age:  This is the minimum age in days a coin is eligibile for tithing.
min_coin_amount: This is the minimum coin amount eligibile for tithing.
max_tithe_amount:  This is the maximum allowed tithe amount.

If you meet the conditions you may tithe and become part of the mining pool.
All of the "sowers" (those who tithed) will be rewarded 12 times per day (once every 16 blocks).
After paying the "reaper" (the block solving miner) 20% of the block reward, the remaining 80% will be split among the sowers.

POOL ROUND MECHANICS:
The POG pool is always 205 blocks wide (24 hours), meaning the tithe_weight's in the pool span from the current block back 205 blocks before the current block.

As an example, if sower A tithed at 11 AM yesterday, and sower B tithed at 10 AM today, and the current time is 10:30AM, these two sowers are in the pool.  However, a user who tithed 26 hours ago is NOT in todays pool.

As each block passes, the pool will pay 1/16th of the recipients based on the individual sowers Tier.  Each tithe is inducted into a tier based on the block # it was Tithed in (not according to its amount). 

So what you can expect as far as rewards:  You will receive 12 rewards per day if you have active tithes in the pool.  Once the tithe expires, you no longer have tithe_weight.


AUTOMATIC TITHING:

The wallet is set up to automatically tithe for you once every 4 hours.  The wallet will scan your available coins sorted by age and amount, and use the most applicable SINGLE COIN for a tithe automatically.  It will automatically send the Maximum amount possible.


MANUAL TITHING:


Method 1 - QT: To tithe manually, go to the QT send money page, and click Donate to foundation.  At this point the POG difficulty parameters will appear on the screen.  Select the appropriate tithe amount and click send.  If the coins are not old enough or high enough in value, an error will appear.

Method 2 - RPC:  From the RPC console, type 'exec tithe amount'.
If the tithe fails, a reason will be given.


CHECKING POG DIFFICULTY:

To see the difficulty parameters, type 'getmininginfo'.


CHECKING HISTORICAL POG GIVING:

Type 'showblock blocknumber'. 
See 24_hour_tithes, pog_difficulty, min_coin_age, min_coin_amt, max_tithe_amount.
The historical 24_hour_tithes will show the amount tithed in the last 24 hours.
The block_tithes will show how many legal tithes were inducted from that block.

CHECKING THE POOL:

Type 'exec pogpool'
This report will show the actual live POG POOL and everything in it.
In this pool, we have 16 payment tiers containing an even distribution of sowers (based on each individuals tithe_height).
This will show us the count and sum of tithes per tier. 
Note that if a sower's nickname is available, it will be listed here in place of the address.
(In the near future, we will summarize this list in a nicer way, this is basically a verbose list for debugging purposes).
You can also see the tithe totals, and at the bottom, the sum of your own personal tithes.

HOW TO SET NICKNAME:
In your biblepay.conf file set the key 'nickname=my_nickname' and restart the wallet.


WALLET VERSION:
Upgrade to 1.1.6.2+.  Start with '-testnet=1' flag.


RPC COMMANDS:

exec tithe tithe_amount min_coin_age min_coin_amount:
This command searches the wallet for coins older than min_coin_age and of greater value than min_coin_amount and tithes that single coin in an amount of "tithe_amount". 

exec getdimensionalbalance min_coin_age min_coin_amount
This command scans the local wallet for coins older than min_coin_age and min_coin_amount, and creates a report based on age and value.  You can use this command for debug purposes in testnet to find coins that may be applicable for manual tithing.  (And for debugging current tithe levels).

exec pogpool:
Use this command to see the current payment tiers (0-15).
You will see the user nickname, public receive address, tithe amount, tier, tithe_height.

Then you will see the total tithes per tier.
Then finally you will see the Highest tithe and the amount of personal tithes you have contributed.

exec bankroll quantity denomination:
This command allows you to generate 'quantity' of tithing BBP notes of 'denomination'.  Then you can let them age, and use them for tithing later.
Example: exec bankroll 50 5000, this command will spend 250,000 bbp (back to yourself), and you will receive 50 quantity of 5000 bbp notes.  At this point they will age, and they can be used for tithing.  Note:  We mark the bank notes with a 1millibbp suffix so that we can modify podc_update to skip spending these in the future.





TEST CASES:

1.  Verify that once a tithe is sent to the foundation, it can be seen in a historical block.  You may do this by sending a tithe, waiting for a confirm, then typing:  exec showblock blocknumber.  The fields near the bottom labeled pog_ will show if the tithe has been included in the block.

2.  Verify that sending more than one tithe in one 24 hour period results in increased tithe_weight for you.  And increased total tithes in the pool.

3.  Verify the integrity of the pool.  Audit the pool and reconcile the pool.

4.  Verify the difficulty level parameters per block and per 24 hour period.  Ensure difficulty algorithm is oscillating perfectly and properly according to the tithe history.

5.  Scan debug.log for any trace of "POG Recipients Invalid".  This error should not be in the log.


2772
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 06, 2018, 12:51:37 PM »
My issue is, and don't take as personal criticism, you've had multiple revisions on the system already.  And i feel that's been mostly been because of the loopholes I've found.  I still feel the current parameters are massively exploitable and will require a tremendous amount of work to circumvent that (and quite frankly, I think it's possible the only real solution to the exploits might require more centralization which many are not in favor of).

No matter how great a programmer you are (and you are a great programmer!) you won't be able to test situations you don't perceive.  So running a stress test will only show if the system could support 10,000 users behaving how you expect them to behave.  It won't be able to adequately test non-expected behaviors.  And I'm not even saying the ones TRYING to game the system, but if you have a lot of new users, they're going to do strange things due to ignorance.  And then you have an entirely different breed of non-expected behaviors from those playing within the rules and exploiting the system.  And finally, you have the edge case users, who actively exploit code to circumvent the system.  Something as novel as a new mechanism, not one we're plugging in from another coin, needs far more testing than we can give it at this time.


Thanks, well actually I don't remember you finding any specific loopholes - I remember you asking about 10 different parts of POG that were not loopholes and me replying about those - then waking up the next morning and realizing we needed a tithe_cap and we needed to stop scripting attacks.    And then I gave credit to Jesus.  And those two are the last changes - and thats normal.  You know, this is not about you finding personal grandeur or becoming a hero for your personal achievements - this mission is about us finding our niche through innovation.

I think one core difference in our beleifs is you think BiblePay should be some perfect clone of an existing coin and that we are not capable of becoming our own crypto - while I starkly disagree and believe our place will be through innovation.

Next, I've already programmed in 99% of the test scenarios that we will need.  I disagree with your assessment 100%, and therefore I guess we will see what we see in testnet.


2773
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 05, 2018, 10:38:03 PM »
As someone who is considering investing money into the BIblepay system, I am looking for some help with lingering concerns.  Here are my questions for the developers and significant stakeholders (anyone with more than one master node):
1.    Which is more important to you: protecting investor value or protecting contributions to charities?
2.   Do you consider moving money into the Biblepay system to be an investment or a donation to a charity?
3.   Biblepay has already seen significant fundamental changes and is again considering more significant changes.  Can you provide any assurances that these changes will stop, or is frequent radical changes something that will continue to be typical for BIblepay?
Thank you in advance for your help!

Thanks, these are great questions.

#1.  They are both important, protecting investor value is a 10 (on a 1-10) and protecting charities is a 7.  Its not that the charities are less important its that we are dealing primarily with sponsorships with insurance.  But I clarify, imo protecting a "UTXO lockup rule" is not protecting investor value over the long term.  (Just as no one knows where our price will be in 6 months).  In my case I'm looking further out to what gives us a unique place in the market as a strong service with net daily newcomers and growth.

#2.  EDIT: From an SEC standpoint we are a utility (not an investment or a charitable donation).  We achieve this by renting business object space and striving to have a purchase api.  From a non sec standpoint if an existing holder were to give an opinion of one or the other -  that is a personal distinction you make yourself.

#3.  I think you will see changes that include:  following the Dash commit pattern for each new platform (IE a rebase for example after Evolution, and into the future) as long as we are c++ based.  You will see major features merged in, like an IPFS based Christian economy platform - however this is more like a bolt-in feature.  You will see us settle on and keep our mining algorithm without changes as soon as we are happy with a positive net daily growth pattern.  I feel that change now is less risky than a stagnant user base.  We will keep all working modules in the background, so for example, when things don't work we can revert back to what did work if we make a mistake.  I think POBH->PODC->POG is quite an unusual circumstance, but I think the chips will fall in the right places and we will stabilize and stay with our new base - as soon as net quantitative growth starts.  However, it is possible you might see something to do with proof-of-service, c# contracts and IPFS get merged into POBH/POG in the future in a way that compensates users for participating in a Christian content economy.  Some people view change as bad, but I am of the camp that change is good until we have our niche in the market - then stability is good.  We are finding our place currently.  Then we can cement ourselves as a Christian utility and work PR around it.


2774
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 05, 2018, 04:16:58 PM »
All I have to say is that if POG really IS the next "billion dollar idea", then a billion bucks could buy a lotta resources!  :D

I hope in the end we are the 'deflationary regauged smaller brother of Dash' that anyone can use or mine, and we have a technical feature that makes us stand out to be unique and through all this we end up being a utility (with real world uses - other than buying 1 bbp worth for a video upload tip).


2775
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 05, 2018, 10:47:01 AM »
Hmm, we might need a second wallet for that then (unless a fix cannot be made).

By the way, being able to do POG on mobile wallets would be perfect :)

I'll think about this technically.  If we have a push to release a testnet version and its not addressed, please mention it in the testnet thread and Ill try to engineer something while we start testing v1.0.


Pages: 1 ... 178 179 180 181 182 183 184 [185] 186 187 188 189 190 191 192 ... 263