References: <CA+8xBpecVQcTTbPxUm_3_GWC99dEd4=-VFWb+QT6jUy4rg8U4w@mail.gmail.com>
	<CANEZrP0kNZDByHpK2=UjP+ag0X1KmqHxnJdm=e_pWMitP4QvvA@mail.gmail.com>
	<CA+8xBpcwhQPQRe=stYb9xksLsTbiABKLS7PZnRtvPga6AmSg4Q@mail.gmail.com>
	<CANEZrP39RHfCDX-x4ARo+oPphLv-70RxuMh3+AJzsNPxzOd=bA@mail.gmail.com>
Message-ID: <1339785752.91313.YahooMailNeo@web121004.mail.ne1.yahoo.com>
Date: Fri, 15 Jun 2012 11:42:32 -0700 (PDT)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CANEZrP39RHfCDX-x4ARo+oPphLv-70RxuMh3+AJzsNPxzOd=bA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] New P2P commands for diagnostics,
	SPV clients
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>

Why though? The bottleneck is not network traffic but disk space usage/bloc=
kchain validation time.=0A=0A=0A=0A----- Original Message -----=0AFrom: Mik=
e Hearn <mike@plan99.net>=0ATo: Jeff Garzik <jgarzik@exmulti.com>=0ACc: Bit=
coin Development <bitcoin-development@lists.sourceforge.net>=0ASent: Friday=
, June 15, 2012 3:43 PM=0ASubject: Re: [Bitcoin-development] New P2P comman=
ds for diagnostics, SPV clients=0A=0A> Yes, the format is something that mu=
st be hashed out (no pun=0A> intended). =A0Need input from potential users =
about what information=0A> they might need.=0A=0AMatts point that a branch-=
per-transaction may duplicate data is well=0Amade, that said, I suspect a f=
ormat that tries to fix this would be=0Amuch more complicated.=0A=0AHow abo=
ut see this project as a three part change?=0A=0AFirst step - add the mempo=
ol command and make nodes sync up their=0Amempools on startup.=0A=0ASecond =
step - if protocol version >=3D X, the "block" message consists=0Aof a head=
er + num transactions + vector<hash>=A0 instead of the full=0Atransactions =
themselves.=0A=0AOn receiving such a block, we go look to see which transac=
tions we're=0Amissing from the mempool and request them with getdata. Each =
time we=0Areceive a tx message we check to see if it was one we were missin=
g=0Afrom a block. Once all transactions in the block message are in=0Amemor=
y, we go ahead and assemble the block, then verify as per normal.=0AThis sh=
ould speed up block propagation. Miners have an incentive to=0Aupgrade beca=
use it should reduce wasted work.=0A=0AThird step - new message, getmerklet=
x takes a vector<hash> and returns=0Aa merkletx message: "merkle branch mis=
sing the root + transaction data=0Aitself" for each requested transaction. =
The filtering commands are=0Aadded, so the block message now only lists tra=
nsaction hashes that=0Amatch the filter which can then be requested with ge=
tmerkletx.=0A=0A-----------------------------------------------------------=
-------------------=0ALive Security Virtual Conference=0AExclusive live eve=
nt will cover all the ways today's security and =0Athreat landscape has cha=
nged and how IT managers can respond. Discussions =0Awill include endpoint =
security, mobile security and the latest in malware =0Athreats. http://www.=
accelacomm.com/jaw/sfrnl04242012/114/50122263/=0A__________________________=
_____________________=0ABitcoin-development mailing list=0ABitcoin-developm=
ent@lists.sourceforge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/bi=
tcoin-development=0A