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 - talisman

Pages: 1 2 [3] 4
31
Also podc I think we could simplify by no team requirement and just require ^1.3. all bounce user needs to do is register their cpk. Wcg.rac just needs cpid and rac. Open it up. That will encourage more Bbp staking.

I support PODC simplification, but I would suggest an even greater coefficient. Small contributors would not be hurt, but running a cpu farm will become very costly. If big boys insist on keeping their places in the leaderboard, so be it - we would have more BBP staked for PODC earnings.

32
Archived Proposals / Re: Automatic Price Mooning
« on: July 22, 2020, 03:48:40 AM »
Check and check. Emission freeze will aply to GSC contracts such as PoDC as well, right?

33
Archived Proposals / Re: Automatic Price Mooning
« on: July 21, 2020, 01:50:06 PM »
That makes sense. Now that vanilla XMRIG is used, miners could easily automate pool switching based on BBP price of the day.

I predict this start-stop pattern would yield an oscillating curve in our prices (i.e., every down-tick would trigger an up-tick and vice versa).

Then we can actually stall in a narrow band. I mean, system would have one vulnerability: Let's say price is 1.8 sat today, and mining is profitable. Tomorrow morning, some miners liquidate and price is recorded as 1.7 sat. Tough luck, one day with no BBP mining incentive. But then, the day after, the price is ticked up to 1.8 sat again, and miners will be motivated to run XMR+BBP. Yes, we have succeded in reducing the emission by half (over a 2-day period), but price is still lingering where it was.

Can you think of a precaution to prevent this?

34
Archived Proposals / Re: Automatic Price Mooning
« on: July 21, 2020, 11:25:11 AM »
Hi Rob,

Interesting idea. I believe in a correlation between scarcity of anything and value attached to it. Here comes my first question:

RandomX miners are sacrificing a percentage of their XMR income in return for BBP they get paid. Assuming these guys are good in calculating their best interests, and many (if not all) are driven here by their greed - I am afraid we will observe a swift reduction in RandomX hashrate once they see they are not getting paid as much as they did until now. That, inturn, will reduce the charity funds generated via dual mining?

35
** PLEASE WITHDRAW FUNDS FROM GRAVIEX WITHIN 14 DAYS **

Graviex is delisting us for low volume.  Please withdraw your assets.


https://graviex.net/

That's very sad. I don't have much experience with Graviex, but it seems to have an interesting offering overall. Losing an exchange just as altcoin markets are warming up is unfortunate; what kind of a volume do they wish to have?

36
Archived Proposals / Re: Should Sanctuaries fund our Orphans?
« on: July 11, 2020, 06:22:00 PM »
Hi Rob,

I find MIP's suggestion noteworthy. Your direction in this proposal is very agreeable, but gradual changes (versus big jumps) are really more welcome among the community. I don't think anyone paying $5/mo for a sanc would mind paying twice as much initially, knowing half is actual donation. As the crypto winter ends, further increases in the donation content would not even trigger any discomfort.

On a separate tone, I think increasing collateral requirement for a donating sanc would also be beneficial due to a lower amount of released coins after the dismantling of some sancs. Oh, how about a system that rewards the sancs in proportion to how much they lock and how much they donate?

37
That port is vardiff, so it is our only port.
Can you please tell me what happens if you telnet to 'foundation.biblepay.org 3001', this will tell me if its a port block or not.
If it has not started working by now please can you give me your bbp address?

We have a limit of 100 tcp connections per miner IP currently.

Here is the output of telnet:
Trying 104.238.147.232...
Connected to foundation.biblepay.org.
Escape character is '^]'.
Connection closed by foreign host.

Problem persists; I sent you more details over pm.

38
** BBP-Xmrig 5.10.1 - Mandatory Upgrade for Miners **


- Remove automatic tithing from the miner

* Note:  The old version of the miner tithes 10%.  Please start using the new version, as the pool now holds back the 10% orphan-tithe automatically.

Binaries:
https://wiki.biblepay.org/Upgrade_to_RandomX

** Mac is still building, MIP will notify

Hi Rob,

I am getting "connection reset by peer" error when I try to mine towards foundation.biblepay.org:3001.

Is there another port I can try?

39
Archived Proposals / Re: BiblePay Future Hash Algorithm for CPUs
« on: January 31, 2020, 10:04:11 AM »
I was exactly referring to what you had in mind (dual-mining algo custom pool) - will be great to see it live !

40
Archived Proposals / Re: BiblePay Future Hash Algorithm for CPUs
« on: January 31, 2020, 05:43:46 AM »
Why don't we simply launch dual mining with our own RandomX pool? If a lot of RandomX miners can be attracted to this first pool offering merged mining, then the pool fees may create a revenue stream for charity even without dipping into the BBP budget.

41
Archived Proposals / Re: BiblePay Future Hash Algorithm for CPUs
« on: January 26, 2020, 02:45:49 PM »
Options 2 and 4 are both very appealing; but I am leaning towards Option 4 (hence my current vote).

Science is good, I love it. Yet we currently are covering enough of that with PODC, I believe.

RandomX will definitely provide us with a lot of exposure at this stage. Monero network hash rate soared from 800 MH/s to 1.2 GH/s in a month - this corresponds to several hundred thousand cpus running RandomX, even if some of them are latest Ryzen 9s. In most parts of the world, a typical 5-year-old cpu is barely breaking even at current network hashrate. Those miners would simply jump over a side benefit such as merged mining of BBP, once they are made aware.

If I am right in the sentence above, then we would see a huge spike in difficulty of BBP POW - old timers or hobby miners may kiss their BBP rewards good bye. This needs to be prevented, imho.

Another concern I have is the flippers: many of those RandomX miners that start mining BBP will prefer to liquidate BBP first, to cover some of their expenses. Remember when we could earn Obyte, Neumannium and a couple others on the side last year with PODC? I doubt anyone kept, say, their Neumanniums :)

I believe this possibility has to be taken into account (better ready than sorry, right?). The only precaution I can think of is incentivising hodling of BBP (or soft-penalising of liquidation). Coin*age requirement as in the ABN times, or proportional PODC RAC requirement for POW rewards, or even fiat donations to charity required for POW rewards, you name it. People that have to pay up front for a reward will be less likely to sell it at any cost (which kills the market). 

 

42
Archived Proposals / Re: PODC TEAM REQUIREMENTS
« on: December 07, 2019, 03:24:16 PM »
I agree completely in the sense that if we want to attract unlimited new users, we should allow the possibility of any team (not just GRC), if they stake the collateral.

I'm definitely open as I want the community to get what they want out of BBP.

So, I extended the deadline 7 more days.

I feel that in order to achieve this we need more votes; so my best advice is to try to drum up more votes if you would like to see this change.

I also agree with Sun's remark - changed my vote to allow members of any team with ^1.6 stake. 

43
Sure, and I will reply asap to the message btw.

On appearing in the leaderboard, the researcher will appear about 5 blocks after a PODC transmission is made; but now the way it works is, if you type exec rac, note how it says 18757 is the next wcg transmission (Fixed), add 205 to that, thats when the wallet sends out the PODC transmission automatically.  But, you will have to see if exec rac shows that you have the coin*age. 

So same issue, if you manually type 'sendgscc wcg' now, the coin age will not be sufficient (until you let it grow a little more).  You know we should also tell the user that (duh) upon manually completing that command.  EDIT:  Ok, the next version will actually give you a reply if you don't have enough coin-age, with a warning, explaining that the RAC may be reduced resulting in a lower reward. 

EDIT: But btw, when a user stakes insufficient collateral, we do reverse engineer it down to the amount staked, and lower the leaderboard RAC, so if you want to try now, you can then look at the leaderboard and see a reduced RAC.

OK, sent a GSC transmission. Required coin-age was 324.976, and I had 200.833. Let's see how it rolls out.

44
Thanks for the funds, Rob ! Otherwise I would have to mine for a couple of days while testing the minimum coinage requirements for a reward  ;D

Do I have to send a manual PODCupdate to show up in the leaderboard?

45
I see one more change that is to be in the next version is increasing the GRC exponent requirement:
https://forum.biblepay.org/index.php?topic=476.new#new

Do we have any volunteer that wants to switch over to team Gridcoin, so we can test the coin-age-requirement is correct in the next version?

I am in with a Gridcoin account. Exponent seems to be working. Here is the output of exec rac:

"Command": "rac",
  "cpid": "82e63a509a38e2201f08c819457df57f",
  "CPK": "ybf862FujX5RZ2G3ENTzNmywA58xkHjL3m",
  "wcg_teamid": 30513,
  "next_podc_gsc_transmission": 18757,
  "team_name": "Gridcoin",
  "researcher_nickname": "amygdala",
  "total_wcg_boinc_credit": 57690.09,
  "total_wcg_points": 403830.63,
  "external_purse_total_coin_age": 0,
  "coin_age_percent_required": 0,
  "NOTE!": "Coins must have a maturity of at least 5 confirms for your coin*age to count.  (See current depth in coin control).",
  "coin_age_required": 286924.2504116587,
  "wcg_id": 1027347,
  "rac": 2576.941353

Pages: 1 2 [3] 4