Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

[Greg Sanders via bitcoin-dev]

Hello Joost, David,

Thanks for the link to my ln-symmetry draft David. I'd also be curious as
to the usage you have in
mind Joost.

It's probably helpful to cite the most recent discussions on the topic,
which is probably
https://github.com/bitcoin-inquisition/bitcoin/pull/22 , where
bitcoin-inquisition has included
the `annexcarrier` option. I have a particular use for APO-enabled payment
channel designs
that doesn't require consensus meaning, so some effort was put in to try
something out there.

Attempting to summarize the linked PR:

I think the biggest remaining issue to this kind of idea, which is why I
didn't propose it for mainnet,
is the fact that BIP341/342 signature hashes do not cover *other* inputs'
annex fields, which we
briefly discussed here
https://github.com/bitcoin-inquisition/bitcoin/pull/22#discussion_r1143382264
.

This means that in a coinjoin like scenario, even if the other joining
parties prove they don't have any
crazy script paths, a malicious party can make the signed transaction into
a maximum sized transaction
package, causing griefing. The mitigation in the PR I linked was to limit
it to 126 bytes, basically punting
on the problem by making the grief vector small. Another solution could be
to make annex usage "opt-in"
by requiring all inputs to commit to an annex to be relay-standard. In this
case, you've opted into a possible
vector, but at least current usage patterns wouldn't be unduly affected.
For those who opt-in, perhaps the first
order of business would be to have a field that limits the total
transaction weight, by policy only?

Some logs related to that here:
https://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7bb

Related discussion on possible BIP118 modifications to mitigate this in
tapscript-spending circumstances:
https://github.com/bitcoin-inquisition/bitcoin/issues/19

Anyways, curious to hear what people think and want to make sure everyone
is on the same page.

Best,
Greg

On Fri, Jun 2, 2023 at 9:08 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote:
> > the benefits of making the annex available in a
> > non-structured form are both evident and immediate. By allowing
> > developers to utilize the taproot annex without delay, we can take
> > advantage of its features today,
>
> Hi Joost,
>
> Out of curiosity, what features and benefits are available today?  I
> know Greg Sanders wants to use annex data with LN-Symmetry[1], but
> that's dependent on a soft fork of SIGHASH_ANYPREVOUT.  I also heard you
> mention that it could allow putting arbitrary data into a witness
> without having to commit to that data beforehand, but that would only
> increase the efficiency of witness stuffing like ordinal inscriptions by
> only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be
> required to create an output in order to spend it.
>
> Is there some other way to use the annex today that would be beneficial
> to users of Bitcoin?
>
> -Dave
>
> [1]
>
> https://github.com/lightning/bolts/compare/master...instagibbs:bolts:eltoo_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800ae2R119
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

[David A. Harding via bitcoin-dev]

On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote:

the benefits of making the annex available in a
non-structured form are both evident and immediate. By allowing
developers to utilize the taproot annex without delay, we can take
advantage of its features today,


Hi Joost,

Out of curiosity, what features and benefits are available today?  I 
know Greg Sanders wants to use annex data with LN-Symmetry[1], but 
that's dependent on a soft fork of SIGHASH_ANYPREVOUT.  I also heard you 
mention that it could allow putting arbitrary data into a witness 
without having to commit to that data beforehand, but that would only 
increase the efficiency of witness stuffing like ordinal inscriptions by 
only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be 
required to create an output in order to spend it.


Is there some other way to use the annex today that would be beneficial 
to users of Bitcoin?


-Dave

[1] 
https://github.com/lightning/bolts/compare/master...instagibbs:bolts:eltoo_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800ae2R119

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] Bitcoin mail list needs an explicit moderation policy

[Bryan Bishop via bitcoin-dev]

Hi Maxim,

This is exceedingly boring. This is not a good use of your time. There are
thousands of developers subscribed to this mailing list, and we should not
waste their time, including this discussion.

On Fri, Jun 2, 2023 at 6:44 PM Dr Maxim Orlovsky via Lightning-dev <
lightning-...@lists.linuxfoundation.org> wrote:

> What happened next was very unexpected. I am giving the core of the
> conversation over Twitter after in Annex A - with the purpose to showcase
> the problem I’d like to address in this e-mail. From the discussion, it is
> clear that bitcoin-dev mail list lacks clear explicit moderation (or
> peer-review) policies, which must be applied on a non-selective basis.
> Also, Bryan Bishop, as the current moderator, had abused his powers in
> achieving his agenda based on personal likes or dislikes. The conversation
> went nowhere, and the post got published only after a requirement from
> Peter Todd [9].
>

What exactly is the abuse being alleged here though? Why would it be
surprising that your tweets didn't get the behavior you wanted out of me?
In general mailing list moderators should not be sending items through
based on twitter mobbing, that's a policy you can consider if you want to
think about policies.

Annex A:
>
>- @kanzure just like to check that our submission to bitcoin-dev
>hasn’t got to spam <
>
> https://twitter.com/lnp_bp/status/1664649328349069320?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>- A few mods are reviewing it <
>
> https://twitter.com/kanzure/status/1664680893548572677?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>- Oh, so a peer review is required to get to bitcoin-dev mail list?
>Never read about that requirement anywhere <
>
> https://twitter.com/lnp_bp/status/1664695061462777858?s=61=9A8uvggqKVKV3sT4HPlQyg>.
>Seems like bitcoin-dev mail list requirements are now specific to the
>author :) <
>
> https://twitter.com/dr_orlovsky/status/1664695668475142144?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>- Not the greatest email to pull this over. I'll double check but
>pretty sure the antagonization is boring me. <
>
> https://twitter.com/kanzure/status/1664705038315409420?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>- Not sure I understand what you are saying. Can you please clarify? <
>
> https://twitter.com/dr_orlovsky/status/1664705280393859103?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>- You are boring me and these antics don't make me want to go click
>approve on your email. <
>
> https://twitter.com/kanzure/status/1664705509147004946?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>
>
Excluding your (and my) other tweets and any other collaborators' tweets
from your report is kind of weird. I think you should include the other
tweets that you were sending me because it provides context. Zooming out,
the entirety of your complaint seems to be about moderation queue latency
and delay. Why would you, or anyone, allege that that moderator latency is
indicative of me specifically not liking you? Wouldn't it be more likely
that the other moderators and I are looking at your email and talking with
each other asynchronously about whether to suggest edits/reject/submit?

I suspect you may be attributing malice to me because I recently asked you
to stop tagging me on quantum woo and you might have taken that negatively
- please keep in mind that not everyone believes in quantum consciousness
or is interested in hearing about it, and it's okay for people like me to
not want to engage on each of your different interests. There is some
overlap in our interests outside of crypto, but that isn't one of them. I
noticed some odd tweets from you to me after that, so that's why that
incident came to my mind as a possible explanation for this.

Thank you.

- Bryan
https://twitter.com/kanzure
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin mail list needs an explicit moderation policy

[Dr Maxim Orlovsky via bitcoin-dev]

Dear community,

I am writing this list to bitcoin-dev mail list, but to prevent potential 
censorship I am sending CC to lightning-dev mail list, in order to leave the 
current moderator(s) without an option not to publish the letter and not to 
leave the topic “under the cover” (sorry Lightning friends for spamming your 
list with this off-topic).

A day before yesterday I sent a post to bitcoin-dev referencing the publication 
of the new Bitcoin scalability and privacy protocol, which had already received 
a broad reaction across the bitcoin community with literally no 
critical/negative responses after ~25k of reads [1]. I am not the first-time 
writer to the mail list and had developed things like RGB smart contracts [2], 
rust lightning implementation named LNP [3], multiple bitcoin libraries and 
software [4], [5], during three years was a main contributor to rust-bitcoin 
[6] etc, etc. The post was clearly not spam and received support from known 
community members like Giacomo Zucco [7]. Bryan Bishop knows me since 2019 when 
I was presenting Storm protocol on the stage on Scaling Bitcoin in Tel Aviv - 
and he was writing a transcript of it [8]. Thus, I am not a random unknown guy 
or a known spammer - and the post can be easily checked for not containing any 
scam promotion.

