Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rob Andrews

Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 ... 127
91
Upgraded to v1.4.2.2b

=

Yeah on the anonymous talk, I think its important for fungibility to have anonymity,
I also think its important for personal safety,
I think in the much much past you may have been open to disable PrivateSend?,
but it sounds like you may now lean more towards privacy/anonymity?

Also, I noticed in the evo docs theres a section about Tor
https://github.com/biblepay/biblepay-evolution/blob/master/doc/tor.md

Casa Node just added a Tor update
https://www.reddit.com/r/Bitcoin/comments/beu2zm/casa_releases_support_for_tor/

I really dont know much of anything about Tor,
Ive heard rumors/stories that most of the exit nodes have been compromised,
but anyways Id be open to testing it out for BiblePay


Regarding me actually being against PrivateSend, I wouldn't say I am actually against it, I think what happened is 616West raised the concern a couple of times that if we are a Christian Crypto, why should we be touting private send features in a do-good environment (IE he was viewing this as why would a villain want to use biblepay if this is a Christian wallet).  And I know we have a savvy group, but what we have to communicate to people is Personal Safety Risk is real - IE there are cases where a normal Christian family has a few hundred grand in their 401k, and they might be the type of family that would rather move it to crypto (I know this sounds crazy to old timers, but look at the world, we may be in the end-times, etc, do you trust all the governments to do the right thing and print and print), anyway, lets say John Doe does move 300K into crypto, doesnt he have the right to remain anonymous and not get traced back to his IP and then have his crypto be taken at gunpoint?  So this issue really had more than one response, when I responded the one time that we should "hide" private send from the overview page, I was talking from a BBP UI perspective to make it easy to use - but I have never been against anonymity.  I think we need to educate the average user into knowing that anonymous features are not here to promote shady behavior from the ones trying to buy shady transactions, these features are here to protect the identity of people who want anonymous balances.

So to reiterate, I think BiblePay should provide two clear facilities, we should embrace Dash's features (untraceable balances) for investors, but we should also provide the public gospel side, and make it very clear in the training manual what could allow those two systems to intermingle.  (System A keeps balances in system A untraceable, while funds sent in System B are associated with a CPK and are public funds).  What this boils down to is if an anon investor intermingles their CPK with their cold storage sanc rewards (or cold locked Sanc collateral), they will expose their identity on the BX for everyone to see. 

So this is not about private send itself; its about starting to demarcate (all the components of every subsystem) in these two systems and make it easy to keep them separate, make sure our business logic doesnt allow breaking the rules and letting the anon user down, and we should also make a training manual for anon education.  We can be clear in our manual we are doing this to maintain the safety of the end user (not to promote shady behavior) inside BBP.

Actually Togo since you are excited about anon features if you want to take on the training manual, I will work with you to split the use cases and you can document them?

As far as Tor, I have never used it.  I sort of know how it works since I have a network engineering background.  Tor is basically going to be for people who are afraid another BBP endpoint would log their nodes IP (IP can be geo-located to your general block, now with Google streets sometimes down to the house number).  BBP does not store the IP (pools might), but all of this can be documented for anon users.  Tor is going to try to prevent the IP from being leaked (as you are coming in from the Tor point IP).  But as you said Tor might even be compromised - but there are other VPNs available for security concious individuals.

However, the IP is not as big of a problem as the actual anon balance.  The idea is if you can create an anonymous investor sanc balance, and never comingle your cold wallet rewards back to your CPK, then you are never going to be a public figure in the BX or a target for a villain (if they just see a key and a balance, they do not know your nickname and cant tie you to any other systems).  So I think this distinct goal is a worthy one for a page in the training manual alone.  You could make a separate endeavor to protect IPs.





92
Thanks (and also thank you Togo)!

I already tried deleting everything (including the 'SAN' folder) except my wallet.dat a couple of times, but that didn't help. I now upgraded to the latest version and put the gen=0 in my biblepay.conf. Let's see how that goes :)

I don't have a lot of spare time at the moment, but I'm going to try and keep up with you guys!

We will probably have an update either in 6 hours or tomorrow morning, and I believe it will be a leisure.
Right now its slow to mine.


