The procedure you need to follow is: 1. Load up the wallet, load up the buyer. 2. Load the config from decrediton/dcrwallet 3. Open the splitticketbuyer.conf file in a text editor. %LOCALAPPDATA%\splitticketbuyer . Modify the matcherhost address to do *not* reinitialize the config after manually editing the file Use session name "dcrbr1" Download the ticket splitter software from: The stakepool we are using is: Check Current Session Status:
Lymbit 888

Hugh. Somebody's using dcrdata instead of dcrstats?!

man that dcrdata page bugs me- isnt that a text descriptor error ? In the Input Column, the chart enumerates 'Previous Outpoint': isnt that incorrect? it bugs me every time... heh

Error reading config: open \AppData\Local\Splitticketbuyer\splitticketbuyer.conf: The system cannot find the path specified.

It would make sense from a testing standpoint...faster votes equals faster data

looking at our most recent ticket, we have another very lucky run

In regard to apparent luck with split ticketing on : 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)

Quick aside, I once made this graphic in an attempt to try to explain to a BCH big blocker what "linear scaling" actually meant. They were steadfast that increasing block size from 2mb to 32mb meant BCH was considered exponential scaling.

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.

Is this the main reason behind keeping tickets to 4.9k, as opposed to keeping price static and ticket pool dynamic? How much data does a ticket actually take up on the blockchain?

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)

can anyone estimate for me how much data I would use if I ran a 24/7 instance of decrediton?

Dang, looks like this ticket failed. Was showing it as unmined in my GUI last night, now its gone and I have my DCR back (minus the fee). Did this just not get mined into block or what? Weird thing is the ticket is still in the block explorer it seems.

Tudor Vacarel
Hi guys, what is stake reward ATM? And how.much is a ticket?
the best way to identify these stats is to check a block explorer: . 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: C:\Users\YourUserName\AppData\Local\Decrediton\wallets\mainnet\YourWalletName\logs\mainnet\dcrwallet

By default, all the session data, including the ticket hash, are stored in your user directory, so don't worry if you already closed it.


what is happening this ticket?

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?

ticket voted!
ticket voted!

104.2 -> the previous session is still pending.. or am I wrong?

You can also paste the ticket hash into and it will show a block number next to "included in block".Right now, it says "mempool" which means it's pending.

Do you have a file called "config.json" in C:\Users\\AppData\Local\Decrediton\wallets\mainnet\?

@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?

hey peeps... what do you think is best: 1. always stake all my DCR in one session or 2. divide my DCR into small portions and participate in multiple sessions?

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