BIBLEPAY - DOGE DECENTRALIZED EXCHANGE

Check this out I just purchased these 5 sell orders which is 1.48 doge but only 0.1625 doge was deducted

also i recieved 7 tx of 2000 bbp when only 2 of the sell orders were for that amount

Check this out I just purchased these 5 sell orders which is 1.48 doge but only 0.1625 doge was deducted

also i recieved 7 tx of 2000 bbp when only 2 of the sell orders were for that amount

Ahh, thanks for the pics.
Luckily, I was the seller so in my wallet I was able to confirm each of these 5 tx's as the counterparty and diagnose this.

Tx 1 = height 565644, txid   f39e5eefa3e9b520d0f47622fc899ea0bb6517c6031f116969ce6ae79d9b0cb8   2000   0.000056   filled
Tx 2 = height 565644, txid   29d6b7afbfd5e225ea0e633853ff229815070d618ff323ab3fb4d9eefc116d03   2000   0.000076   filled

Tx 3 = memory-pool-error      4000   0.000076   error
Tx 4 = memory-pool-error      5000   0.000076   error
Tx 5 = memory-pool-error      7000   0.000076   error

So what is really interesting is somehow in my wallet, it sent the BBP but did not successfully sign over the remaining .22 DGZZ because of a memory pool error.  Not sure what that is, so I have to debug and try to reproduce this.

Checking

Check this out I just purchased these 5 sell orders which is 1.48 doge but only 0.1625 doge was deducted

also i recieved 7 tx of 2000 bbp when only 2 of the sell orders were for that amount

Yeah I found the problem... The good news is, this should actually improve the service in the end to be 100% reliable (which is what we need for this to have any adoption).  The bad news is its kind of complicated and requires a mandatory.

So in our memory pool we have a set of rules where atomics can fail if they violate the colored asset protocol.  Im going to need to modify that to account for multisig txs in some cases where it is allowed to transact the non colored plus the colored in one single atomic tx, as long as the sum(colored sender amount) = spent(colored recv amount).  This will allow the tx to go out in one single atomic tx (thats not exactly how it is today).

So ill work on this next then we can have a new mandatory.  I will probably do this in a way where we just re-test everything we have now and wait for that to finish before we add the complexity of fractional fills.

Please check back over the weekend guys.

I believe we will also have to have a sanc hard fork.

Biblepay v023.3 - Mandatory Upgrade for Entire Network

- Fix memory pool validation


https://github.com/biblepay/biblepay/releases/tag/v023.3-Mandatory




Let's give it another shot guys!

1) If all goes well, these trades should be fully atomic now, meaning that you lose the wrapped DOGE in the same TXID that you gain the BBP, or you lose the BBP and gain the wrapped DOGE atomically in the same TXID.  I just tested one (Note that if you do this you must test on two machines because the tx's are only constructed properly with a counterparty-- not with your own wallet); and it worked!  So far so good on my trade (good luck).  I also tested an ingate and an outgate (which are the same as before).  A nice bonus out of this new feature is if either party either does not have the funds or the tx fails, the entire trade fails and waits for the next block and tries again (which is nice if we lose our quorum for some reason).  Additionally these trades work with instantsend, so you should see the trade go through instantly and see the lightning bolt (when the supermajority of the sancs are upgraded properly).

2) After we get over this hump and things appear to work perfectly then we can move on to fractional fills and populating the metrics in.

was i suppose to wait for sancs to upgrade before testing ? because i think i got a similar error again when selling bbp 7 sells resulted in 18 tx out of bbp but i think i got all the doge

screenshots

could i be on a fork or something?

my blockheight 565864 - Sat Feb 15 14:35:08 2025 - 000000db04270eadc190de339a848e54cc3a027a3bda97eecd7bd25d5bafe171

cryptoid is up to 565880 ...  https://chainz.cryptoid.info/bbp/block.dws?565880

screenshots

You should be fine because it was a hard fork, 00000237a182585f0ce421958a4fce3bb73a86c7a8edc56c24ee9b3acd1c5255
is the hash for 565868 - are you synced with me now?
(We cant check chainz now until we notify them).

Actually I think it worked this time, because the trades that you made at that time- im looking at all the DOGE I lost and the BBP i gained.
I gained 84K bbp and lost 9.4 wrapped doge.  So you should have lost 84k bbp from your wallet.  I can tell its working now because every
tx in my wallet has 2 rows for each one (IE losing bbp, gaining wdoge). 

If you can check one all by itself and just watch it til it fills and then monitor your wdoge asset balance and your bbp balance you should see both change.

I just put a few more in

could i be on a fork or something?

my blockheight 565864 - Sat Feb 15 14:35:08 2025 - 000000db04270eadc190de339a848e54cc3a027a3bda97eecd7bd25d5bafe171

cryptoid is up to 565880 ...  https://chainz.cryptoid.info/bbp/block.dws?565880

Aha!  I see what you were talking about, I was doing some more testing to see exactly what is being transferred.
So realize that the Native BBP going from wallet to wallet will look fine in the transaction list, because the debit in one wallet is really a negative in the txlist, and the credit in the other wallet is a Credit, so that part is not confusing.

HOWEVER, on the colored asset (IE getassetbalance DOGE), since the atomic tx sends the original owner Change, it will actually look as if you are Receiving more DOGE PLUS receiving the BBP if you are the seller.  Thats pretty confusing (we can fix that cosmetically later once we certify the operation of the exchange with about 40+ tests etc and everyone feels comfortable that it is working right).

So I did a test as a buyer just now, and the way I verified it was I recorded my BBP balance before and after the trade and I can see my exec getassetbalance doge going down, my BBP going up, but yet I see a credit in the txlist for +1.2 colored doge-- that is because if you look at getrawtransaction, if you audit the tx, there is 1.2 wdoge in change but yet my wdoge decreased NET by .4.... 

So yeah I believe this is all actually working so far..

Ill see if I can come back online and do 6 tests wallet to wallet and log the results in a spreadsheet.

In the end we just want to see that the only cosmetic issue that needs fixed is the txlist would need to mask the "TRADING-ASSET-DOGE" transactions and just let the rpc show those.

You should be fine because it was a hard fork, 00000237a182585f0ce421958a4fce3bb73a86c7a8edc56c24ee9b3acd1c5255
is the hash for 565868 - are you synced with me now?
(We cant check chainz now until we notify them).

Actually I think it worked this time, because the trades that you made at that time- im looking at all the DOGE I lost and the BBP i gained.
I gained 84K bbp and lost 9.4 wrapped doge.  So you should have lost 84k bbp from your wallet.  I can tell its working now because every
tx in my wallet has 2 rows for each one (IE losing bbp, gaining wdoge). 

If you can check one all by itself and just watch it til it fills and then monitor your wdoge asset balance and your bbp balance you should see both change.

I just put a few more in

yes its synced

yeah so thats the confusing part for me then if i only sold 49k worth of bbp 7 trades @ 7000? how did you get 84k? i lost 126k and you shouldve only spent 3.794 wrapped doge


edit: It must be something to do with when you put in multiple orders for the same amount, like the first time it happened with the 2000 BBP transactions this time with 7000 BBP.  If i do trades one at a time and let them find a match it works fine, when you spam order all of the sells if there's more than 1 match for the order it can buy it multiple times? not sure.

I will put up a bunch of sell orders for 5000 BBP each try to buy all of them at once and see if it replicates the issue for you.

Regarding the base behavior, for orders that have different amounts per order, ignoring the txlist, I got a 100% success rate on all fills over two machines over 10 transactions.  I logged the before and after balance during each trade in this spreadsheet - see below.

Yes, it is possible something else is happening with tx's that have the same amount, or maybe it was just the txlist confusion.
What you can do is load BBP on two machines and transact across those and try to replicate it.
I can also take the other side of the trade on a few that have the same amount next.

In the mean time, Im going to push a version (for windows only) with one tiny change that makes it easier to record this audit log.
I added 'exec getassetbalance trading' which shows your Trading-public-key balance.  What Im doing to audit this is doing exec getassetbalance trading and recording it, and exec getassetbalance doge, and recording it and then finishing the trade.  Ill update separately with that windows version in a few minutes.

yes its synced

yeah so thats the confusing part for me then if i only sold 49k worth of bbp 7 trades @ 7000? how did you get 84k? i lost 126k and you shouldve only spent 3.794 wrapped doge


edit: It must be something to do with when you put in multiple orders for the same amount, like the first time it happened with the 2000 BBP transactions this time with 7000 BBP.  If i do trades one at a time and let them find a match it works fine, when you spam order all of the sells if there's more than 1 match for the order it can buy it multiple times? not sure.

I will put up a bunch of sell orders for 5000 BBP each try to buy all of them at once and see if it replicates the issue for you.

Ok good on synced.
Yeah, that comment about 84K was a very rough comment before I even started digging into the getrawtransaction, so lets let that one go as i might not have been counting something in my list as I have a lot of dust in there from doing some back and forth testing, but if we can keep a log of some sort as we transact to each other, lets start over and do that.

I will think about the possibility of a duplicate also, and get back to you more on that.
Give me a few mins to release this new version with exec getassetbalance trading.

Ok, hopefully this will help you guys hone in on auditing.

If you want, please upgrade to this v0.23.3:
https://github.com/biblepay/biblepay/releases/tag/v023.3-Mandatory

It has the :
exec getassetbalance trading
exec getassetbalance doge

Which you can do before and after a trade and then you can log it in the spreadsheet, and see how your wallet balances were updated.

Ok good on synced.
Yeah, that comment about 84K was a very rough comment before I even started digging into the getrawtransaction, so lets let that one go as i might not have been counting something in my list as I have a lot of dust in there from doing some back and forth testing, but if we can keep a log of some sort as we transact to each other, lets start over and do that.

I will think about the possibility of a duplicate also, and get back to you more on that.
Give me a few mins to release this new version with exec getassetbalance trading.

On the 5K transactions, I bought 5 of them at 5K each. My bbp balance increased by 24999 and my w-doge balance decreased by 1.06.
See if yours had the opposite effect, but without looking at the txlist, maybe checking the two commands instead?