Bible Pay

Read 3021 times

  • inblue
  • Newbie

    • 26


    • 0
    • December 20, 2017, 03:41:42 pm
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #75 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.


  • Swongel
  • Newbie

    • 14


    • 1
    • January 29, 2018, 02:03:22 pm
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #76 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.


  • Rob A.
  • Administrator

    • 1027


    • 17
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #77 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.




  • Rob A.
  • Administrator

    • 1027


    • 17
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #78 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.




  • inblue
  • Newbie

    • 26


    • 0
    • December 20, 2017, 03:41:42 pm
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #79 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. :)


  • Swongel
  • Newbie

    • 14


    • 1
    • January 29, 2018, 02:03:22 pm
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #80 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.


  • Rob A.
  • Administrator

    • 1027


    • 17
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #81 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.





  • Swongel
  • Newbie

    • 14


    • 1
    • January 29, 2018, 02:03:22 pm
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #82 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.


  • Rob A.
  • Administrator

    • 1027


    • 17
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #83 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.






  • Swongel
  • Newbie

    • 14


    • 1
    • January 29, 2018, 02:03:22 pm
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #84 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.




  • Rob A.
  • Administrator

    • 1027


    • 17
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #85 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
« Last Edit: February 01, 2018, 06:40:14 am by Rob A. »


  • jaapgvk
  • Sr. Member

    • 435


    • 18
    • September 01, 2017, 08:02:57 pm
    • Netherlands
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #86 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?


Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #87 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.
« Last Edit: February 04, 2018, 03:00:16 am by Alex »


  • Rob A.
  • Administrator

    • 1027


    • 17
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #88 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.


  • Rob A.
  • Administrator

    • 1027


    • 17
    • June 05, 2017, 08:09:04 pm
    • Patmos, Island Of
    more
Re: BIBLEPAY - TESTNET TESTING THREAD - TESTING Proof-Of-Loyalty
« Reply #89 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?


« Last Edit: February 04, 2018, 08:12:49 am by Rob A. »