📅 Original date posted:2017-02-23
📝 Original message:On Thu, Feb 23, 2017 at 9:53 AM, Chris Priest via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> What problem does this try to solve, and what does it have to do with
> bitcoin?
>
I can't speak to MMRs (they look a bit redundant with the actual blockchain
history to my eye) but circling back to utxo commitments, the benefits are
that it enables actual proofs of non-fraud: You can prove the validity of a
block based on just the previous block (and maybe some previous headers
because of mining rewards) and can prove to a light node that a utxo hasn't
been spent yet.
A major factor in the way of getting utxo commitments in blocks is
performance. The txo set is of course vastly larger and more unwieldy. If
you make the utxo commitments trail by a small fixed number of blocks
(between 2 and 5) their latency problems shouldn't be a big deal as long as
the overall performance is good enough. My thesis is that with appropriate
format and implementation tricks it's possible to get performance good
enough to no longer be a gating factor to deployment.
Disappointingly there hasn't been any feedback about my implementation,
just discussion about merkle sets generally.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170223/5dbd72da/attachment.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 17:56:31
in reply to nevent1q…dxak
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 17:56:31Event JSON
{
"id": "15c49c41ae155e1cc900554b654bcb89e84ddce3f8322dba51048859e13cbb01",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686160591,
"kind": 1,
"tags": [
[
"e",
"7c1fe6216790fb2846f605436edee6db0e33feb9c670df2e38b3b46417cf9504",
"",
"root"
],
[
"e",
"8d384773ec5e191ed4657cc20df68e23f161fff1c829882e98196f1781289855",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2017-02-23\n📝 Original message:On Thu, Feb 23, 2017 at 9:53 AM, Chris Priest via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e What problem does this try to solve, and what does it have to do with\n\u003e bitcoin?\n\u003e\n\nI can't speak to MMRs (they look a bit redundant with the actual blockchain\nhistory to my eye) but circling back to utxo commitments, the benefits are\nthat it enables actual proofs of non-fraud: You can prove the validity of a\nblock based on just the previous block (and maybe some previous headers\nbecause of mining rewards) and can prove to a light node that a utxo hasn't\nbeen spent yet.\n\nA major factor in the way of getting utxo commitments in blocks is\nperformance. The txo set is of course vastly larger and more unwieldy. If\nyou make the utxo commitments trail by a small fixed number of blocks\n(between 2 and 5) their latency problems shouldn't be a big deal as long as\nthe overall performance is good enough. My thesis is that with appropriate\nformat and implementation tricks it's possible to get performance good\nenough to no longer be a gating factor to deployment.\n\nDisappointingly there hasn't been any feedback about my implementation,\njust discussion about merkle sets generally.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170223/5dbd72da/attachment.html\u003e",
"sig": "20a498db137a4290ee7423c8b89a93ab408bab19061a271d0edacb42cdd11f9f35d4b018f9dac4814ec339e85907eae6e6540728bb4ac5d3b59c6d4d7e72f5ad"
}