path: root/64/57abaf5e196efab3c9eb6364dc119803e0133f

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <decker.christian@gmail.com>) id 1RdOlR-0000UF-Tc
	for bitcoin-development@lists.sourceforge.net;
	Wed, 21 Dec 2011 16:11:33 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.175 as permitted sender)
	client-ip=209.85.212.175;
	envelope-from=decker.christian@gmail.com;
	helo=mail-wi0-f175.google.com; 
Received: from mail-wi0-f175.google.com ([209.85.212.175])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RdOlQ-0001fU-D9
	for bitcoin-development@lists.sourceforge.net;
	Wed, 21 Dec 2011 16:11:33 +0000
Received: by wibhq7 with SMTP id hq7so2986239wib.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 21 Dec 2011 08:11:26 -0800 (PST)
Received: by 10.180.83.69 with SMTP id o5mr15664407wiy.1.1324483886187; Wed,
	21 Dec 2011 08:11:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.159.201 with HTTP; Wed, 21 Dec 2011 08:10:45 -0800 (PST)
In-Reply-To: <028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com>
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
	<82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com>
	<CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com>
	<4EEE58CA.5090902@justmoon.de>
	<67FAA76C-1734-471D-A3D8-31E5216DD512@ceptacle.com>
	<CABr1YTdUQeAuw2vwZS=VvDU1dTrN+eqjHRXMsZp2axcxbTsO8A@mail.gmail.com>
	<028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 21 Dec 2011 17:10:45 +0100
Message-ID: <CALxbBHW4v2FohtaFi0MRey5RoBQodEK5kPsGCAv5xVmmDOOjZQ@mail.gmail.com>
To: =?ISO-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
Content-Type: multipart/alternative; boundary=f46d044288908c062c04b49c6fbc
X-Spam-Score: -0.6 (/)
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
	(decker.christian[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	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: 1RdOlQ-0001fU-D9
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Protocol extensions
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: Wed, 21 Dec 2011 16:11:34 -0000

--f46d044288908c062c04b49c6fbc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

For the future evolution without considering DHTs:
While I think we will sooner or later have supernodes, I don't think they
will need to be trusted too much.
Supernodes will be those nodes that verify all transactions and make them
available to miners. Since miners will become more and more specialized
these supernodes are likely to be owned by the miners themself. To be a
miner either you need to verify all the transactions you include (otherwise
others might be able to find an error in your block and thus drop it) or
have someone that verifies them for you. In the end I think we'll end up
with a hierarchical network, with the miners/supernodes tighly
interconnected at the top and the lightweight clients that simply verify
transactions (or their inputs to be precise) that are destined for them at
the bottom.

As for the DHT we had a few brainstorming sessions a while back on the
forum http://bit.ly/sc2RLZ (gmaxwell didn't like it then either :D)
Forcing someone to participate in a fixed position in the block storage
network is a good way to reduce the risk of a sybil attack as Michael said.
The hash should include only information that cannot be changed by the
user, so IP can be used, but including the port is risky.

Broadcasting the transactions would not need to be done, since miners fetch
them from their storage place, alternatively we could use the inv broadcast
to notify peers about a new block/transaction and let it retrieve them from
the permanent storage (DHT or block storage network). If we route traffic
internally in the DHT we could even start caching at nodes leading to the
real location, since announcements would lead to flashcrowds, putting heavy
load on the responsible nodes. Caching is not a risk since the hash of the
object to be retrieved is already known.

Regards,
Chris

On Wed, Dec 21, 2011 at 1:41 PM, Michael Gr=F8nager <gronager@ceptacle.com>=
wrote:

> I find it likely that we will at some point have supernodes. If we have
> browser based wallets then the server for these automatically becomes
> supernodes. Further, if we move along that direction, it becomes much
> simpler to use both the scheme I proposed or to use a a lot of other
> schemes for sharing the validation work on a farm constituting the
> supernode.
>
> However, if we want to keep bitcoin in a real p2p setup and enable
> scalability in terms of ensuring both thin and fat client to connect then
> we need to go along the path I propose.
>
> Actually, after thinking a bit more about the possible new attack vector =
I
> don't find it that alarming - if you still require 7 confirmations of any
> bigger transaction before you, as receiver accepts the transaction as pay=
ed
> you will not risk anything. The question is then if it is sufficiently ea=
sy
> to fake small transaction to e.g. gain access to micropayment based web
> services. I would again say no - the requirement that you have ok from e.=
g.
> 8 different A.B nodes will make it extremely difficult to cheat, and that
> would even require you to gain some level of control over the network tha=
t
> the service you want to cheat is connected through.
>
> This means that you should not divide the hash space more finely than you
> would at all times be able to find 8 different A.B nodes. As the number o=
f
> clients grows you can then divide the hash space further. (with 100000
> nodes today and a division into 512 parts you would have approx 200 nodes
> to choose from).
>
> Cheers,
>
> M
>
>
>
> On 21/12/2011, at 12:42, Eric Lombrozo wrote:
>
> > Is it just me or does it seem inevitable that at some point supernodes
> > will emerge that other nodes trust to validate transactions for them?
> > Supernodes needn't even store the entire block chain and transaction
> > pool...it would be sufficient that they keep lists of IP addresses of
> > other trustworthy nodes and partition them into a hashspace.
> >
> > Anonymous peers have no reputation to defend...but a trusted supernode
> > would, which could provide just enough incentive for the supernode to
> > do its best to ensure the nodes it vouches for are indeed legit. Of
> > course, unless the supernode is validating the entire block chain and
> > transaction pool itself, it could only assess the trustworthiness of
> > other nodes by performing random sampling.
> >
> > Michael, I really like your ideas and the clarity you bring to the
> > issue. Regarding the potential attack vector you mention, would it be
> > possible to partition the hashspace to minimize the risk that an
> > attacker can manage to disproportionately gain control over a part of
> > the hashspace?
> >
> >
> -------------------------------------------------------------------------=
-----
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Creat=
e
> > new or port existing apps to sell to consumers worldwide. Explore the
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/joi=
n
> > http://p.sf.net/sfu/intel-appdev
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
>
> -------------------------------------------------------------------------=
-----
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--f46d044288908c062c04b49c6fbc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

For the future evolution without considering DHTs:<br>While I think we will=
 sooner or later have supernodes, I don&#39;t think they will need to be tr=
usted too much.<br>Supernodes will be those nodes that verify all transacti=
ons and make them available to miners. Since miners will become more and mo=
re specialized these supernodes are likely to be owned by the miners themse=
lf. To be a miner either you need to verify all the transactions you includ=
e (otherwise others might be able to find an error in your block and thus d=
rop it) or have someone that verifies them for you. In the end I think we&#=
39;ll end up with a hierarchical network, with the miners/supernodes tighly=
 interconnected at the top and the lightweight clients that simply verify t=
ransactions (or their inputs to be precise) that are destined for them at t=
he bottom.<br>

<br>As for the DHT we had a few brainstorming sessions a while back on the =
forum <a href=3D"http://bit.ly/sc2RLZ">http://bit.ly/sc2RLZ</a> (gmaxwell d=
idn&#39;t like it then either :D)<br>Forcing someone to participate in a fi=
xed position in the block storage network is a good way to reduce the risk =
of a sybil attack as Michael said. The hash should include only information=
 that cannot be changed by the user, so IP can be used, but including the p=
ort is risky.<br>

<br>Broadcasting the transactions would not need to be done, since miners f=
etch them from their storage place, alternatively we could use the inv broa=
dcast to notify peers about a new block/transaction and let it retrieve the=
m from the permanent storage (DHT or block storage network). If we route tr=
affic internally in the DHT we could even start caching at nodes leading to=
 the real location, since announcements would lead to flashcrowds, putting =
heavy load on the responsible nodes. Caching is not a risk since the hash o=
f the object to be retrieved is already known.<br>

<br>Regards,<br>Chris<br><br><div class=3D"gmail_quote">On Wed, Dec 21, 201=
1 at 1:41 PM, Michael Gr=F8nager <span dir=3D"ltr">&lt;<a href=3D"mailto:gr=
onager@ceptacle.com">gronager@ceptacle.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">

I find it likely that we will at some point have supernodes. If we have bro=
wser based wallets then the server for these automatically becomes supernod=
es. Further, if we move along that direction, it becomes much simpler to us=
e both the scheme I proposed or to use a a lot of other schemes for sharing=
 the validation work on a farm constituting the supernode.<br>


<br>
However, if we want to keep bitcoin in a real p2p setup and enable scalabil=
ity in terms of ensuring both thin and fat client to connect then we need t=
o go along the path I propose.<br>
<br>
Actually, after thinking a bit more about the possible new attack vector I =
don&#39;t find it that alarming - if you still require 7 confirmations of a=
ny bigger transaction before you, as receiver accepts the transaction as pa=
yed you will not risk anything. The question is then if it is sufficiently =
easy to fake small transaction to e.g. gain access to micropayment based we=
b services. I would again say no - the requirement that you have ok from e.=
g. 8 different A.B nodes will make it extremely difficult to cheat, and tha=
t would even require you to gain some level of control over the network tha=
t the service you want to cheat is connected through.<br>


<br>
This means that you should not divide the hash space more finely than you w=
ould at all times be able to find 8 different A.B nodes. As the number of c=
lients grows you can then divide the hash space further. (with 100000 nodes=
 today and a division into 512 parts you would have approx 200 nodes to cho=
ose from).<br>


<br>
Cheers,<br>
<br>
M<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
On 21/12/2011, at 12:42, Eric Lombrozo wrote:<br>
<br>
&gt; Is it just me or does it seem inevitable that at some point supernodes=
<br>
&gt; will emerge that other nodes trust to validate transactions for them?<=
br>
&gt; Supernodes needn&#39;t even store the entire block chain and transacti=
on<br>
&gt; pool...it would be sufficient that they keep lists of IP addresses of<=
br>
&gt; other trustworthy nodes and partition them into a hashspace.<br>
&gt;<br>
&gt; Anonymous peers have no reputation to defend...but a trusted supernode=
<br>
&gt; would, which could provide just enough incentive for the supernode to<=
br>
&gt; do its best to ensure the nodes it vouches for are indeed legit. Of<br=
>
&gt; course, unless the supernode is validating the entire block chain and<=
br>
&gt; transaction pool itself, it could only assess the trustworthiness of<b=
r>
&gt; other nodes by performing random sampling.<br>
&gt;<br>
&gt; Michael, I really like your ideas and the clarity you bring to the<br>
&gt; issue. Regarding the potential attack vector you mention, would it be<=
br>
&gt; possible to partition the hashspace to minimize the risk that an<br>
&gt; attacker can manage to disproportionately gain control over a part of<=
br>
&gt; the hashspace?<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt; Write once. Port to many.<br>
&gt; Get the SDK and tools to simplify cross-platform app development. Crea=
te<br>
&gt; new or port existing apps to sell to consumers worldwide. Explore the<=
br>
&gt; Intel AppUpSM program developer opportunity. <a href=3D"http://appdeve=
loper.intel.com/join" target=3D"_blank">appdeveloper.intel.com/join</a><br>
&gt; <a href=3D"http://p.sf.net/sfu/intel-appdev" target=3D"_blank">http://=
p.sf.net/sfu/intel-appdev</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
<br>
<br>
<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
Write once. Port to many.<br>
Get the SDK and tools to simplify cross-platform app development. Create<br=
>
new or port existing apps to sell to consumers worldwide. Explore the<br>
Intel AppUpSM program developer opportunity. <a href=3D"http://appdeveloper=
.intel.com/join" target=3D"_blank">appdeveloper.intel.com/join</a><br>
<a href=3D"http://p.sf.net/sfu/intel-appdev" target=3D"_blank">http://p.sf.=
net/sfu/intel-appdev</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>
</div></div></blockquote></div><br>

--f46d044288908c062c04b49c6fbc--