public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Date: Thu, 22 Dec 2011 14:46:54 +0000	[thread overview]
Message-ID: <201112221446.54526.andyparkins@gmail.com> (raw)
In-Reply-To: <1324556083.30850.13.camel@mei>

[-- Attachment #1: Type: Text/Plain, Size: 2141 bytes --]

On 2011 December 22 Thursday, Joel Joonatan Kaartinen wrote:
> On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins wrote:
> > Why should they have to?  Joining the network as a node is very low cost
> > to the other nodes.  You can't force any node not to be lazy, since
> > their option is to disconnect themselves.  As to maliciousness, that is
> > defended against because when a node negative announces a transaction,
> > that transaction is going to be checked (note that there is still no
> > implicit trust) -- if a node is incorrectly negative-announcing then it
> > can justifiably be kicked.
> 
> a node that is not doing any checking themselves can not reliably
> forward failed verifications without getting the blame for doing faulty
> work. Those nodes would then have the incentive not to relay the failed
> verifications. This ends up making it important to know which nodes will
> be checking transactions or not so you don't isolate yourself from other
> nodes that are also checking transactions.

Yes; I appreciate that.  It's the very point I'm making.  A node can choose 
what work to do, and should have a way of forwarding the results of that work 
to other nodes.  Transaction verifification is the main one.

Once a negative-announce message exists, it wouldn't be hard to have the other 
two you need as well: positive-announce and neutral-announce.  At present we 
have only neutral-announce.  However, as the need for super nodes and 
distributed verification gets bigger, having the forwarder able to offer an 
opinion on the quality of a transaction seems ideal to me.  Dishonesty will 
get you isolated pretty quickly if you use positive-announce and negative-
announce to lie.

The problem with this is that it requires a web of trust as well as a web of 
connections.  The only way to gain an advantage from this classified 
forwarding is if you have some way of assigning enough trust so that you can 
forward a classified transaction _without_ checking it yourself.  That doesn't 
sound like an easy problem though.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  parent reply	other threads:[~2011-12-22 14:47 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
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 [this message]
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=201112221446.54526.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=joel.kaartinen@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