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

is this normally for pool?     

Load:   156.25%

bible_pay its overload for hw or?

I've just tested this, and it worked. :-)

Faucet is live.

EDIT: Ill up the payout later once I see this is safe.

EDIT2:  I made the faucet available from the outside world also (accountability.biblepay.org) so people can paste in PR blogs.

Ill add one to the pool and give away 100 bbp per ip address.

If anyone feels like running one that is already written, go for it also if you feel like it

Is there coming a faucet for biblepay?

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.

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.

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.

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

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

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.

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

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.

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?

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 [email protected].


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.

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

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.

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?    

+++

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.