📅 Original date posted:2017-09-29
📝 Original message:Only if your keys are online and the transaction is self-signed. It wouldn’t let you pre-sign a transaction for a third party to broadcast and have it clear at just the market rate in the future. Like a payment channel refund, for example.
> On Sep 28, 2017, at 7:17 PM, Nathan Wilcox via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>
>> On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo via bitcoin-dev wrote:
>> > I'm somewhat curious what the authors envisioned the real-world implications of this model to be. While blindly asking users to enter what they're willing to pay always works in theory, I'd imagine in such a world the fee selection UX would be similar to what it is today - users are provided a list of options with feerates and expected confirmation times from which to select. Indeed, in a world where users pay a lower fee if they paid more than necessary fee estimation could be more willing to overshoot and the UX around RBF and CPFP could be simplified greatly, but I'm not actually convinced that it would result in higher overall mining revenue.
>>
>> Note too that the fee users are willing to pay often changes over time.
>>
>> My OpenTimestamps service is a perfect example: getting a timestamp confirmed
>> within 10 minutes of the previous one has little value to me, but if the
>> previous completed timestamp was 24 hours ago I'm willing to pay significantly
>> more money because the time delay is getting significant enough to affect the
>> trustworthyness of the entire service. So the fee selection mechanism is
>> nothing more than a RBF-using loop that bumps the fee every time a block gets
>> mined w/o confirming my latest transaction.
>>
>> This kind of time sensitivity is probably true of a majority of Bitcoin
>> use-cases, with the caveat that often the slope will be negative eventually:
>> after a point in time completing the transaction has no value.
>>
>
> Wouldn't this RBF loop behave pretty much the same in the Monopolistic Price Mechanism? (I haven't grokked RSOP yet.)
>
> In fact, so long as RBF works, isn't it possible to raise Pay-Your-Bid fees and Monopolistic Price fees over time to express the time curve preference?
>
>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> 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/20170928/acc90653/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 18:06:35
in reply to nevent1q…z43z
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 18:06:35Event JSON
{
"id": "ccc557e4a704ca1086786981dff11fe4d39e7678fbbc5f526b12a0195083542b",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686161195,
"kind": 1,
"tags": [
[
"e",
"ae5bb64562efc3a1339440e5c70f6b3b8b12997d5b034703d0bb377a6fd6447b",
"",
"root"
],
[
"e",
"8b6047d831b6ac60034b32bc581c63c61ff67176bd8ee768dd31c785491d8e21",
"",
"reply"
],
[
"p",
"523c0d5379d2d258d92dab5f63a52d60a8a6d34ce6d11f9c60c3f64b24727aaf"
]
],
"content": "📅 Original date posted:2017-09-29\n📝 Original message:Only if your keys are online and the transaction is self-signed. It wouldn’t let you pre-sign a transaction for a third party to broadcast and have it clear at just the market rate in the future. Like a payment channel refund, for example.\n\n\u003e On Sep 28, 2017, at 7:17 PM, Nathan Wilcox via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e \n\u003e \n\u003e\u003e On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo via bitcoin-dev wrote:\n\u003e\u003e \u003e I'm somewhat curious what the authors envisioned the real-world implications of this model to be. While blindly asking users to enter what they're willing to pay always works in theory, I'd imagine in such a world the fee selection UX would be similar to what it is today - users are provided a list of options with feerates and expected confirmation times from which to select. Indeed, in a world where users pay a lower fee if they paid more than necessary fee estimation could be more willing to overshoot and the UX around RBF and CPFP could be simplified greatly, but I'm not actually convinced that it would result in higher overall mining revenue.\n\u003e\u003e \n\u003e\u003e Note too that the fee users are willing to pay often changes over time.\n\u003e\u003e \n\u003e\u003e My OpenTimestamps service is a perfect example: getting a timestamp confirmed\n\u003e\u003e within 10 minutes of the previous one has little value to me, but if the\n\u003e\u003e previous completed timestamp was 24 hours ago I'm willing to pay significantly\n\u003e\u003e more money because the time delay is getting significant enough to affect the\n\u003e\u003e trustworthyness of the entire service. So the fee selection mechanism is\n\u003e\u003e nothing more than a RBF-using loop that bumps the fee every time a block gets\n\u003e\u003e mined w/o confirming my latest transaction.\n\u003e\u003e \n\u003e\u003e This kind of time sensitivity is probably true of a majority of Bitcoin\n\u003e\u003e use-cases, with the caveat that often the slope will be negative eventually:\n\u003e\u003e after a point in time completing the transaction has no value.\n\u003e\u003e \n\u003e \n\u003e Wouldn't this RBF loop behave pretty much the same in the Monopolistic Price Mechanism? (I haven't grokked RSOP yet.)\n\u003e \n\u003e In fact, so long as RBF works, isn't it possible to raise Pay-Your-Bid fees and Monopolistic Price fees over time to express the time curve preference?\n\u003e \n\u003e \n\u003e\u003e --\n\u003e\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/acc90653/attachment.html\u003e",
"sig": "c1e161b1d9dfe671594b50282c1e81ff749fd7c575e8401ee2a3290fb58744c1cb4a777d2990a80e3640f53427836525b0f0816938d75a4d1dc5d07615dd3fc3"
}