From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z37Fo-0002Iu-MC for bitcoin-development@lists.sourceforge.net; Thu, 11 Jun 2015 18:31:04 +0000 X-ACL-Warn: Received: from mail-oi0-f41.google.com ([209.85.218.41]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z37Fk-0003mo-5N for bitcoin-development@lists.sourceforge.net; Thu, 11 Jun 2015 18:31:04 +0000 Received: by oihd6 with SMTP id d6so8460990oih.2 for ; Thu, 11 Jun 2015 11:30:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MzkUZUmMD96atMY3EgbmHFgkh8JHK/rmV/PCVXhDhpM=; b=DF1SJstruPutsAtZxEEI4XMupj6W6lk8rtoAHqiJjAVeXyC/3BP/23qsmLqoK4chx7 UKSkVpFnxr+BivnioaH+9oaDnArORhaxh2ff29STijewoIDBD8HhbStH9pjyWKAZDWcV ADwmGU0jUBDFwCRR6PV4zZcfMmH8nINe56oEUHAxuWTXWL/dF/LMaObK6x/bjmzjjKwQ Qt7M79hpFEJ0JTPJHRVLRKBcj4MHFsvBffwO/c6VCya2fa/qYUeINv5OTU6upuCLxE04 nF75wfft/FqoACohin7VSWsm6JjLhll1/Xd3xVMtBpbWbHKyg1DJVNunHngGS28vSrnc +Q+A== X-Gm-Message-State: ALoCoQmA3XUvv9lqL8hHDLNfGOeQlyQ+Kf1Gh1WNZruqimiecb8g/6+g1LSuEjlOThaitNI7uYkE MIME-Version: 1.0 X-Received: by 10.182.240.228 with SMTP id wd4mr8687264obc.79.1434047454744; Thu, 11 Jun 2015 11:30:54 -0700 (PDT) Received: by 10.182.47.229 with HTTP; Thu, 11 Jun 2015 11:30:54 -0700 (PDT) In-Reply-To: <20150610200323.GA13724@savin.petertodd.org> References: <20150610200323.GA13724@savin.petertodd.org> Date: Thu, 11 Jun 2015 12:30:54 -0600 Message-ID: From: Nathan Wilcox To: Peter Todd Content-Type: multipart/alternative; boundary=089e01634d6e21a5e10518423130 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Z37Fk-0003mo-5N Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 18:31:04 -0000 --089e01634d6e21a5e10518423130 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd wrote: > On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote: > > On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine > wrote: > > > > > It could be done by agreeing on a data format and encoding it in an > > > op_return output in the coinbase transaction. If it catches on it could > > > later be enforced with a soft fork. > > > > > > > > Sounds plausible, except SPV protocols would need to include this > coinbase > > txn if it's going to help SPV clients. (Until a softfork is activated, > SPV > > clients should not rely on this encoding, since until that time the > results > > can be fabricated by individual miners.) > > Fee stats can always be fabricated by individual miners because fees can > be paid out-of-band. > > This is a point I hadn't considered carefully before. I don't understand the marketplace here or why miners would want to move fees outside of explicit inband fees. Implicit in this proposal is that the statistics only cover in-band data, because that's the scope of consensus rules, and thus the proposal is only as useful as the information of in-band fees is useful. I've also noticed a detracting technical argument given a particular tradeoff: A Header-PoW-verifying client could still be given all transactions in a recent block, from which it can see the in-band fees directly. The trade-off is the size of those transactions versus the need to alter any consensus rules or do soft forks. Notice how this trade-off's costs change with maximum block size. > -- > 'peter'[:-1]@petertodd.org > 00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f > -- Nathan Wilcox Least Authoritarian email: nathan@leastauthority.com twitter: @least_nathan PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993 --089e01634d6e21a5e10518423130 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd <pete@petert= odd.org> wrote:
On Wed, Jun 10,= 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:
> On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <voisine@gmail.com> wrote:
>
> > It could be done by agreeing on a data format and encoding it in = an
> > op_return output in the coinbase transaction. If it catches on it= could
> > later be enforced with a soft fork.
> >
> >
> Sounds plausible, except SPV protocols would need to include this coin= base
> txn if it's going to help SPV clients. (Until a softfork is activa= ted, SPV
> clients should not rely on this encoding, since until that time the re= sults
> can be fabricated by individual miners.)

Fee stats can always be fabricated by individual miners because fees= can
be paid out-of-band.


This is a point I hadn't considered carefully be= fore. I don't understand the marketplace here or why miners would want = to move fees outside of explicit inband fees. Implicit in this proposal is = that the statistics only cover in-band data, because that's the scope o= f consensus rules, and thus the proposal is only as useful as the informati= on of in-band fees is useful.

I've also noticed a detracting tec= hnical argument given a particular tradeoff:

A Header-PoW-verifying = client could still be given all transactions in a recent block, from which = it can see the in-band fees directly.=C2=A0 The trade-off is the size of th= ose transactions versus the need to alter any consensus rules or do soft fo= rks.

Notice how this trade-off's costs change with ma= ximum block size.


=C2=A0
--
'peter'[:-1]@pet= ertodd.org
00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f



--
Nathan Wilcox
Least Authoritarian

email: nathan@leastau= thority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7= 514C 67ED =C2=A0E9C9 3BFE 5263 1116 9993
--089e01634d6e21a5e10518423130--