From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rdenu-00030L-RI for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 09:19:10 +0000 X-ACL-Warn: Received: from backup-server.nordu.net ([193.10.252.66]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Rdeno-0000n4-Et for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 09:19:10 +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 pBM9IrIY020551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Dec 2011 10:18:54 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_Gr=F8nager?= In-Reply-To: Date: Thu, 22 Dec 2011 10:18:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <84C7327F-4149-4F69-8D7A-F5B3BBE96FA4@ceptacle.com> References: <82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com> <4EEE58CA.5090902@justmoon.de> <67FAA76C-1734-471D-A3D8-31E5216DD512@ceptacle.com> <028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com> To: Christian Decker 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: 1Rdeno-0000n4-Et 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: Thu, 22 Dec 2011 09:19:10 -0000 >=20 > 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. Agree, that is why we need to keep the different A.B segment requirement = as is also imposed in the client today. >=20 > 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. I agree that in practice the thinner nodes would most likely just serve = as cache, but they need notification on tx'es involving some of their tx = outs or involving some of theirs bitcoin addresses. Today there are some = designs that operate with a thin client that connects to a (web)server = and subscribe to listen for transactions involving a specific bitcoin = address. By letting that be a part of the hash space including that = address you would not reveal your address to the server and we would = keep a true p2p setup. Best regards, Michael >=20 > Regards, > Chris >=20 > On Wed, Dec 21, 2011 at 1:41 PM, Michael Gr=F8nager = 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. >=20 > 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. >=20 > 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. >=20 > 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). >=20 > Cheers, >=20 > M >=20 >=20 >=20 > On 21/12/2011, at 12:42, Eric Lombrozo wrote: >=20 >> 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 >> 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 >=20 >=20 >=20 >=20 >=20 > = --------------------------------------------------------------------------= ---- > 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 >=20