Stephen [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-16 📝 Original message:Comments in line: > On May ...
📅 Original date posted:2015-05-16
📝 Original message:Comments in line:
> On May 8, 2015, at 11:08 PM, Peter Todd <pete at petertodd.org> wrote:
>
> 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.
It seems that using a -miner flag to follow rules about smaller blocks would only reveal miner nodes if one sent the node a solved block that that was valid in every way except the block size. While not impossible, I wouldn't call this trivial, as it still requires wasting an entire block's worth of energy.
>> 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.
>
I think this could be mitigated by counting confirmations differently. We should think of confirmations as only coming from blocks following the miners' more strict rule set. So if a merchant were to see payment for the first time in a block that met their own size restrictions but not the miners', then they would simply count it as unconfirmed.
If they get deep enough in the chain, though, the client should probably count them as being confirmed anyway, even if they don't meet the client nodes' expectation of the miners' block size limit. This happening probably just means that the client has not updated their software (or -minermaxblocksize configuration, depending on how it is implemented) in a long time.
I actually like Tier's suggestion quite a bit. I think we could have the default client limit set to some higher number, and have miners agree out of band on the latest block size limit. Or maybe even build in a way to vote into the blockchain.
Best,
Stephen
Published at
2023-06-07 15:33:42Event JSON
{
"id": "f0c0ada1d60a7c48848688643a845721ac8e07baa387e47f026e250e717c2262",
"pubkey": "10238a6d0c6848c1acb963573a9db5f379583e293364361bd86476b496370490",
"created_at": 1686152022,
"kind": 1,
"tags": [
[
"e",
"f8b5d67799444b0b408a010416662bfec521761783201657452331c18514fd28",
"",
"root"
],
[
"e",
"dcd9454b8f33dd054deae6f05005e142674018e632cc6a51a667659c7f83384c",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-05-16\n📝 Original message:Comments in line:\n\n\u003e On May 8, 2015, at 11:08 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \n\u003e Makes it trivial to find miners and DoS attack them - a huge risk to the\n\u003e network as a whole, as well as the miners.\n\u003e \n\u003e Right now pools already get DoSed all the time through their work\n\u003e submission systems; getting DoS attacked via their nodes as well would\n\u003e be a disaster.\n\nIt seems that using a -miner flag to follow rules about smaller blocks would only reveal miner nodes if one sent the node a solved block that that was valid in every way except the block size. While not impossible, I wouldn't call this trivial, as it still requires wasting an entire block's worth of energy. \n\n\u003e\u003e When in \"miner mode\", the client would reject 4MB blocks and wouldn't build\n\u003e\u003e on them. The reference client might even track the miner and the non-miner\n\u003e\u003e chain tip.\n\u003e\u003e \n\u003e\u003e Miners would refuse to build on 5MB blocks, but merchants and general users\n\u003e\u003e would accept them.\n\u003e \n\u003e That'd be an excellent way to double-spend merchants, significantly\n\u003e increasing the chance that the double-spend would succeed as you only\n\u003e have to get sufficient hashing power to get the lucky blocks; you don't\n\u003e need enough hashing power to *also* ensure those blocks don't become the\n\u003e longest chain, removing the need to sybil attack your target.\n\u003e \n\nI think this could be mitigated by counting confirmations differently. We should think of confirmations as only coming from blocks following the miners' more strict rule set. So if a merchant were to see payment for the first time in a block that met their own size restrictions but not the miners', then they would simply count it as unconfirmed. \n\nIf they get deep enough in the chain, though, the client should probably count them as being confirmed anyway, even if they don't meet the client nodes' expectation of the miners' block size limit. This happening probably just means that the client has not updated their software (or -minermaxblocksize configuration, depending on how it is implemented) in a long time. \n\nI actually like Tier's suggestion quite a bit. I think we could have the default client limit set to some higher number, and have miners agree out of band on the latest block size limit. Or maybe even build in a way to vote into the blockchain. \n\nBest, \nStephen",
"sig": "7bfb640f9ab23ae9db8a71e2a0df5377e0efb4bf19d15d34df4a803ff055bb305608f65cfdc976d1b520ab6653d726aaf7424b6477dad3326901ba3ca180131e"
}