BitShares Loves Puppies

[Nxtblg]

[1714228294]

1714228294

[1714228294]

1714228294

[StanLarimer]

I knew NXT champions would eventually come to their senses.  This is a great start! 

[StanLarimer]

I ran across a new BitShares delegate proposal that I thought I would share with you.
I have no idea whether this individual will get elected (it's very competitive),
but this is certainly a well done proposal.

I bet there are a lot more of you out there who could write a proposal like this.
Why not give it a shot?

Hi!

tl;dr: I'm a professional software developer with 15+ years of experience and I'd like to work on the client and take some load off the core team. Please vote for me:

Code:

wallet_approve_delegate dev-pc.bitcube true

.

Delegate proposal website: http://bts.quisquis.de/delegate/proposal.html


BitShares Delegate Proposal

My name is Peter Conrad and I propose to create a delegate for funding my work. Please support my proposal and vote for me:

Code:

wallet_approve_delegate dev-pc.bitcube true

A. What I have to offer

I'm a freelance software developer and I would like to offer my expertise to the BitShares DAC. Read up on my professional background if you like. As you can see ;-) I'm not a GUI type. My preference is backend programming, network interfaces and console stuff.

I have done most of the backend work for porting PTS to PTS-DPOS. PTS-DPOS is basically a fork from BitShares-0.4.23.1, so I'm already familiar with the BitShares codebase.

I see my activities mainly in these areas (in no particular order, priorities will be worked out together with the core devs on a case-by-case basis):

1. Infrastructure

For PTS I have implemented a dynamic list of seed nodes published via DNS. Porting this to BitShares should be simple. I will create and maintain such a list for BitShares (and DevShares) and publish it in the DNS. These DNS names can then be added to the static list of seed nodes built into the client. Every time the client is started, it will fetch a fresh list of seed nodes from DNS and use these. (Once set up, the list is updated automatically and requires hardly any manual maintenance.)

To my surprise, the current client does not work with IPv6. This is a no-go for a brand new networking application, IMO. I will work on porting the networking code to IPv6.

I will continue to provide my Linux packages of BTS (and DVS) for the current set of distributions (CentOS, Fedora, openSUSE), free of charge - I would do that anyway. I can work for pay on adding support for Debian, RHEL, Ubuntu and ArchLinux.

2. External APIs

The BitShares code already contains a very elegant mechanism for defining and generating the external RPC API (also used by the GUI wallet). The same mechanism also generates the command line interface.

The next logical step is to use this mechanism for generating a common API for external applications. I'm thinking of a BitShares-Java API, a Perl module, C library etc., similar to what Xeroc has already started for Python.

In addition to generating the plain method calls, the parameter types and return types should be formalized as well.

3. Code Quality

A delicate subject. This is not about bashing other people's coding style. It is also not about throwing everything away and starting from scratch (only better this time). Nevertheless, objective metrics on code quality exist, and application on the BitShares codebase suggests that there is room for improvement.

What is code quality and why is it important?

Clean code is simple in the sense that it is easy to read and easy to understand. It is highly modular and well-structured.

When code is easy to read it is also easier to see bugs. This leads to a better product.

Code that is easy to understand makes it easier for new developers to join the team, reducing the time (and cost!) to get them up to speed.

Well-structured code is also easier to maintain, reducing the time (and cost) to find and fix bugs.

Modular code facilitates adding new features to an existing program. It is easier (and cheaper) to add a new module than to fiddle with many details all over the codebase.

Modular code also facilitates code reuse. Reuse reduces the overall code size, which leads to more simplicity, fewer bugs and lower maintenance cost.

How to get there?

•     Educate others. Not with long monotonous lectures, but by setting examples. By generating interest, explaining and giving pointers.
•     Introduce tools. I plan to select tools and metrics for evaluating code quality to highlight problem areas and measure improvement over time.
•     Apply the boy scout principle: Always leave the code cleaner than you found it.

4. Grunt work

There are currently (2015-01-31) 130 open issues in the main github repo. Some of these are more than 7 months old. This is not a sign of lazyness (there are more than a thousand closed issues), it's a sign of an overworked dev team. I can take up some of these issues, taking load off the core team.

In a similar way, I can investigate issues posted by forum users that never even make it into a github ticket.

B. Suggested mode of operation

1. Pricing

I can offer to work for the BitShares DAC for €55.00/hour including all expenses. (This is less than my usual rate, and more than 20% less than the average.) I will adapt the amount of work I'm doing to the exchange rate of BTS/EUR.

I will not charge for

•     time spent on the forum,
•     work that is immediately applicable to PTS-DPOS (the codebases have diverged and merging changes is a real PITA anyway),
•     things I would have done anyway (like maintaining my linux packages, see above).

2. Delegate Operation

I suggest that a 3rd party runs a 100% delegate on my behalf. This should be either an individual living outside the EU, or a business located outside Germany. This serves two purposes:

•     It is a tax optimization - in this setup I don't have to charge VAT.
•     It is an insurance to the DAC - the 3rd party can check that I'm actually working for my money, and withhold/burn the funds if I don't.

The 3rd party will have to make their identity (name and address) known to me, so I can send them a proper bill (for example on a monthly basis). These bills (excluding the 3rd party's identity) plus a more detailed report will be published here for you, the shareholders, to check.

The 3rd party should agree on a fixed price for their own service in this setup, which will also be paid from the delegate proceeds. Any remaining funds below a threshold (for example two weeks of delegate payment) will be carried over to the next month, the rest (above the threshold) will be burned.

The first two weeks of pay will be taken as compensation for the registration fee.

3. Delegate Operator

Cube has agreed to run the delegate for me. He's a long time member of our community and has been running very reliable PTS-DPOS delegates for a while now.

I am a IT consultant cum project manager by profession. I started as a developer and a system admin before moving on to a sys analyst, senior analyst and then the project manager role. My IT profession and experiences are over 20 years. I am one of the team members responsible for the release of PTS DPOS. I detailed my interest in crypto here.

- Cube

Cube will charge USD 135.00 per month for his services. This includes hosting, server maintenance and bookkeeping. At the current rate, USD 135.00 is roughly 10% of the total delegate earnings.

4. Vote for me!

Code:

wallet_approve_delegate dev-pc.bitcube true

Thank you very much!

[StanLarimer]

Here's a series of articles I wrote for this forum to provide some background on The Origin of BitShares:

Part 1   - It Began with ProtoShares
Part 2   - The Death of Mining
Part 3   - The Ideal Mining Pool
Part 4   - AngelShares and Virtual Mining
Part 5   - POW to POS to TaPOS to DPOS!
Part 6   - Sharedrops and Snapshots
Part 7   - BitShares Sharedrop Theory
Part 8   - Experimenting and Pivoting
Part 9   - What is a SuperDAC?
Part 10 - BitShares Unleashed

I've reposted the links here for your convenience.

[StanLarimer]

   

 
I&E 550: Innovation and Cryptoventures

Today Bytemaster had the opportunity to present a two-hour lecture at the Duke University School of Business in Durham, North Carolina under invitation from Professor Campbell R. Harvey (the guy with the necktie).  The forty students taking this course are a mixture of computer science, business, and law majors who are interested in learning about starting entrepreneurial businesses in the crypto industry. The class is divided into eleven teams, each of which is required to develop a crypto business as part of their course objectives.

As you can probably imagine, Dan talked about Decentralized Autonomous Companies (DACs) and how to make them profitable.  Among the opportunities he discussed were:

1.  Cloning the BitShares block chain using the BitShares Toolkit to produce independent businesses like MUSIC and PLAY.
2.  Adding your own business logic like VOTE and DNS to BitShares itself to leverage it's delegates, community, currencies and network effect.
3.  Using BitShares User Issued Assets (UIA) to issue regulation compliant shares in a brick and mortar and flesh and blood company.
4.  What it takes to add your own Market Pegged Asset (MPA) to BitShares.
5.  The opportunity to create a business based on issuing one or more Prediction Market Assets (PMA).
6.  Becoming a BitShares Delegate and using that to bootstrap a startup business.
7.  Creating supporting business for third party add-ons, services, and products inside the emerging ecosystem.
8.  Crowd Funding vs. Crowd Hiring to bootstrap and sustain block chain based businesses.

Unfortunately there are no notes or slides to give you since Dan's lecture was given "off the cuff," but we did record it and hope to publish some or all of his best riffs before long.

For some reason I found Professor Harvey's course reading list particularly interesting, but you should check out all the other resource links on the course web site as well.

Readings

Andrychowicz, Marcin, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek, 2013, Secure Multiparty Computations on Bitcoin.
Antonopoulos, Andreas, 2014. Mastering Bitcoin. [advanced]
Back, Adam, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille, 2014, Enabling Blockchain Innovations with Pegged Sidechains
Fortnow, Lance. 2013. The Golden Ticket. Princeton: Princeton University Press.
Goldwasser, Shaffi and Mihir Bellare, 2008, Lecture Notes on Cryptography. [Advanced]
Grinberg, Reuben. 2011, Bitcoin: An Innovative Alternative Digital Currency.
Harvey, Campbell R., 2014a, Cryptofinance.
Harvey, Campbell R., 2014b, Bitcoin Myths and Facts.
Hearn, Mike, 2014. The future of money.
Isaacson, Walter, 2014. The innovators: How a group of hackers, geniuses, and geeks created the digital revolution. [Amazon link]
King, Ritchie S., Sam Williams, David Yanofsky, 2013, By reading this article, you're mining bitcoins. Quartz. [Explains mining process and network architecture]
Larimer, Stan. 2103. Bitcoin and the Three Laws of Robotics.
Nakamoto, Satoshi, 2009. Bitcoin: A Peer-to-Peer Electronic Cash System.
Selgin, George. Synthetic Commodity Money.
Szabo, Nick. The idea of smart contracts
Szabo, Nick. Formalizing and Securing Relationships on Public Networks.

Perhaps the most amazing thing to me was that a university group of that size and diversity could reach unanimous consensus on anything.  But not a single person in that entire lecture hall expressed one shred of disagreement with Dan's unspoken assertion that dogs are much better than cats.

[StanLarimer]

Here's a tiny 30 second video sample:

Bytemaster on How Much Decentralization is Enough

[StanLarimer]

Over on The Thread That Must Not Be Named, DE has raised some legitimate questions and presented them rationally, so I am happy to address them.

http://bitsharesblocks.com/delegates

This picture really says it all.  The top delegate only has ~17% of the vote.  This is a perfect example to show how easy it is for the wealthiest stakeholders to control the delegates.

That's true that in all blockchains stakeholders/hashpower can collude, but they can only collude in a one-to-one proportion to their stake/hash.  Since approval voting is used in delegate elections, I maintain that large stakeholders can effectively collude to a multiple proportion of their stake.  Whereby, for example, 20% of colluding stake can disproportionately influence the elections of more than 20% of the delegates.  This leads to a coalition of a few wealthy stakeholders being able to determine the outcomes of the mass majority of the delegate elections.  This is especially true considering that voter turnout of smaller stakeholders will be lower than the voter turnout of larger stakeholders.  As I said previously, it would be the intention of the colluding wealthy stakeholders to not harm Bitshares, but to elect delegates from which they would derive monetary gain in excess to their proportion of stake in the system at the expense of all other stakeholders.

Let's give an example.  Remember, in "approval voting", voters do not just vote for one delegate.  They can select as many or as few delegates as they wish and the entire weight of their stake counts towards each delegate they choose.  Say for instance that the top delegate has 50% of the vote and the 101st delegate has 30% of the vote.  The voting spread percentage is 20% (50%-30%).  If the votes per delegate is a linear increase according to delegate rank, an additional 10% of the stake vote will move the 101st delegate to the 50th position.  Likewise, a removal of 10% of the stake vote from the lower 50 delegates will result in them losing their delegate position.  By strategically voting, a few wealthy stakeholders can influence a disproportionate number of delegate positions in relation to their actual stake.  In this example, a coalition of 10% stake was able to control 50% of the delegates.

Does this sound fair to you?!

1.  Non-voting owner's who are happy to accept the decisions of active voters are effectively delegating decisions to those who do vote.  It is their choice.  In the 17% voter turnout example given, it is clear that most owners are happy to go with delegate selection by those who do vote.  I will speculate that they do this for the following reasons:

a.  Rational Ignorance.  It's not worth their time to figure out who to vote for.  It doesn't matter to them which subset of generally acceptable candidates get elected because delegate ability to do something undesirable is negligible.  A delegate either signs blocks and includes transactions faithfully or not, and everyone can tell if they don't.  Those in full-time positions need to avoid having a lynch mob form to vote them out and so they need to continuously answer the question, "What have you done for us lately?"

b.  They have no objection to any of the delegates that are being elected by those who vote.  If an issue comes up, then they presumably are reserving the right to weigh in.  Low participation means owners are generally satisfied.  I don't vote my stake in cold storage for this reason, but if I'm not happy at some point, I will go to that extra trouble.  So that could also be the case for many of the other non-voting stake out there.  Similarly, smaller stakeholders can go to the extra trouble of rallying others to their cause (i.e. "colluding").

c.  In general, a large voter cannot vote in a delegate that doesn't already have broad support from everyone else.  It is true that a large voter can swing which of the otherwise lesser approved delegates get picked.  It is even true that a very small voter can switch who is in positions 101 and 102 by changing one vote.  Similarly, if many small voters agree on certain delegates, there is nothing a big owner can do about it.  This is how it should be.  The bigger your stake, the more you have at risk, and the more say you should have in who runs the business.  This is far more fair than many traditional business that are intentionally structured to disproportionately favor the big guys.

In this example, a coalition of 10% stake was able to control 50% of the delegates.

Yes, and another coalition of 11% of the remaining stakeholders is able to override them.  

2.  Owners have a right to form political alliances to achieve their objectives.  You can call it "collusion" if you want.  The rest of the owners have a similar right to team up (collude) to overrule them.  If an owner doesn't like what the "ruling collation" decides, she can sell her stake.  The company is, by definition, only owned by people who approve of how it is being run.  It is the right of those owners to run it that way.  Blockchain technology is there to ensure transparency in whether the agreed upon rules are being followed.

Bottom Line:  BitShares has been implemented with a well-defined transparent form of decentralized government.  We have tried to make it be fair enough to attract a large number of happy owners.  (We would be fools to do otherwise.)  Those who find that acceptable and profitable will own it.  Those who don't, won't.  If there are enough who want it run differently, they will actively vote for changes or clone a competitor.  So far, the current community seems happy with what they have.

[StanLarimer]

Here's another quick thought experiment on the above topic.

Suppose you have 10 accounts each with 10 shares and you decide that each account gets 1 vote.
One of the account holders divides her shares among 10 puppet accounts.  Now she has 10 votes.
So the rest of the account holders are forced to divide up their shares as much as possible too.

What do you wind up with?  1 vote per share!   

[Come-from-Beyond]

Here's another quick thought experiment on the above topic.

Suppose you have 10 accounts each with 10 shares and you decide that each account gets 1 vote.
One of the account holders divides her shares among 10 puppet accounts.  Now she has 10 votes.
So the rest of the account holders are forced to divide up their shares as much as possible too.

What do you wind up with?  1 vote per share!  

https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem

TL;DR: BitShares ought to do extra voting rounds if total number of votes for outsiders is higher than number of votes for at least one of top 101 delegates. Otherwise you can't claim that the delegates are chosen in a fair/democratic manner.

[StanLarimer]

Voting rounds are continuous and voters can change their votes at any time.  The top 101 delegates are always those with the most number of shares approving them and everyone can look at that set and decide to change their approvals at any time.

So by your criterion, if "extra voting rounds" are needed to make things more "fair/democratic", then BitShares is infinitely fair and democratic because new voting rounds happen every 10 seconds forever.  

 

[Come-from-Beyond]

Voting rounds are continuous and voters can change their votes at any time.  The top 101 delegates are always those with the most number of shares approving them and everyone can look at that set and decide to change their approvals at any time.

So by your criterion, if "extra voting rounds" are needed to make things more "fair/democratic", then BitShares is infinitely fair and democratic because new voting rounds happen every 10 seconds forever.  

 

In the current version voting results are applied on the fly. To follow the criterion you need something like modern president elections (when the 2nd round is used if none of the candidates gets at least 51%):

1. All shareholders cast votes
2. If new top 101 don't get the overwhelming majority then part of delegates with lowest vote count is removed from the list of candidates and goto #1
3. Old 101 delegates are replaced with the new ones

PS: Also, you use "vote-outs". This mixes two different voting systems and may lead to a worse situation.

[StanLarimer]

We use approval voting. 
Everybody indicates all the candidates they approve of.
The 101 most approved of candidates are hired.
No need to make it any more complicated than that.

[Daedelus]

No need to make it any more complicated than that.

I lol'd 

[StanLarimer]

Interesting opportunity if you still have a lot of mining equipment looking for something to do.

Stan

MineBitShares bitUSD Mining is now live at @ http://pool.minebitshares.com

At the new MineBitshares sub-forum : https://bitsharestalk.org/index.php?topic=14119.0

MineBitShares bitUSD Mining is now live at @ http://pool.minebitshares.com

'We aim to be the most profitable multipool with 0% fees and bonus payouts for every miner, every day'

We've just completed payouts of $439 bitUSD to 45 miners who have been mining on the pool over the last 3 days. This is at 0% pool fee and included 3 days bonus payments.

The pool website has been updated and now includes pool profitability stats.

Happy Mining!

[JohnnyBTCSeed]

No need to make it any more complicated than that.

I lol'd 

[Come-from-Beyond]

No need to make it any more complicated than that.

I respectfully disagree. You need a more complicated method because otherwise you have a weak spot. An adversary doesn't need to earn credibility to enter top 101. Lowering credibility of the competitors works too. What is especially bad is that the current voting is asymmetrical - you need N units of effort to earn credibility and N/10* units to lower credibility of other candidates because everyone will likely do the same. I didn't analyse this tactics closely but suspect that cooperation of outsiders trying to asperse the winners and take their place is a powerful trick.

-------
* - assumed for a case of 1000 candidates

[StanLarimer]

That's not how BitShares voting works.

The only thing that an individual voter can do is indicate which potential candidates are most acceptable to them.
If a candidate ceases to be acceptable, the voter can remove that approval.
That's all.

She has no ability to "down vote" anybody or concentrate negative votes on certain candidates.
There is no such thing as negative votes.

Each candidate runs in his or her own independent election.
Each seeks a high percentage of approval from the voters of all shares.

The 101 candidates with the highest approvals get the jobs.

Theoretically 101 candidates could each receive 100% approval.
In practice, our top delegate currently has about 18% and Delegate 101 has about 8%.

BitShares February Newsletter

There's a lot more to BitShares than you typically see on any forum thread.

It is very decentralized with a score of independent marketing and technical projects underway in parallel.

If you've wished you could have a one paragraph summary of every activity
and insights about who is doing what, well, now you can.

Here is the first decentralized BitShares newsletter.  
Legend has it that it simply wrote itself!  

[LiQio]

Legend has it that it simply wrote itself!  

[Come-from-Beyond]

That's not how BitShares voting works.

Good to hear. Update https://bitshares.org/blog/delegated-proof-of-stake/ please, statements like

Every share can be set to vote either for or against a potential delegate.

are very confusing.

[StanLarimer]

That's not how BitShares voting works.

Good to hear. Update https://bitshares.org/blog/delegated-proof-of-stake/ please, statements like

Every share can be set to vote either for or against a potential delegate.

are very confusing.

Agreed.  I had to go do a WTF on that myself.

You can set your defaults to follow the voting slate of some other delegate or group of delegates that you trust rather than picking the full set yourself.

If you do that, then the "thumbs down" icon means, "ignore any recommendations for this candidate".

So, you can toggle the thumb on each candidate between "Thumbs up - add to my custom slate", "Thumbs down - remove this one from my default slate(s)" or un-selected - "do what the default slate(s) I am following recommend".

But all this does is effect how your slate is defined.  When you vote, all you can do is add or not add votes to a candidate.

You can't do anything to subtract the approval they have from other voters.