path: root/f5/cd34b9a234593ae421a0e692d8fe1afe787d27

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7DC75AD6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Sep 2017 03:30:29 +0000 (UTC)
Received: by mail-pf0-f179.google.com with SMTP id n24so64878pfk.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <mark@friedenbach.org>
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>
	<DC1B3730-756E-4A9B-BE6E-481B78E4104D@mattcorallo.com>
	<20170929021033.GA12303@savin.petertodd.org>
	<CAK8perBDQDN0WvOn3bVxDHCVLjn=chg9=pVoBsVa6U67Qox8GQ@mail.gmail.com>
In-Reply-To: <CAK8perBDQDN0WvOn3bVxDHCVLjn=chg9=pVoBsVa6U67Qox8GQ@mail.gmail.com>
To: Nathan Wilcox <nathan@z.cash>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>=20
>=20
>=20
>> On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev <bitcoin-dev=
@lists.linuxfoundation.org> 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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto">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.<br><div><br>On Sep 28, 2=
017, at 7:17 PM, Nathan Wilcox via bitcoin-dev &lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
; wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><br><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Sep 29, 2017=
 at 11:10 AM, Peter Todd via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><span class=3D"">On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo v=
ia bitcoin-dev wrote:<br>
&gt; 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.<br>
<br>
</span>Note too that the fee users are willing to pay often changes over tim=
e.<br>
<br>
My OpenTimestamps service is a perfect example: getting a timestamp confirme=
d<br>
within 10 minutes of the previous one has little value to me, but if the<br>=

previous completed timestamp was 24 hours ago I'm willing to pay significant=
ly<br>
more money because the time delay is getting significant enough to affect th=
e<br>
trustworthyness of the entire service. So the fee selection mechanism is<br>=

nothing more than a RBF-using loop that bumps the fee every time a block get=
s<br>
mined w/o confirming my latest transaction.<br>
<br>
This kind of time sensitivity is probably true of a majority of Bitcoin<br>
use-cases, with the caveat that often the slope will be negative eventually:=
<br>
after a point in time completing the transaction has no value.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><br></d=
iv><div class=3D"gmail_quote">Wouldn't this RBF loop behave pretty much the s=
ame in the Monopolistic Price Mechanism? (I haven't grokked RSOP yet.)<br><b=
r></div><div>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?<br><br>&nbsp;</div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">https=
://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"no=
referrer" target=3D"_blank">petertodd.org</a><br>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<=
wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/m=
ailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=

--Apple-Mail-22B6CA07-3A93-4A3A-A1B9-DE6FD639BE15--