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 - bitder

Pages: 1 [2] 3 4 5
16
General Discussion / Re: segfault in 0.4.19
« on: October 02, 2014, 01:24:07 pm »
I've had a single segfault but 0.4.19 has been stable otherwise.
Since the majority has already upgraded to 0.4.19 it's probably easier to commit to it. The segfault is a hassle but it seems to be harmless otherwise.
The only problem is just restarting your delegate after a segfault but that can be done automatically with HackFisher's expect script (or a slightly modified version of it)
This way we can just wait for patch releases of 0.4.19 as they are made available.
Thoughts?

https://github.com/Bitsuperlab/operation_tools.git
restart/run_wallet.exp
Code: [Select]
#!/usr/bin/expect -f

set timeout -1
set default_port 1776
set port $default_port

### change wallet_name here
set wallet_name "delegate"
send_user "wallet name is: $wallet_name\n"
send_user "wallet passphrase: "
stty -echo
expect_user -re "(.*)\n"
  stty echo
set wallet_pass $expect_out(1,string)

  proc run_wallet {} {
    global wallet_name wallet_pass default_port port
      ### change command line here
      spawn ./bitshares_client --data-dir=delegate --p2p-port $port --server --httpport 9989 --rpcuser user --rpcpassword pass

      expect -exact "(wallet closed) >>> "
      send -- "about\r"
      expect -exact "(wallet closed) >>> "
      send -- "wallet_open $wallet_name\r"
      expect -exact "$wallet_name (locked) >>> "
      send -- "wallet_unlock 99999999\r"
      expect -exact "passphrase: "
      send -- "$wallet_pass\r"
      expect -exact "$wallet_name (unlocked) >>> "
      send -- "wallet_delegate_set_block_production ALL true\r"
      expect -exact "$wallet_name (unlocked) >>> "
      send -- "info\r"
      expect -exact "$wallet_name (unlocked) >>> "
      send -- "wallet_list_my_accounts\r"
      interact
      wait

      if { $port == $default_port } {
        set port [expr $port+1]
      } else {
        set port [expr $port-1]
      }
  }

while true {
  run_wallet
}


17
KeyID / Re: [DNS] ** LAST CHANCE TO CHECK ALLOCATION **
« on: September 30, 2014, 09:19:38 pm »
If the genesis supply is 5 Billion then AGS accounts for 1 Billion (or 20%). Does this mean AGS/PTS is already pre-diluted according to the *Final, guaranteed allocation* thread?

https://bitsharestalk.org/index.php?topic=6753.msg89570#msg89570

AGS gets 2 billion or 40% of the initial allocation (at least 20% of theoretical possible max 10bn)
That's what I thought. Then I think we have a problem with the genesis file.
I scaled the genesis_keyid.json by 1e-8 (which gives me a total supply of 5 billion)
I checked one of my AGS addresses and it was essentially scaling the AGS balance by 1000 (i.e. from a total of 1 Million AGS to 1 Billion DNS)
This means that AGS is only 20% of the total genesis supply.
(Can someone else verify with their AGS addresses?)

There's 2 million AGS total. So 2mn * 1k = 2bn, or 40% of the initial supply.
Thanks, forgot there was 1 million AGS for PTS donations and 1 million AGS for BTC donations.

18
KeyID / Re: [DNS] ** LAST CHANCE TO CHECK ALLOCATION **
« on: September 30, 2014, 09:14:58 pm »
If the genesis supply is 5 Billion then AGS accounts for 1 Billion (or 20%). Does this mean AGS/PTS is already pre-diluted according to the *Final, guaranteed allocation* thread?

https://bitsharestalk.org/index.php?topic=6753.msg89570#msg89570

AGS gets 2 billion or 40% of the initial allocation (at least 20% of theoretical possible max 10bn)
That's what I thought. Then I think we have a problem with the genesis file.
I scaled the genesis_keyid.json by 1e-8 (which gives me a total supply of 5 billion)
I checked one of my AGS addresses and it was essentially scaling the AGS balance by 1000 (i.e. from a total of 1 Million AGS to 1 Billion DNS)
This means that AGS is only 20% of the total genesis supply.
(Can someone else verify with their AGS addresses?)

19
KeyID / Re: [DNS] ** LAST CHANCE TO CHECK ALLOCATION **
« on: September 30, 2014, 09:01:43 pm »
If the genesis supply is 5 Billion then AGS accounts for 1 Billion (or 20%). Does this mean AGS/PTS is already pre-diluted according to the *Final, guaranteed allocation* thread?

https://bitsharestalk.org/index.php?topic=6753.msg89570#msg89570


20
General Discussion / Re: GSS - Genesis Stake Statistics
« on: September 26, 2014, 05:24:44 pm »
I found my mistake .. a stupid btw :) .. I search for the thresholds in the cumulative sum .. not in the individual address balances :) .. just stupid :)

@bitder: it seems you use a different BTSX genesis json file?! Maybe you use the one from the bitshares_toolkit?!

I think you should be using the following genesis (Feb 28 snapshot)
https://raw.githubusercontent.com/dacsunlimited/bitsharesx/master/libraries/blockchain/genesis_btsx.json

The other one is from the post AGS snapshot.

21
General Discussion / Re: GSS - Genesis Stake Statistics
« on: September 26, 2014, 06:47:17 am »
I see ...

Could you publish the code you wrote for the above please?

Excellent work

Code: [Select]
#!/usr/bin/env python
import json
with open('genesis_btsx.json', 'rt') as f:
  b = [ i[1]/500000.0 for i in json.load(f)['balances']]

b.sort()

def gt(b, t):
  print "%10d addresses > %10d BTSX"%(len([i for i in b if i>t]),t)

def top(b, n):
  tn=sum(b[-n:])
  tb=sum(b)
  print "top %6d addresses collectively own (%10d) %3.2f%% of shares"%(n,tn,tn*100.0/tb)

def itop(b,n):
  print "-"*80
  print "top %d addresses individual percentage"%n
  print "-"*80
  tb = b[-n:]
  tb.sort(reverse=True)
  for e,i in enumerate(tb):
    print "%3d %10d (%3.2f%%)"%(e+1,i,i/20000000)

def main():
  print "="*80
  print "total supply: %s, number of addresses: %s"%(sum(b), len(b))
  print "="*80
  for i in range(10):
    gt(b, 100000*2**i)
 
  for i in range(21):
    gt(b, 1000000*i)
 
  for i in range(1,101):
    top(b,i)
 
  itop(b,150)

if __name__ == '__main__':
  main()


22
General Discussion / Re: GSS - Genesis Stake Statistics
« on: September 26, 2014, 06:37:24 am »
Why devide by 5e5? what is the sum of all stakes then?

The supply in the genesis_btsx.json is BIPS  (1billion with a precision of 10e6)  dividing by 5x10e5 adjusts the BIPS to 2 billion BTSX supply.

Code: [Select]
$ ./btsx_stake.py
================================================================================
total supply: 1999999999.94, number of addresses: 57973
================================================================================
      2365 addresses >     100000 BTSX
      1379 addresses >     200000 BTSX
       792 addresses >     400000 BTSX
       431 addresses >     800000 BTSX
       182 addresses >    1600000 BTSX
        60 addresses >    3200000 BTSX
        26 addresses >    6400000 BTSX
        15 addresses >   12800000 BTSX
         8 addresses >   25600000 BTSX
         2 addresses >   51200000 BTSX
     57973 addresses >          0 BTSX
       344 addresses >    1000000 BTSX
       128 addresses >    2000000 BTSX
        66 addresses >    3000000 BTSX
        43 addresses >    4000000 BTSX
        35 addresses >    5000000 BTSX
        27 addresses >    6000000 BTSX
        25 addresses >    7000000 BTSX
        21 addresses >    8000000 BTSX
        20 addresses >    9000000 BTSX
        17 addresses >   10000000 BTSX
        17 addresses >   11000000 BTSX
        15 addresses >   12000000 BTSX
        14 addresses >   13000000 BTSX
        14 addresses >   14000000 BTSX
        14 addresses >   15000000 BTSX
        11 addresses >   16000000 BTSX
         9 addresses >   17000000 BTSX
         8 addresses >   18000000 BTSX
         8 addresses >   19000000 BTSX
         8 addresses >   20000000 BTSX
