Show Posts

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.


Messages - dannotestein

Pages: 1 ... 28 29 30 31 32 33 34 [35] 36 37 38 39 40 41 42 ... 51
511
General Discussion / Re: BitShares v0.4.25-RC1 Feedback
« on: December 09, 2014, 04:21:50 pm »
Window version wallet occupies a lot of memory and CPU percentage, making the computer extremely slow.

Here's what I'm seeing here while testing the Windows GUI version:

Re-indexing takes about about 10 minutes and consumes 1.38GB. If a system has less than that free memory available (after accounting for the OS and other programs), it's going to slow down dramatically as it begins paging, and this could become a very very long operation at that point.

I have sufficient memory on my system to avoid paging, so after re-indexing my cpu usage dropped to a normal 1-3% for the client. But memory stayed at 1.38GB for the duration of that session (my guess is another memory leak in the blockchain code). After restarting the client, my memory usage dropped down to the expected range (~571MB).

513
General Discussion / Re: who is in control of these delegates?
« on: November 26, 2014, 02:19:07 pm »
yes, btsnow is my delegate, I run it mainly to be able to continuously capture logs of a block-producing delegate. delegate.btsnow is the new delegate I created to replace btsnow that uses the new naming convention.

514
General Discussion / Re: Draft Pitch for new BitShares.org
« on: November 07, 2014, 03:10:19 pm »

I think it needs to be a lot more clear what bitshares actually is. If bitshares was just an iteration or improvement of some existing tech that the average consumer knows about, then it would be feasible to sell it mainly on emotions through pictures. But the closest we can get to that is to write that bitshares "is like bitcoin" or "bitcoin 2.0". That will probably still not be enough to prevent the average user from bouncing from confusion.

It sucks, but I think we will have to explain some fundamentals of the the system right on the first page, and will thus need to use a lot more text. Unless people are buying into a third party centralized service that holds bitUSD for them, they need to understand that bitshares are distributed and decentralized with no issuer or owner, so there's no risk of an owner running away with their money, but also no official support, insurance or guarantees.

I had an idea that one of the ways we can communicate the public key crypto that powers our system, is to market to our users as "owners". So you're not a bitUSD user, you're a bitUSD owner. An owner can never have his funds seized, frozen, snooped on or restricted in any way. You're only an owner if you control the private key. We can do an emotional sell by playing on this as something that should be a fundamental human right: if you've earned something through honest work NO ONE should be allowed to take it from you.

I think a good source of inspiration for the visual style would be the style of graphics used in the weusecoins video. I especially like the pacifying colors and that each feature has its own unique icon (and even sound), it quite amazingly done.

Here are some random ideas for how I think it could be done in the current style. These are just quick suggestions and written in haste, but maybe some of the ideas are useful.

BITSHARES - a bank without bankers

DECENTRALIZED (picture: stylized drawing of a meshnet) - Bitshares is powered by all its owners, who work together to run the software that maintains the system across thousands of computers. This ensures that there are no intermediaries between owners and that no one have the ability to change or steal from the system.

OPEN SOURCE (picture of whatever people positively associate with open source) - The open source software uses the most reliable proven cryptography to ensure that an owners funds are always safe and spendable only by him. Every line of code is public and can be audited by anyone at any time.

STORE OF WEALTH (gold bars) - You can deposit money into bitshares in many forms: bitUSD, bitEUR, bitGOLD... Each of these tokens always hold the value of their underlying asset, and pay an interest rate (currently x%). Everything is collateralized at 300% of its value by the highly liquid backbone currency bitshares.

LOW FEES, NO RESTRICTIONS (stylized broken or frozen bank)- Using bitshares you can send money in any form, directly to any other user anywhere on the planet within 10 seconds for 2 cents. You can also exchange currencies and assets instantly and at low fees. There are no restrictions, requirements or authorization needed for the owner to send and spend his money as he wishes. Transactions are private and no one will know how you spend your money.

BE YOUR OWN BANK (picture of sympathetic person) - these features allows anyone to store their money with total privacy in the way they decide, out of reach of getting stolen, frozen or seized. Finally you can own what you own.
+5%

DECENTRALIZED could be COOPERATIVE


Sent from my iPhone using Tapatalk
+5%
 And I think change from decentralized to cooperative is a good idea. It makes me think of "credit unions" with their lower fees versus banks and I think it's a better description of what's going on.

515
Technical Support / Re: No network connections on 23.1 on 32 bit win
« on: November 03, 2014, 09:50:56 pm »
It sounds like your blockchain database was corrupted by the glitch, so you're not able to properly synch with other clients. Delete your blockchain directory and re-sync.

516
General Discussion / Re: v. 0.4.23 windows 32bit issue
« on: October 29, 2014, 06:24:52 pm »
We're currently making new windows builds for 4.23 release, the last ones didn't build properly.

517
Code: [Select]
ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 4523
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 4523
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
That looks reasonable to me at first glance.

518
It just crashed using the github version. This is the output from gdb:

