I confirm the bug at block 286524 UnboundLocalError: local variable 'tx0_give_remaining' referenced before assignment Please panic sell on poloniex, so I can buy cheaply  What bug? We're already at block 286539 |
|
|
|
'counterpartyd market' command doesn't work in 5.1 develop branch?
I get an 'invalid choice: 'market' error message.
How do I view all current market orders now?
in the meantime you view the BTC/XCP DEX orders at http://blockscan.com/order_book.aspx |
|
|
|
Current reward for burning 1 btc? Will this coin remain scarce?
The burn period is over. Buy orders via centralised exchange (poloniex) is currently at 0.01BTC per XCP meaning 100 XCP for every 1BTC. XCP has a fixed supply of no more than 2,648,756 XCP. This would not increase day to day, month to month or year to year, because there is no concept of proof-of-work mining to introduce fresh coins to the supply on regular intervals (and therefore inflate- Bitcoin would need approx 2.3 million $ of fresh income per 24hours in order to maintain it's current price level, XCP does not need to compensate miners ). This number could only ever decrease. (for example, with loss of private keypairs) so to answer your question, yes this coin has scarcity-value if that is what interests you. The real excitement will come when we begin to see web wallets, dramatically lowering the barrier to entry. real use of decentralised aspects of exchange, for example an asset issuer taking advantage of this mechanism XCP is the rarest of the coins! Recall that initial asset issuances destroy 5 XCP, permanently. So not just lost keys... (I'm thinking this fee has to go down at some point in the future, because of the rapidly appreciating value.) Perhaps, but I think the fee should also remain for now... The issuance fee is the only deflationary variable at the moment and it also makes spamming a little bit more costly. What I would like to see are high quality assets vs just pure quantity (number of assets) Btw, JimHsu thank you for the informative posts on reddit! |
|
|
|
What's the point of sweeping it out of the individual deposit account though? I don't really get that.
Suppose five people each deposit one XCP, then one person buys all five XCP and attempts to withdraw them. All the XCP need to be in one account so people who withdraw without depositing can get them. About the withdrawal fee, it is definitely higher than all the others. The others are supposed to be just TX fees, but the XCP has to cover some hidden costs. Once we see what price XCP settles on initially, I'll adjust it accordingly. I have no intention of profiting off of withdrawal fees. Many successful deposits went through, and although only one person made a withdrawal, it was also successful (in addition to my many withdrawal tests). So we're launching! BTC/XCP market now live: https://www.poloniex.com/exchange/btc_xcpHave we decided on a logo yet? Are the deposits working? I did a test deposit and it does not look they are getting credit to the account although they already show on the blockchain |
|
|
|
We can use the reddit logo for now (since that at least has some public exposure) and decide on an official logo later.  A suggestion was made on this thread to possibly get a logo design competition running on 99designs.com. We definitely need something professionally done. https://forums.counterparty.co/index.php/topic,28.15.htmlLogo looks good, in my opinion. We should use this |
|
|
|
I think that I have fixed this issue (and the bad credit for 9.27 XCP doesn't show up anymore). Now, when an order match expires, if each underlying order is still valid, that order goes back on the books with replenished give_remaining and get_remaining, and only otherwise (if the order is expired) is its source credited immediately.
Attention: balances are now slightly different in develop. (A few people were getting extra XCP with order match cancellations.)
Great job Phantom! That could have been a disastrous bug. Should this be pushed to master immediately as a hotfix? I could imagine an attacker making a series of orders with very short expiration, matching them himself, and then generating an infinite amount of XCP which he would then dump at a low price to unsuspecting buyers. Good catch BiggestFish... ! |
|
|
|
I'm using the API.
I added db.setbusytimeout(10000) to util.py, when the database connection is allocated, and that seems to have fixed it. I'm going to let it run overnight, we'll see if it's still alive in the morning.
If you are constantly polling the database either directly or via api, I think you will run into these issues ? If I understand correctly you are doing this for checking the balances? |
|
|
|
All right, the deposit/withdrawal daemon is working. Everything would be ready to go, but...
Traceback (most recent call last):
File "/home/<user>/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 687, in <module>
blocks.follow(db)
File "/home/<user>/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 651, in follow
parse_block(db, block_index, block_time)
apsw.BusyError: BusyError: database is locked
Counterpartyd is now quitting with that error whenever I run the daemon. The daemon makes a zillion database accesses, it has to check everyone single user's balance. It's during that phase that this is now happening.
Had the same issue when I was building blockscan.com initially.... But its an easy fix actually. I assume you are directly reading from the counterparty db and not using the API ? |
|
|
|
Hi PhantomPhreak
Running the latest develop branch and I noticed that the asset list has been reduced. A lot of previously valid assets are now invalid.
Anything changes related to assets?
Can you give me an example? there were close to 180 ++ assets before the upgrading. Blockscan is one of the assets |
|
|
|
|
Hi PhantomPhreak
Running the latest develop branch and I noticed that the asset list has been reduced. A lot of previously valid assets are now invalid.
Anything changes related to assets?
|
|
|
|
I think --fee_required has been updated in the dev branch to mean "as a percentage of the total order", with a default of 1% (ie. 0.01.) The idea is that you shouldn't need to specify --fee_required, counterpartyd should automatically calculate something appropriate. But if you want to override it, specifying "0.0006" would mean your fee required is 0.006% of the value of your order (ie. very small.) Example: If you're ordering, say, 0.02 BTC, and you want the fee to be 0.0001, then you'd set --fee_required=0.005 (ie. half a percent. Because 0.5% of 0.02 BTC == 0.0001.) This might seem a little weird, but makes very good sense when considered in combination with a new protocol change - proportional matching. For example, there's currently a troll order on the DEX for some absurd amount of XCP, but paying 0.0005 fee. There might be 20 orders on the book that all require 0.0001, and he'll match all of them. With the protocol change, he'd only match the first 0.0005 worth (ie. the first 5 orders) and then his fee would be exhausted and the remainder of his order ineffective. If you had the top sell order on the book, with a 0.002 fee, then he'd only match one quarter of your order and have no effect on anyone else. See?  (Note that I'm not responsible for the implementation (I can't claim to have written a single line of counterpartyd code,) I'm just some guy who thinks it's a good idea and wants to help explain it.) ok. I saw the post replies on the counterparty forums and it does look like the figure is now a percentage.. I understand that its still alpha, but it still catches you off guard when it works one way and then the other the next day ;-) Cheers |
|
|
|
Hi PhantomPhreakI am not sure if this is an issue/bug/change with the required-fee option running the latest develop branch I have put a required fee of 0.0006 BTC ( http://blockscan.com/order.aspx?q=3693) in the command line. however, when the order was parsed the required fee became for 0.000042 and subsequently matched the "troll" order ?? same thing for the next test order http://blockscan.com/tx.aspx?q=3694. Used a 0.001 required fee, but when parsed it was 0.00007 BTC ? Something looks messed up again... sigh... Note to self: Need to quit running develop branch
|
|
|
|
|
Selling 300 XCP @ 0.0075 BTC/XCP
While stocks last. Please PM to transact
|
|
|
|
Yea  One of those are mine. Lol So people can still make the deal by giving the exact fee_required. Yea, last chance for them to buy at below 0.01. hahahah |
|
|
|
When can the GUI client roughly be expected (dont want a guarantee just a rough estimate)? Would that GUI client go along with an easy installation?
Two other questions I have:
How many developers are working on counterparty right now and are they full time?
I assume counterparty is working on the bitcoin blockchain which means that transactions/contracts are facilitated by bitcoin miners. Correct? Would it be possible to migrate to an own/different blockchainl with counterparty? Any plans here?
The community has multiple desktop clients in the works. Regarding a web-wallet, I have posted a written tech preview of "Counterwallet", which is the upcoming deterministic web wallet the Counterparty team is hard at work on. Check it out on the counterparty forums at: https://forums.counterparty.co/index.php?topic=79As I stated in that thread, screenshots should be coming by the end of the week. Things are moving along very well. As far as your other question goes, currently Phantom and I are working on Counterparty (pretty much) full-time. We have future plans for additional full-time devs. Hi xnova +1 If this works out even closely to what you have listed out then this is great. I like the fact that the wallet is deterministic. Cheers |
|
|
|
Yea One of those are mine. Lol |
|
|
|
... it looks more like a planned execution to block any exchanges from taking place .. The DEX was actually working quite well for the low volume trades. I think this really does go back to the point that there should be some "abuse" checks in place, without these then if left to market forces the DEX would be non functional.... I was thinking that as alternative to the DEX matching the highest price, why not put in an option to match trades based on a specific tx_hash for example a command like counterpartd.py order --offer_hash=6ecb7518eaabf0a655ea6f67af9145cb625f08e43cdb8884ba4959a9c404e99e could be executed. This could work for orders selling BTC for XCP The orders would then parse by blocks.py and match the specific --offer_hash. If for some reason the order has already been filled or does not meet the criteria then full AUTO cancel and refund takes places. Well it will only absorb all orders at that price, so if one puts a lower offer by .0000001 it shouldn't be a problem. The problem I see for the BTC sell orders is that they aren't committed to follow through with the exchange. The problem is you are now unable to SELL any XCP for BTC because its quite obvious based on the best matched price of 0.099 BTC/XCP, that the buy order is not going to follow through with a BTCPAY.. Vice versa, you can also easily start wiping out the SELL orders for a very low cost as the fee required is very low Cheers |
|
|
|
... it looks more like a planned execution to block any exchanges from taking place .. The DEX was actually working quite well for the low volume trades. I think this really does go back to the point that there should be some "abuse" checks in place, without these then if left to market forces the DEX would be non functional.... I was thinking that as alternative to the DEX matching the highest price, why not put in an option to match trades based on a specific tx_hash for example a command like counterpartd.py order --offer_hash=6ecb7518eaabf0a655ea6f67af9145cb625f08e43cdb8884ba4959a9c404e99e could be executed. This could work for orders selling BTC for XCP The orders would then parse by blocks.py and match the specific --offer_hash. If for some reason the order has already been filled or does not meet the criteria then full AUTO cancel and refund takes places. |
|
|
|
Just heard from poloniex guy. I think my pestering him has made him semi-eager to add it, if only to stop my constant emails to him I can lias with him, or maybe cityglut? Not sure what docs to send him to help him integrate XCP. He is worried that it will be a lot of extra work like adding NXT was. James P.S. coinmarketcap here we come!!! It should be very straightforward to add support for Counterparty in an existing exchange. Pretty much all you need is the 'send' functionality, and we have a solid API for that, and for everything else. Tell this guy to look at our API documentation (which is more stable than the warning at the head of the page suggests). You might PM CityGlut also. EDIT: Does he know about the bounty? Just chiming in here... If you take a mid-long term view, my personal opinion is hold off on adding the coin to any low liquidity exchange and only focus on the more established ones like cryptsy, vircurex, bter, etc Seeing that both Vircurex and BTER added nxt they might be open to the idea to add XCP. Of course if BTC-E is open to the idea then that would be the best choice Cheers |
|
|
|
What was the total damage -- about 1/3 BTC loss? (chips + assembly)
Yea.. somewhere around there.. However, the btc rate was locked in to an earlier rate so overall if just taking the USD value (glass half full view) we pretty much got back what we paid in USD |
|
|
|
|
Show Posts
