From: Jeff Garzik <jgarzik@bitpay•com>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire
Date: Fri, 18 Jul 2014 09:53:35 -0400 [thread overview]
Message-ID: <CAJHLa0NZRF+1QjSwtwjaTE07NWJ_U-O-DE24=P5eSAutMqTupg@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T0ag_o_mu=5Q7Ju7s2hO3jz-o5g9FihE9h4B6+ednd2Pg@mail.gmail.com>
On Thu, Jul 17, 2014 at 6:46 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
> I'd encourage you to code up a prototype first (or at the same time), in
> whatever programming language / networking library you're most familiar
> with.
+1
> Maybe not even using the existing p2p protocol; there could be a mining-only
> very-fast-block-propagation network separate from the existing p2p network.
>
> Combining your optimizations with "broadcast as many near-miss blocks as
> bandwidth will allow" on a mining backbone network should allow insanely
> fast propagation of most newly solved blocks.
Yes, I would encourage thinking along these lines. That was the
motivation of the UDP P2P protocol extension I wrote:
https://bitcointalk.org/index.php?topic=156769.0
The intention was to experiment with sending block header + tx list +
coinbase, via UDP best effort broadcast.
Incentives:
If your neighbors receiving this message already have the TXs in the
TX list, then the block is complete, and may be relayed further.
If your neighbors do not have all TXs in the block, they must fetch
them at additional time/latency cost.
Thus, you have an incentive to relay blocks containing TXs already
distributed out into network mempools and cached in the signature
cache.
We want to capture that incentive in whatever protocol is eventually
used. Miners have a TX fee incentive to include many transactions.
In theory, they want to include as many TX as possible. It will help
us scale quite a bit to solve this problem.
next prev parent reply other threads:[~2014-07-18 13:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-17 21:35 Kaz Wesley
2014-07-17 22:46 ` Gavin Andresen
2014-07-17 23:26 ` Kaz Wesley
2014-07-18 13:53 ` Jeff Garzik [this message]
2014-07-18 14:53 ` Gavin Andresen
2014-07-18 15:06 ` Jeff Garzik
2014-07-18 17:39 ` Kaz Wesley
2014-07-18 17:48 ` Jeff Garzik
2014-07-18 17:53 ` Kaz Wesley
2014-07-18 19:51 ` Kaz Wesley
2014-07-18 19:55 ` Jeff Garzik
2014-07-19 0:54 ` Emin Gün Sirer
2014-07-19 1:25 ` Gregory Maxwell
2014-07-19 3:06 ` Emin Gün Sirer
2014-07-19 6:48 ` Gregory Maxwell
2014-07-19 8:06 ` Wladimir
2014-07-17 23:34 ` Gregory Maxwell
[not found] ` <CABsx9T2PSa3MpfMMDCb8ACVF5vDOZOFLEK9zfP9PakgHA4U16w@mail.gmail.com>
[not found] ` <CAPkFh0vKFnKRE-sd-Z9t1zB73VLPsiaQ3o=OYgBqqtUE4_rTaw@mail.gmail.com>
2014-07-31 20:47 ` Kaz Wesley
2014-07-31 21:29 ` Gregory Maxwell
2014-07-31 21:41 ` Kaz Wesley
2014-07-31 21:51 ` Gregory Maxwell
2014-07-31 22:27 ` Kaz Wesley
2014-07-31 23:18 ` Gregory Maxwell
2014-08-01 1:00 ` Kaz Wesley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJHLa0NZRF+1QjSwtwjaTE07NWJ_U-O-DE24=P5eSAutMqTupg@mail.gmail.com' \
--to=jgarzik@bitpay$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox