📅 Original date posted:2023-02-01
🗒️ Summary of this message: Christopher Allen is exploring the tradeoffs of post-taproot Bitcoin and seeking the most pragmatic way to use the blockchain for non-transactional data.
📝 Original message:I don't have a concrete proposal in mind, I'm just trying to understand
various tradeoffs in post-taproot bitcoin in more detail.
On Tue, Jan 31, 2023 at 6:07 PM Peter Todd <pete at petertodd.org> wrote:
>
> >OP_FALSE
> >OP_IF
> >OP_PUSH my64bytes
> >OP_ENDIF
>
> What's wrong with OpPush <data> OpDrop?
>
I'm not sure pro or con of either. I just saw that proposal above recently.
> Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The
> whole point of OpReturn is to standardize a way to keep such outputs out of
> the UTXO set. There is the 75% discount to using witness space. But
> considering the size of a transaction as a whole using taproot instead of
> OpReturn doesn't save much.
>
There are OP_RETURN tricks in production that do clog UTXO space. I was
trying to avoid consideration of those by just saying to compare apples vs.
apples, by presuming that any form of these transactions holding the 64
bytes is a spent transaction.
Finally, _64_ bytes is more than a mere 32 byte commitment. What specific
> use case do you actually have in mind here? Are you actually publishing
> data, or simply committing to data? If the latter, you can use ECC
> commitments and have no extra space at all.
>
I chose 64 bytes for this exercise, as I know there are tricks hiding 32
bytes as keys. As almost every op_return live out there is >32 bytes, I
wanted an example that could be a signature, two hashes, a hash plus some
metadata, etc. I also considered 96 bytes (for instance a hash and a
signature), but as that doesn't fit into OP_RETURN's 80 bytes, that choice
prohibits comparing the different approaches side-by-side.
To come back to my question another way, if you ignore the people who say
"never put anything except data facilitating coin transactions into the
bitcoin blockchain", but if you also are not trying to use the bitcoin
blockchain as a world database (ala ETH), what is the most pragmatic way to
do so that minimizes any potential harm? The answer pre-taproot was
OP_RETURN. What is it now?
-- Christopher Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230131/60e5928e/attachment.html>;
Christopher Allen [ARCHIVE] /
npub19g…ct5d0
2023-06-07 23:18:54
in reply to nevent1q…phwx
Author Public Key
npub19g47w5ewcqlpd7n07wpkp5cvcu2gjwrse0vl47l0avwl9hu933xsqct5d0Published at
2023-06-07 23:18:54Event JSON
{
"id": "7f715e2e40701a01f8df177c5bffdc01e1baf47fa97c5bceec9dafef0fc0a724",
"pubkey": "2a2be7532ec03e16fa6ff38360d30cc714893870cbd9fafbefeb1df2df858c4d",
"created_at": 1686179934,
"kind": 1,
"tags": [
[
"e",
"db7e30240de322a59459e6f6d735c7f019f73c8194514d70467812fbd7606451",
"",
"root"
],
[
"e",
"f1cb46c4aba0a6c214062937b76bb40645d5f437566886778857223f2d636620",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2023-02-01\n🗒️ Summary of this message: Christopher Allen is exploring the tradeoffs of post-taproot Bitcoin and seeking the most pragmatic way to use the blockchain for non-transactional data.\n📝 Original message:I don't have a concrete proposal in mind, I'm just trying to understand\nvarious tradeoffs in post-taproot bitcoin in more detail.\n\nOn Tue, Jan 31, 2023 at 6:07 PM Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e\n\u003e \u003eOP_FALSE\n\u003e \u003eOP_IF\n\u003e \u003eOP_PUSH my64bytes\n\u003e \u003eOP_ENDIF\n\u003e\n\u003e What's wrong with OpPush \u003cdata\u003e OpDrop?\n\u003e\n\nI'm not sure pro or con of either. I just saw that proposal above recently.\n\n\n\u003e Also, it is incorrect to say that OpReturn outputs \"clog UTXO space\". The\n\u003e whole point of OpReturn is to standardize a way to keep such outputs out of\n\u003e the UTXO set. There is the 75% discount to using witness space. But\n\u003e considering the size of a transaction as a whole using taproot instead of\n\u003e OpReturn doesn't save much.\n\u003e\n\nThere are OP_RETURN tricks in production that do clog UTXO space. I was\ntrying to avoid consideration of those by just saying to compare apples vs.\napples, by presuming that any form of these transactions holding the 64\nbytes is a spent transaction.\n\nFinally, _64_ bytes is more than a mere 32 byte commitment. What specific\n\u003e use case do you actually have in mind here? Are you actually publishing\n\u003e data, or simply committing to data? If the latter, you can use ECC\n\u003e commitments and have no extra space at all.\n\u003e\n\nI chose 64 bytes for this exercise, as I know there are tricks hiding 32\nbytes as keys. As almost every op_return live out there is \u003e32 bytes, I\nwanted an example that could be a signature, two hashes, a hash plus some\nmetadata, etc. I also considered 96 bytes (for instance a hash and a\nsignature), but as that doesn't fit into OP_RETURN's 80 bytes, that choice\nprohibits comparing the different approaches side-by-side.\n\nTo come back to my question another way, if you ignore the people who say\n\"never put anything except data facilitating coin transactions into the\nbitcoin blockchain\", but if you also are not trying to use the bitcoin\nblockchain as a world database (ala ETH), what is the most pragmatic way to\ndo so that minimizes any potential harm? The answer pre-taproot was\nOP_RETURN. What is it now?\n\n-- Christopher Allen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230131/60e5928e/attachment.html\u003e",
"sig": "00d4e12e5e7bee39aa1e9f493a70fc0a620f08161d29b914c7356d1dfe3a23db27fd5c34ebe5247107fac1e3edca0e6bd98c9af8d56580ef5e281b47f8865ff7"
}