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

Pages: 1 2 3 [4] 5
Is that possible, or is she mistaken? She said the ad mentioned "ebites", so I it seems unlikely, plus there's been no mention of such an ad campaign here on the forum, and I expect a TV ad would be big news.

I was listening to this podcast and it touched me and moved me to post a link to it for your consideration.

The thrust of the message I want to convey can be found at time index 38:21 which you can position to by clicking on the progress bar once enough of the podcast is read & cached.

I know BM is on the same page (tho maybe a different paragraph) given what he has posted elsewhere about his desire to end violence.

General Discussion / Questions about delegates
« on: November 03, 2014, 08:23:17 pm »
In a similar vain to my BitAssets questions, I have a few about delegates I can't seem to find answers for, or don't understand the info I've found. Some of my confusion stems from the various contexts I've heard the term delegates used. And if my understanding presented below is incorrect please do let me know where I've missed the mark.

Since DPOS relies very heavily on delegates, it's a fundamental concept of the BitShares ecosystem, so everyone needs to understand them thoroughly.

1. Delegate Roles and Responsibilities

Delegates sign blocks of transactions and enter them into the blockchain ledger
The particular delegate that signs a block is chosen from the 101 in (random | round robin)? order.
This is analogous to bitcoin PoW mining, but instead of a computationally difficult task being performed by many nodes in a race, the winner of which is awarded 50/25/... BTC to sign a block, the signer of DPoS blocks are chosen from the pool of 101 delegates and rewarded with only transaction fees, which is far cheaper than the PoW process.

Q1: Does every delegate do this, or only some of the 101?
Q2: Is this signing process accomplished by just running special delegate client node software, and if so is the process fully automated? i.e. when that node is called on (out of the 101 delegate nodes) to sign a block the software does so as it runs without human intervention.   
Q3: Is it true that the only human intervention required to run a delegate node is to handle problems like hardware failures, network outages and software upgrades?

2. Delegates and Voting

Delegates are voted in / out by owners of BTS, and the strength of their vote is (proportional | directly related)? to (the number of BTS owned | size of BTS transaction the vote is submitted with)?

Is voting only accomplished when a transaction is performed? So the way to vote simply for the sake of voting would be to send BTS to yourself.

What is a "vote"?
Q1: Is it provided as information with each BTS transaction?
Q2: How is the analog / gray scale value for vote strength correlated to whether a delegate is in or out, a binary state?
Q3: If votes are provided by BTS owners with each BTS transaction, are delegates then subject to be voted in or out in real time with every transaction that takes place in the BTS ecosystem?
Q4: How is the voting calculated?
Q5: What about BTS that haven't been sold yet? i.e. if there are a total possible 10 billion BTS, but when an owner trades BTS for something 9.5 billion BTS have never been bought (marketcap of 500 million, right?), then the total voting power of all BTS in play is 500 million, right?
Q6: If 400 million BTS are (offline | in cold storage | owner destroyed his wallet / keys), then total voting power is actually only 100 million, correct?
Q7: How are the votes provided with an owner's transaction summarized over time with other owners votes they may have offered months ago, and in terms of whether a delegate "is in the top 101 delegates" and hence active in the pool, and how does an owner's voting "strength" factor into this (similar to Q4 above)?
Q8: If there were 100 million BTS in the wild, and each owner held only 1 BTS, then there are essentially 100 million votes, and everyone has the exact same voting power. In that case would the 101 delegates be chosen simply by the top 101 votes (i.e. top 101 in a histogram list)?
Q8a: histogram list of what: (transactions? Latest transactions ???)

I haven't even considered questions related to voting slates yet.

General Discussion / BitAssets and Market Pegs - What are Price Feeds?
« on: November 03, 2014, 04:57:56 pm »
Normally I'd post this in the newbie section but there isn't many eyes over there lately.

I'm trying to dig into the concept of BitAssets and really understand them. About the only thing about them I believe I do understand is the psychological basis for why a BitAsset like BitUSD trades near $1. I don't see how that holds true for other assets like gold, silver & oil where the consensus value is more volatile.

It doesn't help that my grasp on futures trading is not rock solid either. I can't seem to retain if a short is a contract you buy when you want the value to go down or if that's the "long" position. As I analyze that now my guess is that short is you want the value to go down to make a profit and long the value to rise to make a profit. So that is one basic question.

