4381
中文 (Chinese) / Re: 暂停 BTSBOTS
« on: January 25, 2015, 06:30:21 am »短短不到 两个月 竟然有23%的利润,ALT 你不该放弃这个事情啊怎么说呢,23%都是投资人赚了。
Alt本来提出过收1%的手续费,结果很多人跑出来质疑。
那个搬砖机器人基金之前收50%利润的管理费也没见谁出来说什么。
(我只是描述情况,并没有责备的意思,其实我很赞同一开始就订好规则的)
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.
短短不到 两个月 竟然有23%的利润,ALT 你不该放弃这个事情啊怎么说呢,23%都是投资人赚了。
Sure the website is under construction.it can't be...when i click the publish button,it jumped to the head of same page,and there are no address or phone number in the "about us" section.I was just about to suggest crowdfunding.@jonasjia It is nice to see your offer! But you need to understand that any investor would want to see PROOF that you are legit and that your product and patent and your whole business actually exists.i really didn't like the pattern of kickstarter ,there are many unreasonable demands such as i must be a american and have company in america and so on,what a international project should be like? yes, thats why i choose BTS,because it's really haven't national boundaries.
But since you will be accepting BITUSD and BitCNY, why don't you reach out to DACX they are the perfect platform for you.
If I'm not mistaken, they are planning on doing both equity and reward projects.
... a BitShares hardware wallet. Purchasers of this hardware wallet (like any purchaser of a Dawn product) will receive an ownership stake in Dawn and a kick-ass hardware wallet.The quantity is limited, right? How many?
...
I'm running a delegate node and the 0.5.3 upgrade seems to have networking issues.Try to remove the peers.leveldb folder and restart?
Looks like it's connecting to itself as a peer and there are race conditions in the code that gets confused about the state of the sync blocks and disconnects (from itself).Code: [Select]Peer <my-own-public-ip>:47595 disconnected us: You offered me a list of more sync blocks than could possibly exist
Peer <my-own-public-ip>:36004 disconnected us: You offered me a list of more sync blocks than could possibly exist
--- there are now 30 active connections to the p2p network
--- there are now 26 active connections to the p2p network
--- there are now 23 active connections to the p2p network
--- there are now 4 active connections to the p2p network
--- there are now 3 active connections to the p2p network
--- there are now 4 active connections to the p2p network
--- in sync with p2p network
--- there are now 19 active connections to the p2p network
--- there are now 18 active connections to the p2p network
--- there are now 4 active connections to the p2p network
--- there are now 3 active connections to the p2p network
--- there are now 2 active connections to the p2p network
--- there are now 1 active connections to the p2p network
--- there are now 0 active connections to the p2p network
--- there are now 2 active connections to the p2p network
--- there are now 4 active connections to the p2p network
--- there are now 17 active connections to the p2p network
Also, on initial start up of 0.5.3 I'm seeing the connection count climb to over 130.
(And I'm about to be bumped off of the top 101...)
There's definitely something fishy going on with the price_history command that's used to generate that candlechart. I have an issue open on Github for it, Vikram has added it to the 0.7 milestone: https://github.com/BitShares/bitshares/issues/1300I added a comment to this issue.
Yes it is apache. I use a command lsof to match up open file handles to processes. There is another problem where the wallet had the ports locked up by the OS after quitting but it isn't the problem. My problem has only happened once, I just realized how annoying it is because even when I stopped apached the port was not immediately available. So if the wallet dies and tries to bind to that port and there is this weird race condition where the easybitcoin php lib keeps it from binding... then wallet can never start. THere is also a chance that the options for the socket creation in the wallet constrain it too much. It has to be fixed in php but if there were other suggestions to put in the readme file.. that could be considered a solution, but this is a php project that interacts with RPC and SMF.Looks like the cause of your problem is out of my knowledge.. Wish you good luck anyway.
I have a list of php options that might would fix it in a different manner, but it really isn't a show stopper. Just a bit puzzling. Anyway, it will likely just be made an issue on github and i'll consider it done.
sysctl net.ipv4.tcp_tw_reuse = 1
sysctl net.ipv4.tcp_tw_recycle = 1
sysctl net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 1
It means every connection will stay in 'TIME_WAIT' state for only one second. Again, be careful.I do have one problem where apache is binding to localhost at the same port and preventing the wallet from connecting. So it took me shutting down apache and waiting and then starting them up in order. I have no clue why using a curl-php5 would do this. I guess I don't understand tcpip ? Regardless it isn't really acceptable because if the wallet dies, a wallet restart won't work because it fails to bind to that port. I've read all the curl lib options etc and nothing makes sense except that I don't understand tcpip as well as I thought. I doubt it'd be a problem if everything wasn't using localhost.I'm not sure if it's a curl-php5 problem.. Maybe set different ports for apache and the wallet will work.