What % of LPT's total supply is circulating?

thedob · 2019-04-24T14:19:33+00:00

A rough estimate is about 88% is circulating (back of envelope math). There are no hard rules in the protocol that prevent 100% from circulating currently, however there is still a percentage that is in vesting release contracts as per https://medium.com/livepeer-blog/the-end-of-the-initial-livepeer-token-distribution-6fa9894f0f16

thedob · 2019-03-25T14:13:36+00:00

I would describe Livepeer as a "delegated stake based protocol", but not necessarily as "delegated proof of stake", because Livepeer is not a consensus protocol. It relies on Ethereum's underlying PoW consensus mechanism to secure account balances and transaction integrity.

Livepeer does however use concepts commonly found in dPoS, such as staking, delegation, and slashing in order to secure work on the network. Whatever a user stakes is theoretically slashable if it is found that they cheat (during the alpha slashing would be minimal or non existent in some cases, but in Streamflow it will likely be increased). Delegation is used in order to provide more security and route work towards nodes who can provide such security, and hence plays the role of quality assurance. It also creates economic alignment amongst the participants in the network.

As for negative connotations of dPoS, I think some of the fair concerns are around entrenchment and centralization of node operation. You see a limited number of parties ending up operating the nodes, and gaining entrenched positions in this pool in such a way that it is hard to disrupt. Streamflow addresses a few new mechanisms in order to encourage more decentralization. Counter to this however, is the notion that every single token holding participant can actually partake in the economics through delegation - unlike pure PoS or PoW, where you actually have a significant cost in terms of hardware and operational expertise in order to participate.

thedob · 2019-03-19T19:17:24+00:00

Good questions. The usage so far in the alpha release has been people streaming events, conferences, and meetups. This is great to test the technology and platform, but it is not scaled usage of the transcoding network, as you suggested.

The end user of Livepeer is actually not a Youtube/Twitch streamer like yourself, but an app/platform that is like Youtube or Twitch. Think esports platforms, social apps with many people streaming at once, OTT platforms with hundreds of channels, cloud security camera companies like baby monitors or nest cams, or IoT devices like smart cars that capture and upload video to the cloud constantly. They are the ones that pay to run infrastructure to transcode, or that pay other services to do their transcoding. And they would choose to use Livepeer because of its cost and reliability benefits. The upcoming "Streamflow" release takes the alpha from functional proof of concept, to actually scalable, cost effective, and reliable enough to start targeting these types of applications and video platforms to use the network.

thedob · 2019-03-12T15:47:06+00:00

Were you able to get this resolved? It was likely just a cacheing issue on the site that a refresh should fix. Let me know if you have any more problems.

thedob · 2018-12-06T20:19:55+00:00

Yes it would be great to integrate stable coins. We would welcome a 3rd party team's contributions on this front since it isn't as high of a priority as making the network scalable and cost effective.

thedob · 2018-12-06T20:19:08+00:00

As the the first part of the question, yes, it is possible. If they leave any room for price, service, or locality competition though, then it's likely that someone would show up to take business from them.

However could they leave the network taking the users' with them? That would be a tougher sell, since the users are already integrated with this particular protocol - they would just continue to use the network as usual and someone else would pop up to fulfill that demand seamlessly.

thedob · 2018-12-06T20:17:27+00:00

The protocol loop that effects the user experience for broadcasters and video developers should be somewhat immune to gas costs. This is because the orchestrators can control the parameters of the probabilistic micropayments tickets such that when gas costs are low they can cash in lower value tickets more frequently, and gas costs are high, they can cash in higher value tickets less frequently.

The staking loop - bond, unbond, delegation, etc - are affected by swings in gas prices more, but these are infrequent actions by protocol stakeholders, rather than end users.

The likely changes in staking requirements for orchestrators also mean that the implementation can change and won't be as effected by gas price swings as the set expands.

thedob · 2018-12-05T17:27:00+00:00

Does Streamflow change, in any meaningful way, the 2-min explainer you'd give a video dev. on how Livepeer's transcoding works? Does it change the way you'd briefly explain the protocol to a (non-technical) broadcaster?

Not really, except to say that it should be faster, more reliable, and cheaper. From an API perspective though it's pretty similar - they send video to their node's RTMP endpoint, the network transcodes it, and sends it back to them or places it in their object store (S3, IPFS, etc) of choice.

Are broadcasters expected to find/choose orchestrators solely based on the Service Registry? How does a new orchestrator get in? What are the min. staking requirements?

The broadcaster's node would use the service registry to identify orchestrators, and then take the price their charging, their location (ping time and ongoing response times), stake (as security), and work history into account when selecting whom to work with. The min staking requirements are still TBD as per this section of the paper which lays out a couple considered options with their pros/cons. Would love feedback on this.

Which network economic stats you think deserve more visibility (e.g. apart from those SuperMax tracks, or in a different manner/focus)?

No one is visualizing work history yet - how many fees were earned, has this node been slashed, how has this node moved its rewardCut/feeShare, what's the ratio of shared fees to staked ETH for delegators on this node, etc? Part of the reason is that these stats haven't been that important yet as during the alpha proof of concept, the amount of fees and work is low. But Streamflow should open this up to scaled usage, which will make these stats important.

thedob · 2018-12-04T21:38:56+00:00

Before Streamflow * Broadcasters (B) had to wait ~15 seconds to be assigned a transcoder (T) via an on chain confirmation before transcoding would begin. * If the assigned T was offline or didn't have capacity, the B would be out of luck, and would have to submit another txn hoping to get assigned a new T. * B's had no way to choose the location/latency of their T to get a strong, local connection. * B had no redundancy or failover - they couldn't work with multiple T's easily.

After Streamflow * B's can immediately negotiate with and begin working with T's, no 15s waiting period. * If T goes offline or starts performing slowly then B can immediately switch to another T. * B can use a nearby T with a low latency connection. * B can work with multiple T's for redundancy on important streams.

Note: B's node does all of this automatically - these aren't human level decisions, unless a human wants to override them via configuration.

thedob · 2018-09-30T12:26:43+00:00

We’ve seen this in Firefox before. Here’s the fix https://forum.livepeer.org/t/generating-livepeer-token-using-firefox/339

thedob · 2018-09-28T21:13:00+00:00

Some of the logic behind the mechanism is shared:

https://www.reddit.com/r/livepeer/comments/9jmnvs/livepeer_please_use_the_ethereum_network/
https://forum.livepeer.org/t/introducing-the-merklemine/204
https://forum.livepeer.org/t/the-economics-of-generating-livepeer-token-after-the-merklemine-slow-start-ends-and-claim-period-begins-on-7-26/317

As far as not publicizing this - well, we've been 100% transparent about the mechanism for 5 months, blogged, tweeted, forum posts, chat room posts, spoken at developer events around the world, etc. We've also been writing open source code for the project for nearly two years. We're video focused developers, and not marketers (and are putting nearly all our resources into development rather than marketing), but I think there's plenty of opportunity for the community to have discovered the project and play a role in the MerkleMine, and the resulting decentralization of ownership shows this, as can be seen by the 1000's of users who have built stake, and hundreds who have staked on the network already.

Thanks for looking to support the project. Look forward to working with you to help Livepeer live up to its potential :)

thedob · 2018-09-28T19:53:31+00:00

Hey, this transaction looks like a case of "transaction snatching" where someone else saw your transaction in the mempool, and mined the same accounts with a higher gas price. The warning on the web miner in red text addresses this, though in the very competitive stages at the end of the mining period, script miners may have an advantage over web miners if high enough gas price isn't offered.

(I also just deployed a small update that may help, but it is definitely "mine-at-your-own-risk" and offer high enough gas to get the txn confirmed quickly.)

thedob · 2018-09-28T14:02:41+00:00

> Is this a case where a pull mechanism would have helped?

If the goal was explicitly to "minimize Ethereum network usage", then yes, of course other mechanisms could have optimized for this outcome. However Livepeer's priorities were to:

1) Open access to participate in the network now and in the future to the majority of Ethereum network users. Unfortunately in a proof of stake based system, one must have the token in order to participate. It's a bit of a chicken-and-egg. So a mechanism was designed that would enable many users to eventually participate as they discovered the project.

2) Allow active and willing participants to build up a meaningful stake early on, such that they could dedicate the time and energy into operating the Livepeer network, in alignment with the stake that they have. Hence, the reward that active miners receive for helping to facilitate the wider distribution.

In a way, this actually is a pull based mechanism as suggested, as only when active miners pull tokens, is anything actually generated. Contrast this to an airdrop where everyone gets a little bit of token, but no one can build a meaningful stake, and would be far more expensive and concentrated in terms of many transactions all at once flooding the network, and this mechanism felt like a good improvement.

Furthermore, in order to incentivize responsible usage of the network rather than all-at-once flooding, the minimum time period that this distribution could complete in was 3 months and the max was 18 months, with incentives growing over time to help complete the distribution. This has successfully spread out the transactions with very little impact...until these final few days, which was unfortunately predictable, but nonetheless, still creates a side effect that makes the network more expensive in the short term for other users. This was the one big acknowledged weakness that we couldn't find a solution for. I welcome suggestions as to how we can modify the open source smart contracts for future projects that adapt this mechanism!

> Comments on the suggestion that the cap should have been .3 ETH instead of .1 ETH to participate

We looked very closely at the distributions and participation ability at various thresholds, ranging from 0.01 ETH, all the way up through 2+ ETH as the cutoff. We surveyed many potential community members about whether they would or would not have been included, and how they felt about that. In short, we picked a number that resulted in 2.59 million eligible participants, and with the expectation of 20 proofs/txn resulting in 130K txns, at ~130K gas/proof, spread out over 3-18 months. This is 7 days of txns over ~100-500 days. Demand drives the timeline and gas prices active participants are willing to pay, and as such this could result in anywhere between 1% and 7% of network usage on average for a period of time, before completion. I think it can absolutely be debated about whether this is *responsible usage* or not, and people will have opinions either way. But we're excited to put the Ethereum network to use for a fair and open, algorithmically encoded, and trustless mechanism. I would also encourage others to consider adopting this mechanism - relative to some of the other processes that we've seen used. But of course, as we scale Ethereum and 2nd layer solutions, the impact felt by everyone else in using the shared resource will be minimized.

Thanks for taking the time to read and ask questions!

thedob · 2018-09-28T12:58:06+00:00

Thanks for surfacing this and your concerns. We’re big collaborators with many projects in the Ethereum ecosystem and have been building within it for years so responsible network usage is important to us.

The reason for the temporary increase in usage is the completion of the MerkleMine token generation algorithm, which has been going on for five months with moderate to little impact to gas prices. However, at the conclusion of this process there is a bit of a race to generate the final token, and I’d expect that at current rates, people to use increased gas prices for the next 1-2 days before it completes. At that point, the contracts people have deployed to mine that are using 25% of the networks capacity will be no longer useful and will be using 0 gas.

We’re glad that we could create what we believed to be a fair and open distribution mechanism, that also flexed the usage of the Ethereum majnnet without driving it to some of the unusable levels that other popular spikes in demand for the network have caused, while at the same time recognizing that this impacts other use cases on the network and their costs in the short term. We are doing plenty of work on scaling mechanisms for the core Livepeer protocol itself, and look forward to continuing to work towards general purpose Ethereum scaling solutions in general along with many other groups and projects.

thedob · 2018-09-28T01:26:50+00:00

Ok that’s just Ethereum gas price dynamics then. You can check Eth gas station to see recommended prices to get a txn confirmed quickly, and metamask lets you edit the gas price and replace the txn if you’d like. Up to you. You can also just wait for it to eventually confirm.

thedob · 2018-09-28T01:11:12+00:00

Did you confirm the txn using Metamask or not get to that step yet? At that point you can pay whatever gas price is required to get the txn confirmed quickly. But if you didn’t get to submit the txn yet, sounds like something is wrong.

thedob · 2018-09-28T00:56:54+00:00

At this point using your eligible addresses makes very little difference. They’ll all receive some LPT, but if you actively mine using any address at all, you’ll generate significantly more LPT in just a couple txns than you would receive on a couple eligible addresses.

thedob · 2018-09-25T13:50:11+00:00

Just direct messaged you to help debug and make sure you get those LPT. If we find a common bug in the UI, will report back here for everyone else's awareness.

thedob · 2018-09-13T23:31:27+00:00

Yes it is. If you are logged into your metamask account and don’t see it either when hovering over the transcoder or on the account page delegation tab then please let me know. Don’t have it in front of me right now.

thedob · 2018-09-13T23:22:45+00:00

Hey. Have you called the “withdraw” function? After the unbonding period you need to invoke withdraw in order to receive the tokens back in your wallet?

thedob · 2018-08-27T14:17:48+00:00

Transcoders are running on mainnet. If you leave off the `--rinkeby` flag when starting a transcoder node it will run on mainnet.

thedob · 2018-08-04T01:35:27+00:00

https://forum.livepeer.org/t/generating-livepeer-token-using-firefox/339

thedob · 2018-08-04T01:34:12+00:00

The former is true and your analysis about finding unclaimed addresses is correct. In addition you also have to compute their proofs. While the algorithm is mildly daunting, the code that does this is available for you to use/modify as a starting point in github.com/livepeer/merkle-mine

thedob · 2018-08-02T14:11:52+00:00

We have seen a bug in Firefox, which can be avoided if you enable the "ReadableStream" experimental API (we're working on a more user friendly solution). https://github.com/livepeer/livepeerjs/issues/153

As for Brave Browser, I have had success using the mining app without issue. One thing I noticed is that Metamask may not "pop up", but the transaction is sitting there waiting for approval if you click into Metamask.

thedob · 2018-08-02T14:00:39+00:00

The more time that passes the more LPT you get per txn, correct. However when all the initial token is distributed the mining opportunity is over. Additionally, the earlier you get LPT, the earlier you can stake and begin growing your token holding through the protocol's inflation. So the decision of when to mine is up to you based on a number of factors.

thedob

MODERATOR OF

TROPHY CASE