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 > <[email protected]> wrote: > > > >> On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev >> <[email protected]> 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 >> [email protected] >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
