Bible Pay

TestNet => TestNet Discussion Archive => Topic started by: Rob Andrews on January 19, 2018, 08:31:58 pm

Title: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 19, 2018, 08:31:58 pm
All, it's time to test a new Biblepay   8)    Feature!

One that helps us make inroads into third world countries, helps us mine on mobile phones, and helps reward our loyal investors who Tithe!

And most importantly helps foil pesky BotNets.

Please see this wiki page for the background information and most technical information:

http://wiki.biblepay.org/Proof_Of_Loyalty


Note, that in the biblepay client, the default staking target percentage is set to .10.  (IE 10% of your coins).  If you would like to change it please modify the "polpercentage" key with a whole number between 00 and 100.


For linux:  Please build 1.0.8.3

or for Windows: Please download v1.0.8.3 from here: https://www.biblepay.org
before proceeding.

You may start your client in testnet by adding the "-testnet" suffix.

Let me know when synced and we will start testing.


NOTE:  The linux version currently has no way to notify you that it was a proof-of-loyalty block, I am working on that now.  The QT version does display it.


NOTE II:  This first version does not make any effort to unlock your wallet.  Staking requires an unlocked wallet.  We can discuss this in the thread.  For now, please unlock your wallet for thousands of minutes to test this version (if it is locked).


EDIT III:  If you need an addnode:  node.biblepay.org, we are on block number 514

** Please start with an empty chain in testnet, rules have changed in testnet since last tests **





Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: klondike on January 20, 2018, 06:06:53 am
where we can change polpercentage? i dont see anything with this settings in win wallet
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 08:52:42 am
where we can change polpercentage? i dont see anything with this settings in win wallet

In the config file, you can type:

polpercentage=30

For example.

But its already set as 10% by default.

Do you need coins ?  And are you synced to block 1000? 

I do not see you on my node.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: SimonSays on January 20, 2018, 09:02:18 am
Hi,

Do I use the same wallet to test as I do for Main network?

Best regards,
Simon
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 09:16:57 am
Hi,

Do I use the same wallet to test as I do for Main network?

Best regards,
Simon

Yes sir we have the feature disabled in prod, so if you do this:
Download 1.0.8.3 (or build it)
Run it with -testnet flag like this:
./biblepay-qt -testnet


You should sync to block 1005 or so?

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: SimonSays on January 20, 2018, 09:26:18 am
OK, it shows block 1042 ... is this OK - it doesn't seem to mine?

{
  "blocks": 1043,
  "currentblocksize": 0,
  "currentblocktx": 0,
  "difficulty": 2.227311951866475,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 1108933658.139833,
  "hashps": 0,
  "minerstarttime": "1-1-1970 00:00:00",
  "ratio": 0,
  "hc1": 0,
  "bhc2": 0,
  "hashcounter": 0,
  "competetive_mining": true,
  "competetivemining_hash_counter": 0,
  "global_competetive_mining_tithe": 0,
  "competetive_mining_ratio": 0,
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": false,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 0,
  "poolmining": false,
  "pool_url": "",
  "poolmining_use_ssl": false,
  "proof_of_loyalty_target_percentage": 0.1,
  "proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""
}
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 09:34:00 am
OK, it shows block 1042 ... is this OK - it doesn't seem to mine?

{
  "blocks": 1043,
  "currentblocksize": 0,
  "currentblocktx": 0,
  "difficulty": 2.227311951866475,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 1108933658.139833,
  "hashps": 0,
  "minerstarttime": "1-1-1970 00:00:00",
  "ratio": 0,
  "hc1": 0,
  "bhc2": 0,
  "hashcounter": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""
}


Yep! Your synced, cool.
Do you need coins? 

It should be mining after a few seconds, ensure setgenerate true X ?

Oh and ensure pool mining is off, since pool in testnet might be off...
(It should technically fall through to solo anyway).
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 20, 2018, 10:36:14 am
I'm going to build my testnet wallet and start testing too :)
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 10:56:11 am
I'm going to build my testnet wallet and start testing too :)

The more the merrier  ;D
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: inblue on January 20, 2018, 11:26:37 am
Me too. :)
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: SimonSays on January 20, 2018, 11:55:36 am
Yes sir we have the feature disabled in prod, so if you do this:
Download 1.0.8.3 (or build it)
Run it with -testnet flag like this:
./biblepay-qt -testnet


You should sync to block 1005 or so?

I have another question: how do i start linux biblepayd with -testnet?  I can't make it work. I have Ubuntu server 16.04.
Thanks.

Best regards,
Simon
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 12:38:13 pm
I have another question: how do i start linux biblepayd with -testnet?  I can't make it work. I have Ubuntu server 16.04.
Thanks.

Best regards,
Simon
You just launch like this:

./biblepayd -testnet

./biblepay-cli getinfo

Worked for me

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Hardijs on January 20, 2018, 01:52:21 pm
Hi, Rob!

I simply copy my main wallet file with 38k bbp to fresh 1.08.03 install directory, but when I start the biblepay-qt.exe its show "0.00"balance! How I can put the bbp in test wallet?
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 02:13:56 pm
Hi, Rob!

I simply copy my main wallet file with 38k bbp to fresh 1.08.03 install directory, but when I start the biblepay-qt.exe its show "0.00"balance! How I can put the bbp in test wallet?
Whats your testnet address? I send you some.

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Hardijs on January 20, 2018, 02:30:19 pm
Whats your testnet address? I send you some.

yfm4gbDunC1moMUwrQQSobgEnZHbshTTpK

...hmm...with balance "0" and "proof_of_loyalty_errors": "BALANCE TOO LOW TO STAKE" I receive 2times a mined bbp, who are "immature". It's OK?
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 02:32:57 pm
yfm4gbDunC1moMUwrQQSobgEnZHbshTTpK

...hmm...with balance "0" and "proof_of_loyalty_errors": "BALANCE TOO LOW TO STAKE" I receive 2times a mined bbp, who are "immature". It's OK?

Ok sent 500k.

Yes, that message is accurate, you have to have mature coins to stake.

Type: exec stakebalance to find your stake balance.

Now just wait about 24 hours for coin-age to accrue.



Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Hardijs on January 20, 2018, 02:45:44 pm
Ok sent 500k.

Yes, that message is accurate, you have to have mature coins to stake.

Type: exec stakebalance to find your stake balance.

Now just wait about 24 hours for coin-age to accrue.

Thx, I got it now!
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: tiras on January 20, 2018, 03:44:35 pm
yfm4gbDunC1moMUwrQQSobgEnZHbshTTpK

...hmm...with balance "0" and "proof_of_loyalty_errors": "BALANCE TOO LOW TO STAKE" I receive 2times a mined bbp, who are "immature". It's OK?

Hi Rob,  can you send me  some tBBP too  ?   thx

yUv5GqYM1XTJh9NDvY91guZpeMZanTjk6X
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 06:14:43 pm
Hi Rob,  can you send me  some tBBP too  ?   thx

yUv5GqYM1XTJh9NDvY91guZpeMZanTjk6X
Sent a cool half mil.
 8)
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 06:15:33 pm
we need for 24Hours now?
You probably dont you were on yesterday, so try getmininginfo, see if your Influence percent is > 0?

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 06:17:38 pm
we need for 24Hours now?
Your IP (58) was banned, but I have 3 connections.  Did you start a fresh chain and 1083?  Because we need to know this system is not banning each other.

Edit: Looks like your chain had a different block at height 5:
2018-01-20 11:38:33 ERROR: ContextualCheckBlockHeader : incorrect proof of work at 5
2018-01-20 11:38:33 Misbehaving: 87.197.124.58:65491 (0 -> 100) BAN THRESHOLD EXCEEDED

Im going to sync one of my other nodes and see if I can join the party


Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: tiras on January 20, 2018, 06:51:11 pm
Sent a cool half mil.
 8)

thank you Sir !

