Refunds are processed in USD via bank transfer, only in some circumstances where it may not be possible to refund via bank transfer, our management can approve a BTC refund. BTC refunds are not given for single Neptune purchases. KnC sucks at this point. I don't understand the logic behind not giving BTC refunds for single Neptune orders. Knowing that they have 5PH mining at this moment this seems a bit stupid. Also only one time per week? Wtf? I can have my refund in 5 mins with BTC, but i have to wait a few days for them to wire the money and then another few days to get it. Sad times. KnC you let me down! I hear you.. I asked for a BTC refund also but was given USD as it was a single order... With no upcoming news I am contemplating refunding my remaining order also. At this rate with no sign of "Plan B" it almost looks like KNC is encouraging refunds (IMHO), for what reasons I do not know  |
|
|
|
Anyone received a btc refund?
I got a refund in BTC for 3 Neptunes, I asked for USD but that was denied. Could you please tell me how many days from "Refunded" to dollars in your bank account ?  About 7 days. The refund was dealt quickly and promptly, no issue there. And it appears that they are refunding BTC for multiple orders and USD for single orders Cheers |
|
|
|
|
To the developers of the counterparty wallet, Thank you!
Cheers
|
|
|
|
Thank you for bringing this to my attention. I have fixed the issue Cheers |
|
|
|
The "Last DEX Btcpay Price" currently shows the value of an order that expired. Wouldn't it make more sense to only show completed orders here?
Its an expired order but with partial successful btcpay matches. Based on what I am seeing the calculation should be correct. I am picking up the last valid BTCPay transaction where BTC/XCP is traded. If it is otherwise, do let me know cheers Ah, got you – that makes sense. I did not realize that the order got partially filled. No problem.. These are my own calculations and there are multiple ways to interpret (calculate) this. Until an official api/calculation (which I am hoping will be available in counterwallet) is available I am sticking to this method of calculation |
|
|
|
The "Last DEX Btcpay Price" currently shows the value of an order that expired. Wouldn't it make more sense to only show completed orders here?
Its an expired order but with partial successful btcpay matches. Based on what I am seeing the calculation should be correct. I am picking up the last valid BTCPay transaction where BTC/XCP is traded. If it is otherwise, do let me know cheers |
|
|
|
Announcement: On that note, in the first blog post, we announce that the Counterparty team has hired two Bitcoin security experts to audit Counterparty's code! For further information, continue reading here: https://counterparty.co/sergio-lerner-peter-todd. +1 Thumbs up. |
|
|
|
Sorry if this is a dumb question, but how come blockscan now says: Total XCP Supply: 2,648,735.92 Why the 20 XCP difference? The difference is from the Asset Issuance fees. From what I understand it was supposed to be 5 XCP per asset issuance but there was a bug in the calculation (which I already reported very much earlier) which only deducted the divisible amount instead of a full 5 XCP. |
|
|
|
Hi PhantomPhreak
Running into the following issue with the latest DEVELOP commit
Status: Blockchain reorganisation at block 287502.
Status: Reparsing all transactions.
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 723, in <module>
blocks.follow(db)
File "C:\counterpartyd_build\dist\counterpartyd\lib\blocks.py", line 788, in follow
block_index = reorg(db)
File "C:\counterpartyd_build\dist\counterpartyd\lib\blocks.py", line 682, in reorg
reparse(db, block_index=block_index-1, quiet=True)
File "C:\counterpartyd_build\dist\counterpartyd\lib\blocks.py", line 618, in reparse
cursor.execute('''DELETE FROM blocks WHERE block_index > ?''', (block_index,))
File "c:\apsw\src\cursor.c", line 231, in resetcursor
apsw.ConstraintError: ConstraintError: FOREIGN KEY constraint failed
I responded to your PM. If anyone else has this issue, even after doing a manual reparse, let me know. Thanks.. but I think there is something not right with the reparse on the latest commit. After doing the reparse it corrupts an existing version 9 DB. At first I thought it might have been a disk issue but I've tried this on multiple servers and have run into the same issue |
|
|
|
|
Hi PhantomPhreak
Running into the following issue with the latest DEVELOP commit
Status: Blockchain reorganisation at block 287502.
Status: Reparsing all transactions.
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 723, in <module>
blocks.follow(db)
File "C:\counterpartyd_build\dist\counterpartyd\lib\blocks.py", line 788, in follow
block_index = reorg(db)
File "C:\counterpartyd_build\dist\counterpartyd\lib\blocks.py", line 682, in reorg
reparse(db, block_index=block_index-1, quiet=True)
File "C:\counterpartyd_build\dist\counterpartyd\lib\blocks.py", line 618, in reparse
cursor.execute('''DELETE FROM blocks WHERE block_index > ?''', (block_index,))
File "c:\apsw\src\cursor.c", line 231, in resetcursor
apsw.ConstraintError: ConstraintError: FOREIGN KEY constraint failed
|
|
|
|
Developers: The API has changed a decent amount in the newest updates to the develop branch. This includes several enhancements, function name changes, changes in semantics, etc. Please check out the updated API documentation at: http://counterpartyd.readthedocs.org/en/develop/API.html So it looks like a database rebuild is required for the develop commit? |
|
|
|
Actually, I think C:\Python32\python.exe setup.py update gets the master branch, and to rebuild the 8.0 database you have to pull the develop branch.
But I have no clue on how to do it. I'm just waiting the devs to update the master branch, and I guess they have more important things to address right now.
This explains why after I update, I am still on v6.0 Yes, the version 8 db is from the develop branch. Blockscan is running the develop branch so that we are always up todate and to also assist in finding bugs (if any) |
|
|
|
How long does this take ? C:\Users\chris>counterpartyd server
C:\Users\chris>echo off
Status: RESTART
Block: 278280
Block: 278281
Block: 278282
Block: 278283
Block: 278284
Block: 278285
Block: 278286
Block: 278287
Block: 278288
Block: 278289
Block: 278290
Block: 278291
Block: 278292
Block: 278293
Block: 278294
Block: 278295
Block: 278296
Block: 278297
Block: 278298
Block: 278299 Quite a while.. around 10-12 hours for me |
|
|
|
Upgraded one Nov Jupiter to 1.00. Went from 680 to 685 GH/s. Can't complain here. Will do the other tomorrow.
Is a HARD reboot (Power Off/On) required after the firmware upgrade ? |
|
|
|
> rolled XCP balances back Is that unclear about when it's rolled back to or perhaps which block?.. Can we trust http://www.blockscan.com to confirm current balances?? Looks like we are .7 counterparty DB .... this will take awhile to rebuild all the blocks. I will revert to the latest DB once the rebuild has been completed |
|
|
|
it also disappeared from the balances. and its not possible to withdraw BTC. Yes, I've suspended XCP for now, because there appears to be a serious problem with it. I think its best that you perhaps try to figure out what actually went wrong than to imply there is a serious problem with XCP. It could very well be an issue with your existing integration with the XCP wallet. |
|
|
|
Adding support for matching orders by order hash directly be a huge help in combating the troll.
The troll can still place orders and force sell orders to have higher fees, but buyers can place orders with low fees and sellers can directly match them.
If we don't care about preserving best/bid offer, we could have order matching ONLY by order hash. That way sellers can place their orders, buyers can place their orders, and anyone who wants to make a trade can match directly. Troll orders would be completely ignored. Fees would be kept to the minimum of 0.0001.
I am all for this and also had proposed the same earlier..... By allowing matching orders directly by order hash the DEX would facilitate a trustless escrow system. There are no other working systems offering this at the moment (that I know off) and implementing this in DEX would make it a first. As the direct matching would be a separate command it should be able to work side by side with the existing order matching system. Combined with a client side reputation based system sellers would be able to sell non BTC assets like XCP to whoever they choose to |
|
|
|
Can anyone tell me how the order book is matched in this dump scenario.
1. A sell order was placed for 0.002 for at least 16,000 XCP
2. There were many buy orders greater than 0.002 at least up to 0.011
Do these buy orders get matched to the dump price? If yes, do they get matched @ 0.002 or at their original bid?
Original bid all the way down to 0.002 |
|
|
|
This unfortunately looks like Poloniex got hacked. http://blockscan.com/address.aspx?q=19rVQ91AgrYmbpX6Sjxw6qCoP2Q1YFcn5bThis address received 35k from Poloniex and immediately redeposited it. Poloniex at the time had a balance of roughly 50k, so unless a big whale had been buying all along this is very fishy. There's no reason for an immediate redeposit unless someone had managed to get Poloniex to pay out to them. Also strange is how there is no intermediate deposit address used--the transfers are going directly into the central wallet. Here is another transfer of 35k: http://blockscan.com/address.aspx?q=1HMoHdzaHm9cHR8FjekGRtkkydoHfgaC8SPerhaps the hacker/exploiter is going for another round? I really hope I'm wrong. It does look as though either the central wallet or Poloniex's internal processes have been compromised. Unfortunately ... it does look highly likely you're right... Has anyone informed poloniex? |
|
|
|
I feel sorry for the guy. Open buy and sell orders right below the sell and buy boxes can confuse the novice. I can't remember, does poloniex have a confirmation dialog box?
No confirmation box. Could have been an extra "0" added to 0.02 vs 0.002. Anyway, lucky for those who managed to sweep up the cheap coins at 0.002 Cheers |
|
|
|
|
Show Posts
