📅 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>;
Arthur Britto [ARCHIVE] /
npub1zw…76ahu
2023-06-07 10:09:16
in reply to nevent1q…unlt
Author Public Key
npub1zwqjevtyx2gsgvu6my8zuaumq809qmmss7r8vpd48k3xrttys5qqs76ahuPublished at
2023-06-07 10:09:16Event JSON
{
"id": "84159b61208bbc7fb4b5407fcffe7e27aa5a893fe83630ad828e6c85e4aa8672",
"pubkey": "13812cb164329104339ad90e2e779b01de506f7087867605b53da261ad648500",
"created_at": 1686132556,
"kind": 1,
"tags": [
[
"e",
"bea123cfa1dde96d98089cdcf953f77564e34363cd7b11c4a3504634664d4aa2",
"",
"root"
],
[
"e",
"48821daae59e86026f1795a956c050396bf2d6a462345fa0c8c9899c54eca5e2",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2012-05-24\n📝 Original message:I think you need the stronger change. Otherwise, the mystery miner could\njust put in a few transactions to himself to mask his block. His block\nwould appear to be of some use while not being helpful.\n\n-Arthur\n\nOn Thu, May 24, 2012 at 9:33 AM, Jeff Garzik \u003cjgarzik at exmulti.com\u003e wrote:\n\n\u003e There appears to be some non-trivial mining power devoted to mining\n\u003e empty blocks. Even with satoshi's key observation -- hash a fixed\n\u003e 80-byte header, not the entire block -- some miners still find it\n\u003e easier to mine empty blocks, rather than watch the network for new\n\u003e transactions.\n\u003e\n\u003e Therefore I was wondering what people thought about a client\n\u003e implementation change:\n\u003e\n\u003e - Do not store or relay empty blocks, if time since last block \u003c X\n\u003e (where X = 60 minutes, perhaps)\n\u003e\n\u003e or even stronger,\n\u003e\n\u003e - Ensure latest block includes at least X percent of mempool\n\u003e unconfirmed TXs\n\u003e\n\u003e The former is easier to implement, though there is the danger that\n\u003e no-TX miners simply include a statically generated transaction or two.\n\u003e\n\u003e The latter might be considered problematic, as it might refuse to\n\u003e relay quickly found blocks.\n\u003e\n\u003e Comments? It wouldn't be a problem if these no-TX blocks were not\n\u003e already getting frequent (1 in 20).\n\u003e\n\u003e --\n\u003e Jeff Garzik\n\u003e exMULTI, Inc.\n\u003e jgarzik at exmulti.com\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Live Security Virtual Conference\n\u003e Exclusive live event will cover all the ways today's security and\n\u003e threat landscape has changed and how IT managers can respond. Discussions\n\u003e will include endpoint security, mobile security and the latest in malware\n\u003e threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120524/a20243f8/attachment.html\u003e",
"sig": "5eb89bc8995d84f53109bf433efe9c263c0245d75bc7d7033e637841261e82053bbd3af5f1067fe447189572e560aba859278e754a03d2607e8df86c5be6dff5"
}