rich1.0npub1zwqjevtyx2gsgvu6my8zuaumq809qmmss7r8vpd48k3xrttys5qqs76ahuhttps://nostr.ae/npub1zwqjevtyx2gsgvu6my8zuaumq809qmmss7r8vpd48k3xrttys5qqs76ahunjumphttps://nostr.ae📅 Original date posted:2012-05-24 📝 Original message:I think you need the stronger change. Otherwise, the mystery miner could just put in a few transactions to himself to mask his block. His block would appear to be of some use while not being helpful. -Arthur On Thu, May 24, 2012 at 9:33 AM, Jeff Garzik <jgarzik at exmulti.com> wrote: > There appears to be some non-trivial mining power devoted to mining > empty blocks. Even with satoshi's key observation -- hash a fixed > 80-byte header, not the entire block -- some miners still find it > easier to mine empty blocks, rather than watch the network for new > transactions. > > Therefore I was wondering what people thought about a client > implementation change: > > - Do not store or relay empty blocks, if time since last block < X > (where X = 60 minutes, perhaps) > > or even stronger, > > - Ensure latest block includes at least X percent of mempool > unconfirmed TXs > > The former is easier to implement, though there is the danger that > no-TX miners simply include a statically generated transaction or two. > > The latter might be considered problematic, as it might refuse to > relay quickly found blocks. > > Comments? It wouldn't be a problem if these no-TX blocks were not > already getting frequent (1 in 20). > > -- > Jeff Garzik > exMULTI, Inc. > jgarzik at exmulti.com > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120524/a20243f8/attachment.html>