ok, so I did "wallet_import_keys_from_json" in 0.5.0, and it looks like it imported everything. Thanks all for the help/comments, you guys rock

Maybe those PTS addresses are the BTS that got sharedropped to PTS during the merger.

Yes, could be. Or they could be PTS addresses from the Feb. 28th snapshot for BTS too. I keep thinking I should have some BTS associated to my PTS addresses, but I remember now that I donated them after the snapshot    I guess wishing really hard for something to be true does not make it true   

Thanks, missed that post, had still an 80/10/10 distribution in mind, hence the reason I was expecting some to be there. To be fair, there are some PTS addresses in genesis.json, not sure what purpose they serve:

https://raw.githubusercontent.com/BitShares/bitshares/dvs/0.4.28/libraries/blockchain/genesis_bts.json
https://raw.githubusercontent.com/BitShares/bitshares/dvs/0.4.28/libraries/blockchain/genesis_dvs.json

(look for addresses that start with 'P')

I guess I'll have to wait, then, however it still felt weird that the private key import seemed to work correctly but that there was no balance associated with them...

Note: I did call wallet_rescan_blockchain, just to be clear...

tl;dr: slate can be seen here: http://www.bitsharesblocks.com/delegate/slate?name=btstools.digitalgaia

Hi all,

I finally got around to putting together a delegate slate of people that I feel should be voted in order to best benefit the BitShares ecosystem. Thanks Xeroc and Fuzz for pushing this issue, I believe it is a very important one. Without further ado, here's the slate (scroll down to see full list):

delegate: btstools.digitalgaia
slate:
    # core developers, all at 100% payrate
    - dev0.nikolai                 # Toast (Nikolai Mushegian)
    - stan.delegate.xeldal         # Stan (Stan Larimer)
    - bm.payroll.riverhead         # Bytemaster (Daniel Larimer)
    - jcalfee1-developer-team.helper.liondani  # James Calfee
    - dev0.theoretical             # Theoretical (formerly: drltc)
    - dev-trial.misc.nikolai       # Toast budget for new dev trials
    - valzav.payroll.testz         # Valentine (Valzav)
    - delegate-dev1.btsnow         # Dan Notestein
    - delegate-dev2.btsnow         # Eric Frias
    - delegate-dev3.btsnow         # Gregorsz
    - delegate-dev4.btsnow         # Gandalf-The-Grey
    - dev.nathanhourt.com          # Nathan Hourt
    - developer.vikram             # Vikram Rajkumar

    # 3rd-party developers (forum id specified when different from delegate)
    - del0.cass                    # 100%  https://bitsharestalk.org/index.php?topic=11753
    - dev.bitsharesblocks          # 100%  https://bitsharestalk.org/index.php?topic=11272 (id: svk)
    - btstools.digitalgaia         #  30%  https://bitsharestalk.org/index.php?topic=12534 (id: wackou)
    - backbone.riverhead           #  10%  https://bitsharestalk.org/index.php?topic=10861
    - dev-metaexchange.monsterer   # 100%  https://bitsharestalk.org/index.php?topic=12317
    - dev.sidhujag                 # 100%  https://bitsharestalk.org/index.php?topic=12027
    - elmato                       # 100%  https://bitsharestalk.org/index.php?topic=12494
    - tradebts.gulu                # 100%  https://bitsharestalk.org/index.php?topic=13457
    - dacx.baozou                  # 100%  https://bitsharestalk.org/index.php?topic=13428
    - dev-pc.bitcube               # 100%  https://bitsharestalk.org/index.php?topic=13995 (id: pc, cube)
    - minebitshares-reloaded       # 100%  https://bitsharestalk.org/index.php?topic=14887 (id: nethyb)  |  seed node: euseednode.minebitshares.com, auseednode.minebitshares.com

    # marketing initiatives
    - marketing.methodx            # 100%  https://bitsharestalk.org/index.php?topic=11663
    - argentina-marketing.matt608  # 100%  https://bitsharestalk.org/index.php?topic=11847
    - media.bitscape               # 100%  https://bitsharestalk.org/index.php?topic=12833
    - delegate.rgcrypto            # 100%  http://rgcrypto.wordpress.com/2015/01/05/announcement/
    - market.cn.group101           # 100%  https://bitsharestalk.org/index.php?topic=13226
    - delegate.verbaltech          # 100%  https://bitsharestalk.org/index.php?topic=13837
    - www.bts-hk                   # 100%  https://bitsharestalk.org/index.php?topic=13724
    - sollywood.sollars-com        # 100%  https://bitsharestalk.org/index.php?topic=13900
    - delegate.dposhub-org         # 100%  https://bitsharestalk.org/index.php?topic=15832
    - delegate.kencode             # 100%  https://bitsharestalk.org/index.php?topic=16072

    # other / special purpose delegates
    - fuzzy.beyondbitcoin          # 100%  https://bitsharestalk.org/index.php?topic=13485
    - fund.bitsharesbreakout       # 100%  https://bitsharestalk.org/index.php?topic=13500
    - del.fav                      #  80%  https://bitsharestalk.org/index.php?topic=15094

    # active "standard" delegates  (3% payrate)
    - delegate.xeroc
    - delegate.liondani     # seed node: 185.25.22.21:1776  |  chain server: 185.25.22.21:1375
    - mr.agsexplorer        # id: boombastic  |  seed node: 180.153.142.120:1777
    - delegate.baozi        # id: alt         |  seed node: 106.185.26.162:1776
    - immortal.bitdelegate  # id: emski       |  seed node: seed.bitdelegate.org:42577
    - dele-puppy            # id: puppies     |  seed node: 95.85.33.16:8764
    - cny.bts500            # id: heyD
    - btsx.chinesecommunity # id: ripplexiaoshan
    - delegate.cgafeng
    - testz
    - delegate.xeldal
    - delegate.coolspeed
    - maqifrnswa
    - spartako
    - emski.bitdelegate
    - dpos.crazybit
    - delegate.webber
    - calabiyau
    - kokojie
    - bdnoble
    - bitcoiners
    - delegate1.john-galt
    - delegate-clayop

    # standby newcomers producing feeds and up-to-date (payrate 3%)
    # (getting these voted in is good for decentralization)
    - delegate.robrigo
    - moon.warlock       # id: davidpbrown
    - delegate-1.lafona  # 1% payrate
    - delegate-mdj       # 2% payrate (id: mdj)
    - delegate.ihashfury # seed nodes and chain servers: https://bitsharestalk.org/index.php?topic=12856.0
    - triox-delegate     # id: triox

I hope I did not forget anyone, if so, please let me know via PM. Another thing I'd like to point out, is that this slate as shown here is in the yaml format (similar to json, but less "visual noise") and can be published if you have the bts_tools installed directly with the following command:

$ bts publish_slate slate.yaml

You can find some documentation on how to publish your own slate with the bts_tools here: http://bts-tools.readthedocs.org/en/latest/cmdline.html#publishing-a-slate

 

I also just added a publish_slate command to my bts_tools that does the same as your script, hopefully more delegates are going to publish slates if we make it as easy as possible. I am currently curating my own slate of delegates and will publish it real soon now.

You could probably implement this in ~5 lines of Python by just running a proxy that forwards RPC's in the whitelist of allowed calls and blocks unlisted RPC methods.

Keep in mind you have to protect your config.json, for example by giving the Bitshares client its own user account and setting UNIX permissions (e.g. chmod 600) on config.json.  Otherwise a rogue script could just read the RPC username and password directly from the config file.

Now that you say it, this indeed seems like the best option. My first thought was to get this as close as possible to the client, so that it's easier to configure/setup and that there is as little attack surface as possible, but then (as you rightly pointed) the config.json file needs to be read-protected with its own user account, which makes it less immediate to setup and then the overhead of setting up a python RPC proxy doesn't seem so big anymore. (I use the standard location of the config.json myself in the bts_tools for convenience to get the RPC user/password without having to type them , so I couldn't limit the tools themselves by setting up access rights in that file...)

I might whip up such in proxy script in the next few days, stay tuned...

The "wallet_enabled" config property should get you 90% of the way there. Do you need more granular control than "can access funds" ?

Thanks, I didn't know about this one. I think more granular would be better, though, for instance let's say I want to give access to my wallet to a script that publishes feeds (quite common ), but I don't really want that script to have unrestricted access to my funds, only the wallet_publish_feed method is required.