Code: [Select]
top      1 addresses collectively own (  58783756) 2.94% of shares
top      2 addresses collectively own ( 116215883) 5.81% of shares
top      3 addresses collectively own ( 157771274) 7.89% of shares
top      4 addresses collectively own ( 190946909) 9.55% of shares
top      5 addresses collectively own ( 223154898) 11.16% of shares
top      6 addresses collectively own ( 255362887) 12.77% of shares
top      7 addresses collectively own ( 282127576) 14.11% of shares
top      8 addresses collectively own ( 307893968) 15.39% of shares
top      9 addresses collectively own ( 324971244) 16.25% of shares
top     10 addresses collectively own ( 341644607) 17.08% of shares
top     11 addresses collectively own ( 358311274) 17.92% of shares
top     12 addresses collectively own ( 374067717) 18.70% of shares
top     13 addresses collectively own ( 389663029) 19.48% of shares
top     14 addresses collectively own ( 404917610) 20.25% of shares
top     15 addresses collectively own ( 417725418) 20.89% of shares
top     16 addresses collectively own ( 429209511) 21.46% of shares
top     17 addresses collectively own ( 440587350) 22.03% of shares
top     18 addresses collectively own ( 450355417) 22.52% of shares
top     19 addresses collectively own ( 459722773) 22.99% of shares
top     20 addresses collectively own ( 468729134) 23.44% of shares
top     21 addresses collectively own ( 476972291) 23.85% of shares
top     22 addresses collectively own ( 484644642) 24.23% of shares
top     23 addresses collectively own ( 492006313) 24.60% of shares
top     24 addresses collectively own ( 499160491) 24.96% of shares
top     25 addresses collectively own ( 506245604) 25.31% of shares
top     26 addresses collectively own ( 512746709) 25.64% of shares
top     27 addresses collectively own ( 519130333) 25.96% of shares
top     28 addresses collectively own ( 524931889) 26.25% of shares
top     29 addresses collectively own ( 530649218) 26.53% of shares
top     30 addresses collectively own ( 536298967) 26.81% of shares
top     31 addresses collectively own ( 541828437) 27.09% of shares
top     32 addresses collectively own ( 547242762) 27.36% of shares
top     33 addresses collectively own ( 552606593) 27.63% of shares
top     34 addresses collectively own ( 557763399) 27.89% of shares
top     35 addresses collectively own ( 562915683) 28.15% of shares
top     36 addresses collectively own ( 567822092) 28.39% of shares
top     37 addresses collectively own ( 572700864) 28.64% of shares
top     38 addresses collectively own ( 577461725) 28.87% of shares
top     39 addresses collectively own ( 582104631) 29.11% of shares
top     40 addresses collectively own ( 586613750) 29.33% of shares
top     41 addresses collectively own ( 591030033) 29.55% of shares
top     42 addresses collectively own ( 595234377) 29.76% of shares
top     43 addresses collectively own ( 599361284) 29.97% of shares
top     44 addresses collectively own ( 603290659) 30.16% of shares
top     45 addresses collectively own ( 607217915) 30.36% of shares
top     46 addresses collectively own ( 611082793) 30.55% of shares
top     47 addresses collectively own ( 614867655) 30.74% of shares
top     48 addresses collectively own ( 618532892) 30.93% of shares
top     49 addresses collectively own ( 622197190) 31.11% of shares
top     50 addresses collectively own ( 625860395) 31.29% of shares
top     51 addresses collectively own ( 629403274) 31.47% of shares
top     52 addresses collectively own ( 632881737) 31.64% of shares
top     53 addresses collectively own ( 636360120) 31.82% of shares
top     54 addresses collectively own ( 639815798) 31.99% of shares
top     55 addresses collectively own ( 643182415) 32.16% of shares
top     56 addresses collectively own ( 646532040) 32.33% of shares
top     57 addresses collectively own ( 649850763) 32.49% of shares
top     58 addresses collectively own ( 653111821) 32.66% of shares
top     59 addresses collectively own ( 656334022) 32.82% of shares
top     60 addresses collectively own ( 659551600) 32.98% of shares
top     61 addresses collectively own ( 662749651) 33.14% of shares
top     62 addresses collectively own ( 665867502) 33.29% of shares
top     63 addresses collectively own ( 668906271) 33.45% of shares
top     64 addresses collectively own ( 671928432) 33.60% of shares
top     65 addresses collectively own ( 674940312) 33.75% of shares
top     66 addresses collectively own ( 677941692) 33.90% of shares
top     67 addresses collectively own ( 680921575) 34.05% of shares
top     68 addresses collectively own ( 683886009) 34.19% of shares
top     69 addresses collectively own ( 686783438) 34.34% of shares
top     70 addresses collectively own ( 689675063) 34.48% of shares
top     71 addresses collectively own ( 692553726) 34.63% of shares
top     72 addresses collectively own ( 695427368) 34.77% of shares
top     73 addresses collectively own ( 698284732) 34.91% of shares
top     74 addresses collectively own ( 701141573) 35.06% of shares
top     75 addresses collectively own ( 703995576) 35.20% of shares
top     76 addresses collectively own ( 706797377) 35.34% of shares
top     77 addresses collectively own ( 709566749) 35.48% of shares
top     78 addresses collectively own ( 712334623) 35.62% of shares
top     79 addresses collectively own ( 715077622) 35.75% of shares
top     80 addresses collectively own ( 717815997) 35.89% of shares
top     81 addresses collectively own ( 720527826) 36.03% of shares
top     82 addresses collectively own ( 723216838) 36.16% of shares
top     83 addresses collectively own ( 725902455) 36.30% of shares
top     84 addresses collectively own ( 728539203) 36.43% of shares
top     85 addresses collectively own ( 731174924) 36.56% of shares
top     86 addresses collectively own ( 733799647) 36.69% of shares
top     87 addresses collectively own ( 736407156) 36.82% of shares
top     88 addresses collectively own ( 738983279) 36.95% of shares
top     89 addresses collectively own ( 741545729) 37.08% of shares
top     90 addresses collectively own ( 744103394) 37.21% of shares
top     91 addresses collectively own ( 746628798) 37.33% of shares
top     92 addresses collectively own ( 749150497) 37.46% of shares
top     93 addresses collectively own ( 751662720) 37.58% of shares
top     94 addresses collectively own ( 754114643) 37.71% of shares
top     95 addresses collectively own ( 756530035) 37.83% of shares
top     96 addresses collectively own ( 758923852) 37.95% of shares
top     97 addresses collectively own ( 761310156) 38.07% of shares
top     98 addresses collectively own ( 763693852) 38.18% of shares
top     99 addresses collectively own ( 766053668) 38.30% of shares
top    100 addresses collectively own ( 768380351) 38.42% of shares
Code: [Select]
--------------------------------------------------------------------------------
top 150 addresses individual percentage
--------------------------------------------------------------------------------
  1   58783756 (2.94%)
  2   57432126 (2.87%)
  3   41555391 (2.08%)
  4   33175634 (1.66%)
  5   32207989 (1.61%)
  6   32207989 (1.61%)
  7   26764689 (1.34%)
  8   25766391 (1.29%)
  9   17077276 (0.85%)
 10   16673362 (0.83%)
 11   16666666 (0.83%)
 12   15756443 (0.79%)
 13   15595312 (0.78%)
 14   15254581 (0.76%)
 15   12807807 (0.64%)
 16   11484093 (0.57%)
 17   11377839 (0.57%)
 18    9768066 (0.49%)
 19    9367356 (0.47%)
 20    9006360 (0.45%)
 21    8243157 (0.41%)
 22    7672351 (0.38%)
 23    7361670 (0.37%)
 24    7154177 (0.36%)
 25    7085113 (0.35%)
 26    6501105 (0.33%)
 27    6383623 (0.32%)
 28    5801556 (0.29%)
 29    5717329 (0.29%)
 30    5649748 (0.28%)
 31    5529469 (0.28%)
 32    5414325 (0.27%)
 33    5363831 (0.27%)
 34    5156805 (0.26%)
 35    5152283 (0.26%)
 36    4906409 (0.25%)
 37    4878772 (0.24%)
 38    4760861 (0.24%)
 39    4642905 (0.23%)
 40    4509118 (0.23%)
 41    4416283 (0.22%)
 42    4204344 (0.21%)
 43    4126906 (0.21%)
 44    3929374 (0.20%)
 45    3927256 (0.20%)
 46    3864878 (0.19%)
 47    3784861 (0.19%)
 48    3665237 (0.18%)
 49    3664298 (0.18%)
 50    3663205 (0.18%)
 51    3542878 (0.18%)
 52    3478462 (0.17%)
 53    3478383 (0.17%)
 54    3455678 (0.17%)
 55    3366616 (0.17%)
 56    3349624 (0.17%)
 57    3318722 (0.17%)
 58    3261058 (0.16%)
 59    3222200 (0.16%)
 60    3217578 (0.16%)
 61    3198050 (0.16%)
 62    3117851 (0.16%)
 63    3038769 (0.15%)
 64    3022160 (0.15%)
 65    3011880 (0.15%)
 66    3001380 (0.15%)
 67    2979883 (0.15%)
 68    2964433 (0.15%)
 69    2897428 (0.14%)
 70    2891625 (0.14%)
 71    2878662 (0.14%)
 72    2873641 (0.14%)
 73    2857364 (0.14%)
 74    2856840 (0.14%)
 75    2854003 (0.14%)
 76    2801800 (0.14%)
 77    2769371 (0.14%)
 78    2767873 (0.14%)
 79    2742998 (0.14%)
 80    2738375 (0.14%)
 81    2711829 (0.14%)
 82    2689011 (0.13%)
 83    2685617 (0.13%)
 84    2636748 (0.13%)
 85    2635720 (0.13%)
 86    2624722 (0.13%)
 87    2607508 (0.13%)
 88    2576123 (0.13%)
 89    2562449 (0.13%)
 90    2557664 (0.13%)
 91    2525404 (0.13%)
 92    2521698 (0.13%)
 93    2512223 (0.13%)
 94    2451922 (0.12%)
 95    2415392 (0.12%)
 96    2393816 (0.12%)
 97    2386304 (0.12%)
 98    2383695 (0.12%)
 99    2359816 (0.12%)
