Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 74.125.82.174 as permitted sender)
	client-ip=74.125.82.174; envelope-from=jgarzik@bitpay.com;
	helo=mail-we0-f174.google.com; 
MIME-Version: 1.0
In-Reply-To: <CA+iPb=FZS9FxP9uYWHTzLpSVJ2uaOwr4dTQSvYuJjhVYCcJOew@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>
	<CAJHLa0O=eCoyvV19dWgTnYd9Di0wLLZtWmCPidc-dWqPNQv_oQ@mail.gmail.com>
	<CA+iPb=H2fkjCxS7-hYqHjFzfMh6onk5RqZMxa8zsXeTn6pQMpA@mail.gmail.com>
	<CAJHLa0NRUdAPuKXgKDBmXOs9to7gMpHv9ECCz_hTfZpg7SVVJA@mail.gmail.com>
	<CA+iPb=HhGkiuaAxQMvpDpUdeU0uA5unPa_0uHGkS3LrmJzEnyQ@mail.gmail.com>
	<CA+iPb=FZS9FxP9uYWHTzLpSVJ2uaOwr4dTQSvYuJjhVYCcJOew@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Fri, 18 Jul 2014 15:55:52 -0400
Message-ID: <CAJHLa0MSdafZiXNH_L8qqH63n3wP5hb0R=EX3SJtsD40Fq_VOA@mail.gmail.com>
To: Kaz Wesley <keziahw@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Squashing redundant tx data in blocks on
 the wire
Precedence: list

Related:  We must handle some legitimate miner-privately-mined cases,
such as miner payout TXs (outside coinbase) or side chain conditional
TXs[1].

[1] https://bitcointalk.org/index.php?topic=676703.msg7682680#msg7682680

On Fri, Jul 18, 2014 at 3:51 PM, Kaz Wesley <keziahw@gmail.com> wrote:
> I've updated the gist, and added an additional proposal that I think
> meshes well:
> https://gist.github.com/kazcw/43c97d3924326beca87d#ultra-fast-block-validation
>
> sparseblocks + UFBV would tighten the new-block process to this (when
> txes have been received in advance):
> - receive block (~2kB for 1000 tx)
> - check whether block contains txes known to belong to conflict-sets,
> and if so whether more than one tx from a single conflict-set has been
> included (a few operations on very small sets)
> - relay block (~2kB)
>
> The benefits of these changes only occur when the transactions have
> been seen in advance, but incentivizing ahead-of-block transaction
> propogation is a plus, as Jeff mentioned; working on a block without
> first ensuring peers have its transactions would be very expensive
> from a miner's point of view.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/