📅 Original date posted:2014-04-23
📝 Original message:On 4/23/2014 12:04 PM, Christophe Biocca wrote:
> It's not necessary that this "coinbase retribution" be either
> profitable or risk-free for this scheme to work. I think we should
> separate out the different layers of the proposal:
>
> 1. Attacking the coinbase instead of orphaning allows for 100 blocks'
> time for a consensus to be reached, rather than 10 minutes. This
> allows for human verification/intervention if needed (orphaning
> decisions would almost always need to be automated, due to the short
> timeframe). This is a useful insight, and I don't think it's been
> brought up before.
>
> 2. The original specification of how it's done (redistribution, no
> cost to voting) does seem exploitable. This can be fixed by reducing
> the incentive (burning instead of redistributing) and/or adding a risk
> to the orphaning attempts (a vote that fails destroys X bitcoins'
> worth from each voting block's own coinbase). The incentives can be
> tailored to mirror those of orphaning a block, to reduce the risk of
> abuse. Then the only difference from orphaning are 1) More limited
> rewriting of history (only the coinbase, vs all transactions in the
> block), and 2) More time to coordinate a response.
>
> 3. This proposal may be used for things other than punishing
> double-spend pools. In fact it might be used to punish miners for
> doing anything a significant percentage of hashpower dislikes (large
> OP_RETURNs, large blocks, gambling transactions, transactions banned
> by a government). But we can make the threshold higher than 51%, so
> that this doesn't turn into a significant risk (if 75% of hashpower is
> willing to enforce a rule, we're already likely to see it enforced
> through orphaning).
>
> On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
>>> And it still would. Non-collusive miners cast votes based on the outcome
>>> of their own attempts to double spend.
>>
>> Individually rational strategy is to vote for coinbase reallocation on every
>> block.
>>
>> Yes, in that case nobody will get reward. It is similar to prisoner's
>> dilemma: equilibrium has worst pay-off.
>> In practice that would mean that simple game-theoretic models are no longer
>> applicable, as they lead to absurd results.
>>
>>> I'm using it in the same sense Satoshi used it. Honest miners work to
>>> prevent double spends. That's the entire justification for their existence.
>>> Miners that are deliberately trying to double spend are worse than useless.
>>
>> Miners work to get rewards.
>> It absolutely doesn't matter whether they are deliberately trying to
>> double-spend or not: they won't be able to double-spend without a collusion.
>>
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
This all sounds verry restrictive. Is it possible to do a "sweep" in
order to "clean up" double spending? Why punish miners for the sake of
punishing them?
--
Kevin
Kevin [ARCHIVE] /
npub1vd…sc3yk
2023-06-07 15:19:34
in reply to nevent1q…nw7h
Author Public Key
npub1vdngmkaq73c0aq4fp7xgzjjtp9l66l2t50j7ma242lcp8rleuvls8sc3ykPublished at
2023-06-07 15:19:34Event JSON
{
"id": "3a3e31f58a6516d47161f9c443f618d1e0bafa99604726ab35fd08696d872ac7",
"pubkey": "63668ddba0f470fe82a90f8c814a4b097fad7d4ba3e5edf55557f0138ff9e33f",
"created_at": 1686151174,
"kind": 1,
"tags": [
[
"e",
"5090665aad23a77b012135979db1e16bc811db23aa511d1ac7d17a56045795a8",
"",
"root"
],
[
"e",
"0783d7689a541c600b49b526730ca8a1c93f01bb59655c7b4a1868723dbfc837",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-04-23\n📝 Original message:On 4/23/2014 12:04 PM, Christophe Biocca wrote:\n\u003e It's not necessary that this \"coinbase retribution\" be either\n\u003e profitable or risk-free for this scheme to work. I think we should\n\u003e separate out the different layers of the proposal:\n\u003e\n\u003e 1. Attacking the coinbase instead of orphaning allows for 100 blocks'\n\u003e time for a consensus to be reached, rather than 10 minutes. This\n\u003e allows for human verification/intervention if needed (orphaning\n\u003e decisions would almost always need to be automated, due to the short\n\u003e timeframe). This is a useful insight, and I don't think it's been\n\u003e brought up before.\n\u003e\n\u003e 2. The original specification of how it's done (redistribution, no\n\u003e cost to voting) does seem exploitable. This can be fixed by reducing\n\u003e the incentive (burning instead of redistributing) and/or adding a risk\n\u003e to the orphaning attempts (a vote that fails destroys X bitcoins'\n\u003e worth from each voting block's own coinbase). The incentives can be\n\u003e tailored to mirror those of orphaning a block, to reduce the risk of\n\u003e abuse. Then the only difference from orphaning are 1) More limited\n\u003e rewriting of history (only the coinbase, vs all transactions in the\n\u003e block), and 2) More time to coordinate a response.\n\u003e\n\u003e 3. This proposal may be used for things other than punishing\n\u003e double-spend pools. In fact it might be used to punish miners for\n\u003e doing anything a significant percentage of hashpower dislikes (large\n\u003e OP_RETURNs, large blocks, gambling transactions, transactions banned\n\u003e by a government). But we can make the threshold higher than 51%, so\n\u003e that this doesn't turn into a significant risk (if 75% of hashpower is\n\u003e willing to enforce a rule, we're already likely to see it enforced\n\u003e through orphaning).\n\u003e\n\u003e On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi \u003calex.mizrahi at gmail.com\u003e wrote:\n\u003e\u003e\u003e And it still would. Non-collusive miners cast votes based on the outcome\n\u003e\u003e\u003e of their own attempts to double spend.\n\u003e\u003e\n\u003e\u003e Individually rational strategy is to vote for coinbase reallocation on every\n\u003e\u003e block.\n\u003e\u003e\n\u003e\u003e Yes, in that case nobody will get reward. It is similar to prisoner's\n\u003e\u003e dilemma: equilibrium has worst pay-off.\n\u003e\u003e In practice that would mean that simple game-theoretic models are no longer\n\u003e\u003e applicable, as they lead to absurd results.\n\u003e\u003e\n\u003e\u003e\u003e I'm using it in the same sense Satoshi used it. Honest miners work to\n\u003e\u003e\u003e prevent double spends. That's the entire justification for their existence.\n\u003e\u003e\u003e Miners that are deliberately trying to double spend are worse than useless.\n\u003e\u003e\n\u003e\u003e Miners work to get rewards.\n\u003e\u003e It absolutely doesn't matter whether they are deliberately trying to\n\u003e\u003e double-spend or not: they won't be able to double-spend without a collusion.\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Start Your Social Network Today - Download eXo Platform\n\u003e\u003e Build your Enterprise Intranet with eXo Platform Software\n\u003e\u003e Java Based Open Source Intranet - Social, Extensible, Cloud Ready\n\u003e\u003e Get Started Now And Turn Your Intranet Into A Collaboration Platform\n\u003e\u003e http://p.sf.net/sfu/ExoPlatform\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 ------------------------------------------------------------------------------\n\u003e Start Your Social Network Today - Download eXo Platform\n\u003e Build your Enterprise Intranet with eXo Platform Software\n\u003e Java Based Open Source Intranet - Social, Extensible, Cloud Ready\n\u003e Get Started Now And Turn Your Intranet Into A Collaboration Platform\n\u003e http://p.sf.net/sfu/ExoPlatform\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\nThis all sounds verry restrictive. Is it possible to do a \"sweep\" in \norder to \"clean up\" double spending? Why punish miners for the sake of \npunishing them?\n\n\n-- \nKevin",
"sig": "f423ad90460eb4ca247ce22ce65420712dbc626e31d99cff7b14b1acbac0723039f1e990e62a6f72ba04c0043aa8d21160f87c3ac9fd0a1db9e55e6e468b887f"
}