📅 Original date posted:2017-05-16
📝 Original message:On Mon, May 15, 2017 at 11:59:58PM +0000, Gregory Maxwell via bitcoin-dev wrote:
> On Mon, May 15, 2017 at 11:04 PM, ZmnSCPxj via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > transactions is in the header, which would let lite nodes download a UTXO
> > set from any full node and verify it by verifying only block headers
> > starting from genesis.
>
> Ya, lite nodes with UTXO sets are one of the the oldest observed
> advantages of a commitment to the UTXO data:
>
> https://bitcointalk.org/index.php?topic=21995.0
>
> But it requires a commitment. And for most of the arguments for those
> you really want compact membership proofs. The recent rise in
> interest in full block lite clients (for privacy reasons), perhaps
> complements the membership proofless usage.
>
> Pieter describes some uses for doing something like this without a
> commitment. In my view, it's more interesting to first gain
> experience with an operation without committing to it (which is a
> consensus change and requires more care and consideration, which are
> easier if people have implementation experience).
To be clear, *none* of the previous (U)TXO commitment schemes require *miners*
to participate in generating a commitment. While that was previously thought to
be true by many, I've seen no counter-arguments to the argument I published I
few months ago(1) that (U)TXO commitments did not require a soft-fork to
deploy.
1) "[bitcoin-dev] TXO commitments do not need a soft-fork to be useful",
Peter Todd, Feb 23 2017,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html
--
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/20170516/8b074bc9/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 18:01:14
in reply to nevent1q…qu0t
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 18:01:14Event JSON
{
"id": "42ca4c9517a58d7b6a619e2bcc42b6f722e34a6faad74ea2a8fcb9ef0b3a0ee3",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686160874,
"kind": 1,
"tags": [
[
"e",
"2462c5efea084ebfedb9b64774e4a3c5d144e23fcea0a84ec9dd98127404e039",
"",
"root"
],
[
"e",
"cf59ab6e0d7911e9a6c1a1f5a01caf1ba409b4589d8ffb503254b4b55686347d",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2017-05-16\n📝 Original message:On Mon, May 15, 2017 at 11:59:58PM +0000, Gregory Maxwell via bitcoin-dev wrote:\n\u003e On Mon, May 15, 2017 at 11:04 PM, ZmnSCPxj via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e transactions is in the header, which would let lite nodes download a UTXO\n\u003e \u003e set from any full node and verify it by verifying only block headers\n\u003e \u003e starting from genesis.\n\u003e \n\u003e Ya, lite nodes with UTXO sets are one of the the oldest observed\n\u003e advantages of a commitment to the UTXO data:\n\u003e \n\u003e https://bitcointalk.org/index.php?topic=21995.0\n\u003e \n\u003e But it requires a commitment. And for most of the arguments for those\n\u003e you really want compact membership proofs. The recent rise in\n\u003e interest in full block lite clients (for privacy reasons), perhaps\n\u003e complements the membership proofless usage.\n\u003e \n\u003e Pieter describes some uses for doing something like this without a\n\u003e commitment. In my view, it's more interesting to first gain\n\u003e experience with an operation without committing to it (which is a\n\u003e consensus change and requires more care and consideration, which are\n\u003e easier if people have implementation experience).\n\nTo be clear, *none* of the previous (U)TXO commitment schemes require *miners*\nto participate in generating a commitment. While that was previously thought to\nbe true by many, I've seen no counter-arguments to the argument I published I\nfew months ago(1) that (U)TXO commitments did not require a soft-fork to\ndeploy.\n\n1) \"[bitcoin-dev] TXO commitments do not need a soft-fork to be useful\",\n Peter Todd, Feb 23 2017,\n https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html\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/20170516/8b074bc9/attachment.sig\u003e",
"sig": "a59b392e115655bb34cffbcb9e63072faf0404b253bb1f738072a8fd33183c87fa59c08d2dc6f4df6fb657681ff3e490960057dc486d097aa8fb693bf4e6dc1e"
}