Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z3nWR-0003wk-N7 for bitcoin-development@lists.sourceforge.net; Sat, 13 Jun 2015 15:39:03 +0000 X-ACL-Warn: Received: from mail-oi0-f43.google.com ([209.85.218.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z3nWQ-0002qe-2T for bitcoin-development@lists.sourceforge.net; Sat, 13 Jun 2015 15:39:03 +0000 Received: by oigz2 with SMTP id z2so36813741oig.1 for ; Sat, 13 Jun 2015 08:38:56 -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=x72DjTrgc39yWSKDhCRvBjSGEZ2dloUo4qM957jph0o=; b=G2h0G9pupoVoklVSy4wIzJGERE06GFC1Fmqa4rJRfvXNx0UJLk1cgXlGab+xXFRzWk 78/30DX3lOQYEVaWsXg1o/G9LSCiaS0haMZVIwMVe+osoEN4+jbybQESXdUpr3gHvaGA cSS/DRtAKh7d65IobLs4gIdjm91rr0EQ9wSR4QeJF8whQV8Pv1ljEnb3DmQs4V1qnwGC zfdXkvMnI90obJt4WFHRQJhg6f+Yf/CKsdSjtch34bKEHtHKOLQali72vIDXJWv2B2W0 PZ3h5o/x3RKhk+j821yrZ8uDn3u3c3jD9AaIgnMa7SwJkTsq3Hvm/PHQ2/Ko5qxsHpAW oqwA== X-Gm-Message-State: ALoCoQm6ZZmndmFqSjjVWFYV56bF8Ij1mSXTyRIG4g+9B0kvUxpFNrIG2zix94YXbTTVxYEK5tAY MIME-Version: 1.0 X-Received: by 10.60.102.37 with SMTP id fl5mr13203259oeb.72.1434209936576; Sat, 13 Jun 2015 08:38:56 -0700 (PDT) Received: by 10.182.47.229 with HTTP; Sat, 13 Jun 2015 08:38:56 -0700 (PDT) In-Reply-To: References: <20150610200323.GA13724@savin.petertodd.org> Date: Sat, 13 Jun 2015 09:38:56 -0600 Message-ID: From: Nathan Wilcox To: Aaron Voisine Content-Type: multipart/alternative; boundary=089e0111bce0cdc3f4051868052a 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: 1Z3nWQ-0002qe-2T 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: Sat, 13 Jun 2015 15:39:03 -0000 --089e0111bce0cdc3f4051868052a Content-Type: text/plain; charset=UTF-8 On Thu, Jun 11, 2015 at 12:55 PM, Aaron Voisine wrote: > > 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. > > You don't know the fees paid by any given transaction unless you also have > all it's inputs. Transaction inputs do not include an amount. You could > however get the average fee-per-kb paid by all transactions in a block by > looking at the coinbase transaction, subtracting the block reward, and > dividing by the size of block minus the header. > > Excellent point and alternative proposal. You're right: to get the specifi fees, you'd need all transactions in a block, and all TxOuts with membership proofs. Your alternative seems like a much leaner trade-off for similar data. > > Aaron Voisine > co-founder and CEO > breadwallet.com > > On Thu, Jun 11, 2015 at 11:30 AM, Nathan Wilcox > wrote: > >> 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 >> > > -- Nathan Wilcox Least Authoritarian email: nathan@leastauthority.com twitter: @least_nathan PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993 --089e0111bce0cdc3f4051868052a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 11, 2015 at 12:55 PM, Aaron Voisine <<= a href=3D"mailto:voisine@gmail.com" target=3D"_blank">voisine@gmail.com= > wrote:
>=C2=A0A 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

You don't know the fees paid b= y any given transaction unless you also have all it's inputs. Transacti= on inputs do not include an amount. You could however get the average fee-p= er-kb paid by all transactions in a block by looking at the coinbase transa= ction, subtracting the block reward, and dividing by the size of block minu= s the header.


Excellent point a= nd alternative proposal. You're right: to get the specifi fees, you'= ;d need all transactions in a block, and all TxOuts with membership proofs.= Your alternative seems like a much leaner trade-off for similar data.
= =C2=A0
<= span class=3D"">

A= aron Voisine
co-founder and CEO
breadwallet.com

On Thu, Jun 11= , 2015 at 11:30 AM, Nathan Wilcox <nathan@leastauthority.com&g= t; wrote:
O= n Wed, Jun 10, 2015 at 2:03 PM, Peter Todd <pete@petertodd.org> wrote:
On Wed, Jun 10, 2015 at 02:00:2= 7PM -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 before. I do= n't understand the marketplace here or why miners would want to move fe= es outside of explicit inband fees. Implicit in this proposal is that the s= tatistics only cover in-band data, because that's the scope of consensu= s rules, and thus the proposal is only as useful as the information of in-b= and fees is useful.

I've also noticed a detracting technical arg= ument given a particular tradeoff:

A Header-PoW-verifying client cou= ld 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 those transa= ctions versus the need to alter any consensus rules or do soft forks.
Notice how this trade-off's costs change with maximum bloc= k size.


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



-- =




--
Nathan Wilcox
Least Authoritarian

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