Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-12 📝 Original message:On Thursday, November 12, ...
📅 Original date posted:2015-11-12
📝 Original message: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
Published at
2023-06-07 17:44:33Event JSON
{
"id": "fd4f467aad63297fa69b0af0ab1d7736a62aa16cde71bd3c9580bf9eda611ea9",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686159873,
"kind": 1,
"tags": [
[
"e",
"c59f6dff72c8db0bd6ddda0f45c2ffa7c951b2b6ab43fd7de238298ff1dc7029",
"",
"root"
],
[
"e",
"eef8b6409a9e76ab4cbddecc3b57db6bb931f3bf00ad83e91428fd8ac1663972",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-11-12\n📝 Original message:On Thursday, November 12, 2015 8:43:17 PM Jorge Timón wrote:\n\u003e On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev\n\u003e \u003e wrote:\n\u003e \u003e\u003e * Mining code will use starting priority for ease of implementation\n\u003e \u003e \n\u003e \u003e This should be optional, at least for 0.12.\n\u003e \n\u003e The ease of implementation is not gained if it's maintained optionally.\n\nIt has come to my attention maintaining the current priority algorithm is not \neven expensive, so I think I'm inclined to NACK using starting priority \naltogether. Since I am the mining maintainer for Core, I believe it's \nreasonable for me to decide on maintenance tradeoffs...\n\nTherefore, my goal in this matter will be to review #6357 in depth to be \nmerged, and follow up with #6898 based on the current default policies.\n\n\u003e \u003e\u003e * Default block priority size will be 0\n\u003e \u003e \n\u003e \u003e We should not be influencing miner policy by changing defaults.\n\u003e \n\u003e I agree changing policy defaults is meaningless, but in this case it\n\u003e is supposed to signal deprecation of the policy option.\n\nThis is a bad idea anyway, since priority is the best metric we have right now \nfor ensuring legitimate transactions get mined despite spam attacks.\n\nLuke",
"sig": "30b5ce7308684b3f7212cc7af59be200c17df3183cbe0e00f52c581257b63ef55105b34d53658822f9bc50bf6fe2af656e778380578bb66ef094eeb6f5eca98f"
}