93
Reporting back, I was able to run "exec sendgscc" with encrypted/locked GUI wallet,
Output:
{
 "Command": "sendgscc",
 "results": 1
}

Ok great!  (Ill be back on asap to answer those other security questions etc).

I discovered a bug today with ABN - this is a good one, now I can see why the network has been crawling soooo slow for the miners.

The ABN mining transaction needs a small adjustment.
For now the block solving speed is extremely slow.

I'm working on the patch.

We are close to moving on, I think these two issues are nearing completion.



94
I clicked Settings >> Encrypt Wallet

"getmininginfo" shows hashps

I tried to do "exec sendgscc true"
but I got message "Diary entry incomplete. (code -1)"

Ok, we need to straighten out the docs, but let me re-clarify :

We used to need "true" in there in the first few versions to force the gscc so it would override the mining timer and send it.  Then later, I made this particular command always force it (as obviously they want to do it).  So you no longer need force=true.

So now its just two situations:  If you are a member of HEALING (exec join healing), you can do this:
exec sendgscc "healed a leper on the street"  ... (or prayed for someone, etc).

OR

exec sendgscc


In Case A, it will send the gscc to every applicable project PLUS ones that take diary entries.

In Case B, it will send it to all non-diary projects.


Good on the mining with a locked wallet, we are halfway there.



95
Alright! Turning off mining seems to have helped :)

Does someone have tBBP for me so I can start a Sanctuary? I only got 400k left when I finally synced to the top.

yc4G3KS6ZSmGRb89LrLSECpRy6AHfEfy59

I took a look at the problem we had and I think it was more related to the abn fork rules- I believe the gen=0 probably didnt help, anyway I also sent you some tBBP.

Good news, we are at over 5+ diff with ABN on, great.



96
Are we all in agreement:


08:15:36

getblockhash 53668


08:15:36

c9fbda30f682499ddbfe4516dca28d3bf5ded73caf36f8c65edd60a8394423bf


I only see a few pog participants in the leaderboard.

I do see 2 new sancs in New Start Required state though.


As a side note, ABN and AntiGPU are disabled til block 54000 hits then we can test those two again both from mining perspective and from syncing from 0.

Now we also should be testing the auto unlock password; ensure you can mine with a locked encrypted wallet, and ensure you can send a gscc also.


97
1.4.2.2b-Mandatory upgrade for TestNet

- In sendcoinentry, only add tithe validation if its a tithe
- Raise ABN starting height to 54000, and prevent chain from stalling
around 50000 due to a low abn height
- Add 2 params to getchaintips (minimum diff and minimum branch length)
- Add RPC command:  setautounlockpassword password (This allows the
gsc-transmissions or the abn transactions to automatically be created)
- Make ABN check more graceful to allow people syncing from 0 to sync to
the top
- Add Leaderboard to Left Menu
- Make leaderboard numeric columns sortable
- Decrease default bezaleel frame size to accomodate the sync modal page
- Decrease Leaderboard default grid size
- Correct PODC verbiage in autounlock


98
I can confirm that it's impossible to get over it (I've tried it so many times, but still nothing) :)
In the meantime, while I'll be waiting for mandatory I have few cosmetic update tips :)
1. I've looked so many times on "synchronization screen" that I realized it is based on biblepay-light theme and it would be better to have it based on biblepay-traditional theme, because it's more bezaleel friendly visual.
You can see it side by side here: https://prnt.sc/ni1npi
2. Other thing which disturbs me is min window height in bezaleel theme. It's 855px and it's impossible to make it smaller. When you change it to traditional theme it's only 740px which is better to me, but I think it can be even lower :)
Side by side here: https://prnt.sc/ni1p7r
3. Leaderboard button should be on left menu (like with POG).
4. Leaderboard sorting is not going well. It sorts badly. Try to sort it and it sorts based on first digit not by whole number. I haven't screenshot, because I'm not able to sync, byt you can try it :) This problem was in POG leaderboard too, but if I remember correctly MIP repaired it.
5. Leaderboard doesn't respect window width and when the window is smaller it just put there horizontal scrollbar. E.g. columns in tx view adjust their width based on window width and there is only vertical scrollbar. Maybe this problem is in other views (maybe proposals) but I'm not synced to confim that.

