Justus Ranvier [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-04 📝 Original message:On 07/04/2015 10:35 AM, ...
📅 Original date posted:2015-07-04
📝 Original message: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 at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/fdca1cb1/attachment-0001.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/fdca1cb1/attachment-0001.sig>;
📝 Original message: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 at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/fdca1cb1/attachment-0001.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/fdca1cb1/attachment-0001.sig>;