now,  I have  533K tBPP .   hwo do I unlock the wallet for staking .  ( I didn't encrypt test wallet though )

Code: [Select]
19:48:45

getmininginfo


19:48:45

{
  "blocks": 1450,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 0.856879486408389,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 542348962.9804804,
  "hashps": 216.2240583635007,
  "minerstarttime": "01-20-2018 22:17:58",
  "ratio": 1,
  "hc1": 1956125,
  "bhc2": 3696925,
  "hashcounter": 1956125,
  "competetive_mining": true,
  "competetivemining_hash_counter": 2728245,
  "global_competetive_mining_tithe": 252,
  "competetive_mining_ratio": 1,
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "WORKER ID EMPTY IN POOL CONFIG; ",
  "miningpulse": 670,
  "poolmining": false,
  "pool_url": "",
  "poolmining_use_ssl": false,
  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": "INSUFFICIENT FUNDS, ENSURE WALLET IS UNLOCKED"
}
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: klondike on January 20, 2018, 06:59:38 pm
Quote
{
  "blocks": 1454,
  "currentblocksize": 0,
  "currentblocktx": 0,
  "difficulty": 1.976088529731034,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 683646085.3454822,
  "hashps": 0,
  "minerstarttime": "1-1-1970 00:00:00",
  "ratio": 0,
  "hc1": 0,
  "bhc2": 0,
  "hashcounter": 0,
  "competetive_mining": true,
  "competetivemining_hash_counter": 0,
  "global_competetive_mining_tithe": 0,
  "competetive_mining_ratio": 0,
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": false,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 0,
  "poolmining": false,
  "pool_url": "",
  "poolmining_use_ssl": false,
  "proof_of_loyalty_target_percentage": 1,
  "proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 08:07:42 pm
thank you Sir !

now,  I have  533K tBPP .   hwo do I unlock the wallet for staking .  ( I didn't encrypt test wallet though )

Code: [Select]
19:48:45

getmininginfo


19:48:45

{
  "blocks": 1450,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 0.856879486408389,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 542348962.9804804,
  "hashps": 216.2240583635007,
  "minerstarttime": "01-20-2018 22:17:58",
  "ratio": 1,
  "hc1": 1956125,
  "bhc2": 3696925,
  "hashcounter": 1956125,
  "competetive_mining": true,
  "competetivemining_hash_counter": 2728245,
  "global_competetive_mining_tithe": 252,
  "competetive_mining_ratio": 1,
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "WORKER ID EMPTY IN POOL CONFIG; ",
  "miningpulse": 670,
  "poolmining": false,
  "pool_url": "",
  "poolmining_use_ssl": false,
  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": "INSUFFICIENT FUNDS, ENSURE WALLET IS UNLOCKED"
}

The stakeminer in test requires 202 confirms, but only .01 hrs of coinage (in prod its 202 confirms ans 24 hours of coin age), so anyway since we have 1 minute blocks in testnet, you really only need to wait 202 blocks for insufficient funds to go away.

To find out how much funds you have "mature" for staking, type 'exec stakebalance'.  Thats unlocked mature stakeable coins.

Wait for that to be > 0 then do getmininginfo.  Look for POL percent to go above 0.

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 08:15:10 pm


What does exec stakebalance say?
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: tiras on January 20, 2018, 08:35:12 pm
The stakeminer in test requires 202 confirms, but only .01 hrs of coinage (in prod its 202 confirms ans 24 hours of coin age), so anyway since we have 1 minute blocks in testnet, you really only need to wait 202 blocks for insufficient funds to go away.

To find out how much funds you have "mature" for staking, type 'exec stakebalance'.  Thats unlocked mature stakeable coins.

Wait for that to be > 0 then do getmininginfo.  Look for POL percent to go above 0.

my stakebalance :


21:33:14
exec stakebalance
21:33:14
{
  "Command": "stakebalance",
  "StakeBalance": 67791
}

POL % :
"proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": "INSUFFICIENT FUNDS, ENSURE WALLET IS UNLOCKED"

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 20, 2018, 10:10:08 pm
my stakebalance :


21:33:14
exec stakebalance
21:33:14
{
  "Command": "stakebalance",
  "StakeBalance": 67791
}

POL % :
"proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": "INSUFFICIENT FUNDS, ENSURE WALLET IS UNLOCKED"

Are all the recvd funds over 202 blocks old yet?

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: tiras on January 20, 2018, 11:28:08 pm
Are all the recvd funds over 202 blocks old yet?

how do I check if the funds are old ?

they are all matured  except for the last one, if you meant this .
got deducted  the 1st POL payment:
Code: [Select]
Status: 73 confirmations
Date: 1/20/2018 22:38
Total debit: 0.00000000 tBiblepay
Total credit: 0.00000000 tBiblepay
Transaction fee: -0.00007600 tBiblepay
Net amount: -0.00007600 tBiblepay

Height: 1569
Difficulty: 2.080899
Time: 01-21-2018 03:38:43
Subsidy: 16857.2210
Proof-Of-Loyalty Weight: 20337.00


Code: [Select]
"proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 8533,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""
}

Code: [Select]
00:32:27

exec stakebalance


00:32:27

{
  "Command": "stakebalance",
  "StakeBalance": 84755
}


all transactions :

Code: [Select]
"Confirmed","Date","Type","Label","Address","Amount (tBiblepay)","ID"
"false","2018-01-20T22:38:43","Mined","","yZ5PUBembq6MeV26aSMQgeUhNHsj6LWaWH","16857.22099996","74906c914c6a97f94b198c16c9c3492fba452d711c5411e21b27624ef096e9b7-000"
"true","2018-01-20T22:38:43","Proof of Loyalty","","","-0.00007600","1e92482039372807b7b13f3592c87de699b90000524a59687adc1547f82d7fb4-000"
"true","2018-01-20T20:26:32","Mined","","yZ5PUBembq6MeV26aSMQgeUhNHsj6LWaWH","16872.52100000","3a8e175577ccd9b84b77314a27ad39266ba1c88a2d636eb5712fd040053ee2f7-000"
"true","2018-01-20T19:13:30","Received with","","yUv5GqYM1XTJh9NDvY91guZpeMZanTjk6X","500000.00000000","b1ca079e8a491c087998c93efd9c07b5d6f86180c8f6176af196285432fb9080-000"
"true","2018-01-20T18:59:36","Mined","","yZ5PUBembq6MeV26aSMQgeUhNHsj6LWaWH","16849.50200000","50e52fdf4d7900b60b3cbcb79e76ab58d279310e71a596affcbbb23e3b30e105-000"
"true","2018-01-20T17:54:12","Mined","","yZ5PUBembq6MeV26aSMQgeUhNHsj6LWaWH","16858.00200000","f26e88cfe9de7a5a68c0219cd6265c619ecadeb58084f087b8f6decae467f315-000"
"true","2018-01-20T17:16:01","Mined","","yeE8TU55jMstcU3bwPgnyreTPPo6xnV2zE","16864.80200000","a5ecb83e95582684db097f299e2691fa95e744406c1ec2dd574550e56eb1ed2c-000"
"true","2018-01-20T17:03:00","Mined","","yjBEd3FRgcYeuG8peLtcH89kXLRsxDTTR7","16852.05199999","ea933292cbb1b1efb9a1e47998f924f00c2291e82622afc5f626598e1439de05-000"


I guess the last mined block was POL :

Code: [Select]
Status: 88 confirmations, broadcast through 187 nodes
Date: 1/20/2018 22:38
Source: Generated
Credit: 16 948.14999996 tBiblepay (matures in 14 more blocks)
Net amount: 0.00000000 tBiblepay

Height: 1569
Difficulty: 2.080899
Time: 01-21-2018 03:38:43
Subsidy: 16857.2210
Proof-Of-Loyalty Weight: 7674.43

:
Transaction ID: 74906c914c6a97f94b198c16c9c3492fba452d711c5411e21b27624ef096e9b7-000

Generated coins must mature 102 blocks before they can be spent. When you generated this block, it was broadcast to the network to be added to the block chain. If it fails to get into the chain, its state will change to "not accepted" and it won't be spendable. This may occasionally happen if another node generates a block within a few seconds of yours.



Debug information

Credit: 16 857.22099996 tBiblepay
Credit: 90.92900000 tBiblepay

Transaction:
CTransaction(hash=74906c914c, ver=1, vin.size=1, vout.size=3, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 0221060105)
    CTxOut(nValue=16857.22099996, scriptPubKey=2102c797735935262abf2feb6dfd02)
    CTxOut(nValue=90.92900000, scriptPubKey=2102c797735935262abf2feb6dfd02)
    CTxOut(nValue=0.00000004, scriptPubKey=76a9149cff090c148949e19f4ed915)

Inputs:
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: tiras on January 21, 2018, 04:13:06 am

my whole balance is staked now except for 2 last mined blocks:
{
  "Command": "stakebalance",
  "StakeBalance": 601703
}

details of the last  TX :
Code: [Select]
Status: 5/unconfirmed, broadcast through 12 nodes
Date: 1/21/2018 05:02
Source: Generated
Credit: 16 975.34999997 tBiblepay (matures in 97 more blocks)
Net amount: 0.00000000 tBiblepay

Height: 1842
Difficulty: 0.728086
Time: 01-21-2018 10:02:33
Subsidy: 16885.3310
Proof-Of-Loyalty Weight: 204131.92
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 21, 2018, 09:52:24 am
my whole balance is staked now except for 2 last mined blocks:
{
  "Command": "stakebalance",
  "StakeBalance": 601703
}

details of the last  TX :
Code: [Select]
Status: 5/unconfirmed, broadcast through 12 nodes
Date: 1/21/2018 05:02
Source: Generated
Credit: 16 975.34999997 tBiblepay (matures in 97 more blocks)
Net amount: 0.00000000 tBiblepay

Height: 1842
Difficulty: 0.728086
Time: 01-21-2018 10:02:33
Subsidy: 16885.3310
Proof-Of-Loyalty Weight: 204131.92

Go ahead and type 'showblock blocknumber'
for example: showblock 1842

And then you can see the POL fields - take a look at the POL age, and the POL weight
You had a weight of 204259 due to age being .40 and amount staked being 500,000.

But the influence on the network level was zero because of the current money supply level.
Everything appears to be working, but I do think we need to add in the "sanctuary locked funds" effect into the money supply to make this system much more accurate.  In summary, that means POL would become easier after I do that.

The theory is that in prod, we have 100 sancs now with locked supply.  Thats 100* 1.55M = 155M of locked funds out of a 350MM supply.  Thats a level of about 55% of the entire money supply.  Meaning that if we can add that accurate argument in to our GetMoneySupply, we could make a much more accurate boost level for POL.


We will probably need a patch for whatever sanc issue we have in prod.  After I take a look at that, Ill consider doing this at the same time.

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: tiras on January 21, 2018, 11:18:01 am
Go ahead and type 'showblock blocknumber'
for example: showblock 1842

And then you can see the POL fields - take a look at the POL age, and the POL weight
You had a weight of 204259 due to age being .40 and amount staked being 500,000.

But the influence on the network level was zero because of the current money supply level.
Everything appears to be working, but I do think we need to add in the "sanctuary locked funds" effect into the money supply to make this system much more accurate.  In summary, that means POL would become easier after I do that.

The theory is that in prod, we have 100 sancs now with locked supply.  Thats 100* 1.55M = 155M of locked funds out of a 350MM supply.  Thats a level of about 55% of the entire money supply.  Meaning that if we can add that accurate argument in to our GetMoneySupply, we could make a much more accurate boost level for POL.


We will probably need a patch for whatever sanc issue we have in prod.  After I take a look at that, Ill consider doing this at the same time.


my stakebalance should be higher but I 've sent 200k to another user for testing

Code: [Select]
12:16:59

exec stakebalance


12:16:59

{
  "Command": "stakebalance",
  "StakeBalance": 503378
}


12:17:01

showblock blocknumber


12:17:01

bad lexical cast: source type value could not be interpreted as target (code -1)


12:17:18

showblock 1842


12:17:18

{
  "hash": "d9a4fb1016c450b9077897cc615768c745c0de3fa7565a4c69bb5bbef4fd34cd",
  "hash2": "7b766d85896f198b6f539212149844ec6a1f665cd0325c640e74592691a30144",
  "confirmations": 311,
  "size": 994,
  "height": 1842,
  "version": 536870912,
  "merkleroot": "f2a75c9368e1a18fc6b60bb16d623caa2c42c63d56b030e03f5bf17114a7ffb1",
  "tx": [
    "86d51b286ece17710a59d791f42a209611ad710f25c0ea1a5dad230af5b0258d",
    "b8aa2ee279953056349773c9f8d8892fa8804ec05d7bec94cc71f8b373431cc6"
  ],
  "time": 1516528953,
  "mediantime": 1516528498,
  "hrtime": "01-21-2018 10:02:33",
  "nonce": 632,
  "bits": "1d015f9a",
  "difficulty": 0.7280857682479724,
  "chainwork": "000000000000000000000000000000000000000000000000000006d84b751b3f",
  "subsidy": 16885,
  "blockversion": "1.0.8.3",
  "masternodereward": 299565000000,
  "previousblockhash": "02629d8bce8eaeb1f8e16387b816bf7e3f5c25d8252dd2bd40c6e26e382dc353",
  "verses": "Co1|3|22| Whether Paul, or Apollos, or Cephas, or the world, or life, or death, or things present, or things to come; all are your's;\r\nExo|10|27| But the LORD hardened Pharaoh's heart, and he would not let them go.\r\nPsa|118|15| The voice of rejoicing and salvation is in the tabernacles of the righteous: the right hand of the LORD doeth valiantly.\r\nJoh|7|36| What manner of saying is this that he said, Ye shall seek me, and shall not find me: and where I am, thither ye cannot come?\r\nHab|2|5| Yea also, because he transgresseth by wine, he is a proud man, neither keepeth at home, who enlargeth his desire as hell, and is as death, and cannot be satisfied, but gathereth unto him all nations, and heapeth unto him all people:\r\nRev|11|1| And there was given me a reed like unto a rod: and the angel stood, saying, Rise, and measure the temple of God, and the altar, and them that worship therein.\r\nJer|46|20| Egypt is like a very fair heifer, but destruction cometh; it cometh out of the north.\r\nKg1|8|18| And the LORD said unto David my father, Whereas it was in thine heart to build an house unto my name, thou didst well that it was in thine heart.\r\n",
  "satisfiesbiblehash": "true",
  "biblehash": "0000000030622a24294cdf1c11fa61b2e03a5ef16065e391dbf809d9f3dd0617",
  "proof_of_loyalty_weight": 204259.235618144,
  "proof_of_loyalty_errors": "",
  "proof_of_loyalty_xml": "<VER>1.0.8.3</VER><polmessage>b092bc1e50d22e570b0ce7a15400f1a273b08cf09518df2cf9b8bcfb52aad6c2</polmessage><polweight>204131.92</polweight><polamount>500000.00</polamount><polavgage>0.408</polavgage><SIG_0>H+qTGu82Ce9G027bwKNZWlrYAOVQS/LP3qJuB2qqFAZ2ToR6cjVDAFOpHp4g2MbgMaNzI+d9PLrKTD/M43/gu8c=</SIG_0><SIG_1>H4x1Qs8hXHNSWr6N9QvhZrmrLFOjzuQCdxbP4oDbJSy0YqhSWgc29DBHXkl1ljz4Flz3u0QPRAiXmrQ0tddQbj0=</SIG_1>",
  "proof_of_loyalty_metrics": "<polamount>500000.00</polamount><polavgage>0.409</polavgage>",
  "block_target_hash": "000000015f9a0000000000000000000000000000000000000000000000000000",
  "proof_of_loyalty_block_target": "000000015f9a0000000000000000000000000000000000000000000000000000",
  "proof_of_loyalty_influence_percentage": 0,
  "prayers": "",
  "nextblockhash": "4d1e0d4ebb1c30b1684fc5892705cff02be6311399afa4d68c252c69a7a7debd"
}
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 21, 2018, 02:32:40 pm
yfm4gbDunC1moMUwrQQSobgEnZHbshTTpK

...hmm...with balance "0" and "proof_of_loyalty_errors": "BALANCE TOO LOW TO STAKE" I receive 2times a mined bbp, who are "immature". It's OK?

Sounds fine. Just wait a little and the mined blocks should mature.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: klondike on January 21, 2018, 04:08:14 pm
What does exec stakebalance say?


23:07:59

exec stakebalance


23:07:59

{
  "Command": "stakebalance",
  "StakeBalance": 1341499
}

Quote
23:20:03

{
  "blocks": 2367,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 0.8277965844785772,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 580167236.0329986,
  "hashps": 468.9287194903009,
  "minerstarttime": "01-21-2018 22:10:27",
  "ratio": 1,
  "hc1": 270336,
  "bhc2": 483328,
  "hashcounter": 270336,
  "competetive_mining": true,
  "competetivemining_hash_counter": 253470,
  "global_competetive_mining_tithe": 26,
  "competetive_mining_ratio": 0,
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 62,
  "poolmining": false,
  "pool_url": "",
  "poolmining_use_ssl": false,
  "proof_of_loyalty_target_percentage": 1,
  "proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": "INSUFFICIENT FUNDS, ENSURE WALLET IS UNLOCKED"
}
im unlock and my balance without changes .... where is problem?

im using this

testnet=1
genproclimit=1
addnode=node.biblepay.org
polpercentage=100
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: tiras on January 21, 2018, 05:23:15 pm
Rob ,  what does this mean in the TX details ?

Subsidy: 16864.2070
Proof-Of-Loyalty Weight: 48445.8

Code: [Select]
Status: 13 confirmations, broadcast through 28 nodes
Date: 1/21/2018 18:00
Source: Generated
Credit: 16 951.54999999 tBiblepay (matures in 89 more blocks)
Net amount: 0.00000000 tBiblepay

Height: 2397
Difficulty: 1.247787
Time: 01-21-2018 23:00:17
Subsidy: 16864.2070
Proof-Of-Loyalty Weight: 48445.83

also ,  what are these tiny  charges showing with every mined block ?

-0.00015860

Code: [Select]
Transaction fee: -0.00015860 tBiblepay
Net amount: -0.00015860 tBiblepay

Height: 2397
Difficulty: 1.247787
Time: 01-21-2018 23:00:17
Subsidy: 16864.2070
Proof-Of-Loyalty Weight: 171338.00
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 21, 2018, 07:06:42 pm
Rob ,  what does this mean in the TX details ?

Subsidy: 16864.2070
Proof-Of-Loyalty Weight: 48445.8

Code: [Select]
Status: 13 confirmations, broadcast through 28 nodes
Date: 1/21/2018 18:00
Source: Generated
Credit: 16 951.54999999 tBiblepay (matures in 89 more blocks)
Net amount: 0.00000000 tBiblepay

Height: 2397
Difficulty: 1.247787
Time: 01-21-2018 23:00:17
Subsidy: 16864.2070
Proof-Of-Loyalty Weight: 48445.83

also ,  what are these tiny  charges showing with every mined block ?

-0.00015860

Code: [Select]
Transaction fee: -0.00015860 tBiblepay
Net amount: -0.00015860 tBiblepay

Height: 2397
Difficulty: 1.247787
Time: 01-21-2018 23:00:17
Subsidy: 16864.2070
Proof-Of-Loyalty Weight: 171338.00


The charge is the transaction fee for the POS tx in the block (the amount spent to send it to yourself).
The weight is the stakeage*amountstaked (outlined in the spec doc).
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 22, 2018, 03:16:59 am
all POS is crap  >:( 

no help
no tutorial what is what
no video help

togo/rob will be time when bbp will be mining only botnet and you  ;)

You know this is testnet right? What do you need help with?
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: klondike on January 22, 2018, 08:03:01 am
nobody knows how it work....beautiful  ...
im mining with staked 2.7M BBP and results nothing
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 22, 2018, 08:45:42 am
nobody knows how it work....beautiful  ...
im mining with staked 2.7M BBP and results nothing

Do you mean you still get "INSUFFICIENT FUNDS, ENSURE WALLET IS UNLOCKED"?

I didn't get that before, but I do get it now.

I first staked 10% without problems:
Code: [Select]
  "blocks": 2268,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 4.130205297074162,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 1430163394.55595,
  "hashps": 139.3904570489989,
  "minerstarttime": "01-21-2018 10:37:50",
  "ratio": 1,
  "hc1": 4707992,
  "bhc2": 7857816,
  "hashcounter": 4707992,
  "competetive_mining": true,
  "competetivemining_hash_counter": 4438530,
  "global_competetive_mining_tithe": 303,
  "competetive_mining_ratio": 0,
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 997,
  "poolmining": false,
  "pool_url": "",
  "poolmining_use_ssl": false,
  "proof_of_loyalty_target_percentage": 0.1,
  "proof_of_loyalty_weight": 11835,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""

Then I made it 30% and it seemed to go well:

Code: [Select]
  "blocks": 2288,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 1.278881430021076,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 553951922.6495132,
  "hashps": 139.3679734561737,
  "minerstarttime": "01-21-2018 20:10:06",
  "ratio": 1,
  "hc1": 173056,
  "bhc2": 275456,
  "hashcounter": 173056,
  "competetive_mining": true,
  "competetivemining_hash_counter": 164220,
  "global_competetive_mining_tithe": 14,
  "competetive_mining_ratio": 0,
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 38,
  "poolmining": false,
  "pool_url": "",
  "poolmining_use_ssl": false,
  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 45129,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""

But now I also get the same loyalty_error:

Code: [Select]
  "blocks": 3048,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 0.8104548490020034,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 430086389.9288061,
  "hashps": 139.4398538501017,
  "minerstarttime": "01-21-2018 20:10:06",
  "ratio": 1,
  "hc1": 9273811,
  "bhc2": 16048595,
  "hashcounter": 9273811,
  "competetive_mining": true,
  "competetivemining_hash_counter": 8735280,
  "global_competetive_mining_tithe": 648,
  "competetive_mining_ratio": 0,
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 1973,
  "poolmining": false,
  "pool_url": "",
  "poolmining_use_ssl": false,
  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": "INSUFFICIENT FUNDS, ENSURE WALLET IS UNLOCKED"

I didn't change anything and the wallet is unlocked.

Code: [Select]
"Command": "stakebalance",
  "StakeBalance": 341681
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: klondike on January 22, 2018, 09:20:48 am
Quote
16:20:17

{
  "blocks": 3077,
  "currentblocksize": 0,
  "currentblocktx": 0,
  "difficulty": 1.436729951330732,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 611722846.6623292,
  "hashps": 0,
  "minerstarttime": "1-1-1970 00:00:00",
  "ratio": 0,
  "hc1": 0,
  "bhc2": 0,
  "hashcounter": 0,
  "competetive_mining": true,
  "competetivemining_hash_counter": 0,
  "global_competetive_mining_tithe": 0,
  "competetive_mining_ratio": 0,
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": false,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 0,
  "poolmining": false,
  "pool_url": "",
  "poolmining_use_ssl": false,
  "proof_of_loyalty_target_percentage": 1,
  "proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""
}

im on bad chain ?  blocks 3077  :o

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 22, 2018, 09:43:59 am
It's probably alright :) We have fast blocks now, I think.

Code: [Select]
./biblepay-cli -testnet getblockhash 3092
eadb8e4f7a78776f8699574ab6bf8a1fe0b9bbc0f6e60c8711eef038cd577770
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: klondike on January 22, 2018, 10:30:29 am
but its weird that this info is 0 after 48hours. Can you check if your wallet still syncing masternods?


"proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 22, 2018, 12:04:50 pm
but its weird that this info is 0 after 48hours. Can you check if your wallet still syncing masternods?


"proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,

Yes, that's true. Your 'loyalty_weight' should - in my opinion - be more than zero, or something is wrong with staking.

I can see that mine is more than zero again:

Code: [Select]
"proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 26201,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""

Also, I don't think there are active masternodes on the testnet now?
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: klondike on January 22, 2018, 12:35:53 pm
by me POS is dead ....


Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 22, 2018, 01:49:29 pm
Yes, that's true. Your 'loyalty_weight' should - in my opinion - be more than zero, or something is wrong with staking.

I can see that mine is more than zero again:

Code: [Select]
"proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 26201,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""

Also, I don't think there are active masternodes on the testnet now?

Yes your correct, its working for you.  Your influence is just 0 because of the low number of blocks we had, we havent really emitted much money supply.

No mn's on testnet yet either, since we rejumped the chain.



As far as Clusters issue  -   I will try to create a proof-of-loyalty diagnostic command.  Let me see....

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 22, 2018, 03:20:17 pm
So Im going through the punchlist, checking to make sure I have everything for the next testnet release:

Money supply to take Locked coins from Sancs into account (making POL easier)
Remove decimal formatting problem in Tx List
Make POL boost more granular (IE not jump from 2% to 5%)
Make 16 min late block threshhold (to move us from 10 min to 7 min block targets)
Ensure POL age is correct to not ddos each other
Add ability to see POL in listtransactions for the daemon
Superblock budget based on a 1.5 diff (in contrast to 750,000 diff)



I was going to add a feature to diagnose POL inability to stake and then I realized, in coin control you can already see how old all of your inputs are.  This makes it easy enough for a 3 year old to do it.  Just look at your inputs and make sure they are over 24 hours old.  Then do an exec stakebalance.  I dont want to pollute the code base for something so simple. 

Anything else we need in this next release?


Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: tiras on January 22, 2018, 09:31:50 pm
Rob ,  do you need test wallets running  for now or we can shut them down until the next  test build ?


my current status :

exec stakebalance
{
  "Command": "stakebalance",
  "StakeBalance": 605039
}


  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 46178,
  "proof_of_loyalty_influence_percentage": 0,
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 23, 2018, 02:21:45 am
My staking seems to be buggy again:

Code: [Select]
"Command": "stakebalance",
  "StakeBalance": 477233

Code: [Select]
{
  "walletversion": 61000,
  "balance": 477233.94799278,
  "retirement_account_balance": 23732,
  "unconfirmed_balance": 0.00000000,
  "immature_balance": 33875.89999999,
  "txcount": 4447,
  "keypoololdest": 1508425662,
  "keypoolsize": 1001,
  "keys_left": 1000,
  "paytxfee": 0.00000000
}

Code: [Select]
"blocks": 3796,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 1.077559275214575,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 594220480.0499583,
  "hashps": 139.3632057089721,
  "minerstarttime": "01-21-2018 20:10:06",
  "ratio": 1,
  "hc1": 18143777,
  "bhc2": 31148577,
  "hashcounter": 18143777,
  "competetive_mining": true,
  "competetivemining_hash_counter": 17091120,
  "global_competetive_mining_tithe": 1246,
  "competetive_mining_ratio": 0,
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 3859,
  "poolmining": false,
  "pool_url": "",
  "poolmining_use_ssl": false,
  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": "INSUFFICIENT FUNDS, ENSURE WALLET IS UNLOCKED"
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 23, 2018, 08:37:46 am
My staking seems to be buggy again:

Code: [Select]
"Command": "stakebalance",
  "StakeBalance": 477233

Code: [Select]
{
  "walletversion": 61000,
  "balance": 477233.94799278,
  "retirement_account_balance": 23732,
  "unconfirmed_balance": 0.00000000,
  "immature_balance": 33875.89999999,
  "txcount": 4447,
  "keypoololdest": 1508425662,
  "keypoolsize": 1001,
  "keys_left": 1000,
  "paytxfee": 0.00000000
}

Code: [Select]
"blocks": 3796,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 1.077559275214575,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 594220480.0499583,
  "hashps": 139.3632057089721,
  "minerstarttime": "01-21-2018 20:10:06",
  "ratio": 1,
  "hc1": 18143777,
  "bhc2": 31148577,
  "hashcounter": 18143777,
  "competetive_mining": true,
  "competetivemining_hash_counter": 17091120,
  "global_competetive_mining_tithe": 1246,
  "competetive_mining_ratio": 0,
  "pooledtx": 0,
  "testnet": true,
  "chain": "test",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 3859,
  "poolmining": false,
  "pool_url": "",
  "poolmining_use_ssl": false,
  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 0,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": "INSUFFICIENT FUNDS, ENSURE WALLET IS UNLOCKED"


Its not really buggy though, well, let me explain the logic.  Im apprehensive about taking the message out "insufficient funds ensure wallet is unlocked", because we are going to have people out there with encrypted locked wallets.  Thats going to at least cause them to try to unlock the wallet for 900,000 seconds and attempt to stake.  Thats a different subject.

Your client attempts to stake 30% of your coin-age.  When it finds that percent of your wallet, 140,000 BBP over 202 confirms old, it then goes through and clears the error and makes a POL transaction inside the block. 

So its just basically trying once every minute to do that, and reporting the insufficient funds error.  I dont know Im sure we can make that a little clearer but I also dont want to pollute the code.

So technically its working as soon as it has enough age.  If you go through your 24 hour history you will probably find one POL every so many hours.

Not sure if you all are using the biblepay-qt wallet for this, but its easier to see the tx list with POL in QT.  In the next version I do label the listtransactions with POL.

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 23, 2018, 08:40:14 am
Rob ,  do you need test wallets running  for now or we can shut them down until the next  test build ?


my current status :

exec stakebalance
{
  "Command": "stakebalance",
  "StakeBalance": 605039
}


  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 46178,
  "proof_of_loyalty_influence_percentage": 0,




I would go ahead and review how many POLs you got but then just shut it down.

Ive got the new version about 95% ready, but I need to finalize a pool feature to address the naysayers in prod with that, then release it all at the same time.  The ETA is before the end of the day today.

Thanks for testing!

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 23, 2018, 08:53:07 am
Jaap,

I thought about it and maybe your right- I think the issue is exec stakebalance shows coins over 24 hours old, but the stakeminer requires 202 confirms + over 24 hour old.

Let me adjust exec stakebalance, and the error message to be clear when user has no coins to stake.  That wont pollute anything and it will make it clearer.


Disregard most of what I said except the part the reveals the issue.

Thanks for pointing out the problem.


Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: tiras on January 23, 2018, 09:33:07 am



I would go ahead and review how many POLs you got but then just shut it down.

Ive got the new version about 95% ready, but I need to finalize a pool feature to address the naysayers in prod with that, then release it all at the same time.  The ETA is before the end of the day today.

Thanks for testing!


 why proof of loyalty weight dropped   from 153108 to 131920 ??

  "StakeBalance": 605039  didnt change .


Code: [Select]
09:43:26
  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 153108,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""
}


10:27:01

getmininginfo


10:27:01
  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 131920,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""
}


