BiblePay - New Coin Launch - Official Thread

[bible_pay]

Its a sealed contest, what I've gathered is those get higher quality entries.  So once it closes we'll have 14 days to select a winner, and there is polling system we can use to do it here or at the forum.

To increase the chance of getting better results do not forget to invite top talents.



I was after a minimalist logo, so I searched logo designers with "minimal", "flat" keywords and then invited them to my project.

I am not sure minimal will suit the best so a few minimalist artist a few icon artist etc can be invited. This will increase the overall quality as well.

A few suggestions
1) All designs should have white background (transparent is ok). No mockup should be allowed. Which will surely mislead non-designers.
2) Always do a cross check if the logo is genuine. Google images and tiny eye will give you hints.

Thanks for the pointers, but I wanted to add :
The final logo package MUST have a transparent background on all PNGs.

And I might as well add: Some ideas should be dark themes and some on light so the community can vote on the favorite color scheme.

In the end, the one we pick with the transparent backgrounds, one use case for it is the pool logo which currently has a black theme (IE the transparent coin will still be used on the pool), and, if the wallet has a light Gen2 theme, the transparent logo will not break down for us, and our web site might have a totally different (hope not, it should be consistent) but it could have a totally different background on a particular page, and logo should not break down, hence part of the reason that all images are transparent.  The other is transparent PNGs are used in the wallet and size restrictions are important.

[bible_pay]

Its a sealed contest, what I've gathered is those get higher quality entries.  So once it closes we'll have 14 days to select a winner, and there is polling system we can use to do it here or at the forum.

I just made you a moderator on forum.biblepay.org, so now you should be able to create a topic for this logo contest and link it here, and ask for fundraiser funds.
I was thinking you could provide your BBP address and ask for BBP donations and occasionally let us know how much we raised in $ toward the goal.

Id start soon so we can start getting the kitty increasing for you as the logo draws to a close.

[painmaxx]

I still do not understand what promotes this project? Why are you encroaching on the holy things that people have?

[bible_pay]

I still do not understand what promotes this project? Why are you encroaching on the holy things that people have?

Please click the following link:

http://accountability.biblepay.org/

and then click on Orphans | Sponsored orphan list.

Then click on one of the rows.

And then please tell us if you don't see that we are trying to be the light of the world.

[bible_pay]

Summary on our sanctuary testing so far:

We have about 8 people helping us in testnet testing the future sanctuaries.  Out of the 8, I think about 4 are very active.
Out of the 4 we only have a few sanctuaries actually running.

We could still use at least 2 more active testnet sanctuaries, as we are getting close to the point where we need to mock up a fake monthly Compassion invoice (for recurring orphan expenses) and actually vote on it in testnet (from the sanctuaries), see it enter into the budget, and then watch it pay in a superblock, and verify that it becomes a historical expense paid in Proposals | Historical Proposals. (We also need to test a more elaborate budget, one in which a couple users create a proposal, and we let the community shoot down the bad proposal - by voting it out, and approve another miscellanous proposal submitted by someone other than me, and watch 2+ proposals enter the same superblock- this tests the ability for our sanctuary code to combine budget items and ensure it can handle distinct public key receiving addresses, amounts, and ensure it can handle the situation where we would not want to exceed the maximum budget for that period).

So today, I think we are within hours of mocking up the actual orphan invoice and asking Sanctuaries to vote on it in testnet.  So it is critical we get one more working sanctuary over in testnet so that we can ensure when I ask for a vote, that we have a supermajority of Yes so the object moves to its next phase in accountability.biblepay.org and becomes part of the superblock.

Here is the link if you want to get active in testnet and create one:

http://forum.biblepay.org/index.php?topic=16.75


Thanks!

[ferohers]

Its a sealed contest, what I've gathered is those get higher quality entries.  So once it closes we'll have 14 days to select a winner, and there is polling system we can use to do it here or at the forum.

To increase the chance of getting better results do not forget to invite top talents.

https://preview.ibb.co/dMagVb/1.png

I was after a minimalist logo, so I searched logo designers with "minimal", "flat" keywords and then invited them to my project.

I am not sure minimal will suit the best so a few minimalist artist a few icon artist etc can be invited. This will increase the overall quality as well.

