Published on: 2013-06-17T17:39:42+00:00
The email thread discusses proposals for improving the prioritization of transactions in Bitcoin mining. One suggestion is to delay broadcasting INV messages until child transactions with higher fees are found. Another proposal is to include fee/kb information in INV advertisements sent to peers. The discussion also addresses the suboptimal way new blocks are communicated to peers and suggests prioritizing fast peers and investigating the network-wide costs of broadcasting block header + coinbase TX + TX list to opt-in miners.In a conversation between Peter Todd and Luke-Jr, they discuss the practice of using one share per second in pools, suggesting higher difficulty shares instead. They also discuss P2Pool-like solutions where only a subset of shares are sent to the pool. The importance of auditing and troubleshooting in mining operations is mentioned, as well as eliopool's ability to accept arbitrary shares and possible protocol extensions.To reduce bandwidth in mining, suggestions include sending only the block header for normal shares and randomly auditing a subset of transactions. The possibility of using higher difficulty shares that are audited is also discussed. The discussion emphasizes the need for proper prioritization and fee/kb information in INV advertisements. It is recommended to sort peer lists based on #inv-received/time for optimal flood-fill/gossip algorithms.Peter Todd's ideas for pooled mining and solo mining implementation involve making two connections - to the pool and a local bitcoind. Miners work on the subset of transactions common to both getblocktemplate and the local one. Shares that don't meet difficulty are handed over to the pool, while shares that meet difficulty are handed over to both the pool and the local bitcoind. Suggestions are made to optimize this process by handing over transaction hashes where possible. Bandwidth reduction suggestions include passing only the block header for normal shares and randomly auditing a subset of transactions.The email dated June 10, 2013, discusses the protocol work for miners, focusing on the connections between the miner, pool, and local bitcoind. The process of working on common transaction subsets and handing over shares based on difficulty is explained. Suggestions are made to reduce bandwidth by passing only the block header for normal shares and randomly auditing a subset of transactions. The intentional orphaning of slow-to-propagate blocks is also mentioned. The email discusses possible protocol extensions and the need for code to merge block templates together.The pooled-solo mining mode is introduced as a concept where miners run a local bitcoin node to construct blocks while the pool tracks shares and organizes payouts. This aims to decentralize power and protect against pool hacking. Technical requirements and possible protocol extensions are discussed.A post by Peter Todd on bitcointalk highlights the need for change in Bitcoin mining practices. Pooled-solo mining is proposed as a solution to give more power to individual miners and protect against pool hacks. The concept involves miners running a local Bitcoin node to construct blocks, while the pool handles share tracking and payouts. Todd plans to fund a developer to make this idea a reality under Keep Bitcoin Free's next project.
Updated on: 2023-08-01T05:04:22.409640+00:00