Messages

271

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 06:44:48 PM »

InstantSend (IX) used to say 5 out of 6 confirmations. Now it is just 1 out of 6, but with the key checkbox icon in the column? I notice the transaction line continues to be blue.

272

Archived Proposals / Re: Cryptoid Explorer for next six months (Aug 2019 ~ Mar 2020)

« on: November 26, 2019, 06:28:01 PM »

We got 4.7 months paid for.

bbp (Biblepay) on 2019-08-30 20:53 Expires 2020-01-27 23:09 (in 149.1 days) On 2019-08-30 20:00, credit "Paymium c36c24" (144.88 days), new expiry 2020-01-27 23:09 On 2019-05-14 09:15, credit "BTC at $8000 bonus!" (8.00 days), new expiry 2019-09-05 01:57 On 2019-04-29 09:07, credit initial contribution ()

It is time to renew again. We have less than 60 days left with last payment. Will try to renew again for 6 months. Asking 350k BBP. Will convert to BTC and submit to Cryptoid Explorer. I hope everyone sees value in this explorer over Iquudus in terms of cost and features.

273

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 04:09:54 PM »

had to erasechain and delete instantsend.dat - settled on 18446. was on 18459



2019-11-26 21:41:27 UpdateTip: new best=8b1ad9df4a08823a7b1cb36c7671d21e8b549334e322ff6e1bfebfaf0e7e8170 height=18459 version=0x20000001 log2_work=46.18226809 tx=29113 date='2019-11-26 21:29:42' progress=0.258118 cache=0.1MiB(897txo) evodb_cache=0.0MiB
2019-11-26 21:41:27 CheckForkWarningConditions: Warning: Found invalid chain which has higher work (at least ~6 blocks worth of work) than our best chain.




If I had the foresight, I would have saved the old instandsend.dat and current so you could do some binary comparison.

274

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 02:54:04 PM »

other than healing and pog (or dws) which are manual transactions anyways... it makes sense to to add POOM to auto payments like WCG? If the accounting is correct and you trust the oracle data, then I don't think it should matter whether it is BOINC data or POOM data.

275

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 02:51:06 PM »

i erase the chain started over... now exec rac says


looks like I missed the one in between



"next_podc_gsc_transmission": 18552,

276

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 26, 2019, 02:17:50 PM »

No, nothing.  If you type 'exec rac' it should reveal the height in which the daily tx goes out (automatically).

PODC_Height:

When I type exec rac, I don't see podc_height.


I see a next_podc_gsc_transmission. the block is 18347, but I think we are on 18422 (although I could be on the wrong chain).



  "next_podc_gsc_transmission": 18347,

277

Archived Proposals / Re: Dynamic Whale Staking

« on: November 25, 2019, 11:59:39 PM »

The drastic difference however is in POG, you have control over your coins and each day, you can crash our market or spend the coins.

With burning otoh, you lose control of your coins and burn them, and therefore make our coins rarer for the period that our money supply shrinks.

So this type of ecosystem what we would hope for is new buyers buy into biblepay, our price rises, they burn the coins, they get a refund later plus a reward, and by then we have even more users.  So its sort of an ecosystem with an impetus for popularity, if it works out.

Do you feel investors will feel comfortable losing control over their coins by burning to an address they do not own? It is quite nerve racking to lose your coins, then wait and hope the code will send you back the original plus reward. Don't you want investors to feel safer by keeping funds in the wallet and time locking it via a smart contract? This is what Dai Savings Rate (DSR) does (https://web.archive.org/web/20190730215041/https://medium.com/makerdao/dai-reward-rate-earn-a-reward-from-holding-dai-10a07f52f3cf) and I feel a lot safer with a mechanism like this than "burning" and "unburning". In the end, both methods keep supply locked up and Dai Savings Rate feels much safer to investors than Dynamic Whale Staking.

278

Archived Proposals / Re: PODC TEAM REQUIREMENTS

