|
try some recent peers:
85.25.217.233
65.15.37.140
62.75.145.171
176.9.13.13
88.198.15.19
51.255.38.28
121.108.241.247
82.229.201.131
162.13.4.69
78.226.160.96
115.28.42.60
178.62.185.131
167.114.249.196
81.181.155.53
76.169.236.235
67.165.77.192
75.130.163.51
72.55.148.203
96.127.136.18
88.198.53.194
63.247.147.166
88.206.186.58
217.8.62.188
46.231.137.186
217.215.190.134
2.86.63.69
59.147.43.232
104.42.224.48
24.168.17.50
173.65.129.85
84.119.62.223
59.147.43.232
2.239.61.146
176.28.45.179
73.211.90.130
185.48.78.78
77.21.104.176
46.253.169.134
163.172.156.107
74.120.222.234
192.99.233.217
162.255.117.105
188.166.91.37
149.56.122.72
71.1.13.122
88.113.76.138
81.205.30.207
203.189.127.54
68.190.213.46
98.202.147.55
89.212.19.49
162.210.92.46
115.70.19.28
68.43.220.127
79.227.171.148
68.46.103.181
98.207.117.83
79.200.255.204
82.8.59.60
71.241.204.215
108.247.198.39
156.57.141.221
92.26.168.113
71.53.157.49
68.45.147.145
79.54.185.53
110.202.11.148
91.82.171.9
74.14.104.167
95.116.195.148
90.113.82.59
98.118.105.12
82.241.71.230
98.161.16.55
93.211.231.89
2.26.181.156
|
|
|
|
What is the difference between EasyDEX and InstantDEX? I only recently heard of EasyDEX, so I'm unsure which asset covers it?
Where does EasyDEX get revenue from, and how is it distributed (i.e. which assets).
As i understand it, EasyDEX is a shapeshift. I dont know if any assets cover that, potentially crypto777? James would know. ok, so EasyDEX is like ShapeShift, thanks! I'm hoping its revenues fall under the InstantDEX asset, as that's what I own. I thought crypto777 asset was Iguana ... supernet needs an appendix to define what everything is, and how the revenues will be distributed. Maybe one exists already ... easyDEX revs are for InstantDEX |
|
|
|
I had explained upthread that data is insufficient and ambiguous w.r.t. to the half-life of the attrition rate:If the 3000 signups per day claim is correct, then they are seeing at least 60% abandoned accounts rate, which also is approximately corroborated by the loss of actives of newbies from all history to recent 7 days. Only 28% of the weeks active are active on any given day. So the majority are not revisiting every day. Given the evidence of a high rate of attrition, it is possible that instead of gaining a set of sticky users which is 40% of the signups, instead what might be happening is after so many days, nearly 100% abandon the site and the new signups are replacing the lost people ( mathematically plausible if the rate of signups has been increasing which would also mean the attrition rate is much higher than 60% when comparing recent 7 days to all history). Meaning that it is possible the site has no stickiness. We need see charts on users by age of account and activity in order to answer this question. Also to more accurately see how the rates might be changing over time. The last 24 hours stats might be skewed by the downtime due to the hack. I just look at latest 24 hours data 4,821 accounts and weekly 13,734 accounts if those number keep going up then it is not at equilibrium yet of course it is noisy data and to get a really accurate idea, the blockchain would need to be analyzed. however many people make more than one account, and recent hack incidents surely slowed some things down |
|
|
|
|
Where can I find API docs, especially for liquidity providers
also is there a way to import liquid steem from bittrex directly to steem wallet?
|
|
|
|
Is the price fixed, When will be the end of Stage 1?  ?? when the inventory of each stage runs out, it advances to the next stage. BTC is still at stage one, and I assume so is ETH, the rest are stage 2 or 3 You are connected to this project? just as investor |
|
|
|
Is the price fixed, When will be the end of Stage 1? ?? when the inventory of each stage runs out, it advances to the next stage. BTC is still at stage one, and I assume so is ETH, the rest are stage 2 or 3 |
|
|
|
Really looking forward to the Tech and how it compares to Ardors proposal.
Using memory mapped files instead of DB will allow much, much higher transaction capacity. |
|
|
|
If all 25 Million tokens are reserved prior to ICO end date, an additional stack of up to 5 Million HEAT can be released at the HEAT Team's discretion at various outlets, for a price of approx. 0.00025 BTC each. Don't you think that the price is not a little too high 25,000 sats per coin? I think it is the other way around. .0001 BTC price of first tranche is probably too low, but it is too late to change. If all is sold out, that means the .0002 BTC is all sold out, so .00025 is not high at all. To put in perspective, the total raised for this ICO will probably be a bit less than 5000 BTC and once it is sold out, after market is the only place to get it. This is different from recent uncapped ICO where 100% of demand was filled during ICO creating an equilibrium based marketcap of total BTC raised. So the question is if a marketcap of 5000 BTC for HEAT is below the expected open market price. James P.S. considering the feature set of NEM and its marketcap, I have no worries about making ROI with HEAT |
|
|
|
SuperNET was one of the early ICO investors and I also have a personal ICO investment. To support HEAT community, I made a #heat channel in supernet's slack http://slackinvite.supernet.org/ will automatically get you access. When HEAT makes their own slack we can cross link. In the meantime all interested parties can brainstorm how to help HEAT James |
|
|
|
It is an interesting point, but the performance improvements he desires can be accomplished with encapsulation by employing polymorphic types (storing a header of type H that the Person type can't operate on because it only knows it is an H but the container collection can) but of course this binds the instances (e.g. of Person) to the type of H they were constructed with so they can't be added to other types of containers that require another type for H. But his C solution also makes this conflation.
The biggest issue of using C++ for system software is the undefined behavior for error handling, especially during interrupt time and all the system calls it makes on its own, which directly affects memory caching at the very least and who knows what else. Which may not matter for the Equihash, but I got your point that you don't bother with C++ generally because of that general issue. And there are other tradeoffs. Btw, I also am loathe to upgrade my C++ skills to master the STL. I last coded in C++ in approximately 2002. When I look at C code, I can feel what the algorithms are doing, so it is a night and day difference. Being fluent vs having to look words up in a dictionary. I get headaches looking at C++ code, probably as I cant fathom the nearly infinite system states the code represents. With C++ the possible system states are orders of magnitude greater and there is no control by the programmer. So if there is some strange bug, it can be buried deep inside of some automatic garbage collection process, causing a cache miss that triggers a swap to HDD, which then makes the interrupt handler fall out of realtime and things get out of sync. With C, at least I know I am the cause for any bug. |
|
|
|
It is an interesting point, but the performance improvements he desires can be accomplished with encapsulation by employing polymorphic types (storing a header of type H that the Person type can't operate on because it only knows it is an H but the container collection can) but of course this binds the instances (e.g. of Person) to the type of H they were constructed with so they can't be added to other types of containers that require another type for H. But his C solution also makes this conflation.
The biggest issue of using C++ for system software is the undefined behavior for error handling, especially during interrupt time and all the system calls it makes on its own, which directly affects memory caching at the very least and who knows what else. |
|
|
|
Software is already way ahead of hardware..
Trains are faster than horses, but I dont see the relevance |
|
|
|
It is an interesting point, but the performance improvements he desires can be accomplished with encapsulation by employing polymorphic types (storing a header of type H that the Person type can't operate on because it only knows it is an H but the container collection can) but of course this binds the instances (e.g. of Person) to the type of H they were constructed with so they can't be added to other types of containers that require another type for H. But his C solution also makes this conflation. The reason to prefer C over C++ is that C has a smaller surface area of base concepts whereas C++ has everything and the kitchen sink in its 1500 page manual. When it comes to performance, a skilled C programmer can beat an average C++ programmer who utilizes the STL. So jl777 wants to understand the algorithms well enough so that he can create a C implementation. This seems to be a worthwhile activity as it will make the Zcash PoW algorithm accessible to C programmers who hate C++ of which there are probably many. I would bet that if you can write down the algorithms in a simple pseudo code which he can easily translate to C, then I bet he'd probably pay you the bounty. code clarity is the most important, but it needs to use the optimized method and also be able to actually create valid solution sets basically a drop in replacement for the existing zcash miner |
|
|
|
but why?
http://250bpm.com/blog:4 and http://250bpm.com/blog:8 give some reasons. For doing GUI or anything not time critical, hey, you can use Java or Javascript or whatever language you want, but if performance is the primary goal (without CPU dependency), then C is clearly the answer. If CPU dependency is ok, then assembler Last I checked, mining fell into the "performance is everything" category please no C++ is gods gift to programming stuff and I know c++ can compile C code and has all sorts of wonderful classes for everything. I just never liked classes. If anybody seriously believes that an optimized C miner wont be faster than a C++ one, then let us make some wager James |
|
|
|
|
The current zcash miner is in C++, but I want a pure C version. There is already C versions of blake, but not of the main birthday problem as zcash uses
James
|
|
|
|
If I buy UNITY on Poloniex, do I get dividends also? Or must I buy UNITY on the NXT platform for the dividends?
poloniex eventually seems to distribute dividends, but holding the native asset is most direct |
|
|
|
|
Show Posts
