Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7DC75AD6 for ; Fri, 29 Sep 2017 03:30:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com [209.85.192.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B1AC3FC for ; Fri, 29 Sep 2017 03:30:29 +0000 (UTC) Received: by mail-pf0-f179.google.com with SMTP id n24so64878pfk.5 for ; Thu, 28 Sep 2017 20:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=GXXQm74x2ToNmR8HZ5OSq5f9O+opZq/dAwFc83Q8jg4=; b=gDE80T+IzEd6+Jty13UMos33SFOSbN1HIYFWY3jHnG3QAyrrEaLoDm1P7RDmUHlOvW zMkL0c7uG3Yz5nqWfpCqixdhZUqYC11LcwayLF0ur30huAjr/ErnAuSUH6+p+Ao1bprB 6MMcyGJBJ1gtG9LIq70Y47qv23suSk/0S9YeEX23eq8HDj2RYGj9CWl4M+anlVPKDf58 RIPtGnuM9ZKn40GtOB2V9RzxkMrmYABr8ZEBaXjas9Gvv2/wYb2u6nwRilLk1kOOMlu2 K30GJN/ijFgVOaJZzU1or/eFt2MpKtZqndXdigmJA5pdIyBVbE/nmPwfAJgcTRtJ608S z3CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=GXXQm74x2ToNmR8HZ5OSq5f9O+opZq/dAwFc83Q8jg4=; b=RUL/ZLz9qLN7QPTG4bs7HZebAwzJ/P0C09beOsvB0atfuQO8LK199sBUH/XyTQqxpZ 4RZ22v2MVTMuybz2NTjz67r5ChYMC4mQgdlDFtoy0XL9XtFPl2e6vY39O03FClRiUx6Q GlwyZr954Xnk1PfHedrshBaq3xrW3rJNDEnu38x4zFNv1WJHBR1RMCRMpq0O/7Tu560k vCqKu6Yw4zddtnQl9YB7uV88bpZzotK2kwltQw4xvhVqcNa3Qw58Vk86C4lwgf7vLeii viRl9KXiXLKcx5ZBkd1yWxyVjWMSSLiGdDnBKM9u+2mjxFleeUUMcDWsA+3FTFd/sVqJ lJ7g== X-Gm-Message-State: AHPjjUiNhQ9QLLB/5Mf2zsS31Je3gplpiulQY4AtfBexrpZ8NkJdvEdL RHJLIh3nP1CQWNtHRRRJvdBi/KySx8c= X-Google-Smtp-Source: AOwi7QBVyrSdDMuXRYH6VXtvXmhMnbFsACIeEkNy1DOEdIjCtr0Bd/gtpPvBLDEHb2Vksf2oj7HN0A== X-Received: by 10.99.45.67 with SMTP id t64mr6080032pgt.62.1506655829283; Thu, 28 Sep 2017 20:30:29 -0700 (PDT) Received: from ?IPv6:2601:646:8080:1291:e45d:dd5d:7212:1e7c? ([2601:646:8080:1291:e45d:dd5d:7212:1e7c]) by smtp.gmail.com with ESMTPSA id t81sm5034908pfg.154.2017.09.28.20.30.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Sep 2017 20:30:28 -0700 (PDT) From: Mark Friedenbach Content-Type: multipart/alternative; boundary=Apple-Mail-22B6CA07-3A93-4A3A-A1B9-DE6FD639BE15 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Thu, 28 Sep 2017 20:30:27 -0700 Message-Id: <53AEC8D5-EF33-434A-85C7-9CF824C1FDF2@friedenbach.org> References: <359FFE85-86AF-4FBD-9491-3528382E5002@friedenbach.org> <20170929021033.GA12303@savin.petertodd.org> In-Reply-To: To: Nathan Wilcox , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (15A402) X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 29 Sep 2017 04:09:33 +0000 Subject: Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 03:30:30 -0000 --Apple-Mail-22B6CA07-3A93-4A3A-A1B9-DE6FD639BE15 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Only if your keys are online and the transaction is self-signed. It wouldn=A1= =AFt let you pre-sign a transaction for a third party to broadcast and have i= t 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 wrote: >=20 >=20 >=20 >> On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev wrote: >> On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo via bitcoin-dev wr= ote: >> > I'm somewhat curious what the authors envisioned the real-world implica= tions of this model to be. While blindly asking users to enter what they're w= illing to pay always works in theory, I'd imagine in such a world the fee se= lection UX would be similar to what it is today - users are provided a list o= f 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 nece= ssary fee estimation could be more willing to overshoot and the UX around RB= F and CPFP could be simplified greatly, but I'm not actually convinced that i= t would result in higher overall mining revenue. >>=20 >> Note too that the fee users are willing to pay often changes over time. >>=20 >> My OpenTimestamps service is a perfect example: getting a timestamp confi= rmed >> 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 signific= antly >> 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 g= ets >> mined w/o confirming my latest transaction. >>=20 >> 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 eventual= ly: >> after a point in time completing the transaction has no value. >>=20 >=20 > Wouldn't this RBF loop behave pretty much the same in the Monopolistic Pri= ce Mechanism? (I haven't grokked RSOP yet.) >=20 > In fact, so long as RBF works, isn't it possible to raise Pay-Your-Bid fee= s and Monopolistic Price fees over time to express the time curve preference= ? >=20 > =20 >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-22B6CA07-3A93-4A3A-A1B9-DE6FD639BE15 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Only if your keys are online and the transa= ction is self-signed. It wouldn=E2=80=99t 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, 2= 017, at 7:17 PM, Nathan Wilcox via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>= ; wrote:



On Fri, Sep 29, 2017= at 11:10 AM, Peter Todd via bitcoin-dev <bitcoin-dev@li= sts.linuxfoundation.org> wrote:
On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo v= ia bitcoin-dev wrote:
> I'm somewhat curious what the authors envisioned the real-world implica= tions of this model to be. While blindly asking users to enter what they're w= illing to pay always works in theory, I'd imagine in such a world the fee se= lection UX would be similar to what it is today - users are provided a list o= f 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 nece= ssary fee estimation could be more willing to overshoot and the UX around RB= F and CPFP could be simplified greatly, but I'm not actually convinced that i= t would result in higher overall mining revenue.

Note too that the fee users are willing to pay often changes over tim= e.

My OpenTimestamps service is a perfect example: getting a timestamp confirme= d
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 significant= ly
more money because the time delay is getting significant enough to affect th= e
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 get= s
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 s= ame 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-Y= our-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@lists.<= wbr>linuxfoundation.org
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev


____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-22B6CA07-3A93-4A3A-A1B9-DE6FD639BE15--