A few suggestions
1) All designs should have white background (transparent is ok). No mockup should be allowed. Which will surely mislead non-designers.
2) Always do a cross check if the logo is genuine. Google images and tiny eye will give you hints.

Thanks for the pointers, but I wanted to add :
The final logo package MUST have a transparent background on all PNGs.

And I might as well add: Some ideas should be dark themes and some on light so the community can vote on the favorite color scheme.

In the end, the one we pick with the transparent backgrounds, one use case for it is the pool logo which currently has a black theme (IE the transparent coin will still be used on the pool), and, if the wallet has a light Gen2 theme, the transparent logo will not break down for us, and our web site might have a totally different (hope not, it should be consistent) but it could have a totally different background on a particular page, and logo should not break down, hence part of the reason that all images are transparent.  The other is transparent PNGs are used in the wallet and size restrictions are important.

All good. White will help you to match apple to apple. you bring down all the designs to simple white background to see how they perform in a basic environment. The final product will come in illustrator format or any kind of vector.

[bible_pay]

All good. White will help you to match apple to apple. you bring down all the designs to simple white background to see how they perform in a basic environment. The final product will come in illustrator format or any kind of vector.

+++

[seeksilence]

Does the pool mining have advantage over solo mining?
Just have some time reading the miner code.

I saw in BibleMiner
   in nonce loop            if ((pblock->nNonce & 0x7FFF) == 0)
                                  break;
       out of the loop                            if (pblock->nNonce >= 0xFF)                    
                                                               break;
 So anything after the above statement will be ignored (pblock->nNonce will be 0x8000 which is always > 0xFF):
                // Update nTime every few seconds
             if (pindexPrev)
            {
               if (UpdateTime(pblock, chainparams.GetConsensus(), pindexPrev) < 0)
                  break; // Recreate the block if the clock has run backwards,
                        // so that we can use the correct time.
            }
 The miner cannot just update the ntime to create a new task without createnewblock?    

[bible_pay]

Does the pool mining have advantage over solo mining?
Just have some time reading the miner code.

I saw in BibleMiner
   in nonce loop            if ((pblock->nNonce & 0x7FFF) == 0)
                                  break;
       out of the loop                            if (pblock->nNonce >= 0xFF)                    
                                                               break;
 So anything after the above statement will be ignored (pblock->nNonce will be 0x8000 which is always > 0xFF):
                // Update nTime every few seconds
             if (pindexPrev)
            {
               if (UpdateTime(pblock, chainparams.GetConsensus(), pindexPrev) < 0)
                  break; // Recreate the block if the clock has run backwards,
                        // so that we can use the correct time.
            }
 The miner cannot just update the ntime to create a new task without createnewblock?    

Actually, you did find something valuable here and this is true: we would gain a very small HPS increase by readjusting that 0xFF condition that is out of the loop- to the proper trigger level- and now - I will fix this asap.

But I do want to mention this so no one freaks out:  This inner loop is only exited about once every 15 seconds, so the difference between updating the timestamp and creating a new block template will not be very much (probably 10 HPS difference), but, thank you very much for pointing that out. 

I think what happened is I raised the inner loop high to try to squeeze out more HPS, and never readjusted the 0xFF.

[PhaseshiftUK]

Summary on our sanctuary testing so far:

We have about 8 people helping us in testnet testing the future sanctuaries.  Out of the 8, I think about 4 are very active.
Out of the 4 we only have a few sanctuaries actually running.

We could still use at least 2 more active testnet sanctuaries, <snip>

I'm just in the process of setting up a sanctuary now.  I hope that helps. :-)

[bible_pay]

Two things regarding todays progress:

1)  If any devs out there have been on the fence and you like the idea of the one click web mining by clicking a URL discussed in the last page, I believe it was called Monero web mining, and you want to take on that project feel free to contact us here or at contact@biblepay.org.


2)  In addition to what I think will be a groundbreaking feature (adding retirement accounts in our wallet, a place to sweep your extra BBP in hopes that it grows while it is stored in the 401k account):
    I was thinking today, it would be novel for us to be the first coin to create a couple new transaction types in the wallet:  Contingent transactions and Cancelable transactions.  Right now, you cannot cancel a bitcoin transaction because once it is broadcast and included in a block, it cannot be reversed.  But I was thinking, we could add a field for contingency rules.  The transaction is not included in a block unless a certain condition is met.  If the condition is not met, the tx may be canceled.

   One condition I discovered that would be useful for the design of the retirement account is a contingent transaction based upon another contingent transaction.

  So for example, User A wants to buy User B's 401k balance, but, does not want to spend asset A until the escrow for Asset B is broadcast into the memory pool.  So what we can do is add a new transaction type called ContingentUpon, and in the scripting language, honor the amount, send address of escrow, signature, coin color, senders address, signature and coin color.

And basically what would happen is (lets go through a failed transaction and a successful one):

FAILED TRANSACTION (IE CONTINGENT WORKED):
User A advertises that he wants to buy 1000 rBBP for 1000 BBP.
User B advertises that he wants to sell 1000 rBBP for 1000 BBP.
(These are through the new RPC trading commands in the console).

User A's client realizes that B wants to trade, so User A creates an advanced contingent transaction (A requires B to create a contingent transaction otherwise As transaction will be canceled), while A's contingent tx is broadcast and accept in everyones memory pool.

User B deliberately fails to send User A the rBBP owed (lets say, because he had a corrupt wallet.dat file, with no actual rBBP in his wallet, while fooling the client) so therefore he cant really afford to send the 1000 rBBP back to user A, so A is going to want his money back (IE does not want the trade to go through).  At this point, the tx is not in a block yet.

The complex tx sent by A *would be canceled* and never mined by a miner - because the mandatory memory pool rule (for contingent transactions) would not allow a miner to mine the complex tx.

SUCCESSFUL CONTINGENT TRANSACTION:

User B creates a complex contingent transaction and broadcasts it while transaction A is still in the memory pool.
Since B satisfies A's condition, both A & B will be mined by a miner, successfully crossing the transaction and completing the sale safely.

In this way a contingent transaction allows both a & b to transact safely, and adds value to the Bitcoin transaction set.

This transaction method also appears to be much more efficient than one with two sets of collateral, lag time, confirmations, and a market maker.  Technically, it can be done with two participants only if we used the more advanced Contingent tx type.

[seeksilence]

Is the new idea like the smart contract?

BTW, I just checked the pool leaderboard. It looks like the pool can use one workerid for multiple miners now:
inblue  blu-a11  5818.9(HPS)   721669.92(HPS2)   1334(shares)

Some changes on the pool code?

[616westwarmoth]

Is the new idea like the smart contract?

BTW, I just checked the pool leaderboard. It looks like the pool can use one workerid for multiple miners now:
inblue  blu-a11  5818.9(HPS)   721669.92(HPS2)   1334(shares)

Some changes on the pool code?

You've pretty much been able to use a single workerid for multiple miners for a while, it just shows the HPS of one miner and the HPS2 is the aggregate of all miners using that ID.  No real advantage or disadvantage to doing it.

[PhaseshiftUK]

<snip>
   One condition I discovered that would be useful for the design of the retirement account is a contingent transaction based upon another contingent transaction.

  So for example, User A wants to buy User B's 401k balance, but, does not want to spend asset A until the escrow for Asset B is broadcast into the memory pool.  So what we can do is add a new transaction type called ContingentUpon, and in the scripting language, honor the amount, send address of escrow, signature, coin color, senders address, signature and coin color.

And basically what would happen is (lets go through a failed transaction and a successful one):

FAILED TRANSACTION (IE CONTINGENT WORKED):
User A advertises that he wants to buy 1000 rBBP for 1000 BBP.
User B advertises that he wants to sell 1000 rBBP for 1000 BBP.
(These are through the new RPC trading commands in the console).

User A's client realizes that B wants to trade, so User A creates an advanced contingent transaction (A requires B to create a contingent transaction otherwise As transaction will be canceled), while A's contingent tx is broadcast and accept in everyones memory pool.

User B deliberately fails to send User A the rBBP owed (lets say, because he had a corrupt wallet.dat file, with no actual rBBP in his wallet, while fooling the client) so therefore he cant really afford to send the 1000 rBBP back to user A, so A is going to want his money back (IE does not want the trade to go through).  At this point, the tx is not in a block yet.

The complex tx sent by A *would be canceled* and never mined by a miner - because the mandatory memory pool rule (for contingent transactions) would not allow a miner to mine the complex tx.

SUCCESSFUL CONTINGENT TRANSACTION:

User B creates a complex contingent transaction and broadcasts it while transaction A is still in the memory pool.
Since B satisfies A's condition, both A & B will be mined by a miner, successfully crossing the transaction and completing the sale safely.

In this way a contingent transaction allows both a & b to transact safely, and adds value to the Bitcoin transaction set.

This transaction method also appears to be much more efficient than one with two sets of collateral, lag time, confirmations, and a market maker.  Technically, it can be done with two participants only if we used the more advanced Contingent tx type.

You might want to look at 0x (ZRX) for ideas - they have implemented an API to allow decentralised exchanges in this manner.

[616westwarmoth]

Its a sealed contest, what I've gathered is those get higher quality entries.  So once it closes we'll have 14 days to select a winner, and there is polling system we can use to do it here or at the forum.

I just made you a moderator on forum.biblepay.org, so now you should be able to create a topic for this logo contest and link it here, and ask for fundraiser funds.
I was thinking you could provide your BBP address and ask for BBP donations and occasionally let us know how much we raised in $ toward the goal.

Id start soon so we can start getting the kitty increasing for you as the logo draws to a close.

I'll get that done tomorrow, we've gotten a lot of entries, but many have been standard logos and not within the parameters 220x220.  Some novel takes on things really.  You might be able to see some of the entries even though its supposed to be sealed, it seems that might be something that is up to the submitter but I'm not sure.

[m4tsby]

<snip>
   One condition I discovered that would be useful for the design of the retirement account is a contingent transaction based upon another contingent transaction.

  So for example, User A wants to buy User B's 401k balance, but, does not want to spend asset A until the escrow for Asset B is broadcast into the memory pool.  So what we can do is add a new transaction type called ContingentUpon, and in the scripting language, honor the amount, send address of escrow, signature, coin color, senders address, signature and coin color.

And basically what would happen is (lets go through a failed transaction and a successful one):

FAILED TRANSACTION (IE CONTINGENT WORKED):
User A advertises that he wants to buy 1000 rBBP for 1000 BBP.
User B advertises that he wants to sell 1000 rBBP for 1000 BBP.
(These are through the new RPC trading commands in the console).

User A's client realizes that B wants to trade, so User A creates an advanced contingent transaction (A requires B to create a contingent transaction otherwise As transaction will be canceled), while A's contingent tx is broadcast and accept in everyones memory pool.

User B deliberately fails to send User A the rBBP owed (lets say, because he had a corrupt wallet.dat file, with no actual rBBP in his wallet, while fooling the client) so therefore he cant really afford to send the 1000 rBBP back to user A, so A is going to want his money back (IE does not want the trade to go through).  At this point, the tx is not in a block yet.

The complex tx sent by A *would be canceled* and never mined by a miner - because the mandatory memory pool rule (for contingent transactions) would not allow a miner to mine the complex tx.

SUCCESSFUL CONTINGENT TRANSACTION:

User B creates a complex contingent transaction and broadcasts it while transaction A is still in the memory pool.
Since B satisfies A's condition, both A & B will be mined by a miner, successfully crossing the transaction and completing the sale safely.

In this way a contingent transaction allows both a & b to transact safely, and adds value to the Bitcoin transaction set.

This transaction method also appears to be much more efficient than one with two sets of collateral, lag time, confirmations, and a market maker.  Technically, it can be done with two participants only if we used the more advanced Contingent tx type.

You might want to look at 0x (ZRX) for ideas - they have implemented an API to allow decentralised exchanges in this manner.

Fantastic idea, great project and team. I believe things to move this direction inevitably

[jaapgvk]

Hello all, I have configured a Windows Server 2008 instance on Azure. I have configured the biblepay.conf like here:

Code:

addnode=node.biblepay.org  
addnode=biblepay.inspect.network  
gen=1  
genproclimit=1
poolport=80  
pool=http://pool.biblepay.org  
workerid=prometheus

but from getmininginfo it seems it's not pool-mining:

Code:

getmininginfo
04:18:03
{
"blocks": 0,
"currentblocksize": 0,
"currentblocktx": 0,
"difficulty": 4.656542373906925e-009,
"errors": "",
"genproclimit": 1,
"networkhashps": 0,
"hashps": 0,
"minerstarttime": "10-15-2017 08:15:28",
"pooledtx": 0,
"testnet": false,
"chain": "main",
"biblepay-generate": true,
"poolinfo1": "",
"poolinfo2": "",
"poolinfo3": "",
"miningpulse": 0,
"poolmining": false
}

Could be a firewall issue as is enabled by default? It seems it is not synchronizing with the network, also.

Any help is very welcome, thanks.

Does your wallet find peers at all (tools>peers list)? The default port for the Biblepay-mainnet is 40000. Maybe that port is blocked by your firewall?

Here are some ip's that you could try to 'addnode':"
addnode=107.191.39.175:40000
addnode=65.116.124.47:40000
addnode=94.130.49.121.40000

[bible_pay]

Its a sealed contest, what I've gathered is those get higher quality entries.  So once it closes we'll have 14 days to select a winner, and there is polling system we can use to do it here or at the forum.

I just made you a moderator on forum.biblepay.org, so now you should be able to create a topic for this logo contest and link it here, and ask for fundraiser funds.
I was thinking you could provide your BBP address and ask for BBP donations and occasionally let us know how much we raised in $ toward the goal.

Id start soon so we can start getting the kitty increasing for you as the logo draws to a close.

I'll get that done tomorrow, we've gotten a lot of entries, but many have been standard logos and not within the parameters 220x220.  Some novel takes on things really.  You might be able to see some of the entries even though its supposed to be sealed, it seems that might be something that is up to the submitter but I'm not sure.

Yeah, I tried to click on every one yesterday and can only see a fluffy icon.  Maybe they have it so your logged in account receives the actual image.

[bible_pay]

Is the new idea like the smart contract?

BTW, I just checked the pool leaderboard. It looks like the pool can use one workerid for multiple miners now:
inblue  blu-a11  5818.9(HPS)   721669.92(HPS2)   1334(shares)

Some changes on the pool code?

Not like a smart contract, like an enhanced transaction type.

Here is bitcoins script language, if you would like to take a look at it:
https://en.bitcoin.it/wiki/Script

This is more like extending the script of bitcoin transactions to allow the Contingent order type (one tx depends on another tx's data and rule evaluation to be filled).

A smart contract is more of a coin-level programming language that allows you to embed a script that can be executed over multiple instructions-blocks-peers.  If we had an API for example, that pulled in the trusted bitcoin price into the sanctuary quorum, and the sanctuaries signed that price and inserted in the chain ocasionally, then we could possibly go as far as implementing a smart contract that said "if price Y > X, then release escrow Z to A on the expiration date B".  That would be a smart contract.

[bible_pay]

This transaction method also appears to be much more efficient than one with two sets of collateral, lag time, confirmations, and a market maker.  Technically, it can be done with two participants only if we used the more advanced Contingent tx type.

You might want to look at 0x (ZRX) for ideas - they have implemented an API to allow decentralised exchanges in this manner.

Thanks, well I took a look at ZRX, and it appears that they implemented decentralized trading in ethereum (although Im not sure if they delivered it, there was an article saying the ICO didnt include the trading engine), but anyway, its much easier, a level of magnitude easier to program trading in ethereum because they already have smart contracts running.  I take for granted that Ethereum and Ripple do certain things for the blockchain, while bitcoin and other BerkeleyDb coins provide value in other ways.   We are in the bitcoin camp, because we have a variation of bitcoin with masternodes running on a berkeleyDB database.  So I was looking to enhance the base Bitcoin transaction in this case.  Speaking on the earlier post however, it would not be outside of the realm of possibility to go further and ask our Sanctuaries to store signed crypto prices in the chain (IE each of them would pull prices once per hour, keep a database, and if they all agree on the price, vote on it and store it).  That might allow us to implement smart contracts also in the future, which would be valuable if a node wants to buy or sell in a smart contract based on an outcome.

I also could not find any leveldb coin that already has decentralized trading, or this transactiontype, so I maintain this would potentially still be a novel feature for bitcoin based coins.