From: Tier Nolan <tier.nolan@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Fork of invalid blocks due to BIP66 violations
Date: Sat, 4 Jul 2015 16:35:49 +0100 [thread overview]
Message-ID: <CAE-z3OWTzgYP7CKbFLf-YFKU+G6CNKND2DmAbnr_3_NjB-Y4fw@mail.gmail.com> (raw)
In-Reply-To: <5597F93B.3000205@openbitcoinprivacyproject.org>
[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]
On Sat, Jul 4, 2015 at 4:18 PM, Justus Ranvier <
justus@openbitcoinprivacyproject•org> wrote:
> 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.
>
Yeah, fraud proofs have been suggested lots of times in the past.
In this case, they weren't even needed. Fully updated SPV clients should
also have rejected the invalid fork. All the information required to
reject it was in the header chain.
The problem wasn't SPV miners, it was SPV-miners where the SPV part wasn't
upgraded to handle v3 blocks.
> 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.
>
Even that can be handled with UTXO set commitments. If the UTXO tree is
sorted you can prove that an entry doesn't exist.
What cannot be handled is proving that a block is invalid if the
transaction data for the block is withheld.
> 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.
>
That is reasonable. Unconfirmed transactions can't include that info
though.
It could be committed in as an extra commitment.
One issue is that you need to prove of of these commitments too.
A transaction which points to the wrong block would also be provable in the
same way.
> 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.
>
You could just have an extra merkle tree.
You would only need to include the block hashes for all transactions to
show that the two trees don't match. That is 32 bytes per transaction
rather than the full 200-500 bytes per transaction.
[-- Attachment #2: Type: text/html, Size: 3291 bytes --]
next prev parent reply other threads:[~2015-07-04 15:35 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
2015-07-04 15:35 ` Tier Nolan [this message]
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=CAE-z3OWTzgYP7CKbFLf-YFKU+G6CNKND2DmAbnr_3_NjB-Y4fw@mail.gmail.com \
--to=tier.nolan@gmail$(echo .)com \
--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