When I read the BitShares wiki entry for BitAssets the opening paragraph was enough to motivate me to write this post. Then under Initial Creation I read this:

BitAssets are created whenever a short is matched with a buyer at a price set by the median price feed which is provided by delegates.

And was further confused by not understanding what a price feed is, how the delegates set it, on what basis they do so and whether it's individually set by each delegate or some sort of cooperation or consensus is at play.

Other questions related to futures trading procedure are:
1) what do I buy BitUSD with, BTC coins, BTSX shares, or any of the above at bter btc38 or other exchanges where BitUSD is traded?
2) can I buy BitUSD in my BitShares client directly without using an exchange?
3) do I need to "put up" some bond or form of collateral to buy BitUSD, since it's value is based on trade speculation?
4) if no to #3, do I have to "put up" collateral to short or go long on BitUSD?

If you'd prefer to discuss this with me on mumble I'll be listening in backroom #3 (just drag your username from the conference hall to backroom 3), or you could respond here. I really need to get these things nailed down in my brain.


This is basically a poll, but in an open ended format. Any response is fine, links, whatever. Trying to distill the "essence" o.f BitShares according to this community of mostly true believers, but also newbies that found there way here.

Thanks for your input

General Discussion / Another Summary of the Early Oct-24-2014 Mumble
« on: October 25, 2014, 12:34:13 am »
Mumble Session Highlights

I tried to post this a few hours ago but the forum was offline.

On 10/18/2014 bytemaster started this thread: relating his initial proposal for a merger. Two days later Ander started this thread: to summarize the merger discussion as of 10/22/2014.

At the end of the mumble session today I offered to document what I perceive is the majority consensus on some of the issues, but it is by no means a comprehensive summary of all of the points discussed in the session. Gamey always does an excellent job of that. My primary objective is to help document what appears to be points of consensus concerning the proposed merger. Upon reflection and a second listen of the entire session, I don't believe I have much of a consensus to document. Nevertheless, perhaps this post may help clarify some points for someone.

Translation of Existing Stakes Into BTS Shares

From what I have seen in the forums this week, the issues around what position each stakeholder of [AGS | BTSX | DNS | PTS | VOTE | MUSIC | etc.] will have in the new BTS ecosystem constitutes the majority of the contention and concern. No surprise there.

I was quite surprised however that no discussion of this took place in the mumble session. My personal take, given the large number of forum posts discussing this is:

  • Either the majority of the community is satisfied and thus has reached a consensus
  • None of those dissatisfied were present in the mumble session
  • Those who were dissatisfied and present chose not to raise their concerns

As I think through the issues I read on the forum, I realize there are several aspects of the merger besides how a given stake will transform into BTS shares, such as how PTS will vest in BTS over time, will those vehicles continue to exist after the merger and how will they be represented on the exchanges, what market caps will be used to calculate investment values and issues about liquidity.

Since none of this was discussed at all in the mumble session, I tried to go back through the forum posts to come up with a concise position transformation formula, but I cannot, there is too many discussions and too many elements to factor in, at least for me.

Although much discussion was posted about the relative portions of AGS, BTSX, DNS & PTS etc to BTS It's not exactly clear to me when I see a statement like "7% AGS, 7% PTS, 3% VOTE, 3% DNS and 80% BTSX" what that even means. Percentage of what? If I have 1000 shares of PTS does that mean I get 70 shares of BTS? Is it a percentage of each funds market cap or of BTSX's market cap? It's very difficult to understand these discussions when so many elements are assumed or scattered on different threads.

Bytemaster was asked if DNS would be the same after the merger or if it would be a bitAsset. He said BTS would allow auctioning the domain names for bitUSD, but did not know the auction specifics.

Bytemaster also stated that PTS and AGS would not end but will continue on; they are not bought out or retired, contrary to his original proposal. Though PTS and AGS will continue to exist, he will no longer have any interest in them to divide his time and loyalties. But when asked if AGS would only be used for BTS "because they were bought out", he said yes. He also said that it's up to the shareholders of Music or Vote or other DAC team to decide whether to be a part of BTS or operate on their own separate blockchain, it wasn't his decision to make.

