📅 Original date posted:2012-05-24 📝 Original message:I think the strong ...

Joel Joonatan Kaartinen [ARCHIVE] /

npub1654…8xrx

2023-06-07 10:09:19

in reply to nevent1q…5ylg

📅 Original date posted:2012-05-24
📝 Original message:I think the strong verification would go well if you add it along with an
optimization that avoids rechecking transactions that have already been
verified as valid. Any transactions it doesn't have to verify are from the
pool, of course :)

On Thu, May 24, 2012 at 7:33 PM, 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/736e9b6b/attachment.html>;

Author Public Key

npub1654pkuj4rway0043gcu6rdh4umxescp7ew42d2czqvts3kwvg3esc48xrx

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-06-07 10:09:19

Kind type

1 Short Text Note

Event JSON

{ "id": "e5c057a29887276811f2ab9ca9b67398e6c44b3eb8d05af5b1e5b80983ee2252", "pubkey": "d52a1b72551bba47beb14639a1b6f5e6cd98603ecbaaa6ab02031708d9cc4473", "created_at": 1686132559, "kind": 1, "tags": [ [ "e", "bea123cfa1dde96d98089cdcf953f77564e34363cd7b11c4a3504634664d4aa2", "", "root" ], [ "e", "84159b61208bbc7fb4b5407fcffe7e27aa5a893fe83630ad828e6c85e4aa8672", "", "reply" ], [ "p", "13812cb164329104339ad90e2e779b01de506f7087867605b53da261ad648500" ] ], "content": "📅 Original date posted:2012-05-24\n📝 Original message:I think the strong verification would go well if you add it along with an\noptimization that avoids rechecking transactions that have already been\nverified as valid. Any transactions it doesn't have to verify are from the\npool, of course :)\n\nOn Thu, May 24, 2012 at 7:33 PM, 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/736e9b6b/attachment.html\u003e", "sig": "608e5c13d1912e12a6609755fa60c96b7d2a340e5799848fc838413527469cde082e1a1efc6e212244e393bc0df46d038f42fb201f2864e7453cec243581a7a8" }