Maybe more tips will be after I'll be synced after new mandatory release :)

I have #3 already, and I think Marcus can probably do #1 if  hes working on the new Bezaleel now, but Ill take care of all the rest for the next release.


99
Thank you for answering all my questions Rob!

No problem, so while we are discussing splitting, MIP had also asked about this, can we potentially not send the stake back to the CPK, but instead to an anonymous change address.  I investigated that today, and there are many issues here that surface - for one in order to prove that the CPK (who is registered) actually staked the amount, we currently send the coins to our own CPK and when we check the sig, we verify the recipient sig is the one who signed the coins.

So, although we could make a whole new scheme, I want to explain, my idea in the future is to take the average amount staked to each CPK per day, and use that for the CPKs voting weight (for those Christian object votable lists).  And for non-sanc polls (such as multi-choice community steering polls).  Another words, in this system we expose the users average free balance for voting weight.

So Im thinking what we do is when we create our training manual - for security concious individuals concerned with anonymity, we create a use case where users will generally create sancs with their anonymizable balances and lock those.
Then the non-anon part of Biblepay is your free balance.  This is used for GSC campaigns, mining, ABN staking, and voting. 

So I think this idea works relatively well to appease concerns from both camps.  We need to be anon-concious for investors, but we also need to be spreading the gospel and doing the cool things necessary on the public side with the CPKs.

The primary change in the future to make this a reality is to explain to the anon camp they will need to create cold storage addresses for their sanc outputs (not send them back to the hot wallet where our GSC will pick them up and convert them to CPK funds).



100
Stucked again.
Block 50564.
log:
Code: [Select]
2019-04-28 20:52:36 {PNB}: ACC 
ContextualCheckBlock::ABN ERROR!  Block 50564.000000 does not meet anti-bot-net-minimum required guidelines: BlockWeight 0.000000, RequiredWeight 1000.000000ERROR: AcceptBlock: low-abn-weight, Insufficient ABN weight (code 16)
2019-04-28 20:52:36 Misbehaving: 193.187.180.41:40001 peer=1 (0 -> 1)
2019-04-28 20:52:36 ERROR: ProcessNewBlock: AcceptBlock FAILED: low-abn-weight, Insufficient ABN weight (code 16)
But good news is that my backup works :D
But....
next stuck block 50589:
Code: [Select]
2019-04-28 21:05:47 {PNB}: ACC 
ContextualCheckBlock::ABN ERROR!  Block 50589.000000 does not meet anti-bot-net-minimum required guidelines: BlockWeight 0.000000, RequiredWeight 1000.000000ERROR: AcceptBlock: low-abn-weight, Insufficient ABN weight (code 16)
2019-04-28 21:05:47 Misbehaving: 108.61.194.83:40001 peer=5 (0 -> 1)
2019-04-28 21:05:47 ERROR: ProcessNewBlock: AcceptBlock FAILED: low-abn-weight, Insufficient ABN weight (code 16)
2019-04-28 21:05:47  AntiGPU i 0.000000, CPK yUNSEjjtC9pdeHp4spswdFWh1npfV5Jvqe      UpdateTip: new best=ffd3388b019833152c97333ad0b92c682decb88d52a0c2915d0c28197d078766 height=50543 version=0x20000001 log2_work=45.94637348 tx=143538 date='2019-04-27 21:55:43' progress=0.994223 cache=0.0MiB(0txo)
2019-04-28 21:05:48 {PNB}: ACC   AntiGPU i 0.000000, CPK ygavD5YuAJXpHDMLRyiiJ199YM5y9fTWfB      UpdateTip: new best=639d36532617d90194c7cb36e05e4c6b6130671377871fc2c054543eecd8a6bd height=50544 version=0x20000001 log2_work=45.94637566 tx=143540 date='2019-04-27 21:56:10' progress=0.994225 cache=0.0MiB(0txo)
2019-04-28 21:05:48 {PNB}: ACC  ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)
BTW: now i have gen=0 and unlocked wallet

