Pages:
Author

Topic: BiblePay - New Coin Launch - Official Thread - page 39. (Read 119845 times)

full member
Activity: 462
Merit: 103
Also, since the pool is open source, someone could remove this fee? BTW, the fee is paid to the pool or orphan foundation?

Good questions, I have also wondered the same things.



West, thanks, I think the dev should use your explanation to fill the "Help guide" section at the pool which is currently empty and that's what seeksilence was asking about, the lack of instructions.

If you think you can write to that one, great, if not, keep looking.

... But what if I can't write to anyone? I would think I am a strange case, but according to the ratio of pool users who didn't write a letter vs. the ones who did, it seems I am in the majority. If you think there are miners who don't care about that and only care about money, actually that is directly related with their profits. So one would think even them would take a minute to do it, at least sloppily.

I like to help children in need and other causes and I like "automatic" helping very much, like BBP already does with tithe blocks. I actually donate to UNICEF automatically every month, and I also donate to some local organization. But I have never written anything to anyone, I just speak with my money. It's arguable what would bring a child more happiness, a lovely letter or new shoes. But I don't see a reason to be forced to do both. I have social anxiety and also a real fear of writing something bad in a letter, because I get nervous if I have to relay my thoughts to an innocent child, because I have personality issues, dark thoughts etc. In real life I am already not good with family, neighbors etc.

So do you (and pool admin) think that it's all right to force pool users into doing something they don't want and have low quality letters, compared to having someone who would be delighted to write a letter (or two) without forcing them? The fee has increased from 2% to 6%, which is starting to get crazy, and I already imagine it being higher in the near future. Also, for me it wouldn't be a problem if the fee went to charity, because I would see that as kind of an increased donation for those who don't want to write letters, but it seems the fee is only going to the pool, since at the orphan foundation address I only see tithe blocks payouts from mining. I see no use in that and I will be switching to solo mining if another pool doesn't emerge soon.

The dev has stated that he is against us being a "mining organization" which is why I understand his actions with the pool website, but I want to remind him that that's a pool website. Yup, it's in the domain name even. While I haven't seen a coin website with such awesome features, they don't belong there. Ideally they should all be in the Qt wallet and I already said that the higher cost/time involved with it is not a real issue when a pro Qt designer could do that when he is hired for the redesign anyway - it would not be hard to make a few more windows with some server communication.

Then, if the dev thinks that writing a letter every 60 days is a real requirement to be able to use (or just to mine) BiblePay, then by all means, make it mandatory. It could be done in the wallet and if the user has written a letter, they could mine, if not, they couldn't mine at all, which can be controlled since the miner is integrated with the wallet. I am not for this (nor against it), but it's important to see a big difference here: in this case, it would be a BiblePay rule for everyone and if somebody doesn't want to do it, they can't mine BiblePay and that's it. But not like it is now - the rule is enforced by one pool, which is not an exclusive way to use or mine BBP, so solo miners have an indisputable advantage of 6% over pool miners, and so will have miners on a new pool. Moreover, I think miners shouldn't be responsible or required to write letters or anything of the sort. They already have a steady role in keeping the BiblePay network secure and they already donate every 10th block to charity, which is not meager. They don't have to take up another role if they don't want to. They can, but they shouldn't need to. I understand that we are in very early stages, nevertheless it's obvious that it's the regular users who should be the ones using those features, so not miners, but Christians, investors, enthusiasts etc. And what is absurd is that there are probably users who are not miners who don't even know about letter writing, but they would be glad to write a letter only if they knew about that feature!

The dev has also recently changed the masternode share of the profit to be heavily against miners, which confirms his view of things, along with the "mining organization" statement and the constantly increasing fee for miners. Although I like the current proposed [miner/masternode/charity/IT] percentage distribution, I realized what is happening here, especially with the recent retirement/colored coins proposal. It seems like the current state of things does not adhere to the developer's vision when he started the coin and I am not saying this in a bad way. I agree with that, since the main focus right now is heavily on mining, as if this is some generic coin. But why would it not be possible to completely change the focus and the rules by a consensus? Of course there are other ways to secure the network except mining, but I'm not suggesting such a drastic change. I will continue after the following quote:

One benefit of having this particular feature is we would attract outside investors that would need to buy BBP in order to have the ability to buy rBBP and they also potentially download the wallet and be users and might have a tendency to be long term holders.

Um, actually... Why wouldn't BBP be rBBP?! Kinda. Obviously it can't be some of the things outlined in the idea, but most of them it can. Isn't it better to attract investors directly with BBP coin, rather than with some invisible internal asset? That way BBP could be seen at CoinMarketCap, exchanges and everywhere else, but rBBP would hardly make an impact. And I think having an asset inside an asset is too convoluted anyway, even for a technical user, not to mention an average user. And if the coin wants to be for the masses, Christians, philanthropists etc, then I think it shouldn't be made too hard to use (which is in line with my argument about charity features in Qt). You have my support if BiblePay itself could be made in any way more in line with your idea of rBBP, or even generally your revised idea of what BiblePay should and should not be. I think we are still a very early and small community and that even bigger changes could still be made without dissent. The past has shown that the majority of users were OK with the changes, even when they caused some issues.

Thank you for reading, I hope I have inspired some discussion.
full member
Activity: 406
Merit: 101
I just saw the letter fee went above 5%. Is there any maximum of the fee and how can I avoid it?


Non-Participating Letter Fees:
6%

My (Personal) Letter Fees:
6%

Go to the Orphan tab, Sponsored Orphans List.  Find an Orphan listed that shows Needs Written True.  Read their bio, by double clicking on that field.  If you think you can write to that one, great, if not, keep looking.  Once you find an Orphan to write to, right click on their name and it will show "Write".  Put together a paragraph or two to them.  Then the letters get up or down voted.  Once it has enough up votes (7) it will be approved.  Once it goes out in the batch send, your fee will drop to 0% for 60 days.  If ALL the Orphans get written to in a 60 day period, then everyone's fee drops to 0%.
full member
Activity: 239
Merit: 250
I just saw the letter fee went above 5%. Is there any maximum of the fee and how can I avoid it? Need an instruction on the pool page.


Non-Participating Letter Fees:
6%

My (Personal) Letter Fees:
6%

Edit: Also, since the pool is open source, someone could remove this fee? BTW, the fee is paid to the pool or orphan foundation?
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
I just wanted to mention that I have been a little busy lately (other than being interrupted to upload the pool, which is a huge necessity), with a brand new cryptocurrency feature for biblepay.  I think it might be "the" feature for us that gives us the edge to the top 50.

I'm thinking about adding colored coins into biblepay with an integrated 401k or retirement account fund inside the wallet.  And in-wallet trading.

One benefit of having this particular feature is we would attract outside investors that would need to buy BBP in order to have the ability to buy rBBP and they also potentially download the wallet and be users and might have a tendency to be long term holders.


So, I understand that this second colored coin could be used as private payment between users, without the fear of a possible dumping in value due to exchange speculation. In other words, it´s a more stable asset for long term savings. To me looks like a very good idea.

Yes you got the general idea, but it would not be entirely without speculation effects in BBP and market price changes.  The financial ecosystem of biblepay changes slightly:
- A block reward of 10,000 biblepay would include something like 2,000 retirement coins (that 2000 rBBP component of the reward would decrease by 1% per day - forever)
- The retirement coins can only be spent by sending a certain colored tx to another user OR by trading them in the BiblePay trading system in the wallet (for BBP! not rBBP)
- The price of BiblePay *would* be affected in as much as : Outside users may buy BBP on an exchange for BTC in order to run the wallet in order to buy rBBP inside the wallet
- If a person nears retirement wants to dump 10 million rBBP, they will crash the in-wallet market, and therefore lower the price of BBP temporarily as the outside market absorbs the shock (normal arbitrage)

Security considerations:
- The colored coins cannot be sent outside the wallet and cashed in on an exchange, even if the keys are compromised - because the coins will be colored, and they have a value of 1/10000 of a BBP and less per satoshi inside the wallet internally
- Rules will be added to only allow colored->colored transactions
- Colored coins are not selected for payment from AvailableCoins or in Coin Control
- Tx with colored coins are only allowed to be 2 vouts (no complex tx allowed) and all outputs must be colored

