path: root/d3/289981089d80e578d38b686979012e0f44ab1f

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1X8zBv-0006vv-Ez
	for bitcoin-development@lists.sourceforge.net;
	Sun, 20 Jul 2014 22:02:47 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.53 as permitted sender)
	client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f53.google.com; 
Received: from mail-oa0-f53.google.com ([209.85.219.53])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1X8zBt-0003eh-CU
	for bitcoin-development@lists.sourceforge.net;
	Sun, 20 Jul 2014 22:02:47 +0000
Received: by mail-oa0-f53.google.com with SMTP id j17so6136274oag.26
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 20 Jul 2014 15:02:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.133.69 with SMTP id pa5mr31680490obb.2.1405893759936;
	Sun, 20 Jul 2014 15:02:39 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Sun, 20 Jul 2014 15:02:39 -0700 (PDT)
In-Reply-To: <CA+iPb=GVyfYAjSRitt8LW-LLvi8U5F=noQ9igOQKmHyi8-DACA@mail.gmail.com>
References: <CA+iPb=GVyfYAjSRitt8LW-LLvi8U5F=noQ9igOQKmHyi8-DACA@mail.gmail.com>
Date: Mon, 21 Jul 2014 00:02:39 +0200
X-Google-Sender-Auth: xY0p5OO9T9N2xEWJ88OIVsUPFZo
Message-ID: <CANEZrP164g19q1_vGszcwesSS_xf836XO1SZ2+AOzjzAN-GC5Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Kaz Wesley <keziahw@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8ff1ce12272f6204fea72607
X-Spam-Score: -0.5 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1X8zBt-0003eh-CU
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Trickle and transaction propogation
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: Sun, 20 Jul 2014 22:02:47 -0000

--e89a8ff1ce12272f6204fea72607
Content-Type: text/plain; charset=UTF-8

No comment on the proposal itself, which sounds reasonable but I didn't
think about it much yet. Instead, just an observation that by now most
users are not using the Core wallet anymore, but rather use either SPV
wallets or more centralised blockchain/coinbase style gateways to the
network.

SPV wallets don't relay thus you know any tx sent from them must be
originated by that wallet. Centralised services accept tx submissions via
SSL and can easily improve their users privacy by sending transactions out
via a node that isn't listening.

So IMHO we should be optimising the network for the common use case rather
than stuff that only helps Core wallet users, and actively slows down
everyone else. If your proposed techniques let us have our cake and eat it,
fantastic, otherwise I still think we should remove tx trickling.



On Sun, Jul 20, 2014 at 11:01 PM, Kaz Wesley <keziahw@gmail.com> wrote:

> The inv trickling mechanism currently serves two purposes:
> - protect casual users' privacy by slightly obscuring a tx's originating
> node
> - reduce invs unnecessarily sent both directions for a connection
> It has some drawbacks:
> - it slows transaction propagation
> - it delays knowledge between two nodes of what txes are mutually known
> These drawbacks will be especially costly once optimizations based on
> mutually-known transactions are available (in progress, see "sparse
> blocks" thread).
>
> Both of the benefits of trickling can be achieved more efficiently and
> without the costs to transaction propagation and mutual transaction
> knowledge.
>
> Privacy: trickling helps hide the origin of 3/4 of the transactions a
> node is pushing by preventing most of the node's neighbors from seeing
> the transactions from that node right away; by the time a peer becomes
> the trickle node, it may have received the same inv from another of
> its peers.
> This staggering of introduction of new invs to the network could be
> made more effective by scheduling staggered pushes of wallet
> transactions to each peer in a structure similar to mapAskFor.
> This does have the drawback that someone who has established multiple
> connections to a node can observe that some invs are pushed at
> different times, suggesting they are in the stagger set. I don't see
> any straightforward way to remedy this, but trickling is also
> vulnerable to sybil attacks, and floods 1/4 of its transactions
> immediately anyway -- so I think staggered push would be an overall
> privacy improvement.
> Likelihood of a partial sybil obtaining inv origin information could
> be reduced by a policy of ending staggering and pushing to all peers
> once another peer has received the tx from elsewhere and inved the
> transaction back to the original node; if the staggering is
> sufficiently slow, only one or two nodes would receive the initial
> push to the network and after that the inv would be treated
> indistinguishably from if it originated externally.
>
> Redundant invs: without trickling, when two nodes receive transactions
> at around the same time they may each send each other an inv before
> receiving the other's. Trickling reduces this by giving all
> non-trickleSend nodes a chance to send first. Thus just eliminating
> trickling would at most double inv traffic. Although invs are small
> they are numerous, being the only common message potentially sent from
> every node to all its neighbors.
> A more efficient solution to the who-sends-first problem would be for
> connections to have directional parity:
> - a node initiating a connection would announce its parity (even or odd)
> - an inv is sent right away to peers with matching parity, but only
> sent against parity if a certain timeout has elapsed without the inv
> being received
> In order to allow for nodes with few peers (i.e. -connect) or nodes on
> local connections that might as well flood everything to each other,
> parity could be specified as a mask (fEven << 1 & fOdd). Peers from
> pre-directional-parity versions can be treated as having the mask
> fully set.
>
> Both push staggering and directional parity admit simple
> implementations. The specific staggering delay distribution would need
> some thought; it could be set slower than the typical trickle cycle
> period for better than current privacy, since general transaction
> propagation would not impeded by heavy staggering. What do you think
> of this approach? Any gotchas/improvements/alternatives?
>
>
> ------------------------------------------------------------------------------
> 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
>

--e89a8ff1ce12272f6204fea72607
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">No comment on the proposal itself, which sounds reasonable=
 but I didn&#39;t think about it much yet. Instead, just an observation tha=
t by now most users are not using the Core wallet anymore, but rather use e=
ither SPV wallets or more centralised blockchain/coinbase style gateways to=
 the network.<div>
<br></div><div>SPV wallets don&#39;t relay thus you know any tx sent from t=
hem must be originated by that wallet. Centralised services accept tx submi=
ssions via SSL and can easily improve their users privacy by sending transa=
ctions out via a node that isn&#39;t listening.</div>
<div><br></div><div>So IMHO we should be optimising the network for the com=
mon use case rather than stuff that only helps Core wallet users, and activ=
ely slows down everyone else. If your proposed techniques let us have our c=
ake and eat it, fantastic, otherwise I still think we should remove tx tric=
kling.</div>
<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, Jul 20, 2014 at 11:01 PM, Kaz Wesley <span dir=3D"ltr">&lt;=
<a href=3D"mailto:keziahw@gmail.com" target=3D"_blank">keziahw@gmail.com</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">The inv trickling mechanism currently serves=
 two purposes:<br>
- protect casual users&#39; privacy by slightly obscuring a tx&#39;s origin=
ating node<br>
- reduce invs unnecessarily sent both directions for a connection<br>
It has some drawbacks:<br>
- it slows transaction propagation<br>
- it delays knowledge between two nodes of what txes are mutually known<br>
These drawbacks will be especially costly once optimizations based on<br>
mutually-known transactions are available (in progress, see &quot;sparse<br=
>
blocks&quot; thread).<br>
<br>
Both of the benefits of trickling can be achieved more efficiently and<br>
without the costs to transaction propagation and mutual transaction<br>
knowledge.<br>
<br>
Privacy: trickling helps hide the origin of 3/4 of the transactions a<br>
node is pushing by preventing most of the node&#39;s neighbors from seeing<=
br>
the transactions from that node right away; by the time a peer becomes<br>
the trickle node, it may have received the same inv from another of<br>
its peers.<br>
This staggering of introduction of new invs to the network could be<br>
made more effective by scheduling staggered pushes of wallet<br>
transactions to each peer in a structure similar to mapAskFor.<br>
This does have the drawback that someone who has established multiple<br>
connections to a node can observe that some invs are pushed at<br>
different times, suggesting they are in the stagger set. I don&#39;t see<br=
>
any straightforward way to remedy this, but trickling is also<br>
vulnerable to sybil attacks, and floods 1/4 of its transactions<br>
immediately anyway -- so I think staggered push would be an overall<br>
privacy improvement.<br>
Likelihood of a partial sybil obtaining inv origin information could<br>
be reduced by a policy of ending staggering and pushing to all peers<br>
once another peer has received the tx from elsewhere and inved the<br>
transaction back to the original node; if the staggering is<br>
sufficiently slow, only one or two nodes would receive the initial<br>
push to the network and after that the inv would be treated<br>
indistinguishably from if it originated externally.<br>
<br>
Redundant invs: without trickling, when two nodes receive transactions<br>
at around the same time they may each send each other an inv before<br>
receiving the other&#39;s. Trickling reduces this by giving all<br>
non-trickleSend nodes a chance to send first. Thus just eliminating<br>
trickling would at most double inv traffic. Although invs are small<br>
they are numerous, being the only common message potentially sent from<br>
every node to all its neighbors.<br>
A more efficient solution to the who-sends-first problem would be for<br>
connections to have directional parity:<br>
- a node initiating a connection would announce its parity (even or odd)<br=
>
- an inv is sent right away to peers with matching parity, but only<br>
sent against parity if a certain timeout has elapsed without the inv<br>
being received<br>
In order to allow for nodes with few peers (i.e. -connect) or nodes on<br>
local connections that might as well flood everything to each other,<br>
parity could be specified as a mask (fEven &lt;&lt; 1 &amp; fOdd). Peers fr=
om<br>
pre-directional-parity versions can be treated as having the mask<br>
fully set.<br>
<br>
Both push staggering and directional parity admit simple<br>
implementations. The specific staggering delay distribution would need<br>
some thought; it could be set slower than the typical trickle cycle<br>
period for better than current privacy, since general transaction<br>
propagation would not impeded by heavy staggering. What do you think<br>
of this approach? Any gotchas/improvements/alternatives?<br>
<br>
---------------------------------------------------------------------------=
---<br>
Want fast and easy access to all the code in your enterprise? Index and<br>
search up to 200,000 lines of code with a free copy of Black Duck<br>
Code Sight - the same software that powers the world&#39;s largest code<br>
search on Ohloh, the Black Duck Open Hub! Try it now.<br>
<a href=3D"http://p.sf.net/sfu/bds" target=3D"_blank">http://p.sf.net/sfu/b=
ds</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>

--e89a8ff1ce12272f6204fea72607--