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

Pages: [1] 2
General Discussion / Cryptofresh update, feedback
« on: June 27, 2017, 10:34:03 pm »
Just brought CF back up. As far as I can determine, a double-produced block caused issues with cf sync, which then led to an out-of-memory condition. The node just finished replaying and the site is caught up with the chain.

I'd like to start a dialogue about cryptofresh and its future. My witness has been voted out for a while so I'm maintaining (plus witness node) out of pocket, including dev hours and hardware upgrades.

IMV the witness was a convenient method of funding maintenance. I understand the desire for separation of roles, but I have experience with both so it avoided worker overhead. Would voters support a maintenance worker?

I'm also evaluating ways to continue development of cryptofresh. Here's a brief list of pending projects/todos:

 - fork handling
 - upgrading node, evaluate new APIs & check compatibility
 - upgrade server
 - improve rate bridging calcs
 - load charts faster (async generation)
 - tuning views
 - check API load/performance
 - open source
 - custom reports
 - worker caching bug

Any other issues I should know about?

General Discussion / Cryptofresh API
« on: March 30, 2016, 11:38:46 pm »

Stay tuned to this thread for notifications about API updates and potentially breaking changes.
Also feel free to use it for questions or requests!

Technical Support / cli_wallet keeps crashing
« on: March 10, 2016, 02:05:45 pm »
Last night I had to update and rebuild the node on the cryptofresh server. The witness_node and cli_wallet had been running smoothly for weeks, but now cli_wallet crashes randomly, on average maybe every 5-15 minutes.

I was getting a different error last night, one that didn't crash cli_wallet, but made it forget how to perform a 'get_object' call. I didn't save that one unfortunately. This morning, I am seeing a more cryptic error:

Code: [Select]
new >>> Server has disconnected us.
9 canceled_exception: Canceled

    th_a  thread_d.hpp:461 start_next_fiber
1297659ms th_a       wallet.cpp:787                save_wallet_file     ] saving wallet to file wallet.json
1297672ms th_a       http_api.cpp:118              on_request           ] e.to_detail_string(): 9 canceled_exception: Canceled

    th_a  thread_d.hpp:461 start_next_fiber
1297676ms th_a       http_server.cpp:123           handle_connection    ] unable to read request 9 canceled_exception: Canceled

    th_a  thread_d.hpp:461 start_next_fiber
pure virtual method called
terminate called without an active exception
./ line 1: 10592 Aborted                 ./programs/cli_wallet/cli_wallet --rpc-http-endpoint="" -s ws://

When this happens, I restart the cli_wallet, and everything works fine for another 5-10 minutes.

This is a big PITA for I'm at my wits end with this issue... any help/leads are appreciated.

I've tried the following to no avail:
 - starting with a new wallet
 - building 'bitshares' latest
 - building 2.0.160302 (failed)
 - building 2.0.160309

I've spent a lot of time on the block explorer ( since the launch of 2.0. It brings me great joy to be able to unearth some of the inner workings of Graphene and to share them with the community. Especially with the governance features, I considered it critically important to have a public frontend for voting & committee data, and that's what I built. It was low priority for the wallet, and an ideal task for the block explorer. I am particularly proud of the voting report page -- it's far from perfect but I would love to work more on this report (and others) and it's a good example of how I can transform rich yet ugly data into something beautiful. And this was just the start..

My goal for the block explorer is to provide maximum utility to the BitShares community as a whole. This is to be accomplished by (1) providing useful reports (especially governance), visualizations, and data aggregation; (2) forming a social hub and information source; and (3) serving as an educational portal while also highlighting our unique selling points.

Block Explorer

Graphene serves an endless supply of data and it's worth it to expose as much of it as possible. As more apps are built on the chain, I plan to expand the site to work with the new data streams. The block explorer serves as a prominent face of BitShares and the pages must be adjusted for wider audiences as our network grows. It will always offer things the wallets can't.. the features from many apps & wallets can be unified as one searchable portal.

Upcoming Features
  • Better assets list - add volume, price data, sorting. it should look a lot like CMC.
  • Improved asset markets - been waiting for updated APIs, which were just released!
  • Unified search - quickly look up any user, asset, transaction, or block
  • More graphs & reports - balances claimed, usage stats, fee income, etc
  • Proposals index - all past/upcoming proposed transactions (committee and otherwise)
  • Translations - to be a true hub, we need to support more languages

API Development

