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 11:01:37 -0500 [thread overview]
Message-ID: <55980361.9040707@openbitcoinprivacyproject.org> (raw)
In-Reply-To: <CAE-z3OWTzgYP7CKbFLf-YFKU+G6CNKND2DmAbnr_3_NjB-Y4fw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1683 bytes --]
On 07/04/2015 10:35 AM, Tier Nolan wrote:
> Even that can be handled with UTXO set commitments. If the UTXO tree is
> sorted you can prove that an entry doesn't exist.
How do we know if a committed UTXO set is valid? If a majority of the
hashing power is willing to extend an invalid branch, it's reasonable to
assume they'd be willing to commit an invalid UTXO set as well.
In order for the committed UTXO set to be reliable at a minimum it will
need to contain at a source block reference for each item in the set.
That would enable fraud proof to show that the committed UTXO set
contains invalid entries.
>> 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.
I agree the information should be an extra commitment produced by the
miner, rather than changing the format of the transaction, since the
author of a transaction can't always know the required information ahead
of time.
> One issue is that you need to prove of of these commitments too.
If items in the the proof tree are required to be sorted, then it's easy
to proof that an item is missing.
--
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 16:08 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
2015-07-04 16:01 ` Justus Ranvier [this message]
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=55980361.9040707@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