There is a question found in WIN,you will come back login page after reloaded.[/size][/glow]

Win 0.0.7 is not working here,  win 7 / 64
Stuck after ~ 100 Blocks loading on every restart, says: 12 connections.
Wiping "chain" dir = same result

Sent "Yesterday" some (linux  :) XTS to:
2124.2    2014-06-30T19:10:31 calyau              dxtr                 7f915edf
2124.1    2014-06-30T19:10:50 calyau              rzshenwei        6e1008a4
2124.3    2014-06-30T19:11:08 calyau              dexinwong       dd627248
2124.0    2014-06-30T19:11:25 calyau              cassssss          2f82d47b

>>> wallet_list_unspent_balances
           BALANCE                                   OWNER                     VOTE
--------------------------------------------------------------------------------------------------------------------------
       9.60000 XTS    XTS56UucX4Newen27wNhWrFQQCspp9a4fVsc10 assert_exception: Assert Exception
!"unimplemented condition type":
    {}
    th_a  cli.cpp:1081 print_unspent_balances



default (unlocked) >>> about
{
  "bitshares_toolkit_revision": "2851364a09924c06b3b8dc76471d41c0755401c9",
  "bitshares_toolkit_revision_age": "6 hours ago",
  "fc_revision": "13da4b0d6a715d744fec3a04989e1a0788c37b37",
  "fc_revision_age": "15 hours ago",
  "compile_date": "compiled on Jun 30 2014 at 18:57:55"
}

Guys, please, vote me back in,

I probably got voted out, don't know why, but since half of delegates are doubles/inits this doesn't sound fare.

I want to participate in the next run.

Hi HackFisher,
The win wallet has two window, and one has nothing but  a menubar. It will look nicely if combine the two window into one.

the latest code  (just pulled from git hub) doesn't show "blockchain_head_block_num":


momkey (unlocked) >>> about
{
  "bitshares_toolkit_revision": "2851364a09924c06b3b8dc76471d41c0755401c9",
  "bitshares_toolkit_revision_age": "3 hours ago",
  "fc_revision": "13da4b0d6a715d744fec3a04989e1a0788c37b37",
  "fc_revision_age": "12 hours ago",
  "compile_date": "compiled on Jun 30 2014 at 19:37:48"
}

(unlocked) >>> info
{
  "blockchain_head_block_num": 0,
  "blockchain_head_block_age": "2 minutes old",
  "blockchain_head_block_timestamp": "20140701T030600",
  "blockchain_average_delegate_participation": 0,
  "blockchain_blocks_left_in_round": 101,
  "blockchain_confirmation_requirement": 202,
  "blockchain_share_supply": 199999999981923,
  "blockchain_random_seed": "0000000000000000000000000000000000000000",
  "blockchain_database_version": 109,
  "blockchain_version": 104,
  "network_num_connections": 12,
  "network_num_connections_max": 200,
  "network_protocol_version": 104,
  "ntp_time": "20140701T030807",
  "ntp_error": -0.069119,
  "wallet_open": true,
  "wallet_unlocked": true,
  "wallet_unlocked_until": "12 days in the future",
  "wallet_unlocked_until_timestamp": "20140712T165018",
  "wallet_block_production_enabled": true,
  "wallet_next_block_production_time": null,
  "wallet_next_block_production_timestamp": null,
  "wallet_version": 100
}

Quote from: bytemaster on June 30, 2014, 10:06:26 PM
The last fork I see is block 1866 at 4:46:00 UTC... yet I still only have 54% participation. 

Eric has checked in some fixes that should eliminate a major source of the latency / forking. 

We have identified the following issues to be resolved:

1) synchronizing with the network is painfully slow after our weekend-long stress test.
      - we have some database optimizations to put into place that should resolve this.

2) scanning the blockchain for transactions that belong to you is CPU intensive
      - we have an architecture design in place that will support much lighter weight operation for everyone, but this will not delay launch because we don't expect 2 trx per second sustained to be the norm until long after we have the light-client support in place.

3) We are going to make all transactions expire after 48 hours
      - this will remove a major hit on our database, reduce the amount of storage required for a full node to validate blocks
      - it will eventually be possible to synchronize with the blockchain with only the "current state" + 48 hours of transactions.
      - this will be a small change, but result in a hard fork.

4) We are going to allow accounts to upgrade to delegates and reduce their pay (but not increase it). 
      - this will be a hard fork that will be implemented a long with the 48 hour trx validation window.

A new dry run will launch tomorrow night that will include all fixes to date and hopefully be the last of our forking days.   Keep producing blocks on this dry run with the latest client and we will see if our forks are reduced.

+5% +5% +5%
some questions:
1. will  the cycle time still 2 minutes?
2. will include a udt p2p network for delegate?

Quote from: GregGozzo on July 01, 2014, 02:11:05 AM
Just tried the new windows release and got this:

I get this as well when i use my windows 8 desktop. it says something about no disk F. my windows 7 laptop works find tho.

Is it worth participating in this dry run. i just updated to the most recent build on my mac and the sync is ridiculously slow and is using way to much energy on my cpu. On previous dry runs the energy impact was something like .1 and this energy impact is 100

Quote from: liondani on July 01, 2014, 01:50:46 AM
somebody sent me 10 XTS to make a delegate on my win7 node also  ;)

send you 33 XTS.

Now something strange...

when I transferred 1 XTS and 5 XTS from liondani-win7 to liondani-win7 I received back my funds minus the 0.2 XTS fees  (thats ok!)
BUT when I transferred 1 XTS from liondani-win7 to liondani  (the account that I haved renamed to liondani-win7) I "lost"/burnt that 1 XTS
Normaly the system schould not accept the transfer OR sent it to the same address key...

Just tried the new windows release and got this:

somebody sent me 10 XTS to make a delegate on my win7 node also  ;)

1.I created an account "liondani" with windows gui 0.0.7
2.I have sent 10 XTS from my linux account to "liondani" on my windows account...
3.I tried to register it but was not possible because I have allready that same name registered on the linux system
   so the next step was ...
4.wallet_account_rename liondani liondani-win7

now there is the bug! On "My Accounts" I see both accounts simultaneously with each account with 10 XTS
the good news is after I tried to rename the "existend" account liondani again (I wanted to get reach :P) it was not possible again... :)
so fix the confusing "feeling" that 2 accounts are present with the same amount of XTS due duplication....

screenshot:

Quote from: liondani on June 30, 2014, 06:15:18 PM

Quote from: cass on June 30, 2014, 05:54:48 PM
need some funds pls -- XTS6Gv31BJPo2UH1jRR7jQJRqBTWVSxYGgCk3HEWodSxpT4t2TE23 (cassssss) thx

Code Select Expand


liondaniel (unlocked) >>> wallet_transfer 50 XTS liondaniel cassssss
    BLK.TRX  TIMESTAMP           FROM                TO                  MEMO                                             AMOUNT             FEE              ID
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   pending   2014-06-30T18:13:49 liondaniel          cassssss                                                       50.00000 XTS         0.10000 XTS        6171ed15


thx

Quote from: sfinder on June 30, 2014, 10:38:24 PM
client crashed while opening wallet


(wallet closed) >>> connect: Operation now in progress
open momkey

Program received signal SIGSEGV, Segmentation fault.
_int_malloc (av=0x7ffff697e760 <main_arena>, bytes=39) at malloc.c:3302
3302    malloc.c: No such file or directory.
(gdb)

People seem to be getting segfaults once in a while, but it seems to be fixed upon wiping the data directory. Make sure you are on the latest code otherwise you could give that a shot: https://bitsharestalk.org/index.php?topic=5303.msg71563#msg71563