public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jameson Lopp <jameson.lopp@gmail•com>
To: Hector Chu <hectorchu@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A solution to increase the incentive of running a node
Date: Wed, 19 Aug 2015 08:44:03 -0400	[thread overview]
Message-ID: <CADL_X_f5WZOQF==1LiBkX=kLO+9dGb1mxu__6Mu_b1WqR20hYA@mail.gmail.com> (raw)
In-Reply-To: <CAAO2FKHG1PHKjMw7ER=w-MgS7uNY_NLgzFM0aVKqP+BRUZOw9g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

On Wed, Aug 19, 2015 at 8:15 AM, Hector Chu <hectorchu@gmail•com> wrote:

> On 19 August 2015 at 13:08, Jameson Lopp <jameson.lopp@gmail•com> wrote:
> > If operating as an SPV node then it can check the transactions by
> querying
> > other nodes.
>
> SPV is for checking validity of transactions that have already entered
> the blockchain, as I understand it. My proposal requires nodes to
> validate transactions that are unconfirmed, and to commit to the
> validation by doing a POW on it.
>
> It's possible to check that a transaction is cryptographically valid
without having any blockchain data available; are you referring to a
different type of validation?

If you're running an SPV node that is listening to full nodes on the
network, you can request an unconfirmed transaction from connected peers
after receiving the inventory message they send - that's how unconfirmed
transactions propagate through the node network. This is not 100% proof
that the transaction is valid for inclusion in the blockchain, but it's a
very good indicator.

- Jameson


> > On an unrelated note, it sounds like your proposal will significantly
> > increase the data size of every transaction, which will create even more
> > contention for block space.
>
> If we stipulate that the coinbase fields only hold space for a single
> pubkey, then the entire block header including the two coinbases
> should only take an extra 100 bytes or so. Transactions are already
> routinely 250 bytes+. So an increase of roughly 33%.
>

[-- Attachment #2: Type: text/html, Size: 2180 bytes --]

  reply	other threads:[~2015-08-19 12:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-19 11:15 Hector Chu
2015-08-19 11:42 ` Jameson Lopp
2015-08-19 11:48   ` Hector Chu
2015-08-19 12:08     ` Jameson Lopp
2015-08-19 12:15       ` Hector Chu
2015-08-19 12:44         ` Jameson Lopp [this message]
2015-08-19 12:51           ` Hector Chu
2015-08-21 20:50   ` Tamas Blummer
2015-08-21 21:12     ` Sergio Demian Lerner

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='CADL_X_f5WZOQF==1LiBkX=kLO+9dGb1mxu__6Mu_b1WqR20hYA@mail.gmail.com' \
    --to=jameson.lopp@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=hectorchu@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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