Yes, sorry, I was not clear  - actually I never got back to you yet :),  lol, we do need an upgrade here because I confirm that the height issue introduced about 48 hours ago causes all people who have to sync from below 50K to get stuck at your height, but the people already running are still running, thats why you are pulling your hair out.

Im working on trying to get the other suggestions in at the same time (like the autounlock feature).


So, Im glad you have your backup though to fall back to.  Ill notify asap as soon as its ready.






101
Thanks for looking into things Rob!


3. Is the ABN Stake transaction just coins going to the CPK address?
3.a. I havent noticed any of the CPK address transactions in my Transactions list, filter set to All, but I do notice coins moving around in Send >> Inputs (Settings >> Options >> Wallet >> Enable coin control features)

On #3,  Yes, its as if your wallet is finding enough coin*age, taking those coins, making a transaction to yourself, and sending those to your CPK address (which proves you owned that much coin*age).  It only does this however if you solved that POBH block.

On #3a, We do not show the ABN tx as a separate row on the txlist (because then you would see two entries for every block mined).  (This is the same behavior as we see in blackcoin and other staking systems) - it looks really cluttered if we do that.  You can see the tx though if you double click your mining reward, we show the debug info.  You can also get the txid and type : getrawtransaction txid 1, and see all the coins it used for the stake.



102
Thanks for looking into things Rob!

=

1. So this coin splitting behavior is intended and happens automatically every so often? when mining? (and every wallet is now set to mine by default?)
1.a. Is an amount of 4500001 ignored for coin splitting? when user is setting up a masternode?
1.b. Does this mean new miners have to own some amount of BBP coins in their wallet to participate in mining? (but they can jump in to mine when block hasnt been solved for 60 minutes if they dont have coins?)

2. Also for the CPK, I noticed that I never ran a command (exec cpk my_nickname) to create one, is default behavior that one is created automatically? And the command is to just add a nickname to it?

=

Just poking around the documentation:

https://wiki.biblepay.org/Getting_Started_with_Evolution
https://wiki.biblepay.org/Generic_Smart_Contracts

GSC (Generic Smart Contract)
"The GSC is split into a client server architecture. The client side user joins campaigns with a CPK (Christian Public Keypair) and competes in these campaigns for points. The server side (our Sanctuaries) assess user points and tracks user progress. Once per day, the points are converted and paid in a Generic Smart Contract. The GSC is voted on by the Sanctuaries automatically at a certain chain height. The GSC is paid once per day as a superblock from BiblePay core, and is split among campaigns by points rewarded per campaign per user. "

ABN (Anti-BotNet)
"which requires a certain amount of coin*age to be present in each mined block in order to mine BiblePay"
"Our network requires an average calculated and pre-assessed static amount (posted in getmininginfo) of required coin*age and stores this in the chain. Each miner checks this number, and will search the wallet (this is all automatic) for coins totaling the requirement and place these coins in an ABN Stake transaction - and then begin mining"

=

3. Is the ABN Stake transaction just coins going to the CPK address?
3.a. I havent noticed any of the CPK address transactions in my Transactions list, filter set to All, but I do notice coins moving around in Send >> Inputs (Settings >> Options >> Wallet >> Enable coin control features)
On coin splitting -  There is no actual splitting.  We are just sending the transactions change back to you when you break a bill (the same as classic does).  The only new thing to know is if your wallet is about to create a GSCC transmission for the POG (or other) campaign(s), if it assembles a 1 million coin*age stake by using 1.1 million in coins, the 100,000 of change is sent back to your CPK (Christian-Public-Key) address.  This also happens if you make a 1.1 million ABN stake - the leftover change is sent back to your CPK.



"1. So this coin splitting behavior is intended and happens automatically every so often? when mining? (and every wallet is now set to mine by default?)"
->  This ABN transaction only occurs if you solve a POBH block, or create a new GSCC transmission.  These GSCCs are sent once an hour in testnet, and once every 24 hours in prod.

1.a. Is an amount of 4500001 ignored for coin splitting? when user is setting up a masternode?
->  Yes, any normal send from the Send UI works as classic does (no splitting, no difference in change, etc).