« on: November 24, 2019, 11:52:49 PM »

1.3 vs 1.6 is in my opinion too different
1.3 vs 1.4 or 1.4 vs 1.5 will be better

but stake 13m with 1.3 or 579m with 1.6 is too much

I don't think it is too high at all.


https://gridcoinstats.eu/project/world%20community%20grid


Most of the top RAC "users" are pools. CharityEngine and grcpool.


Already, they are slightly split up so the RAC to BBP requirement is less.


Personally, I'd say blacklist any user above 100k RAC, but having the exponent discourage pool, people with high RAC hardware, or force you to split your cpid.

279

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 24, 2019, 10:45:55 AM »

did we need something in our biblepay.conf to send out wcg tx regularly?

280

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 24, 2019, 10:31:53 AM »

Will we have InstantSend default or ChainLocks in the recent merges?

281

Archived Proposals / Re: PODC TEAM REQUIREMENTS

« on: November 22, 2019, 12:12:41 PM »

794k RAC between grcpool 1,2,3 pools means 33.7M BBP is required if RAC ^1.3

282

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 21, 2019, 03:38:54 PM »

Ok everyone please stop testing the DWS burns until the next version, I added a couple more rules.

Lets test everything else.

For PoDC 2.0, I was thinking of hopping back and forth between team BiblePay and another team (GRC or OByte). Was thinking I could time bouncing back and forth somehow to double dip.


Just thinking back to the days where PoDC users shifted BBP between wallets to perform their PoDC updates and stake far less than required. I think you are using coinage somehow so the wallet shifting wouldn't work, but still trying to figure out any potential exploits.

283

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 21, 2019, 07:48:03 AM »

If we repeatedly send dws - there's no way to prevent this message? I can foresee a lot of tech support around this. You can tell people to send only one tx, but you know that will not happen. With PoG v1, people sent multiple tithes in a block... same scenario here.


2019-11-21 13:44:39 ERROR: AcceptToMemoryPool : Transaction b869f42c5188368c5f9a8541b48f384e6bbf79fed89f7d38f437161bc731956e conflicts with completed Transaction Lock ef650256b9e1d1fcb79f138f53baa5220bdc28d13f0c42dfce5db0eab4360616
2019-11-21 13:44:39 CommitTransaction(): Transaction cannot be broadcast immediately, tx-txlock-conflict

284

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 20, 2019, 07:50:55 AM »

2019-11-20 02:28:28 UpdateTip: new best=609dd6f5a03962ad5313f4f7a9a1ffc945a0ae8d4e4578f3ae972ccab3e3cebd height=17211 version=0x20000001 log2_work=45.77639859 tx=26702 date='2019-11-20 02:28:18' progress=0.249753 cache=0.1MiB(448txo)
2019-11-20 02:28:28 {PNB}: ACC  {PNB}: ACC  ERROR: AcceptBlockHeader: prev block f449b1b97feddb3869fc604682355eefb80d35186d853bf678ff49daee7feecb conflicts with chainlock

Seems to be okay now, I quit the testnet wallet and tried again and both are on 17308:
"hash": "0975df866939ada03b79d06fc5a087178b3f89931105ec5aaa02cd57345b8a78",

285

TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)

« on: November 19, 2019, 08:44:54 PM »

2019-11-20 02:28:28 UpdateTip: new best=609dd6f5a03962ad5313f4f7a9a1ffc945a0ae8d4e4578f3ae972ccab3e3cebd height=17211 version=0x20000001 log2_work=45.77639859 tx=26702 date='2019-11-20 02:28:18' progress=0.249753 cache=0.1MiB(448txo)
2019-11-20 02:28:28 {PNB}: ACC  {PNB}: ACC  ERROR: AcceptBlockHeader: prev block f449b1b97feddb3869fc604682355eefb80d35186d853bf678ff49daee7feecb conflicts with chainlock