📅 Original date posted:2015-11-12
📝 Original message:To be clear Luke, its not THAT complicated to maintain the mining policy,
but preserving the ability of people to place priority based transactions
in a limited mempool world is quite complicated. See recently closed
#6992.
I think the biggest issue with #6357 is being sure the logic doesn't break
in future changes. There are a lot of things that need to be updated in
the right order when blocks are connected or disconnected.
And whats the point of having even that added extra complication if its not
easy to place free transactions and starting priority is a decent
approximation for mining anyway (txs can just be rebroadcast in the worst
case).
On Thu, Nov 12, 2015 at 4:10 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thursday, November 12, 2015 8:43:17 PM Jorge Timón wrote:
> > On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev
> > > wrote:
> > >> * Mining code will use starting priority for ease of implementation
> > >
> > > This should be optional, at least for 0.12.
> >
> > The ease of implementation is not gained if it's maintained optionally.
>
> It has come to my attention maintaining the current priority algorithm is
> not
> even expensive, so I think I'm inclined to NACK using starting priority
> altogether. Since I am the mining maintainer for Core, I believe it's
> reasonable for me to decide on maintenance tradeoffs...
>
> Therefore, my goal in this matter will be to review #6357 in depth to be
> merged, and follow up with #6898 based on the current default policies.
>
> > >> * Default block priority size will be 0
> > >
> > > We should not be influencing miner policy by changing defaults.
> >
> > I agree changing policy defaults is meaningless, but in this case it
> > is supposed to signal deprecation of the policy option.
>
> This is a bad idea anyway, since priority is the best metric we have right
> now
> for ensuring legitimate transactions get mined despite spam attacks.
>
> Luke
> _______________________________________________
> 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/20151112/e994acb0/attachment.html>;
Alex Morcos [ARCHIVE] /
npub10z…3xfzw
2023-06-07 17:44:33
in reply to nevent1q…k6d5
Author Public Key
npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzwSeen on
wss://relay.nostr.bandPublished at
2023-06-07 17:44:33Event JSON
{
"id": "ecf3f0dd4352c09fb261c92a3c390d6506d649f1d79d0de7a9f09153b527cc9a",
"pubkey": "78aa6925095b629d95a9e79aed6ed9da0973239bc6eedf11af42240f0e1d755c",
"created_at": 1686159873,
"kind": 1,
"tags": [
[
"e",
"c59f6dff72c8db0bd6ddda0f45c2ffa7c951b2b6ab43fd7de238298ff1dc7029",
"",
"root"
],
[
"e",
"fd4f467aad63297fa69b0af0ab1d7736a62aa16cde71bd3c9580bf9eda611ea9",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2015-11-12\n📝 Original message:To be clear Luke, its not THAT complicated to maintain the mining policy,\nbut preserving the ability of people to place priority based transactions\nin a limited mempool world is quite complicated. See recently closed\n#6992.\nI think the biggest issue with #6357 is being sure the logic doesn't break\nin future changes. There are a lot of things that need to be updated in\nthe right order when blocks are connected or disconnected.\nAnd whats the point of having even that added extra complication if its not\neasy to place free transactions and starting priority is a decent\napproximation for mining anyway (txs can just be rebroadcast in the worst\ncase).\n\n\nOn Thu, Nov 12, 2015 at 4:10 PM, Luke Dashjr via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Thursday, November 12, 2015 8:43:17 PM Jorge Timón wrote:\n\u003e \u003e On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev\n\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e \u003e On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev\n\u003e \u003e \u003e wrote:\n\u003e \u003e \u003e\u003e * Mining code will use starting priority for ease of implementation\n\u003e \u003e \u003e\n\u003e \u003e \u003e This should be optional, at least for 0.12.\n\u003e \u003e\n\u003e \u003e The ease of implementation is not gained if it's maintained optionally.\n\u003e\n\u003e It has come to my attention maintaining the current priority algorithm is\n\u003e not\n\u003e even expensive, so I think I'm inclined to NACK using starting priority\n\u003e altogether. Since I am the mining maintainer for Core, I believe it's\n\u003e reasonable for me to decide on maintenance tradeoffs...\n\u003e\n\u003e Therefore, my goal in this matter will be to review #6357 in depth to be\n\u003e merged, and follow up with #6898 based on the current default policies.\n\u003e\n\u003e \u003e \u003e\u003e * Default block priority size will be 0\n\u003e \u003e \u003e\n\u003e \u003e \u003e We should not be influencing miner policy by changing defaults.\n\u003e \u003e\n\u003e \u003e I agree changing policy defaults is meaningless, but in this case it\n\u003e \u003e is supposed to signal deprecation of the policy option.\n\u003e\n\u003e This is a bad idea anyway, since priority is the best metric we have right\n\u003e now\n\u003e for ensuring legitimate transactions get mined despite spam attacks.\n\u003e\n\u003e Luke\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/20151112/e994acb0/attachment.html\u003e",
"sig": "7a5d984d6341b70bbace3211a7e48486aecdbdadba792f8db78eb23e8c3f5ca46d7534ba660a171a2c1f9c70072e3c3491aec8f4841cfaba6756507e01fbad0d"
}