Kostas Karasavvas [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-05-27 to 2023-04-19
💬 Posted a total of 9 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-06-09 13:13:04

- reply

📅 Original date posted:2023-04-19
🗒️ Summary of this message: A proposal for tighter coupling between full nodes and Lightning nodes has been suggested, with the argument that in a world with higher transaction fees, almost every full node would also want to be a Lightning node. However, the complexity argument for separation of concerns remains strong.
📝 Original message:
Hi Michael,
On Wed, Apr 19, 2023 at 2:40 AM Michael Folkson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Any thoughts on this from the Core Lightning contributors? The way I see
> it with upcoming proposed changes to default policy (primarily though not
> exclusively for Lightning) and a soft fork activation attempt of APO/APOAS
> (primarily though not
>
Could you please point me to a resource that describes the default policy
changes (that are happening for lightning)? I have seen discussions here
and there but it would help if they are aggregated somewhere for reviewing.
> exclusively for Lightning) that a tighter coupling between the full node
> and the Lightning node could eventually make sense. In a world where
> transaction fees were much higher you'd think almost every full node would
> also want to be a Lightning node and so the separation of concerns would
> make less sense.
>
Separation of concerns always makes sense to manage complexity. One would
need to have really strong incentives to counter the complexity argument.
I might be missing some context here but what would the actual benefit of
integrating them be? Not having to install lightning node separately and
maybe a more intuitive UX?
Having two separate P2P networks and two separate P2P protocols also
> wouldn't make much sense in this scenario. You could obviously still opt
> out of Lightning P2P messages if you weren't interested in Lightning.
>
> The alternative would be just to focus on Knots style consensus compatible
> forks of Core with limited additional functionality. But I think we've
> reached the point of no return on Core dominance and not having widely used
> "distros". As the ecosystem scales systems and processes should be
> constantly evolving and improving and to me if anything Core's seem to be
> going backwards.
>
>
Personally, I have great difficulty seeing lightning as something other
than an L2 build on top of Bitcoin. There will be other L2s.
Regards,
Kostas
PS. Besides, the amount of effort would be significant. Wouldn't that
effort be better spent on, say, separating the consensus logic (i.e. a
second libbitcoinkernel attempt)?
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Saturday, January 14th, 2023 at 20:26, Michael Folkson <
> michaelfolkson at protonmail.com> wrote:
>
> I tweeted this [0] back in November 2022.
>
> "With the btcd bugs and the analysis paralysis on a RBF policy option in
> Core increasingly thinking @BitcoinKnots and consensus compatible forks of
> Core are the future. Gonna chalk that one up to another thing @LukeDashjr
> was right about all along."
>
> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated
> with Core Lightning was a long term idea I had (and presumably many others
> have had) but the dysfunction on the Bitcoin Core project this week (if
> anything it has been getting worse over time, not better) has made me start
> to take the idea more seriously. It is clear to me that the current way the
> Bitcoin Core project is being managed is not how I would like an open
> source project to be managed. Very little discussion is public anymore and
> decisions seem to be increasingly made behind closed doors or in private
> IRC channels (to the extent that decisions are made at all). Core Lightning
> seems to have the opposite problem. It is managed effectively in the open
> (admittedly with fewer contributors) but doesn't have the eyeballs or the
> usage that Bitcoin Core does. Regardless, selfishly I at some point would
> like a bare bones Bitcoin and Lightning implementation integrated in one
> codebase. The Bitcoin Core codebase has collected a lot of cruft over time
> and the ultra conservatism that is needed when treating (potential)
> consensus code seems to permeate into parts of the codebase that no one is
> using, definitely isn't consensus code and should probably just be removed.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensus
> engine out of Core but it seems like it won't achieve that as consensus is
> just too slippery a concept and Knots style consensus compatible codebase
> forks of Bitcoin Core seem to still the model. To what extent you can
> safely chop off this cruft and effectively maintain this less crufty fork
> of Bitcoin Core also isn't clear to me yet.
>
> Then there is the question of whether it makes sense to mix C and C++ code
> that people have different views on. C++ is obviously a superset of C but
> assuming this merging of Bitcoin Core and Core Lightning is/was the optimal
> final destination it surely would have been better if Core Lightning was
> written in the same language (i.e. with classes) as Bitcoin Core.
>
> I'm just floating the idea to (hopefully) hear from people who are much
> more familiar with the entirety of the Bitcoin Core and Core Lightning
> codebases. It would be an ambitious long term project but it would be nice
> to focus on some ambitious project(s) (even if just conceptually) for a
> while given (thankfully) there seems to be a lull in soft fork activation
> chaos.
>
> Thanks
> Michael
>
> [0]:
> https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
https://twitter.com/kkarasavvas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230419/feeac28d/attachment-0001.html>

2023-06-09 13:08:34

- reply

📅 Original date posted:2023-04-19
📝 Original message:
Hi Michael,
On Wed, Apr 19, 2023 at 2:40 AM Michael Folkson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Any thoughts on this from the Core Lightning contributors? The way I see
> it with upcoming proposed changes to default policy (primarily though not
> exclusively for Lightning) and a soft fork activation attempt of APO/APOAS
> (primarily though not
>
Could you please point me to a resource that describes the default policy
changes (that are happening for lightning)? I have seen discussions here
and there but it would help if they are aggregated somewhere for reviewing.
> exclusively for Lightning) that a tighter coupling between the full node
> and the Lightning node could eventually make sense. In a world where
> transaction fees were much higher you'd think almost every full node would
> also want to be a Lightning node and so the separation of concerns would
> make less sense.
>
Separation of concerns always makes sense to manage complexity. One would
need to have really strong incentives to counter the complexity argument.
I might be missing some context here but what would the actual benefit of
integrating them be? Not having to install lightning node separately and
maybe a more intuitive UX?
Having two separate P2P networks and two separate P2P protocols also
> wouldn't make much sense in this scenario. You could obviously still opt
> out of Lightning P2P messages if you weren't interested in Lightning.
>
> The alternative would be just to focus on Knots style consensus compatible
> forks of Core with limited additional functionality. But I think we've
> reached the point of no return on Core dominance and not having widely used
> "distros". As the ecosystem scales systems and processes should be
> constantly evolving and improving and to me if anything Core's seem to be
> going backwards.
>
>
Personally, I have great difficulty seeing lightning as something other
than an L2 build on top of Bitcoin. There will be other L2s.
Regards,
Kostas
PS. Besides, the amount of effort would be significant. Wouldn't that
effort be better spent on, say, separating the consensus logic (i.e. a
second libbitcoinkernel attempt)?
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Saturday, January 14th, 2023 at 20:26, Michael Folkson <
> michaelfolkson at protonmail.com> wrote:
>
> I tweeted this [0] back in November 2022.
>
> "With the btcd bugs and the analysis paralysis on a RBF policy option in
> Core increasingly thinking @BitcoinKnots and consensus compatible forks of
> Core are the future. Gonna chalk that one up to another thing @LukeDashjr
> was right about all along."
>
> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated
> with Core Lightning was a long term idea I had (and presumably many others
> have had) but the dysfunction on the Bitcoin Core project this week (if
> anything it has been getting worse over time, not better) has made me start
> to take the idea more seriously. It is clear to me that the current way the
> Bitcoin Core project is being managed is not how I would like an open
> source project to be managed. Very little discussion is public anymore and
> decisions seem to be increasingly made behind closed doors or in private
> IRC channels (to the extent that decisions are made at all). Core Lightning
> seems to have the opposite problem. It is managed effectively in the open
> (admittedly with fewer contributors) but doesn't have the eyeballs or the
> usage that Bitcoin Core does. Regardless, selfishly I at some point would
> like a bare bones Bitcoin and Lightning implementation integrated in one
> codebase. The Bitcoin Core codebase has collected a lot of cruft over time
> and the ultra conservatism that is needed when treating (potential)
> consensus code seems to permeate into parts of the codebase that no one is
> using, definitely isn't consensus code and should probably just be removed.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensus
> engine out of Core but it seems like it won't achieve that as consensus is
> just too slippery a concept and Knots style consensus compatible codebase
> forks of Bitcoin Core seem to still the model. To what extent you can
> safely chop off this cruft and effectively maintain this less crufty fork
> of Bitcoin Core also isn't clear to me yet.
>
> Then there is the question of whether it makes sense to mix C and C++ code
> that people have different views on. C++ is obviously a superset of C but
> assuming this merging of Bitcoin Core and Core Lightning is/was the optimal
> final destination it surely would have been better if Core Lightning was
> written in the same language (i.e. with classes) as Bitcoin Core.
>
> I'm just floating the idea to (hopefully) hear from people who are much
> more familiar with the entirety of the Bitcoin Core and Core Lightning
> codebases. It would be an ambitious long term project but it would be nice
> to focus on some ambitious project(s) (even if just conceptually) for a
> while given (thankfully) there seems to be a lull in soft fork activation
> chaos.
>
> Thanks
> Michael
>
> [0]:
> https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
https://twitter.com/kkarasavvas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230419/feeac28d/attachment-0001.html>

2023-06-07 23:20:49

- reply

📅 Original date posted:2023-04-19
🗒️ Summary of this message: Discussion on potential tighter coupling between full node and Lightning node due to proposed changes to default policy and soft fork activation attempt. Separation of concerns and complexity management questioned.
📝 Original message:Hi Michael,
On Wed, Apr 19, 2023 at 2:40 AM Michael Folkson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Any thoughts on this from the Core Lightning contributors? The way I see
> it with upcoming proposed changes to default policy (primarily though not
> exclusively for Lightning) and a soft fork activation attempt of APO/APOAS
> (primarily though not
>
Could you please point me to a resource that describes the default policy
changes (that are happening for lightning)? I have seen discussions here
and there but it would help if they are aggregated somewhere for reviewing.
> exclusively for Lightning) that a tighter coupling between the full node
> and the Lightning node could eventually make sense. In a world where
> transaction fees were much higher you'd think almost every full node would
> also want to be a Lightning node and so the separation of concerns would
> make less sense.
>
Separation of concerns always makes sense to manage complexity. One would
need to have really strong incentives to counter the complexity argument.
I might be missing some context here but what would the actual benefit of
integrating them be? Not having to install lightning node separately and
maybe a more intuitive UX?
Having two separate P2P networks and two separate P2P protocols also
> wouldn't make much sense in this scenario. You could obviously still opt
> out of Lightning P2P messages if you weren't interested in Lightning.
>
> The alternative would be just to focus on Knots style consensus compatible
> forks of Core with limited additional functionality. But I think we've
> reached the point of no return on Core dominance and not having widely used
> "distros". As the ecosystem scales systems and processes should be
> constantly evolving and improving and to me if anything Core's seem to be
> going backwards.
>
>
Personally, I have great difficulty seeing lightning as something other
than an L2 build on top of Bitcoin. There will be other L2s.
Regards,
Kostas
PS. Besides, the amount of effort would be significant. Wouldn't that
effort be better spent on, say, separating the consensus logic (i.e. a
second libbitcoinkernel attempt)?
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Saturday, January 14th, 2023 at 20:26, Michael Folkson <
> michaelfolkson at protonmail.com> wrote:
>
> I tweeted this [0] back in November 2022.
>
> "With the btcd bugs and the analysis paralysis on a RBF policy option in
> Core increasingly thinking @BitcoinKnots and consensus compatible forks of
> Core are the future. Gonna chalk that one up to another thing @LukeDashjr
> was right about all along."
>
> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated
> with Core Lightning was a long term idea I had (and presumably many others
> have had) but the dysfunction on the Bitcoin Core project this week (if
> anything it has been getting worse over time, not better) has made me start
> to take the idea more seriously. It is clear to me that the current way the
> Bitcoin Core project is being managed is not how I would like an open
> source project to be managed. Very little discussion is public anymore and
> decisions seem to be increasingly made behind closed doors or in private
> IRC channels (to the extent that decisions are made at all). Core Lightning
> seems to have the opposite problem. It is managed effectively in the open
> (admittedly with fewer contributors) but doesn't have the eyeballs or the
> usage that Bitcoin Core does. Regardless, selfishly I at some point would
> like a bare bones Bitcoin and Lightning implementation integrated in one
> codebase. The Bitcoin Core codebase has collected a lot of cruft over time
> and the ultra conservatism that is needed when treating (potential)
> consensus code seems to permeate into parts of the codebase that no one is
> using, definitely isn't consensus code and should probably just be removed.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensus
> engine out of Core but it seems like it won't achieve that as consensus is
> just too slippery a concept and Knots style consensus compatible codebase
> forks of Bitcoin Core seem to still the model. To what extent you can
> safely chop off this cruft and effectively maintain this less crufty fork
> of Bitcoin Core also isn't clear to me yet.
>
> Then there is the question of whether it makes sense to mix C and C++ code
> that people have different views on. C++ is obviously a superset of C but
> assuming this merging of Bitcoin Core and Core Lightning is/was the optimal
> final destination it surely would have been better if Core Lightning was
> written in the same language (i.e. with classes) as Bitcoin Core.
>
> I'm just floating the idea to (hopefully) hear from people who are much
> more familiar with the entirety of the Bitcoin Core and Core Lightning
> codebases. It would be an ambitious long term project but it would be nice
> to focus on some ambitious project(s) (even if just conceptually) for a
> while given (thankfully) there seems to be a lull in soft fork activation
> chaos.
>
> Thanks
> Michael
>
> [0]:
> https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
https://twitter.com/kkarasavvas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230419/feeac28d/attachment.html>

2023-06-07 23:19:20

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: Discussion on storing unlimited amounts of NFT content as witness data using the ordinal scheme, with concerns about future disk use and suggestions for imposing size limits or charging premiums.
📝 Original message:On Fri, Feb 3, 2023 at 10:17 PM Melvin Carvalho via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> pá 27. 1. 2023 v 13:47 odesílatel Robert Dickinson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> napsal:
>
>> I'm curious what opinions exist and what actions might be taken by core
>> developers regarding storing unlimited amounts of NFT (or other?) content
>> as witness data (https://docs.ordinals.com/inscriptions.html). The
>> ordinal scheme is elegant and genius IMHO, but when I think about the
>> future disk use of all unpruned nodes, I question whether unlimited storage
>> is wise to allow for such use cases. Wouldn't it be better to find a way to
>> impose a size limit similar to OP_RETURN for such inscriptions?
>>
>>
Personally, I was always considering future disk use at full capacity
anyway (and planning accordingly). Even without inscriptions/ordinals that
would happen. The latter competes for block space and are paying tx fees so
I don't see it as that much harmful (esp.now that it is out there... I
would be more conservative if we were talking about introducing it!).
> I think it would be useful to link a sat to a deed or other legal
>> construct for proof of ownership in the real world, so that real property
>> can be transferred on the blockchain using ordinals, but storing the
>> property itself on the blockchain seems nonsensical to me.
>>
>
> Low tech solution: miners charge a premium for storing images in the block
> chain. Say 2x, 5x, 10x.
>
> This encourages bitcoin to be used as a financial network, while
> increasing the security budget.
>
How would you enforce this technically? I only see it feasible if miners
agree by social contract.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/864a905e/attachment.html>

2023-06-07 23:18:58

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: Increasing the size of OP_RETURN to support a hash, signature, and metadata would be helpful, but inscription-style use cases will still be primarily for larger datasets.
📝 Original message:On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I think the right way so people don't invent deviant things is to
>> increase the size of OP_RETURN, I don't get this number of 80B, you can
>> hardly store a signature (of what?) in there and not the "what" if the
>> "what" is a hash for example
>>
>
> Updating the size of OP_RETURN to support a hash (or two), a signature,
> and maybe a few more bytes for metadata, would be very helpful in a number
> of scenarios. It is still a limit but a reasonable one. Otherwise, I think
> we'll have a lot more inscription-style scenarios.
>
I wouldn't be against an increase in OP_RETURN but I don't think it will
make any difference in how often inscription-style use cases will be used.
They will be used primarily for much larger datasets than, say 120 bytes,
and they also have the segwit discount.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/c2c7730d/attachment.html>

2023-06-07 23:18:54

- reply

📅 Original date posted:2023-02-01
🗒️ Summary of this message: OP_RETURN is better for time-stamping, while Taproot is better for keeping data private until needed. For 80 bytes or less, OP_RETURN is still preferable.
📝 Original message:With OP_RETURN you publish some data that are immediately visible in the
blockchain. I would consider this better (more straightforward) for things
like time-stamping.
With Taproot you need to spend the utxo to make the script visible. This
seems better when you don't want the data public but you need to be able to
reveal the data when the time comes.
Unless it is important to reveal later, it seems to me that for 80 bytes or
less OP_RETURN is still the way to go post-taproot.
On Wed, 1 Feb 2023, 04:30 Christopher Allen via bitcoin-dev, <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> 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/20230201/22b11f78/attachment-0001.html>

2023-06-07 23:06:30

- reply

📅 Original date posted:2022-03-21
📝 Original message:Hi vjudeu,
There are use cases where your following assumption is wrong: ".. and that
kind of data is useful only to the transaction maker."
No one really publishes the actual data with an OP_RETURN. They publish the
hash (typically merkle root) of that 1.5 GB of data. So the overhead is
just 32 bytes for arbitrarily large data sets. What you gain with these 32
bytes is that your hash is visible to anyone and they can verify it without
active participation of the hash publisher.
Regards,
Kostas
On Sat, Mar 19, 2022 at 9:26 PM vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > There are two use-cases for OP_RETURN: committing to data, and
> publishing data. Your proposal can only do the former, not the latter, and
> there are use-cases for both.
>
> Only the former is needed. Pushing data on-chain is expensive and that
> kind of data is useful only to the transaction maker. Also, the latter can
> be pushed on a separate chain (or even a separate layer that is not a chain
> at all).
>
> Also note that since Taproot we have the latter: we can spend by TapScript
> and reveal some public key and tapbranches. It is possible to push more
> than 80 bytes in this way, so why direct OP_RETURN is needed, except for
> backward-compatibility? (for example in Segwit commitments)
>
> There is only one problem with spending by TapScript, when it comes to
> publishing data: only the first item is the public key. If we could use
> public keys instead of tapbranch hashes, we could literally replace
> "OP_RETURN <commitment>" with "<tweakedPublicKey> <tweakedTapBranchKey1>
> <tweakedTapBranchKey2> <tweakedTapBranchKey3> ... <tweakedTapBranchKeyN>".
> Then, we could use unspendable public keys to push data, so OP_RETURN would
> be obsolete.
>
> By the way, committing to data has a lot of use cases, for example the
> whole idea of NameCoin could be implemented on such OP_RETURN's. Instead of
> creating some special transaction upfront, people could place some hidden
> commitment and reveal that later. Then, there would be no need to produce
> any new coins out of thin air, because everything would be merge-mined by
> default, providing Bitcoin-level Proof of Work protection all the time,
> 24/7/365. Then, people could store that revealed commitments on their own
> chain, just to keep track of who owns which name. And then, that network
> could easily turn on and off all Bitcoin features as they please. Lightning
> Network on NameCoin? No problem, even the same satoshis could be used to
> pay for domains!
>
> On 2022-03-16 19:21:37 user Peter Todd <pete at petertodd.org> wrote:
> > On Thu, Feb 24, 2022 at 10:02:08AM +0100, vjudeu via bitcoin-dev 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.
>
> There are two use-cases for OP_RETURN: committing to data, and publishing
> data.
> Your proposal can only do the former, not the latter, and there are
> use-cases
> for both.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> 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/20220321/73bed610/attachment-0001.html>

2023-06-07 22:51:47

- reply

📅 Original date posted:2021-04-17
📝 Original message:Indeed, it was 40 then 80 then 40 again and then 80 at the end (or
something like this.. not sure about the exact history!).
Looking forward to the proposal(s).
On Fri, Apr 16, 2021 at 11:12 PM Christopher Gilliard <
christopher.gilliard at gmail.com> wrote:
> Thanks for the feedback. Will update the 40 bytes to 80 bytes (40 bytes
> was the previous value, but it has since been updated to 80 so that's
> correct). Regarding the L2 proposal. I think the BIPs I am working on will
> address your questions and I'm hoping to have two more out early next week
> so please stay tuned. I'm open to merging those BIPs into this BIP or
> vice-versa, but for the sake of making things more readable I broke them
> down into several BIPs for the time being.
>
> On Fri, Apr 16, 2021 at 7:15 PM Kostas Karasavvas <kkarasavvas at gmail.com>
> wrote:
>
>> Hi Christopher,
>>
>> Some feedback:
>>
>> "OP_RETURN is limited to 40 bytes of data."
>> It is 80 bytes.
>>
>> "A future BIP proposing such a layer two protocol will be forthcoming."
>> So what is this BIP about? Just saying that it would be a nice idea? This
>> BIP should be the one that would go through this L2 suggestion. If one root
>> OP_RETURN substitutes all the rest it should say how that would be done...
>> where would the merkle proofs be stored, what are the trust
>> assumptions that we need to make, etc.
>>
>> "Objections to this proposal" section
>> I agree with others re hard-fork, which would be a good thing of course.
>> My main objection with this proposal is that I don't see a proposal. It
>> seems like wishful thinking... if only we could substitute all the
>> OP_RETURNs with one :-)
>>
>> We have to make sure that a proposal like this (L2, etc.) would make sure
>> that there are incentives that justify the added complexity for the users.
>> Multisig is not the only way data could be stored the wrong way; P2PK,
>> P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not good
>> enough people would start using these UTXO-bloat-heavy alternatives.
>>
>> There are a multitude of L2's (kind-of) that do this 'aggregation' of
>> data hashes using merkle trees. Factom is adding a single merkle root per
>> bitcoin block for the millions upon millions of records (of thousand of
>> users) that they keep in their network. Opentimestamps, tierion,
>> blockstacks and others do a similar thing. I have investigated several of
>> those in the past, for one of my projects, but I ended up using plain old
>> OP_RETURN because the overhead of their (L2-like) solution and trust
>> assumptions where not to my liking; at least for my use case. They were
>> pretty solid/useful for other use cases.
>>
>> Unless the proposed L2 is flexible/generic enough it would really
>> prohibit this L2 innovation that OP_RETURN allowed (see above).
>>
>>
>>
>> On Fri, Apr 16, 2021 at 4:32 PM Christopher Gilliard via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I have created a BIP which can be found here:
>>> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>>>
>>> I'm sending this email to start the discussion regarding this proposal.
>>> If there are any comments/suggestions, please let me know.
>>>
>>> Regards,
>>> Chris
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> --
>> Konstantinos A. Karasavvas
>> Software Architect, Blockchain Engineer, Researcher, Educator
>> https://twitter.com/kkarasavvas
>>
>
--
Konstantinos A. Karasavvas
Software Architect, Blockchain Engineer, Researcher, Educator
https://twitter.com/kkarasavvas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210417/6f3da8fa/attachment-0001.html>

