📅 Original date posted:2016-12-18
📝 Original message:Hi All,
I'm coming late to the party. I like the Block75 proposal.
Multiple people have said miners would/could stuff blocks with insincere
transactions to increase the block size, but it was never adequately
explained what they would gain from this. If there aren't enough legitimate
transactions to fill up the block, where do you plan to earn extra income
once the block is bigger?
Miners would be incentivized to include as many legitimate transactions as
possible, but if propagation time is as big an issue as some of you have
said it is, miners would also be incentivized to keep their blocks small
enough to propagate. So why not give them the choice? Once the block size
gets too big to propagate effectively, miners would be naturally
incentivized to limit how much data they put in each block, finding the
perfect balance.
In my opinion, none of the downsides presented so far have been a good
argument. Risk of a 51% attack is not unique to this proposal, saying "we
could also do that with hardcoded limits" doesn't actually point out any
problem with this proposal, and miners already have the ability to add or
withhold transactions from their blocks.
We trust our miners to serve us by acting in their own best interests, and
this proposal simply gives them more options for doing that. If anyone can
make a strong argument against that would earn top marks in a high school
debate class, I'd love to hear it!
James
On Sun, Dec 11, 2016 at 3:23 PM s7r via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Andrew Johnson wrote:
> > "You miss something obvious that makes this attack actually free of cost.
> > Nothing will "cost them more in transaction fees". A miner can create
> > thousands of transactions paying to himself, and not broadcast them to
> > the network, but hold them and include them in the blocks he mines. The
> > fees are collected by him because transactions are included in a block
> > that he mined and the left amount is in another wallet of the same
> > person. Repeat this continuously to fill blocks."
> >
> > This is easily detectable as long as the network isn't heavily
> > partitioned(which is an assumption we make today in order for
> > transaction propagation to work reliably as well as for xThin and
> > CompactBlocks to work effectively to reduce block transmission time).
> > Other miners would have an incentive to intentionally orphan blocks that
> > contained a large number of transactions that their nodes were unaware
> of.
> >
> > I don't think this sort of attack would last long. Even later when
> > subsidies are drastically reduced, you would still lose out on
> > significant genuine fee revenue if your orphan rate increased even
> > 10%(one out of ten of your poison blocks intentionally orphaned by
> > another miner).
> >
>
> I disagree.
>
> I didn't say this is impossible to detect, but it is hard to act against
> it. One miner orphaning the block intentionally is very unlikely if that
> miner acts rationally. It would only make sense if 51% of the hash rate
> would intentionally orphan it. Otherwise the miner who intentionally
> orphans a valid block, let's say block X, has to continue to mine one in
> its place on top of block X-1, and by the time he finds one:
>
> a) his block X' is rejected by other miners because they already have a
> valid block X on top of which they already started to mine;
>
> b) block X+1 was already found and broadcasted, so the miner who
> orphaned X intentionally is on the shorter chain ignored by the network.
>
> So, one miner cannot do anything about it. Even a pool cannot do
> anything about it, because the loss is greater. You need 51% of the hash
> rate to intentionally orphan it, and all the miners forming 51% need to
> be colluding and know for sure that every one will intentionally orphan
> the said block, otherwise there's a huge risk of loss for who does it.
> Nobody would gamble to do this (I am not sure if gambling is the right
> word, since the loss is 100% sure here). But, we are not discussing 51%
> attacks because those are a different topic.
>
> _______________________________________________
> 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/20161218/f08a63d8/attachment-0001.html>;
James MacWhyte [ARCHIVE] /
npub12t…pye9h
2023-06-07 17:54:51
in reply to nevent1q…p6ap
Author Public Key
npub12tjaqer27049ejmvf0f3yd7kq6p93gg6ecavgrczge4rlzf59y5q2pye9hPublished at
2023-06-07 17:54:51Event JSON
{
"id": "00a2e1cbecaa3dc386459a646f2cfe1b7b143e3f85957d79d4bdd4c31254155d",
"pubkey": "52e5d0646af3ea5ccb6c4bd31237d6068258a11ace3ac40f02466a3f89342928",
"created_at": 1686160491,
"kind": 1,
"tags": [
[
"e",
"93f229f84c7a0d580081719bdeab8a0791a31bea972b61b4a96af898141b5a6b",
"",
"root"
],
[
"e",
"6162cec58198c19040a7f6d5259f81725c7af7511217017293f3c5945ff8b069",
"",
"reply"
],
[
"p",
"947955301a8805054c8d6a2c9ac2abf07a7a18f4a33b0a573a277868302953b1"
]
],
"content": "📅 Original date posted:2016-12-18\n📝 Original message:Hi All,\n\nI'm coming late to the party. I like the Block75 proposal.\n\nMultiple people have said miners would/could stuff blocks with insincere\ntransactions to increase the block size, but it was never adequately\nexplained what they would gain from this. If there aren't enough legitimate\ntransactions to fill up the block, where do you plan to earn extra income\nonce the block is bigger?\n\nMiners would be incentivized to include as many legitimate transactions as\npossible, but if propagation time is as big an issue as some of you have\nsaid it is, miners would also be incentivized to keep their blocks small\nenough to propagate. So why not give them the choice? Once the block size\ngets too big to propagate effectively, miners would be naturally\nincentivized to limit how much data they put in each block, finding the\nperfect balance.\n\nIn my opinion, none of the downsides presented so far have been a good\nargument. Risk of a 51% attack is not unique to this proposal, saying \"we\ncould also do that with hardcoded limits\" doesn't actually point out any\nproblem with this proposal, and miners already have the ability to add or\nwithhold transactions from their blocks.\n\nWe trust our miners to serve us by acting in their own best interests, and\nthis proposal simply gives them more options for doing that. If anyone can\nmake a strong argument against that would earn top marks in a high school\ndebate class, I'd love to hear it!\n\nJames\n\nOn Sun, Dec 11, 2016 at 3:23 PM s7r via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Andrew Johnson wrote:\n\u003e \u003e \"You miss something obvious that makes this attack actually free of cost.\n\u003e \u003e Nothing will \"cost them more in transaction fees\". A miner can create\n\u003e \u003e thousands of transactions paying to himself, and not broadcast them to\n\u003e \u003e the network, but hold them and include them in the blocks he mines. The\n\u003e \u003e fees are collected by him because transactions are included in a block\n\u003e \u003e that he mined and the left amount is in another wallet of the same\n\u003e \u003e person. Repeat this continuously to fill blocks.\"\n\u003e \u003e\n\u003e \u003e This is easily detectable as long as the network isn't heavily\n\u003e \u003e partitioned(which is an assumption we make today in order for\n\u003e \u003e transaction propagation to work reliably as well as for xThin and\n\u003e \u003e CompactBlocks to work effectively to reduce block transmission time).\n\u003e \u003e Other miners would have an incentive to intentionally orphan blocks that\n\u003e \u003e contained a large number of transactions that their nodes were unaware\n\u003e of.\n\u003e \u003e\n\u003e \u003e I don't think this sort of attack would last long. Even later when\n\u003e \u003e subsidies are drastically reduced, you would still lose out on\n\u003e \u003e significant genuine fee revenue if your orphan rate increased even\n\u003e \u003e 10%(one out of ten of your poison blocks intentionally orphaned by\n\u003e \u003e another miner).\n\u003e \u003e\n\u003e\n\u003e I disagree.\n\u003e\n\u003e I didn't say this is impossible to detect, but it is hard to act against\n\u003e it. One miner orphaning the block intentionally is very unlikely if that\n\u003e miner acts rationally. It would only make sense if 51% of the hash rate\n\u003e would intentionally orphan it. Otherwise the miner who intentionally\n\u003e orphans a valid block, let's say block X, has to continue to mine one in\n\u003e its place on top of block X-1, and by the time he finds one:\n\u003e\n\u003e a) his block X' is rejected by other miners because they already have a\n\u003e valid block X on top of which they already started to mine;\n\u003e\n\u003e b) block X+1 was already found and broadcasted, so the miner who\n\u003e orphaned X intentionally is on the shorter chain ignored by the network.\n\u003e\n\u003e So, one miner cannot do anything about it. Even a pool cannot do\n\u003e anything about it, because the loss is greater. You need 51% of the hash\n\u003e rate to intentionally orphan it, and all the miners forming 51% need to\n\u003e be colluding and know for sure that every one will intentionally orphan\n\u003e the said block, otherwise there's a huge risk of loss for who does it.\n\u003e Nobody would gamble to do this (I am not sure if gambling is the right\n\u003e word, since the loss is 100% sure here). But, we are not discussing 51%\n\u003e attacks because those are a different topic.\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161218/f08a63d8/attachment-0001.html\u003e",
"sig": "e4c0a2e5a3dd5c7c81329610b5537d7e4479837229cc840bebf71cd4e425b91d3e698d3e85eecca0e1aae45545bdd26eb689892b0c9ad9a4c3daaf8e3270199d"
}