Dr Maxim Orlovsky [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-08-19 to 2023-06-03
💬 Posted a total of 21 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1a80jcetgws9xmu7wnylvekpymw2acym2psjpp03e0chmhq38pc8qwrpwgy

Profile Code

nprofile1qqswnhevv458gznd708fj0kvmqjdh9wuzd4qcfqshcuhutamsgnsurspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsy6hd20

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1a80jcetgws9xmu7wnylvekpymw2acym2psjpp03e0chmhq38pc8qwrpwgy

Show more details

Last Notes

2023-06-09 15:13:25

- reply

📅 Original date posted:2023-06-02
🗒️ Summary of this message: A proposal has been made for the bitcoin-dev mail list to have clear moderation policies and for the current moderator to be replaced, following allegations of abuse of power.
📝 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/lightning-dev/attachments/20230602/f0fd6794/attachment-0001.html>

2023-06-09 15:08:56

- reply

📅 Original date posted:2023-06-02
📝 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/lightning-dev/attachments/20230602/f0fd6794/attachment-0001.html>

2023-06-09 15:05:48

- reply

📅 Original date posted:2022-04-11
📝 Original message:
https://twitter.com/dr_orlovsky/status/1513555717218873355?s=21&t=NbHfD-n1NEu8Gdh-dOPifA
You do not deserve any other form of answer.
On Tue, Apr 5, 2022 at 5:06 PM, Olaoluwa Osuntokun via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi y'all,
>
> I'm excited to publicly publish a new protocol I've been working on over the
> past few months: Taro. Taro is a Taproot Asset Representation Overlay which
> allows the issuance of normal and also collectible assets on the main Bitcoin
> chain. Taro uses the Taproot script tree to commit extra asset structured meta
> data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree or
> MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a sparse
> merkle tree, enabling things like easily verifiable asset supply proofs and
> also efficient proofs of non existence (eg: you prove to me you're no longer
> committing to the 1-of-1 holographic beefzard card during our swap). Taro asset
> transfers are then embedded in a virtual/overlay transaction graph which uses a
> chain of asset witnesses to provably track the transfer of assets across
> taproot outputs. Taro also has a scripting system, which allows for
> programmatic unlocking/transfer of assets. In the first version, the scripting
> system is actually a recursive instance of the Bitcoin Script Taproot VM,
> meaning anything that can be expressed in the latest version of Script can be
> expressed in the Taro scripting system. Future versions of the scripting system
> can introduce new functionality on the Taro layer, like covenants or other
> updates.
>
> The Taro design also supports integration with the Lightning Network (BOLTs) as
> the scripting system can be used to emulate the existing HTLC structure, which
> allows for multi-hop transfers of Taro assets. Rather than modify the internal
> network, the protocol proposes to instead only recognize "assets at the edges",
> which means that only the sender+receiver actually need to know about and
> validate the assets. This deployment route means that we don't need to build up
> an entirely new network and liquidity for each asset. Instead, all asset
> transfers will utilize the Bitcoin backbone of the Lightning Network, which
> means that the internal routers just see Bitcoin transfers as normal, and don't
> even know about assets at the edges. As a result, increased demand for
> transfers of these assets as the edges (say like a USD stablecoin), which in
> will turn generate increased demand of LN capacity, result in more transfers, and
> also more routing revenue for the Bitcoin backbone nodes.
>
> The set of BIPs are a multi-part suite, with the following breakdown:
> * The main Taro protocol: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki
> * The MS-SMT structure: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki
> * The Taro VM: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki
> * The Taro address format: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
> * The Taro Universe concept: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki
> * The Taro flat file proof format: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki
>
> Rather than post them all in line (as the text wouldn't fit in the allowed size
> limit), all the BIPs can be found above.
>
> -- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220411/acc7e752/attachment-0001.html>

2023-06-08 01:22:10

- reply

📅 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>

2023-06-08 01:22:05

- reply

📅 Original date posted:2023-06-01
🗒️ Summary of this message: The LNP/BP Standards Association has proposed Prime, a scalable and anonymous layer 1 upgrade for Bitcoin protocol, which can be deployed without a softfork and doesn't affect BTC or PoW.
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230601/3ede4035/attachment.html>

2023-06-08 01:22:05

- reply

📅 Original date posted:2023-06-03
🗒️ Summary of this message: Bitcoin PoW Anchoring protocol reset allows for a special bitcoin transaction providing publically-identifiable OP_RETURN information about a new miner single-use-seal.
📝 Original message:Hi John,
Thank you for the question. We have discussed this case in the paper, second paragraph of the “Bitcoin PoW Anchoring” Section:
> If a party spends current miner single-use-seal without creating a commitment - or committing to a header without sufficient PoW, such closing is considered invalid; in this case, any party is allowed to create a special bitcoin transaction providing publically-identifiableOP_RETURNinformation ("announcement") about a new miner single-use-seal (protocol reset); only the firstOP_RETURNannouncement which is closed with a proper procedure is considered valid under the consensus rules.
Kind regards,
Maxim Orlovsky
On Sat, Jun 3, 2023 at 4:30 PM, John Tromp via bitcoin-dev <[bitcoin-dev at lists.linuxfoundation.org](mailto:On Sat, Jun 3, 2023 at 4:30 PM, John Tromp via bitcoin-dev <<a href=)> wrote:
>> The white paper describing the proposal can be found here:
>> https://github.com/LNP-BP/layer1/
>
> Some questions about the Bitcoin PoW anchoring:
>
> What if a miner spends the current miner single-use-seal while
> creating a commitment, but makes the PMT only partially available, or
> entirely unavailable ?
>
> How do other miners reach consensus on whether a protocol reset is
> required? It seems impossible to agree on something like PMT
> availability (much like mempool contents).
> _______________________________________________
> 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/20230603/283cc020/attachment.html>

2023-06-08 01:20:30

- reply

📅 Original date posted:2023-04-19
🗒️ Summary of this message: RGB allows for trustless contracting beyond Bitcoin script, including user-defined sidechains and smart contracts that don't need BTC. A new blockchain, sigchain, could remove the need for pegouts.
📝 Original message:Hi David,
> Ok, I think I understand you, but I'd like to try rephrasing what you
> wrote in a very brief format to see if you agree that it's correct and
> in the hopes that it might help other Bitcoin/LN developers understand.
In your description you mix together question of how BTC* can be issued
and how the contract settlement happens. However, they must be
distinguished, otherwise the contract trust model can't be anyhow better
than a fixed centralized BTC* design you add to the equation as an
assumption:
> What it doesn't provide is trustless contracting beyond the
> capabilities of Bitcoin script.
However:
1. Contract x*2=4 settlement is fully trustless.
2. BTC* contract settlement may vary.
One may argue that there is no way of getting BTC* in a trustless way,
but this is not true:
1. We may have a trustless BTC* in lightning channels (including
multiparty channels with many participants).
2. It also depends on how you define the value of the original BTC.
If BTC is a coin existing in bitcoin blockchain, than yes - you
can't have a fully trustless BTC* for on-chain operations. But if
you define BTC as a digital scarcity strictly inheriting existing
UTXO set from bitcoin blockchain, but which may exist elsewhere
than bitcoin blockchain, you may have a 100% trustless BTC*.
What can be a case for (2)? As I told in my first letter, with RGB
we do not need the existing heavy-duty bitcoin blockchain at all.
We still need a layer 1 settlement for our single-use-seals, but it may
have a very different design comparing to existing bitcoin blockchain.
At LNP/BP Standards Association we are working on such design for the
last 3 years, and have quite a lot of progress in this direction. The
design we have for the layer 1 needed for client-side-validation
(which Peter Todd calls "proof of publication medium") can be
represented as a single signature + pubkey per block, scaling up to
theoretically unlimited number of transactions. There are still some
problems we have to solve, but overall the direction seems realistic.
So, if/once we have a new blockchain, RGB (or its successor) can
operate on both bitcoin blockchain (let's call it timechain) and the
new blockchain (we call the new blockchain "sigchain" or "sealchain",
depending on the design model - we currently have 2 of them). Than, BTC
can be 100% trustlessly lifted from the timechain into RGB - and than
operate on top of the sigchain. In this model no pegout would be ever
needed, and the last point of trust gets removed.
> In short, I think this capability of RGB allows easily creating
> user-defined sidechains based on arbitrary scripts.
True, but RGB capabilities are even much larger than that. There is a
plenty of smart contracts which do not need BTC/BTC* at all and can
operate on RGB even today - but which were impossible on bitcoin
blockchain or lightning before RGB (at least without heavily polluting
block space):
1. Bearer securities - corporate shares, bonds, options, futures etc.
They will be 100% confidential and censorship-resistant + scalable
b/c of Lightning network. Yes, you still trust the issuer (like with
corporate shares), but the the secondary market is much improved.
2. Bearer ownership rights ("NFTs done in the right way"), again
private, scalable, not polluting blockchain. For instance, I would
like to have all books & songs as a bought to be present in this
format. This also opens options for creators to earn commissions not
just from an initial sale, but also from secondary market.
3. Digital collateral-based stable coins (in terms of their purchasing
power and not necessary linked to any fiat).
4. Digital identity, where RGB and single-use-seals make key revocation
a global event. Without this it is impossible to prove that a given
key was or was not revoked at certain date.
5. Decentralized naming systems - like ENS, but much better because
no ethereum is required :)
6. Provable historical event logs: opentimestamps doesn't allow
proving that there is no alternative commitments. With RGB it is
possible to build event logs which has 100% trustless provable
properties that no alternative history of the events does exist.
For instance, if a doctor gives a prediction that a baby will be
a boy and not a girl, it is impossible to witness the case with
OpenTimeStamp (the doctor can make 2 OTSes for both outcomes),
while with RGB it can be proven that no alternative commitment was
created.
7. Liquidity pools, DEXes, AMM and other fancy stuff on Lightning,
which we call "BiFi" (Bitcoin finance). One may listen to the talk
on the last Bitcoin Amsterdam conference where I have presented
that concept [1]. It requires more than just RGB - also some
improvements to the Lightning network and protocols like Storm
as a decentralized (tokenless!) data layer - but all of that is
WIP at LNP/BP Standards Association with many parts already being
released in a test versions (another reason why LNP Node is
important - a topic we were discussing two e-mails ago).
Thus we say that RGB allows everything what can be done with existing
"blockchain smart contracts" - but in much more scalable,
privacy-preserving way and with bitcoin, not requiring new/other
tokens. Arguably, this is the largest thing that happened to bitcoin
since bitcoin, with a potential to make Lightning network obsolete
(sigchain potentially exceeds in scalability the existing LN,
especially when gossip traffic and liquidity limitations are taken
into account).
The time will show where all these assumptions about the potential of
sigchain and #BiFi are correct. Meanwhile, we at LNP/BP Standards
Association continue our work on advancing bitcoin protocol and
lightning network protocols - without whining about any soft- or hard-
forks :). Of course, we, as a non-profit, need support - so all bitcoin
hodlers are welcome to join the very few organizations and individuals
already supporting our efforts [2], making all this future possible
(you can contact us via "ukolova [at] lnp-bp.org").
At the end, I'd like t, thank you for the detailed analysis and great
write-up on RGB in the latest Bitcoin Optech Newsletter. It explains
RGB in more simple words than I was was able to!
Kind regards,
Maxim Orlovsky
LNP/BP Standards Association
GitHub: https://github.com/LNP-BP
Twitter: @lnp_bp
[1]: https://www.youtube.com/watch?v=DtkTE6m0zio
[2]: https://rgb.tech/thanks/sponsors/

2023-06-08 01:20:28

- reply

📅 Original date posted:2023-04-18
🗒️ Summary of this message: The email discusses the invalidity of a proposed setup for using RGB with BTC and suggests a new setup involving creating an RGB contract with BTC* and specific conditions.
📝 Original message:Hi Harding,
This is the continuation from my previous e-mail [1] addressing the
largest and last unanswered question from your reply:
> To give my own example of the problem <… description follows …>
I am not entirely understand your argument or question, even though
I have spent a lot of time trying to crack it. For me it seems that
this is due to different paradigms we are thinking in. Client-side-
validation and work on RGB had required me to dramatically change
the way I see distributed systems, bitcoin and other “blockchains”
and multi-party contracts, thus this may have caused inability to
speak in the same terms. For me, the setup you are describing
doesn’t make sense at all: there is no reason of doing things with
RGB that way. I.e, you are suggesting invalid setup - and then
prove that it is not working :).
I will try first to explain why I think the reasoning you are
putting into the argument is invalid in the assumptions: nobody
should expect that RGB somehow magically makes on-chain BTC (I will
use this acronym to distinguish BTC-as-money from bitcoin-as-
blockchain or tech) more programmable or anyhow better: it is
impossible without softfork or a hardfork on _blockchain consensus_
level. What is possible is to add functionality on top of that; but
anything additional won’t work for BTC unless it is “lifted” into
that new layer. This is true with sidechains, this is true with
Lightning, this is for sure true with RGB. So any setups we are
analyzing must analyze such lifted BTC* in RGB as a value, and not
an on-chain. Next, most forms of contracts do not require a new
token, so I propose not to make setups more complex and start
discussing them without introducing a new tokens unless it is
really required.
Now, my setup to cover your case (or at least what I understood
from it) would be the following:
1. Assume we have some BTC lifted to RGB, which we will name BTC*.
(let’s leave the question on how to do that aside; it can be
discussed separately).
2. > Bob doesn't believe that there's a number which can be
multiplied by to produce 4. He's willing to pay a bounty for
proof that he's wrong.
This part I will take from your letter without changes, however
will skip the rest about production of some tokens etc, which
is unnecessary here.
(Please correct me if I am wrong in understanding what you wanted
to achieve and I will correct it - for instance I can't understand
why we need some Carol(s) at all).
To fulfill the described setup, Bob have to create a new RGB
contract (its **genesis**) featuring BTC* AND providing the
following conditions (in the contract **schema**, which is a part
of genesis):
1. The value of BTC* is preserved within the contract not attached
to any of UTXOs (it has become possible with RGB v0.10
introduction of “global state”)
2. BTC* can be reclaimed by any party providing a solution (in form
of RGB **state extension**) which is verified by AluVM. Alice,
if she have found the solution, now can **assign** that
previously “floating”/unowned BTC* to an UTXO she controls.
State extensions were introduced into RGB in late 2020 v0.4.
State extensions are different from a normal state transitions
by the fact that they do not have inputs referencing some
previously-owned (i.e. assigned to an UTXO) state, i.e. their
creation doesn’t require creation of a corresponding bitcoin
transaction spending some UTXOs with a state (as it is in case
of a state transitions).
3. To ensure uniqueness of the winner (i.e. prevent
“double-spending” of “free-floating”/unowned BTC* from the
contract global state) Alice is also required (by the contract
conditions defined by Bob in the contract schema) to post some
identifiable information into a mined bitcoin transaction
on-chain (NB: this is not the same as a witness transaction; it
can be any transaction not related to the contract UTXOs in any
way). The transaction must contain a pre-defined signal in a
form known only to the contract participants; for instance some
pre-defined random value stored in OP_RETURN, address, value,
witness, pay-to-contract tweak of some pre-defined pubkey - or
anywhere else. This can re-use a transaction which can be mined
anyway (like a payment that happens in parallel) and can even
avoid additional block space consumption if something like P2C
or tapret commitment is used (though this will require
a pre-knowledge of public keys at the moment of contract
creation). The contract script claims that only the first
party who had made such tx mined wins the game (if two txes are
mined in a block, they may be sorted by their txid or block
position). Because of AluVM, contracts can inspect on-chain
bitcoin state and find the signal.
That’s it! The structure of the contract would be genesis and that
thing called “state extension” - and nothing more. “Normal” RGB
flow (known to those who read about RGB before introduction of
state extensions) with state transitions and witness bitcoin
transactions would start only when Alice would like to spend that
BTC* or to peg out - and at that point of time an RGB state
transition will have to be created, and a corresponding bitcoin
transaction (called “witness transaction”) spending that Alice’s
UTXO, will have to be crafted, signed and mined.
Final notes:
============
Communication medium
--------------------
All communications between Alice and Bob happens wherever they
want - in IRC, mailing list, Nostr, telegram - or using
decentralized networks like LN (with [Storm] on top, which we
deliberately created for that purpose). It would be also possible
for Alice and Bob to use their RGB Nodes which will be
communicating through RGB RPC protocol - there is a lot of ways,
and RGB is fully abstracted from them.
Going fully off-chain
---------------------
The above design can be put fully off-chain if the group of players
may set up a n-of-n or n-of-m multiparty state channel (“channel
factory”).
Question of BTC*
----------------
Regarding BTC* creation, for now we do have at least two designs we
have developed over years:
1) for Lightning channels, which has the same level of
trustlessness as the pure BTC in LN;
2) on-chain "lifting" which is semi-trusted (trustless private
decentralized peg-in and semi-trusted federated peg-out
requiring user+federation multisig but no privacy/history
exposure thanks to zk; such on-chain lifting is still much
better than other alternatives with drivechains or federated
sidechains).
Last, but not least
-------------------
> Is there any documentation or discussion archives that address the
> problem of non-publishable conditional statements seemingly being
> insecure in multiparty protocols, as previously described on this
> list [1] by Ruben Somsen?
As far as I see, Ruben's letter was about different protocol, built
by Lightning Labs after they had studied (since they did plan to
implement) RGB - but they ended up with taking results of many years
of our research and did a successful fundraising of ~80m on it, even
"forgetting" to mention the original authors - until they were
ashamed by the community. Funny enough, even the original name of
their "protocol" was [CMYK].
I have no desire on commenting how they solved (and did they solve)
that - or any other - problem. I expect that they would again try
to take the solution I have described above and do another
fundraising with motto of transforming their product into “smart
contracts on Lightning” :)
Kind regards,
Maxim Orlovsky
CEO (Chief engineering officer)
@ LNP/BP Standards Association,
https://lnp-bp.org
Twitter: @lnp_bp
-----
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021559.html
[Storm]: https://github.com/Storm-WG
[CMYK]: [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020208.html](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020208.html)

2023-06-08 01:20:27

- reply

📅 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

2023-06-08 01:20:24

- reply

📅 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_

2023-06-08 01:06:47

- reply

📅 Original date posted:2022-04-01
📝 Original message:Hi Jeremy,
Thank you for your reply. P2C tweaks are unrelated to BIP32 derivations and
can't be mixed with BIP32 derivation paths. Specifically, P2C commitments can't
be relying on extended key chain code, which should be not known to the
verifyer. Thus, P2C is incompatible with BIP32 CDK.
Kind regards,
Maxim Orlovsky
On Sun, 2022-01-16 at 17:41 +0000, Dr Maxim Orlovsky wrote:
> Dear Bictoin dev community,
>
>
> In Mar 2019 Andrew Poelstra sent to bitcoin dev mail list a proposal
> for extending existing PSBT standard [6], which among other was suggesting
> adding a field for P2C tweaks:
>
> > (c) a map from public keys to 32-byte "tweaks" that are used in the
> > pay-to-contract construction. Selfishly I'd like this to be a
> > variable-length bytestring with the semantics that (a) the first
> > 33 bytes represent an untweaked pubkey; (b) the HMAC-SHA256 of
> > the whole thing, when multiplied by G and added to the untweaked
> > pubkey, result in the target key. This matches the algorithm in
> > [3] which is deployed in Blockstream's Liquid, but I'd be happy
> > with a more efficient scheme which e.g. used SHA256 rather than
> > HMAC-SHA256.
>
> This BIP proposal is an attempt to structure that idea into a more
> universal and standard form, following a discussion happened in
> https://github.com/bitcoin/bips/pull/1239. Specifically, it adds a PSBT input
> field for inputs spending UTXOs with previously created pay-to-contract (P2C)
> public key tweaks.
>
>
> -----------------------------------------------------------------------
>
> <pre>
> BIP: ?
> Layer: Applications
> Title: Pay-to-contract tweak fields for PSBT
> Author: Maxim Orlovsky <orlovsky at lnp-bp.org>,
> Andrew Poelstra <apoelstra at wpsoftware.net>
> Discussions-To: <bitcoin-dev at lists.linuxfoundation.org>
> Comments-URI: <to be assigned>
> Status: Draft
> Type: Standards Track
> Created: 2022-01-16
> License: BSD-2-Clause
> Requires: BIP-174
> </pre>
>
> ==Introduction==
>
> ===Abstract===
>
> This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2
> that allow for pay-to-contract key tweaking data data to be included in a PSBT
> of any version. These will represent an extra-transaction information required
> for the signer to produce valid signatures spending previous outputs.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ===Background===
>
> Key tweaking is a procedure for creating a cryptographic commitment to some
> message using elliptic curve properties. The procedure uses the discrete log
> problem (DLP) to commit to an extra-transaction message. This is done by
> adding
> to a public key (for which the output owner knows the corresponding private
> key)
> a hash of the message multiplied on the generator point G of the elliptic
> curve.
> This produces a tweaked public key, containing the commitment. Later, in order
> to spend an output containing P2C commitment, the same commitment should be
> added to the corresponding private key.
>
> This type of commitment was originally proposed as a part of the pay to
> contract
> concept by Ilja Gerhardt and Timo Hanke in [1] and later used by Eternity Wall
> [2] for the same purpose. Since that time multiple different protocols for P2C
> has been developed, including OpenTimeStamps [3], Elements sidechain P2C
> tweaks
> [4] and LNPBP-1 [5], used in for constructing Peter Todd's single-use-seals
> [6]
> in client-side-validation protocols like RGB.
>
> ===Motivation===
>
> P2C outputs can be detected onchain and spent only if the output owner
> not just knowns the corresponding original private key, but also is aware
> about
> P2C tweak applied to the public key. In order to produce a valid signature,
> the
> same tweak value must be added (modulo group order) to the original private
> key
> by a signer device. This represents a channelge for external signers, which
> may
> not have any information about such commitment. This proposal addresses this
> issue by adding relevant fields to the PSBT input information.
>
> The proposal abstracts details of specific P2C protocols and provides
> universal
> method for spending previous outpus containing P2C tweaks, applied to the
> public
> key contained within any standard form of the <tt>scriptPubkey</tt>, including
> bare scripts and P2PK, P2PKH, P2SH, witness v0 P2WPKH, P2WSH, nested witness
> v0
> P2WPKH-P2SH, P2WSH-P2SH and witness v1 P2TR outputs.
>
>
> ==Design==
>
> P2C-tweaked public keys are already exposed in the
> <tt>PSBT_IN_REDEEM_SCRIPT</tt>, <tt>PSBT_IN_WITNESS_SCRIPT</tt>,
> <tt>PSBT_IN_TAP_INTERNAL_KEY</tt> and <tt>PSBT_IN_TAP_LEAF_SCRIPT</tt> fields;
> the only information signer is needed to recognize which keys it should sign
> with is from which of the original keys they were generated. This is achieved
> by
> introducing new `PSBT_IN_P2C_TWEAK` field which has the original key as a
> field
> key and the tweak as a field value. The signer will recognize the keys which
> are
> available to it, apply the tweak to them and see in which scripts it was used
> --
> and use this information to apply tweaks for the corresponding private keys
> and
> produce valid signatures.
>
>
> ==Specification==
>
> The new per-input type is defined as follows:
>
> {|
> ! Name
> ! <tt><keytype></tt>
> ! <tt><keydata></tt>
> ! <tt><keydata></tt> Description
> ! <tt><valuedata></tt>
> ! <tt><valuedata></tt> Description
> ! Versions Requiring Inclusion
> ! Versions Requiring Exclusion
> ! Versions Allowing Inclusion
> > -
> > P2C Key Tweak
> > <tt>PSBT_IN_P2C_TWEAK = 0x19</tt>
> > <tt><pubkey></tt>
> > 33 bytes of compact public key serialization specifying to which of keys the
> P2C tweak may be applied (i.e. this MUST be a value of a public key before the
> tweak is applied). BIP-340 keys are serialized by appending `02`
> byte.<ref>'''Why compressed public keys are not distinguished from BIP-340
> public keys'''We follow the logic of BIP32 key derivation which does not
> performs that distinguishment. The type of the key is defined by the input
> type,
> and adding additional PSBT field type will just create the need for handling
> errors when the input type does not match the provided key type.</ref>
> > <tt><tweak></tt>
> > The 32 byte value which MUST be added to a private key to produce correct
> ECDSA and/or Schnorr signature ("key tweak"). Signers SHOULD remove this field
> after <tt>PSBT_IN_PARTIAL_SIG</tt> is constructed.
> >
> > 0, 2
> > BIP-P2C
> > }
>
> ==Security considerations==
>
> The scope of this proposal is deliberately kept narrow; it addresses
> only spending of transaction outputs containing P2C tweaks - and does not
> addresses construction of a new P2C commitments or transactions containing
> them in their outputs.<ref>'''Why only spending of P2C tweaked outputs is
> covered'''P2C tweaks commit to external data, some of which may represent
> certain value (like in some sidechains, single-use-seal applications like RGB
> etc). Creation of such outputs much allow hardware devices to understand the
> structure of such extra-transaction data, which may be in different formats
> and constantly involve. Thus, this should be addresses with a separate
> standards (or be a vendor-based). The current proposal only touches the
> question of spending an output which contained previously created P2C
> commitment, which does not creates a new commitment and does not provides that
> kind of risk of extra-blockchain value loses.</ref>
>
>
> ==Rationale==
>
> <references/>
>
>
> ==Compatibility==
>
> The proposal is compatible with the existing consensus rules and does not
> require any of their modifications.
>
> The proposed P2C PSBT fields provides sufficient information for creating a
> valid signatures for spendings of the following output types containing
> tweaked
> public keys:
> - bare scripts,
> - P2PK,
> - P2PKH,
> - P2SH,
> - witness v0 P2WPKH and P2WSH,
> - nested witness v0 P2WPKH-P2SH and P2WSH-P2SH,
> - witness v1 P2TR outputs.
>
> Possible future witness versions, including witness v1 non-taproot outputs may
> not be supported or covered by this BIP and may require addition of new fields
> to the PSBT inputs.
>
>
> ==Reference implementation==
>
> WIP
>
>
> ==Acknowledgements==
>
> TBD
>
>
> ==Test vectors==
>
> TBD
>
>
> ==References==
>
> [1] Ilja Gerhardt, Timo Hanke. Homomorphic Payment Addresses and the
> Pay-to-Contract Protocol. arXiv:1212.3257 \[cs.CR\]
> <https://arxiv.org/pdf/1212.3257.pdf>
> [2] Eternity Wall's "sign-to-contract" article.
> <https://blog.eternitywall.com/2018/04/13/sign-to-contract/>
> [3] Peter Todd. OpenTimestamps: Scalable, Trust-Minimized, Distributed
> Timestamping with Bitcoin.
> <https://petertodd.org/2016/opentimestamps-announcement>
> [4] Adam Back, Matt Corallo, Luke Dashjr, et al. Enabling Blockchain
> Innovations with Pegged Sidechains (commit5620e43). Appenxix A.
> <https://blockstream.com/sidechains.pdf>;;.
> [5] Maxim Orlovsky, Rene Pickhardt, Federico Tenga, et al. Key
> tweaking: collision- resistant elliptic curve-based commitments.
> LNPBP-1 Standard.
> <https://github.com/LNP-BP/LNPBPs/blob/master/lnpbp-0001.md>
> [6] Peter Todd. Single-use-seals. LNPBP-8 Standard.
> <https://github.com/LNP-BP/LNPBPs/blob/master/lnpbp-0008.md>
>
> --
> Maxim Orlovsky
> orlovsky at protonmail.com
> GitHub: @dr-orlovsky
> Twitter: @dr_orlovsky
>
> LNP/BP Standards Association
> orlovsky at lnp-bp.org
> github.com/LNP-BP
>
>
>
>

2023-06-08 01:02:20

- reply

📅 Original date posted:2022-01-16
📝 Original message:Dear Bictoin dev community,
In Mar 2019 Andrew Poelstra sent to bitcoin dev mail list a proposal
for extending existing PSBT standard [6], which among other was suggesting adding a field for P2C tweaks:
> (c) a map from public keys to 32-byte "tweaks" that are used in the
> pay-to-contract construction. Selfishly I'd like this to be a
> variable-length bytestring with the semantics that (a) the first
> 33 bytes represent an untweaked pubkey; (b) the HMAC-SHA256 of
> the whole thing, when multiplied by G and added to the untweaked
> pubkey, result in the target key. This matches the algorithm in
> [3] which is deployed in Blockstream's Liquid, but I'd be happy
> with a more efficient scheme which e.g. used SHA256 rather than
> HMAC-SHA256.
This BIP proposal is an attempt to structure that idea into a more
universal and standard form, following a discussion happened in https://github.com/bitcoin/bips/pull/1239. Specifically, it adds a PSBT input field for inputs spending UTXOs with previously created pay-to-contract (P2C) public key tweaks.
-----------------------------------------------------------------------
<pre>
BIP: ?
Layer: Applications
Title: Pay-to-contract tweak fields for PSBT
Author: Maxim Orlovsky <orlovsky at lnp-bp.org>,
Andrew Poelstra <apoelstra at wpsoftware.net>
Discussions-To: <bitcoin-dev at lists.linuxfoundation.org>
Comments-URI: <to be assigned>
Status: Draft
Type: Standards Track
Created: 2022-01-16
License: BSD-2-Clause
Requires: BIP-174
</pre>
==Introduction==
===Abstract===
This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2
that allow for pay-to-contract key tweaking data data to be included in a PSBT
of any version. These will represent an extra-transaction information required
for the signer to produce valid signatures spending previous outputs.
===Copyright===
This BIP is licensed under the 2-clause BSD license.
===Background===
Key tweaking is a procedure for creating a cryptographic commitment to some
message using elliptic curve properties. The procedure uses the discrete log
problem (DLP) to commit to an extra-transaction message. This is done by adding
to a public key (for which the output owner knows the corresponding private key)
a hash of the message multiplied on the generator point G of the elliptic curve.
This produces a tweaked public key, containing the commitment. Later, in order
to spend an output containing P2C commitment, the same commitment should be
added to the corresponding private key.
This type of commitment was originally proposed as a part of the pay to contract
concept by Ilja Gerhardt and Timo Hanke in [1] and later used by Eternity Wall
[2] for the same purpose. Since that time multiple different protocols for P2C
has been developed, including OpenTimeStamps [3], Elements sidechain P2C tweaks
[4] and LNPBP-1 [5], used in for constructing Peter Todd's single-use-seals [6]
in client-side-validation protocols like RGB.
===Motivation===
P2C outputs can be detected onchain and spent only if the output owner
not just knowns the corresponding original private key, but also is aware about
P2C tweak applied to the public key. In order to produce a valid signature, the
same tweak value must be added (modulo group order) to the original private key
by a signer device. This represents a channelge for external signers, which may
not have any information about such commitment. This proposal addresses this
issue by adding relevant fields to the PSBT input information.
The proposal abstracts details of specific P2C protocols and provides universal
method for spending previous outpus containing P2C tweaks, applied to the public
key contained within any standard form of the <tt>scriptPubkey</tt>, including
bare scripts and P2PK, P2PKH, P2SH, witness v0 P2WPKH, P2WSH, nested witness v0
P2WPKH-P2SH, P2WSH-P2SH and witness v1 P2TR outputs.
==Design==
P2C-tweaked public keys are already exposed in the
<tt>PSBT_IN_REDEEM_SCRIPT</tt>, <tt>PSBT_IN_WITNESS_SCRIPT</tt>,
<tt>PSBT_IN_TAP_INTERNAL_KEY</tt> and <tt>PSBT_IN_TAP_LEAF_SCRIPT</tt> fields;
the only information signer is needed to recognize which keys it should sign
with is from which of the original keys they were generated. This is achieved by
introducing new `PSBT_IN_P2C_TWEAK` field which has the original key as a field
key and the tweak as a field value. The signer will recognize the keys which are
available to it, apply the tweak to them and see in which scripts it was used --
and use this information to apply tweaks for the corresponding private keys and
produce valid signatures.
==Specification==
The new per-input type is defined as follows:
{|
! Name
! <tt><keytype></tt>
! <tt><keydata></tt>
! <tt><keydata></tt> Description
! <tt><valuedata></tt>
! <tt><valuedata></tt> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| P2C Key Tweak
| <tt>PSBT_IN_P2C_TWEAK = 0x19</tt>
| <tt><pubkey></tt>
| 33 bytes of compact public key serialization specifying to which of keys the
P2C tweak may be applied (i.e. this MUST be a value of a public key before the
tweak is applied). BIP-340 keys are serialized by appending `02`
byte.<ref>'''Why compressed public keys are not distinguished from BIP-340
public keys'''We follow the logic of BIP32 key derivation which does not
performs that distinguishment. The type of the key is defined by the input type,
and adding additional PSBT field type will just create the need for handling
errors when the input type does not match the provided key type.</ref>
| <tt><tweak></tt>
| The 32 byte value which MUST be added to a private key to produce correct
ECDSA and/or Schnorr signature ("key tweak"). Signers SHOULD remove this field
after <tt>PSBT_IN_PARTIAL_SIG</tt> is constructed.
|
|
| 0, 2
| BIP-P2C
|}
==Security considerations==
The scope of this proposal is deliberately kept narrow; it addresses
only spending of transaction outputs containing P2C tweaks - and does not addresses construction of a new P2C commitments or transactions containing them in their outputs.<ref>'''Why only spending of P2C tweaked outputs is covered'''P2C tweaks commit to external data, some of which may represent certain value (like in some sidechains, single-use-seal applications like RGB etc). Creation of such outputs much allow hardware devices to understand the structure of such extra-transaction data, which may be in different formats and constantly involve. Thus, this should be addresses with a separate standards (or be a vendor-based). The current proposal only touches the question of spending an output which contained previously created P2C commitment, which does not creates a new commitment and does not provides that kind of risk of extra-blockchain value loses.</ref>
==Rationale==
<references/>
==Compatibility==
The proposal is compatible with the existing consensus rules and does not
require any of their modifications.
The proposed P2C PSBT fields provides sufficient information for creating a
valid signatures for spendings of the following output types containing tweaked
public keys:
- bare scripts,
- P2PK,
- P2PKH,
- P2SH,
- witness v0 P2WPKH and P2WSH,
- nested witness v0 P2WPKH-P2SH and P2WSH-P2SH,
- witness v1 P2TR outputs.
Possible future witness versions, including witness v1 non-taproot outputs may
not be supported or covered by this BIP and may require addition of new fields
to the PSBT inputs.
==Reference implementation==
WIP
==Acknowledgements==
TBD
==Test vectors==
TBD
==References==
[1] Ilja Gerhardt, Timo Hanke. Homomorphic Payment Addresses and the
Pay-to-Contract Protocol. arXiv:1212.3257 \[cs.CR\]
<https://arxiv.org/pdf/1212.3257.pdf>
[2] Eternity Wall's "sign-to-contract" article.
<https://blog.eternitywall.com/2018/04/13/sign-to-contract/>
[3] Peter Todd. OpenTimestamps: Scalable, Trust-Minimized, Distributed
Timestamping with Bitcoin.
<https://petertodd.org/2016/opentimestamps-announcement>
[4] Adam Back, Matt Corallo, Luke Dashjr, et al. Enabling Blockchain
Innovations with Pegged Sidechains (commit5620e43). Appenxix A.
<https://blockstream.com/sidechains.pdf>;.
[5] Maxim Orlovsky, Rene Pickhardt, Federico Tenga, et al. Key
tweaking: collision- resistant elliptic curve-based commitments.
LNPBP-1 Standard.
<https://github.com/LNP-BP/LNPBPs/blob/master/lnpbp-0001.md>
[6] Peter Todd. Single-use-seals. LNPBP-8 Standard.
<https://github.com/LNP-BP/LNPBPs/blob/master/lnpbp-0008.md>
--
Maxim Orlovsky
orlovsky at protonmail.com
GitHub: @dr-orlovsky
Twitter: @dr_orlovsky
LNP/BP Standards Association
orlovsky at lnp-bp.org
github.com/LNP-BP