Market makers will be available to cross a transaction (this would be one chosen sanctuary at the time the trade is placed).  So basically, User A wants to Buy 1000 rBBP for normal BBP, user B wants to SELL 1000 rBBP for BBP, Market Maker C jumps in and receives the escrow from both parties while putting up the equivalent amount of escrow, then crosses the trade and then completes the transaction.  Resulting in one person buying retirement coins for normal BBP and one with less retirement coins and more BBP.

The goal is that some participants view this deflationary retirement asset as something they want to hold for a longer period therefore they tie up BBP in rBBP for a longer period of time.

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
This could be the next PINK coin.

But what an interesting niche idea. (Interesting)
I think I'll add this to equal out all of the EOS in my wallet.
Interesting coin...  Kind of wild...
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords

I am having a problem connecting to the node too. So to connect via one of my peers would I just type:

Code:
addnode "121.99.196.86:xxxxx" "onetry"

where the address is the node id address (or should it be the "via"?)

Thanks
Telnet is connecting successfully right now- we may have overloaded the connection count at that time on the seed nodes.
(Windows can only handle 1024 connections).
You can also try:  Biblepay.inspect.network is another good one to add as a seed node.

From a command line try this
telnet biblepay.inspect.network 40000

If that connects you should be able to add the addnode= to your config file and restart.
Also:
addnode=node.biblepay.org


full member
Activity: 364
Merit: 102


Thanks for posting the code.  I'll play around with it tonight and see if I can get a test pool running.  And no that wasn't me that posted on there Smiley


Just let me know when you get the ASPX compiled and "almost" running (IE pool starts in debug mode and you cannot login).  At that point I will upload the SQL backup file of the empty database into github.  (I will get to it hopefully tomorrow).  So dont waste time recreating the schema as I have all of it.


Ironically what I have wasted hours on so far is getting the daemon to connect!  I thought maybe it was an incompatibility thing with win 2016, tried it on win 2012 with no luck.  Firewall is off both in the OS and through Amazon EC2.  Could it be possible that something is up with those 2 default nodes?  I see someone else posted the same issue earlier.  My QT-Wallet on my local box works fine, and my other linux VM is mining without problems.  Seems like maybe this has to do with initially populating the nodes?



Hi,
First on the daemon inside the AWS cloud (or wherver you want to run biblepayd as the pool hot wallet) ensure this is in biblepay.conf:

rpcuser=myuser
rpcpassword=mypass
rpcallowip=your_public_ip
rpcallowip=your_home_ip
rpcallowip=127.0.0.1
rpcport=30000
server=1
daemon=1


Then go to home computer and ensure you can 'telnet daemon_public_ip 30000' ensure that that answers?

Ok, I will start working on that biblepay.bak file for you to see also.

Thanks.




Yes but I'm not even getting that far.  Like I can't even get the daemon to sync up to the blockchain.  It seems like it momentarily will find a peer, then back to no connection.  I'm going to give this a try in Google Compute, it could be just an amazon thing.



Even though the firewall is open on the windows 2012 server, check AWS master console to see if you are subject to the AWS default firewall policy. I remember at work we had to clone it and modify it.

Then from the server you can install telnet client and try the same test from the command line through the public IP.

Also you can install the block explorer as an add node, but I doubt thats it.


** I uploaded the SQL database creation scripts to github **
Now you can run schema create and then data create.

 

Thanks for the help.  I tested on Google compute and had the same problem.  on Google after submitting the addnode "node.biblepay.org" "onetry" command a bunch of times it finally connected to the node.  I went back to AWS and that command didn't fix it on that side.  I finally just logged into the linux box I have mining and grabbed the address of one of the peers my daemon there was connected to and added it as a node, it instantly connected.  Kind of a weird problem but its working now.  Last night I got up to the point of installing IIS.  I'm at work right now but hopefully I can wrap this up mostly tonight.


I am having a problem connecting to the node too. So to connect via one of my peers would I just type:

Code:
addnode "121.99.196.86:xxxxx" "onetry"

where the address is the node id address (or should it be the "via"?)

Thanks
full member
Activity: 406
Merit: 101
so its there already an amount set to run a masternode in december? I only have 100k but hopefully I can mine some and buy some more.

The Testnet is 500K Test BBP.  The value talked about has been 1,000,000.  While that is a lofty number in some ways, it's very attainable in the marketplace compared to many other MN coins.  At the end of the day, I would say with 95% certainty, the final value will be between 750,000 and 1,500,000 for a masternode.  Part of it will get resolved during the test run, since the coin benefits from having some number of masternodes, but the valuation of the coin is boosted by scarcity, and a high coin masternode should increase scarcity and lead to a more stable valuation than something low.  Just my two cents, and for the record, I hope to be running a MN or two (am doing one in Testnet to help the coin and educate myself).
sr. member
Activity: 868
Merit: 279
so its there already an amount set to run a masternode in december? I only have 100k but hopefully I can mine some and buy some more.
member
Activity: 112
Merit: 10
Professional Knife catcher
This could be the next PINK coin.

But what an interesting niche idea. (Interesting)
I think I'll add this to equal out all of the EOS in my wallet.
newbie
Activity: 42
Merit: 0
Not sure if I am missing the info anywhere but is it possible to mine using software other than the wallet? Cpuminer? sgminer? ccminer? etc?

Currently there are no external miners for the coin because the algorithm is really unique and even takes into account that you are running a node, so for now one has to run a node and mine using the in-built miner.

If you want to setup a node fast and start mining on the pool, I had put up a script for linux to do so.
https://gist.github.com/anonymous/d1c1d35e3c8f67f5fb2e204479fa5c6b

Cheers
newbie
Activity: 10
Merit: 0
I just wanted to mention that I have been a little busy lately (other than being interrupted to upload the pool, which is a huge necessity), with a brand new cryptocurrency feature for biblepay.  I think it might be "the" feature for us that gives us the edge to the top 50.

I'm thinking about adding colored coins into biblepay with an integrated 401k or retirement account fund inside the wallet.  And in-wallet trading.

I'm thinking maybe we can be the first coin with the ability to trade BiblePay for our second asset inside the wallet (other than Ripple, but technically, Ripple is a network of market makers making existing markets).  This is a little different.

I'm thinking we emit a new deflationary colored currency (called either retirement coins or 401k coins) inside the wallet on a schedule decreasing by 1% per day.  Then, the wallet will keep track of both normal balance and "colored coin" balances.  So you would have your BBP balance and your rBBP balance. 

   Starting on the day we have retirement coins, the retirement system would emit 1 million retirement coins per day equally divided over 202 daily blocks to the miners who mine the blocks.  However each day, the emission rate would decrease by 1% .  So on day 2 we would emit 10,000 coins less (or 990,000 retirement coins over 202 blocks).  Each block solver would receive normal BBP, plus a separate share of colored retirement coins.  If you mined 4,000 retirement coins on day #1, your balance would now be:  1,000,000 BBP and 4,000 rBBP (retirement bbp). 

You cannot send colored coins to an exchange to sell them and cannot buy colored coins on an exchange.
All colored coins must be sent in a transaction that includes a reference to the root of the colored coins (another words, the colored indicator on the tx, the previous output is colored, and the new vout for the receiver is colored).

Available coins for spending will never select colored coins for spending (IE They cannot be spent). But they can be Traded for BBP with other holders through Trade transactions.

A new RPC command will allow you to send colored coins back and forth among others, if you want to give them to others.

Now here is where it gets interesting.  If we view the colored coins as a deflationary retirement account (assuming that IF they are becoming scarcer, storing FIAT in rBBP would theoretically result in a gain in value).

We implement in-wallet trading to allow trading from BBP to rBBP.  So we would have RPC commands to "execute order SELL 9000 rBBP for 1100 BBP" for example.  Other in-wallet users would "execute order BUY rBBP 5000 for 700 BBP".  When the matching engine matches an order over the nodes, one masternode  who is the chosen winner of the round (chosen winner meaning which masternode has the closest hash to the center of the blockhash for the current BBP block, can be active market maker for this tx).

At this point, the masternode jumps in, Locks the trade, grabs the collateral from the seller and the buyer, crosses the trade, then unlocks it and it is completed.  We will have a Trading log in biblepay, so you can go into your separate debug file and monitor STEPS that occur during trading.  (In case something goes wrong partially through).

Lastly, partially executed orders would be changed via a MODIFY - so if only 1000 got filled your order would readvertise with the partial amount left.

In this way, we would have in-wallet trading, colored coins, and a second deflationary asset inside biblepay.

My projection shows that the retirement coins would deflate for 4000 days before reaching a floor where they would be emitted at approximately 1 per day (if we start with a million per day).  I think at that point, I would like the system to reverse split the coins and start over, so that we perpetually have a deflationary retirement asset inside BBP.

One benefit of having this particular feature is we would attract outside investors that would need to buy BBP in order to have the ability to buy rBBP and they also potentially download the wallet and be users and might have a tendency to be long term holders.


So, I understand that this second colored coin could be used as private payment between users, without the fear of a possible dumping in value due to exchange speculation. In other words, it´s a more stable asset for long term savings. To me looks like a very good idea.
newbie
Activity: 7
Merit: 0
Not sure if I am missing the info anywhere but is it possible to mine using software other than the wallet? Cpuminer? sgminer? ccminer? etc?
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
I just wanted to mention that I have been a little busy lately (other than being interrupted to upload the pool, which is a huge necessity), with a brand new cryptocurrency feature for biblepay.  I think it might be "the" feature for us that gives us the edge to the top 50.

I'm thinking about adding colored coins into biblepay with an integrated 401k or retirement account fund inside the wallet.  And in-wallet trading.

I'm thinking maybe we can be the first coin with the ability to trade BiblePay for our second asset inside the wallet (other than Ripple, but technically, Ripple is a network of market makers making existing markets).  This is a little different.

I'm thinking we emit a new deflationary colored currency (called either retirement coins or 401k coins) inside the wallet on a schedule decreasing by 1% per day.  Then, the wallet will keep track of both normal balance and "colored coin" balances.  So you would have your BBP balance and your rBBP balance. 

   Starting on the day we have retirement coins, the retirement system would emit 1 million retirement coins per day equally divided over 202 daily blocks to the miners who mine the blocks.  However each day, the emission rate would decrease by 1% .  So on day 2 we would emit 10,000 coins less (or 990,000 retirement coins over 202 blocks).  Each block solver would receive normal BBP, plus a separate share of colored retirement coins.  If you mined 4,000 retirement coins on day #1, your balance would now be:  1,000,000 BBP and 4,000 rBBP (retirement bbp). 

You cannot send colored coins to an exchange to sell them and cannot buy colored coins on an exchange.
All colored coins must be sent in a transaction that includes a reference to the root of the colored coins (another words, the colored indicator on the tx, the previous output is colored, and the new vout for the receiver is colored).

Available coins for spending will never select colored coins for spending (IE They cannot be spent). But they can be Traded for BBP with other holders through Trade transactions.

A new RPC command will allow you to send colored coins back and forth among others, if you want to give them to others.

Now here is where it gets interesting.  If we view the colored coins as a deflationary retirement account (assuming that IF they are becoming scarcer, storing FIAT in rBBP would theoretically result in a gain in value).

We implement in-wallet trading to allow trading from BBP to rBBP.  So we would have RPC commands to "execute order SELL 9000 rBBP for 1100 BBP" for example.  Other in-wallet users would "execute order BUY rBBP 5000 for 700 BBP".  When the matching engine matches an order over the nodes, one masternode  who is the chosen winner of the round (chosen winner meaning which masternode has the closest hash to the center of the blockhash for the current BBP block, can be active market maker for this tx).

At this point, the masternode jumps in, Locks the trade, grabs the collateral from the seller and the buyer, crosses the trade, then unlocks it and it is completed.  We will have a Trading log in biblepay, so you can go into your separate debug file and monitor STEPS that occur during trading.  (In case something goes wrong partially through).

Lastly, partially executed orders would be changed via a MODIFY - so if only 1000 got filled your order would readvertise with the partial amount left.

In this way, we would have in-wallet trading, colored coins, and a second deflationary asset inside biblepay.

My projection shows that the retirement coins would deflate for 4000 days before reaching a floor where they would be emitted at approximately 1 per day (if we start with a million per day).  I think at that point, I would like the system to reverse split the coins and start over, so that we perpetually have a deflationary retirement asset inside BBP.

