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.


Topics - maqifrnswa

Pages: 1 [2] 3
16
Summary: Raspberry Pi (RPI) and other single-board-computers (SBCs) could be good platforms for distributed, low-power, low-cost witness nodes in BitShares2.0. A convenient way of getting BiShares2.0 on RPIs, especially for those just learning RPI or BitShares, will aid adoption and help the network. This project is looking at ways to simplify access to BitShares2.0 through RPI disk images and repositories.

For CubieBox and archlinux, see https://bitsharestalk.org/index.php/topic,17297.msg220456.html#msg220456


Three ways to get it:

1) Download our Raspbian Jessie minimal server preconfigured for graphene and will update graphene when you run "apt-get update && apt-get upgrade":
https://www.dropbox.com/s/qzeeqnhbngoqo99/20150814_bitshares_raspbian.zip?dl=0
Code: [Select]
$ md5sum 20150814_bitshares_raspbian.zip
9bad200938d32531f5f0c341e5ea482e  20150814_bitshares_raspbian.zip
See "SD card image based on Raspbian Jessie is available for initial testing" below.

OR

2) Download a Raspbian Jessie distribution (such as http://sirlagz.net/2013/07/19/raspbian-server-edition-2-5/) then follow the instructions for "Rapsbian Jessie PPA" below.

OR

3) Upgrade your Raspbian Wheezy to Jessie and then follow the instructions for "Rapsbian Jessie PPA" below:
a) Download and install Raspbian (https://www.raspberrypi.org/documentation/installation/installing-images/README.md)
b) Make sure you're up to date
Code: [Select]
apt-get update
apt-get upgrade
c) Optionally remove packages you don't need to speed up the upgrade (e.g., if you're a server and don't care about -dev packages)
Code: [Select]
apt-get remove  --auto-remove --purge libx11-.* .*-devd) Upgrade to Jessie
Code: [Select]
sed -i 's/wheezy/jessie/g' /etc/apt/sources.list
find /etc/apt/sources.list.d -type f -exec sed -i -e 's/wheezy/jessie/g' {} \;
apt-get update
apt-get dist-upgrade -o Dpkg::Options::="--force-confold"
e) Follow the steps for "Rapsbian Jessie PPA" below

OR

Undocumented, untested 4th way: apt-pin so that you can install packages from Jessie if they are missing from wheezy.

Rapsbian Jessie PPA:

As super user or root, grab the archive key and add the repository
Code: [Select]
sudo wget -O - http://people.debian.org/~showard/raspbian/bitshares_repo.gpg.key | sudo apt-key add -
sudo sh -c 'echo "deb  http://people.debian.org/~showard/raspbian/ jessie main bitshares\ndeb-src http://people.debian.org/~showard/raspbian/ jessie main bitshares" > /etc/apt/sources.list.d/bitshares.list'

Install graphene
Code: [Select]
apt-get update
apt-get install graphene

4) you now have two new binaries to use, "witness_node" and "cli_wallet"



SD card image based on Raspbian Jessie is available for initial testing.

disk image resize doesn't work, but you still have 500 MB to work with for testing

Please test the image and be a pioneer!
What you need:
  • a RPI or RPI2
  • an SD card > 2.2 GB
  • a connection to the internet for the RPI
  • another computer on your network to log in to the RPI, or a monitor and keyboard to log in to the RPI

Step one:
Download the image from the link at the top of the post

Step two:
Follow the instructions on how to install the downloaded image on an SD card. Depending on your OS, you can find instructions here:
https://www.raspberrypi.org/documentation/installation/installing-images/README.md

Step three:
a) ADVANCED: Plug in your RPI to your network and plug in to power. If you know how to do SSH already, and know how to find the RPI's IP address, you can just log in with the user name "pi" and "raspberry" as the password. Go to step four.
b) BEGINNER: Plug in a a keyboard and monitor to the RPI. Plug in your RPI to your network, then plug in to power.
Login with the following information when prompted:
Username: pi
Password: raspberry

then type
Code: [Select]
ifconfig in to the terminal

write down the INET address of eth0, should look like:
Code: [Select]
inet addr:192.168.1.2 or something like that.

you can type "exit" to return to the log in screen. You don't need the keyboard or mouse any more.

Step four:
Log in to the RPI using another computer on your network:
linux/macosx (use the inet address from above)
Code: [Select]
ssh pi@192.168.1.2windows (use the inet address from above)
https://www.raspberrypi.org/documentation/remote-access/ssh/windows.md

