Nostr notes by

📅 Original date posted:2023-06-02 🗒️ Summary of this ...

2023-06-08T01:22:10+02:00

In reply to nevent1q…xumn
_________________________

📅 Original date posted:2023-06-02
🗒️ Summary of this message: A proposal for clear moderation policies on the bitcoin-dev mail list and the replacement of the current moderator, who has been accused of abusing their powers.
📝 Original message: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&t=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&to=2022-04-12&type=c

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

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

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

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&t=9A8uvggqKVKV3sT4HPlQyg>;
- A few mods are reviewing it <https://twitter.com/kanzure/status/1664680893548572677?s=61&t=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&t=9A8uvggqKVKV3sT4HPlQyg>;. Seems like bitcoin-dev mail list requirements are now specific to the author :) <https://twitter.com/dr_orlovsky/status/1664695668475142144?s=61&t=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&t=9A8uvggqKVKV3sT4HPlQyg>;
- Not sure I understand what you are saying. Can you please clarify? <https://twitter.com/dr_orlovsky/status/1664705280393859103?s=61&t=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&t=9A8uvggqKVKV3sT4HPlQyg>;
- Are you the person to approve emails for it? <https://twitter.com/phyrooo/status/1664732932068589568?s=61&t=9A8uvggqKVKV3sT4HPlQyg>;
- Yes <https://twitter.com/kanzure/status/1664733107096899585?s=61&t=9A8uvggqKVKV3sT4HPlQyg>;
- It appears that people boring @kanzure is going through a dedicated review procedure on bitcoin-dev mail list. Good moderation! Very clear policy! <https://twitter.com/dr_orlovsky/status/1664706165790461959?s=61&t=9A8uvggqKVKV3sT4HPlQyg>;
- What are you even doing. How does this behavior suppose to get people to help you? <https://twitter.com/kanzure/status/1664706931083329536?s=61&t=9A8uvggqKVKV3sT4HPlQyg>;
- I am not expecting you to help me - and never asked. I expect you to openly declare moderation (or peer review) policy and follow it. <https://twitter.com/dr_orlovsky/status/1664719295123685381?s=61&t=9A8uvggqKVKV3sT4HPlQyg>; Since “if you get me bored I will not click an accept button” is not a moderation policy which I expect from bitcoin-dev mail list. Probably not just me. <https://twitter.com/dr_orlovsky/status/1664719786633310209?s=61&t=9A8uvggqKVKV3sT4HPlQyg>;
- Yeah I mean I don't think these tweets are likely to get me to enthusiastically resolve your problem... I dunno man. What's even going on here. <https://twitter.com/kanzure/status/1664735139065208833?s=61&t=9A8uvggqKVKV3sT4HPlQyg>;
- Bitcoin mail list clearly lacks explicit moderation policy. The same mistake like with rust-bitcoin 1+ yrs ago. I am fine with peer review. Moderation. But only explicit - not just “the way I (dis)like this guy” <https://twitter.com/dr_orlovsky/status/1664736404931321859?s=61&t=9A8uvggqKVKV3sT4HPlQyg>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230602/f0fd6794/attachment-0001.html>;

📅 Original date posted:2023-04-17 🗒️ Summary of this ...

2023-06-08T01:20:27+02:00

In reply to nevent1q…jl70
_________________________

📅 Original date posted:2023-04-17
🗒️ Summary of this message: The author thanks the recipient for their analysis and addresses small questions. They clarify the status of RGB implementations and mention documentation efforts.
📝 Original message:Hi David,

Thank you for taking time on doing analysis and writing comments.
I will address all small questions in this reply -- with a follow-up
e-mail dedicated to the technical question from your letter
regarding the problem of "on-publishable conditional statements seemingly
being insecure in multiparty protocols", which requires longer write-up.

> FYI: the RGB-WG organization page links to a repository whose latest
> release is 0.9 and whose latest commit is titled, "Release v.0.9.1", see
> https://github.com/RGB-WG/rgb-node/

Thank you for spotting; we hadn't updated the readme. Now its fixed.

> > Nevertheless, in 2021 we were able to present both RGB powered with a
> > Turing-complete virtual machine (AluVM) [2] and RGB had became
> > operational on
> > Lightning Network [3] using the LNP Node - a complete rust
> > re-implementation of
> > the Lightning protocol made by me at the Association [4].
>
> Could you clarify the status of these implementations?

The status of LNP implementation is "experimental": it is an instrument
for testing new protocols in the scope of the Lightning network, and
its main feature is in having lightweight and modular architecture.

LNP implementation is not anymore required for using RGB on LN - as
Federico already mentioned in his reply, Bitfinex team was able to
independently integrate RGB with existing LDK codebase [1] (I even
didn't know about that before they announced), and there is a WIP on
integrating RGB through CLN extensions. So the question of LNP node
readiness/completeness is unrelated to the question of RGB readiness,
features or technical properties; in my previous e-mail I just had
pointed out that at some (past) point in time we had to work on LN
re-implementation due to some restrictions we had back those days --
like with pay-to-contract commitments which were impossible to
implement in the existing nodes due to architecture limitations --
but with the change to taproot-based commitments in late 2021-
early 2022 this is not true anymore.

> While trying to
> learn about RGB, I noticed that you don't have much completed
> documentation. Previous reviewers also mentioned this and I saw that
> you suggested them to read the code or view your videos.

A lot of documentation was written and is being written. For instance,
if you look at the foundational crates we have in RGB, they are
well documented, containing more docs than the code itself, like in
<https://github.com/LNP-BP/client_side_validation/blob/master/single_use_seals/src/lib.rs>;

Also, we have a number of websites tracking the RGB docs, listed in
<https://rgb.tech/docs/>; and <https://rgb.tech/learn/>; - literally
dozens of them. So your information is outdated.

Of course, much more need to be written - but again, for a small team
of community & self-fundend non-profit with the budget comparable to
a coffee shop. I think we are doing all what we can. If community
needs more docs -- it is welcome to provide more funding or hands in
writing them.

> When reading your code for your LN implementation (LNP), I noticed it
> seemed to be missing a lot of things present in other LN implementations
> I regularly review. For example, I can't find where it supports
> creating or parsing onions, which seems to be a fundamental requirement
> for using LN.

It is there, literally for years, where it should be - in P2P protocol,
BOLT4, as directory and file names suggest:
<https://github.com/LNP-WG/lnp-core/blob/master/lnp2p/src/bolt/bolt4.rs>;

It is based on our other library which provides encryption:
<https://docs.rs/internet2/0.9.0/internet2/presentation/sphinx/index.html>;

> In trying to figure out how it works, I also noticed that
> I couldn't find either unit tests or integration tests---indeed several
> of your applications seem to almost entirely lack the string "test".
> For example, here are LNP-node and RGB-node compared to the four LN
> implementations I regularly monitor:
>
> /tmp/rgb-node$ git grep -i '\<test\>' | wc -l
> 7

RGB Node is not a part of the current RGB release -- starting from
v0.10 RGB do not require a background service. The node is still useful
in server-side environments - but 100% of mobile and most of desktop
users and wallet devs would never need to touch it; thus the update
of the node to v0.10 will come later. Anyway, there is no reason of
doing its extensive test coverage since it its role to be a wrapper
around RGB libraries (existing in other repositories) which contain
100% of RGB consensus and applied business logic. Node just manages
threads and file I/O - not the stuff which is test-covered first of
all (and even for that task it uses others of our libraries with a
like io-react, used in other high-load projects. (BTW pls pay
attention to how such libs are documented:
<https://docs.rs/io-reactor/0.1.2/reactor/>;).

The real RGB code is here, as it is clearly stated in the Github:
* consensus-level
- <github.com/RGB-WG/rgb-core>
- <github.com/BP-WG/bp-core>
- <github.com/LNP-BP/client_side_validation>
* integration libraries - <github.com/RGB-WG/rgb-wallet>

With the update to v0.10 a lot of code was changed, so most of tests
got outdated and were thrown out. Yes, we need more time and
effort to re-do them -- but even taking that into the account,
the core of RGB is covered to much greater extent than the estimations
you have provided:
* client-side-validation library - 80%:
<https://app.codecov.io/gh/LNP-BP/client_side_validation>;
* RGB Core - ~25% (due to significant re-write in v0.10)
<https://app.codecov.io/gh/RGB-WG/rgb-core>;

Finally, the most of code coverage happens due to the used
strict types system [4], which does compilation-type verification
of all data serialization, deserialization and semantic type system.
I.e. with its taken into account, the actual code coverage exceeds
2/3 (>60%). I provide more explanations at the end of the letter.

> /tmp/lnp-node$ git grep -i '\<test\>' | wc -l
> 4
>
> ~/repos/rust-lightning$ git grep -i '\<test\>' | wc -l
> 2008
> ~/repos/cln$ git grep -i '\<test\>' | wc -l
> 1459
> ~/repos/lnd$ git grep -i '\<test\>' | wc -l
> 3547
> ~/repos/eclair$ git grep -i '\<test\>' | wc -l
> 2576

Well, that's a strange way to estimate the code coverage by counting
lines with the word "test". I usually use code coverage reports, like
those coming from codecov.com -- since neither count of unit tests nor
code lines in them are a valid metric to see how the code is
test-covered.

Unlike all those implementations, the node repository doesn't contain
any lightning network business logic or protocols - it is just a "shell"
providing I/O, networking and thread management, not requiring much
testing. Instead, one should look into the actual LNP codebase
implementing BOLT standards, which is in
<https://github.com/LNP-BP/lnp-core>;. And as one might see from test
coverage reports [2] it has 40% of all code covered in tests - which
is not huge, yes, but (see next reply)...

> I realize those are all projects by larger teams than that which works
> on RGB, but a difference of three orders of magnitude is very surprising
> to me. Do you have out-of-tree testing or am I missing something else?

... as I pointed above, there is no "three orders of magnitude" difference
if the comparison is done correctly. Of course mainstream implementation
developed for more than 5 years, with millions invested by large companies/
non-profits and full teams of devs will have more test coverage than
an implementation created at my own personal expense - and I do not
understand what is surprising here :) I wrote about this implementation
to attract more interest from the community devs who may be interested
in joining to work/use an independent lightning re-implementation with
more open architecture allowing much larger protocol-level customizations
than any other mainstream implementation out there.

> As your replies to previous reviewers also mentioned that they should
> view your Youtube videos, I also tried that.

I had never replied to previous _reviewers_ like that. For instance, the
protocol was reviewed by Peter Todd and Federico Tenga, as well as by
other devs from the community, and I am sure they can confirm that the
communications were complete and I was providing all the required answers
and comments. If you are talking about Ruben Somsen, he was never
introduced to me as a reviewer, nor wrote to me anything other than
several sarcastic tweets -- and I rather see him as an internet troll,
who, notwithstanding verbal communications and explanations I
had provided him over phone call, continues to spread miss-information
positioning himself as "RGB expert" -- while still demonstrating absence
of desire of reading any recent updates we had even when provided links.

> I focused on the ones
> discussing LNP, as LN is something I know fairly well,

But this discussion is an offtopic to RGB and this letter. I am fine to
have it, but let's move it to a separate thread.

> I skimmed them quite fast, but I couldn't find any demos where you
> progressed beyond using LNP to open a channel with another node. E.g.,
> they seemed to stop at the same point as this demo:
> https://github.com/LNP-WG/lnp-node/blob/c402decc9ff5b557a9e3d542f74e2fd6ed856742/doc/demo-alpha.4/README.md

The current LNP Node version is v0.9, so v0.4-alpha is extremely outdated,
as well a doc there. For sure the doc needs an update. These are more
recent demos of node operations, with a remote CLN node as of end of 2021:
* https://youtu.be/DoNfKLLjzsY
* https://youtu.be/L6JlIQXbl6Y

> My understanding of the basic goal of RGB from years ago was that it
> would allow ordinary users to define new assets on Bitcoin in a way that
> would allow those assets to be transferred over LN. As far as I can
> tell, it doesn't do that yet, not even in a way that's accessible to a
> power user such as myself.

I do not know how to compare the power of users, but, for instance it
was successfully demonstrated by an independent Bitfinex team using BDK
and LDK last month on the stage of Lightning Tuscany Summit. Of course
there yet no fancy UI all around, but absence of UI says nothing about
technology or its readiness. In fact, several teams are working on the
first UI apps using RGB, so this thing will change - and it is not a
task for a non-profit protocol-level research organization, but rather
for commercial ventures.

> Even for that original goal, there are
> several problems outstanding---problems which will likely require
> significant research and experimentation to overcome, e.g.[2].
> Instead of tackling those problems and building upon existing wallet and
> LN libraries, I see an ambitious effort at reimplementation and massive
> scope creep.

Sorry for not meeting your expectations about how I should use my time,
funds and funds of those who support such developments :)

The real part of the story is that 80% of the time we were working
on solving the original scope you pointed out. It just appeared that
there were much more hidden stones (than was expected back in 2018)
in doing the idea of "assets over Lightning":
* the original single-use-seals didn't worked for the world of multiple
assets which may co-exists, which required development of a set of
quite complex protocols (still being probably most complex part
of RGB);
* the original pay-to-contract commitment scheme did work badly on
practice, being poorly inter-operable with existing lightning
implementations (which took a year of work on LNP node in total,
as I mentioned above) and leading to hard problems in wallet
integration and compatibility with all existing frameworks. We were
solving that problem until Taproot had arrived - and then we switched
to Taproot-based commitment scheme. It took another half of year
to update the whole code base - but the reward was compatibility
with BDK, LDK and other existing tools in the ecosystem, so your
comment on "Instead of tackling those problems and building upon
existing wallet and LN libraries" is not valid;
* as a part of the above, I had to significantly contribute to
taproot implementation and maintenance of rust-bitcoin project,
being the most active project contributor during the course of
2019-2022 [3] (="building upon existing wallet libraries);
* a lot of time was spent on privacy-related improvements, since none
of the original authors nor sponsors had seen any value about putting
"colored coins on lightning" without worriyng about the privacy;
and only after that comes some "fancy stuff", like doing a dedicated
virtual machine and rich data type system -- which primary features
were not "Turing completeness" but ability of formal verification and
compiler-time safety guarantees. For instance, the developed type
system [4] allows not just to "compile" any rust data type into a
smart contract, but also to prove that all data types used in
consensus code do not mutate between releases. If bitcoin had that
type system, there would be no "unnoticed" hardforks or risks of them
in a future -- and I think not implementing such system in doing a
new consensus protocol would be a poor decision. And the last, but
not least, I do not want to be in such situation
<https://twitter.com/fiatjaf/status/1647976362374844416?s=61&t=H4U6Q30N4eanvS4GjyAt4g>;
preferring to spend a year more on a proper design instead of
"shipping earlier". What is acceptable for networking protocols
can't be acceptable for consensus-level protocols, which, unlike
even blockchain consensus can't have softforks.

----

Overall, I am quite negatively impressed with the amount of
misinterpretations and estimates which are simply wrong - and I know
that they are being floated around working like fake news.
Unfortunately writing answers to such claims takes a lot of time -
and takes it from doing other stuff like writing docs, tests or
integrations. I understand that this letter will be read by many,
thus I did address some of most common misconceptions. I am doing
that on bitcoin-dev mail list, but not elsewhere, since if I were
doing that on Twitter I would never have time for anything else.

[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021558.html
[2]: https://app.codecov.io/gh/LNP-WG/lnp-core
[3]: https://github.com/rust-bitcoin/rust-bitcoin/graphs/contributors?from=2019-01-11&to=2022-04-11&type=c
[4]: https://www.strict-types.org

📅 Original date posted:2023-04-10 🗒️ Summary of this ...

2023-06-08T01:20:24+02:00

In reply to nevent1q…2z63
_________________________

📅 Original date posted:2023-04-10
🗒️ Summary of this message: RGB v0.10, supported by LNP/BP Standards Association and several bitcoin companies, brings smart contract support to Bitcoin and Lightning after four years of development.
📝 Original message:TL;DR
-----

LNP/BP Standards Association <https://www.lnp-bp.org>;, supported by Fulgur
Ventures, Bitfinex, Hojo Foundation, Pandora Prime, and DIBA, is happy to
announce the release of RGB v0.10 - the next significant milestone in the RGB
protocol <https://rgb.tech>; which brings full support of smart contracts to
Bitcoin and Lightning. This is the result of a great cross-industry long-term
collaboration between these bitcoin companies and more than four years of
extensive development work.

RGB v0.10 can be downloaded and installed as described on <https://rgb.tech>;
website, which also contains a number of user and developer guidelines.
RGB source code can be found on <https://github.com/RGB-WG>;

Background of RGB
-----------------

Some of you might remember the announcement of RGB protocol idea back in
2018 [1]: it was an idea of “colored coins” over Lightning by Giacomo
Zucco, based on new concepts developed by Peter Todd - client-side-validation
and single-use-seals.

In 2019 me (Maxim Orlovsky) and Giacomo Zucco formed the LNP/BP Standard
Association, aiming to bring RGB from the concept to production. The initiative
was supported by Bitfinex and Fulgur Ventures. My goal with RGB was not just to
enable assets on Lightning, but that of a much larger scope: to build a
programmability layer for Bitcoin and Lightning, which may unlock other cases
than just tokens - DAOs, decentralized identities and other things that
bitcoin itself was lacking. This took much longer than was expected, and both
myself and the LNP/BP Standards Association had gone through very turbulent
times on this road, relying on self-financing for more than a year...

Nevertheless, in 2021 we were able to present both RGB powered with a
Turing-complete virtual machine (AluVM) [2] and RGB had became operational on
Lightning Network [3] using the LNP Node - a complete rust re-implementation of
the Lightning protocol made by me at the Association [4]. Those who are
interested in the history of RGB development and our past releases may refer
to it graphical representation [5] - or navigate through years of videos and
demos on our YouTube channel <https://www.youtube.com/@LNPBP/videos>;.

Despite 4 years of active development, weekly community calls, talks on
all mainstream bitcoin-only evens and conferences, the awareness about RGB
in the bitcoin community is still very small - and some bitcoin media put
as a requirement for us to submit information about RGB to the bitcoin-dev mail
list, so that they could see the new technology that has been developed -
so here we are.

RGB v0.10
---------

Today we’d like to announce the next main milestone: **release of RGB v0.10**,
which includes consensus layer, standard library (used by wallets/exchanges
for integration) and a command-line tool.

v0.10 release is a major milestone which brings RGB further to being a
production-ready system. It introduces the last consensus-breaking changes,
aiming at keeping future RGB versions fully backward-compatible. It also unlocks
the last features that were required for implementing fully-functional smart
contracts which may be arbitrary customized by contract developers.

This release brings the support of the following features to RGB:

- ### Global state in RGB contracts
Now each RGB contract has a global state accessible by a virtual machine
and clients (wallets etc).

- ### Contract interfaces
Interfaces, introduced in this version, represent a standard way of
communicating a diverse range of smart contracts through well-defined APIs.
Interfaces can be compared to contract ABIs and ERCs in Ethereum world,
however, unlike in Ethereum, they require neither obligatory standardization
(as ERCs) nor separate distribution, being always packed together with
contracts. By using interfaces, wallets and other software can provide a
semantic-aware UI for the users for working with the contracts - and contract
developers may add more interfaces to their existing contracts over time
without the need to update the immutable contract itself.

- ### Strict type system
Strict types is a new functional data type system with provable
properties used for the RGB contract state representation and introspection.
It allows compile-time guarantees on the size of any data, simplifying RGB
operations on low-end and limited-memory devices like hardware wallets.
The whole RGB consensus layer is now compiled into strict types, which
allows formal proofs of the binary compatibility between releases (the
feature which might have been very useful for bitcoin consensus if it existed
back in the days of Satoshi). You can learn more about strict types on
<https://www.strict-types.org>;

- ### Contracts in Rust
Writing and compiling an RGB smart contracts in Rust. Thanks to the strict
types, it is also possible to compile rust data types right into RGB
contracts.

- ### State introspection
Contracts can introspect their own state in the validation code used by the
virtual machine, which unlocks the way for writing complex forms of contracts
working with bitcoin transactions, DLCs and other complex data.

- ### URL-based invoice format
Previously RGB was using Bech32m-encoded invoices, which were very long,
not human-readable and couldn't be automatically opened with most of the
software. The new format is much shorter, easier to verify by the user and
can be opened automatically as a link with a preconfigured software.

- ### WASM support
RGB standard library can run without I/O and file system access,
i.e. can operate inside a web page or a browser plugin.

- ### Tapret descriptors and custom derivation
RGB uses taproot-based OP_RETURN commitments (in short - tapret), which
require support on the descriptor level such that wallets could see the
transactions with tweaked outputs as those belonging to the wallet descriptor.
New version also introduces custom derivation indexes that prevent non-RGB
wallets from accidentally spending outputs with RGB assets (and thus -
destroying assets).

- ### Simplified dependencies
RGB consensus layer is being shipped with fewer dependencies, improving the
stability of API. We have abandoned the dependency on custom bulletproofs
implementation from Grin projects. We also do not use rust-bitcoin and
rust-miniscript due to their overall API instability and recently discovered
bugs; since RGB uses a very small subset of bitcoin functionality it is now
implemented as a part of the library with no assumptions about bitcoin
consensus layer (like those which halted rust-bitcoin powered software when
Burak's hack had happened last year).

- ### Simplified integration
Many operations that previously required multiple API calls, as well as
cross-language encoding of complex data structures now work with a
single API call. RGB contract state is represented as a JSON object and
can be serialized across different languages without a hassle.

- ### Simplified UX
Previously, to use RGB, a wallet or a user had to run the RGB Node, interface
it through RPC (or cli tool) - and use a number of other libs and command-line
tools to perform most of the operations on PSBTs etc. With the new release
this complex stack was replaced by a single library API and a command-line
tool `rgb`, which operate like a swiss knife for RGB user (and it can be
compared to the way `git` works). RGB Node still can be run by users on their
home servers, but is not obligatory for using RGB anymore.

### Migration notes

There is no migration from contracts issued on RGB v0.9 to the future versions.
All assets have to be re-issued; asset holders can contact asset issuers to
provide them with a newly re-issued contracts and assets matching the assets
from v0.9.

RGB v0.10 can be downloaded and installed as described on [https://rgb.tech]
(https://rgb.tech) website, which also contains a number of user and
developer guidelines. RGB source code can be found on https://github.com/RGB-WG

Roadmap after v0.10
-------------------

With this release the future development of the core RGB technology (at in its
consensus layer) becomes gradually ossified, as the cases of
client-side-validated systems upgrades are more complex to coordinate than
those of blockchain layer 1. Also, the normal understanding of soft-forks and
hard-forks do not apply to upgrades in layer 2 and 3. So we found a way
for backwards-compatible upgrades, which we call “fast-forwards”, where users
keep their assets issued under the older versions that can always operate and be
accepted by the users of any other future version. However, the users of a newer
version will be restricted in transferring their assets only to the users of the
same or more recent version (but they can always ask recipients to upgrade their
software). We have a number of features planned for the future fast-forwards:

- full support of bitcoin layer 1 and channel state introspection;
- inter-contract interaction;
- bulletproofs++ support;
- zero-knowledge-based optimizations of the client-side-validated history.

We're also working on the design of a layer 1 which will be perfect for the
client-side-validated applications (“how to design a blockchain today if we
knew about client-side-validation/single-use-seals”). This should be very
compact (order of one signature per block) ultra-scalable (theoretically
unlimited no of tx in a block) chain which can run systems like RGB - with
Bitcoin UTXO set migrated into RGB operating on both bitcoin blockchain and
this new chain (we code-name it “sigchain”). However, these are quite early
developments with a number of unsolved tradeoffs and challenges; if there is
an interest on this topic here we can start a different discussion thread
on the matter.

Software and integrations
-------------------------

Companies, which are a part of the LNP/BP Standards Association, as well
as other independent vendors are already working on upgrading their software
to v0.10. This includes (but not limited to):

- MyCitadel wallet (iOS, Desktop)
- Iris wallet (Android) from RGB team inside Bitfinex
- BitMask (Web browser plugin) from DIBA
- LNP Node with RGB support - lightning node from the LNP/BP Standards Association
- RGBEx.io - website listing RGB assets and contracts,
using pseudonymous credentials (public key + signatures)
- RGB Tools library - SDK based on BitcoinDevKit for RGB wallet integration
- LightningDevKit with RGB support - again by RGB team in Bitfinex
- Core Lightning RGB plugin

LNP/BP Standards Association will focus its further development activity
around these three areas:

- Completing RGB documentation, specification and helping public audits of the
technology. Right now we have a nearly-complete RGB whitepaper [6] a codified
standards [7]
- Lightning network support for complex RGB smart contracts - the thing we name
#BiFi (Bitcoin finance) [8]. It includes further development of Storm -
a decentralized data storage & messaging network on top of Lightning, that we
presented last year.
- RGB toolchain, which includes a new high-level functional smart contracting
language called Contractum (<https://www.contractum.org>;) and other tools
which will simplify the life of RGB devs.

Sources of information
----------------------

We have already witnessed some actors distributing misinformation about
non-existing products released with/on RGB even before the official releases of
some RGB components happened. Thus, we advise all media people to always check
the official sources before publishing information about the RGB protocol.

All releases and major things are being announced on:
* Official website of the protocol <https://rgb.tech>;,
community <https://rgbfaq.com>; and LNP/BP Standards Association
<https://lnp-bp.org>;.
* Twitter of the Association: <https://twitter.com/lnp_bp>;
* Community telegram channel: <https://t.me/rgbtelegram>;

Other websites are not in control of the RGB protocol developers and are not
open-source and should not be considered to be trusted sources of information.

-------------------------
Maxim Orlovsky
Mail: orlovsky [at] lnp-bp.org
Github: https://github.com/dr-orlovsky
Twitter: https://twitter.com/dr_orlovsky
PGP: EAE7 30CE C0C6 6376 3F02 8A58 6009 4BAF 18A2 6EC9

[1]: https://www.youtube.com/watch?v=xHWxtmgQP94
[2]: https://www.youtube.com/watch?v=Mma0oyiVbSE
[3]: https://www.youtube.com/watch?v=6Svmh0OQVf4
[4]: https://github.com/LNP-WG/lnp-node
[5]: https://twitter.com/dr_orlovsky/status/1640833926456307714/photo/1
[6]: https://blackpaper.rgb.tech
[7]: https://standards.lnp-bp.org
[8]: https://www.youtube.com/watch?v=DtkTE6m0zio_

📅 Original date posted:2021-02-11 📝 Original message:Hi ...

2023-06-07T20:28:27+02:00

In reply to nevent1q…ekm3
_________________________

📅 Original date posted:2021-02-11
📝 Original message:Hi Dmitry,

Thank you very much for readying and analyzing my proposal!

>> Testnet path is unhardened from this point & till the end of the
>> derivation path: no need to prevent private key leak there,
>> simplifies test software (hardened paths require private key access
>> for derivation).
>
> I believe this will reduce robustness and will add complexity to the
> test software instead. If the derivation path is hardened in 'production
> code' and is unhardened in 'test code', then: code paths that depend on
> hardened derivation may not be tested; there will be unnecessary
> code that will need to deal with 'un-hardening' the paths for test code.
<...>
> It is OK to require privkey access to hardened paths in test
> software, because the same behaviour is expected in 'production’.

You are right, agree

> It is much more robust to just change the 'purpose' part of the path,
> and leave the rest unchanged.

Not sure whether the purpose is the correct place to indicate testnet: in this case it we will have to support one testnet per each blockchain type (which is not the case). So probably we should reserve a single dedicated value for any testnet withing ``blockchain` field using hardened path as you suggested - for instance, 0xFFFFFFFF may do the job.

Kind regards,
Maxim

📅 Original date posted:2021-02-05 📝 Original message:Hi, ...

2023-06-07T20:28:26+02:00

In reply to nevent1q…82ae
_________________________

📅 Original date posted:2021-02-05
📝 Original message:Hi,

Background
==========

Had a discussion last night in Bitcoin Core IRC with Peter Wuille on different topics regarding key derivations, security, key tweaks in context of Schnorr signatures & Taproot. Would like to share some action points and plans that emerged from there:

1. There is a real need for BIP-43 based new BIP with a new purpose field for keys used in Schnorr signatures. Peter will not do it (he is not very much interested in spending his time on wallet-level stuff), so someone else should.

2. Keys used in Schnorr signatures MUST NEVER BE used in ECDSA signatures, otherwise there is a risk of private key leak via correlation attack. This is rationale behind N1.

3. The other need (not discussed with Peter) is to change the general structure of derivation path used before with BIP-44, 45, 84. This change is required to enable the use of all modern wallet use cases under a single standard: single-sigs & multi-sigs, ECDSA & BIP340 signatures.

4. Embedding multisig support in a hierarchical format requires introduction of a “signer id” concept as a part of the derivation path. I found a way how this can be done seamlessly, leading to emergence of decentralized identity as a side effect.

Proposal
========

Derivation path structure & purpose values
------------------------------------------

The new format for the hierarchical derivation BIP32 path is the following:

m/purpose’/blockchain’/identity’/scope'/case/index

**Purpose:**
BIP-43 purpose values under the proposal:
- 340’ for BIP340 signatures
- ???’ for old-style ECDSA signatures (??? will be set to the BIP number of this standard once it gets assigned)
Thus, purpose will be used to signify the type of the signature.
NB: purpose MUST be hardened since otherwise a key leak may occur.

**Blockchain:**
was not there before, but now we should have it:
- to prevent key reuse across blockchains & combined inter-chain analysis
- to get rid of using custom xpub prefixes (like SLIP-132) which are very unwelcomed by the community and are unnecessary since we have descriptors.

Testnet path `1` covers all testnets (no problem with key re-use for valueless testnet or inter-testnet chainanalysis) - this follows the logic of recent changes in other standards related to testnet (use the same Bech32 prefixes for all testnets).

Testnet path is unhardened from this point & till the end of the derivation path: no need to prevent private key leak there, simplifies test software (hardened paths require private key access for derivation).

Devs are free to choose other unhardened number if they need, without changing the standard - unhardened numbers will never be used for chains with real value.

**Identity and scope**
Hardened components signify the main identity (decentralized id) and the scope under that id used in context of specific multisig wallet or other identity case. Scope is required to use the same id with different peers without exposing the main identity xpub (and, thus, the scope must be hardened as well).

**Case**
This is the same as a “change” field before (under BIP44 etc), however it is proposed to change the name to denote that the field may have other values and is used for signalling support for some custom features (for instance, pay-to-contract or sign-to-contract schemes, which may be used for client-side validation like in RGB protocol etc).

**Index**
Sequentially increased index like in BIP44

Identity basics
---------------

**Identity index** SHOULD be a random number within BIP32 hardened index range.

Rationale: derivation path may be kept public (see decentralized logins below), and use of sequential numbers will leak information of how many identities are used by some person.

**(Identity) scope index**: depending on whether revocation is enabled:
- if revocation is not enabled, or before the first revocation, it SHOULD be any random hardened number
- otherwise, it must be a number provided during the revocation procedure for the previous scope

Rationale for identity scope: it is required for an identity to be safely usable under multiple multisig wallets/descriptors without exposure of the identity xpub to unrelated parties. Its introduction also allows to use the keys derived under the same identity index as a universal decentralized identity (see details below) without the risk of correlation analyses; especially when they are used outside of the transaction context (for instance as a part of login) without the risk of chain analysis against such data (linking logins to onchain transactions).

Identity representations
------------------------

The XpubIdentifier created with extended public key under BIP32 derivation path ending at the level of the identity index is called **bitcoin decentralized id** (hereinafter simply **decentralized id**).

Rationale: XpubIdentifier is a hash of the extended public key, thus id does not leak any confidential information about the user, her/his outputs or any keys used in the setup and after. As a 256-bit number it is sufficient for global unique identification; and it is created in such a way that it will always be unique for each user (based on the selection of random number), seed & derivation path combination; which allows each user to have multiple unique decentralized ids without any significant risk collision. These ids will be scoped to some blockchain & authorization scheme (based on the use of specific signature algorithm).

Decentralized id can be used as a unique user login or a key for searching user metadata with different centralized or decentralized systems, which design is outside of the scope of this proposal (however there is a WIP in this regard involving client-validated LN-based smart contract system).

Aside from the decentralized id, when a user needs to use the identity under some scope (i.e. creating multisig wallet or registering/signing up to some online service or an app) he should use the following string, called “decentralized login” and/or “decentralized id string":

m/purpose’/blockchain'/identity’=[decentralized_id]/scope’=[scope_xpub]

Where:
- purpose', blockchain’, identity’ and scope' have the meaning according to this proposal (see the proposed BIP43 derivation path structure above);
- * decentralized_id* is the decentralized id (XpubIdentifier value at that derivation path level) encoded as BIP350 Bech32m string with HRP set ot `bcid`;
- **scope_xpub* is the Base64-encoded xpubkey (according to BIP32) derived at that level.

Rationale on the use of Bech32m encoding for XpubIdentifier
- the standard 64-hex string can be easily confused with other 64-hex strings such as transaction ids, XpubIdentifiers, SHA256(d) hash values etc. Bech32 prefix provides context making it unambiguously parsable by software
- Bech32m contains a checksum which makes it easier to check whether two ids are equal visually
- `bcid` HRP is selected to signify that this particular id standard is based on bitcoin ecosystem and Secp256k1 curves.

Rationale on login string:
- decentralized login string is designed in such a way that it can both be an id backup for the id owner (providing full information necessary for deriving keys under this id or checking the value of the scoped xpub from the seed) - and give the context (blockchain and signature algo) under which this id is valid.
- text representation of the login string is easy to check in the logs and simple to use in text-based protocols such as HTTP for authentication.

NB: If the revocation protocol is supported this string MUST be suffixed with a revocation single-use-seal (see below) in form of `?txid:vout`

**Examples:**

Decentralized id: bcid1ncr68x65lpvpz8nqtjrchnheru2e5x9rcdf2dk (this id corresponds to XpubIdentifier 9e07a39b54f858111e605c878bcef91f159a18a3; since I do not have Bech32m at hand I have temporally used Bech32)

Decentralized login: m/340’/0'/[bcid1ncr68x65lpvpz8nqtjrchnheru2e5x9rcdf2dk]/20721421274’=[xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV]

Decentralized login with key revocation: m/340’/0'/[bcid1ncr68x65lpvpz8nqtjrchnheru2e5x9rcdf2dk]/20721421274’=[xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV]?0e94ada127fbbc6d2152b18a50fd02ea9aaa608ec20cfc606ad327da1c255201:1

Multisig wallets with decentralized id
--------------------------------------

In case of multisig wallet creation, the parties may share their decentralized id strings in one of two forms:

1. Compact, skipping the scope xpub and replacing it with 32-bit xpub fingerprint:
```
m/purpose’/blockchain'/identity’=[decentralized_id]/scope’=[scope_xpub_fingerprint]
```
2. Full, as specified in the previous section

This will provide all parties with a sufficient information to construct full paths with a sequentally-increased final indexes

m/purpose’/blockchain’/identity’/scope'/case/index

for change and normal cases.

The first option will allow all parties to prepare PSBTs for the common signing process; however they will not be able to generate invoices or track blockchain for new transactions. However, on the other hand, that will not leak the scoped xpub.

The second option allows full features for multisig wallets, including invoice creating and onchain tracking.

Authenticating with decentralized id
------------------------------------

To authenticate (or register) a user must provide the authentification service with the following information:
- Login string from the previous section
- Random number within the **unhardened** BIP32 index range
- A signature, created according to the signature algorithm specified as a part of login (ECDSA or BIP340) with the private key derived with the following derivation path:

m/purpose’/blockchain'/identity’/scope’/random_seed

where *random_seed* is the random number from the above.

This scheme is non-interactive and can be used for authentication, authorization and registration with servers or applications.

Rationale:
- random number is required for avoiding private key reuse
- it is unhardened so the public key required for signature verification may be generated by the service from the scoped identity xpub provided as a part of the login
- random number can’t be a challenge from the service side since it will (a) make the protocol interactive, introducing unnecessary complexity and (b) will allow malicious servers to repeat the same challenge for private key correlation analysis if BIP340 signature is used.

Identity revocations
--------------------

It will be possible to revoke identities using single-use-seals mechanics ([originally proposed by Peter Todd][1]) based on bitcoin blockchain. What's important here is that this will not lead to the increase in transaction size and may be simply combined with normally happening transactions using special signature design procedure (see below).

NB: Since the revocation procedure is non-trivial, it is proposed to have the first version of the standard to be published without it and add it later by using the suffix `?txid:vout` with the revocation single-use-seal added to the identity string.

The protocol runs as follows:

### Identity creation
Alice, after creating a decentralized identity under this standard and its first scope, chooses some of her existing bitcoin UTXOs and uses it as a suffix for the identity/login string. It is important that:
- the UTXO must be protected by a key from the derivation path unrelated to the used identity.
- the UTXO should be mined at a safe depth, such that reogs would have a negligible probability.
- should be spendable by a single signature from a private key in Alice's possession.

### Identity scope revocation
If Alice needs to revoke specific scoped identity xpub (for instance, a private key leak happened) she needs to:
1. Spend the previously specified revocation UTXO signalling about the revocation by setting two most significant bits of the random number `k` used during the signature creation to `01` value.
2. Use the first output of the spending transaction as a new revocation UTXO.
3. For now, she needs to use 32-byte fingerprint | 0x8000000 of the transaction as a new identity scope for future logins and key derivations under the same identity.

### Full identity revocation
Alice also has an option of completely revoking the identity without providing a new scope, which will be an equivalent of removing login or cancelling participation in a multisig wallet. To do so she just needs to set two most significant bits to `10` value instead of `01`.

### Identity revocation detection
Other parties knowing Alice's identity string (her multisig co-signers under the same identity scope or services that her login information is) will know about revocation by monitoring the spending of the revocation UTXO in the blockchain and checking firts two most significant bit values in `k` value computable from the the signature in the spending input. They will be able to monitor consequent revocations using the first output from the revocation transaction as a new single-use-seal. They will also update Alice’s identity scope accordingly and will be able to verify Alice’s new signatures without any communications with her. It’s quite important that they will also be able to decline Alice's login attempts with the revoked key from the moment the revocation tx got into mempool, i.e. instantly.

### Spending single-use-seal without revocation
If, because of whatever reason, Alice needs to spend the UTXO which was previously marked as a revocation UTXO without the actual revocation, she can do that by setting ‘k’ two most significant bits to `00` value. The new revocation UTXO will become assigned to the first input of that transaction, but the identity would not be revoked and the scope value will not change.

Visual summaries
================

I have prepared some visual summary covering the proposal, which may simplify its analysis:

![image]( )

=================

Hope that all make sense. Me and my colleagues spent more than a year on finding ways to build decentralized identity standard suitable for cypherpunk needs, and this is the first part of what I came up with. Since I am also engineer behind [RGB smart contracts][2] (allow complex logic on top of bitcoin transactions & Lightning channels using client-side-validation and single-use-seals), the proposed identity, if accepted, will be later accompanied by layer-2 and 3 solutions on top, giving user the ability to provide the identity meta-information (name, surname, emails, avatars etc) with such features as:
- decentralized non-blockchain database & search engine for metadata: LN network
- no centralized notary: I will not need to ask anyone’s permission if I’d like to change my name
- partial meta-information disclosures: ability to selectively hide some fields
- multiple IDs under some root ID: unlinkable, until I disclose the link myself (and I can prove that the link exists, if I need)
- can be combined with bitcoin multisigs without confidentiality leaks: no onchain analysis is possible

Since there is no need to make that part of BIPs, I narrowed this proposal down to the part which is relevant only in the context of Layer 1 stuff.

——
[1]: https://building-on-bitcoin.com/docs/slides/Peter_Todd_BoB_2018.pdf
[2]: https://rgb-org.github.io/

Kind regards,
Dr Maxim Orlovsky,
LNP/BP Standards Association (https://lnp-bp.org)
& Pandora Core AG
GPG: FBDE A843 3DDC 1E69 FA90 C35E FFC0 2509 47E5 C6F7

https://github.com/dr-orlovsky
IRC: dr-orlovsky at freenode (usually in #rust-bitcoin, #lnp-bp & ##taproot-activation)
Twitter: @dr_orlovsky

📅 Original date posted:2019-08-19 📝 Original message:Hi, ...

2023-06-07T20:20:20+02:00

In reply to nevent1q…9jya
_________________________

📅 Original date posted:2019-08-19
📝 Original message:Hi,

I'd like to propose a design for distributed storage and messaging with escrow/economic incentivization leveraging LNP/BP ecosystem and working at Layer 2 and 3. It is described in details here: https://github.com/storm-org/storm-spec [1]

Briefly, it allows to construct special type of payment channels guaranteeing remote data storage and retrieval with counterparty risks mitigated by economic stimulus (stakes etc). Next, it can be combined with Lightning Network, i.e. operate completely off-chain ("Storm with Lightning" :).

This proposal came as a side-effect of our joint work on RGB and single-use seals technologies (recently mentioned by Peter Todd here [2]). In the nearest future I will be busy with finalizing and implementing these protocols, but don't want this idea to be missed/forgotten, since it can be very useful for other L2/L3 technologies requiring client-stored data, like guaranteeing external storage of script data for Taproot, scriptless scripts or Prometheus (technology for scalable computing [3]). So I'd welcome any possible comments, critics, or interest in driving Storm development forward.

[1] https://github.com/storm-org/storm-spec
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017257.html
[3] https://github.com/pandoracore/prometheus-spec/blob/master/prometheus.pdf

------

Dr Maxim Orlovsky
Pandora Core AG
https://twitter.com/dr_orlovsky
https://github.com/dr-orlovsky
xorlovsky[1..]@pandoracore.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190819/31c10a56/attachment.html>;