One benefit of having this particular feature is we would attract outside investors that would need to buy BBP in order to have the ability to buy rBBP and they also potentially download the wallet and be users and might have a tendency to be long term holders.
full member
Activity: 1179
Merit: 131


Thanks for posting the code.  I'll play around with it tonight and see if I can get a test pool running.  And no that wasn't me that posted on there Smiley


Just let me know when you get the ASPX compiled and "almost" running (IE pool starts in debug mode and you cannot login).  At that point I will upload the SQL backup file of the empty database into github.  (I will get to it hopefully tomorrow).  So dont waste time recreating the schema as I have all of it.


Ironically what I have wasted hours on so far is getting the daemon to connect!  I thought maybe it was an incompatibility thing with win 2016, tried it on win 2012 with no luck.  Firewall is off both in the OS and through Amazon EC2.  Could it be possible that something is up with those 2 default nodes?  I see someone else posted the same issue earlier.  My QT-Wallet on my local box works fine, and my other linux VM is mining without problems.  Seems like maybe this has to do with initially populating the nodes?



Hi,
First on the daemon inside the AWS cloud (or wherver you want to run biblepayd as the pool hot wallet) ensure this is in biblepay.conf:

rpcuser=myuser
rpcpassword=mypass
rpcallowip=your_public_ip
rpcallowip=your_home_ip
rpcallowip=127.0.0.1
rpcport=30000
server=1
daemon=1


Then go to home computer and ensure you can 'telnet daemon_public_ip 30000' ensure that that answers?

Ok, I will start working on that biblepay.bak file for you to see also.

Thanks.




Yes but I'm not even getting that far.  Like I can't even get the daemon to sync up to the blockchain.  It seems like it momentarily will find a peer, then back to no connection.  I'm going to give this a try in Google Compute, it could be just an amazon thing.



Even though the firewall is open on the windows 2012 server, check AWS master console to see if you are subject to the AWS default firewall policy. I remember at work we had to clone it and modify it.

Then from the server you can install telnet client and try the same test from the command line through the public IP.

Also you can install the block explorer as an add node, but I doubt thats it.


** I uploaded the SQL database creation scripts to github **
Now you can run schema create and then data create.

 

Thanks for the help.  I tested on Google compute and had the same problem.  on Google after submitting the addnode "node.biblepay.org" "onetry" command a bunch of times it finally connected to the node.  I went back to AWS and that command didn't fix it on that side.  I finally just logged into the linux box I have mining and grabbed the address of one of the peers my daemon there was connected to and added it as a node, it instantly connected.  Kind of a weird problem but its working now.  Last night I got up to the point of installing IIS.  I'm at work right now but hopefully I can wrap this up mostly tonight.
full member
Activity: 574
Merit: 104
"Is there any chance we will be seeing an ARM supported wallet? Preferably RPi 3?" -chrisnelsonx via /r/BiblePay
https://www.reddit.com/r/BiblePay/comments/6ummuj/how_to_mine_biblepay_on_linux/do7yfw1/

Yes, someone here on the forum said they were compiling biblepay on arm the other day, and said they would be excited to post the HPS of the pi.  Anyone?


Yeah, that was me. But the compile failed. I don't have enough linux knowledge to work it all out unfortunately, but if someone else wants to try...?
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
"Is there any chance we will be seeing an ARM supported wallet? Preferably RPi 3?" -chrisnelsonx via /r/BiblePay
https://www.reddit.com/r/BiblePay/comments/6ummuj/how_to_mine_biblepay_on_linux/do7yfw1/

Yes, someone here on the forum said they were compiling biblepay on arm the other day, and said they would be excited to post the HPS of the pi.  Anyone?

Afaik, to do this, there are about 50 lines of code that might need to be added- things that hint the compiler to do certain things.
When we get to the stage of having a PPM for linux, we can ask our configuration manager to create a compile step for arm and for mac.

I think once we attract a few devs into our slack team, this would be a good fit for someone who really likes to maintain our releases as a volunteer.
Once we have our IT voting running, we could put that person on payroll.

full member
Activity: 1260
Merit: 115
Help us Test Sanctuaries! (Masternodes)

