📅 Original date posted:2022-02-24
📝 Original message:Note this has always been possible, and is not specifically related to
tapscript. As long as you're committing to an ECC point, you can tweak it
to commit data inside it (i.e. pay-to-contract). This includes P2PK and
P2PKH.
Committing to 1.5GB of data has equally been possible with OP_RETURN
<hash>, or even an entire merkle tree of hashes, as is the case with Todd's
opentimestamps.
Also, tweaking an ECC point (this includes tapscript) in non-deterministic
ways also makes it harder to recover from backup, because you can't recover
the key without knowing the full commitment.
Furthermore, the scheme is not actually equivalent to op_return, because
it requires the user to communicate out-of-band to reveal the commitment,
whereas with op_return the data is immediately visible (while not popular,
BIP47 and various colored coin protocols rely on this).
Cheers,
Ruben
On Thu, Feb 24, 2022 at 10:19 AM vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Since Taproot was activated, we no longer need separate OP_RETURN outputs
> to be pushed on-chain. If we want to attach any data to a transaction, we
> can create "OP_RETURN <anything>" as a branch in the TapScript. In this
> way, we can store that data off-chain and we can always prove that they are
> connected with some taproot address, that was pushed on-chain. Also, we can
> store more than 80 bytes for "free", because no such taproot branch will be
> ever pushed on-chain and used as an input. That means we can use "OP_RETURN
> <1.5 GB of data>", create some address having that taproot branch, and
> later prove to anyone that such "1.5 GB of data" is connected with our
> taproot address.
>
> Currently in Bitcoin Core we have "data" field in "createrawtransaction".
> Should the implementation be changed to place that data in a TapScript
> instead of creating separate OP_RETURN output? What do you think?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/e1bb7a97/attachment-0001.html>;
Ruben Somsen [ARCHIVE] /
npub1cn…qyeq0
2023-06-07 23:04:51
in reply to nevent1q…37tl
Author Public Key
npub1cnrnujx86le38yu2jrt3la0yhewsrh2p2lucakv6mu28x7lm0rsq9qyeq0Published at
2023-06-07 23:04:51Event JSON
{
"id": "62608eac0890e7ef88d06f0312942a9a2b22cbdcf30b52d5ce882038741c41c1",
"pubkey": "c4c73e48c7d7f313938a90d71ff5e4be5d01dd4157f98ed99adf14737bfb78e0",
"created_at": 1686179091,
"kind": 1,
"tags": [
[
"e",
"3e6d073ce9df9e718a58810827a644673d7a6ffe0ae6d99287d03c682a819b60",
"",
"root"
],
[
"e",
"07f1098b660224768d51ae3e6f9ff5f1ca16c79603028f06ebb83fff149e9eb2",
"",
"reply"
],
[
"p",
"8d3cf7eba921036409f1fec074cf8cfd8925bc7cb18e35d358b1ccc89752ee32"
]
],
"content": "📅 Original date posted:2022-02-24\n📝 Original message:Note this has always been possible, and is not specifically related to\ntapscript. As long as you're committing to an ECC point, you can tweak it\nto commit data inside it (i.e. pay-to-contract). This includes P2PK and\nP2PKH.\n\nCommitting to 1.5GB of data has equally been possible with OP_RETURN\n\u003chash\u003e, or even an entire merkle tree of hashes, as is the case with Todd's\nopentimestamps.\n\nAlso, tweaking an ECC point (this includes tapscript) in non-deterministic\nways also makes it harder to recover from backup, because you can't recover\nthe key without knowing the full commitment.\n\nFurthermore, the scheme is not actually equivalent to op_return, because\nit requires the user to communicate out-of-band to reveal the commitment,\nwhereas with op_return the data is immediately visible (while not popular,\nBIP47 and various colored coin protocols rely on this).\n\nCheers,\nRuben\n\n\nOn Thu, Feb 24, 2022 at 10:19 AM vjudeu via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Since Taproot was activated, we no longer need separate OP_RETURN outputs\n\u003e to be pushed on-chain. If we want to attach any data to a transaction, we\n\u003e can create \"OP_RETURN \u003canything\u003e\" as a branch in the TapScript. In this\n\u003e way, we can store that data off-chain and we can always prove that they are\n\u003e connected with some taproot address, that was pushed on-chain. Also, we can\n\u003e store more than 80 bytes for \"free\", because no such taproot branch will be\n\u003e ever pushed on-chain and used as an input. That means we can use \"OP_RETURN\n\u003e \u003c1.5 GB of data\u003e\", create some address having that taproot branch, and\n\u003e later prove to anyone that such \"1.5 GB of data\" is connected with our\n\u003e taproot address.\n\u003e\n\u003e Currently in Bitcoin Core we have \"data\" field in \"createrawtransaction\".\n\u003e Should the implementation be changed to place that data in a TapScript\n\u003e instead of creating separate OP_RETURN output? What do you think?\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/e1bb7a97/attachment-0001.html\u003e",
"sig": "7c0d53d9ca767ec53c24555720edd2a0e42428be112796c962f94d2f28fc83c1c8d66ba48aa3fd5e85dbff61a5482a99b2222382eaf7ec1a59c7f48fec88cfc7"
}