10:27:11

exec stakebalance


10:27:11

{
  "Command": "stakebalance",
  "StakeBalance": 605039
}
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 23, 2018, 11:20:02 am

 why proof of loyalty weight dropped   from 153108 to 131920 ??

  "StakeBalance": 605039  didnt change .


Code: [Select]
09:43:26
  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 153108,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""
}


10:27:01

getmininginfo


10:27:01
  "proof_of_loyalty_target_percentage": 0.3,
  "proof_of_loyalty_weight": 131920,
  "proof_of_loyalty_influence_percentage": 0,
  "proof_of_loyalty_errors": ""
}


10:27:11

exec stakebalance


10:27:11

{
  "Command": "stakebalance",
  "StakeBalance": 605039
}


Weight = coin_age * amount.


If you look at your last POL block, using showblock blocknumber, you can then read the internal characteristics of the age and the amount.


Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 23, 2018, 12:18:29 pm

1.0.8.4-Leisure for Prod
Mandatory for TestNet
Mandatory for Pool Miners to upgrade before block 27500

Production:
- Enhanced pool protocol required for submitting pool solutions (goes live on block 27500)

Test:
- Money Supply estimate fixed to include sanctuaries
- POL StakeMiner verbose errors
- More granular POL weight
- 16 minute late block threshhold (for future 7 min blocks in prod)
- Fix for superblock budget amount to be based on 1.5 Diff





Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: klondike on January 23, 2018, 01:07:30 pm
i have

