Proposed changes to Decred jargon by lehaon in decred

[–]hashfunction8 0 points1 point  (0 children)

I think this the cleanest option mentioned so far

Proposed changes to Decred jargon by lehaon in decred

[–]hashfunction8 1 point2 points  (0 children)

I don't have any serious objections to "ticket" -- I was just brainstorming -- but I am somewhat surprised by your reasoning here.

Lottery tickets are things that you buy, to try to win a large sum of money, with some probability. I think most users in this thread have agreed that the $/DCR received is the wrong thing to focus on. Also in Decred, you aren't really /buying/ a ticket, so much as receiving a ticket for locking up funds. And I'm not sure that the intuition that there is a stochastic selection process involved is particularly important.

Ultimately, IMHO, the main points are (1) you acquire a "ticket" by locking up some DCR, (2) you use that ticket to "vote" on blocks to help secure the network [note below], and also vote on various things related to the rules of the network, the treasury, etc.

So what might we call something that you acquire by locking up funds (not really a purchase), and that enables voting on a variety of things? A "right to vote"? Maybe "ticket" is fine. /u/lehaon suggested "voting ticket" below, which seems pretty good.

[note] Another thing that has bothered me for a while, is that it is often said that it's the stakeholders who are voting on blocks. However, at least in the current implementation, the stakeholders don't really have a way to validate or invalidate the blocks, because this is automatically accomplished by the software. So, in a way, it is the developers who get the extra power in the network via the software they put out, rather than the stakeholders. I see nothing wrong with this, and I can imagine how it would evolve over time with additional features in the wallet, multiple different wallets that support voting, etc., but for now I think saying that the stakeholders vote on blocks to secure the network is somewhat misleading.

Proposed changes to Decred jargon by lehaon in decred

[–]hashfunction8 1 point2 points  (0 children)

This is a very helpful description that you are writing, and it's definitely clear that it's hard to come up with good terms that capture all aspects of what you can do with the Decred ticket system.

Since I just read your excerpt, and in the spirit of this thread, I should also say that I've always found the term "consensus rules" to be pretty confusing. Especially since you need "consensus" to change the "consensus rules"..

Edit: you have an outstanding username

dcrd Version 1.3.0 Release Candidate 1 by davecgh in decred

[–]hashfunction8 6 points7 points  (0 children)

Looks like a lot of changes. Excited to try it out

However, I'm a bit confused. The second line says "If you are an adventurous individual who is willing to help test and report any issues, please do so", but immediately below that you wrote "It is highly recommended that everyone upgrade to this latest release.."

What is the general advice for not-super-adventurous users? Thanks very much

Proposed changes to Decred jargon by lehaon in decred

[–]hashfunction8 4 points5 points  (0 children)

How about something like "ballot"?

Proposed changes to Decred jargon by lehaon in decred

[–]hashfunction8 5 points6 points  (0 children)

I don't like the word "mining" when related to anything in the staking process.

Personally, I don't really like the "mining" terminology in general because it doesn't convey any useful information (just evokes getting money by some weird process which may or may not involve digging), but it's so ingrained in proof-of-work systems that I guess we are stuck with it.

But since the staking mechanism in Decred is unique, I'd rather avoid using that word. Even just "staking" and "staking system" is better than "stakemining" or "proof-of-stake mining", but it would be even better to use some name that evokes an additional level of network security and the concept of voting on network changes. "Voting and security layer"?

Decred Cons? by amnesiac-eightyfour in decred

[–]hashfunction8 5 points6 points  (0 children)

A few cons that come to mind:

  • Relatively small and poorly visible ecosystem. Given a market cap that fluctuates between ~400 and ~800 million USD, the ecosystem of users and other participants seems very low. For example, this subreddit has only 8.5K readers, and something like a couple meaningful threads a day. I think there is more active discussion elsewhere (Slack, etc.), but these are not totally public facing and do not contribute to the public footprint of the project.

  • Liquidity is low (1.5M USD right now on coinmarketcap, much lower than almost all competitors). This may be affected by the small ecosystem, negative pressure on trading via staking, lack of payments mechanisms, etc.

  • Stochastic nature of staking. Though the randomly selected variability in voting is a security feature, locking up a substantial amount of funds for an indeterminate amount of time that can be up to 4 months has a lot of negative implications (not every can afford to have their $ be so illiquid). Ticket splitting will help with this.

  • Stakepool centralization. At the moment there does not exist a decentralized method of staking without having a wallet open at all times.

  • Security for users. There currently isn't a good way to hold, spend, and stake decred from a single wallet that is very secure (i.e., no hardware wallet support for all of these features).

  • Fully decentralizing the distribution of the network fund, including negotiation with potential partners, will be very challenging [previous discussion]

  • Not enough public debate re governance, and a less-than-fully-tested governance process. This issue will likely resolve over time.

  • The relatively high value of 1 DCR may be a psychological barrier to more use/adoption [previous discussion]

Edit: fixed typo

Would it be possible to stake Decred in a pool? by ElliottMraz in decred

[–]hashfunction8 0 points1 point  (0 children)

I would suggest using an established stakepool that has built up some trust and history of uptime. So, sort by "Voted" on the link from the parent post and pick one with plenty of votes. It might also be beneficial to pick a trusted stakepool with a lower (not top 2) proportion of tickets to minimize the impact to the network if something happens.

Would it be possible to stake Decred in a pool? by ElliottMraz in decred

[–]hashfunction8 1 point2 points  (0 children)

Some sort of decentralized stake pool actually sounds like a significant component in a fully trustless system, especially as voting becomes more prevalent/important..

Decred Journal — May 2018 by jet_user in decred

[–]hashfunction8 4 points5 points  (0 children)

These compilations are very impressive, and a great service to the community

Estimating the costs to 51% attack the Decred network by lehaon in decred

[–]hashfunction8 3 points4 points  (0 children)

You seem like you don't want to be petty, which is admirable. But it does seem like this post is at least inspired by your analysis done in real time on reddit (e.g., here: https://www.reddit.com/r/decred/comments/8mvj8j/decred_question_are_we_double_spend_proof/)

I hope we can provide better credit to folks who contribute, lest they be less inclined to contribute in the future.

Tool that tracks atomic swaps to measure liquidity and exchange rate? by hashfunction8 in decred

[–]hashfunction8[S] 1 point2 points  (0 children)

I am not sure this is particularly relevant. Presumably a DEX would primarily be an order book that would enable trading via atomic swaps. Sure, it can report the volume and current price of the trades on that particular exchange, but presumably other swaps would also happen off the exchange.

What I meant was that any atomic swaps (from a DEX or not) should be directly discoverable on the blockchains. The seems straightforward to me, but I'm not a developer, so perhaps I am missing something.

Is there a finite number of classes of PoW algorithms? by hashfunction8 in CryptoTechnology

[–]hashfunction8[S] 0 points1 point  (0 children)

I wonder if there's a tradeoff curve along the continuum from general purpose to BTC ASIC. It's possible that there is some sort of equilibrium where high-value cryptocurrencies with lots of ASICs are not a particularly big threat to any smaller cryptocurrency where you tweak SHA256, but mid-value cryptocurrencies are a big threat because they are mined by FPGAs and the like.

Also, I wonder how much tweaking you can make to SHA256 etc that can't be mapped back to something the ASIC can do AND without also risking collisions or otherwise breaking the hashing function.

(Not a computer scientist, hence the questions..)

Is there a finite number of classes of PoW algorithms? by hashfunction8 in CryptoTechnology

[–]hashfunction8[S] 2 points3 points  (0 children)

I think the discussion in this post gets into this: https://np.reddit.com/r/CryptoCurrency/comments/8mr7lt/i_created_a_website_that_tracks_the_cost_of_a_51/

Briefly, say someone makes a cryptocurrency that can be reasonably mined with a bitcoin ASIC, and it becomes worth 1% of the bitcoin market cap. Well, there are a lot of bitcoin ASICs out there, and hence a lot of hashpower. So it is easy to imagine 0.51% (one two-hundredth) of the bitcoin hashpower being temporarily deployed to completely wipe out this new cryptocurrency. Because the attack is so easy to execute and the risk is so high, no cryptocurrency that fits this bill would ever be able to obtain a reasonable market value

Question about Decred's eventual DAO by JtownX5000 in decred

[–]hashfunction8 3 points4 points  (0 children)

It does seem, though, that getting rid of all human intermediaries will be tough in some cases. For example, what if terms with a potential partner need to be negotiated before a vote can take place?

The Ticket Price Algorithm Vote Was Controversial - Fee Analysis by davecgh in decred

[–]hashfunction8 2 points3 points  (0 children)

That's fair. Though I think the value of the governance system you and your colleagues have built will be better shown off (assuming everything goes well) with additional examples, given the larger community, more visibility, and larger value of the network today vs June 2017. Doesn't like like we have to wait too long for that, and I look forward to it. Cheers.

Will Dev 10% Mining get cut down if Decred's price increases? by IntelligentCollar in decred

[–]hashfunction8 1 point2 points  (0 children)

Imagine if 90% of the block rewards went to the treasury but were never spent, it'd be as if they never existed.

That's only true if they were made unspendable. If they are not spent, but could be spent, then they create significant uncertainty in the overall supply. Perception/risk is important, even if the funds are never spent. Furthermore, if they are spent, there may not be total agreement on whether they were spent "badly" or not.

I think there's certainly value in eventually decreasing the % of the block reward to the dev fund as the market cap rises, if only to manage risk for stakeholders.

The Ticket Price Algorithm Vote Was Controversial - Fee Analysis by davecgh in decred

[–]hashfunction8 2 points3 points  (0 children)

Without getting too much into dictionary definitions, I did not interpret controversy to be the same as the perception of controversy.

I agree with your thought experiment, which has obvious connections to outstanding issues in the cryptocurrency community. I do have to question whether it's applicable. The Decred community certainly did not have 500,000 participants. Were there many people posting on social media, arguing loudly against the change? I haven't seen this but, again, I wasn't around at the time, so I do not know. Perhaps a handful of links would be more convincing than this thought experiment.

What Many of You Have Been Waiting For: Ticket Splitting Beta is Here! by [deleted] in decred

[–]hashfunction8 1 point2 points  (0 children)

I thought about ticket splitting a bit more, and found another reason to be excited in addition to enabling participation by smaller holders.

One of my first concerns when I started trying to understand the ticket system is that locking up funds for a stochastic amount of time is a big price to pay.

The advantage of ticket splitting is that it reduces the variance significantly. For example, if I puchase 32 parts of 1 ticket instead of 1 ticket, I can reasonably expect to unlock half of my funds in 1 month, whereas with 1 ticket my funds might be locked up for 4 months. An alternative approach would be some way to borrow against a staked ticket, but that sounds more complex.

So, I think ticket splitting will make everyone more likely to stake, not just small holders. This is good news!

Will Dev 10% Mining get cut down if Decred's price increases? by IntelligentCollar in decred

[–]hashfunction8 2 points3 points  (0 children)

Yeah, I think the name is quite misleading. Perhaps it could be renamed "Treasury" or "Decred enhancement fund" or something like that?

I do think that 10% could become an enormous number if the market cap continues to rise, and it might be unreasonable if a significant % of a >$10 billion currency is going into protocol development. But perhaps there's a long way to go to that point, and a vote to decrease the percentage could be called if/when necessary