Code: [Select]
(wallet closed) >>> [Thread 0x7fffd0ff9700 (LWP 6502) exited]
[Thread 0x7fffd17fa700 (LWP 6501) exited]
[Thread 0x7fffd1ffb700 (LWP 6500) exited]
[Thread 0x7fffd27fc700 (LWP 6499) exited]
[Thread 0x7fffd2ffd700 (LWP 6498) exited]
[Thread 0x7fffd37fe700 (LWP 6497) exited]
[Thread 0x7fffd3fff700 (LWP 6496) exited]
[Thread 0x7fffe48f0700 (LWP 6495) exited]
[Thread 0x7fffe50f1700 (LWP 6494) exited]
[Thread 0x7fffe60ea700 (LWP 6493) exited]
[Thread 0x7fffe6ffd700 (LWP 6492) exited]
[Thread 0x7fffe77fe700 (LWP 6491) exited]
[Thread 0x7fffe7fff700 (LWP 6490) exited]
[Thread 0x7ffff4bc8700 (LWP 6489) exited]
[Thread 0x7ffff53c9700 (LWP 6488) exited]
[Thread 0x7ffff5bca700 (LWP 6487) exited]
[Thread 0x7ffff63cb700 (LWP 6486) exited]
Program terminated with signal SIGKILL, Killed.
The program no longer exists.

I didn't do that.

How do I get something useful to report for debugging?
Apparently the program was killed somehow, so you won't be able to get a backtrace.

I looked at your p2p log, looks like normal messages there (message about disconnections are quite common and destroying peer connection objects for those connection is normal behavior). The underlying fc library used by bitsharesx client throws exceptions to indicate a socket has been closed by the peer you're communicating with.

The interesting question is how the program was killed, maybe you're hitting a ulimit on your system that is terminating the client. Can you type "ulimit -a" and post the output of that command?

519
I ran it in the debugger, maybe it's still running, as there's my 'gdb...' command still in htop.

After 10 minutes or so I got the (gdb) prompt in my console:

Code: [Select]
Reading symbols from /home/ubuntu/BitSharesX/bitshares_toolkit/programs/client/bitshares_client...done.
(gdb)

Have you typed "run" in gdb to start the process yet?

520
Technical Support / Re: Syncing is slooow
« on: October 07, 2014, 03:15:00 pm »
Im running 0.4.20 since about 30 minutes ago, and its taken that long to sync 5 days worth of blocks - its still not finished :(
The next release will include a significant speedup in sync time: in our tests took 1/3 the time of 4.20.

521
Technical Support / Re: Should i downgrade?
« on: October 06, 2014, 01:40:46 pm »
Ever since I updated to the new version of BTSX 0.4.19 and then to 0.4.20, I get: Not Connected

Should I downgrade to 0.4.18? How would I do this? Or should I wait for 0.4.21 and hope that it fixes the problem?
Downgrading isn't a good idea, there's been hard forks that will likely cause problems for older clients to sync up.

522
General Discussion / Re: "Not Connected"
« on: October 06, 2014, 01:38:01 pm »
What does "get_info" report? Note this is different from "blockchain_get_info".

523
General Discussion / Re: What the Fork??
« on: September 22, 2014, 02:43:28 pm »
Thank you for the research, svk. That is an interesting point as a few times I have found that on another wallet (where I'm playing with bots) I sometimes see that my client is five to 10 minutes behind.

So I guess the next question is....why is my client experiencing these stoppages in block syncing? I wonder if there's enough information in the logs to correlate connection count and the missing blocks.

Experiencing similar things since some delegates upgraded to 0.4.16 (cr1/2) with my non delegate client. My client was still on 0.4.15; Now with me on 0.4.16 I have seen this behavior 3 or 4 times. Restarting seems to fix the problem for me but then again it is easy when one is not delegate... Will post more info the next time this happens...will be good if somebody points me to what info will be helpful.
My initial post/info: https://bitsharestalk.org/index.php?topic=9099.msg118456#msg118456

I can confirm that since upgrading to 0.4.16 my delegate has missed blocks.
My non-delegate client (also running 0.4.16) stopped syncing.
Code: [Select]
   "blockchain_head_block_age": "5 hours old",
   "client_version": "v0.4.16",
   "network_num_connections": 5,

Restarted the non-delegate client and it made some progress but stopped syncing again

Code: [Select]
  "blockchain_head_block_num": 552498,
  "blockchain_head_block_age": "22 minutes old",
  "blockchain_head_block_timestamp": "2014-09-22T13:34:40",
  "client_version": "v0.4.16",
  "network_num_connections": 14,
  "network_num_connections_max": 200,
  "ntp_time": "2014-09-22T13:57:02",
  "ntp_time_error": -0.024471,
Can you try deleting the node_config.json in your data directory for that client and see if the problem goes away? I want to check if it's this issue: https://github.com/BitShares/bitshares_toolkit/issues/794

524
Technical Support / Re: Does the X of BitSharesX stand for eXperimental?
« on: September 20, 2014, 08:26:38 pm »
I've always thought that it was bitsharesx because it was intended to be forked and built upon.  But maybe I am wrong.

If that is incorrect, eXchange would be the only other one I can think of...
X is for exchange: several names were debated to get across the concept of an exchange, but there was a lot of disagreement on what name to use for it.

525
General Discussion / Re: 0.4.16-RC1 Issues
« on: September 19, 2014, 09:05:23 pm »
Getting connections seems to be a lot slower.
I've started a delegate and it had 2 connections for the last 10 minutes.
I manually added all the seed nodes I could find but I still have only 2 connections.
I tried to restart - no luck.
Older version on the same machine finds connections much faster (15 connections 20 seconds after start).
Can you run the old version now and still get the 15 connections after 20 seconds? I'd like to establish if the difference is in the client or in the current state of the network (e.g. less public nodes to connect to versus nodes behind firewalls).

Pages: 1 ... 28 29 30 31 32 33 34 [35] 36 37 38 39 40 41 42 ... 51