{
  "Command": "stakebalance",
  "StakeBalance": 3232762
}


but my pol doesnt working  :-\


is any problem with peers on v183 testnet i cant connect to any peerers and i cant mining with new version:  config setuped and setgenerate true doesnt working too
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 23, 2018, 03:14:14 pm
i have

{
  "Command": "stakebalance",
  "StakeBalance": 3232762
}


but my pol doesnt working  :-\

is any problem with peers on v183 testnet i cant connect to any peerers and i cant mining with new version:  config setuped and setgenerate true doesnt working too

You still can't mine? I just updated and I can mine. I have 1 connection.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: klondike on January 23, 2018, 05:36:09 pm
im mining now ...

(https://i.imgur.com/ltZyYFZ.png)
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 23, 2018, 07:26:08 pm
Are we on the same chain:


19:24:18

getblockhash 4437


19:24:18

5f4a1003c7fff57dbb52bd774a2ecdec696755ba5bf0a0b382f9c2245e98a8bf


Btw, if anyone cant sync up to 4437, I pushed an optional linux upgrade (1084c) out that grandfathers the testnet client up to block 4437.

Windows unfortunately is hosed for tonight (unless you already synced past 4400 then you are OK).

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 24, 2018, 01:17:01 am
Are we on the same chain:


19:24:18

getblockhash 4437


19:24:18

5f4a1003c7fff57dbb52bd774a2ecdec696755ba5bf0a0b382f9c2245e98a8bf


Btw, if anyone cant sync up to 4437, I pushed an optional linux upgrade (1084c) out that grandfathers the testnet client up to block 4437.

Windows unfortunately is hosed for tonight (unless you already synced past 4400 then you are OK).

I'm on the same chain. I only have one connection though (87.197.*.*). I'm on Linux with the GUI wallet now :)
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: klondike on January 24, 2018, 02:09:28 am
87 its me and my POS working perfect now

stakebalance will be raise or?  my stake balance falling


"StakeBalance": 15696
"StakeBalance": 9372
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 24, 2018, 09:24:29 am
87 its me and my POS working perfect now

stakebalance will be raise or?  my stake balance falling


"StakeBalance": 15696
"StakeBalance": 9372


Stakebalance drops after you stake a POL block (run the ./biblepay-qt -testnet gui version to see the tx list), then it slowly rises as coin-age accrues again.

If you want to see the effect better, set your polpercentage=0, restart, then watch it rise, then go back and set it to =100 then watch it get hammered down.


Stakebalance is just your mature stakeable coins with > 24 hours of coin-age.

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 25, 2018, 08:31:11 am
Are we all still on the same chain, please everyone check:


08:14:27

getblockhash 5920


08:14:27

662a54eefc26dea8333f8758c70551116b03c025afa1d07c32c0497447a752fe



Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 25, 2018, 08:37:46 am
Are we all still on the same chain, please everyone check:


08:14:27

getblockhash 5920


08:14:27

662a54eefc26dea8333f8758c70551116b03c025afa1d07c32c0497447a752fe

I am :)

Code: [Select]
15:37:18

getblockhash 5920


15:37:18

662a54eefc26dea8333f8758c70551116b03c025afa1d07c32c0497447a752fe

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Lichtsucher on January 25, 2018, 09:15:07 am
I Rob, I want to start testing it, too.

Can you send me some coins to my testnet Wallet: yQiXLmo6a1MB169ipHhfdqfjshw9gEns1f
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 25, 2018, 10:55:36 am
I Rob, I want to start testing it, too.

Can you send me some coins to my testnet Wallet: yQiXLmo6a1MB169ipHhfdqfjshw9gEns1f

I've sent you 500.000 tBBP :)
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: inblue on January 25, 2018, 01:02:59 pm
I just fired up testnet (1.0.8.6 on Windows), and in the wallet I see an old transaction which is unconfirmed now and the wallet shows 0 available balance. TX ID: 4eb9ab75a914da64afdbe7c79c5118bdd07c76a2d69a9c8f6151058fd4782172

My latest block is 6120 and this is its hash: 1079b5b08ef1719c066856a65b7401c8104f46bbd9d12727bee556c8cc5874cc

Btw, I have 5 active connections and I see blocks are being mined, it's not stuck. So am I on a fork or something else?
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 25, 2018, 01:11:59 pm
I just fired up testnet (1.0.8.6 on Windows), and in the wallet I see an old transaction which is unconfirmed now and the wallet shows 0 available balance (look at the pic in the attachment). TX ID: 4eb9ab75a914da64afdbe7c79c5118bdd07c76a2d69a9c8f6151058fd4782172

My latest block is 6120 and this is its hash: 1079b5b08ef1719c066856a65b7401c8104f46bbd9d12727bee556c8cc5874cc

Btw, I have 5 active connections and I see blocks are being mined, it's not stuck. So am I on a fork or something else?

Nope you are on the right chain; the balance is 0 because we erased the chain.
Sweet, you are synced.

Whats your address Ill send you some?

EDIT: To remove your orphaned transactions, just restart with -zapwallettxes

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: inblue on January 25, 2018, 01:19:51 pm
Nope you are on the right chain; the balance is 0 because we erased the chain.
Sweet, you are synced.

Whats your address Ill send you some?

EDIT: To remove your orphaned transactions, just restart with -zapwallettxes

I deleted wallet.dat and restarted, I guess that works too? ;D But thanks for the command -zapwallettxes, I'm learning so much. :)

My testnet address: yigNrPFK8wLWCqpiwdg45W91sXnuvFeEdT

Thanks!

EDIT: Wow you were fast :D
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 26, 2018, 02:33:15 pm
So Im thinking about worst case scenario if we raise the magnitude of the Proof-of-loyalty equation.

Right now, it gives one who controls 1% of the money supply the ability to stake approx. once per day.
Its doing this by giving you a 90% level of the hashing required to solve the block (relative to the difficulty at the time).
Meaning that we are probably going to raise the diff in prod by about 50%.

However what I am seeing is that most normal users who leave the stake setting at 10%, will generally see a POL influence of 0.

Im considering raising the influence level 10*.  What I believe this will do is temporarily raise the diff for everyone in prod while all the stakers stake, then, it will start to normalize.  And then that would mean throughout the day, those with lower balances would actually stake with an influence of 2-3%.

I think that ecosystem is healther for the future- and for the propensity to stake on a jamaican cell phone.


Any disagreements to doing this in the next version?

The plan would be to add a constant to the algorithm: number of stakes per day, and basically set it to 10 and re-test.

And, of course I welcome any other recommendations for the next version for testnet.


Btw, if anyone wants to test on additional nodes side by side your prod node if it is a masternode type this:

./biblepay-qt -testnet -masternode=0 -rpcport=40000

That will let you boot side by side your masternode in prod.

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 28, 2018, 07:41:09 am
Sound good! I really like the idea of mining on a cellphone.

I loved the Bitcoin-idea of 'banking the unbanked', and I can't wait to see a future evolve in which everyone can transact money between each other in a trustless way :)
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 28, 2018, 08:09:33 am
Sound good! I really like the idea of mining on a cellphone.

I loved the Bitcoin-idea of 'banking the unbanked', and I can't wait to see a future evolve in which everyone can transact money between each other in a trustless way :)

Yes, the unbanked project sounds extremley exciting and Huge for us.

So heres what I plan on doing:

- Switch influence to a float with 2 decimals so we are more granular
- Raise influence by 10*
- Ensure syncing on a bad chain doesnt spam with thousands of errors
- Ensure pol error works in log similar to checkblock error
- Ensure resync from 0 works in testnet

- Write proof-of-concept for Luke and Togo



Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Lichtsucher on January 29, 2018, 06:02:49 am
I'm not sure if I do it right, I had a POL error message the whole time:
"proof_of_loyalty_errors": "BALANCE TOO LOW TO STAKE"

{
  "Command": "stakebalance",
  "StakeBalance": 0
}

{
  "walletversion": 61000,
  "balance": 10418865.62299800,
  "retirement_account_balance": 0,
  "unconfirmed_balance": 0.00000000,
  "immature_balance": 752689.42450000,
  "txcount": 810,
  "keypoololdest": 1516891781,
  "keypoolsize": 1001,
  "keys_left": 999,
  "paytxfee": 0.00000000
}

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 29, 2018, 09:51:58 am
I'm not sure if I do it right, I had a POL error message the whole time:
"proof_of_loyalty_errors": "BALANCE TOO LOW TO STAKE"

{
  "Command": "stakebalance",
  "StakeBalance": 0
}

{
  "walletversion": 61000,
  "balance": 10418865.62299800,
  "retirement_account_balance": 0,
  "unconfirmed_balance": 0.00000000,
  "immature_balance": 752689.42450000,
  "txcount": 810,
  "keypoololdest": 1516891781,
  "keypoolsize": 1001,
  "keys_left": 999,
  "paytxfee": 0.00000000
}

Were you also mining this whole time?
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Lichtsucher on January 29, 2018, 09:54:18 am
Were you also mining this whole time?

Yes, I had forgotten the maschine over the weekend, but it was mining and had found a lot of blocks on the testnet.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on January 29, 2018, 10:03:15 am
Yes, I had forgotten the maschine over the weekend, but it was mining and had found a lot of blocks on the testnet.

Okay :) I just wanted to make sure.

Uhm... Are you using the GUI wallet? Then you can easily check if you had POL transactions in the 'transaction' tab.

Because if I get it right, you need a certain threshold to be able to stake coins. And after it stakes, it goes back to zero and you have a 'BALANCE TOO LOW TO STAKE' notification. So maybe you just checked at the 'wrong' times.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: inblue on January 29, 2018, 03:15:01 pm
By the way, is PoL working in prod as we speak?! :o

This pic is from a user from Discord who solo mined a block yesterday. And this is his current stake balance:
{
  "Command": "stakebalance",
  "StakeBalance": 51302
}

He says that the stake is the same as his total wallet balance and that his last mined block was ~18 hrs ago.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: inblue on January 29, 2018, 04:07:07 pm
I just wanted to report about PoL testing, I'm not familiar with how it should work exactly, it seems it's working all right, but I wanted to check. :)

I fired up the testnet wallet, it immediately found a block because I presume my stake was large (758k BBP), got a PoL transaction with it, then it found the next two blocks with PoL in a few minutes. I had 725k received from Rob and had two more mined blocks about 17k each. Then I was able to find more blocks, but it took more time and there were no PoL transactions anymore. So I had a PoL transaction for each of my inputs (first for the 725k input, second and third for the 17k mined block inputs), is that as expected? It was still staked as total balance, for the first PoL tx when I had 758k - PoL weight was 75.8k (is that normal to be 10% of the balance?), then for the second PoL tx when I had remaining 34k balance (from two mined blocks), PoL weight was 3.4k and finally, for the last 17k balance, PoL weight was 1.7k in the third and final PoL tx. But in the tx details I can also see this:
Debit: -725,000.00000000 tBiblepay
Credit: 75,886.91004126 tBiblepay
Credit: 649,113.08995874 tBiblepay

I see that the first credit is same as the PoL stake weight, and the debit is the balance which was staked, so the second credit is just change? But this means it takes only from one input, not from all?

Also, if I understand correctly, 24 hrs need to pass for the coins to be staked again and have PoL txs? Then I'm wondering what does that mean in the scenario where I can normally find let's say 2 blocks per day with my hash rate, but because of the staking 24 hrs reset (or call it luck increase reset), does that mean my "normal" block find rate will be pushed more to 1 per day (say 1.3 per day instead of 2 per day)? But this is obviously an advantage for small hash power miners, which is good.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Swongel on January 29, 2018, 05:17:52 pm
Regarding Proof of Loyalty in it's current form:

Assuming the following (from earlier posts on Bitcoin Talk and the forum):

- 1% of the coins should yield 1 block per day we can safely assume 2 days will nearly guarentee a block.
- Waiting 20 days with 1% of the coins will build up a coinage which will allow the miner to mine 10 consecutive blocks; therefor allowing the single actor to create a 51% attack using a fraction of the network hashing capacity and money supply.

A bad actor with a small pocket could launch such an attack simply by waiting longer for their coinage to build up. Due to the very nature of the block chain and trust I believe the current proposal would greatly harm the foundation on which BiblePay was build.

Furthermore, Proof of Loyalty would benefit rich users more than poor users of Bible Pay generating an ever growing divide between the two; those who have more money will be able to easily mine more and therefor have more of an advantage mining. A person with twice the amount of coins would build up twice the amount of coinage each day.

As possible alternative I would suggest we look towards a new algorithm or solution in order to solve the bot net problem, we could perhaps look towards the fact that many Chinese PC's still use older versions of Operating Systems, if we require the algorithm to use functionality only availible in the newest Operating Systems it should be possible to circumvent or at least make it less profitable to run on a malicious chinese bot net.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 30, 2018, 12:19:53 pm
Regarding Proof of Loyalty in it's current form:

Assuming the following (from earlier posts on Bitcoin Talk and the forum):

- 1% of the coins should yield 1 block per day we can safely assume 2 days will nearly guarentee a block.
- Waiting 20 days with 1% of the coins will build up a coinage which will allow the miner to mine 10 consecutive blocks; therefor allowing the single actor to create a 51% attack using a fraction of the network hashing capacity and money supply.

A bad actor with a small pocket could launch such an attack simply by waiting longer for their coinage to build up. Due to the very nature of the block chain and trust I believe the current proposal would greatly harm the foundation on which BiblePay was build.

Furthermore, Proof of Loyalty would benefit rich users more than poor users of Bible Pay generating an ever growing divide between the two; those who have more money will be able to easily mine more and therefor have more of an advantage mining. A person with twice the amount of coins would build up twice the amount of coinage each day.

As possible alternative I would suggest we look towards a new algorithm or solution in order to solve the bot net problem, we could perhaps look towards the fact that many Chinese PC's still use older versions of Operating Systems, if we require the algorithm to use functionality only availible in the newest Operating Systems it should be possible to circumvent or at least make it less profitable to run on a malicious chinese bot net.


Hi Swongel, welcome aboard, thanks.

Ive been waiting for someone like you to come along for this exact reason.
So wait lets not throw the baby out with the bathwater here.
I accept your risk on point 1, that if there is *any* chance of a 51% attack, we need to kill the idea.

But - the idea of using coin*age to make a hybrid proof-of-stake/proof-of-work is still a solid way to stave off a botnet, as it requires a unique provable txout to be presented in the block, in order to gain a hashing advantage, something that is very valuable in this algo, and still, the best idea so far for starving a botnet, as I feel keeping money on a machine is something they wont do. 

So lets take this one step at a time.  Let me understand the 51% attack vector.  Lets say I am greedy with my stake, and let the coin age build up, then in a rush I attack the chain by emitting 10 blocks at once.  Please, bear with me.  Why does that give me an advantage of creating my own fork after my coin age runs out?  I mean I see the problem, of having 10 blocks, but how do I have the propensity to control the chain as in a 51% attack after block 10?

It seems to me that we would be better off limiting POL's with weight > say 10,000 to every other block.  We could just say block mod % 2 == 0 requires weight < 10,000.  Then no one with saved up weight could stake more than one in a row.

Regarding furthering the divide- this system does not pay interest, so I disagree that it will perpetually further the divide much more than the propensity to go out and buy bbp and further the divide.  Although, I would consider capping the POL weight to 1% of the money supply so that for one who accumulates a lot of coin age, the cap is hit and could not continue getting fatter and richer.  That would only work if the above rule (mod %2) was implemented.  I dont care if we go mod % 3.  We only have 150 blocks per day, so a rule like that would kill the fat cat.


Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 30, 2018, 12:29:49 pm
I just wanted to report about PoL testing, I'm not familiar with how it should work exactly, it seems it's working all right, but I wanted to check. :)

