From: Justus Ranvier <justus@openbitcoinprivacyproject•org>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Fork of invalid blocks due to BIP66 violations
Date: Sat, 04 Jul 2015 10:18:19 -0500 [thread overview]
Message-ID: <5597F93B.3000205@openbitcoinprivacyproject.org> (raw)
In-Reply-To: <20150704054453.GA348@savin.petertodd.org>
[-- Attachment #1.1: Type: text/plain, Size: 1621 bytes --]
On 07/04/2015 12:44 AM, Peter Todd wrote:
> Fact is, SPV means you're trusting other people to check the rules for
> you. In this particular case bitcoinj could have - and should have -
> checked the BIP66 soft-fork rules, but in general there's no easy
> solution to this problem.
In general, the situation can be improved if there existed proofs which
validating full nodes could broadcast which would tell SPV nodes why the
branch it sees with the most proof of work is actually invalid.
As far as I can tell, producing such proofs is reasonably
straightforward for all cases except the case where a block is invalid
because it contains a transaction which references a non-existent output.
The shortest proof that a particular transaction does not exist in the
blockchain is the entire blockchain.
If each transaction input identified the block containing the referenced
outpoint, then the proof of non-existence is either the block in
question, or the list of block headers (to show that the block doesn't
exist). That's a significant improvement in proof size over the entire
blockchain.
Proving the non-existence of a particular transaction in a specific
block could be made easier for future blocks by requiring transactions
to be ordered in the merkle tree by their hashes. Then it would just
require a few nodes in the tree to show that the transaction isn't in
the place where it should be.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus@openbitcoinprivacyproject•org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2015-07-04 15:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-04 5:43 Raystonn
2015-07-04 5:44 ` Peter Todd
2015-07-04 15:18 ` Justus Ranvier [this message]
2015-07-04 15:35 ` Tier Nolan
2015-07-04 16:01 ` Justus Ranvier
2015-07-04 17:58 ` Tier Nolan
2015-07-04 23:33 ` Justus Ranvier
2015-07-05 1:32 ` Tier Nolan
-- strict thread matches above, loose matches on Subject: below --
2015-07-04 5:46 Raystonn
2015-07-04 5:17 Raystonn
2015-07-04 5:22 ` Peter Todd
2015-07-04 5:40 ` odinn
2015-07-04 3:11 Raystonn
2015-07-04 3:17 ` Gregory Maxwell
2015-07-04 3:30 ` Peter Todd
2015-07-04 3:32 ` odinn
2015-07-04 10:04 ` Tier Nolan
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=5597F93B.3000205@openbitcoinprivacyproject.org \
--to=justus@openbitcoinprivacyproject$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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