diff options
| author | Jeff Garzik <jgarzik@bitpay.com> | 2014-07-18 11:06:23 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-07-18 15:06:51 +0000 |
| commit | c1483c93cbbe60f877c5684b6c0698833c738f4e (patch) | |
| tree | c529757aa1bed9bbb42c778d90ee8b6bfecfb7bb | |
| parent | 89d654c60ad868a51959a96f38d69a97a41bea49 (diff) | |
| download | pi-bitcoindev-c1483c93cbbe60f877c5684b6c0698833c738f4e.tar.gz pi-bitcoindev-c1483c93cbbe60f877c5684b6c0698833c738f4e.zip | |
Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire
| -rw-r--r-- | da/fa8952238631929b1a0311d7e96d0b5c142ceb | 119 |
1 files changed, 119 insertions, 0 deletions
diff --git a/da/fa8952238631929b1a0311d7e96d0b5c142ceb b/da/fa8952238631929b1a0311d7e96d0b5c142ceb new file mode 100644 index 000000000..d06c989e6 --- /dev/null +++ b/da/fa8952238631929b1a0311d7e96d0b5c142ceb @@ -0,0 +1,119 @@ +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 <jgarzik@bitpay.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <CABsx9T2BDBNqvinVNk3FmBRWU7R8jf6Vm6NaH74te0FRCh1O-w@mail.gmail.com> +References: <CA+iPb=EaX=bvOjNtZ+LnYTMRLQQ9nFcrefAkBdv8eActoX_b8A@mail.gmail.com> + <CABsx9T0ag_o_mu=5Q7Ju7s2hO3jz-o5g9FihE9h4B6+ednd2Pg@mail.gmail.com> + <CAJHLa0NZRF+1QjSwtwjaTE07NWJ_U-O-DE24=P5eSAutMqTupg@mail.gmail.com> + <CABsx9T2BDBNqvinVNk3FmBRWU7R8jf6Vm6NaH74te0FRCh1O-w@mail.gmail.com> +From: Jeff Garzik <jgarzik@bitpay.com> +Date: Fri, 18 Jul 2014 11:06:23 -0400 +Message-ID: <CAJHLa0O=eCoyvV19dWgTnYd9Di0wLLZtWmCPidc-dWqPNQv_oQ@mail.gmail.com> +To: Gavin Andresen <gavinandresen@gmail.com> +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 <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Fri, 18 Jul 2014 15:06:52 -0000 + +On Fri, Jul 18, 2014 at 10:53 AM, Gavin Andresen +<gavinandresen@gmail.com> 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/ + + |