I fired up the testnet wallet, it immediately found a block because I presume my stake was large (758k BBP), got a PoL transaction with it, then it found the next two blocks with PoL in a few minutes. I had 725k received from Rob and had two more mined blocks about 17k each. Then I was able to find more blocks, but it took more time and there were no PoL transactions anymore. So I had a PoL transaction for each of my inputs (first for the 725k input, second and third for the 17k mined block inputs), is that as expected? It was still staked as total balance, for the first PoL tx when I had 758k - PoL weight was 75.8k (is that normal to be 10% of the balance?), then for the second PoL tx when I had remaining 34k balance (from two mined blocks), PoL weight was 3.4k and finally, for the last 17k balance, PoL weight was 1.7k in the third and final PoL tx. But in the tx details I can also see this:
Debit: -725,000.00000000 tBiblepay
Credit: 75,886.91004126 tBiblepay
Credit: 649,113.08995874 tBiblepay

I see that the first credit is same as the PoL stake weight, and the debit is the balance which was staked, so the second credit is just change? But this means it takes only from one input, not from all?

Also, if I understand correctly, 24 hrs need to pass for the coins to be staked again and have PoL txs? Then I'm wondering what does that mean in the scenario where I can normally find let's say 2 blocks per day with my hash rate, but because of the staking 24 hrs reset (or call it luck increase reset), does that mean my "normal" block find rate will be pushed more to 1 per day (say 1.3 per day instead of 2 per day)? But this is obviously an advantage for small hash power miners, which is good.

So on the coin age accrual, since you waited a day, and the default POL percentage is .10, your wallet mined consecutive blocks using the weight available during each iteration, until the stakeweight ran out.  You quickly mined because you raised the hashtarget up high due to your weight.

Regarding the debit - credit in the tx description, Yes, since its a payment from you to you, you can just see the details of the original vout (your original UTXO, unspent coin), and the details of the payment to you.  To answer your question on the amount of inputs,
the system is smart enough to keep finding multiple inputs until the stakeweight % is met.  So if you have 1 million UTXOs of 10K each, and your staketarget is 100K, it will make 10 inputs.  In the case of the one you were viewing it did not have to as it found a large one.

If you send some smaller bbp to yourself 10 times, and split your wallet up into smaller coins, then test again you will see the example form with multi inputs.

Yes, 24 hours of coin age needs to pass before the "exec stakebalance" and the stakeminer finds any coins in the available coins vector.

As far as the block find rate for you personally, yes this would put you on a schedule where your single wallet would go from 0 activity (unless you get lucky on the POW side) to high activity, and it would oscillate.  But I think with a few thousand miners out there we will overlap efforts, so thats not a problem.

Let me know if I failed to answer anything!  Thanks for testing.


Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: inblue on January 30, 2018, 01:52:20 pm
So on the coin age accrual, since you waited a day, and the default POL percentage is .10, your wallet mined consecutive blocks using the weight available during each iteration, until the stakeweight ran out.  You quickly mined because you raised the hashtarget up high due to your weight.

Regarding the debit - credit in the tx description, Yes, since its a payment from you to you, you can just see the details of the original vout (your original UTXO, unspent coin), and the details of the payment to you.  To answer your question on the amount of inputs,
the system is smart enough to keep finding multiple inputs until the stakeweight % is met.  So if you have 1 million UTXOs of 10K each, and your staketarget is 100K, it will make 10 inputs.  In the case of the one you were viewing it did not have to as it found a large one.

If you send some smaller bbp to yourself 10 times, and split your wallet up into smaller coins, then test again you will see the example form with multi inputs.

Yes, 24 hours of coin age needs to pass before the "exec stakebalance" and the stakeminer finds any coins in the available coins vector.

As far as the block find rate for you personally, yes this would put you on a schedule where your single wallet would go from 0 activity (unless you get lucky on the POW side) to high activity, and it would oscillate.  But I think with a few thousand miners out there we will overlap efforts, so thats not a problem.

Let me know if I failed to answer anything!  Thanks for testing.

Thank you very much for the thorough explanation and patience! You have answered everything. :)
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Swongel on January 30, 2018, 02:39:56 pm

Hi Swongel, welcome aboard, thanks.

Ive been waiting for someone like you to come along for this exact reason.
So wait lets not throw the baby out with the bathwater here.
I accept your risk on point 1, that if there is *any* chance of a 51% attack, we need to kill the idea.

But - the idea of using coin*age to make a hybrid proof-of-stake/proof-of-work is still a solid way to stave off a botnet, as it requires a unique provable txout to be presented in the block, in order to gain a hashing advantage, something that is very valuable in this algo, and still, the best idea so far for starving a botnet, as I feel keeping money on a machine is something they wont do. 

So lets take this one step at a time.  Let me understand the 51% attack vector.  Lets say I am greedy with my stake, and let the coin age build up, then in a rush I attack the chain by emitting 10 blocks at once.  Please, bear with me.  Why does that give me an advantage of creating my own fork after my coin age runs out?  I mean I see the problem, of having 10 blocks, but how do I have the propensity to control the chain as in a 51% attack after block 10?

It seems to me that we would be better off limiting POL's with weight > say 10,000 to every other block.  We could just say block mod % 2 == 0 requires weight < 10,000.  Then no one with saved up weight could stake more than one in a row.

Regarding furthering the divide- this system does not pay interest, so I disagree that it will perpetually further the divide much more than the propensity to go out and buy bbp and further the divide.  Although, I would consider capping the POL weight to 1% of the money supply so that for one who accumulates a lot of coin age, the cap is hit and could not continue getting fatter and richer.  That would only work if the above rule (mod %2) was implemented.  I dont care if we go mod % 3.  We only have 150 blocks per day, so a rule like that would kill the fat cat.

Hi Rob,

The attack would play out as the following:

Malroy has 1% of the coins in a wallet with a coinage of 20 days; malroy transacts those coins to Alice in a transaction, after 6 confirmations Alice would think the coins have safely arived, then Malroy begins to mine on the block before the transaction to Alice with the high coin age instantly building a fork of 10 new blocks, the network will now follow the fork and Alice will lose her coins she though to be transacted.

If the attack fails; Malroy could choose not to broadcast the 10 blocks and no one would ever be the wiser.

Capping the amount of weight would help, and I very much like the concept of adding a modulo, however to prevent a double spend to happen with less than 51% of the network we would need a block without any PoL weight in the mix (thus requiring more than 51% of the network to mine).

Concidering the idea of using the modulo:

Assuming for simplicity: if(BLOCK_HEIGHT % 2 == 0) MAX_POL_WEIGHT = 0;
Would require a 10 block fork to mine 5 blocks in the time the normal chain mines 10 blocks, thus halving the required hashpower for a double spend attack from 51% to 25.5%.

Making this MAX_POL_WEIGHT parameter higher would decrease the required double spend hashrate.

I like it since it would make the attack vector way smaller, but I don't like it because it would still make the required hashrate lower than 51% breaking the spirit of true consensus.

The amount of percentage taken away from the botnet (or miners without stake) would be inversely correlated to the amount of hashes needed to launch a double spend attack. (50% less botnet reward, 50% less hashes needed to launch double spend).
 

Ways of mitigation could be:
- Using the modulo (but this still keeps some adverse effects for double spending)
- Limiting the amount of days coinage can be build up (requiring more coins to create large amounts of coin age)
- Preventing staked coins from being spend (requiring more coins to exploit, Malroy would need to exchange a different set of coins with Allice).

However I don't think these mitigations would be enough because it would still be possible to double spend with less than 51% of the network, something I don't think is a great idea considering the current global hash rates aren't too high for an attack to be unfeasible.

Regarding making the wealth gap larger: having more coins will allow you to accrue coinage faster therefor making mining easier making it harder for poor people to mine relative to the average, however servers and hardware also cost money so this is probably already the case, I doubt PoL would make it worse or better having thought some more about it.

Considering the problem of consensus without trust using Proof of Work lowering the amount of hash power needed to double spend lower than 51% would be - In my opinion - not worth the trade off.
Especially considering the global hash rate for Bible Pay is well within reach of a large botnet.

If PoL would still be implemented which I would advise against considering the above; I would highly recommend having the modulo with a low MAX_POL_HEIGHT (ideally 0), limiting the max amount of days for coin age to build up and generally keeping the POL_HEIGHT low.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 30, 2018, 03:52:26 pm
Hi Rob,

The attack would play out as the following:

Malroy has 1% of the coins in a wallet with a coinage of 20 days; malroy transacts those coins to Alice in a transaction, after 6 confirmations Alice would think the coins have safely arived, then Malroy begins to mine on the block before the transaction to Alice with the high coin age instantly building a fork of 10 new blocks, the network will now follow the fork and Alice will lose her coins she though to be transacted.

If the attack fails; Malroy could choose not to broadcast the 10 blocks and no one would ever be the wiser.

Capping the amount of weight would help, and I very much like the concept of adding a modulo, however to prevent a double spend to happen with less than 51% of the network we would need a block without any PoL weight in the mix (thus requiring more than 51% of the network to mine).

Concidering the idea of using the modulo:

Assuming for simplicity: if(BLOCK_HEIGHT % 2 == 0) MAX_POL_WEIGHT = 0;
Would require a 10 block fork to mine 5 blocks in the time the normal chain mines 10 blocks, thus halving the required hashpower for a double spend attack from 51% to 25.5%.

Making this MAX_POL_WEIGHT parameter higher would decrease the required double spend hashrate.

I like it since it would make the attack vector way smaller, but I don't like it because it would still make the required hashrate lower than 51% breaking the spirit of true consensus.

The amount of percentage taken away from the botnet (or miners without stake) would be inversely correlated to the amount of hashes needed to launch a double spend attack. (50% less botnet reward, 50% less hashes needed to launch double spend).
 

Ways of mitigation could be:
- Using the modulo (but this still keeps some adverse effects for double spending)
- Limiting the amount of days coinage can be build up (requiring more coins to create large amounts of coin age)
- Preventing staked coins from being spend (requiring more coins to exploit, Malroy would need to exchange a different set of coins with Allice).

However I don't think these mitigations would be enough because it would still be possible to double spend with less than 51% of the network, something I don't think is a great idea considering the current global hash rates aren't too high for an attack to be unfeasible.

Regarding making the wealth gap larger: having more coins will allow you to accrue coinage faster therefor making mining easier making it harder for poor people to mine relative to the average, however servers and hardware also cost money so this is probably already the case, I doubt PoL would make it worse or better having thought some more about it.

Considering the problem of consensus without trust using Proof of Work lowering the amount of hash power needed to double spend lower than 51% would be - In my opinion - not worth the trade off.
Especially considering the global hash rate for Bible Pay is well within reach of a large botnet.

If PoL would still be implemented which I would advise against considering the above; I would highly recommend having the modulo with a low MAX_POL_HEIGHT (ideally 0), limiting the max amount of days for coin age to build up and generally keeping the POL_HEIGHT low.


Excellent! 

Thank you for coming to our community, you are a God send.

I agree with you 100% on every point, and even on Not implementing POL with the modulus of %2, if it yields a 25% attack vector, we need to plug that vector to consider POL. 

On the rich-getting-richer, I think we should still limit one particular stake instance to 1% of money supply with some type of Max weight, just to ensure its not "too easy" to solve any block, at that point, one relinquishes the stored up massive coin age but receives limited weight for that coinstake.  That should at least partially block the rich-getting-richer although it seems we both agree that is a minor effect compared to the double spend risk.