100    2326682 (0.12%)
101    2296374 (0.11%)
102    2290479 (0.11%)
103    2283298 (0.11%)
104    2273360 (0.11%)
105    2247281 (0.11%)
106    2246884 (0.11%)
107    2220930 (0.11%)
108    2218040 (0.11%)
109    2214284 (0.11%)
110    2171617 (0.11%)
111    2159797 (0.11%)
112    2156815 (0.11%)
113    2154175 (0.11%)
114    2133075 (0.11%)
115    2127135 (0.11%)
116    2121827 (0.11%)
117    2102519 (0.11%)
118    2097921 (0.10%)
119    2094096 (0.10%)
120    2087144 (0.10%)
121    2061556 (0.10%)
122    2055383 (0.10%)
123    2053970 (0.10%)
124    2047357 (0.10%)
125    2036753 (0.10%)
126    2027721 (0.10%)
127    2024862 (0.10%)
128    2006044 (0.10%)
129    1994740 (0.10%)
130    1986672 (0.10%)
131    1980159 (0.10%)
132    1964291 (0.10%)
133    1956322 (0.10%)
134    1936345 (0.10%)
135    1932751 (0.10%)
136    1932485 (0.10%)
137    1930349 (0.10%)
138    1922749 (0.10%)
139    1916867 (0.10%)
140    1915761 (0.10%)
141    1909669 (0.10%)
142    1900547 (0.10%)
143    1892317 (0.09%)
144    1890150 (0.09%)
145    1881665 (0.09%)
146    1866750 (0.09%)
147    1861346 (0.09%)
148    1843122 (0.09%)
149    1838428 (0.09%)
150    1834548 (0.09%)


