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 1X89kJ-0002eB-QA for bitcoin-development@lists.sourceforge.net; Fri, 18 Jul 2014 15:06:51 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com designates 74.125.82.177 as permitted sender) client-ip=74.125.82.177; envelope-from=jgarzik@bitpay.com; helo=mail-we0-f177.google.com; Received: from mail-we0-f177.google.com ([74.125.82.177]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1X89kI-00056x-1G for bitcoin-development@lists.sourceforge.net; Fri, 18 Jul 2014 15:06:51 +0000 Received: by mail-we0-f177.google.com with SMTP id w62so4660550wes.8 for ; Fri, 18 Jul 2014 08:06:43 -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:from:date :message-id:subject:to:cc:content-type; bh=gkoy2TIA4hHQqfqT+speDNa/TSgnNP+Vhac+Iy/eJ/4=; b=jFmeN8QMyOwLVeYt6goqh6j5nhR4dV8UXl90JY7C10RdjzKP1UZC8ZBrzK9MI4NbBh SL9JQVG4XqqNpTNiBbAMdH4o/NRbv35AKt1EVPBPT0kNEf9yrhIv2URTx/dKcLhzfsYV 2TwBUxhv71i5lKy0NXyyHLyOGfFv7tHRbvpXoLn8QyFIF5zLZhy8CWhFRfjz7HDCIcCp yYnEUOabzxu4jaRZhKneOtP0rpmkabDX5QNtJpaq7CZbwmUs3UAuipxqEZabA6jtEOOd +6FdR5jvNTC2eVhCfIfbwu8dG5/ozl7Fo47XXE95ZFHvkb0uWX8QxzpccLzEv7MRV9G8 6QVg== X-Gm-Message-State: ALoCoQldGrOUaaBUx51/Oe/byM0lG9R1FtucXAupdSSAsf0mO4KijM/wJ6t+RkCDa0Q8QFZjcoc3 X-Received: by 10.194.172.167 with SMTP id bd7mr7844536wjc.74.1405696003647; Fri, 18 Jul 2014 08:06:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.5.67 with HTTP; Fri, 18 Jul 2014 08:06:23 -0700 (PDT) In-Reply-To: References: From: Jeff Garzik Date: Fri, 18 Jul 2014 11:06:23 -0400 Message-ID: To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) 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.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1X89kI-00056x-1G Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire 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: Fri, 18 Jul 2014 15:06:52 -0000 On Fri, Jul 18, 2014 at 10:53 AM, Gavin Andresen wrote: > But if there was some agreed-upon canonical ordering, then it should > theoretically be possible to take shortcuts in the "what order". > > You'd start with setof(transactions I think everybody knows about) > Select some subset, based on miner's policy > Sort that subset with the canonical ordering algorithm > Very efficiently broadcast, taking all sorts of shortcuts assuming most of > your peers already know the set you started with and expect the same > canonical ordering (see gmaxwell's thoughts on block encoding). Related implementation detail: Having pursued this train of thought, I noted that you don't want to include too-young transactions that you received in the past few seconds, because those are likely still propagating around the network. > Second half-baked thought: > I wonder if broadcasting your transaction selection policy ("11KB of free > transactions, sorted by priority, then 111K of fee-paying transactions, > sorted by fee") might make it possible to save even more bandwidth by > letting your peers create a very good approximation of your block with just > that information.... Absolutely. One path I would like to see pursued is multiple p2pool-esque chains. Each with their own policy, perhaps with their own administrative team. ie. you could have a fully decentralized p2pool-like chain, or multiple such chains, each with a stated policy/reward pattern. Or, GHash/BTCGuild/Eligius could run a semi-centrally managed chain ultimately guaranteed not only by protocol but by administrators' digital signatures. In each case, advertising technical attributes about your pool [chain] policy would give nodes the better ability to predict what is in an upcoming block. And the flip side of that, such predictions are never perfect. Need to make sure the fallback case, while undoubtedly more costly than the Fast Path, is not overly painful. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/