Bram Cohen [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-24 📝 Original message:On Thu, Feb 23, 2017 at ...
📅 Original date posted:2017-02-24
📝 Original message:On Thu, Feb 23, 2017 at 7:15 PM, Peter Todd <pete at petertodd.org> wrote:
>
> Glad we're on the same page with regard to what's possible in TXO
> commitments.
>
> Secondly, am I correct in saying your UTXO commitments scheme requires
> random
> access? While you describe it as a "merkle set", obviously to be merkelized
> it'll have to have an ordering of some kind. What do you propose that
> ordering
> to be?
>
The ordering is by the bits in the hash. Technically it's a Patricia Trie.
I'm using 'merkle tree' to refer to basically anything with a hash root.
> Maybe more specifically, what exact values do you propose to be in the set?
>
>
That is unspecified in the implementation, it just takes a 256 bit value
which is presumably a hash of something. The intention is to nail down a
simple format and demonstrate good performance and leave those semantics to
a higher layer. The simplest thing would be to hash together the txid and
output number.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170223/ebb642c9/attachment.html>
Published at
2023-06-07 17:56:33Event JSON
{
"id": "0dd8c17ca6735d9f9fcb330f32bcb6aba0bc2312e5265e59a494933acda6bb0a",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686160593,
"kind": 1,
"tags": [
[
"e",
"7c1fe6216790fb2846f605436edee6db0e33feb9c670df2e38b3b46417cf9504",
"",
"root"
],
[
"e",
"cbd86faa8950dbdd305e7fc5ac11d98292e15a6e802f06ce18e582f2c7434f8a",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2017-02-24\n📝 Original message:On Thu, Feb 23, 2017 at 7:15 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e\n\u003e Glad we're on the same page with regard to what's possible in TXO\n\u003e commitments.\n\u003e\n\u003e Secondly, am I correct in saying your UTXO commitments scheme requires\n\u003e random\n\u003e access? While you describe it as a \"merkle set\", obviously to be merkelized\n\u003e it'll have to have an ordering of some kind. What do you propose that\n\u003e ordering\n\u003e to be?\n\u003e\n\nThe ordering is by the bits in the hash. Technically it's a Patricia Trie.\nI'm using 'merkle tree' to refer to basically anything with a hash root.\n\n\n\u003e Maybe more specifically, what exact values do you propose to be in the set?\n\u003e\n\u003e\nThat is unspecified in the implementation, it just takes a 256 bit value\nwhich is presumably a hash of something. The intention is to nail down a\nsimple format and demonstrate good performance and leave those semantics to\na higher layer. The simplest thing would be to hash together the txid and\noutput number.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170223/ebb642c9/attachment.html\u003e",
"sig": "e7cbb69816df5ec5ee5254aef2817b54b652bb4961fa4b0ae77688951901e8e0227d03bf8c270794b90bec7319d3158a1bdf44a1254e8f5e7a846eb88e03b8cb"
}