dcr-split-ticket-matcher VS dcps

Also, why do you use term "ticket splitting", if it is widely known in the community as a non-custodial service powered by dcr-split-ticket-matcher? I think it may mislead some people to think BisonPool is also non-custodial, at least until they do due research.

The beta and design docs outlined a bunch of unsolved game-theoretic issues. I guess those were a factor for not putting more work into it.

In the more distant future, an exciting thing will be LN-based Multi-Owner Tickets. This will significantly lower the barrier to staking (without the drawbacks of the first iteration) of ticket splitting).

One was linked from matheusd's matcher repo:

If you are more generally referring to nodes, there are a few wallet-like lightweight implementations based on Decred's rather secure implementation of Block Header Commitments.

4) At around 4:06, technically the bits you described about the stake root aren't really accurate anymore either as of DCP0005 - Block Header Commitments, but it is correct prior to that point. After the activation of DCP0005, the stake root field has been repurposed to commit to data such as compact filters.

Change PoW/PoS Subsidy Split Agenda ID: #changesubsidysplit https://github.com/decred/dcps/blob/master/dcp-0010/dcp-0010.mediawiki Change block reward subsidy split to 10/80/10 as defined in DCP0010 Proposal to modify the block reward subsidy split such that 10% goes to Proof-of-Work and 80% goes to Proof-of-Stake.

Fix for treasury expenditure policy bug (DCP-7) will allow us to spend from the new treasury with reasonable protections from over-spending.

If you want the low level details of how it all works see this: https://github.com/decred/dcps/blob/master/dcp-0001/dcp-0001.mediawiki

As can be seen on the voting site, the first phase voting process is now complete and therefore voting on the decentralized treasury consensus change will start at block 536320, which is in approximately a week and a half from the time this is being posted.

No, hard forks are a normal part of the upgrade process in Decred for making changes to the consensus rules. In this particular case, it enables a Decentralized Treasury. See DCP0006 for details.

At this point, all consensus changes must be accompanied by a highly detailed technical specification in the form a Decred Change Proposal and the code must be fully tested and vetted by people with years of experience coding for blockchain consensus rules at this point before it would be merged to master.

It really depends on your definition of smart contract, I'd say yes though, and this contract actually required adding a new op code (changing consensus rules). https://github.com/decred/dcps/blob/master/dcp-0006/dcp-0006.mediawiki

On the other hand, if you're looking for the exact details on how it's happening, see the Specification section.