📅 Original date posted:2017-03-30
📝 Original message:On Thursday, March 30, 2017 9:34:31 AM Natanael via bitcoin-dev wrote:
> You want to really make sure your transaction gets processed quickly?
> Transactions could have a second fee type, a specially labeled
> anyone-can-spend output with an op_return value defining a "best-before"
> block number and some function describing the decline of the fee value for
> every future block, such that before block N the miners can claim the full
> expedience fee + the standard fee (if any), between block N+1 and N+X the
> miner can claim a reduced expedience fee + standard fee, afterwards only
> the standard fee.
Minor detail: OP_RETURN doesn't work like that. You'd need OP_DROP.
> When a transaction is processed late such that not the full expedience fee
> can be claimed, the remainder of the expedience fee output is returned to
> the specified address among the inputs/outputs (could be something like
> in#3 for the address used by the 3rd UTXO input). This would have to be
> done for all remaining expedience fees within the last transaction in the
> block, inserted there by the miner.
Inputs don't have addresses, and addresses should only ever be used once.
You might be able to fix this by increasing the value of the change, though.
It would require a new signature-check opcode at the very least.
I don't see a purpose to this proposal. Miners always mine as if it's their
*only* chance to get the fee, because if they don't, another miner will. Ie,
after 1 block, the fee effectively drops to 0 already.
> ---
>
> Fee pool. Softfork compatible.
The standard problem with these is that miners are incentivised to publish
their own "out of band fee" address so they get all the fee directly.
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:58:31
in reply to nevent1q…t664
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:58:31Event JSON
{
"id": "0d958c8252a8ad58613d51d5032b2df5b1bb695d4f5b3f1d68bd39fdd89afcc0",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160711,
"kind": 1,
"tags": [
[
"e",
"4f5cc115e4c69b7e46c2ce410bcf3bce353d9771e5f344aee3442cd26791714e",
"",
"root"
],
[
"e",
"1de6e5ff48ea61635053e3b1ee65f9582a4a85ed8a4c12c73eaccb13f4f34aec",
"",
"reply"
],
[
"p",
"f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018"
]
],
"content": "📅 Original date posted:2017-03-30\n📝 Original message:On Thursday, March 30, 2017 9:34:31 AM Natanael via bitcoin-dev wrote:\n\u003e You want to really make sure your transaction gets processed quickly?\n\u003e Transactions could have a second fee type, a specially labeled\n\u003e anyone-can-spend output with an op_return value defining a \"best-before\"\n\u003e block number and some function describing the decline of the fee value for\n\u003e every future block, such that before block N the miners can claim the full\n\u003e expedience fee + the standard fee (if any), between block N+1 and N+X the\n\u003e miner can claim a reduced expedience fee + standard fee, afterwards only\n\u003e the standard fee.\n\nMinor detail: OP_RETURN doesn't work like that. You'd need OP_DROP.\n\n\u003e When a transaction is processed late such that not the full expedience fee\n\u003e can be claimed, the remainder of the expedience fee output is returned to\n\u003e the specified address among the inputs/outputs (could be something like\n\u003e in#3 for the address used by the 3rd UTXO input). This would have to be\n\u003e done for all remaining expedience fees within the last transaction in the\n\u003e block, inserted there by the miner.\n\nInputs don't have addresses, and addresses should only ever be used once.\nYou might be able to fix this by increasing the value of the change, though.\nIt would require a new signature-check opcode at the very least.\n\nI don't see a purpose to this proposal. Miners always mine as if it's their \n*only* chance to get the fee, because if they don't, another miner will. Ie, \nafter 1 block, the fee effectively drops to 0 already.\n\n\u003e ---\n\u003e \n\u003e Fee pool. Softfork compatible.\n\nThe standard problem with these is that miners are incentivised to publish \ntheir own \"out of band fee\" address so they get all the fee directly.\n\nLuke",
"sig": "e9f572f95cd22c6b7dee2abb471437c81ea8a6c108ce5729d4ee5bd2ede82b24c3ae590b591a1e682b0061c8d2cfce7995202fa75ebf6307d842669062100f47"
}