more efficient transactions

[antonilol]

i found a way of committing a merkle tree to a bitcoin transaction that costs less fees and is compatible with the current opentimestamps client instead of an op_return output, the merkle tree is embedded in a p2wsh script

the op return output costs 8 bytes value, script length (22), OP_RETURN (6a), data length (20), 32 bytes data = 43 vbytes total when spending, the last witness element of 33/4 vbytes (p2wpkh pubkey) is replaced with a script <pubkey> checksigverify <commitment> ((34 + 1 + 33)/4 vbytes) and the p2wsh output costs 12 vbytes more compared to p2wpkh. timestamp transactions produced this way are 22.25 vbyte smaller, and will cost 23 sats less at 1 sat/vB (i like sats)

example (i timestamped a message with this type of transaction on testnet): timestamped text: testnet timestamps example 1 put this is a file named 'example'

ots file as hex: (echo <hex> | xxd -r -p > example.ots to convert to ots file)

004f70656e54696d657374616d7073000050726f6f6600bf89e2e884e8929401081d31be05e85083599f737b57093d6e30ec571a8473a5d1415ba3135ce56a03c0f1242102fd4e04cdb53aaba4a42f8c5ef2351512167a5d47022cccb66250312b519ccda6ad2008f13a0100000001f121a3cbddd4ca29758e9017d8c53638b24a51100b8da5ba03c13425af2bb6960000000000ffffffff018d26000000000000220020f004000000000808f020af10816130558cac98ea58e94b767f7ea9bbef818455c63db3ee5365ef2394190808f02011a84a66c3bf689f6298daafe39833b9046f6c5686f2121dcd86fb16a336f3e80808f0208e9b34418af67c0f8f1648616dc3535048973d40414a911b7972eab8106a84c10808f120b43540f35f0165b55c58a88915d8bd5d17a0938626ede9871bd1aee6a485ce4f0808f1200bd207f905c3b51c3d4c1feb83cbbbcf1d47b8f68a182dd4f6631467b6d0cadb0808000588960d73d7190104e0eb9201

verify:

$ ots --btc-testnet verify example.ots 
Assuming target filename is 'example'
Success! Bitcoin block 2405856 attests existence as of 2022-11-11 CET

txid (testnet): e880fa56a829a3890393a2213fe43f20a1a2ea51d4d8c4758b9bf65a4cfa3216 (forgot to use low r so only 22 vbyte smaller)

btw, merkle trees can also be committed using a taproot tweak like pubkey tweak, leaving no traces on the blockchain, but the opentimestamps client does not support this yet

[petertodd]

Thanks! Yes, that does save some space and cost. One reason why I haven't implemented that idea however is that if you lose the commitment, you've lost access to the funds. Not a huge problem. But needs some thought.

Also, would you mind redoing that timestamp on mainnet? It'd be cool to add it as a example in the OpenTimestamps client directory of timestamp examples. Best to make it be a timestamp of a short text file explaining how the timestamp works. Pretty sure you're the first person to actually implement this!

On November 11, 2022 7:21:18 PM GMT-05:00, Antoni Spaanderman @.***> wrote:

i found a way of committing a merkle tree to a bitcoin transaction that costs less fees and is compatible with the current opentimestamps client instead of an op_return output, the merkle tree is embedded in a p2wsh script

the op return output costs 8 bytes value, script length (22), OP_RETURN (6a), data length (20), 32 bytes data = 43 vbytes total when spending, the last witness element of 33/4 vbytes (p2wpkh pubkey) is replaced with a script <pubkey> checksigverify <commitment> ((34 + 1 + 33)/4 vbytes) and the p2wsh output costs 12 vbytes more compared to p2wpkh. timestamp transactions produced this way are 22.25 vbyte smaller, and will cost 23 sats less at 1 sat/vB (i like sats)

example (i timestamped a message with this type of transaction on testnet): timestamped text: testnet timestamps example 1 put this is a file named 'example'

ots file as hex: (echo <hex> | xxd -r -p > example.ots to convert to ots file)

004f70656e54696d657374616d7073000050726f6f6600bf89e2e884e8929401081d31be05e85083599f737b57093d6e30ec571a8473a5d1415ba3135ce56a03c0f1242102fd4e04cdb53aaba4a42f8c5ef2351512167a5d47022cccb66250312b519ccda6ad2008f13a0100000001f121a3cbddd4ca29758e9017d8c53638b24a51100b8da5ba03c13425af2bb6960000000000ffffffff018d26000000000000220020f004000000000808f020af10816130558cac98ea58e94b767f7ea9bbef818455c63db3ee5365ef2394190808f02011a84a66c3bf689f6298daafe39833b9046f6c5686f2121dcd86fb16a336f3e80808f0208e9b34418af67c0f8f1648616dc3535048973d40414a911b7972eab8106a84c10808f120b43540f35f0165b55c58a88915d8bd5d17a0938626ede9871bd1aee6a485ce4f0808f1200bd207f905c3b51c3d4c1feb83cbbbcf1d47b8f68a182dd4f6631467b6d0cadb0808000588960d73d7190104e0eb9201

verify:

$ ots --btc-testnet verify example.ots 
Assuming target filename is 'example'
Success! Bitcoin block 2405856 attests existence as of 2022-11-11 CET

txid (testnet): e880fa56a829a3890393a2213fe43f20a1a2ea51d4d8c4758b9bf65a4cfa3216 (forgot to use low r so only 22 vbyte smaller)

btw, merkle trees can also be committed using a taproot tweak like pubkey tweak, leaving no traces on the blockchain, but the opentimestamps client does not support this yet

-- Reply to this email directly or view it on GitHub: https://github.com/opentimestamps/opentimestamps-server/issues/91 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[antonilol]

One reason why I haven't implemented that idea however is that if you lose the commitment, you've lost access to the funds.

i have been working recently on storing 32 bytes of data in ecdsa signatures with no extra blockchain footprint, this can be used to store the commitment to later in case of disk failure reconstruct the p2wsh script with only the public blockchain (for the signature and message hash) and the seed/master key https://github.com/antonilol/btc_stuff/blob/master/ecdsa_sigdata.ts in this script, instead of signing with random/deterministic k, H(d || m) ^ encryptedData is used, the data is encrypted using aes 256 there but other encryption algorithms can also be used. this value can later be extracted and xor'ed with H(d || m), and decrypted. some grinding is needed however because not every signature is usable (low r and low s)

the commitment along with the derivation path (or only child key index) can also be stored somewhere else, it does not have to be private, so this could be anything (like pastebin ;)), but not having to rely on 3rd parties is better

Also, would you mind redoing that timestamp on mainnet? It'd be cool to add it as a example in the OpenTimestamps client directory of timestamp examples. Best to make it be a timestamp of a short text file explaining how the timestamp works. Pretty sure you're the first person to actually implement this!

sure, will open a pr there

also, i read you were rewriting this timestamp server in Rust, any progress on this? i can help implement this, just have to find some more free time to dig deeper in how Rust works :)