📅 Original date posted:2015-10-14
📝 Original message:That conversation missed a second issue. Namely that there is no way to punish people if there is a double spend in a micro block that happens in key block which reorg'd away the first transaction. eg one miner mines a transaction in a micro block, another miner (either by not having seen the first yet, or being malicious - potentially the same miner) mines a key block which reorgs away the first micro block and then, in their first micro block, mines a double spend. This can happen at any time, so you end up having to fall back to regular full blocks for confirmation times :(.
Also, Greg Slepak brought up a good point on twitter at https://twitter.com/taoeffect/status/654358023138209792. Noting that this model means users could no longer pick transactions in a mining pool which was set up in such a way (it could be tweaked to do so with separate rewards and pubkeys, but now the user can commit fraud at a much lower cost - their own pool reward, not the block's total reward).
On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure at gmail.com>
>wrote:
>
>> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > while the whitepaper has all the nitty gritty details:
>> > http://arxiv.org/abs/1510.02037
>>
>> Taking reward compensation back by fraud proofs is not enough to fix
>> the problems associated with double spending (such as, everyone has
>to
>> wait for the "real" confirmations instead of the "possibly
>> double-spend" confirmations). Some of this was discussed in -wizards
>> recently:
>> http://gnusha.org/bitcoin-wizards/2015-09-19.log
>
>
>Fraud proof removes all the attacker's revenue. It's like the attacker
>sacrifices an entire block for double spending in the current system. I
>think Luke-Jr got it right at that discussion.
>
>Best,
>Ittay
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151014/84d65583/attachment-0001.html>;
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 17:43:28
in reply to nevent1q…3wgs
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-07 17:43:28Event JSON
{
"id": "d0436693b6dd989322e5790c61aa47d2028d677159c4d736ca0fe5da8b8d3bbf",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686159808,
"kind": 1,
"tags": [
[
"e",
"8b34bf2b799e8049f16f95541ce82646f95e8a9250529a9231a0af367eee7a3c",
"",
"root"
],
[
"e",
"aa052477609afe5d28c63ecb5659fcf184dc14dc82be0669b6061d908ba69908",
"",
"reply"
],
[
"p",
"99c8b0a6b21759bf5fe55d05687329c239cd5a291b04b00315b230db39bc0660"
]
],
"content": "📅 Original date posted:2015-10-14\n📝 Original message:That conversation missed a second issue. Namely that there is no way to punish people if there is a double spend in a micro block that happens in key block which reorg'd away the first transaction. eg one miner mines a transaction in a micro block, another miner (either by not having seen the first yet, or being malicious - potentially the same miner) mines a key block which reorgs away the first micro block and then, in their first micro block, mines a double spend. This can happen at any time, so you end up having to fall back to regular full blocks for confirmation times :(.\n\nAlso, Greg Slepak brought up a good point on twitter at https://twitter.com/taoeffect/status/654358023138209792. Noting that this model means users could no longer pick transactions in a mining pool which was set up in such a way (it could be tweaked to do so with separate rewards and pubkeys, but now the user can commit fraud at a much lower cost - their own pool reward, not the block's total reward).\n\nOn October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eOn Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop \u003ckanzure at gmail.com\u003e\n\u003ewrote:\n\u003e\n\u003e\u003e On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e while the whitepaper has all the nitty gritty details:\n\u003e\u003e \u003e http://arxiv.org/abs/1510.02037\n\u003e\u003e\n\u003e\u003e Taking reward compensation back by fraud proofs is not enough to fix\n\u003e\u003e the problems associated with double spending (such as, everyone has\n\u003eto\n\u003e\u003e wait for the \"real\" confirmations instead of the \"possibly\n\u003e\u003e double-spend\" confirmations). Some of this was discussed in -wizards\n\u003e\u003e recently:\n\u003e\u003e http://gnusha.org/bitcoin-wizards/2015-09-19.log\n\u003e\n\u003e\n\u003eFraud proof removes all the attacker's revenue. It's like the attacker\n\u003esacrifices an entire block for double spending in the current system. I\n\u003ethink Luke-Jr got it right at that discussion.\n\u003e\n\u003eBest,\n\u003eIttay\n\u003e\n\u003e\n\u003e------------------------------------------------------------------------\n\u003e\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151014/84d65583/attachment-0001.html\u003e",
"sig": "0fe05e231cb30fcf01e585f56b72be734927a564a25d1b310c6ed702b3baf5dc1d4583c2d7ef55119c4776202ea2743900a78f16668076777dd4d7ca5921bc32"
}