- Open Source Governance
- Mining Pool
- Roadmap for next hard fork
- smoothing: missing 1 of 6 blocks negatively impacts performance
- missing blocks due to RBF and insufficient fees
Action Item: Create a test
Open Source Governance
- FYI current Stacks Improvement Proposals (SIPs) are moving from the to
- SIPs are
- can we request issues/fix priority?
- can we issue bounties for fixes?
- Stacks Governance is working
- master (stable release), develop(new features), next(new consensus) branch in github
Action Item: Create a SIP for sortition issue
- Using mulit-sig accounts is the current recommendation for pooling
- Daemon working on
Running a miner
- Your account requires at least two UTXO to run smoothly ()
- Your miner might spent BTC while syncing ()
- Workaround for using working_dir in config file, uses rsync to backup in rotation:
- could possibly end up on a fork? others recommend starting from scratch
- if using debug mode on Linux, rotatelogs is a good tool, example from user LNow:
- stacks-node start --config=config.toml 2>&1 | rotatelogs -v -e -n 5 logfilename 25M
- above method really useful when working with DEBUG enabled
- note: I’m seeing this as logrotate on Linux, not sure what the above version is, but similar concept, could be part of apache2-utils package as rotatelogs
- Data analysis?
- must have for a miner
- would be nice to link up with the bitcoin data (blockcypher has a nice free API)
- from Friedger
- faster bitcoin blocks it is more likely for smaller commits to win (data to “proof”?)
- Peter S: with the right configuration, everyone should face the same problem? So equal sortition?
- Peter S: I just want to point out that the theoretical and the actual wins smooth out nicely since the start.
- Does mining from a raspberry pi or lower-performant machine cause a disadvantage?
- slow cpu = blocks not reaching in time ?
- running bitcoind on a separate machine ?
- Mining Challenge part 3?
- still in planning, unclear