From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VnoCX-0000do-LW for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 11:31:37 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.82 as permitted sender) client-ip=62.13.149.82; envelope-from=pete@petertodd.org; helo=outmail149082.authsmtp.co.uk; Received: from outmail149082.authsmtp.co.uk ([62.13.149.82]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VnoCW-00056Z-Eo for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 11:31:37 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id rB3BVUwk080586; Tue, 3 Dec 2013 11:31:30 GMT Received: from tilt (ge-19-102-21.service.infuturo.it [151.19.102.21]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rB3BVMJt056725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 11:31:28 GMT Date: Tue, 3 Dec 2013 06:31:17 -0500 From: Peter Todd To: Mike Hearn Message-ID: <20131203113117.GA12623@tilt> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 735a79a5-5c0e-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgEUHFAXAgsB AmUbWlVeU1x7W2s7 ag9QcwRUfEtOXRto UVdMSlVNFUsqcx9z YGNkFhl3cQJEfTBx Zk5gWT5cX0Erck8s R1NRRm1TeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4lGjk1 WxEEEn0hEEAeDyw1 I1QdEmBUF0IQP0Mu KjMA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 151.19.102.21/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] X-Headers-End: 1VnoCW-00056Z-Eo Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Floating fees and SPV clients 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: Tue, 03 Dec 2013 11:31:37 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 01, 2013 at 12:51:46PM +0100, Mike Hearn wrote: > 4) Finally, when we next hard fork, we make v2 transactions include the > output value in the signature, same as the output script (this proposal h= as > been on the forums for a while now). That allows the fee data added in st= ep > 2 to be cross-checked against the signatures on the inputs, thus > authenticating it. FTFY s/hard-fork/soft-fork/ The proposals on the forums with regard to a soft-fork are for a new transaction format - to be done in parallel with the old one - that commits to transaction inputs and outputs via a merkle tree extending into the transaction. This data is then committed to via the merge-mine standard. In addition, all this discussion about trying to figure out transaction fees based on transaction is a bit irrelevant if you suppose a soft-fork. We already know that we need a merkle-sum-tree of fees and transaction size to be able to audit miners and create compact fraud proofs, and using that merkle-sum-tree you can easily calculate sum fees/sum size for the whole block to determine fees. We know that we can make a good assumption that transactions in blocks will have been broadcast prior by the assumption you and Gavin are making that miners would by far prefer to mine transactions that have already been broadcast so that block propagation via txid lists works. That advantage is on the order of 10x to 100x (or even higher) lower cost per KB to the miner. (if this is not true, let us all know, because then your scalability arguments are bunk with regard to blocksize) In addition faking fees via non-disclosed high-fee transactions has a cost of about 1% due to the risk your block gets orphaned and the tx fee gets mined by another miner. Between those two the merkle-sum-trees for fees and size can be used for various levels of average fee for a whole block, plus statistical distributions. Next it is also desirable for another, related, soft-fork to include a sorted list of txids and/or H(scriptPubKey)'s in a block. (the latter is explicitly part of my TXO commitments proposal) With the txids version especially it's easy and low-bandwidth for SPV nodes to get proof that a given transaction has been mined recently, by asking for proof of inclusion or exclusion to accompany a bloom filter match. Finally with various anti-sybil techniques that create long-term identities it's easy to show that a peer lied about the data required for fee estimates anyway. > One obvious concern is what to do if nodes don't converge on very similar > estimates. Wallets will always want to pay the lowest fee possible, so th= at > means they'll always be riding the very edge of what's acceptable, opening > up tx propagation to random flaky failures if fee estimates change whilst= a > transaction is in progress, or if some nodes don't calculate the same > estimates as others. Propagation failures are not a major problem if transactions can be rebroadcast with new, higher, fees; propagation failures can be detected easily and quickly with my proof-of-tx-mining proposal. --=20 'peter'[:-1]@petertodd.org 000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJSncEEAAoJECSBQD2l8JH7yMIH/3txXGyQ47+EuPsUy2567wRM Q3L2baGremy+3K+fRn969Y78h9dpckbCiWirWhDIoLQbWaJqB/RlaHjxtMu35Nd+ nmy3iKwJa8RyVNLFASt7XEmpSAKmZElCcdHOABoyfq9bxGqnIlgcV6tJPt1GHytp dIpmEbUgD8/8Ia2EhOK8f+VpjRaCt9ev1UUp+9/iEa9pFafE5WZIxHGzXY0wF+7I kkSwTMFUZG943Lg1U1CeEptBz+Yiu0/hnX4Sz0sHDaog8/NvCy/DjhjAaLxTUqOm VfbNHQw7961GZEeNoTPiNb3EAefibcuF2eeRqkrj/FceTWQeyLlhoff/T00YaT0= =08ST -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW--