136
General Discussion / nuBits: 9$ - nice peg
« on: February 06, 2015, 03:08:14 pm »
not CMC's fault:
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.
not CMC's fault:
137
General Discussion / [Python-API] python-bitsharesrpc
« on: January 25, 2015, 05:54:08 pm »
python-bitsharesrpc
Python module for the BitShares client
Download
https://github.com/xeroc/python-bitsharesrpc
Installation
Requirements
Usage
All RPC commands of the BitShares client are exposed as methods in the class bitsharesrpc. Once an instance of bitsharesrpc is created, i.e.,
Example to unlock the wallet
Example to lock the wallet
Minimalistic CLI:
Python module for the BitShares client
Download
https://github.com/xeroc/python-bitsharesrpc
Installation
Code: [Select]
git clone https://github.com/xeroc/python-bitsharesrpc
cd python-bitsharesrpc
python setup install # (optionally with parameter --user fo non-root installations)
Requirements
- python-requests
Usage
All RPC commands of the BitShares client are exposed as methods in the class bitsharesrpc. Once an instance of bitsharesrpc is created, i.e.,
Code: [Select]
import bitsharesrpc
import config
rpc = bitsharesrpc.client(config.url, config.user, config.passwd)any rpc command can be issued using the instance via the syntax rpc.command(parameters). Example:Code: [Select]
rpc.get_info()
rpc.open_wallet("default")
rpc.ask(account, amount, quote, price, base)
...Example to unlock the wallet
Code: [Select]
#!/usr/bin/python
import bitsharesrpc
import config
if __name__ == "__main__":
rpc = bitsharesrpc.client(config.url, config.user, config.passwd)
print(rpc.wallet_open(config.wallet))
print(rpc.unlock(999999, config.unlock))Example to lock the wallet
Code: [Select]
#!/usr/bin/python
import bitsharesrpc
import config
if __name__ == "__main__":
rpc = bitsharesrpc.client(config.url, config.user, config.passwd)
print rpc.wallet_open("delegate")
print rpc.lock()Minimalistic CLI:
Code: [Select]
#!/usr/bin/python
import bitsharesrpc, json
rpc = bitsharesrpc.client("http://localhost:1998/rpc", "username", "password")
while 1:
cmd = raw_input(">>").split()
print(json.dumps(rpc.rpcexec({"method":cmd[0],"params":list(cmd[1:]),
"jsonrpc":"2.0","id":0}),indent=4))
138
Stakeholder Proposals / Python script to put portions of delegate pay into markers at or below the feed
« on: January 24, 2015, 03:04:50 pm »
Source:
https://github.com/xeroc/pytshares/blob/master/exchange-delegate-pay.py
Configuration of RPC:
from https://github.com/xeroc/pytshares/blob/master/config-sample.py
put the RPC config stuff into config.py
Configuration of Script:
I am going to run this on a weekly basis at the above settings to feed the USD and BTS markets with my 3% pay delegate.
https://github.com/xeroc/pytshares/blob/master/exchange-delegate-pay.py
Configuration of RPC:
from https://github.com/xeroc/pytshares/blob/master/config-sample.py
put the RPC config stuff into config.py
Code: [Select]
url = "http://127.0.0.1:19988/rpc"
user = 'username'
passwd = 'pwd'
unlock = "unlockPwd"
wallet = "default"
Configuration of Script:
Code: [Select]
accountname = "delegate.xeroc" # the delegate
exchangename = "exchange.xeroc" # a separate account to do the market operations
payoutname = "payouts.xeroc" # collect all funds to that account
partition = { # how to split the pay .. here 50% stay BTS 25% each for EUR and USD
"USD" : .25,
"EUR" : .25,
"BTS" : .5,
} ## BTS has to be last
spread = 0.02 # put ask 2% below feed
txfee = 0.1 # BTS
btsprecision = 1e5
I am going to run this on a weekly basis at the above settings to feed the USD and BTS markets with my 3% pay delegate.
139
General Discussion / Easy-to-use Python RPC API for BitShares
« on: January 23, 2015, 02:47:03 pm »
Download (With some custom functions)
https://github.com/xeroc/pytshares/blob/master/btsrpcapi.py
Code:
Quick'n Dirty Howto:
Dump all private keys (owner keys only)
Switch block production over to another machine:
Have fun!
https://github.com/xeroc/pytshares/blob/master/btsrpcapi.py
Code:
Code: [Select]
#!/usr/bin/python
import requests
import json
class btsrpc(object) :
def __init__(self, url, user, pwd) :
self.auth = (user,pwd)
self.url = url
self.headers = {'content-type': 'application/json'}
def rpcexec(self,payload) :
try:
response = requests.post(self.url, data=json.dumps(payload), headers=self.headers, auth=self.auth)
return json.loads(response.text)
except:
raise Exception("Unkown error executing RPC call!")
def __getattr__(self, name) :
def method(*args):
r = self.rpcexec({
"method": name,
"params": args,
"jsonrpc": "2.0",
"id": 0
})
if "error" in r:
raise Exception(r["error"])
return r
return method
class btsrpcapi(btsrpc) :
def __init__(self, url, user, pwd) :
btsrpc.__init__(self, url, user, pwd)
### Room for Custom Functions: ###
def getassetbalance(self,name,asset) :
balance = self.wallet_account_balance(name)
for b in balance[ "result" ][ 0 ][ 1 ]:
if b[ 0 ] == asset : return float(b[ 1 ])
return -1
def setnetwork(self,d,m) :
return self.network_set_advanced_node_parameters({"desired_number_of_connections":d, "maximum_number_of_connections":m})
def orderhistory(self,a,b,l) :
return self.blockchain_market_order_history(a,b,1,l)
Quick'n Dirty Howto:
Dump all private keys (owner keys only)
Code: [Select]
#!/usr/bin/python
from btsrpcapi import *
import config
if __name__ == "__main__":
rpc = btsrpcapi(config.url, config.user, config.passwd)
print rpc.info()
print rpc.wallet_open(config.wallet)
rpc.unlock(9999,config.unlock)
r = (rpc.wallet_list_my_accounts())
accounts = r["result"]
print "---------------------------------------------------------------------------------"
for account in accounts :
print "%20s - %s - %s" % (account["name"], account["owner_key"], rpc.wallet_dump_private_key(account["owner_key"]))
print "---------------------------------------------------------------------------------"
print rpc.lock()
Switch block production over to another machine:
Code: [Select]
#!/usr/bin/python
import csv
import os
from btsrpcapi import *
import config
rpc = btsrpcapi(config.backupurl, config.backupuser, config.backuppasswd)
rpc2 = btsrpcapi(config.mainurl, config.mainuser, config.mainpasswd)
def enable( ) :
print "checking connectivity"
rpc2.info()
rpc.info()
print "enabling backup block production"
rpc2.wallet_open("delegate")
rpc2.wallet_delegate_set_block_production("ALL","true")
rpc2.unlock(999999, config.mainunlock)
rpc2.setnetwork(25,30)
print "disabling main block production"
rpc.wallet_open("delegate")
rpc.lock()
rpc.wallet_delegate_set_block_production("ALL","false")
if __name__ == "__main__":
enable( )
Have fun!
140
General Discussion / Can we have dacsunlimited.com removed or point to bitshares.org
« on: January 21, 2015, 03:30:07 pm »
The content of http://dacsunlimited.com/ is hopelessly out-dated!!
142
Stakeholder Proposals / Howto publish a Slates for Delegates
« on: January 05, 2015, 03:31:49 pm »
Hey there,
I'd like to see many more (managed) slates among the elected delegates to build a web-of-trust using delegate slates such as delegate.xeroc.
Why?
The advantage of having several trusted sources of slates are:
- users have no need to evaluate 101 delegates
- if I trust delegate xyz .. and the delegates (how is supposedly connected to some of the other delegates) trust delegate abc, why shouldn't I?
- assuming delegate uvy disappoints (fraud, misuse, reliability, ...) removing it from slates would directly affect all future transactions made via "as delegates recommend" - firing a delegate should be easier that way.
Helper script:
I published a script (originally wrote it for fuzz) which should be quite easy to use:
https://github.com/xeroc/delegate-slate
1) $ git clone https://github.com/xeroc/delegate-slate
2) $ cp config-example.py config.py
3) modify config.py accordingly
4) Run the script with $ python main.py
Example configuration:
Example output:
If you publish your slate please consider announcing your slate and keeping it up to date. I hope that svk eventually finds the time to list delegates slate separately and allows browsing their approvals.
Happing slating!
I'd like to see many more (managed) slates among the elected delegates to build a web-of-trust using delegate slates such as delegate.xeroc.
Why?
The advantage of having several trusted sources of slates are:
- users have no need to evaluate 101 delegates
- if I trust delegate xyz .. and the delegates (how is supposedly connected to some of the other delegates) trust delegate abc, why shouldn't I?
- assuming delegate uvy disappoints (fraud, misuse, reliability, ...) removing it from slates would directly affect all future transactions made via "as delegates recommend" - firing a delegate should be easier that way.
Helper script:
I published a script (originally wrote it for fuzz) which should be quite easy to use:
https://github.com/xeroc/delegate-slate
1) $ git clone https://github.com/xeroc/delegate-slate
2) $ cp config-example.py config.py
3) modify config.py accordingly
4) Run the script with $ python main.py
Example configuration:
Code: [Select]
## URL to RPC API of client
url = "http://10.0.0.16:19988/rpc"
## User as defined with --rpcuser=test or BitShares config file
user = 'username'
## User as defined with --rpcpassword=test or BitShares config file
passwd = 'password'
## Wallet name ( default: default :) )
wallet = "default"
## Unlock passphrase for the wallet
unlock = ""
## Delegate for which to publish a slate
delegate = "delegate.xeroc"
## Delegate which pays for the slate broadcast transaction
payee = "payouts.xeroc"
## NOTE: the private keys for both, "delegate" and "payee", must be in
## available in the wallet!
## List of trusted delegates
trusted = [
"a.delegate.charity",
"alecmenconi",
"angel.bitdelegate",
"b.delegate.charity",
"backbone.riverhead",
"bdnoble",
"bitcoiners",
"bitcube",
"bitsuperlab.gentso",
"clout-delegate1",
"crazybit"
"del.coinhoarder",
"dele-puppy",
"delegate.baozi",
"delegate.charity",
"delegate.jabbajabba",
"delegate.liondani",
"delegate.svk31",
"delegate.xeldal",
"delegate1.john-galt",
"forum.lottocharity",
"happyshares",
"luckybit",
"maqifrnswa",
"mr.agsexplorer",
"skyscraperfarms",
"spartako",
"testz",
"wackou.digitalgaia",
]
Example output:
Code: [Select]
python main.py
Opening connection to client
Opening wallet delegate
Unlocking wallet
Unapproving all previously approve delegates
Approving trusted delegates
- a.delegate.charity
- alecmenconi
- angel.bitdelegate
- b.delegate.charity
- backbone.riverhead
- bdnoble
- bitcoiners
- bitcube
- bitsuperlab.gentso
- bts.fordream
- clout-delegate1
- crazybit
- del.coinhoarder
- dele-puppy
- delegate-clayop
- delegate.baozi
- delegate.charity
- delegate.jabbajabba
- delegate.liondani
- delegate.nathanhourt.com
- delegate.xeldal
- delegate1.john-galt
- dev.bitsharesblocks
- dev0.nikolai
- forum.lottocharity
- happyshares
- luckybit
- maqifrnswa
- marketing.methodx
- mr.agsexplorer
- skyscraperfarms
- spartako
- testz
- titan.crazybit
- wackou.digitalgaia
- dev-metaexchange.monsterer
- stan.delegate.xeldal
- bm.payroll.riverhead
- del0.cass
- argentina-marketing.matt608
- btstools.digitalgaia
- dev.sidhujag
- media-delegate
- jcalfee1-developer-team.helper.liondani
- media.bitscape
- provisional.bitscape
- valzav.payroll.testz
- elmato
- blackwavelabs
Broadcasting slate
Transactions ID: 88ed833a426d96ad93a95553e870da8eaaae7bd4
If you publish your slate please consider announcing your slate and keeping it up to date. I hope that svk eventually finds the time to list delegates slate separately and allows browsing their approvals.
Happing slating!
143
General Discussion / FYI: relative asks/bids available in the CLI [update: commands available-0.4.27]
« on: December 16, 2014, 04:19:25 am »Code: [Select]
delegate (locked) >>> help wallet_market_submit_relative_ask
Usage:
wallet_market_submit_relative_ask <from_account_name> <sell_quantity> <sell_quantity_symbol> <relative_ask_price> <ask_price_symbol> [limit_ask_price] Used to place a request to sell a quantity of assets at a price specified in another asset
Used to place a request to sell a quantity of assets at a price specified in another asset
Parameters:
from_account_name (account_name, required): the account that will provide funds for the ask
sell_quantity (string, required): the quantity of items you would like to sell
sell_quantity_symbol (asset_symbol, required): the type of items you would like to sell
relative_ask_price (string, required): the relative price per unit sold.
ask_price_symbol (asset_symbol, required): the type of asset you would like to be paid
limit_ask_price (string, optional, defaults to ""): the minimum price per unit sold.
Returns:
transaction_record
aliases: relative_ask
and
Code: [Select]
delegate (locked) >>> help wallet_market_submit_relative_bid
Usage:
wallet_market_submit_relative_bid <from_account_name> <quantity> <quantity_symbol> <relative_price> <base_symbol> [limit_price] Used to place a request to buy a quantity of assets at a price specified in another asset
Used to place a request to buy a quantity of assets at a price specified in another asset
Parameters:
from_account_name (account_name, required): the account that will provide funds for the bid
quantity (string, required): the quantity of items you would like to buy
quantity_symbol (asset_symbol, required): the type of items you would like to buy
relative_price (string, required): the price relative to the feed you would like to pay
base_symbol (asset_symbol, required): the type of asset you would like to pay with
limit_price (string, optional, defaults to ""): the limit on what you are willing to pay
Returns:
transaction_record
aliases: relative_bid
144
General Discussion / [Business Proposal] 2-factor escrow agent for BTS
« on: December 11, 2014, 11:53:41 pm »
X-Post:
https://bitsharestalk.org/index.php?topic=12186.msg160885#msg160885
We should think about a extra PublicData field such that the user can define a 2fak service provider and let the wallet send the mail automatically ..
Making a transaction that way would look like this:
1) Users adds these values to the tx:
- recipient
- amount + asset
- memo
- 2fak
2) your account name requires a "2fak" field that points to your service provider
3) the wallet creates the tx and sends a BTSmail to service provider including all data from 1)
4) service provider takes the tx .. verifies your authentication via 2fakcode in the tx (or any other 2fak,, such as SMS)
5) if auth is ok .. service provider signs your tx and the tx can withdraw funds from a 2-of-4 secured address ..
optionally:
6) service proivider sends a receipt and a bill for the usage to the user
7) if user does not pay the bill the service provider just kills the private key and stops further business with the client (may be played by socket puppet .. will get more difficult with reputation on the blockchain)
wouldn't that make sense?
Who feels up to that task?
https://bitsharestalk.org/index.php?topic=12186.msg160885#msg160885
Quote
you can do escrow/multisig as greenaddress.it and the other btc service i forgot the name to is doing. It would work that way:
1) all your funds require at least 2 out of 3 or 4 signatures
2) your have 1 installed on your computer and 2 in cold storage
3) the other key is installed at a service provider
4) you want to make a transaction and sign the tx ..
5) you mail your service provider with the built-in mailing app
6) your service provider sends a SMS or does some other kind of 2 faktor authentication
7) if the authentication is successfull the service provider also signs the tx and the tx gets valid
that way you can even include 2Fak via Google Authenticator or similar. Like a
extra for when you do your transaction that holds the 2fak code ..
We should think about a extra PublicData field such that the user can define a 2fak service provider and let the wallet send the mail automatically ..
Making a transaction that way would look like this:
1) Users adds these values to the tx:
- recipient
- amount + asset
- memo
- 2fak
2) your account name requires a "2fak" field that points to your service provider
3) the wallet creates the tx and sends a BTSmail to service provider including all data from 1)
4) service provider takes the tx .. verifies your authentication via 2fakcode in the tx (or any other 2fak,, such as SMS)
5) if auth is ok .. service provider signs your tx and the tx can withdraw funds from a 2-of-4 secured address ..
optionally:
6) service proivider sends a receipt and a bill for the usage to the user
7) if user does not pay the bill the service provider just kills the private key and stops further business with the client (may be played by socket puppet .. will get more difficult with reputation on the blockchain)
wouldn't that make sense?
Who feels up to that task?
145
General Discussion / [Request Review] Python Code for PrivKey/Address Creation [ColdStorage]
« on: December 07, 2014, 11:16:27 pm »
I wrote a python script (copy-paste + modification) to get a random private key and the corresponding bts pubkey and bts address ..
https://github.com/xeroc/pytshares/blob/master/genbtskey.py
THAT CODE IS UNTESTED!!
USE WITH CAUTION!
Crosschecking results with https://bitsharestalk.org/index.php?topic=8907.msg115470#msg115470
are looking good ..
maybe there is a dev that can take a look and confirm/review the python code for correctness ..
For those not getting the reason for this script.
Suppose you want to have coldstorage ... how do you create a private key and the corresponding pubkey/address that you can fund WITHOUT installing the full client?!
I'd love to see someone code this in JS and have a offline Website like brainwallet.org for that too ...
https://github.com/xeroc/pytshares/blob/master/genbtskey.py
THAT CODE IS UNTESTED!!
USE WITH CAUTION!
Crosschecking results with https://bitsharestalk.org/index.php?topic=8907.msg115470#msg115470
are looking good ..
maybe there is a dev that can take a look and confirm/review the python code for correctness ..
For those not getting the reason for this script.
Suppose you want to have coldstorage ... how do you create a private key and the corresponding pubkey/address that you can fund WITHOUT installing the full client?!
I'd love to see someone code this in JS and have a offline Website like brainwallet.org for that too ...
146
General Discussion / MarketVolume not "fair"
« on: December 04, 2014, 08:59:00 am »
Having a forced cover after 30 days means that the whole "market cap" of N x 1bitUSD (N beeing the bitUSD supply) ... will have to trade ..
Thus .. on average .. we will have a daily volume of
SUPPLY / 30
That's nice as people take "volume" serious for trading .. but not nice as it makes it "unfair" to compare to other schemes .. say nuB.. na .. who cares
Thus .. on average .. we will have a daily volume of
SUPPLY / 30
That's nice as people take "volume" serious for trading .. but not nice as it makes it "unfair" to compare to other schemes .. say nuB.. na .. who cares
147
General Discussion / german FED .. meeting in january .. talking DACs
« on: December 02, 2014, 04:19:34 pm »
http://www.bundesbank.de/Redaktion/EN/Termine/Research_centre/2015/2015_01_29_frankfurt.html
Pls tell me we have this on the radar!
Pls tell me we have this on the radar!
149
General Discussion / bitcoinmagazine.com disaster!
« on: November 19, 2014, 01:08:53 pm »
http://bitcoinmagazine.com/18467/dacs-vs-the-corporation/
That article could have been a nice read .. wasn't it for the huge amount of non-sense about BitShares ..
Not only does the author not know how to "write" BitShares correctly, the author also doesn't seem too interested in BitShares though want's to given in overview of the DAC/DAO technologies ..
Why can't I drop a comment there?
Can we fix this?
That article could have been a nice read .. wasn't it for the huge amount of non-sense about BitShares ..
Not only does the author not know how to "write" BitShares correctly, the author also doesn't seem too interested in BitShares though want's to given in overview of the DAC/DAO technologies ..
Why can't I drop a comment there?
Can we fix this?
150
General Discussion / [Proposal] Public JSON attributes for delegates
« on: November 18, 2014, 11:57:57 am »
From the discussion in
https://bitsharestalk.org/index.php?topic=11476.0
I proposed to have a standardized (read: consensus) way of publishing auxiliary data for each delegate (read: registered account)
Taking some attributes from
https://wiki.namecoin.info/index.php?title=Identity
I'd propose to have those attributes set by delegates:
=> http://wiki.bitshares.org/index.php/Delegate/PublicData <=
Services have been initially described in:
https://bitsharestalk.org/index.php?topic=11356.msg149525#msg149525
All attribute names, descriptions aswell as the structure are made up and need
discussion. So...
Discuss!
https://bitsharestalk.org/index.php?topic=11476.0
I proposed to have a standardized (read: consensus) way of publishing auxiliary data for each delegate (read: registered account)
Taking some attributes from
https://wiki.namecoin.info/index.php?title=Identity
I'd propose to have those attributes set by delegates:
=> http://wiki.bitshares.org/index.php/Delegate/PublicData <=
Services have been initially described in:
https://bitsharestalk.org/index.php?topic=11356.msg149525#msg149525
All attribute names, descriptions aswell as the structure are made up and need
discussion. So...
Discuss!
