public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Michael Grønager" <gronager@ceptacle.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Protocol extensions
Date: Wed, 21 Dec 2011 13:41:51 +0100	[thread overview]
Message-ID: <028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com> (raw)
In-Reply-To: <CABr1YTdUQeAuw2vwZS=VvDU1dTrN+eqjHRXMsZp2axcxbTsO8A@mail.gmail.com>

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.
> 
> 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. 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







  reply	other threads:[~2011-12-21 12:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-17  7:41 [Bitcoin-development] Protocol extensions Eric Lombrozo
2011-12-17 13:13 ` Michael Grønager
2011-12-17 13:37   ` Christian Decker
     [not found]     ` <CABsx9T0puk3CWH1cfNHMSVEoCPaLJJWNJ+H5ObCERZrzMbrTyA@mail.gmail.com>
2011-12-17 19:06       ` Gavin Andresen
2011-12-17 21:49         ` theymos
2011-12-18  0:44           ` Jordan Mack
2011-12-18  1:07             ` Jeff Garzik
2011-12-18  1:27           ` Jordan Mack
2011-12-18 14:16             ` Andy Parkins
2011-12-18 17:09             ` theymos
2011-12-18 18:06               ` Alan Reiner
2011-12-18 18:47                 ` Amir Taaki
2011-12-18 19:37               ` Jorge Timón
2011-12-17 19:28     ` Gregory Maxwell
2011-12-17 20:34       ` Christian Decker
2011-12-18 21:19     ` Stefan Thomas
2011-12-19 21:43       ` Jordan Mack
2011-12-20  9:10         ` Wladimir
2011-12-20 10:44           ` Nicolas Fischer
2011-12-21  0:47         ` Kyle Henderson
2011-12-21  8:50       ` Michael Grønager
2011-12-21 11:42         ` Eric Lombrozo
2011-12-21 12:41           ` Michael Grønager [this message]
2011-12-21 16:10             ` Christian Decker
2011-12-22  9:18               ` Michael Grønager
2011-12-22 10:12               ` Andy Parkins
2011-12-22 10:27                 ` Michael Grønager
2011-12-22 11:52                   ` Andy Parkins
2011-12-22 12:14                     ` Joel Joonatan Kaartinen
2011-12-22 12:26                       ` Christian Decker
2011-12-22 12:42                       ` Michael Grønager
2011-12-22 14:46                       ` Andy Parkins
2011-12-25  2:55                         ` Zell Faze
2011-12-21 17:17         ` Jordan Mack
2011-12-22  9:19           ` Michael Grønager
2011-12-21  6:19 Eric Lombrozo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com \
    --to=gronager@ceptacle.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=elombrozo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox