Show Posts
|
Pages: [1]
|
Syrenity: what exact error message are you getting? I'm not a Windows person, but I'll be glad to help if I can.
|
|
|
Man, who is building blockscan.com ? Massive props to you, it's really looking good. There's even a way now for asset issuers to "claim" their asset (and presumably do things like add descriptions, etc.).
If you're interested in counterparty and have not yet checked out this site, I'd highly suggest taking a look. I suspect it will only get better from here. Amazing that counterparty already has an informational site that is beginning to rival blockchain.info in features after only a month.
Anyway, props to the dev of blockscan.com. I'd suggest to anyone who can to leave a tip on the address at the bottom of the page there.
|
|
|
Additional requirement: All submissions must be open sourced and freely licensed by the end of the burn period (but the earlier the better).
Great, this information will allow me to move forward with more confidence and devote more time to this project in the coming week.
|
|
|
If anybody has the patience to help a newbie I'd appreciate it.
You're almost there. You're exactly right -- you need to keep the one cmd window open and running the counterpartyd server (there are easier ways to do this as a service but if you only want to do it once this is fine). While you're doing this, open another cmd window, and run the exact same command, only replacing "server" with whatever command you want to run ("wallet" would be a good one first time). But you have to wait until the server has caught up with the current bitcoin block. You can check the current number on blockchain.info or on blockscan.com
|
|
|
Actually, rpc-host is set to what local interface IP counterpartyd will bind to (with 0.0.0.0 meaning "all interfaces"). So, it must be a local interface on the box (e.g. rpc-host=68.122.255.122 will bind to the local interface that has IP 68.122.255.122... that interface must exist on the system).
Yes -- stupid mistake on my part. I wasn't thinking that one through. rpc-host just specifies which IP address cherrypy binds to. The only way you can accept external IP connections is to bind to 0.0.0.0, and there's no way to limit that by IP. Actually, I'm not sure how bitcoind even implements rpcallowip -- I'll have to check it out. But agreed that firewalls are the way to go. It's also pretty simple to configure nginx as reverse proxy to limit external connections to certain hosts, using the "location" block and `allow x.x.x.x` then `denyall`. Check me on that if you do it, can't quite remember if there's anything else to do.
|
|
|
Is there an equivalent rpcallowip?
If I'm not mistaken, rpc-host is essentially the same as rpcallowip. This will allow any IP to connect: If you specify the IP number, connections should be limited to that IP only: However, IP addresses can be spoofed, so make sure you're using a very strong password if you've opened the connection to the Internet (20+ chars). I would be very, very careful about exposing the API on the open Internet if you're storing any significant amount of XCP/BTC on that wallet. It would be better to put it behind a proxy server, like nginx. You probably know all this, but I mention this for the sake of others reading.
|
|
|
The bounty is up to just over 3.2 BTC.
I'm looking forward to seeing the GUI client!
I've got a good start on a client using Qt (so cross-platform: Windows, OSX, Linux, and even Android with some extra work). I think I should be able to release a very basic alpha version by the end of the burn period, and definitely have a working beta for the desktop incorporating user feedback by end of the bounty period. The Android port -- if I pursue that option -- will be on down the road. I am a little wary about releasing it before the bounty period is over for fear someone else might fork my code base and make a few cosmetic changes that people prefer, and then receive the bounty. Does anyone have any suggestions on how I might go ahead and open source the code and yet still protect my potential claim on the bounty? And again, I'm aiming for the end of the burn period for an initial release -- no promises. It depends on how much time I'm able to give to this project over the coming week. My plan is to release under the MIT license, since I believe that's what counterpartyd is under.
|
|
|
I’m on xubuntu 13.10 and get the same "import zmq" error after updating.
If you're on ubuntu, just run: sudo apt-get install python3-zmq As long as you're using the system Python3 (running commands with `python3 cmd`) then you should be ok.
|
|
|
PhantomPhreak and xnova are there any plans for a user friendly client shortly after the burn period is finished? If not should we as a community start discussing and possibly set up a bounty for this? I would be happy to donate some BTC or XCP for a client.
Thanks for all the great work you guys have been doing on this. I’ve donated to the dev fund and intend to donate more.
As a third-party dev, I've started work on a user-friendly client that should be done in about 4-5 weeks working part-time. However, if there were a significant bounty, I could probably justify working on it full-time (I'm a freelancer) and have it done in probably a week or less (at least a beta version). I'd also love to get input from users on what you want. At the moment, it's designed as a client with two tabs, one for your wallet (with the usual wallet features) and one for the market. You will be able to filter the market transactions by type. Probably a third tab for broadcasts. Any other ideas? Edit: Also, depending on user feedback, I could fairly easily change the tabs to a more traditional toolbar-driven interface, if that's what more people want.
|
|
|
Ironically, considering the atmosphere of the alt-scene at the time this was launched (ie. new IPO scams every day), XCP would probably have received a tiny fraction of the investment that it ended up getting.
Yeah, this is the thing. Proof of burn was one of the only avenues open to demonstrate good faith. It's also turned out to be a nice way to distribute initial stake, even if it is a lousy way to reward creators and devs for their efforts. I just hope this community can pull together and fund at least enough money for PhantomPhreak or xnova to work on this full-time, considering that the other competitors will have plenty of funds to pay salaries.
|
|
|
I assume the devs will push a hotfix soon, although it does worry me a little bit that activity on the counterpartyd repo (including the dev branch) seems to have tailed off -- and right when I was starting work on a GUI!. Hope the large influx of capital hasn't diluted their shares to the point where they're losing interest. This is a extremely promising project.
I haven't had good Internet access is all! And if there're are any particular changes to counterpartyd that you'd like to see happen in the near future, let us know. Excellent, glad you're here. I really like the zmq API in the dev branch. ZeroMQ is a brilliant piece of engineering that makes true parallelism in Python a snap. Is that going to be integrated into production? If so, I'll use its pubsub for the GUI I'm building to get updates instead of polling the JSON-RPC API. Also, are you drawing the line at 1 confirmation? i.e, do you not want to show any 0 confirmation transactions? If not, an easy and effective way in Python to signal whenever a new tx hits the network is to use one of the many implementation of ArtForz's old Python half-node, which is effectively a Bitcoin node (as you probably know). In fact, Jeff Garzik has made this into a full Bitcoin node in PyNode. Anyway, the asyncore imple is probably best for this project since it wouldn't introduce any external dependencies and can be used with any Python3 (asyncio/tulip is very cool but only 3.3+). But this way, you can get notification of new 0 confirmation transactions without polling bitcoind listsinceblock, which is inefficient and cumbersome since you have to keep up with the tx's you've already processed. This way, there's no 10 minute delay before a new tx shows up (of course, you'd need to indicate it's a 0 confirmation tx). But I can understand if you've decided to only officially display 1 confirmation transactions.
|
|
|
Are people still able to run the client now? Someone has issued a buy order for a non-existent asset (asset name "CREDIT") and it's crashing my client. I've hacked out a fix, but I see at least one other person is still making orders. Does the client still run on some other OS, like Windows? I see that at least blockscan.com is stuck at the same place I was, prior to the buy order for a non-existing asset.
By the way (and if I'm understanding the problem correctly), if you created the buy order for "CREDIT" without first creating the asset, would you please cancel your order? Thanks -- It's blocking trade for the rest of us.
I assume the devs will push a hotfix soon, although it does worry me a little bit that activity on the counterpartyd repo (including the dev branch) seems to have tailed off -- and right when I was starting work on a GUI!. Hope the large influx of capital hasn't diluted their shares to the point where they're losing interest. This is a extremely promising project.
PS: All of you who are gleefully creating non-backed assets such as Dogecoin should just save yourself the time and read through the old Ripple forum threads -- it's all been done before and people will soon get bored and only people trading real, trusted assets will remain. By the way, everyone who was calling for Ripple on the Bitcoin blockchain should jump on this opportunity, because this project is all the innovative features of Ripple on the BTC blockchain, plus significant additional features, all with a fair distribution. What more could you ask for?
|
|
|
|