HELP NEEDED FOR SANCTUARIES for Christmas go live:

Ive been doing a little testing over the last few days for the upcoming sanctuaries.  I discovered I will need a lot of help otherwise we cant go live with sanctuaries.

We need at least 8 or so testers in the sanctuary thread (the thread does not exist yet).  Im going to deprioritize the news testing thread, and create a sanctuary thread and post it here by the end of the day, and lets focus on testing in that thread otherwise, we wont have a chance of going live at Christmas.

There are a lot of variables, and here are some, that need worked out:

- Testing requires linux - because windows will not run watchman on the wall (thats the decentralized sanctuary database)
- Testing requires 500,000 bbp to be sent to the new testnet masternode (actually send more, so you have extra first) - this is not the final amount to run a sanctuary, its the testnet amount
- Testing requires an external open IP, IE you need to be able to run with the firewall port 40001 open
- Testing needs to have the latest version of BBP compiled from source

As you can see this is a complicated endeavor and therefore requires a lot of help to get this working properly by Christmas.

If you want to get started you can do the above and sync the node up in testnet and then you will be almost ready to help.
The reason I cant do this myself is there are security rules in place that hang up on other sanctuaries if certain conditions are not met, and they cant be disabled.  One particular rule is dont accept inbound connections from sanctuaries unless the mnsync status is 999, and that will fragment the network.  IE we need more than 4 or so synced nodes to test this properly.  Also, the governance qurorum is going to require a few synced sanctuaries in order for us to test voting on the fake proposal.  The fake proposal will have the orphanage budget in it, etc.  Otherwise, I cant see the votes.

Here it is, lets move the Sanctuary testnet conversation here :

http://forum.biblepay.org/index.php?topic=16.msg94#msg94

One addnode is : node.biblepay.org

You should be able to hit 'telnet node.biblepay.org:40001'

Ill post a hash over there.
full member
Activity: 1260
Merit: 115
"Is there any chance we will be seeing an ARM supported wallet? Preferably RPi 3?" -chrisnelsonx via /r/BiblePay
https://www.reddit.com/r/BiblePay/comments/6ummuj/how_to_mine_biblepay_on_linux/do7yfw1/
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords


Thanks for posting the code.  I'll play around with it tonight and see if I can get a test pool running.  And no that wasn't me that posted on there Smiley


Just let me know when you get the ASPX compiled and "almost" running (IE pool starts in debug mode and you cannot login).  At that point I will upload the SQL backup file of the empty database into github.  (I will get to it hopefully tomorrow).  So dont waste time recreating the schema as I have all of it.


Ironically what I have wasted hours on so far is getting the daemon to connect!  I thought maybe it was an incompatibility thing with win 2016, tried it on win 2012 with no luck.  Firewall is off both in the OS and through Amazon EC2.  Could it be possible that something is up with those 2 default nodes?  I see someone else posted the same issue earlier.  My QT-Wallet on my local box works fine, and my other linux VM is mining without problems.  Seems like maybe this has to do with initially populating the nodes?



Hi,
First on the daemon inside the AWS cloud (or wherver you want to run biblepayd as the pool hot wallet) ensure this is in biblepay.conf:

rpcuser=myuser
rpcpassword=mypass
rpcallowip=your_public_ip
rpcallowip=your_home_ip
rpcallowip=127.0.0.1
rpcport=30000
server=1
daemon=1


Then go to home computer and ensure you can 'telnet daemon_public_ip 30000' ensure that that answers?

Ok, I will start working on that biblepay.bak file for you to see also.

Thanks.




Yes but I'm not even getting that far.  Like I can't even get the daemon to sync up to the blockchain.  It seems like it momentarily will find a peer, then back to no connection.  I'm going to give this a try in Google Compute, it could be just an amazon thing.



Even though the firewall is open on the windows 2012 server, check AWS master console to see if you are subject to the AWS default firewall policy. I remember at work we had to clone it and modify it.

Then from the server you can install telnet client and try the same test from the command line through the public IP.

Also you can install the block explorer as an add node, but I doubt thats it.


** I uploaded the SQL database creation scripts to github **
Now you can run schema create and then data create.

 
Pages:
Jump to: