From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RdLUl-0001Cy-NN for bitcoin-development@lists.sourceforge.net; Wed, 21 Dec 2011 12:42:07 +0000 X-ACL-Warn: Received: from backup-server.nordu.net ([193.10.252.66]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1RdLUh-0001kd-2V for bitcoin-development@lists.sourceforge.net; Wed, 21 Dec 2011 12:42:07 +0000 Received: from [109.105.106.215] ([109.105.106.215]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBLCfq47013690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Dec 2011 13:41:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_Gr=F8nager?= In-Reply-To: Date: Wed, 21 Dec 2011 13:41:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com> References: <82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com> <4EEE58CA.5090902@justmoon.de> <67FAA76C-1734-471D-A3D8-31E5216DD512@ceptacle.com> To: Eric Lombrozo X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1RdLUh-0001kd-2V Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Protocol extensions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 12:42:07 -0000 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 payed 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 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 that 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 of 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. >=20 > 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. >=20 > 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? >=20 > = --------------------------------------------------------------------------= ---- > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. = Create=20 > new or port existing apps to sell to consumers worldwide. Explore the=20= > 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