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 - alee67

Pages: [1] 2
1
Oh that one, ok yeah your right, I didn't see that one, it does end in your pin.

Ok, I see the problem.  Luckily this has been resolved without an upgrade.  Basically, I had to change a setting that allows the TXID plus the ordinal to be a valid transaction hash (in contrast to just the plain old txid).  Now it sees all txids on the network (even if we have more than one per transaction hash).

Now you are in the leaderboard...  Sorry about that...

Thanks for fixing this!  If I understand correctly, the problem before was that it was only looking for one output in the transaction with my foreign coin address, and when it found the change output with that address (since I was sending it from my address back to itself), it didn't look at the other output that had the same address?

1000 BBP

2
Bottom line is, your DOGE address, DNr*, has an unspent output from TXID bc157112f04f5e2f9d64d7a3a2d8ea706dfb501516a600a930aa3e5509b4c700 for 1.58372072 and not for
1.5875720 like we require.

Here is the current UTXO:
https://api.blockchair.com/dogecoin/dashboards/address/DNrVShF3dp1gj6KaPGfR6ADdhU4WQEE3yX

Our users need to adjust the utxos to end in the correct pin suffix - or they do not count.

I've sent DOGE from binance and from coinbase to trustwallet, and yes you do have control over what you send to your address if you check further into the fees. 

If you are wondering why they are not additive, for security purposes, we do not allow non matching UTXOs to be additive.  Each pin matched UTXO counts and is additive.

It's the other UTXO output from the transaction to the same address, for 402.0007572(0) DOGE, that's supposed to be the stake: https://blockchair.com/dogecoin/transaction/bc157112f04f5e2f9d64d7a3a2d8ea706dfb501516a600a930aa3e5509b4c700?from=trustwallet.  The smaller amount was the change.

1000 BBP

3
Hi Alee,

So I think you might be experiencing a transaction deduction issue from the provider you sent it from.  When I reproduce with your DOGE address I see the pin is supposed to be 75720 (its ok this is publicaly calculable) and the amount sent to the address is 1.58372072 leading me to believe a fee was deducted first.

If you are sending to trustwallet from binance or from SX, on SX you have to pay the fee yourself, and on binance you have to take out your calculator and add the fee on first.  Bottom line is the address has to receive '75720' for it to count (in the suffix).  On binance I add the fee on with my calculator for example...




8200 BBP

That was the change, worth about $0.40.  I sent the stake from my Trust Wallet address back to my Trust Wallet address, so both outputs went to the same address.  This is the transaction:

https://blockchair.com/dogecoin/transaction/bc157112f04f5e2f9d64d7a3a2d8ea706dfb501516a600a930aa3e5509b4c700?from=trustwallet

1000 BBP

4
I tried creating a DOGE stake; I sent an amount of DOGE from Trust Wallet to itself ending with the PIN over 4 hours ago.  It doesn't show up at all in the leaderboard, and 'listutxostakes 0' says that I have 0 DOGE staked.  In Portfolio Builder, when I click on 'Query UTXO', it shows the change received from the transaction, which went to the same address, 'DNrVShF3dp1gj6KaPGfR6ADdhU4WQEE3yX', and that amount doesn't end in the PIN, of course.  The PIN for the DOGE address ends in '0'.  Could it be that the trailing zero in the amount staked is getting dropped, so the PIN isn't being recognized?

1000 BBP

5
I have an opposing view that what we've done is bent over backwards to provide a high level of flexibility for the user to stake currencies that are not even related to biblepay and earn rewards, for very little fees.

It's a one time adjustment, and the transaction charges are something inherently high in bitcoin and ethereum, not on our end.



8000 BBP

I didn't mean this as a criticism of BiblePay.  Using a 5 digit PIN is a reasonable security measure to prevent possible abuse, while allowing the user to keep the foreign cryptocurrency themselves.  It had occurred to me that an extremely limited way around the minimum 1 million SAT stake for BTC might be, if the PIN is, say, 12345, would be to stake exactly 0.00012345 or 0.0012345 BTC.  It might be helpful if the documentation noted the high minimum value for a BTC stake, and the high BTC and ETH fees.

1000 BBP

6
Yeah, I hear you, I was going through the same thing in TestNet when I wanted to test BTC.  If you add three zeroes before your pin, (IE .00012345) it gets it down to about $20 at the end, but nevertheless thats a lot of money to make an 'adjustment'.   (Same goes for ethereum, as far as network fees).

DOGE is turning out to be very valuable for those type of things.

Of course Stellar only costs .01 to make an adjustment.



8000 BBP

Since 8 decimal places seems to be standard, if you put in 3 zeroes before the PIN, it seems that you need to stake over 0.010 of whatever currency for the PIN to be recognized, which is a significant amount for BTC (or perhaps simply stake the PIN itself with 2 or 3 zeroes before it, which gives very little flexibility.)

7
Yeah, it was due to our address length check on BTC; I have added the 42 char (bech32) support to 1.6.2.8 - please see latest release above.

Please try now!



8000 BBP

It seems to be accepting the address now, though now it doesn't seem to be working because I didn't have enough BTC to put a '0' between the PIN and the rest of the amount.  I think I'll be converting it to something else, which means I'll have to spend even more on network fees to send my BTC to an exchange.  I'm certainly never going to use BTC to buy coffee or pizza.

8
I had no problems creating a BBP only stake.  Thanks for the referral reward, Rob!

Now I'm trying to create a BTC stake, but when I paste the BTC address I copied from Trust Wallet, bc1q08tkcyac8dzwm5wzxacy898g2fu69nsj2kf7fc, Portfolio Builder says "Address invalid." when I click on either "Submit" or "Query UTXO."  Why isn't this working for me?

9
General Support - Solved / Re: BBP staking
« on: March 15, 2021, 12:15:22 AM »
Now I'm waiting for maintenance to finish on Freefaucet so I can send a couple over.

Are you trying to withdraw BBP from freefaucet.io?  They don't seem to be fixing that.  It didn't work for me a couple of weeks ago, and if you search this forum, you'll find that it wasn't working last fall.  It seems the only thing you can do on their site with BBP is to convert it to BRAZ and withdraw that.

10
General Support - Solved / Re: PODC setup
« on: October 09, 2020, 12:58:01 AM »
One last question. What happens if my wallet is not running for one or more days? Will I lose the PODC rewards of these days? Or will they be sent cumulatively to my wallet the next time the wallet sends the staking transaction or I issue the transaction manually (I think through "sendgscc wcg")?

Each of these is only good for one day.  If you run "sendgscc wcg" manually, you have to do it every day.  The window that you can do it in to get a day's reward is fairly large, but I'm not actually sure when it begins or ends.  If you don't send it in time, you won't get that day's reward.  If you leave the wallet running continuously, it's taken care of automatically.

11
Because we didn't enforce the sanctuary governance version, and 51% of the sancs upgraded early, you went on a fork before 217K.

The sanctuaries drive a hard consensus for the daily GSC block - making them an additional decision maker in our chain (in addition to POW). 



4200 BBP

OK, but my computer went on a fork three days AFTER I updated to 1.5.2.2, and was receiving PODC rewards during those three days.

12
1) I agree first of all that a *non-updated wallet* on the old chain before the mandatory cutover height should not have forked til *after* 217K.  That is something we will definitely prevent in the future by enforcing the version of the sancs up to the cutover height.

2)  On your question, Why would an up-to-date wallet end up on a fork 3 days *after* the mandatory height (updating later):
This is defintely possible in the dash world.  Here is how that happens.  If you accept a block on the main chain after the mandatory height on a non-upgraded wallet, these wallets will never erase the dirty block index flags without an -erasechain=1 (or an exec reassesschains command).  So basically at that point, the other wallets will ddos you (because you are then sending them invalid block headers).  So thats why we always need to erasechain if we upgrade late.

On the missing funds feel free to paste your CPK and estimated amount lost and I will give you a tip.



4200 BBP

I still don't understand.  I updated the wallet on 8/22, which then forked on 8/25.  This was days BEFORE the mandatory height, on 8/29 or 8/30.  I actually started trying to figure out if it was on a fork before the mandatory height had been reached by starting the wallet on another computer on 8/29.

13
Hi Dave,

The issue is that the supermajority of the sancs upgraded early and forced the protoversion up before the mandatory height started, and the GSC contents were being voted on by the wrong chain (because the sancs have communication no matter what chain they are on), then everything worked itself out yesterday now that we have 51% on the 1.5.2.2.  We'll have to consider that on our next mandatory to stop that behavior.   Anyway all the exchanges upgrade to 1.5.2.2 so we don't have fork risk so thats good.

I sent you an estimated payment from my account - please let me know if I didnt send you enough.

Have a good one!



4200 BBP

I updated to 1.5.22 on 8/22, and and was receiving PODC rewards through 8/25.  Then they stopped, along with the automatic GSC transmissions, though I sent them manually.  Yesterday, I started the wallet on a second computer, and discovered that the first had been on a fork since some time after the last PODC reward on 8/25, around the same time that davebbp said that he stopped receiving PODC rewards.  The second computer showed everything through the 8/25 PODC reward, but none of the later manual GSC transmissions.  One thing that seemed strange to me is that the first computer, the one on a fork, reported a larger number of sanctuaries, around 170, than the second computer, the one that isn't (I think) on a fork.  It also looked like blocks were regularly being generated on the fork, though the count was lower on the fork, which is how I finally concluded that the first computer was on a fork, and the second one wasn't on a (different) fork, by comparing the block counts with the block explorers.  In the end, I shut down both wallets, copied all the data from the second computer to the first and restarted the wallet on the first computer to fix things.

Why would an up-to-date wallet end up on a fork three days after updating?

14
Hi Alee,

Will this work for you?

https://github.com/biblepay/biblepay/tree/master/binaries

Thanks,
Rob


4200 BBP

Thanks!  I guess I wasn't clear that I had already successfully downloaded the wallet from biblepay.org, after multiple attempts.  I tried the download from Github, and it works much better for me.  The downloader (wget) knew the size of the download, and the download didn't stop early so I was able to get it in a single try.  It would be helpful if binaries of future versions continue to be available on Github as an alternate download site, since I've had the same problem downloading the wallet binaries from biblepay.org on previous versions, too.  Using Zip files makes it easy to test that the download is complete and error-free, though it does adds an extra step to install, which might not suit some people.

15
I made my first forum post, a complaint / suggestion.  My faucetcode is B5EWXaw4K9chi42LyD4f9wKwBeDLDm3zD1-517-64-18-10-192.  Thanks!

Pages: [1] 2