WafflePool is a multi-coin (scrypt) mining pool. Point your miner to WafflePool with a Bitcoin address as your username, and we take care of automatically mining the most profitable coin at all times, converting the earnings from each coin into Bitcoins, and paying you out in bitcoins! Mining alt-coins and converting to bitcoin is very often orders of magnitude more valuable than mining Bitcoin directly! No registration, no hassles, just point and start getting paid!
Bitcoin mining is analogous to the mining of gold, but its digital form. The process involves specialized computers solving algorithmic equations or hash functions. These problems help miners to confirm blocks of transactions held within the network. Bitcoin mining provides a reward for miners by paying out in Bitcoin in turn the miners confirm transactions on the blockchain. Miners introduce new Bitcoin into the network and also secure the system with transaction confirmation.
It seems like extremely large mining pools are causing some political issues with bitcoin, I am wondering how Ethereum plans to address this issue. It looks like it has to do with Proof of Work vs Proof of Stake but I am not sure. Can someone explain this to me? Thanks in advance! submitted by
https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/184.108.40.206 submitted by
Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that.
Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap.
We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout.
Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.
Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now.
Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER
the v11 transition (around Oct 4th) and BEFORE
October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date.
The transition height is also when the team requirement will be relaxed for the network.
Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.
The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use.
There are so many goodies here it is hard to summarize them all.
I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures.
The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!
Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.
- Network magnitude unit pinned to a static value of 0.25
- Max research reward allowed per block raised to 16384 GRC (from 12750 GRC)
- New CPIDs begin accruing research rewards from the first superblock that contains the CPID instead of from the time of the beacon advertisement
- 500 GRC research reward limit for a CPID's first stake
- 6-month expiration for unclaimed rewards
- 10-block spacing requirement between research reward claims
- Rolling 5-day payment-per-day limit
- Legacy tolerances for floating-point error and time drift
- The need to include a valid copy of a CPID's magnitude in a claim
- 10-block emission adjustment interval for the magnitude unit
- One-time beacon activation requires that participants temporarily change their usernames to a verification code at one whitelisted BOINC project
- Verification codes of pending beacons expire after 3 days
- Self-service beacon removal
- Burn fee for beacon advertisement increased from 0.00001 GRC to 0.5 GRC
- Rain addresses derived from beacon keys instead of a default wallet address
- Beacon expiration determined as of the current block instead of the previous block
- The ability for developers to remove beacons
- The ability to sign research reward claims with non-current but unexpired beacons
As a reminder:
- Beacons expire after 6 months pass (180 days)
- Beacons can be renewed after 5 months pass (150 days)
- Renewed beacons must be signed with the same key as the original beacon
- Magnitudes less than 1 include two fractional places
- Magnitudes greater than or equal to 1 but less than 10 include one fractional place
- A valid superblock must match a scraper convergence
- Superblock popularity election mechanics
- Yes/no/abstain and single-choice response types (no user-facing support yet)
- To create a poll, a maximum of 250 UTXOs for a single address must add up to 100000 GRC. These are selected from the largest downwards.
- Burn fee for creating polls scaled by the number of UTXOs claimed
- 50 GRC for a poll contract
- 0.001 GRC per claimed UTXO
- Burn fee for casting votes scaled by the number of UTXOs claimed
- 0.01 GRC for a vote contract
- 0.01 GRC to claim magnitude
- 0.01 GRC per claimed address
- 0.001 GRC per claimed UTXO
- Maximum length of a poll title: 80 characters
- Maximum length of a poll question: 100 characters
- Maximum length of a poll discussion website URL: 100 characters
- Maximum number of poll choices: 20
- Maximum length of a poll choice label: 100 characters
- Magnitude, CPID count, and participant count poll weight types
- The ability for developers to remove polls and votes
[220.127.116.11] 2020-09-03, mandatory, "Fern"
- Backport newer uint256 types from Bitcoin #1570 (@cyrossignol)
- Implement project level rain for rainbymagnitude #1580 (@jamescowens)
- Upgrade utilities (Update checker and snapshot downloadeapplication) #1576 (@iFoggz)
- Provide fees collected in the block by the miner #1601 (@iFoggz)
- Add support for generating legacy superblocks from scraper stats #1603 (@cyrossignol)
- Port of the Bitcoin Logger to Gridcoin #1600 (@jamescowens)
- Implement zapwallettxes #1605 (@jamescowens)
- Implements a global event filter to suppress help question mark #1609 (@jamescowens)
- Add next target difficulty to RPC output #1615 (@cyrossignol)
- Add caching for block hashes to CBlock #1624 (@cyrossignol)
- Make toolbars and tray icon red for testnet #1637 (@jamescowens)
- Add an rpc call convergencereport #1643 (@jamescowens)
- Implement newline filter on config file read in #1645 (@jamescowens)
- Implement beacon status icon/button #1646 (@jamescowens)
- Add gridcointestnet.png #1649 (@caraka)
- Add precision to support magnitudes less than 1 #1651 (@cyrossignol)
- Replace research accrual calculations with superblock snapshots #1657 (@cyrossignol)
- Publish example gridcoinresearch.conf as a md document to the doc directory #1662 (@jamescowens)
- Add options checkbox to disable transaction notifications #1666 (@jamescowens)
- Add support for self-service beacon deletion #1695 (@cyrossignol)
- Add support for type-specific contract fee amounts #1698 (@cyrossignol)
- Add verifiedbeaconreport and pendingbeaconreport #1696 (@jamescowens)
- Add preliminary testing option for block v11 height on testnet #1706 (@cyrossignol)
- Add verified beacons manifest part to superblock validator #1711 (@cyrossignol)
- Implement beacon, vote, and superblock display categories/icons in UI transaction model #1717 (@jamescowens)
- neuralnet: Add integrity checking to researcher accrual snapshot registry #1727 (@jamescowens)
- Add workaround for scrypt assembly on macOS #1740 (@cyrossignol)
- gui: Build onboarding/beacon wizard #1739 (@cyrossignol)
- doc: Add CONTRIBUTING.md from bitcoin #1723 (@div72)
- rpc: Implement inspectaccrualsnapshot and parseaccrualsnapshotfile #1744 (@jamescowens)
- scraper: Add disk based state backing for verified beacon list in scraper #1751 (@jamescowens)
- Add ability to recover beacon in block version 11+ #1768 (@cyrossignol)
- refactor: Add transaction context to contract handlers #1777 (@cyrossignol)
- gui: Add context for when BOINC is attached to a pool #1775 (@cyrossignol)
- doc: Clarify what to do if PR in multiple categories (for CONTRIBUTING.md) #1798 (@RoboticMind)
- qt: Add option to choose not to start the wallet minimized #1804 (@jamescowens)
- superblock: Add check for OutOfSyncByAge to SuperblockValidator::Validate #1806 (@jamescowens)
- contract: Standardize contract validation and add block context #1808 (@cyrossignol)
- add seed.gridcoin.pl to default config #1812 (@wilkart)
- gui: Implement sidestake send display #1813 (@jamescowens)
- gui: Add pool/investor pages to researcher wizard #1819 (@cyrossignol)
- ci: Port lint scripts from Bitcoin #1823 (@div72)
- doc: Create basic readme in contrib #1826 (@RoboticMind)
- gui: Implement TransactionRecord::Message #1829 (@jamescowens)
- rpc: Add private_key_available to beaconstatus #1833 (@a123b)
- gui: Validate email address in researcher wizard #1840 (@a123b)
- rpc: Add "getrawwallettransaction" RPC function #1842 (@cyrossignol)
- consensus: Set block version 11 threshold height for mainnet #1862 (@cyrossignol)
- Upgrade LevelDB from v1.17 to v1.20 #1562 (@cyrossignol)
- Re-enable scrypt optimizations #1450 (@denravonska)
- Derive CScript from prevector type (optimization) #1554 (@cyrossignol)
- Disable quorum for grandfathered blocks to speed up sync #1568 (@cyrossignol)
- Refactor hashBoinc for binary claim contexts #1558 (@cyrossignol)
- integrated_scraper_2 branch tracking PR #1559 (@jamescowens)
- Upgrade depends - OpenSSL to 1.1.1d #1581 (@jamescowens)
- Ubuntu 19.10 fixes #1590 (@denravonska)
- Force a re-parse of legacy claims in generated blocks #1592 (@cyrossignol)
- Improve the "versionreport" RPC output #1595 (@cyrossignol)
- Overhaul the core tally and accrual system #1583 (@cyrossignol)
- Overhaul the superblock quorum system #1597 (@cyrossignol)
- Add more data to the "superblocks" RPC output #1599 (@cyrossignol)
- Update Windows Build doc #1606 (@barton2526)
- Change the order of calls in gridcoinresearchd.cpp to optimize rpc shunt path #1610 (@jamescowens)
- Change staking tooltip to display frequency #1611 (@jamescowens)
- Enhancements to ETTS #1442 (@jamescowens)
- Standardize money values as integers #1614 (@cyrossignol)
- Clean up and optimize legacy coin age code #1616 (@cyrossignol)
- Some scraper cleanups #1620 (@jamescowens)
- Reorganize accrual code and fix 6-month cutoff #1630 (@cyrossignol)
- Update Copyright years #1633 (@barton2526)
- Change team whitelist delimiter to <> for CPID detection #1634 (@cyrossignol)
- Change team whitelist separator to <> to accomodate more team names #1632 (@jamescowens)
- Change Curl download speed type to support older environments #1640 (@cyrossignol)
- Optimize logo SVGs used for tray icons #1638 (@cyrossignol)
- Tweak consolidateunspent rpc function #1644 (@jamescowens)
- ETTS and staking icon enhancements #1650 (@jamescowens)
- Implement new transaction fees for block version 11 #1652 (@jamescowens)
- Optimize in-memory storage of superblock data #1653 (@cyrossignol)
- Miscellaneous superblock API improvements and housekeeping #1654 (@cyrossignol)
- Update openssl to 1.1.1f compatibility #1660 (@jamescowens)
- Optimize bdb to avoid synchronous flush of database #1659 (@jamescowens)
- Add support for CPID input to "lifetime" RPC function #1668 (@cyrossignol)
- Overhaul the contract handling system #1669 (@cyrossignol)
- Make the autostart mainnet/testnet aware #1671 (@jamescowens)
- Remove slashes from User Agent in peers tab #1674 (@div72)
- Refactor contracts for polymorphic binary payloads #1676 (@cyrossignol)
- Overhaul the beacon system #1678 (@cyrossignol)
- Replace boost::optional with non-owning pointers #1680 (@cyrossignol)
- Optimize proof-of-stake validation #1681 (@cyrossignol)
- Updated Slack link #1683 (@NeuralMiner)
- Update build-unix.md #1686 (@Quezacoatl1)
- Replace deprecated QT methods #1693 (@Pythonix)
- Made protocol.h more similar to bitcoin #1688 (@Pythonix)
- Touch up some details for block version 11 #1697 (@cyrossignol)
- More tweaks for block version 11 #1700 (@cyrossignol)
- Finish the conversion to the BCLog class based logger #1699 (@jamescowens)
- Move claim version transitional code in miner for proper signature #1712 (@cyrossignol)
- doc: Update threads in coding.txt #1730 (@div72)
- qt: Include QPainterPath in trafficgraphwidget.cpp #1733 (@div72)
- doc: Update doc/build-unix.md #1731 (@div72)
- gui: Show peers tab on connections icon click #1734 (@div72)
- refactor: Change return type of IsMine to isminetype && move wallet files to wallet directory #1722 (@div72)
- build: Updates boost to 1.73.0 for depends #1673 (@jamescowens)
- doc: Update Unit Test Readme #1743 (@RoboticMind)
- wallet: Change Assert To Error Message In kernel.cpp #1748 (@RoboticMind)
- scraper: Shorten display representation of verification codes #1754 (@cyrossignol)
- log: Change ".B." to Clear Message #1758 (@RoboticMind)
- util: Fix braindamage in GetDefaultDataDir() #1737 (@jamescowens)
- scraper: Improve scraper processing of beacon verifications #1760 (@jamescowens)
- scraper: Add instrumentation to convergencereport #1763 (@jamescowens)
- rpc: Improve rpc stress test script #1767 (@tunisiano187)
- Generalize enum serialization #1770 (@cyrossignol)
- scraper: Improve handling of ETags in http class and tweak verified beacon logic #1776 (@jamescowens)
- scraper: Improve ProcessNetworkWideFromProjectStats and other tweaks #1778 (@jamescowens)
- researcher: Automate beacon advertisement for renewals only #1781 (@cyrossignol)
- gui: Tweak behavior of beacon page in researcher wizard #1784 (@cyrossignol)
- Prepare for block version 11 hard-fork on testnet #1787 (@cyrossignol)
- scraper: Modify UpdateVerifiedBeaconsFromConsensus #1791 (@jamescowens)
- gui: Optimize OverviewPage::updateTransactions() #1794 (@jamescowens)
- ci: Adopt ci changes from Bitcoin #1795 (@div72)
- consensus: switch snapshot accrual calculation to integer arithmetic #1799 (@cyrossignol)
- voting: Overhaul the voting system #1809 (@cyrossignol)
- contract: Optimize contract replay after chain reorganization #1815 (@cyrossignol)
- contract: Reimplement transaction messages as contracts #1816 (@cyrossignol)
- staking: Sign claim contracts with coinstake transaction #1817 (@cyrossignol)
- gui: Change research wizard text #1820 (@div72)
- net: Update protocol version and clean up net messaging #1824 (@cyrossignol)
- rpc, wallet: Corrections to GetAmounts #1825 (@jamescowens)
- gui: Tweak some minor researcher wizard details #1830 (@cyrossignol)
- gui: Change GetEstimatedStakingFrequency text #1836 (@jamescowens)
- scraper: Scraper global statistics cache optimization #1837 (@jamescowens)
- doc: Update Vulnerability Response Process #1843 (@RoboticMind)
- scraper: Optimization of manifest and parts sharing between ConvergedScraperStatsCache, mapManifest, and mapParts #1851 (@jamescowens)
- consensus: Update Checkpoints #1855 (@barton2526)
- docs: Update docs to build off master #1856 (@barton2526)
- gui: Fix and improve GUI combo box styles #1858 (@cyrossignol)
- build: Tweak Gridcoin installer for Fern release #1863 (@jamescowens)
- Remove old research age checks (rebase #1365) #1572 (@cyrossignol)
- Remove PrimaryCPID check from diagnostics dialog #1586 (@cyrossignol)
- Remove missed label for PrimaryCPID from diagnostics #1588 (@cyrossignol)
- Remove legacy quorum messaging system (@neural network) #1589 (@cyrossignol)
- Remove old remnants of legacy smart contract experiments #1594 (@cyrossignol)
- Remove block nonce for version 11 #1622 (@cyrossignol)
- Delete obsolete contrib/Installer and Upgrader directories #1623 (@jamescowens)
- Remove redundant LoadAdminMessages() calls #1625 (@cyrossignol)
- Remove some legacy informational RPC commands #1658 (@cyrossignol)
- Remove informational magnitude field from binary claims #1661 (@cyrossignol)
- Remove fDebug3,4, and net and convert to BCLog::LogFlags #1663 (@jamescowens)
- Remove qt5.7.1 depends support build System #1665 (@iFoggz)
- Remove unused jQuery library #1679 (@cyrossignol)
- Remove unused NetworkTimer() function and global state #1701 (@cyrossignol)
- Refactor claim context objects into contracts #1704 (@cyrossignol)
- Clean old assets up #1718 (@div72)
- Remove legacy "rain" RPC (not by-project rain) #1742 (@cyrossignol)
- Temporarily disable voting system on testnet #1769 (@cyrossignol)
- gui: Remove legacy GUI transaction description for contracts #1772 (@cyrossignol)
- gui: Remove transaction fee setting #1780 (@cyrossignol)
- trivial: Cleanup unused legacy functions #1793 (@cyrossignol)
- mining, rpc: Remove kernel-diff-best and kernel-diff-sum #1796 (@jamescowens)
- refactor: Remove libs subdirectory #1802 (@div72)
- scraper: cleanup unused/unnecessary functions #1803 (@jamescowens)
- gui: Remove useless "Detach databases at shutdown" #1810 (@jamescowens)
- test: Remove testnet condition for standard transactions #1814 (@cyrossignol)
- consensus: Remove transitional testnet code #1854 (@cyrossignol)
- Fix "Owed" amount in output of "magnitude" RPC method #1569 (@cyrossignol)
- Add support for paths with special characters on Windows #1571 (@cyrossignol)
- Fix lingering peers.dat temp files and clean up remaining paths #1582 (@cyrossignol)
- Fix incorrect beacon length warning in GUI transaction list #1585 (@cyrossignol)
- Fix default config file line endings on Windows #1587 (@cyrossignol)
- Reenable Travis builds for MacOS #1591 (@jamescowens)
- Correct peer detail info background color #1593 (@jamescowens)
- Fix exception in debug3 mode #1598 (@cyrossignol)
- Fix deadlock in "getmininginfo" RPC function #1596 (@cyrossignol)
- Fix accuracy of statistics in "network" RPC output #1602 (@cyrossignol)
- Fix heights for quorum vote weight calculations #1604 (@cyrossignol)
- Fix deadlock in log archiver when rename fails #1607 (@cyrossignol)
- Fix a spurious segmentation fault during client load on Windows with fast CPUs #1608 (@jamescowens)
- Fix lock order debugging and potential deadlocks #1612 (@jamescowens)
- Add dependencies #1613 (@Scalextrix)
- Fix std namespace pollution #1617 (@denravonska)
- Add missing condition for newbie accrual computer #1618 (@cyrossignol)
- Track first reward blocks in research accounts #1619 (@cyrossignol)
- Fix lingering beacon warning after advertisement #1627 (@cyrossignol)
- Fix accrual calculation for new, zero-magnitude CPIDs #1636 (@cyrossignol)
- Fix diagnostics, add ETTS test, fix tooltipcolor, add missing lock, and add email=investor check #1647 (@jamescowens)
- Fix help message of two RPC methods #1656 (@div72)
- Fix legacy accrual for newbie with non-zero past reward #1667 (@cyrossignol)
- Fix GUI autostart on Windows for paths with wide characters #1670 (@cyrossignol)
- Qualify boost bind placeholders with their full namespace #1672 (@Ponce)
- Fix suffix when copying txids #1677 (@div72)
- Unnecessary if-statement removed #1685 (@Pythonix)
- Fix consolidatemsunspent Help Message #1687 (@Pythonix)
- Fix gettransaction help message #1691 (@Pythonix)
- Fix GetNewMint To Look for Stakes #1692 (@RoboticMind)
- Suppress deprecated copy warnings for Qt with GCC 9+ #1702 (@cyrossignol)
- Fix exclusion error on stats processing and misplaced ENDLOCK logging entry #1710 (@jamescowens)
- Removed unnecessary comparison #1708 (@Pythonix)
- Fixed typo #1707 (@Pythonix)
- Fix out-of-bounds exception for peers tab version slashes #1713 (@cyrossignol)
- Fix transition for v1 superblocks when reorganizing #1714 (@cyrossignol)
- Touch up transition to version 2 transactions #1715 (@cyrossignol)
- Avoid mutating transactions in ConnectBlock() #1716 (@cyrossignol)
- Skip beacon advertisement when already pending #1726 (@cyrossignol)
- Fix Windows cross-compilation in newer environments #1728 (@cyrossignol)
- Fix out-of-bounds access in IsMineInner() #1736 (@cyrossignol)
- Fix a couple of block version 11 issues #1738 (@cyrossignol)
- Fix null pointer dereference in GUI researcher model #1741 (@cyrossignol)
- accrual: Reset research accounts when rebuilding accrual snapshots #1745 (@cyrossignol)
- scraper: Correct update for verified beacons #1747 (@jamescowens)
- accrual: Refactor tally initialization for snapshot rebuild #1749 (@cyrossignol)
- rpc: Fix "cpid" field in "beaconconvergence" RPC output #1750 (@cyrossignol)
- accrual: Fix snapshot accrual superblock state transitions #1752 (@cyrossignol)
- scraper: Correct stale verified beacon logic #1753 (@jamescowens)
- rpc: Correct possible divide by zero in getblockstats #1755 (@jamescowens)
- gui: Fix issues with researcher wizard flow #1756 (@cyrossignol)
- wallet: Stop Error When Starting From Zero #1759 (@RoboticMind)
- Don't count empty email as explicit investor #1761 (@cyrossignol)
- accrual: Fix snapshot accrual superblock state transitions #1764 (@cyrossignol)
- rpc: Cleanup Help Message and Fix Typo #1771 (@RoboticMind)
- scraper: Fix scraper etag header case sensitivity #1773 (@cyrossignol)
- consensus: Use explicit time to check if superblock needed #1774 (@cyrossignol)
- gui: Fix scroll area dark theme styles #1785 (@cyrossignol)
- rpc, gui: Fix three divide by zero possibilities #1789 (@jamescowens)
- rpc: Fix balance pre-check in "rainbymagnitude" RPC #1792 (@cyrossignol)
- accrual: Fix outdated comment and correct grammar #1800 (@RoboticMind)
- gui: Fix stuck cursor on labels #1801 (@div72)
- beacon: Fix research wizard beacon renewal status #1805 (@cyrossignol)
- gui: Fix translations for port numbers #1818 (@cyrossignol)
- util: Create parent directory #1821 (@div72)
- mining: Fix coinstake/claim signature order #1828 (@cyrossignol)
- voting: Remove double increment in loop #1831 (@cyrossignol)
- neuralnet, scraper: Fix compilation with gcc5 and older libcurl #1832 (@a123b)
- wallet: Fix smallest coin selection for contracts #1841 (@cyrossignol)
- gui: Fix display of polls with no votes yet #1844 (@cyrossignol)
- gui: add indentation to diagnostic status bar labels #1849 (@jamescowens)
- voting, gui: Fix formatting and alignment of vote shares and percent #1850 (@jamescowens)
- wallet, rpc: Fix for self-transactions in listtransactions #1852 (@jamescowens)
- accrual: Clear any accrual snapshots when syncing from pre-v11 #1853 (@cyrossignol)
- accrual: Fix reset of accrual directory if starting sync below research age height #1857 (@jamescowens)
- gui: Fix researcher wizard layout on macOS with native theme #1860 (@cyrossignol)
This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else
wants it, but why would I
, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else
because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
- You the HODLer should be the one who controls where your money goes. Your keys, your coins.
- You the HODLer should be able to coordinate and make contracts with other people regarding your funds.
- You the HODLer should be able to do the above without anyone watching over your shoulder and judging you.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can
get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?
Taproot and Your /Coins
Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single
public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single
signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a soft
fork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least
2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally
. First do no harm!
Taproot and Your Contracts
No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables
more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow
, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also
get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).
Taproot and Your Contracts, Part 2: Cryptographic Boogaloo
Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
- Privacy. Everyone scraping the Bitcoin blockchain can see any HTLCs, and preimages used to claim them.
- This can be mitigated by using offchain techniques so HTLCs are never published onchain in the happy case. Lightning would probably in practice be the easiest way to do this offchain. Of course, there are practical limits to what you can pay on Lightning. If you are buying something expensive, then Lightning might not be practical. For example, the "software" you are activating is really the firmware of a car, and what you are buying is not the software really but the car itself (with the activation of the car firmware being equivalent to getting the car keys).
- Even offchain techniques need an onchain escape hatch in case of unresponsiveness! This means that, if something bad happens during payment, the HTLC might end up being published onchain anyway, revealing the fact that some special contract occurred.
- And an HTLC that is claimed with a preimage onchain will also publicly reveal the preimage onchain. If that preimage is really the activation key of a software than it can now be pirated. If that preimage is really the activation key for your newly-bought cryptographic car --- well, not your keys, not your car!
- Trust requirement. You are trusting the developer that it gives you the hash of an actual valid activation key, without any way to validate that the activation key hidden by the hash is actually valid.
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra
. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given public key to you.
Another nice thing with PTLCs is that they are deniable
. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature
) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
- Privacy: PTLCs are private even if done onchain. Nobody else can learn what the private key behind the public key is, except you who knows the adaptor signature that when combined with the complete onchain signature lets you know what the private key of the activation key is. Somebody scraping the blockchain will not learn the same information even if all PTLCs are done onchain!
- Lightning is still useful for reducing onchain use, and will also get PTLCs soon after Taproot is activated, but even if something bad happens and a PTLC has to go onchain, it doesn't reveal anything!
- Trust issues can be proven more easily with a public-private keypair than with a hash-preimage pair.
- For example, the developer of the software you are buying could provide a signature signing a message saying "unlock access to the full version for 1 day". You can check if feeding this message and signature to the program will indeed unlock full-version access for 1 day. Then you can check if the signature is valid for the purported pubkey whose private key you will pay for. If so, you can now believe that getting the private key (by paying for it in a PTLC) would let you generate any number of "unlock access to the full version for 1 day" message+signatures, which is equivalent to getting full access to the software indefinitely.
- For the car, the manufacturer can show that signing a message "start the engine" and feeding the signature to the car's fimrware will indeed start the engine, and maybe even let you have a small test drive. You can then check if the signature is valid for the purported pubkey whose privkey you will pay for. If so, you can now believe that gaining knowledge of the privkey will let you start the car engine at any time you want.
- (pedantry: the signatures need to be unique else they could be replayed, this can be done with a challenge-response sequence for the car, where the car gathers entropy somehow (it's a car, it probably has a bunch of sensors nowadays so it can get entropy for free) and uses the gathered entropy to challenge you to sign a random number and only start if you are able to sign the random number; for the software, it could record previous signatures somewhere in the developer's cloud server and refuse to run if you try to replay a previously-seen signature.)
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)
Now if you were really
paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from
a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from
a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from
the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
- Current quantum computers can barely crack prime factorization problem for primes of 5 bits.
- The 256-bit elliptic curve use by Bitcoin is, by my (possibly wrong) understanding, equivalent to 4096-bit primes, so you can see a pretty big gap between now (5 bit primes) and what is needed (4096 bit primes).
- A lot of financial non-Bitcoin systems use the equivalent of 3072-bit primes or less, and are probably easier targets to crack than the equivalent-to-4096-bit-primes Bitcoin.
- Quantum computers capable of cracking Bitcoin are still far off.
- Pay-to-public-key-hash is not as protective as you might think.
- We will probably see banks get cracked before Bitcoin, so the banking system is a useful canary-in-a-coal-mine to see whether we should panic about being quantum vulnerable.
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).
- If you are a singlesig HODL-only Bitcoin user, Taproot will not affect you positively or negatively. Importantly: Taproot does no harm!
- If you use or intend to use multisig, Taproot will be a positive for you.
- If you transact onchain regularly using typical P2PKH/P2WPKH addresses, you get a minor reduction in feerates since multisig users will likely switch to Taproot to get smaller tx sizes, freeing up blockspace for yours.
- If you are using multiparticipant setups for special systems of trade, Taproot will be a positive for you.
- Remember: Lightning channels are multipartiicpiant setups for special systems of lightning-fast offchain trades!
I Wanna Be The Taprooter!
So, do you want to help activate Taproot? Here's what you
, mister sovereign Bitcoin HODLer, can do!
- If you have developer experience especially in C, C++, or related languages
- Review the Taproot code! There is one pull request in Bitcoin Core, and one in libsecp256k1. I deliberately am not putting links here, to avoid brigades of nontechnical but enthusiastic people leaving pointless reviews, but if you are qualified you know how to find them!
- But I am not a cryptographeBitcoin Core contributomathematician/someone as awesome as Pieter Wuille
- That's perfectly fine! The cryptographers have been over the code already and agree the math is right and the implementation is right. What is wanted is the dreary dreary dreary software engineering: are the comments comprehensive and understandable? no misspellings in the comments? variable names understandable? reasonable function naming convention? misleading coding style? off-by-one errors in loops? conditions not covered by tests? accidental mixups of variables with the same types? missing frees? read-before-init? better test coverage of suspicious-looking code? missing or mismatching header guards? portability issues? consistent coding style? you know, stuff any coder with a few years of experience in coding anything might be able to catch. With enough eyes all bugs are shallow!
- If you are running a mining pool/mining operation/exchange/custodial service/SPV server
- Be prepared to upgrade!
- One of the typical issues with upgrading software is that subtle incompatibilities with your current custom programs tend to arise, disrupting operations and potentially losing income due to downtime. If so, consider moving to the two-node setup suggested by gmax, which is in the last section of my previous post. With this, you have an up-to-date "public" node and a fixed-version "private" node, with the public node protecting the private node from any invalid chainsplits or invalid transactions. Moving to this setup from a typical one-node setup should be smooth and should not disrupt operations (too much).
- If you are running your own fullnode for fun or for your own wallet
- Be prepared to upgrade! The more nodes validating the new rules (even if you are a non-mining node!), the safer every softfork will be!
- If you are using an SPV wallet or custodial wallet/service (including hardware wallets using the software of the wallet provider)
- Contact your wallet provider / SPV server and ask for a statement on whether they support Taproot, and whether they are prepared to upgrade for Taproot! Make it known to them that Taproot is something you want!
But I Hate Taproot!!
- Raise your objections to Taproot now, or forever hold your peace! Maybe you can raise them here and some of the devs (probably nullc, he goes everywhere, even in rbtc!) might be able to see your objections! Or if your objections are very technical, head over to the appropriate pull request and object away!
- Maybe you simply misunderstand something, and we can clarify it here!
- Or maybe you do have a good objection, and we can make Taproot better by finding a solution for it!
Discussions About Taproot Activation
This is because all Bitcoin mining pools will ask you for a Bitcoin address that will be used to send your mining rewards and payouts. Our guide on the best bitcoin wallets will help you get a wallet. Read the full guide. The Biggest Mining Pools. The list below details the biggest Bitcoin mining pools. This is based on info from Blockchain’s pool share chart: We strongly recommend new ... If you want to start bitcoin mining, then the answer right now is to join the bitcoin mining pool and get the most profit. The main benefit of bitcoin mining cloud is you don’t have to manage any hardware or software yourself. You only have to join the bitcoin cloud mining pool, and you will be assigned mining power with you can start your mining at your home. MineBTC is an industry leading Bitcoin mining pool. All of the mining power is backed up by physical miners. Mining with the latest algorithms allows to make as much Bitcoin as possible. We aim to provide you with the easiest possible way to make money without having to do any of the hard stuff. With data centers around the globe, we aim to keep bills down and mining power high, meaning you ... Login to your account. Invalid password or username. Forgot password? Slush Pool is the 1st mining pool with more than 1.2M BTC mined since 2010. Explore features such as advanced payouts, monitoring and more.
BTC.com is a popular block explorer bitcoin mining pool. This tutorial will demonstrate how to mine bitcoin on btc.com mining pool. #bitcoin #miningpool #cry... Coinbase Wallet: https://www.coinbase.com/join/5a87ecac52a16c066e6760c3 Blockchain wallet: https://blockchain.info/fr/wallet/#/login Coinpaiments Wallet: htt... Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube. Bitcoin mining pool slushpool offers a new AI and a powerful dashboard. This tutorial will demonstrate how you can setup a worker on slushpool to mine bitcoi... What it really takes to mine a Bitcoin in 10 Minutes. Firstly I'll show you a special free method to mine Bitcoin and send funds directly to your wallet in 1...