2023-06-08 00:58:25

- reply

📅 Original date posted:2021-09-02
📝 Original message:Hi Peter,
Yep, I think it is a good idea just to do new BIP and ignore IANA opinion on the matter. I can write it since I was going to propose pretty much the same thing some time ago. I will share the draft in this mail list in a week.
Kind regards,
Maxim Orlovsky
LNP/BP Standards Association
http://lnp-bp.org
github.com/dr-orlovsky
-------- Original Message --------
On 1 Sep 2021, 15:39, Peter D. Gray via bitcoin-dev wrote:
>> ... I tried doing this with "application/bitcoin-psbt" back in
>> 2019 but it was not accepted...
>
> Thanks for this background.
>
> Based on your experience, we should probably ignore the IANA then,
> and just declare a few useful "mime types" (note the quotes) in a
> new BIP. We can then agree inside the Bitcoin community on their
> usage and meaning.
>
> Anyone want to write that BIP and shepherd it? I can support you
> but I'd rather write code.
>
> ---
> @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
>
> On Tue, Aug 31, 2021 at 07:46:55PM +0000, Andrew Chow wrote:
>> Hi Peter,
>>
>> It would be nice to have mime types registered for Bitcoin things, but
>> I'm not sure that it will be possible, at least not in the way that we
>> would like. I tried doing this with "application/bitcoin-psbt" back in
>> 2019 but it was not accepted. From that attempt, here is what I have
>> learned:
>>
>> There are only a few accepted top level types, so we would not be able
>> to use "bitcoin" as the top level (unless you want to submit an RFC to
>> add a "bitcoin" top level). Of the available top level types,
>> "application" is the most appropriate for Bitcoin.
>>
>> Next is the tree that the mime type should be in. The best would be the
>> Standards tree, but it has some requirements that Bitcoin doesn't really
>> meet. In order to be in the standards tree, the registration must be
>> either associated with an IETF specification (so a RFC) or registered by
>> a recognized standards related organization. Unfortunately the closest
>> thing to a standards organization that Bitcoin has is the BIPs process,
>> and that is not a really a standards organization nor is it recognized
>> by IANA. So in order to register the mimetypes as Standards tree types,
>> we would need to write an RFC, but this could be an independent
>> submission (https://www.rfc-editor.org/about/independent/) rather than
>> IETF-stream submission. I did not continue to pursue this because I
>> didn't have the time.
>>
>> Another alternative would be to use the Vendor tree, but that would
>> prefix the mimetype with "vnd." so it would end up being something like
>> "application/vnd.bitcoin.psbt". I did not think this was an reasonable
>> so I did not continue to pursue this avenue.
>>
>>
>> Andrew Chow
>>
>> On 8/31/21 2:27 PM, Peter D. Gray via bitcoin-dev wrote:
>> > Hi list!
>> >
>> > I am proposing to register the following MIME (RFC 2046) media types with the IANA:
>> >
>> >
>> > bitcoin/psbt
>> >
>> > - aka. a BIP-174 file, in binary
>> > - does not make any claims about signed/unsigned status; lets leave that to the file
>> >
>> > bitcoin/txn
>> >
>> > - aka. wire-ready fully-signed transaction in binary
>> >
>> > bitcoin/uri
>> >
>> > - aka [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki)
>> > - could be just a bare bech32 or base58 payment address
>> > - but can also encode amount, comments in URL args
>> > - potentially interesting as a response to 402 - Payment required
>> >
>> >
>> > Other thoughts
>> >
>> > - some mime-types are proposed in BIP-71 but those are unrelated to above, and never
>> > seem to have been registered
>> >
>> > - for those who like to encode their binary as base64 or hex, that can be indicated
>> > as "encoding=hex" or "encoding=base64" in the optional parameters, just like
>> > "text/plain; encoding=utf-8" does. However, the default must be binary.
>> >
>> > - although the above are useful for web servers, they are also useful elsewhere and I
>> > intend to use them in NFC (NDEF records) where a shorter length is critical.
>> >
>> > - I have no idea how easily IANA will accept these proposals.
>> >
>> > - current approved mime types: https://www.iana.org/assignments/media-types/media-types.xhtml
>> >
>> > Thoughts?
>> >
>> > ---
>> > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> 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/20210902/cb571cb2/attachment.html>

2023-06-07 20:28:30

- reply

📅 Original date posted:2021-02-18
📝 Original message:Hi Adam,
Commenting on your question:
> With segWit vs pre-SegWit didn't wallets just select and standardize
> on a different HD derivation path?
>
> Is there something else needed than a Schnorr derivation path?
The general accepted practice (defined in BIP43) is to define a dedicated purpose field for each kind of key derivation and address encoding. There is a dedicated purpose for pre-SegWit, SegWit, multisigs — and now a purpose for Schnorr sigs/Taproot outputs is needed. That is why I brought forward this proposal, which addresses exactly this need - and also will support at the same time multisigs and pre-Taproot outputs, making all previously used purpose fields redundant, simplifying future wallets.
Kind regards,
Maxim

2023-06-07 20:28:29

- reply

📅 Original date posted:2021-02-18
📝 Original message:Hi Pieter,
Addressing your comments:
>> Thank you very much for all the clarifications; it’s good to have them sorted out and clearly structured. From what you wrote it follows that we still need to reserve a dedicated purpose (with new BIP) for BIP340 signatures to avoid key reuse, am I right?
>
> Maybe, but it would be for a particular way of using keys (presumably: single-key pay-to-taproot), not just the signature scheme itself. If you go down this path you'll also want dedicated branches for multisig participation, and presumably several interesting new policies that become possible with Taproot.
Yes, previously we had a dedicated standards (BIPs) for purpose fields on each variant: single-sig, multi-sig etc. With this proposal I simplify this: you will have a dedicated deterministically-derived *hardened* keys for each use case under single standard, which should simplify future wallet implementations.
> And as I said, dedicated branches only help for the simple case. For example, it doesn't address the more general problem of preventing reuse of keys in multiple distinct groups of multisig sets you participate in. If you want to solve that you need to keep track of index is for participating in what - and once you have something like that you don't need dedicated purpose based derivation at all anymore.
In the BIP proposal there is a part on how multisigs can be created in a simple and deterministic way without keys reuse.
> So I'm not sure I'd state it as us *needing* a dedicated purpose/branch for single-key P2TR (and probably many other useful ways of using taproot based spending policies...). But perhaps it's useful to have.
My proposal is to have a new purpose field supporting all the above: hardened derivation that supports for multisigs, single-sigs etc.
Kind regards,
Maxim

2023-06-07 20:28:29

- reply

📅 Original date posted:2021-02-11
📝 Original message:Hi Pieter,
... and sorry for misspelling your name in my first e-mail :(
Thank you very much for all the clarifications; it’s good to have them sorted out and clearly structured. From what you wrote it follows that we still need to reserve a dedicated purpose (with new BIP) for BIP340 signatures to avoid key reuse, am I right?
Kind regards,
Maxim
> On Feb 6, 2021, at 02:15, Pieter Wuille <bitcoin-dev at wuille.net> wrote:
>
>
> On Friday, February 5, 2021 9:51 AM, Dr Maxim Orlovsky via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> 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.
>
> Hi Maxim,
>
> thanks for bringing up this discussion here. I'd like to clarify a few things though, as I think the above is formulated far too strongly.
>
> There are two issues here: (1) reasons to avoid reusing the same key for privacy reasons, and (2) reasons to avoid using related keys for cryptographic reasons. And in practice, solutions to the first (which we already need, unrelated to Taproot/Schnorr) mean the second is largely moot.
>
>
> # Don't reuse keys for privacy/organizational reasons.
>
> Reusing the same key in Bitcoin scripts - for use in distinct signature schemes or not - should always be avoided. It has obvious privacy implications; I don't think this is controversial, and it's a problem that exists today, unrelated to Taproot. E.g. you don't want to reuse the same keys as both single-sig and participation in multisig.
>
> My personal view here is that distinct standard derivation paths help with this in the simple cases, but they're not a full solution in the most general case. E.g. if you want to use one seed/root to participate in multiple sets of multisig policies, you'll need some kind of index to assign to each anyway. For this reason in general I prefer solutions that explicitly track what path is used for what.
>
>
> # Don't use related keys for cryptographic reasons
>
> There are some concerns to address here, but I want to make it clear there are no known attacks against usage of related keys across ECDSA and Schnorr, and I don't expect there will be. However, there is probably no proof for this, and creating one may be tricky. On the other hand, the ecosystem (Bitcoin, but also many other applications) has accepted ECDSA long ago, while it had no security proofs whatsoever (and even the ones that exist now rely on fairly unusual assumption; a proof for security of mixed Schnorr/ECDSA usage would inherently need equally unusual assumptions too).
>
> Now, as soon as a hardened derivation separates different uses there is no concern at all. So any solution for avoiding key reuse (section above) that works by assigning (implicitly or explicitly) different hardened derivation paths (as BIP43 etc. do) to different uses implies there is never any concern about related keys across Schnorr/ECDSA.
>
> If the keys are not separated by a hardened step, it's more complicated. Looking at the different cases:
>
> (1) Signing with related ECDSA keys (e.g. two unhardened child keys from the same xpub)
>
> - This is very common on BIP32 usage today, so hopefully it is secure! Tim Ruffing pointed me today to https://link.springer.com/chapter/10.1007/978-3-030-36938-5_8 whose abstract seems to indicate they prove this is actually secure, but I don't know under what assumptions. Note that the comment there about Schnorr not having this property does not apply to BIP340, because it uses key-prefixed Schnorr.
>
> (2) Signing with related Schnorr keys.
>
> - I believe this is secure simply because BIP340 challenges commit to the pubkey (key prefixing), and thus a signature on one shouldn't teach you anything about others. A formal proof is probably a bit longer, but still trivial to construct.
>
> (3) The real question: signing with a Schnorr key that is related to an ECDSA key.
>
> - I don't expect that this is easy to prove, but I have a very hard time imagining how it could be exploitable, given the use of domain-separated hashes. Aspects such as BIP340's key prefixing and the fact that Bitcoin sighashes indirectly commit to the (set of) signing pubkeys make it even harder.
>
>
> # TL;DR
>
> * For privacy reasons, you should use separate keys/derivation branches for different uses in all circumstances (duh).
> * To stay within the realm of provably security it's advisable to make sure ECDSA key and Schnorr keys use distinct hardened derivation steps.
> * Even if you don't, you're really just back to the level of assurance we had about unhardened BIP32 ECDSA keys before a proof was known (which I think most people aren't even aware of).
>
> Cheers,
>
> --
> Pieter

2023-06-07 20:28:28

- reply

📅 Original date posted:2021-02-11
📝 Original message:Hi Christopher,
Thank you very much! Will look forward to talk to you regarding all of these, as we discussed elsewhere.
Kind regard,
Maxim
> On Feb 5, 2021, at 23:37, Christopher Allen <ChristopherA at lifewithalacrity.com> wrote:
>
> Concept ACK.
>
> I, in my role as a co-author of the emerging W3C Decentralized Identifier standard and of the BTCR DID method, organizer of the Bitcoin Airgapped Wallet Community (https://github.com/blockchainCommons/airgapped-Wallet-Community/discussions), and as principal architect of Blockchain Commons, am very interested in supporting discussion on this topic, and implementation of anything we decide. I also have some Patron's to Blockchain Commons interested in this topic and may be willing to financially support some reference code.
>
> -- Christopher Allen

2023-06-07 20:28:27

- reply

📅 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

2023-06-07 20:28:26

- reply

📅 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](https://user-images.githubusercontent.com/372034/107058405-dd645580-67d4-11eb-986f-a0211d2dd54f.png)
=================
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

2023-06-07 20:20:21

- reply

📅 Original date posted:2019-08-21
📝 Original message:Hi ZmnSCPxj,
> The Deaf Bob Attack
> =============================================
> - If Alice does not publish the HTLC settlement transaction, then Bob will eventually enter the N2 state and get the stake+reward.
> - If Alice does publish the HTLC settlement transaction, without Bob giving the encrypted data, then Bob can just use the hashlock and reveal the decryption key.
> - The decryption key is useless without the encrypted data!
That is the main attack already addressed by couple of other guys in different forms; and you have provided the most detailed explanation of it, thank you. I was working for its solution over the last day and I'd like to propose the following update: https://github.com/storm-org/storm-spec/issues/6#issuecomment-523497555
Briefly, I introduce two new intermediary HTLC transactions (called confirmation and fallbacks). Alice has now a choice to sign HTLC fallback tx if she didn't get the data, and in that case she will get her money (reward) back and Bob's stake as a compensation. Bob can "appeal" to this by confirming that he had hold the data for Alice. Bob does this by providing a "preimage" to the secret hashed by Alice.
This secret is composed at setup time by Alice, and she uses her newly-derived public key for both funding transaction output and deterministically definition of some small portion of the source data. This portion is double-hashed to 160-bit hash and included into HTLC fallback tx by Alice as a hash lock. Later, when Bob wants to prove that he still has the data available, he see the published HTLC transaction, extracts Alice public key and uses it to get the same deterministic piece of the source data as Alice. Bob computes a single hash on the date, which gives him a preimage to unlock the hash lock from HTLC transaction output before Alice will spend it (Alice's output is timelocked).
This solution requires Bob to select decription key at setup time, when he pre-signs the transaction, as you correctly have pointed out:
> If Bob already selected the decryption key at setup time, then Bob can ignore Alice.
Now, we need to aviod situation where by selecting the encryption/decryption pair Bob knows which part of the data he needs to provide Alice in PCP proof, and can discard the rest of the data. This can be mitigated by requiring that the data have to be encrypted using EC multiplication with some factor provided by Alice at the request time.
The only case for possible cheating now is Alice not needing data anymore and avoiding paying the full amount for the storage. However, this can be a part of the Bob business risk and may be covered by some insurance + Alice's reputation & taken into account by Bob at setup time.
Kind regards,
Maxim Orlovsky

2023-06-07 20:20:21

- reply

📅 Original date posted:2019-08-21
📝 Original message:Hi ZmnSCPxj,
Thank you very much for spending your time on analysing my idea at such a deep level – and writing the detailed review proposing possible solutions to the main found issues.
> Insufficient/unclear Description of Probabilistic Proof
> =======================================================
>
> <...>
> It might be that you imply this in your step 1 for Alice validation of the probabilistically checkable proof though it may be better clarified that Alice has to keep the Merkle Tree root for the original data it originally requested:
>
>> With these data, Alice will be able to check with this zero-knowledge argument by:
>> 1. Checking Merkle tree paths leading to the chunks and resulting Merkle tree root hash to correspond to them
Correct, I forgot to put this step into the description, will fix, sorry for that. Indeed, Alice needs to take a "shot" from the data in a form of Merkle tree and keep its root for herself, and Bob has to provide her with
* "PCP-selected" blocks of source
* "PCP-selected" blocks of encrypted data
* siblings of the Merkle root "leafs" for the selected source data (required for Alice to check source data paths up to the Merkle root which she had kept for herself)
* Merkle paths for both of them
* public key used for the encryption, so Alice can re-encrypt received source data blocks and make sure they are equal to the provided encrypted blocks, so this public key is true
> Will the Real Decryption Key Please Stand Up?
> =============================================
>
> Also, it seems to me that the encryption used must be an asymmetrical encryption.
> That is, the encryption and decryption keys must be different, with the encryption key being a "public" key Bob can safely share with Alice and the decryption key being a "private" key that Bob can share only once it has acquired its funds.
Correct, it should be working like in PGP/GPG
> That is, Bob must prove:
>
> * The given hash h is the hash of the secret decryption key d whose equivalent encryption key is e
>
> ...while revealing only h and e to Alice.
Yes, that is an important point, I've missed that out.
> If there exists some asymmetric encryption using EC (I know of no such, but that is only due to my ignorance), where the decryption key is a scalar and the encryption key is the scalar times the generator then it would be possible to use 2p-ECDSA / Schnorr Scriptless Script to atomically pay for knowledge of the scalar / decryption key, while knowing the encryption key.
> Instead of a hash of the decryption key, Bob sends the encryption key during setup and Alice and Bob use that in the pointlocked timelocked contract under Scriptless Script.
A very elegant solution, thank you! Yes, seems one can encrypt/decrypt with EC: https://developer.ibm.com/swift/2019/03/04/blueecc-elliptic-curve-cryptography/ and this should work. I will include your solution to the proposal.
It also might be possible to implement your solution with threshold ECDSA signatures, that will enable Storm before Schorr's will get to Bitcoin. I am not very good in understanding them yet, but it seems that multiparty ECDSA (or threshold ECDSA, t-ECDSA) unlock many of Schnorr’s signature features and benefits.
One may check https://github.com/KZen-networks/multi-party-ecdsa and papers:
* https://eprint.iacr.org/2019/114.pdf
* https://link.springer.com/chapter/10.1007/978-3-319-39555-5_9 https://twitter.com/alexbosworth/status/1163116574238056448
I will investigate that in more details.
> Transporting Storm Over Lightning
> =================================
>
> Of note is that any mechanism that requires multiple participants to put up money into a contract (as in the case of Storm, which requires both the stake from Bob and the reward from Alice to be put into a single timebound HTLC) can only live inside a single LN channel and is not transportable across intermediate nodes.
> This is because intermediate nodes potentially become subject to attack in case of routing failure.
> (Though it *may* be possible to reuse the sketch I give here for HTLC-enforced publication of combined HTLCs: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002055.html)
>
> This is part of what makes LN difficult to work with multiple asset types due to HTLCs naturally forming premium-free American Call Options.
> Avoiding premium-free American Call Options is possible by extracting the premium from the receiver and combining it with the money from the exchange, but this again is doable only onchain, or in a single LN channel (meaning receivers must centralize around exchanges).
> It may be possible to get around this, once Lightning supports payment points + scalars, by use of EC magic homomorphisms, though I lack the energy right now to go dig up the resources on lightning-dev.
> But the storage provider can route a payment to Alice to serve as stake, which can be claimed only if knowing some secret, then Alice routes the stake+reward to Bob, and use some of the EC magic homomorphism while keeping intermediate nodes unaware.
You are right, my solution is limited to a single LN channels, i.e. there must be a direct dually-funded channel between Alice and Bob (and we don't have dually-funded channels as a part of current LN BOLT's). I will add this disclaimer to the spec.
Your solution to the transporting problem is indeed very interesting, however, I need some time to analyze it in more details. Meanwhile, if you don't mind, I will open an issue on GitHub and will be copying the discussion to there as well, so others from outside of this mail list can also join.
Kind regards,
Maxim Orlovsky
https://github.com/dr-orlovsky

2023-06-07 20:20:20

- reply

📅 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>