In regard to apparent luck with split ticketing on decredbrasil.com : this :emiliomann: stakebrasil is one of the pools with the lowest number of missed and expired tickets. It was one of the first and has a smaller percentage than the most recent ones who haven’t had the time to do so. (...) The Brazilian pool should be the one with the more servers spread around the world: 6 to decrease the latency. This is to explain to you why the [pool fee] rate of 5% (currently around 0.06 DCR) on the reward is also one of the highest.
girino: 8 voting wallets now. I just finished setting up a new one yesterday. All of them in different datacenters, 3 in europe, 3 in north america, 1 in brazil and one in asia. We also have 3 more servers, 1 for the front end, one for "stats" and one for dcrdata. (#general)
Exactly, we can "peg" offchain information into a blockchain and it is still immutable...similar to how Politeia and DCRTime work. Not everything in Politeia goes onchain...that would lead to bloat that other progects have. Not for Decred. By stamping a minimal time based hash of the relevant info you can store massive amounts of data that are tied to the chain without bloating it. LN for scaling transactions. Politeia for scaling the vote/proposal side of governance. Splitting and other solutions for scaling the vote/user side of governance.
Decred could add 10x the tickets by increasing the pool size 10x...but that just means 10x the data goes onchain. Not saying it's always the wrong choice...maybe as computer systems evolve and needs evolve increasing the data going in and eventually block size makes sense...and that could of course be voted in as well.
Anyway I seem to understand that lowering ticket prices would increase the amount of data stored onchain? Fair enough, but that's still problematic for adoption if split tickets have no real split vote. It's easy to hold DCR, but this is underselling the uniqueness of Decred if it's not really accessible for newcomers ( both voting and staking)
the best way to identify these stats is to check a block explorer: https://dcrdata.org . you will notice that DCR reward changes frequently. also you will become familiar with the math behind the stake cost, which changes more frequantly.
In the meantime, you can try to pull up your wallet logs to see exactly what it's doing. It should be in:
I completely agree David. Maintaining security and robustness is the key. For me this requires a balance of simplicity and effort. Complex path toward a solution: @ the pool operator level, we align split purchasers by voting preference. This seems preferable to alignment of investment weight. The pluses outweigh here, in that we increase our voter representation by a magnitude. With alignment, we can specify that splits must be purchased in multiples of the minimum unit. Doing so allows the software to represent "Voices" in the TotalTix*(Totaltix/MinSplitCost) range or 40960 * (40960/5.03)=335million ‘Voices’ versus 40960, range in optimal conditions. Understanding that this method leaves buying votes down to your net worth, it simultaneously enfranchises the ever more diluted small user. There are some big issues with this idea, but the core of it is that we didn't think we'd have to address governance and voting expense this early. To address this, we may have to think through how we Scale the governance, and we will apparently have to do so (scale), every time the current tix algo incentivizes users opting for splitting. Another incentive to split, is to decrease the amount of time the majority of your capital is locked. As the pricing algo increases the competition for tix, and thus price adjusts higher, the ‘cost effect’ will magnify the ‘time locked’ issue. That's an economic driver and will intensify cyclically many times in the future as the software grows, unless we coordinate the development of the pricing algo with the development of the splitting software. Simplicity tells me, that the plus to be gained yields an outcome worth the effort. Ultimately I'd like to see an environment of UI integration wherein users can see what's on the table, self-align into purchasing/voting cohorts, and we'd only be adding another UI/logic layer, and not rewrite anything fundamental. By aligning at the VSP layer, we create an 'easy to integrate into Decrediton' path, in that we model and test the logic outside of Decrediton, and then consider integration. Problems that I see are: security, anonymity, meta-data. It's got to be a cryptographic solution. I see the matching method as: hashing voting preferences, matching hashes and minimum contribution blocks, and developing a ‘mini- quorum’ on a ticket purchase event. Analogize this: Senators (full ticket holders) and Representatives (many voters in a pool). But GROK this: we attain DIRECT DEMOCRACY for a magnitude more users than we have now. It’s a complex path, and it’s hard to state the value of the goal. It’s very complicated to understand if this kind of Direct Representation is worth the effort. I feel the plus could become the topic of conversation and the goal. Sometimes implementing mainline beta drives out the problems. Sometimes it drives out the solutions. In this case, I hope we drive out the vision and the architecture, instead of implementing a ‘patch’ mentality. I have been intending to develop this talk here, amongst splitters and operators to give the conversation to the masses as it were. Done well, this might also yield high levels of community inertia.Thanks for listening, I’m really new to this project, and clearly, this is meant to provoke thought and contribution onto the idea of scaling our ability to represent group thought, intention, and effort. Engagement and Representation are some of the core issues that created Decred. That weighs on my mind often.Thoughts/feelings?
@o_rexy, I just found where splitticketbuyer pulls the username and password from. It's in C:\Users\\AppData\Local\Dcrd\dcrd.conf. It's the "rpcuser" line. Maybe try copying what it says in there and pasting it into splitticketbuyer.conf in the DcrdUser variable?
The others have had some solid feedback, but I wanted to add some numbers about fees. Fees are specified as a "fee rate" in terms of transaction size in kilobytes. Currently everyone is using the fee "rate" of 0.001 DCR per kB. The tickets with the lowest fees are always going to be full solo tickets because there's not a lot of data going into the transaction of a full ticket purchase.Then, a full ticket purchased via a VSP is going to have a slightly larger fee because now you're including more data in the purchase transaction, which makes for a larger transaction size in kB.Then, a split ticket is going to have the largest fee because of all the individual parties' wallets involved, the VSP, etc. Much more data is included, so a bigger transaction size is to be expected.Even with all this in mind:A full solo ticket fee is around 0.0003 DCR.A full VSP ticket fee is approximately 0.00055 DCR.A 4-way split ticket fee is approximately 0.001282 DCR.All of these fee examples came from real tickets on the chain where the fee rate was approximately 0.00101 DCR/kB