From: Gavin Andresen <gavinandresen@gmail.com>
To: "Emin Gün Sirer" <el33th4x0r@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Draft] Datastream compression of Blocks and Transactions
Date: Thu, 3 Dec 2015 14:14:55 -0500 [thread overview]
Message-ID: <CABsx9T3+y6ip3cUW8jP-0n+1FS8t_FdX8fA42JaTO7qW5pMhzA@mail.gmail.com> (raw)
In-Reply-To: <CAPkFh0t9SwVOLrPnL7z80s-Rriezhqxn_3vXKYRxr6JVGNiUZQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
On Wed, Dec 2, 2015 at 1:57 PM, Emin Gün Sirer <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> How to Do It
>
> If we want to compress Bitcoin, a programming challenge/contest would be
> one of the best ways to find the best possible, Bitcoin-specific
> compressor. This is the kind of self-contained exercise that bright young
> hackers love to tackle. It'd bring in new programmers into the ecosystem,
> and many of us would love to discover the limits of compressibility for
> Bitcoin bits on a wire. And the results would be interesting even if the
> final compression engine is not enabled by default, or not even merged.
>
I love this idea. Lets build a standardized data set to test against using
real data from the network (has anybody done this yet?).
Something like:
Starting network topology:
list of: nodeid, nodeid, network latency between the two peers
Changes to network topology:
list of: nodeid, add/remove nodeid, time of change
Transaction broadcasts:
list of : transaction, node id that first broadcast, time first broadcast
Block broadcasts:
list of : block, node id that first broadcast, time first broadcast
Proposed transaction/block optimizations could then be measured against
this standard data set.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 2468 bytes --]
next prev parent reply other threads:[~2015-12-03 19:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-30 23:12 [bitcoin-dev] [BIP Draft] Datastream compression of Blocks and Transactions Peter Tschipper
2015-12-01 5:28 ` Matt Corallo
2015-12-01 20:06 ` Pavel Janík
[not found] ` <565E30C6.1010002@bitcartel.com>
2015-12-02 6:47 ` Pavel Janík
2015-12-02 7:33 ` Simon Liu
2015-12-02 18:45 ` Patrick Strateman
2015-12-02 18:57 ` Emin Gün Sirer
2015-12-02 20:16 ` Peter Tschipper
2015-12-02 22:23 ` Matt Corallo
2015-12-02 23:02 ` Peter Tschipper
2015-12-04 13:30 ` Matt Corallo
2015-12-03 19:14 ` Gavin Andresen [this message]
2015-12-03 23:07 ` Rusty Russell
2015-12-02 23:05 ` Peter Tschipper
2015-12-03 5:52 ` Dave Scotese
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=CABsx9T3+y6ip3cUW8jP-0n+1FS8t_FdX8fA42JaTO7qW5pMhzA@mail.gmail.com \
--to=gavinandresen@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=el33th4x0r@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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