Let me think about a couple of other things.  But in the mean time, I have a question, If we implement the %2 modulus, and totally decline POL weight every other block, requiring a pure POW block, (IE weight is always 0 on it), wouldn't that break the ability for Malroy's double spend in that he has 0% to control the future of any single block - thereby dropping the rate of double spend to closer to zero and not 25%?   Could you please analyze that scenario in your head and verify the reality is still 25% and not .01% risk for this type of system?  The reason I ask is I believe blackcoin was there and I have heard of some coins that force an alternating POW/POS, and I am thinking they are not subject to such a high degree of a 51% attack - I know POS has that vulnerability but it is also based on concentration of the money supply (IE how many distinct large whales we have).  I think there is also one other element we have to consider, when someone POL mines, DGW should technically be "raising" the average diff making it rather hard to mine those in-between blocks - which should really be good for security.



Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Swongel on January 30, 2018, 04:11:54 pm

Excellent! 

Thank you for coming to our community, you are a God send.

I agree with you 100% on every point, and even on Not implementing POL with the modulus of %2, if it yields a 25% attack vector, we need to plug that vector to consider POL. 

On the rich-getting-richer, I think we should still limit one particular stake instance to 1% of money supply with some type of Max weight, just to ensure its not "too easy" to solve any block, at that point, one relinquishes the stored up massive coin age but receives limited weight for that coinstake.  That should at least partially block the rich-getting-richer although it seems we both agree that is a minor effect compared to the double spend risk.

Let me think about a couple of other things.  But in the mean time, I have a question, If we implement the %2 modulus, and totally decline POL weight every other block, requiring a pure POW block, (IE weight is always 0 on it), wouldn't that break the ability for Malroy's double spend in that he has 0% to control the future of any single block - thereby dropping the rate of double spend to closer to zero and not 25%?   Could you please analyze that scenario in your head and verify the reality is still 25% and not .01% risk for this type of system?  The reason I ask is I believe blackcoin was there and I have heard of some coins that force an alternating POW/POS, and I am thinking they are not subject to such a high degree of a 51% attack - I know POS has that vulnerability but it is also based on concentration of the money supply (IE how many distinct large whales we have).  I think there is also one other element we have to consider, when someone POL mines, DGW should technically be "raising" the average diff making it rather hard to mine those in-between blocks - which should really be good for security.

Happy to be here Rob

It's getting a bit late here, I'll think about it over night I'll do some calculations tomorrow evening, however I do think that having %2 would change it from 0.1% hash power needed to 25% power needed.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 30, 2018, 04:28:21 pm
Happy to be here Rob

It's getting a bit late here, I'll think about it over night I'll do some calculations tomorrow evening, however I do think that having %2 would change it from 0.1% hash power needed to 25% power needed.

Thanks Swongel, yeah I was thinking about the attack -  This Kilroy character is basically holding back his 1% coin-age, creating a raw transaction to Alice, then trying to pound the network with blocks 1-10 in quick succession so as to convince the network to go on his chain, so he can transmit the "old" transaction and have it double spent.

So, now lets say its block 1,POW,2,POW,3 - I think that Kilroys % chance is possibly lower than 25% because of : the window for confirmations is 6 in biblepay, so this character would need to pull off 6 consecutive fraudulent blocks, correct? Since he controls 1% of the money supply, wouldnt having the POW in between the 6 drop him much lower than 25, since on the 6th confirm his transaction could not be broadcast (because 3 of those blocks were mined by POW miners who know his block 1 stake is spent)?   But please do let me know if Im in error here, as I would then want to lower parameters if need be. 

I was thinking of potential mitigations.    If we limit max coin age to 30 days, that would help a lot.  I dont want someone coming in 60 days later with a closed off (off network wallet) and massively staking 10 in a row.  Let them be a blessing and stay online most of the time servicing the network :).  So thats one biggie we can change - limit max coin age to 1 month.  Stake more as a user.

Then of course adding the modulus %2 to the mix.  Then limiting coin-age weight to 1% of the money supply max.

Now depending on what you come back with tomorrow... I was thinking of a way to "bust" this problem.  The biggest weakness in this POL, imo, is allowing the network to consume a massive amount of POLs per hour (we have 7 blocks per hour or so).  Another words, with our modulo, we kind of hurt the small miners who just wanted to stake consecutive blocks with low POL weights.  Maybe what we could do is limit POL per pindexHeight-pindexHeight-4 to be no more than 50% of the global network weight - or something, have a limit, so that small miners can still stake all they want, but when a big dog stakes, there are no more stakes allowed of that size until 4 blocks passes. 

I want to keep it simple, so something like :
Weight + (pindexLast(Weight)+pindexN-2(Weight) + pindexN-3(weight)+pindexN-4(weight) must be < MoneySupply * .005, otherwise reject that new block etc...  That would allow lots of small miners to potentially continue to stake without an issue.

Its kind of counterintuitive that I am trying to limit the whales from staking, but its true we are trying to prevent any form of 51% attack, so we should limit the whales from consecutive staking by placing a governor on the pindexLast set to be no more than half of the network weight.




Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Swongel on January 31, 2018, 01:54:47 pm
Thanks Swongel, yeah I was thinking about the attack -  This Kilroy character is basically holding back his 1% coin-age, creating a raw transaction to Alice, then trying to pound the network with blocks 1-10 in quick succession so as to convince the network to go on his chain, so he can transmit the "old" transaction and have it double spent.

So, now lets say its block 1,POW,2,POW,3 - I think that Kilroys % chance is possibly lower than 25% because of : the window for confirmations is 6 in biblepay, so this character would need to pull off 6 consecutive fraudulent blocks, correct? Since he controls 1% of the money supply, wouldnt having the POW in between the 6 drop him much lower than 25, since on the 6th confirm his transaction could not be broadcast (because 3 of those blocks were mined by POW miners who know his block 1 stake is spent)?   But please do let me know if Im in error here, as I would then want to lower parameters if need be. 

I was thinking of potential mitigations.    If we limit max coin age to 30 days, that would help a lot.  I dont want someone coming in 60 days later with a closed off (off network wallet) and massively staking 10 in a row.  Let them be a blessing and stay online most of the time servicing the network :).  So thats one biggie we can change - limit max coin age to 1 month.  Stake more as a user.

Then of course adding the modulus %2 to the mix.  Then limiting coin-age weight to 1% of the money supply max.

Now depending on what you come back with tomorrow... I was thinking of a way to "bust" this problem.  The biggest weakness in this POL, imo, is allowing the network to consume a massive amount of POLs per hour (we have 7 blocks per hour or so).  Another words, with our modulo, we kind of hurt the small miners who just wanted to stake consecutive blocks with low POL weights.  Maybe what we could do is limit POL per pindexHeight-pindexHeight-4 to be no more than 50% of the global network weight - or something, have a limit, so that small miners can still stake all they want, but when a big dog stakes, there are no more stakes allowed of that size until 4 blocks passes. 

I want to keep it simple, so something like :
Weight + (pindexLast(Weight)+pindexN-2(Weight) + pindexN-3(weight)+pindexN-4(weight) must be < MoneySupply * .005, otherwise reject that new block etc...  That would allow lots of small miners to potentially continue to stake without an issue.

Its kind of counterintuitive that I am trying to limit the whales from staking, but its true we are trying to prevent any form of 51% attack, so we should limit the whales from consecutive staking by placing a governor on the pindexLast set to be no more than half of the network weight.

Hi Rob,

Unfortunatly I don't have as much time as I hoped to have this evening nevertheless I've thought some about your ideas;

Regarding limiting coin age to allow smaller investors to keep using PoL: this would be a good idea but unfortunatly is vulnarable to an attack by Malroy (Malroy is Malicious);

Malroy could split his fortune into many small funds (the smallest stakable amount) then split his mining capacity over all these funds, now when Malroy finds a block only that small portion of his funds will be spent allowing for the rest of the funds to still be used; making the amount needed to launch an attack even smaller than assumed earlier.

It would be impossible to limit the amount staked due to the fact that an attacker could simply split his funds into an arbitrary amount keeping the same benefit all the while losing less coin age.


Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on January 31, 2018, 11:43:06 pm
Hi Swongel,

I have to head to bed, but I just checked in.  I think I need to understand the exact nature of Malroys attack .  Lets go back to the example where we enforce modulo % 2.  Could you walk me through exactly how Malroy pulls off a double spend in that scenario?  Im under the impression the attack always fails at block #2 during the POW block.  (IE how could Malroy transmit the stale transaction with the spent vout in it at block N+3) without being ddossed for a double spend?

EDIT:
And I assert that the nature of the 51% attack comes from the ability to stake more than 51% of the network weight during a given confirmation period.  If a governor were indeed in place to limit network weight staked to no more than 40% of the network weight per 6 block confirm period, I believe that rule indeed would prevent a 51% attack.  (Implying the governor idea above is also useful).  Specifically, the block that is rejected in the miner due to large weight would *require* proof-of-work mining for that block (at a higher diff even).  That process appears to kill the chances of a single entity controlling the future of the chain. 

Regarding the greedy staking - remember, even if they split stakes, we dont honor more than 30 day coin age, so if they split it they reliniquish it, and if they hold it its capped at 30 day weight, and if more than 40% net weight attacks during a concsecutive attack of 6 blocks, the code would switch to POW for the remaining blocks.  I believe the governor idea works.



Thanks,
Rob
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: jaapgvk on February 03, 2018, 11:57:05 am
Since the development focus is on the cancer research right now, do you still need people on testnet for the time being Rob?
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Alex on February 04, 2018, 02:50:03 am
Hey Rob,

I have noticed that there was a lot of instances with the same txid included in multiple blocks in testnet. I didn't know it was possible until I saw this. It is apparently possible in the earliest version of bitcoin (only one instance of it recorded for bitcoin), not anymore:
https://bitcointalk.org/index.php?topic=216938.0

It was modified here https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki

Now, I have been wondering why it has been happening (a lot) in testnet (hasn't happened in mainnet since I launched the new BX but haven't checked for earlier blocks) and was wondering if I could get your input on that. I'm guessing it could be related to the implementation of PoL?

For example, e00dda7694df2f71beb9e5fd25d0f7fd281ac4f58cf804153e1c346f9cfff24d is included in both 15718 and 15725.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on February 04, 2018, 08:00:28 am
Since the development focus is on the cancer research right now, do you still need people on testnet for the time being Rob?

Thanks!  I don't need immediate testing for this version, but it should not be much longer before I have something ready to test.
From what I can see I will need help within 3 days.  There are a lot of features to test and things to do for cancer research, so please check back in a couple days and I have should have something to test.  Thanks for the help.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on February 04, 2018, 08:05:39 am
Hey Rob,

I have noticed that there was a lot of instances with the same txid included in multiple blocks in testnet. I didn't know it was possible until I saw this. It is apparently possible in the earliest version of bitcoin (only one instance of it recorded for bitcoin), not anymore:
https://bitcointalk.org/index.php?topic=216938.0

It was modified here https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki

Now, I have been wondering why it has been happening (a lot) in testnet (hasn't happened in mainnet since I launched the new BX but haven't checked for earlier blocks) and was wondering if I could get your input on that. I'm guessing it could be related to the implementation of PoL?

For example, e00dda7694df2f71beb9e5fd25d0f7fd281ac4f58cf804153e1c346f9cfff24d is included in both 15718 and 15725.

Hi Alex,  interesting topic, good investigations.

I dont see e00 in 15718 though .  Are you sure your client was not on a fork at that time?
See the BX: https://testnet.biblepay-explorer.org/block/15718

And showblock 15718 does not pull up e00dda either.  I do see it in 15725.

So looking at that blog, nice info.  We do have that code in place to prevent the multiple tx (from being in two places at a time).  We have the chainheight in the coinbase implementing that protocol.

Could you see if you have another example in testnet or on main where one txid is in two blocks and both blocks are part of the main chain?


Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Alex on February 04, 2018, 08:32:34 am
Hi Alex,  interesting topic, good investigations.

I dont see e00 in 15718 though .  Are you sure your client was not on a fork at that time?
See the BX: https://testnet.biblepay-explorer.org/block/15718

And showblock 15718 does not pull up e00dda either.  I do see it in 15725.

So looking at that blog, nice info.  We do have that code in place to prevent the multiple tx (from being in two places at a time).  We have the chainheight in the coinbase implementing that protocol.

Could you see if you have another example in testnet or on main where one txid is in two blocks and both blocks are part of the main chain?

Hey Rob,

I designed the BX with unique txids in mind (which causes some issues) so it won't show if you directly go to the tx details, however you can see it the txs included in blocks here (disregards the second link where it says the tx is in 15718, it is because only the first tx has been saved in the tx db by the block explorer.):

https://testnet.biblepay-explorer.org/txs/block/15718
https://testnet.biblepay-explorer.org/txs/block/15725

This is what I get for example:

biblepay-cli getblock 4cef7e3327237142b064995a28c0039826e8d0a969a10838c4682e40eda028ed
biblepay-cli getblock 345335a74a39345efbbfc602f4c29f6a7be7ea8851e64694f340375550a74636

"tx": [
    "9da7482b4c9b1ac74b149a009bde8a545aac14b26750a85bb25dde71811c4409",
    "e00dda7694df2f71beb9e5fd25d0f7fd281ac4f58cf804153e1c346f9cfff24d"
  ],

 "tx": [
    "0d189a1d7048227e8552a999e7128bf61a139903265f12419f728e70e63d3e1a",
    "157bb08b58af9f62f55bedd2ec1f4c633fb5d7f53e981ae86498b64cabcc1194",
    "a1ccc4a840a1c33c1710d938648115f177a902cb8e585bdcef9c68c7c4c05a33",
    "e00dda7694df2f71beb9e5fd25d0f7fd281ac4f58cf804153e1c346f9cfff24d"
  ],

You can see "e00dda7694df2f71beb9e5fd25d0f7fd281ac4f58cf804153e1c346f9cfff24d" in both.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Alex on February 04, 2018, 08:42:02 am
Other examples:

86715440507d550c0307f38bee6456664e4d904de8180e2b0fe39fb4cea64de6 in both 15796 and 15798

and

b046a65421acca1d491270b0903c87be5ad88539a9b4b6a06636942fb1f30cc4 in both 15798 and 15803

Checked on 1 linux wallet and 1 win wallet and they both have the same duplicate txids.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on February 04, 2018, 08:53:22 am
Hey Rob,

I designed the BX with unique txids in mind (which causes some issues) so it won't show if you directly go to the tx details, however you can see it the txs included in blocks here (disregards the second link where it says the tx is in 15718, it is because only the first tx has been saved in the tx db by the block explorer.):

https://testnet.biblepay-explorer.org/txs/block/15718
https://testnet.biblepay-explorer.org/txs/block/15725

This is what I get for example:

biblepay-cli getblock 4cef7e3327237142b064995a28c0039826e8d0a969a10838c4682e40eda028ed
biblepay-cli getblock 345335a74a39345efbbfc602f4c29f6a7be7ea8851e64694f340375550a74636

"tx": [
    "9da7482b4c9b1ac74b149a009bde8a545aac14b26750a85bb25dde71811c4409",
    "e00dda7694df2f71beb9e5fd25d0f7fd281ac4f58cf804153e1c346f9cfff24d"
  ],

 "tx": [
    "0d189a1d7048227e8552a999e7128bf61a139903265f12419f728e70e63d3e1a",
    "157bb08b58af9f62f55bedd2ec1f4c633fb5d7f53e981ae86498b64cabcc1194",
    "a1ccc4a840a1c33c1710d938648115f177a902cb8e585bdcef9c68c7c4c05a33",
    "e00dda7694df2f71beb9e5fd25d0f7fd281ac4f58cf804153e1c346f9cfff24d"
  ],

You can see "e00dda7694df2f71beb9e5fd25d0f7fd281ac4f58cf804153e1c346f9cfff24d" in both.

4cef is not the blockhash for block 15718 on the mainchain:
biblepay-cli getblock 4cef7e3327237142b064995a28c0039826e8d0a969a10838c4682e40eda028ed
^ That block is on a sidechain.  When you pull it up it has "confirms=-1" meaning its not on the main chain its on a fork.

I believe that is the case for every example, as the tx-index in the coin is very similar (enforces unique hashes by merkle root).

The mainchain block : showblock 15718  - contains different blockhash.

And the reason this is happening more in test:  With POL it appears we have a massive amount of forks.
getchaintips shows 100 forks.
So it appears I need to either Fix POL to be fork-proof, or let us go back to POW-Biblehashes only and remove POL, and migrate to Proof-of-distributed-computing.

Ive been thinking about it a lot, and I believe with Rosettas cancer research, giving them the ability to research on a Jamaican cell phone is equivalent to our final goal anyway (moving heat miners over to proof-of-dc).  If POL is going to cause us problems, I want to remove it from the equation.

EDIT:
This brings up the issue that you might have to add a process to prune or invalidate blocks that go on a fork (IE that tx does not belong to 15718 anymore - if a block is not on the mainchain it should be removed from the BX so they dont rely on it as "official" data)

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Alex on February 04, 2018, 09:02:28 am
When you say main chain, you mean the main chain for testnet right?

I see it in all my testnet nodes. I will resync one now to see if it's still there. Have you checked the other txs?

Edit:

Also, even if that block was not on the main chain, it would mean that the BX is on the fork and so that this fork has still duplicate txids.
The issue wouldn't be to remove orphan blocks from the BX as that block is not considered orphan by the wallet itself but instead, it is seen as a valid block by the wallet.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on February 04, 2018, 09:11:00 am
When you say main chain, you mean the main chain for testnet right?

I see it in all my testnet nodes. I will resync one now to see if it's still there. Have you checked the other txs?

Edit:

Also, even if that block was not on the main chain, it would mean that the BX is on the fork and so that this fork has still duplicate txids.

Yeah, Im referring to testnet only for all these.  I mean, the main chain in testnet - the official chain with the most work.
For example, if I type showblock 15990 in testnet I get this hash: 6cb5f0c9b09c91f282ea29e39e375bd798683c2e39228c019e6290a03b9ffe0f
If your BX is on that chain, then its block 15718 must only have transactions in it that belong to that merkle root (yours differ).  You can type showblock 15718 if your 15990 hash matches mine to see the official txes contained in 15718.

No it does not mean your bx was on a fork actually, your bx should be able to access all forks as each best block is processed.  Another words the BX should be able to invalidate blocks by height - reloading the official block by merkle root if those older blocks reorganize to another chain.

As far as checking more, if you have more examples I would need the getblockhash command for those, as I dont have a way to search for them.  But I think you will find they are on a fork also.  As the core only allows one unique Txid on the main chain per merkle root.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Alex on February 04, 2018, 09:13:52 am
Okay I found the issue, My confusion stemmed from my windows wallet being on the fork. The block showed as valid (instead of confirm -1)
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on February 04, 2018, 09:15:25 am
I forgot to say one more important thing:
It is going to be very common to find duplicate txids across forked chains in different blocks, as the core copies those txids to every chain (another words miners actually try to mine those duplicates into different heights as its their job), that is why if you want to send Alice 50,000 bbp right before we fork, that same TXID could go out on all chains.

When we reorganize lets say due to power failure, we go off on fork A, B, then C then back to A, you will find that 50,000 txid in every chain.  This is so Alice will persistenly recieve her BBP no matter how bad a fork is.  Its pretty rare for the TXID to become orphaned.  That usually only happens when a double spend occurs, or a txid is so nonstandard that it becomes an orphan.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Alex on February 04, 2018, 09:15:33 am
Yeah, Im referring to testnet only for all these.  I mean, the main chain in testnet - the official chain with the most work.
For example, if I type showblock 15990 in testnet I get this hash: 6cb5f0c9b09c91f282ea29e39e375bd798683c2e39228c019e6290a03b9ffe0f
If your BX is on that chain, then its block 15718 must only have transactions in it that belong to that merkle root (yours differ).  You can type showblock 15718 if your 15990 hash matches mine to see the official txes contained in 15718.

No it does not mean your bx was on a fork actually, your bx should be able to access all forks as each best block is processed.  Another words the BX should be able to invalidate blocks by height - reloading the official block by merkle root if those older blocks reorganize to another chain.

As far as checking more, if you have more examples I would need the getblockhash command for those, as I dont have a way to search for them.  But I think you will find they are on a fork also.  As the core only allows one unique Txid on the main chain per merkle root.

Yes, I had included something in the BX to reconsider blocks but I guess I will look at it again. I got confused with another wallet being on another chain showing that block as valid (instead of orphan).
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Alex on February 04, 2018, 09:21:28 am
Alright, I checked and it seems the mainnet BX didn't encounter that issue yet.

Edit:

BTW My strategy is just to remove orphan blocks and replace them by the actual blocks. Still looking at why/how this happened. I think it might be too tricky and potentially confusing to be able to browse through orphan blocks in the BX.
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Alex on February 04, 2018, 09:46:33 am
Alright, almost done fixing the pruning. I guess testnet is perfect right now to test that. Something positive in the negative!
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on February 06, 2018, 03:52:23 pm
Alright, almost done fixing the pruning. I guess testnet is perfect right now to test that. Something positive in the negative!

Thats awesome!  Thats great your BX cant handle forks now.

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on February 06, 2018, 03:54:47 pm
All,

Lets all stop testing Proof-of-loyalty for now, as Proof-of-distributed-computing is ready for testing.

Let's focus on testing Proof-of-DC, evaluating if it can handle heat diversion and one-to-many research machines to wallets, and stave off the botnet.  If so we will not need to enable POL. 

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Alex on February 06, 2018, 03:56:27 pm
The new version is working and I'm testing it on my private dev server right now. I will deploy it at the end of the week if I don't find other bugs. It seems to be working pretty great!
Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on February 06, 2018, 04:01:31 pm
The new version is working and I'm testing it on my private dev server right now. I will deploy it at the end of the week if I don't find other bugs. It seems to be working pretty great!

Sweet!

Title: Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
Post by: Rob Andrews on February 06, 2018, 04:01:57 pm
All,

Lets all stop testing Proof-of-loyalty for now, as Proof-of-distributed-computing is ready for testing.

Let's focus on testing Proof-of-DC, evaluating if it can handle heat diversion and one-to-many research machines to wallets, and stave off the botnet.  If so we will not need to enable POL.

All, please go here to start testing Distributed-Computing:

http://forum.biblepay.org/index.php?topic=108.new#new