2023-06-07 22:51:46

- reply

📅 Original date posted:2021-04-16
📝 Original message:Hi Christopher,
Some feedback:
"OP_RETURN is limited to 40 bytes of data."
It is 80 bytes.
"A future BIP proposing such a layer two protocol will be forthcoming."
So what is this BIP about? Just saying that it would be a nice idea? This
BIP should be the one that would go through this L2 suggestion. If one root
OP_RETURN substitutes all the rest it should say how that would be done...
where would the merkle proofs be stored, what are the trust
assumptions that we need to make, etc.
"Objections to this proposal" section
I agree with others re hard-fork, which would be a good thing of course.
My main objection with this proposal is that I don't see a proposal. It
seems like wishful thinking... if only we could substitute all the
OP_RETURNs with one :-)
We have to make sure that a proposal like this (L2, etc.) would make sure
that there are incentives that justify the added complexity for the users.
Multisig is not the only way data could be stored the wrong way; P2PK,
P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not good
enough people would start using these UTXO-bloat-heavy alternatives.
There are a multitude of L2's (kind-of) that do this 'aggregation' of data
hashes using merkle trees. Factom is adding a single merkle root per
bitcoin block for the millions upon millions of records (of thousand of
users) that they keep in their network. Opentimestamps, tierion,
blockstacks and others do a similar thing. I have investigated several of
those in the past, for one of my projects, but I ended up using plain old
OP_RETURN because the overhead of their (L2-like) solution and trust
assumptions where not to my liking; at least for my use case. They were
pretty solid/useful for other use cases.
Unless the proposed L2 is flexible/generic enough it would really prohibit
this L2 innovation that OP_RETURN allowed (see above).
On Fri, Apr 16, 2021 at 4:32 PM Christopher Gilliard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have created a BIP which can be found here:
> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>
> I'm sending this email to start the discussion regarding this proposal. If
> there are any comments/suggestions, please let me know.
>
> Regards,
> Chris
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Konstantinos A. Karasavvas
Software Architect, Blockchain Engineer, Researcher, Educator
https://twitter.com/kkarasavvas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210416/7a11fc7d/attachment.html>

2023-06-07 18:18:23

- reply

📅 Original date posted:2019-05-27
📝 Original message:On Sun, May 26, 2019 at 5:07 PM Aymeric Vitte via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I realized recently that my segwit implementation was not correct,
> basically some time ago, wrongly reading the specs (and misleaded by
> what follows), I thought that scriptsig would go into witness data as it
> was, but that's not the case, op_pushdata is replaced by varlen
>
> Now reading correctly the specs, they seem to be not totally correct,
> then the first question is: why OP_0 is 00 in witness data and not 0100?
> Does this apply to other op_codes? This does not look logical at all
>
>
op_pushdata allows for unsigned integers and thus it uses the extra byte to
specify that.
A varint (varlen) is unsigned. 0 and anything <= 252 is one byte length,
so 00.
> The second question is: why for non segwit inputs there is a 00 length
> in segwit data, what is the rational for that? It should just be nothing
> since you don't need this to reconciliate things
>
>
Because you don't have the number of witnesses as you have for
inputs/outputs. The witness data length is assumed to be the same as the
inputs length. And then for non-segwit inputs you need the 00 to specify
that it is empty.
Hope that helps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190527/b1ee6569/attachment.html>