š
Original date posted:2017-02-24
š Original message:On Thu, Feb 23, 2017 at 06:50:10PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 5:09 PM, Peter Todd <pete at petertodd.org> wrote:
>
> > I think you've misunderstood what TXO commitments are. From my article:
> >
> > "A merkle tree committing to the state of all transaction outputs, both
> > spent
> > and unspent, can provide a method of compactly proving the current state
> > of an
> > output."
> > -https://petertodd.org/2016/delayed-txo-commitments#txo-commitments:
> >
>
> The proposal on that page is of a tree which does require random access
> updates, it just positions entries in the order they happened to be added
> instead of sorting by their hash. Once you start updating it to indicate
> spent status all the exact same issues of TXO size and cache coherence on
> updates show up again, but now you're using a more complex bespoke data
> structure instead of a basic fundamental one.
Sorry, but I was replying to your statement:
> What you can't do with MMRs or the blockchain is make a compact proof that
> something is still in the utxo set, which is the whole point of utxo
> commitments.
So to be clear, do you agree or disagree with me that you *can* extract a
compact proof from a MMR that a given output is unspent?
I just want to make sure we're on the same page here before we discuss
performance characteristics.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170223/5d17c853/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 17:56:33
in reply to nevent1qā¦08j6
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 17:56:33Event JSON
{
"id": "3a68b69aeee69cced2b09b3c45a87d51f59272410ce918f1ffa2c88674940f66",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686160593,
"kind": 1,
"tags": [
[
"e",
"7c1fe6216790fb2846f605436edee6db0e33feb9c670df2e38b3b46417cf9504",
"",
"root"
],
[
"e",
"c991691163a4fc8c1a719b1acc9a25f3c7129edc4280892eccc91806a594e91d",
"",
"reply"
],
[
"p",
"fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9"
]
],
"content": "š
Original date posted:2017-02-24\nš Original message:On Thu, Feb 23, 2017 at 06:50:10PM -0800, Bram Cohen wrote:\n\u003e On Thu, Feb 23, 2017 at 5:09 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \n\u003e \u003e I think you've misunderstood what TXO commitments are. From my article:\n\u003e \u003e\n\u003e \u003e \"A merkle tree committing to the state of all transaction outputs, both\n\u003e \u003e spent\n\u003e \u003e and unspent, can provide a method of compactly proving the current state\n\u003e \u003e of an\n\u003e \u003e output.\"\n\u003e \u003e -https://petertodd.org/2016/delayed-txo-commitments#txo-commitments:\n\u003e \u003e\n\u003e \n\u003e The proposal on that page is of a tree which does require random access\n\u003e updates, it just positions entries in the order they happened to be added\n\u003e instead of sorting by their hash. Once you start updating it to indicate\n\u003e spent status all the exact same issues of TXO size and cache coherence on\n\u003e updates show up again, but now you're using a more complex bespoke data\n\u003e structure instead of a basic fundamental one.\n\nSorry, but I was replying to your statement:\n\n\u003e What you can't do with MMRs or the blockchain is make a compact proof that\n\u003e something is still in the utxo set, which is the whole point of utxo\n\u003e commitments.\n\nSo to be clear, do you agree or disagree with me that you *can* extract a\ncompact proof from a MMR that a given output is unspent?\n\nI just want to make sure we're on the same page here before we discuss\nperformance characteristics.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170223/5d17c853/attachment.sig\u003e",
"sig": "0620578691d6fe9f31160194641fcd19ab15c01b0101653e6e0678591e53c081d8aa4972a036729f2dc29473ae51d66002c3cfd5d14fc7463cf58d49a10d819f"
}