Step five:
Change your password:
ADVANCED: https://www.raspberrypi.org/documentation/linux/usage/users.md
BEGINNER:
1) type "sudo rasp-config" in to the terminal
2) choose "Change User Password" and follow the prompts

Step six (might not work at the moment, and is optional):
Expand your disk so you can use the whole thing:
1) type "sudo rasp-config" in to the terminal
2) choose "Expand Filesystem" and follow the prompts

step seven:
Check out bitshares.
To make sure you're running the latest graphene:
Code: [Select]
apt-get update
apt-get upgrade
[/quote]
"witness_node" and "cli_wallet" are both in the PATH - so just type those commands and it will work
See https://github.com/cryptonomex/graphene
on how to use them for now

step eight:
update with "apt-get update" then "apt-get upgrade". If I put a new version online, it will pull in the new version without having to get a new image

17
Technical Support / Graphene and secp256k1-zkp
« on: June 23, 2015, 09:39:00 pm »
I see that the secp256k1-zkp library has configuration options hard coded instead of using the ./configure script:
https://github.com/cryptonomex/fc/blob/master/CMakeLists.txt
https://github.com/ElementsProject/secp256k1-zkp

That is causes build errors on some systems:
In file included from /home/pi/graphene/graphene/libraries/fc/vendor/secp256k1-zkp/src/secp256k1.c:11:0:
/home/pi/graphene/graphene/libraries/fc/vendor/secp256k1-zkp/src/util.h:102:37: error: ‘__int128’ is not supported for this target
 SECP256K1_GNUC_EXT typedef unsigned __int128 uint128_t;

since not all architectures have __int128

just running ./autogen.sh and ./configure then make works in that folder, but the fc cmake build does not work

I know it's early and it's probably just set up for testing at this point, but I wanted to give a heads up.

18
Technical Support / purpose of LC_ALL="en_US.UTF-8"
« on: April 29, 2015, 02:58:09 pm »
I just wanted to check the purpose of:
https://github.com/BitShares/bitshares/commit/b0efbee1b6d96f07b04788d9df85b7bd9161239d

Is it required for make, but not for regular use? Why is it required for make? thanks

19
EDIT!:: See posts below, debugging figured things out - it's a 32bit problem

I'm trying wallet_regenerate_keys on an account in a wallet, but it keeps crashing. Any hints? Redacted error below:

Code: [Select]
>>> wallet_regenerate_keys XXX 10500
Backing up wallet...
Wallet automatically backed up to: XXX-before_key_regeneration.json
This may take a while...
Regenerating wallet child keys and importing into account: XXX
10 assert_exception: Assert Exception
*account_name == account_record->name: That key already belongs to a local account with a different name!
    {"account_record":{"index":X,"id":X,"name":"[b]NOT THE NAME I'M REGENERATING[/b]","public_data":null,"owner_key":"XXX","active_key_history":[["XXX"]],"registration_date":"XXX","last_update":"XXX","delegate_info":null,"meta_data":{"type":"public_account","data":""},"is_my_account":true,"approved":0,"is_favorite":true,"block_production_enabled":false,"last_used_gen_sequence":0,"private_data":null},"account_name":"[b]THE NAME I'M REGENERATING[/b]"}
    th_a  wallet.cpp:1667 import_private_key

    {"account_name":"[b]THE NAME I'M REGENERATING[/b]","create_account":false}
    th_a  wallet.cpp:1689 import_private_key
10 assert_exception: Assert Exception
*account_name == blockchain_account_record->name: That key already belongs to a registered account with a different name!
    {"blockchain_account_record":{"id":X,"name":"[b]ANOTHER DIFFERENT NAME[/b]","public_data":{"version":"0.8.1","slate_id":X},"owner_key":"XXX","active_key_history":[["XXX"]],"registration_date":"X","last_update":"X","delegate_info":{"votes_for":XXX,"pay_rate":X,"signing_key_history":[[XXX],"last_block_num_produced":XXX,"next_secret_hash":"XXX","pay_balance":XXX,"total_paid":XXX,"total_burned":X,"blocks_produced":XXX,"blocks_missed":XXX},"meta_data":{"type":"titan_account","data":""}},"account_name":"[b]THE NAME I'M REGENERATING[/b]"}
    th_a  wallet.cpp:1631 import_private_key

    {"account_name":"[b]THE NAME I'M REGENERATING[/b]","create_account":false}
    th_a  wallet.cpp:1689 import_private_key
10 assert_exception: Assert Exception
*account_name == account_record->name: That key already belongs to a local account with a different name!
    {"account_record":{"index":X,"id":XX,"name":"[b]YET ANOTHER DIFFERENT NAME[/b]","public_data":{"gravatarID":""},"owner_key":"XXX","active_key_history":[["XXXX"]],"registration_date":"X","last_update":"X","delegate_info":null,"meta_data":{"type":"titan_account","data":""},"is_my_account":true,"approved":0,"is_favorite":true,"block_production_enabled":false,"last_used_gen_sequence":X,"private_data":null},"account_name":"[b]THE NAME I'M REGENERATING[/b]"}
    th_a  wallet.cpp:1667 import_private_key

    {"account_name":"[b]THE NAME I'M REGENERATING[/b]","create_account":false}
    th_a  wallet.cpp:1689 import_private_key
Segmentation fault (core dumped)

20
General Discussion / New SEC rules for small business securities sales
« on: March 30, 2015, 09:18:03 pm »
http://www.sec.gov/news/pressrelease/2015-49.html
http://www.coindesk.com/sec-crowdfunding-ruling-revolutionary/

no longer need to only sell to qualified investors, eases rules for selling securities. Probably not related to bitshares directly, although someone could list registered securities on bitshares (but then would the bitshares network need to be registered as an exchange?)

21
Update: going to be busy again for a while won't have enough time to properly devote to this post's effort. Will revisit in future.

22
Technical Support / 0.4.23.1 comiling error (libraries/cli/pretty.cpp)
« on: October 30, 2014, 04:02:59 pm »
Got this while trying to build the most recent release:

Code: [Select]
/home/showard/bitcoin/bitsharesx/libraries/cli/pretty.cpp: In function ‘std::string bts::cli::pretty_timestamp(const fc::time_point_sec&)’:
/home/showard/bitcoin/bitsharesx/libraries/cli/pretty.cpp:29:36: error: ‘const class fc::time_point_sec’ has no member named ‘to_iso_extended_string’
       return "<d-ign>" + timestamp.to_iso_extended_string() + "</d-ign>";
                                    ^
/home/showard/bitcoin/bitsharesx/libraries/cli/pretty.cpp:30:22: error: ‘const class fc::time_point_sec’ has no member named ‘to_iso_extended_string’
     return timestamp.to_iso_extended_string();

23
Technical Support / build bitsharesx without internet connect?
« on: October 18, 2014, 10:32:38 pm »
Is there a way to build bitsharesx without an internet connect? Can I give someone a single .tar.gz that they can then build? Right now the node stuff requires you to do a "node install" which requires internet access (and potential security breach, imagine a redirect attack if you could compromise a build server's DNS).

Can all that node stuff be done before distributing? I'm trying that, but that requires using cmake - and once i've done that I've locked in to a single architecture. I can't do that on an i386 machine, make a tarball, and hand it to an amd64 machine (it can't find needed libraries). If I delete all the cmake files, it finds the libraries but then can't find resources needed for htdocs/ and qt_wallet.

This is something I'm exploring for secure distribution of binaries.

24
Technical Support / BitSharesX compiling: do out of tree builds work?
« on: September 22, 2014, 12:33:28 pm »
I'm trying to do an out-of-tree build:
Code: [Select]
mkdir -p obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None -DINCLUDE_QT_WALLET=ON -DCMAKE_INSTALL_PREFIX=/usr/bi

But get:
make[3]: *** No rule to make target `programs/qt_wallet/images/splash_screen.jpg', needed by `programs/qt_wallet/qrc_bitshares.cpp'.  Stop.

and programs/qt_wallet/images/splash_screen.jpg is found in tree but not in:
obj-x86_64-linux-gnu/programs/qt_wallet/images/splash_screen.jpg

thanks

25
Technical Support / 0.4.16-RC2 BitSharesX crash on startup, Ubuntu 14.04
« on: September 20, 2014, 02:37:05 pm »
ubuntu 14.04
bitshares_client works fine, reindexes and connects to network.

BitSharesX crashes:
Code: [Select]
$ ./programs/qt_wallet/bin/BitSharesX
terminate called after throwing an instance of 'fc::assert_exception'
Aborted (core dumped)

gdb backtrace:
Code: [Select]
#0  0xb7fdd424 in __kernel_vsyscall ()
#1  0xb48e2577 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xb48e59a3 in __GI_abort () at abort.c:89
#3  0xb4b14595 in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/i386-linux-gnu/libstdc++.so.6
#4  0xb4b121f3 in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#5  0xb4b1222f in std::terminate() ()
   from /usr/lib/i386-linux-gnu/libstdc++.so.6
#6  0xb4b124f5 in __cxa_rethrow () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#7  0x083c4e0b in bts::blockchain::address::is_valid (base58str=...)
    at /home/showard/bitcoin/bitsharesx/libraries/blockchain/address.cpp:42
#8  0x083c4f2f in bts::blockchain::address::address (this=0xbfffef5c,
    base58str=...)
    at /home/showard/bitcoin/bitsharesx/libraries/blockchain/address.cpp:13
#9  0x08203caf in __static_initialization_and_destruction_0 (__initialize_p=1,
    __priority=65535)
    at /home/showard/bitcoin/bitsharesx/programs/qt_wallet/WebUpdates.hpp:14
#10 _GLOBAL__sub_I__ZN10MainWindowC2Ev ()
    at /home/showard/bitcoin/bitsharesx/programs/qt_wallet/MainWindow.cpp:935
#11 0x08b65f02 in __libc_csu_init ()
#12 0xb48cda1a in __libc_start_main (main=0x8203c00 <main(int, char**)>,
    argc=1, argv=0xbffff054, init=0x8b65eb0 <__libc_csu_init>,
---Type <return> to continue, or q <return> to quit---
    fini=0x8b65f20 <__libc_csu_fini>, rtld_fini=0xb7fed180 <_dl_fini>,
    stack_end=0xbffff04c) at libc-start.c:246