A summary of the current proposal should be stated for each of the entities in this ecosystem without ambiguity. Issues such as the vesting schedule and market cap should also be stated. But you'll have to wait for someone more capable than I at summarizing the forum discussions. When I asked Bytemaster  when a more formal merger description would be forthcoming he tentatively said next week.

Chinese Community

There was considerable time given to address issues from the Chinese community, as well as discussion about marketing efforts to them. Concerns were raised that individual efforts from the Chinese community were not being recognized or compensated. Bytemaster said he trusts in Bo Chen but would like to see more transparency and disclosure of how the funds he has provided are being spent.

It was stated early on in the session that we should all be aware of the language barrier and difficulty the Chinese community has in participating in the session, and to make an effort to speak more slowly. There were several people present helping with the translation in real time.

Some questions were posed by the Chinese community about the metrics for evaluating performance. Bytemaster responded by discussing what Brian Page was working on and the difficult position he is in. He related how pleased he is about the new, unified BTS and how Brian had been asking for it for quite awhile now. He said Brian's pay and that of the entire marketing staff are dependent on market cap growth, as it doubles.

They would get 10 - 20 million BTS shares if they are able to bring BTS' market cap up to match bitcoin's.
Bytemaster was asked about the model of how new developers would be added. He responded by saying anyone wishing to become a BTS developer should demonstrate their value, how they will work with the team by fixing bugs or implementing new features.  He feels it would be bad to hire someone with unproven skills.

The BTS Roadmap

After the merger a BTS marketing push slated for this December with a rebranded client, everything merged in with their vesting stake a working voting application or voting booth. IN early 2015 "KeyGraph" will be an important focus (aimed at vote validation / certification). After that the long term plan is to create a scripting app to compete with Etherium. The goal is to be able to create any other DACs without the need for continual hard forks. After that the focus will become specific appliations such as auctions and others TBA.

BTS DAC Structure

A number of questions related to the company structure and accountability to shareholders were raised, and bytemaster responded by saying the future direction would be to migrate developers into elected delegate positions and have their work rewarded by that model as opposed to being paid through I3. He emphasized that AGS funds would be invested into the growth of the BTS "superDAC" and it's staff.
When asked about revealing individual staff member pay bytemaster said they have avoided doing that to protect privacy, but salaries as a group will continue to be reported for I3.  Bytemaster said that tying delegate pay to bitUSD would be very complicated.

General Discussion / Forums seem kindof dead today...
« on: October 13, 2014, 07:21:36 pm »
This is the least amount of activity I've seen on this board since getting involved here. Is there something going on I should know about?

And on top of that there's the PTS --> DPOS-DAC changes coming up by year end. Just not sure what makes sense now. I probably should have split my BTC into both PTS and BTSX rather than only BTSX?

You thoughts on this most welcome...

General Discussion / Talk about a comprehensive project!
« on: September 24, 2014, 05:01:36 pm »
I just became of, which sounds like a blockchain 2.0 project but I haven't invested the time to check it out thoroughly yet.

The use of the word governance troubles me. Bitnation did popup on reddit too:

Technical Support / Delegate voting
« on: September 23, 2014, 09:24:23 pm »
I just put the bulk of my funds into cold storage and I noticed the delegate voting options during the transfer.

Not yet being satisfied I am informed enough to individually select delegates (let alone 101 of them!), I went ahead and selected the "let delegates decide" option (or something like that. I still get the msg "this account is not voting with all of it's stake" tho).

In my mind there's a rather big hole in our DPOS implementation that needs to be filled and that's in setting up some basic standards or guidelines for delegates and providing a central place where that info can be published. Even basic info like hardware description, ISP, UPS and the like for each delegate would be better than nothing.

I wouldn't want to lock in a set of requirements, but having a basic checklist of guidelines each delegate could publish would give people a metric to compare delegates. Another set of criteria would be operational information and run-time stats, like svk publishes on his website.

These things may have been discussed, but I haven't found such discussions if so. I'm also aware this probably isn't on the top of the priority pile, but it probably needs to be addressed before going live to general public in a big way.