1.b. Does this mean new miners have to own some amount of BBP coins in their wallet to participate in mining? (but they can jump in to mine when block hasnt been solved for 60 minutes if they dont have coins?)
->  Yes, if the block is > 60 minutes (late block threshhold = true), anyone can mine it.  But yes, with ABN enabled on the network, with a 1000 minimum ABN weight, every mining use must have coin*age to mine.  So yes they would actually need biblepay to mine a POBH block.

2. Also for the CPK, I noticed that I never ran a command (exec cpk my_nickname) to create one, is default behavior that one is created automatically? And the command is to just add a nickname to it?
->  So on the CPK auto creation, when the wallet tries to mine, it realizes you had some coin*age for the ABN but you didn't have a CPK yet.  So it pre-created the wallet receive address for the CPK (and it is smart enough to re-use it when you register your cpk), so this is OK and normal.  This way it can re-access it for every ABN it tries to make.  (This also because you can mine BBP with just a plain old wallet with 5K in it for example and dont have to register your CPK or join any projects if you want to be simple).  I know we added a step to require BBP to mine BBP, but this is a tradeoff to enable the anti-bot-net weight rules.

Basically, we can make it harder for rich miners with hundreds of servers to keep pinching out the newbies if we ratchet up the minimum ABN weight requirement.



103
Im in agreement on blockhash for 52240
My masternode IP is:  108.61.194.83
I see 4 ENABLED masternodes

I never registered my cpk, so I just ran "exec cpk togo"

How do you view the leaderboard?
"exec prominence" is not working for me "Command not found"

Also do I need to run "exec join pog"?
Are POG and ABN different things?

Ok great, just checking for my own sanity cause 5 participants seemed rather lonely.
Yes, I see your 108.61 as enabled, good deal.

So, when you ran the 'exec cpk togo' that did register your CPK.  (The Christian-Public-Keypair Address book entry can actually get created by another process, Ill explain that in the post when I reply to your other post).

So the exec prominence was changed to rpc command: leaderboard  (for ease of use).  Now you should see about 5 in there, but you will have to do a:
exec join pog
First, and then force out a GSC to get in the next superblock (exec sendgscc true). 

You can also view the leaderboard in QT by clicking "Leaderboard" (its like our old pog view).


So once you have a CPK, you are basically just in our list of CPKs (that lets you vote on future things and gives you voting weight depending on how much your average stake is).  You have to join pog in order to actually send GSC transmissions.

POG & abn are different:  POG is BiblePay campaign #1, proof-of-giving, its a hybrid stake/giving campaign requiring coin*age to get rewards, and a small component of it is POG (donations to the foundation).  These transmissions are one type.  ABN is another.

ABN is strictly for POW miners.  It adds the requirement to POBH mining to have coin age in each solved block.  So when your wallet is about to solve a POBH, it adds on the ABN with coin*age in it.  So each of these require distinct unlocks of the wallet for them to be successful.

Im adding the code now to support the autounlock command so people can type that in every time they boot.


104
Thats because the wallet pulls more blocks after the problem until it cant (you can check the log for ERROR to see the real root problem really occurs "ABN ERROR!  Block 50558.000000 does not meet anti-bot-net-minimum required guidelines: BlockWeight 0.000000" at 50558. 
^ Thats got to be the real root problem in every log right now.

If you want you can exit even earlier at 49000 to give you more time - I would recommend that.

Also, I have successfully recovered a node with getchaintips just now, but lets go through that later, since we know we need another mandatory I dont want to confuse everyone right now.


105
Ok. So, now I'm stucked on 50655 :D
I was away of my PC, so I'll try to sync it again to 50k and make a backup :)
I hope, I'll stop it in right time :D

Thats because the wallet pulls more blocks after the problem until it cant (you can check the log for ERROR to see the real root problem really occurs "ABN ERROR!  Block 50558.000000 does not meet anti-bot-net-minimum required guidelines: BlockWeight 0.000000" at 50558. 
^ Thats got to be the real root problem in every log right now.

If you want you can exit even earlier at 49000 to give you more time - I would recommend that.


Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 ... 127