#13 0x08207200 in _start ()

26
Now that feeds are important, delegates have to pay 0.5BTSX periodically throughout the day for each currency.

The average delegate is making 85.5 * 2.3 * .86 =169.2 BTSX per day. My delegate is making 29.5 BTSX per day, which is enough to pay for the server. However, if the network needs accurate feeds for BTC, CNY, USD (1.5BTSX per feed update), I'll have to operate at a loss. I set my pay rate not knowing about this expense (and to my own fault, I assumed the pay rate market would be free).

This becomes prohibitive if more feeds are required.

Would either of these be possible? (For now I'll just override the minimum fee)

27
Many here are technically inclined, but not necessarily financially experienced. Right now bitsharesx is still in its infancy, and as such has small liquidity. That creates an opportunity for profit by arbitrage. Such profit also injects liquidity - so it's a win-win.

Here are two quick ways you can participate:
1) Inter-exchange arbitrage If you know the "true" market rate for BTSX in dollars (e.g., from coinmarketcap/bter/btc38 prices), you can trade the spread between such a "true" price and the price trading for BTSX:USD in bitsharesx:
fill in the gaps...

Code: [Select]
while True:
    time.sleep(2)
    new_price = get_true_price()
    sec_since_update += 2
    if abs(new_price - last_price) / last_price > (SPREAD / 3):
        log("Price moved  -  old:  %f   new:  %f" % (last_price, new_price))
        log("Seconds since previous update:  %d" % sec_since_update)

        client.cancel_all_orders("USD", SYMBOL)
        client.wait_for_block()
        usd_balance = client.get_balance("USD")
        btsx_balance = client.get_balance(SYMBOL)
        client.submit_bid(0.3*(usd_balance * new_price), SYMBOL, new_price * (1+SPREAD), "USD")
        client.submit_ask(0.3*btsx_balance, SYMBOL, new_price * (1-SPREAD), "USD")
        last_price = new_price

2) Three-legged arbitrage If you can trade BTSX:BitUSD (bitsharesx), BitUSD:BTC (https://bter.com/trade/btc_bitusd), and BTC:BTSX (https://bter.com/trade/BTSX_BTC), you can use arbitrage to generate more coins if the exchange rates are not "correct":
right now (1400 UTC 2014-08-27) if I start with 1 BTSX and convert it to BTC then BITUSD then back to BTSX I end up with
1* 0.0000710 BTC/BTSX * 551.00 BitUSD/BTC * 26.698008 BTSX/USD = 1.044452771
That means if there are no fees, and I just buy one BTC then use that to buy BitUSD thenuse that to buy BTSX, and I end up with 4% more BTSX then I started with, free money.

3) Discount trading just check this out, and act accordingly:
https://bter.com/trade/BITUSD_USD

28
General Discussion / Introduction to how fees work in BitsharesX
« on: August 05, 2014, 03:56:23 pm »
There seems to be some confusion over how fees work, so I think it could be a good to describe it in one place. If it is already explained somewhere, please let me know and I can put a link in place of this post! NOTE: the numbers are not consistent since I pulled them across different blocks, but they are close. Also, these are the fees as of 8/5/2014. They may change.

When you perform a blockchain operation (e.g., register an account or register an asset), you pay fees. Before paying the delegate, your feels are added to a running total of fees to be paid out. You can see the total running fees that still have to be paid out here:
"blockchain_accumulated_fees": "122,421.75559 BTSX"

Once the fees are added to "blockchain_accumulated_fees", the delegate producing a block will get paid the following fee:
blockchain_delegate_pay_rate=specific_delegate_percentage_pay_rate * blockchain_delegate_pay_rate
where
blockchain_delegate_pay_rate = blockchain_accumulated_fees/(number_of_blocks_produced_in_two_weeks)

the rest of the fees are destroyed and blockchain_delegate_pay_rate is the pay rate when a delegate has a 100% pay rate. This smooths out large investments such as registering assets. The current maximum pay, that is when a delegate as a 100% pay rate, can be seen with the console command get_info:
"blockchain_delegate_pay_rate": "1.01193 BTSX"

Delegate registration fees
are equal to:
(blockchain_delegate_pay_rate * number_of_blocks_produced_in_two_hours)/number_of_delegates

That means that a delegate breaks even if they are a delegate for two hours with 100% pay rate.

This can be seen with "blockchain_get_info" console command:
"delegate_reg_fee": "7.20891 BTSX"

Asset registration fees are based on the total fees delegates should receive over a two week time, which (at this moment) is the same as "blockchain_accumulated_fees" and can be seen with the command "blockchain_get_info":
"asset_reg_fee": "122,320.80000 BTSX"

Hopefully this clears up some of the misconceptions and helps the discussion going forward!

29
There is a weird game theory thing happening with delegate payrates, by preventing delegates from raising rates you risk damaging network coverage.

Current Rules:
1) You are allowed to lower, but not increase fees
2) Once elected a delegate, you remain one until votes decrease to eliminate you.

Market forces:
1) BTSX price and BTC are volatile, as is daily fees earned
2) there are fixed expenses (for the most part) for running a node/delegate
3) People are bidding on fees, lowest bids should, in theory win.

Outcome:
1) Delegates bid such that they make a profit
2a) If BTSX increases in value, they can decrease to stay competitive in the market
2b) If BTSX decreases in value, there is no ability to increase fees to stay competitive. The delegate will turn off their machine since income is less than cost. Voting response is slow. Network yield is hurt.

I currently am only running 1 delegate, at 15%, and am providing services to the community (maintaining an ubuntu PPA, bug reporting/testing/validation). Others are running 5 nodes at 100%. That's fine, I don't mind only running one delegate since I believe in decentralization - but now that BTSX is slipping I see I'm stuck with the choice of losing money or hurting the system. I'm going to keep it running, but others in my situation will hurt the system.

Could there be a mechanism by which delegates increase their fee? perhaps they declare a fee change and have to wait x number of days before it is implemented so voters can vote them out if they think it is unfair?

30
General Discussion / Ubuntu BitShares PPA
« on: July 23, 2014, 10:19:21 pm »
Hello all, to make it easier for people, this is all you need to install bitshares:

Code: [Select]
$ sudo apt-add-repository ppa:showard314/bitshares
$ sudo apt-get update
$ sudo apt-get install bitshares

If you want the command line interface only (CLI, e.g. if you are running a headless server):
Code: [Select]
$ sudo apt-get install bitshares-cliinstead of
Code: [Select]
$ sudo apt-get install bitshares
You will then have a bitshares icon in your application search (dash) or from command line:
Code: [Select]
$ BitSharesand/or the CLI:
Code: [Select]
$ bitshares_client
all the utilities are installed as well, but if they're not needed I can cut them out for space later.

Service of:
https://bitsharestalk.org/index.php?topic=5938
15% delegate: wallet_approve_delegate maqifrnswa
50% delegate: wallet_approve_delegate delegate1.maqifrnswa
(I have two since we're not allowed to raise payrates to remain competitive in the market, which I mistakenly did not know when I made the first one)

Please post bugs/problems here.

Note:
Since there are no such thing as "official" binaries any more [1], the PPA is as official as you can get. They were uploaded by a delegate, the source code used to build the packages is signed with a GPG key in the debian-keyring and is inspectable on the launchpad site. The binaries built from the GPG code are signed by with the PPA key and will be verified by apt when you download and install. This is the same system bitcoin uses for distribution, as well as mozilla, libreoffice, wine, and several others.

[1] https://bitsharestalk.org/index.php?topic=7067.msg148186#msg148186

Pages: 1 [2] 3