23
General Discussion / Re: GSS - Genesis Stake Statistics
« on: September 26, 2014, 01:27:07 am »
xeroc, give this a try.

$ cat ./btsx_stake.py
Code: [Select]
#!/usr/bin/env python
import json
with open('genesis_btsx.json', 'rt') as f:
  b = [ i[1]/500000.0 for i in json.load(f)['balances']]
def gt(b, t):
  print "%10d addresses > %10d BTSX"%(len([i for i in b if i>t]),t)

print "total supply: %s, number of addresses: %s"%(sum(b), len(b))
for i in range(10):
  gt(b, 100000*2**i)


Code: [Select]
$ ./btsx_stake.py
total supply: 1999999999.94, number of addresses: 57973
      2365 addresses >     100000 BTSX
      1379 addresses >     200000 BTSX
       792 addresses >     400000 BTSX
       431 addresses >     800000 BTSX
       182 addresses >    1600000 BTSX
        60 addresses >    3200000 BTSX
        26 addresses >    6400000 BTSX
        15 addresses >   12800000 BTSX
         8 addresses >   25600000 BTSX
         2 addresses >   51200000 BTSX


24
General Discussion / Re: GSS - Genesis Stake Statistics
« on: September 25, 2014, 03:26:55 pm »
So there are about 200 addresses with a million shares. Sounds about right.
That's way off.
1379 addresses  > 1 million BTSX
128 addresses > 10 million BTSX
8 addresses > 100 million BTSX
3 addresses > 200 million BTSX
top address > 293 million BTSx

25
I experienced something very strange.
Although I had perfect internet connection my delegates end up on a fork.
They didn't synchronize until I've restarted the client.
This never happened before.

There's definitely something wrong with the networking code with 0.4.16
I left my non-delegate client (CLI) running after upgrading to 0.4.16 and it has stopped syncing multiple times now.
It requires one or more restarts of the client for it to sync again.

26
General Discussion / Re: What the Fork??
« on: September 22, 2014, 02:02:40 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,

Restarted my non-delegate client again and it caught up.

27
General Discussion / Re: What the Fork??
« on: September 22, 2014, 02:00:15 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,

28
Technical Support / Re: Problem in connect. Invalid chain id
« on: September 21, 2014, 02:27:21 pm »
...
Code: [Select]
>> blockchain_get_info

{
  "blockchain_id": "d2b8c7464fee1179616efc306c195aaddf2bdf4da26bd31c825d3ad2b266b933",
  "symbol": "XTS",
  "name": "BitShares XTS",
  "version": 109,
  "db_version": 133,
  "genesis_timestamp": "2014-09-01T00:00:00",
  "block_interval": 10,
  "max_block_size": 51200,
  "max_blockchain_size": 107374182400,
  "address_prefix": "XTS",
  "inactivity_fee_apr": "0.00010 XTS",
  "relay_fee": "0.10000 XTS",
  "delegate_num": 101,
  "delegate_reg_fee": "0.00000 XTS",
  "name_size_max": 63,
  "memo_size_max": 19,
  "data_size_max": 65536,
  "symbol_size_max": 5,
  "symbol_size_min": 3,
  "asset_reg_fee": "0.00000 XTS",
  "asset_shares_max": 1000000000000000,
  "min_market_depth": "2,000,000.00000 XTS",
  "max_pending_queue_size": 10,
  "max_trx_per_second": 1,
  "min_block_fee": "0.00000 XTS"
}

I noticed genesis.json is broken, there is no "tests/genesis.json":
genesis.json -> ../../tests/genesis.json
So I download one from https://raw.githubusercontent.com/dacsunlimited/bitsharesx/master/libraries/blockchain/genesis.json .
Ues parameter with --genesis-config genesis.json. But it also not work.

Could u help me?

You're building from the wrong repo. You need to clone the dacsunlimited fork since btsx is launched by them.
git clone https://github.com/dacsunlimited/bitsharesx.git


29
  I think the current "chicken and egg" situation where you need to ask someone to register you is a little ridiculous.

Again check the first proposal here:
https://bitsharestalk.org/index.php?topic=9075.0

It should allow us to get rid of "Post here if you want 1 BTSX" threads.

Wouldn't it be simpler to just allow transfers to any address as well as TITAN transfers to a name?
A problem with only supporting TITAN is that the exchanges have a record of all fund transfers by name (which arguably is less private than just allowing transfers to any address where the exchanges can't definitively associate the participant on the other side of the transaction).
i.e. the exchange knows you transferred 50K BTSX to account Fred instead of just knowing that you transferred 50K BTSX to some address that may or may not be yours.

30
General Discussion / Re: publish feed price automatic(From BitSuperLab)
« on: September 16, 2014, 03:13:59 pm »
If all the delegates are using alt's code doesn't that sort of defeat the purpose? I guess we could modify his source to use different sources...but there aren't a lot to choose from I guess.

The delegates are sampling and updating at different times so the overall median price feed should track the sampled data source (with a lag that's dependent on how frequently the delegates as a group updates the feed).
Obviously, the more delegates sampling the data source and publishing feeds the closer it will track the sampled source.
http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem


Pages: 1 [2] 3 4 5