It seems like every day I see web designs on the internet that look outstanding, and makes me feel like my efforts are neanderthal in comparison. But I could throw up a Joomla site with some generalized info pages about delegate voting, and a forum, guestbook or some way to for delegates to post the essentials of their "campaign platform" for the general public. Maybe even putting up polls to gauge what the BitShare community considered to be important in a delegate might provide useful input. Hell I dunno. Anyway, this may not even be worth 2 shatoshis to this community, but it's a thought that crossed my mind.

Technical Support / Latest client code
« on: September 23, 2014, 04:41:39 pm »
I've only gotten the bitshares client binaries from, but is there a better place to get them?

Reason I'm asking is I'm running version 0.4.16 and it's telling me there is a "mandatory" upgrade available, but that's what's on the download page. I haven't yet seen the "check for updates" menu selection ever work either.

The client has 9 network connections and it says the "last block was synced 1h 59m 47s ago", counted down from 9 hrs or so. It's been in that state now for going on 5 minutes. Is this normal, due to an old client version or some other problem?

Technical Support / Cold storage methodologies
« on: September 21, 2014, 07:26:51 pm »
As I gain more cryptocurrency understanding and presence on the net, I have established various accounts, wallets and balances here and there. However, I wish to protect my primary holdings in cold storage, which as I understand it is having a wallet whose primary keys and access passwords are not online.

My question is, what is the best way to go about this for BTC and BTSX?

My thought is to create a new virtual machine using Parallels or Virtualbox, install brand new wallets in it, transfer whatever primary balances I want in cold storage to the new wallets leaving whatever online balance in place in my existing wallets. Once the transfer is confirmed to the new wallets I would copy or image the partition the VM was on onto a removable USB drive and then securely wipe that partition.

Anyone care to comment on this approach or suggest others?

Technical Support / Does the X of BitSharesX stand for eXperimental?
« on: September 20, 2014, 02:44:19 am »
And is there a PTS DAC or is PTS the obsolete "ProtoShares" that have now evolved into the BTSX DAC?

What is the roadmap to going "live"? Will my BTSX shares have to be transferred to a new blockchain or will the current bc just evolve and grow as the toolkit code matures?

General Discussion / BTC address test
« on: September 16, 2014, 10:17:05 pm »
I have installed Electrum 1.9.8 and before I buy any bitcoins I want to make sure my client and address are fully operational.

Is someone willing to send me a bare minimum amount of BTC to 1FhkptEMU23KSaNrCjpJpumY5e3izqAwyB ?

I hope to be able to repay the sender with whatever he sends plus a small tip to express my gratitude, once I can make a BTC purchase which will be in process soon.

I could find a faucet, provide my email, register etc, but prefer to avoid that hassle not to mention the spam that would likely result. I can setup a new email account on my hosting service but that too is just another hassle and takes time. I thought if someone were willing to send me a bare minimum amount of BTC it would be faster.

I haven't done any transactions with BTC, so I don't know what king of real world money we're talking about in terms of fees to send 5, 10, 20 or so satoshi to a bitcoin address. Obviously if the cost is significant I wouldn't expect anyone to answer this request without some form of compensation.

I don't want anyone to send more BTC than I can get from a faucet, just to put a limit on this. If the deal I've got in the works falls through I can always repay whoever may respond to this request from proceeds I will get from a faucet.

Thanks for your consideration.

Technical Support / Security issue running client on VM
« on: September 14, 2014, 06:55:33 pm »
Not sure if this is an important issue or one being tested against, but thought I'd report it for the community's consideration.

In running the bts client on a Windows Virtualbox VM, if I suspend the VM with the bts client open and unlocked (I'm aware that's not a very smart thing to do) and resume it the next day, the client is is still open and unlocked.

It would be better if the client came up in the locked state (require password) as soon as it can detect the delta time has exceeded the lockout time threshold.

When the VM is first resumed, the clock may reflect the time it was before it was suspended, at least for a few cycles. I'm not sure that's actually the case or if the the btx app will be able to detect the gap and initiate the lockout out state.

I'm not sure if or how this could be implemented, whether it's worth looking at, or whether it's practical to resolve this. As I said, it's not very smart to suspend a VM running an open and unlocked BitShares client, but if it's possible, practical and a small cost to implement this is a security hole that would be nice to plug.

Pages: 1 2 3 [4] 5