📅 Original date posted:2015-05-09
📝 Original message:On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote:
> On Fri, May 8, 2015 at 5:37 PM, Peter Todd <pete at petertodd.org> wrote:
>
> > The soft-limit is there miners themselves produce smaller blocks; the
> > soft-limit does not prevent other miners from producing larger blocks.
> >
>
> I wonder if having a "miner" flag would be good for the network.
Makes it trivial to find miners and DoS attack them - a huge risk to the
network as a whole, as well as the miners.
Right now pools already get DoSed all the time through their work
submission systems; getting DoS attacked via their nodes as well would
be a disaster.
> When in "miner mode", the client would reject 4MB blocks and wouldn't build
> on them. The reference client might even track the miner and the non-miner
> chain tip.
>
> Miners would refuse to build on 5MB blocks, but merchants and general users
> would accept them.
That'd be an excellent way to double-spend merchants, significantly
increasing the chance that the double-spend would succeed as you only
have to get sufficient hashing power to get the lucky blocks; you don't
need enough hashing power to *also* ensure those blocks don't become the
longest chain, removing the need to sybil attack your target.
--
'peter'[:-1]@petertodd.org
000000000000000004bd67400df7577a30e6f509b6bd82633efeabe6395eb65a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/b01ee01a/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 15:33:41
in reply to nevent1q…rzq5
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 15:33:41Event JSON
{
"id": "dcd9454b8f33dd054deae6f05005e142674018e632cc6a51a667659c7f83384c",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686152021,
"kind": 1,
"tags": [
[
"e",
"f8b5d67799444b0b408a010416662bfec521761783201657452331c18514fd28",
"",
"root"
],
[
"e",
"003bb509897bf04e28a614aa9127c818a7074d5433986334cde0f451cc6b019e",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "📅 Original date posted:2015-05-09\n📝 Original message:On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote:\n\u003e On Fri, May 8, 2015 at 5:37 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \n\u003e \u003e The soft-limit is there miners themselves produce smaller blocks; the\n\u003e \u003e soft-limit does not prevent other miners from producing larger blocks.\n\u003e \u003e\n\u003e \n\u003e I wonder if having a \"miner\" flag would be good for the network.\n\nMakes it trivial to find miners and DoS attack them - a huge risk to the\nnetwork as a whole, as well as the miners.\n\nRight now pools already get DoSed all the time through their work\nsubmission systems; getting DoS attacked via their nodes as well would\nbe a disaster.\n\n\u003e When in \"miner mode\", the client would reject 4MB blocks and wouldn't build\n\u003e on them. The reference client might even track the miner and the non-miner\n\u003e chain tip.\n\u003e \n\u003e Miners would refuse to build on 5MB blocks, but merchants and general users\n\u003e would accept them.\n\nThat'd be an excellent way to double-spend merchants, significantly\nincreasing the chance that the double-spend would succeed as you only\nhave to get sufficient hashing power to get the lucky blocks; you don't\nneed enough hashing power to *also* ensure those blocks don't become the\nlongest chain, removing the need to sybil attack your target.\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000004bd67400df7577a30e6f509b6bd82633efeabe6395eb65a\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/b01ee01a/attachment.sig\u003e",
"sig": "489d33ad35e604ecb872cae9bf7a446c1b72966079a5190e6f7d24d682e6bffcd43f73120b025fc22be28a17f543247cc2b77999801c3df4f989bbeb364db9ac"
}