John Light [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-10-11 to 2022-10-12
💬 Posted a total of 2 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-08-06 23:37:35

- reply

📅 Original date posted:2023-08-06
🗒️ Summary of this message: John Light has sent an email to Peter regarding his proposal on removing OP_RETURN output count and data size limits, asking questions about the impact on full node operators.
📝 Original message:
Hi Peter,
Re: https://github.com/bitcoin/bitcoin/pull/28130
I have a few questions about your proposal and its impact on full node operators:
1. With your proposed policy change removing the OP_RETURN output count and data size limits, is there ever a case where using OP_RETURN to embed data actually results in fewer bytes onchain than embedding the same data using the segwit/taproot witness space e.g. the envelope technique inscriptions use? Robin Linus suggested on your PR there may be a case that "effectively results in a discount for small inscriptions".[1] It would be good to have confirmation on this and specific details about the range of inscription sizes that would receive the discount if this is true. (Robin himself is of course also welcome to answer this question; I have cc'd him directly on this email as an invitation to respond.)
2. Documentation about OP_RETURN says that OP_RETURN outputs are "provably-prunable".[2] A question I had about this was, are there any tools available that a full node operator could use to prune this data from their nodes? While researching this question I found PR #2791 from Pieter Wuille, which implemented pruning of provably-unspendable outputs, which I assume includes OP_RETURN outputs.[3] After looking around some more and not finding definitive answers, I have a few new questions about this:
i) Is the unspendable output pruning implemented in PR #2791 on by default or is this a flag that needs to be enabled by full node operators? If it's a flag, what is the flag called and how can it be enabled? If it's on by default, how can it be disabled?
ii) If a full node operator does prune OP_RETURN outputs, does that in any way impair their ability to help a new node do IBD to validate the blockchain? And would that answer be any different if we were talking about pruning Taproot witness space (i.e. "envelopes" or "inscriptions") instead of OP_RETURN outputs?
Regards,
John Light
[1] https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1664950834
[2] https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain
[3] https://github.com/bitcoin/bitcoin/pull/2791

2023-06-07 23:15:09

- reply

📅 Original date posted:2022-10-12
📝 Original message:On Wed, Oct 12, 2022, at 9:28 AM, Greg Sanders wrote:
> Is there a one page cheat sheet of "asks" for transaction
> introspection/OP_ZKP(?) and their uses both separately and together for
> different rollup architectures?
We do not have this yet. Trey Del Bonis wrote a more detailed technical post about how those components would be used in a validity rollup, which was cited in my report and can be found here:
https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html
But it'll take more research and design work to suss out those details you asked for and put them into a nice cheatsheet. I like this idea though!

2023-06-07 23:15:09

- reply

📅 Original date posted:2022-10-11
📝 Original message:Hi all,
Today I am publishing "Validity Rollups on Bitcoin", a report I produced as part of the Human Rights Foundation's ZK-Rollup Research Fellowship.
Here's the preface:
> Ever since Satoshi Nakamoto first publicly announced bitcoin, its supporters, critics, and skeptics alike have questioned how the protocol would scale as usage increases over time. This question is more important than ever today, as blocks are increasingly full or close to full of transactions. So-called "Layer 2" (L2) protocols such as the Lightning Network have been deployed to take some transaction volume "offchain" but even Lightning needs to use _some_ bitcoin block space. It's clear that as bitcoin is adopted by more and more of the world's population (human and machine alike!) more block space will be needed. Another thread of inquiry concerns whether bitcoin's limited scripting capabilities help or hinder its value as electronic cash. Researchers and inventors have shown that the electronic cash transactions first made possible by bitcoin could be given new form by improving transaction privacy, supporting new types of smart contracts, and even creating entirely new blockchain-based assets.
>
> One of the results of the decade-plus research into scaling and expanding the capabilities of blockchains such as bitcoin is the invention of the validity rollup. Given the observed benefits that validity rollups have for the blockchains that have already implemented them, attention now turns to the question of whether they would be beneficial for bitcoin and existing bitcoin L2 protocols such as Lightning, too. We explore this question by examining validity rollups from several angles, including their history, how they work on a technical level, how they could be built on bitcoin, and what the benefits, costs, and risks of building them on bitcoin might be. We conclude that validity rollups have the potential to improve the scalability, privacy, and programmability of bitcoin without sacrificing bitcoin's core values or functionality as a peer-to-peer electronic cash system. Given the "trustless" nature of validity rollups as cryptographically-secured extensions of their parent chain, and given bitcoin's status as the most secure settlement layer, one could even say these protocols are a _perfect match_ for one another.
You can find the full report here:
https://bitcoinrollups.org
Happy to receive any comments and answer any questions the bitcoin dev community may have about the report!
Best regards,
John Light