I've received many requests from developers for various APIs, though I haven't had time to add them all or document any. There's a big void in this space and the block explorer is perfectly poised to fill it. The API is another aspect I've held back on because it's not profitable. Yet developer-friendly API's would be a big step forward in lowering the barrier of entry to BitShares.

Graphene is a very powerful database but its minimal approach means concession of indexes and its initial API methods are a bit limiting. This block explorer uses multiple approaches to extract all the useful data efficiently and allow for queries against it. Providing public access to this data has value but running a documented endpoint comes with responsibility. So ultimately this will need to be an open-source and distributed effort (I'll author a Rails gem + minimal http API app for this worker).

Social Network

Bulletin boards and social networks on our own blockchain are something I'm particularly excited about. I've built a working MVP that allows you to publish posts on the blockchain, and I'll need your help to test it soon. Here's a sneak peek:

On this prototype you can author posts on the blockchain as well as tip posts (off-chain). It will be ready for public testing this week. This approach uses custom operations, but it supports multiple message sources--meaning it's ready to grow as a content aggregator across a variety of apps running on BitShares. It's already compatible with the "public memo" approach used by the announce feature.

Now that we have shown a minimum viable way for accounts to login and submit public messages, it opens many interesting possibilities:
  • threaded forum / message board
  • community map
  • local bitshares
  • advertising
  • job board
  • sharing of PGP keys
  • coin-weighed polls
  • reputation / feedback
  • donation-tracking pages
  • dedicated fundraiser pages
  • stores & digital downloads
  • federated social networks
  • "stack exchange" style network

A lot of these features are low-hanging fruit for the Cryptofresh platform. Any of this stuff could be integrated into the wallet or into the witness_node directly, but it's magnitudes easier to test it on our platform.


I hope that by delivering the initial block explorer features up front I've demonstrated the value and commitment I can bring.

I release my previous work on the block explorer at no cost to the community, but for the next stage I would like to go with a worker proposal. I am requesting 30,000 BTS per day from 3/1 - 5/31 to work towards the goals and priorities outlined in this document, at a rate of 20 hours per week. The pay will vest for 90 days. I will release the block explorer as open-source under MIT license when this worker has been funded in full.

Most of my work is front-end/UI-oriented, so it will be easy for you to watch the progress. I will also provide regular updates.

Witness Resignation

I would also like to take this opportunity to announce that I no longer wish to run a witness node.
Please unvote witness roadscape when you cast your vote for the worker!


Code: [Select]
create_worker roadscape "2016-03-01T00:00:00" "2016-05-31T23:59:59" 3000000000 "Blockchain Explorer and API Development" ",21532.0.html" {"type":"vesting","pay_vesting_period_days":90} false
Blockchain Explorer and API Development (1.14.33)

General Discussion / Snowdrift - MAS for freely licensed digital works
« on: February 12, 2016, 02:54:23 am »
Came across this project, they have a nice website and an interesting approach for donation matching.

"Patrons pledge to donate based on how many other patrons donate with them.
Thus, when you join, others will donate more."

The Economics of Public Goods

They had a Tilt campaign and raised $9k (goal was $3k):
Quote uses network effects to put the power back in the hands of the people instead of the platform owners. At, you become a project's patron with a monthly donation pledge: For each additional patron who gives with you, you will donate a little more (limited by the amount of funds you choose to make available to the system overall).

This way, those of us already pledged invite the rest of the world to join us. The existing patrons of a project will together match the donation from each new patron (although our exact proposal includes additional measures to accommodate varying pledge levels from different patrons).

This approach is something like the mutual assurance and reduced risk that we get from a hard threshold for a crowdfunding campaign… Except with, the mutual assurance isn't all or nothing. It's flexible, sustainable, and designed specifically for the needs of funding free/libre/open digital works.

General Discussion / [ANN] announce & announce private key
« on: January 15, 2016, 02:46:36 pm »
This is an experiment. Send a memo to 'announce' to have it published:

Import private key 5KJJNfiSyzsbHoVb81WkHHjaX2vZVQ1Fqq5wE5ro8HWXe6qNFyQ and you can read the memos from your web/cli wallet!

Or, set your memo key to BTS6fUJfBNkD88eDmoBhHGu3r98aTnieVwwqZVSzkzDaxzF57c4ce to get the same functionality on any account. Example:

General Discussion / BTS voting initiative
« on: December 04, 2015, 08:37:35 pm »
I don't recall seeing a thread dedicated to discussing how to get more BTS stake voting.

It's important (or rather critical) for our security and as of today we have only 18% of stake voting.

Here is a tool to help the discussion:

(It's definitely not "done" but thought I'd share it sooner than later. I'm aware of several issues, just haven't been able to address them. Also there are many possible improvements)

 - Why aren't you voting?
 - What do we do about the exchanges?
 - What's our goal?

General Discussion / Let's Talk Bitcoin! #260 - New Growth
« on: November 01, 2015, 12:41:45 am »
Adam sits down with Daniel Larimer, leader of the Bitshares project. They talk about the new release, the lessons learned over the last nearly three years and what comes next.

Only halfway through.. great discussion so far. Great primer for anyone looking to catch up on recent developments!

General Discussion / Cryptofresh Block Explorer + MUSE now available
« on: October 26, 2015, 08:35:39 pm »
Started building this as a debugging tool, and it's turning into something more interesting.
It's a little rough around the edges, but we thought you might enjoy a preview:

Nowhere near ready for production but certainly better than our "down for maintenance" page :)

The store will be back in due time, with some other fun features.


BTS Block Explorer:
MUSE Block Explorer:

1) Is it possible to have non-encrypted memos? Can an account be configured to receive only public memos?

2a) What's the format of vote_ids? 0:11, 1:27, 2:65, etc. Does each votable object have a unique vote_id? Is the first number a namespace and second number an incrementing id?

2b) Is there a method to get a list of accounts that specify a specific proxy? (And each account can only specify one proxy right?)

3) Is it in any way possible to implement a key-value store in the current version of Graphene?

Thanks :)

I want to build a tool that will strip a 0.9.3c export file of empty balance keys, as I understand this is the primary cause of slow imports.

The first thing I did was to pre-process the 2.0 genesis file and put each unique key on its own line.
There are 4 types of public keys: account-owner, account-active, balance, and vesting balance.

By my count, there is a total of 250,084 unique keys in the genesis file.

Here's a sample of the processed output:
Code: [Select]
BTS7w6nraWnLP2vvXhZJoiNw23ZzwZQpYe6EDQ86X4W4q9vRVSkKb pptall1 (active key) (lifetime)
BTS7w6nraWnLP2vvXhZJoiNw23ZzwZQpYe6EDQ86X4W4q9vRVSkKb pptall1 (owner key) (lifetime)
BTS5aR1DMjc1YLi82S1dUSxvUrxpuf52mKKEHF4H6EJr8YJxv6ZRk itunes (active key)
BTS5aR1DMjc1YLi82S1dUSxvUrxpuf52mKKEHF4H6EJr8YJxv6ZRk itunes (owner key)
BTS7N9L3mXEcyS5kBeYovZMjTAFVMNDY8e737jg2T6xa9x4YfKyDB qfhtw (active key) (lifetime)
BTS7N9L3mXEcyS5kBeYovZMjTAFVMNDY8e737jg2T6xa9x4YfKyDB qfhtw (owner key) (lifetime)
BTS8KeeWrZNMVksJFk4xW8EzMbfJxSG4WKMHKxeu9ghcQVenDdD3Y lfj (active key)
BTS8KeeWrZNMVksJFk4xW8EzMbfJxSG4WKMHKxeu9ghcQVenDdD3Y lfj (owner key)
BTS6sgieE6Hp1MHfX8xj3m4gQSai1ZYbwpSKLUuUyB145WQD9s1d1 asusa (active key) (lifetime)
BTS6sgieE6Hp1MHfX8xj3m4gQSai1ZYbwpSKLUuUyB145WQD9s1d1 asusa (owner key) (lifetime)
BTS84xPPonkZcssdD3CK4Ga6Uk878MEyybzAJnnVLBEvz67H18xRV lhb (active key)
BTS84xPPonkZcssdD3CK4Ga6Uk878MEyybzAJnnVLBEvz67H18xRV lhb (owner key)
BTS6AuyvQxZihktvkfY5Quazg27nu8uHRBedmUiPB9sn13M7ngDSV daniellarimer (active key)
BTS6AuyvQxZihktvkfY5Quazg27nu8uHRBedmUiPB9sn13M7ngDSV daniellarimer (owner key)
BTS1DabHAHdQeXFre6PC2YYGeayhuKuniVF 139895643 BTS
BTS1Dny3PirXmuRAMEWVi34fSsRWQpK7LZk 490645755 BTS
BTS1EFYgopx2r2zb9rzMAxtnfGn4GbPmpAa 21084 BTS
BTS1GFnzJf9q1QxegMufbHeWbRWD1mGXWdi 7070002 BTS
BTS1HMKhb6m9iHUKEUDTFdgxVSsgrsALwoQ 10000 BTS
BTS1JoujPuh25UY54dMqwSWVh46aEAE8gwi 4 CNY
BTS1Kkovbwo6eHxqxcrAxcMHotjUq5orGvQ 100000 BTS
BTS1KossAtqDrMc6NSX1EnCUbz9X5nnX93v 1 USD
BTS1Lc1y6bfwWzy2BvXTBLwEUyevK1Xh7Uh 1 CNY
BTS1M9qUwuJLt8ziqpkx4wgPaoWofQu1jmd 8459 BTS
BTSQEfUxEonuTvMzQ1Dju99SWVp6UisfUdQs 71656 BTS (vesting)
BTSQEiSzJERXqeCxbyy43sGdDr7fVRnQrWNx 6686334 BTS (vesting)
BTSQEigNwanoeCh7Gf4yErCaEAapG39KnJo2 9541 BTS (vesting)
BTSQEmYusBAvVFy6raYMYk51Pdd7GsaQzjpe 116821 BTS (vesting)
BTSQEo58CfiShWNWjAfyo5LE5uyBKgsQWgAq 321730 BTS (vesting)
BTSQEoQVa7LBaHLjSRRMaCZSRxmyV6U1iRh1 3892856327 BTS (vesting)
BTSQEpuL3mZR5jRSeYDvGb7iBZdXH42M2wCm 14952 BTS (vesting)
BTSQEq1uTzTb8hugonsGhugCo2T2vmq5QzdG 3574773 BTS (vesting)
BTSQEsL8W7oGQPExWDzc1EqDS6qKtVkKEZ1M 12998 BTS (vesting)

The next step is to parse the keys.json file and check what matches or doesn't.

I'm getting positive matches on account keys, but not balances.
So it seems the balance key format is different between the genesis and the export file.

Could someone explain the difference in formats and help me convert one to the other?

General Discussion / Cryptofresh & BitShares Road Trip Video Release
« on: October 15, 2015, 09:01:05 pm »
The delegate pay model introduced in BitShares 0.4.24 was revolutionary, and we’re proud to
have been part of such a bold experiment. Thank you all for the opportunity and support.

Here’s a recap of some of our initiatives over our 7 months as BitShares delegates:

With the launch of the new chain, we are refining our approach and consolidating brands. We’ll
use cryptofresh as our platform for BitShares-related projects. We took the store down to update
it for 2.0 and will post another announcement when the new site launches.

As creative opportunities unfold in the following months, we’ll explore all our funding options
for further projects: the referral program, worker proposals, external funding, and crowdfunding.

With that said, enjoy our first video...

General Discussion / Peertracks featured in Billboard magazine!
« on: August 06, 2015, 05:08:34 am »

PeerTracks hopes to garner marketing dollars -- it aims to stay ad-free for users -- through "artist tokens," a concept comparable to baseball cards. Consider it A&R, gamified. Every artist on PeerTracks can create their own token, bearing their face and name. The artist sets the amount of available tokens. "Since it is limited edition," Cobban explains, "once you create your tokens, you can't create more." The idea is to create a type of sub-cryptocurrency, the valuation of which directly reflects the appeal of an artist.

Just like the real world, the valuation of PeerTracks tokens is determined by supply and demand. Tastemakers can buy tokens of unknown artists while they are cheap, speculating on that creator's future potential. "Boom! Your incentives have been magically aligned with that of the artist," Cobban explains. "You now want that artist discovered, you want him to sell music. You want him to be streamed and sell merchandise, because your tokens can go up in value as that artist becomes more successful."

Brainstorming Faucets, Funnels, and Referrals in 2.0

BitShares is different from other chains because it requires the use of a faucet to get started. Faucets as we know them today are merely registration forms, but they will play a bigger role when the referral system is launched. It’s not yet clear how all of this will work in Graphene, but I’d like to share some ideas of what might be possible. 

Ease of use

We lose referrals because the current faucet system is inconvenient. To take full advantage of the referral program, we should streamline the current faucet system without losing its flexibility.

Ideally, users would start at the faucet and then go to the web wallet. No hopping back and forth.

Instead of website→wallet→faucet→wallet I’d like to see just faucet→wallet. More on this below.

Cross-compatible wallets & faucets

CCEDK, BANX, and BunkerDEX will run their own skinned BitShares web wallet. We may have 'stock' wallets similar to And we’ll have 3rd-party wallets like Moonstone.

The idea is for wallets to remain compatible so users are not locked in.
You should always be able to migrate to any wallet/provider at will (to paraphrase BM).

Could we make faucets and wallets completely interchangeable yet seamless?
For service providers, this would make A/B testing trivial. And they could take it to the next level by leveraging free market forces via the power of independent marketers/developers.

Every user on the chain only needs to interact with a faucet once.
Marketers will compete to reach various market segments first.
If marketers have powerful tools, we’ll have a very healthy race.

Faucet variants
  • Invite-only faucet
    • Generate invite codes for printing/emailing. Perfect for meetups.
    • "Create a free account at & enter code RTYSDTF to claim your 5 BitUSD".
    • A benefit of this approach is that no email verification is required.
    • Valentine explored a similar approach last year, but 2.0 changes things.
  • Skinnable faucets
    • Allow marketers to easily create highly-targeted funnels for different markets
    • We could have endless user-generated keyword-rich signup pages.
    • Anyone with basic HTML skills could create single-page funnel-faucets.
  • Tipbot faucet:
    • Receive a tip on social media.
    • To claim it, you verify your login and create/link a BTS account.
    • If the user does not yet have a BTS account, they create one
      • Tip-sender and tip-bot split the referral income
    • Great way to incentivize tipping
  • LocalBitShares faucet/service:
    • We need P2P on/off-ramps, this would be great for grassroots efforts.
    • You can register and guide first-time BTS buyers
  • Ad-supported faucet:
    • e.g. Allows you to register a premium name if you complete an offer
    • Doubt there would be much interest in this, but it’s interesting nonetheless
  • Plain faucets
    • Probably what most built-in wallet faucets will look like. (CCEDK, BANX, etc)
    • It would have to use either email or social sign-in, to prevent abuse
    • Example:

Example: emailable/printable invite code faucet

Something like this would be *perfect* for meetups. The basic flow:
  • You get a an invite code for 5 BitUSD (via email, meetup, etc)
  • Go to, type in the redemption code
  • Select an account name
  • Choose your wallet (CCEDK, BunkerDEX, etc)
  • You are redirected to the chosen wallet
  • Initialize your wallet, set your password
  • Within seconds, your account shows up with a balance of $5

The same scenario, from a more technical standpoint:
  • Marketer goes to and prints an "invite coupon" for 5 BitUSD
  • Receiver of voucher (new user) goes to, types in the redemption code
  • Faucet guides the user in picking an account name
    • Why? The faucet allows the user to dip into their $5 credit to register a premium name
  • User selects which wallet they would like to use (CCEDK, BunkerDEX, etc)
  • User is redirected to their chosen wallet
    • in the URL are 2 parameters: account_name and faucet_callback_url
  • Wallet guides user through wallet creation (password, recovery key, etc)
  • Wallet adds the (still unregistered) account_name
  • Wallet makes a backend call to faucet_callback_url with account_name, account_key, owner_key
    • Faucet registers the account, and
    • transfers the coupon balance to it
  • Done. Account is registered and has a balance of $5.
This is just one way to implement it, but it’s very secure because it does not require users to reveal/migrate their private keys nor for the faucets to be https.


There’s plenty more to cover but I wanted to share my thoughts and start a discussion. I'd love to start coding something (perhaps the invite faucet or tipbot faucet), but there's a lot of unknowns. I'm sure others are in a similar position.

Developers: Are you willing to implement the basic functionality into the web wallet that would make these faucets possible?
Marketers: How do you want to use faucets? What are your plans for 2.0? What tools would help you?

The possibilities of DPOS2 and the referral system are almost overwhelming. Let’s map it out and narrow it down!

General Discussion / "Keyhotee" Identity Management in 2.0
« on: June 30, 2015, 08:54:58 pm »
From what I understand, BitShares effectively replaced Keyhotee.

Is identity management still a core use case in 2.0?
Will we have BitShares Login going forward?

Neither of those are mentioned on the new site:

Hope it's just an oversight :)

Pages: [1] 2