Nevertheless, I next day I see other e-mails getting released to bitcoin-dev, 
while mine - was not. It is not a problem, but since we already had an incident 
in the past where Bryan reported the failure of his software, me and my 
colleagues from LNP/BP Standards Association started asking questions about 
whether this post ever got to Bryan.

What happened next was very unexpected. I am giving the core of the 
conversation over Twitter after in Annex A - with the purpose to showcase the 
problem I’d like to address in this e-mail. From the discussion, it is clear 
that bitcoin-dev mail list lacks clear explicit moderation (or peer-review) 
policies, which must be applied on a non-selective basis. Also, Bryan Bishop, 
as the current moderator, had abused his powers in achieving his agenda based 
on personal likes or dislikes. The conversation went nowhere, and the post got 
published only after a requirement from Peter Todd [9].

In this regard, I’d like to propose the following:

- The bitcoin-dev mail list must have a clear moderation (or pre-publication 
peer-review policy). It can be proposed and discussed in this mail list and, 
upon agreement, must become public and obligatory.
- Bryan Bishop, who was acting for a long time as moderator, must be 
appreciated for many years of unpaid work, and replaced with the new moderator 
who should be selected from a list of potential candidates (again in this mail 
list) using the criteria “least votes against”.
- The role of the moderator(s) must be purely executive of the policies, 
without any personal preferences.
- A dedicated mail list should be created (“bitcoin-dev-unmoderated”) which 
will publish all submissions without moderation. It may contain spam and only 
people interested in the auditing bitcoin-dev main mal list non-censorship will 
be reading it. However, if they will notice that some non-spam e-mails were 
censored, they can announce that publicly. In this case, the failing 
moderator(s) should be removed and replaced.
- The incentive to work as a moderator should be reputation-based.

With that, I rest my case.

Kind regards,

Maxim Orlovsky

[1]:https://twitter.com/lnp_bp/status/1664329393131364353?s=61=9A8uvggqKVKV3sT4HPlQyg

[2]:https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021554.html

[3]:https://github.com/LNP-WG

[4]:https://github.com/BP-WG

[5]:https://github.com/mycitadel

[6]:https://github.com/rust-bitcoin/rust-bitcoin/graphs/contributors?from=2018-12-31=2022-04-12=c

[7]:https://twitter.com/giacomozucco/status/1664515543154544645?s=61=9A8uvggqKVKV3sT4HPlQygandhttps://twitter.com/giacomozucco/status/1664731504923095041?s=61=9A8uvggqKVKV3sT4HPlQyg

[8]:https://scalingbitcoin.org/transcript/telaviv2019/wip-storm-layer-2-3-storage-and-messaging

[9]:https://twitter.com/peterktodd/status/1664742651835367424?s=61=9A8uvggqKVKV3sT4HPlQyg

Annex A:

- @kanzure just like to check that our submission to bitcoin-dev hasn’t got to 
spam 

- A few mods are reviewing it 

- Oh, so a peer review is required to get to bitcoin-dev mail list? Never read 
about that requirement anywhere 
.
 Seems like bitcoin-dev mail list requirements are now specific to the author 
:) 

- Not the greatest email to pull this over. I'll double check but pretty sure 
the antagonization is boring me. 

[bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation

[Dr Maxim Orlovsky via bitcoin-dev]

Dear community,

Some time ago we (LNP/BP Standards Association) announced the release of RGB 
smart contract system [1]. In the subsequent discussion, we have referenced [2] 
that the introduction of client-side validation has the potential for upgrading 
Bitcoin layer 1 - blockchain, which has become an unnecessary limiting factor 
for the Bitcoin ecosystem, creating both scaling and privacy problems. While 
client-side validation requires consensus protocol and some layer 1 (for the 
proof of publication), this layer can be implemented in a more efficient way 
than the Bitcoin blockchain.

Today we are glad to present Prime: a proposal to upgrade Bitcoin protocol with 
the new scalable (up to billions of tx per minute) and fully anonymous (opaque) 
layer 1, moving most validation work into the client-side validation system. It 
leaves BTC (Bitcoin as money) and the rest of the Bitcoin ecosystem (including 
PoW) intact. It may be deployed without a softfork and miners upgrade, but can 
certainly benefit from it. It doesn't affect those users who are not willing to 
upgrade and doesn't require any consensus or majority for the initial 
deployment. It also makes Lightning Network and other layer 2 systems 
redundant. Finally, it will make things like BRC20, inscriptions, ordinals etc. 
impossible; all proper assets, NFTs etc. will be done with RGB smart contracts, 
not forcing non-users to store, validate and use their network bandwidth for 
the unpaid third-party interests.

The white paper describing the proposal can be found here:
https://github.com/LNP-BP/layer1/

As LNP/BP Standards Association we are setting a working group which will be 
focused on formal specification and reference implementation of this new layer 
- and will gladly accept everybody who wishes to cooperate on this topic. We 
also plan educational and workshop activities to make community understand the 
underlying technology better and take educated decision on its adoption.

We believe that this infrastructural effort must not be managed by a for-profit 
company - or a commercial group with its interests, and the only proper way of 
funding such an effort should be through non-profit donations. We do plan a 
fundraising campaign, so everyone interested in driving the Bitcoin evolution 
forward please contact us at ukolova [at] lnp-bp.org. For-profit organizations 
can also become members of the Association [3] and get to the committees 
defining the shape of the future Bitcoin technologies.

Dr Maxim Orlovsky
on behalf of LNP/BP Standards Association
https://lnp-bp.org/
GitHub: github.com/LNP-BP
Twitter: @lnp_bp
Nostr: npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym

[1]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021554.html
[2]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021577.html
[3]: https://www.lnp-bp.org/membership___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Standardisation of an unstructured taproot annex

[Joost Jager via bitcoin-dev]

Hi,

As it stands, the taproot annex is consensus valid but non-standard. The
conversations around standardization seem to be leaning towards the
adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt
that this approach has considerable potential. However, settling on an
exact format may require a significant amount of time.

In the interim, the benefits of making the annex available in a
non-structured form are both evident and immediate. By allowing developers
to utilize the taproot annex without delay, we can take advantage of its
features today, without the need to wait for the finalization of a more
lengthy standardization process.

With this in view, I am proposing that we define any annex that begins with
'0' as free-form, without any additional constraints. This strategy offers
several distinct benefits:

Immediate utilization: This opens the door for developers to make use of
the taproot annex for a variety of applications straight away, thus
eliminating the need to wait for the implementation of TLV or any other
structured format.

Future flexibility: Assigning '0'-beginning annexes as free-form keeps our
options open for future developments and structure improvements. As we
forge ahead in determining the best way to standardize the annex, this
strategy ensures we do not limit ourselves by setting its structure in
stone prematurely.

Chainspace efficiency: Non-structured data may require fewer bytes compared
to a probable TLV format, which would necessitate the encoding of length
even when there's only a single field.

In conclusion, adopting this approach will immediately broaden the
utilization scope of the taproot annex while preserving the possibility of
transitioning to a more structured format in the future. I believe this is
a pragmatic and efficient route, one that can yield substantial benefits in
both the short and long term.

Joost

[1] https://github.com/bitcoin/bips/pull/1381
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Vaults in the MATT framework

[Johan Torås Halseth via bitcoin-dev]

Hi,

It was briefly mentioned in the original post, but wanted to show how
simple it is to use COCV as an alternative to CTV, removing that
dependency.

> In particular, it also inherits the choice of using OP_CTV as a primitive,
> building on top of the bitcoin-inquisition's current branch that has already
> merged OP_CTV. Reasonable vaults would be possible without CTV, but they
> would be less efficient, particularly in the case of sending to many addresses
> in a single unvaulting flow.

Instead of specifying a CTV hash as embedded data, one could embed the
(commitment to the) outputs of the withdrawal transaction. Then
instead of a single OP_CTV, one OP_COCV per output to match against
the embedded data. Less efficient in case of many outputs as you
mention, but simple enough to be interesting.

Here's an example how to use MATT as a CTV replacement:
https://github.com/halseth/tapsim/blob/b07f29804cf32dce0168ab5bb40558cbb18f2e76/examples/matt/ctv2/README.md

Cheers,
Johan



On Tue, May 2, 2023 at 10:22 AM Salvatore Ingala via bitcoin-dev
 wrote:
>
> Hi Michael,
>
> I can't make any claim of expertise on the field (especially on the
> other proposals that you mentioned), so this post necessarily includes
> my opinions − and possibly my biases.
>
> The core functionality of MATT is quite simple, and could be adapted
> to any version of the scripting system: basically, COCV allows to
> "embed" some data in the next output, and decide its script; CICV
> allows "reading" this data.
> The design I proposed on taproot is surely not the only possible way,
> but it's the most simple/elegant I could come up with. Moreover, it
> doesn't seem very useful to spend time trying to get it to work on
> pre-taproot Script, due to the obvious advantages of those ideas when
> deployed on taproot (like having taptrees, and all the nice properties
> of Schnorr signatures).
>
> CICV/COCV can certainly be considered an additional form of
> introspection: you're checking that the script of an input/output
> equals a certain value, which is not possible in today's Script.
> I think that's generally true for all covenant proposals.
>
> Unlike some other proposals, MATT is not yet fully formalized, so I
> generally call "MATT" the combination of CICV+COCV, plus some other
> small set of opcodes that is yet to be defined exactly. I would say it
> fits in the same family as APO/OP_CTV/OP_VAULT, per your bucketization.
>
> The previous posts about MATT, fraud proofs, etc. are an exploration of
> the deeper things that are enabled by the MATT opcodes. The claim is
> that a set of changes that is (arguably) quite small and easy to analyze
> is enough to express general smart contracts − thanks to fraud proofs.
> However, fraud proofs themselves are a quite advanced application of
> the new opcodes, and are not needed for most/all of the things that
> people are trying to build today with the other covenant proposals.
>
>
> Since you mention Simplicity: my current understanding is that its
> endeavour of replacing Script with a better language is orthogonal to
> the discussion about what features (e.g.: introspection, covenants)
> should be in the language.
>
> All the covenant proposals listed above are technically a lot smaller
> and easier to audit than both the SegWit and the Taproot soft forks,
> both in terms of code and conceptual complexity.
>
> Therefore, if we _do_ want the features that they enable, the required
> engineering for a soft-fork is relatively straightforward, and there is
> not much of a reason to wait for Simplicity. It will be trivial to "port" any
> constructions we might create today with covenants to Simplicity scripts.
>
> If we _do not_ want those features, then the decision would rather be
> guided by other considerations, like potential risks to bitcoin caused
> by the effect of those features on miners' incentives. These
> concerns are not answered by Simplicity, as far as I understand:
> you would then want to implement Simplicity _without_ those features.
>
> Best,
> Salvatore
>
> On Mon, 1 May 2023 at 16:18, Michael Folkson  
> wrote:
>>
>> Hi Salvatore
>>
>> Can you clarify for me which bucket this proposal sits? We have APO, CTV, 
>> OP_VAULT etc that are proposals to add additional functionality to SegWit 
>> version 1, Tapleaf version 0 scripts. We have Simplicity that would need a 
>> new Tapleaf version (e.g. Tapleaf version 1). And then there are CISA like 
>> proposals that would need a new SegWit version (e.g. SegWit version 2). It 
>> looks to me like your proposal is in the first bucket (same as APO, CTV etc) 
>> as it is just introducing new opcode functionality to existing script with 
>> no deeper introspection needed but previous and current discussion of fraud 
>> proofs, MATT frameworks etc made me initially think it was going to require 
>> more than that.
>>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> GPG: