📅 Original date posted:2012-05-25
📝 Original message:We just implemented our own mining tool, soup-to-nuts, and I would say that
the likely motivation for what I presume are botnet owners is just economic.
It's a lot more work to make sure your merkleing and keeping up-to-date are
happening than it is to just get an 80 byte header from a central server,
and re-calc a single transaction merkle client-side.
Not to mention the extra work to keep track of what version of
getmemorypool output you're receiving work for in a broadly distributed
pool.
For what it's worth, we did this extra engineering work since we care about
Bitcoin, but if I just wanted to pull value out of the ecosystem, we would
have skipped it.
The only solutions to this are economic solutions -- making such 'cheater'
blocks less valuable, or increasing the value of the transactions.
Also note that botnet operators likely care, in the end, about fiat
currency, so going to 25 btc per block in what I think of as transaction
fee subsidies won't necessarily impact this -- it's a matter of what
happens to exchange rates vs generation rates that will matter.
I think we also have to moderate this consideration against the rights (and
arguable benefits) of someone wanting to build an express-delivery mining
service, one that will provide provably faster certification for those
adding a transaction fee of, say, 1 btc.
My own experience now in the MMO world is that we have to carefully
understand how we deal with griefers who control massive resources (compute
or gold-farmers). It may not be a winning battle to choose a solution which
harms the rest of the network in exchange for harming the griefers.
This is definitely out of the box, but one solution might be to change the
difficulty calculations to just ignore 1tx blocks; that would minimize
impact on others to a great extent, and would let someone set up an express
block service if they chose. I guess we'd have to settle on whether or not
such blocks counted towards the issuance countdown as well. Or, we could
allow only 1/10 generation fees on such blocks.
Peter
On Fri, May 25, 2012 at 9:44 AM, Alan Reiner <etotheipi at gmail.com> wrote:
> I like the concept except that it only works if every node connected to
> the miner enforces the rule (if it works). Once any one of the nodes
> forwards the block, other nodes see it coming from a node that can pass
> the challenge.
>
> I don't think any solution based on node queries will succeed, especially
> if it requires spontaneous super-majority-of-nodes acceptance. I think
> it's gotta be based on the block itself and each nodes' own info.
>
> If you could spontaneously get all miners to agree not to build off of
> anti-social blocks (however that is defined) , it would have a chance of
> making a difference, but individual miners would have an advantage
> building off the antisocial block because they only need to produce one to
> create the longest chain (and collect reward) while the miners following
> the rules need two blocks.
>
> --Sent from my overpriced smartphone
> On May 25, 2012 3:48 AM, "Christian Decker" <decker.christian at gmail.com>
> wrote:
>
>> How about a simple proof of work test? This one though does not ask for
>> CPU work but asks the miner for a random old transaction. If the miner
>> really stores the entire blockchain he will not have any problem answering
>> to that getdata request, whereas a botnet would have to ask someone else
>> for it, which could be detected if the response time deviates too much from
>> what has been previously measured (compare it against getdata for the block
>> they advertise). It's not perfect but it allows an estimate of whether it
>> is a chainless miner.
>>
>> Regards,
>> Chris
>> --
>> Christian Decker
>>
>>
>>
>> On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
>>
>>> On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke at dashjr.org> wrote:
>>> > Block times are not accurate enough for that.
>>>
>>> The times in your log are very accurate, assuming your system clock is
>>> remotely accurate.
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
> ------------------------------------------------------------------------------
> 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
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120525/c9f827d7/attachment.html>;
Peter Vessenes [ARCHIVE] /
npub1ez…6r8pt
2023-06-07 10:09:58
in reply to nevent1q…sual
Author Public Key
npub1ezg54d03a7unwu0fckmlugxulukrg06x7jzx4engngxfg79sfcqsn6r8ptPublished at
2023-06-07 10:09:58Event JSON
{
"id": "171d26f55e480c305a076320edecbba078a6d1799cf147bd206215f66cd0088b",
"pubkey": "c8914ab5f1efb93771e9c5b7fe20dcff2c343f46f4846ae6689a0c9478b04e01",
"created_at": 1686132598,
"kind": 1,
"tags": [
[
"e",
"bea123cfa1dde96d98089cdcf953f77564e34363cd7b11c4a3504634664d4aa2",
"",
"root"
],
[
"e",
"47923e6b372f33f35ef6157cd400acef140317d3b7d5993b884e9d6d55e7b11e",
"",
"reply"
],
[
"p",
"86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec"
]
],
"content": "📅 Original date posted:2012-05-25\n📝 Original message:We just implemented our own mining tool, soup-to-nuts, and I would say that\nthe likely motivation for what I presume are botnet owners is just economic.\n\nIt's a lot more work to make sure your merkleing and keeping up-to-date are\nhappening than it is to just get an 80 byte header from a central server,\nand re-calc a single transaction merkle client-side.\n\nNot to mention the extra work to keep track of what version of\ngetmemorypool output you're receiving work for in a broadly distributed\npool.\n\nFor what it's worth, we did this extra engineering work since we care about\nBitcoin, but if I just wanted to pull value out of the ecosystem, we would\nhave skipped it.\n\nThe only solutions to this are economic solutions -- making such 'cheater'\nblocks less valuable, or increasing the value of the transactions.\n\nAlso note that botnet operators likely care, in the end, about fiat\ncurrency, so going to 25 btc per block in what I think of as transaction\nfee subsidies won't necessarily impact this -- it's a matter of what\nhappens to exchange rates vs generation rates that will matter.\n\nI think we also have to moderate this consideration against the rights (and\narguable benefits) of someone wanting to build an express-delivery mining\nservice, one that will provide provably faster certification for those\nadding a transaction fee of, say, 1 btc.\n\nMy own experience now in the MMO world is that we have to carefully\nunderstand how we deal with griefers who control massive resources (compute\nor gold-farmers). It may not be a winning battle to choose a solution which\nharms the rest of the network in exchange for harming the griefers.\n\nThis is definitely out of the box, but one solution might be to change the\ndifficulty calculations to just ignore 1tx blocks; that would minimize\nimpact on others to a great extent, and would let someone set up an express\nblock service if they chose. I guess we'd have to settle on whether or not\nsuch blocks counted towards the issuance countdown as well. Or, we could\nallow only 1/10 generation fees on such blocks.\n\nPeter\n\n\nOn Fri, May 25, 2012 at 9:44 AM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\n\u003e I like the concept except that it only works if every node connected to\n\u003e the miner enforces the rule (if it works). Once any one of the nodes\n\u003e forwards the block, other nodes see it coming from a node that can pass\n\u003e the challenge.\n\u003e\n\u003e I don't think any solution based on node queries will succeed, especially\n\u003e if it requires spontaneous super-majority-of-nodes acceptance. I think\n\u003e it's gotta be based on the block itself and each nodes' own info.\n\u003e\n\u003e If you could spontaneously get all miners to agree not to build off of\n\u003e anti-social blocks (however that is defined) , it would have a chance of\n\u003e making a difference, but individual miners would have an advantage\n\u003e building off the antisocial block because they only need to produce one to\n\u003e create the longest chain (and collect reward) while the miners following\n\u003e the rules need two blocks.\n\u003e\n\u003e --Sent from my overpriced smartphone\n\u003e On May 25, 2012 3:48 AM, \"Christian Decker\" \u003cdecker.christian at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e How about a simple proof of work test? This one though does not ask for\n\u003e\u003e CPU work but asks the miner for a random old transaction. If the miner\n\u003e\u003e really stores the entire blockchain he will not have any problem answering\n\u003e\u003e to that getdata request, whereas a botnet would have to ask someone else\n\u003e\u003e for it, which could be detected if the response time deviates too much from\n\u003e\u003e what has been previously measured (compare it against getdata for the block\n\u003e\u003e they advertise). It's not perfect but it allows an estimate of whether it\n\u003e\u003e is a chainless miner.\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e Chris\n\u003e\u003e --\n\u003e\u003e Christian Decker\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik \u003cjgarzik at exmulti.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e On Thu, May 24, 2012 at 8:57 PM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\u003e\u003e\u003e \u003e Block times are not accurate enough for that.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The times in your log are very accurate, assuming your system clock is\n\u003e\u003e\u003e remotely accurate.\n\u003e\u003e\u003e\n\u003e\u003e\u003e --\n\u003e\u003e\u003e Jeff Garzik\n\u003e\u003e\u003e exMULTI, Inc.\n\u003e\u003e\u003e jgarzik at exmulti.com\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\u003e Live Security Virtual Conference\n\u003e\u003e\u003e Exclusive live event will cover all the ways today's security and\n\u003e\u003e\u003e threat landscape has changed and how IT managers can respond. Discussions\n\u003e\u003e\u003e will include endpoint security, mobile security and the latest in malware\n\u003e\u003e\u003e threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Live Security Virtual Conference\n\u003e\u003e Exclusive live event will cover all the ways today's security and\n\u003e\u003e threat landscape has changed and how IT managers can respond. Discussions\n\u003e\u003e will include endpoint security, mobile security and the latest in malware\n\u003e\u003e threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\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\u003e\n\n\n-- \nPeter J. Vessenes\nCEO, CoinLab\nM: 206.595.9839\nSkype: vessenes\nGoogle+ \u003chttps://plus.google.com/112885659993091300749\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120525/c9f827d7/attachment.html\u003e",
"sig": "dfb72f0165f798faaee3ee98e89e5995e0119fa0bc1f8f7f375a74f830bc1b346c3b7ca5eeaf1ab3f32b225c861ee02bbb31fb7649f9a94a130d68c1cbc31701"
}