Re: [bitcoin-dev] Trustless 2-way-peg without softfork

[Dr Maxim Orlovsky via bitcoin-dev]

Hi,

I got a lot of feedback on my proposal -- and it appears that I have to work on 
a simpler paper explaining how the proposed generic model ("Prometheus") can be 
applied to a specific case of two-way peg. I have planned this work for the 
next several weeks and will post it to this mailing list once ready.

Kind regards,
Maxim


--- Original Message ---
On Monday, September 11th, 2023 at 5:26 PM, G. Andrew Stone via bitcoin-dev 
 wrote:


> Any chance of a quick tldr to pique our interest by explaining how exactly 
> this works "and the protocol will reach consensus on whether the state 
> reported by the oracle is correct" in presumably a permissionless, anonymous, 
> decentralized fashion, and what caveats there are?
> 
> Regards,
> Andrew
> 
> On Sun, Sep 10, 2023 at 4:06 PM Dr Maxim Orlovsky via bitcoin-dev 
>  wrote:
> 
> > Hi,
> > 
> > Several years ago my team from Pandora Project working on 
> > censorship-resistant distributed machine learning proposed Prometheus: a 
> > protocol for high-load computing on top of Bitcoin. The protocol operates 
> > as a multi-party game setting where an oracle ("worker") is provided with 
> > an arbitrary computationally complex task (any Turing-complete computing, 
> > machine learning training or inference etc) and the network is able to 
> > reach a consensus on whether a result reported by the worker is true. The 
> > consensus is reached via optional rounds of verification and arbitrage. The 
> > protocol is cryptoeconomically-safe, i.e. has a proven Nash equilibrium. 
> > The protocol was later transferred to LNP/BP Standards Association 
> > (https://lnp-bp.org) and was kept in a backlog of what can be done in a 
> > future as a layer on top of Bitcoin.
> > 
> > I'd like to emphasize that Prometheus works on Bitcoin, requires just 
> > several Bitcoin tx per task, and _doesn't require any soft fork_. All 
> > economic setting is done with Bitcoin as a means of payment, and using 
> > existing Bitcoin script capabilities.
> > 
> > Link to the paper describing the protocol: 
> > <https://github.com/Prometheus-WG/prometheus-spec/blob/master/prometheus.pdf>
> > 
> > Only today I have realized that Prometheus protocol can be used to build 
> > cryptoeconomically-safe (i.e. trustless) 2-way-peg on the Bitcoin 
> > blockchain without any soft-forks: a "worker" in such a case acts as an 
> > oracle for some extra-bitcoin system (sidechain, client-side-validated 
> > protocol, zk rollup etc) validating it, and the protocol will reach 
> > consensus on whether the state reported by the oracle is correct.
> > 
> > In other words, this is an alternative to BIP-300 and other similar 
> > soft-forks having the only purpose of doing 2-way pegs. It also enables the 
> > two-way trustless transfer of Bitcoins between Bitcoin blockchain, RGB and, 
> > in a future, potential new layer 1 called "prime" (to learn more about 
> > prime you can check my Baltic Honeybadger talk 
> > <https://www.youtube.com/live/V3vvybsc1A4?feature=shared&t=23631>).
> > 
> > 
> > Kind regards,
> > Dr Maxim Orlovsky
> > Twitter: @dr_orlovsky
> > Nostr: npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym
> > 
> > LNP/BP Standards Association
> > Twitter: @lnp_bp
> > 
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

Re: [bitcoin-dev] Trustless 2-way-peg without softfork

[Dr Maxim Orlovsky via bitcoin-dev]

In the last e-mail I missed the second article which describes proofs for the 
Nash equilibrium for the protocol model: 

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

[bitcoin-dev] Trustless 2-way-peg without softfork

[Dr Maxim Orlovsky via bitcoin-dev]

Hi,

Several years ago my team from Pandora Project working on censorship-resistant 
distributed machine learning proposed Prometheus: a protocol for high-load 
computing on top of Bitcoin. The protocol operates as a multi-party game 
setting where an oracle ("worker") is provided with an arbitrary 
computationally complex task (any Turing-complete computing, machine learning 
training or inference etc) and the network is able to reach a consensus on 
whether a result reported by the worker is true. The consensus is reached via 
optional rounds of verification and arbitrage. The protocol is 
cryptoeconomically-safe, i.e. has a proven Nash equilibrium. The protocol was 
later transferred to LNP/BP Standards Association (https://lnp-bp.org) and was 
kept in a backlog of what can be done in a future as a layer on top of Bitcoin.

I'd like to emphasize that Prometheus works on Bitcoin, requires just several 
Bitcoin tx per task, and _doesn't require any soft fork_. All economic setting 
is done with Bitcoin as a means of payment, and using existing Bitcoin script 
capabilities.

Link to the paper describing the protocol: 


Only today I have realized that Prometheus protocol can be used to build 
cryptoeconomically-safe (i.e. trustless) 2-way-peg on the Bitcoin blockchain 
without any soft-forks: a "worker" in such a case acts as an oracle for some 
extra-bitcoin system (sidechain, client-side-validated protocol, zk rollup etc) 
validating it, and the protocol will reach consensus on whether the state 
reported by the oracle is correct.

In other words, this is an alternative to BIP-300 and other similar soft-forks 
having the only purpose of doing 2-way pegs. It also enables the two-way 
trustless transfer of Bitcoins between Bitcoin blockchain, RGB and, in a 
future, potential new layer 1 called "prime" (to learn more about prime you can 
check my Baltic Honeybadger talk 
).


Kind regards,
Dr Maxim Orlovsky
Twitter: @dr_orlovsky
Nostr: npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym

LNP/BP Standards Association
Twitter: @lnp_bp

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

[bitcoin-dev] New BIP to align descriptors, xpub derivation and miniscript

[Dr Maxim Orlovsky via bitcoin-dev]

Hi,

Script output descriptors ("output descriptors", "wallet descriptors", or 
simply "descriptors") are getting more and more traction. Descriptors work 
in combination with miniscript, extended BIP32 keys (xpub/xprivs 
"descriptors" equipped with origin and derivation information) and are used
to construct new primitives like "wallet templates" used in Ledger and 
BitBox today.

Nevertheless, due to historical reasons, the resulting combination of the 
mentioned technologies is frequently redundant and leaves a lot of 
unspecified caveats, when it is unclear how descriptor with 
internally-conflicting data has to be handled by wallets and/or devices. 
For instance,
- derivation path standards (following BIP44) commit to the type of the 
  script pubkey (P2PKH, P2SH, P2WSH, P2WPKH, P2TR), but the same information
  is present in the descriptor itself;
- each of the public keys within the descriptor replicates the derivation 
  information and information about Bitcoin network (testnet or mainnet);
- if the same signer participates in different miniscript branches, due 
  to miniscript anti-malleability rules a new derivation path has to be used
  in pre-Taproot context (but not in Taproot) -= and multiple contradictory
  approaches exist on how to handle that;
- client-side-validation approach, used by several projects, introduces new
  descriptor-level concepts, like taproot-ebmedded OP_RETURN commitments 
  (so-called "tapret"), which are not handled by existing standards.

As a result, descriptors contain a lot of redundant information, which makes
them bulk, hard to read or type, and impossible to handle in the narrow UI
of hardware wallets.

At LNP/BP Standards Association we'd like to work/coordinate efforts on 
a new BIP proposal removing all the issues above. Before working on the 
BIP proposal text I would like to start by discussing an approach, seeking
Concept (n)ACKs and Approach (n)ACKs from this mail list.


The approach


Existing separate BIP44 standards, committing to a specific form of script
pubkey are made redundant with the introduction of output descriptors. Thus,
I think we need a new BIP44 purpose field which will be used with all 
descriptor formats. The standard must _lexicographically require_ all keys 
to follow the same standard and use the same network and terminal derivation
format. By "lexicographically require" I mean that there must be no 
syntactic option to do otherwise, i.e. the information must not repeat 
within the descriptor for each of the keys and has to be placed in the 
descriptor itself, using prefix (for the network) and suffix (for the 
terminal derivation format):

```
wsh/test(or(
and(1@[fe569a81//1']xpub1..., 2@[8871bad9//1h]xpub2..., 
3@[beafcafe//1']xpub3...), 
and(older(1000), thresh(2, @1, @2, @3))
))/<0;1>/*
```

Please note that each of the keys appears in the descriptor only once, and
is aliased using the `i@` construction preceding the key origin. These
aliases must be incremental starting from `1` (otherwise the descriptor is
invalid). Each other time the same account xpub is used in some other
condition only the alias should be used.

For the mainnet the prefix must be omitted: `wsh(or...)/<0;1>/*`

The descriptor is used to construct derivation for each of the keys 
in the same way:

`m/89'/network'/account'/branch/<0;1>/*`

where:
- 89' is the purpose - an assumed number for the newly proposed BIP;
- `network'` is either `0'` or `1'` and is taken from the descriptor prefix;
- `account` is taken from the xpub origin in the descriptor (it follows the
  master fingerprint and `//` character) and the last `/<0;1>/*` must match
  the descriptor suffix.
- `branch` part, which is a new segment compared to BIP44. This branch index
  must be always unhardened and is computed from the descriptor, starting 
  with 0 for each key and incrementing each time the same key alias is found
  in the descriptor;
- `<0;1>` may contain only 0, 1 index, unless a dedicated BIP extending 
  the meaning of this segment is filed. One such case may be the use of 
  a change index for storing an associated state in client-side-validation,
  like in RGB protocol, where indexes 9 and 10 are used to represent the
  assignation of an external state or the presence of a tapret commitment.
  It is important to require the standardization of new change indexes since
  without that wallets unaware of clinet-side-validation may spend the UTXO
  and burn the external state.


Reference implementation


Once the approach is acknowledged by the mailing list the reference 
implementation will be written on Rust and deployed with MyCitadel wallet 
(https://mycitadel.io), which is the only wallet supporting since spring
2022 combination of all three: descriptors, miniscript and taproot (there 
are more descriptor/miniscript wallets which have appeared over the last 
year, but they are still lacking taproot support AFAIK).


Kind regards,
Maxi

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

[Dr Maxim Orlovsky via bitcoin-dev]

Hi Peter,

Thank you for your comments. My replies are below:

> The section describing this timestamping service simply isn't detailed enough
> to understand what the timestamping service is exactly. Also, I strongly
> suspect you are misusing the term "timestamping" to refer to something 
> entirely
> different.
> Remember that timestamping merely proves data existed in the past. Using that
> term to refer to something with stronger guarantees is an abuse of terminology
> and has caused endless confusion by convincing people that OpenTimestamps (and
> similar schemes) can do things it simply can not.

I agree the section should be extended.

I use the term timestamping to specify that some set of facts was known prior
to some moment time in the past. This is done via headers committing to the
previous header AND to the Merkle root of the commitments to the facts 
(single-use-seals closings).

The stronger guarantees are absent on the level of the header-producing miners
("timestamping layer"). They appear on the level of PMT and client-side-
validated data, which is not timestamping (and not named that way).
Giacomo Zucco in private conversation suggested using "timesealing" for that
part of the system.


> Similarly, I see you using the term "timechain" - stop that. Unless you are
> genuinely talking about timestamping, "timechain" is an atrocious term.

I am afraid you are talking to the wrong person: the only way I use the term 
"timechain" is as a reference to the way Satoshi Nakamoto named it in the
Bitcoin whitepaper. That is a historical fact that can't be changed.

None of the components of the system I described is named "timechain".


> The proofs section claims that "Each network user tracks all new PMTs". This 
> of
> course does not scale, contradicting your scalability claims. To make this
> scalable, you have to explain how to shard the consensus layer, eg as I have
> done in:
> 
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
> 
> as well as:
> 
> https://petertodd.org/2014/tree-chains-preliminary-summary

This does scale since the consensus layer includes only headers of the fixed
size (~200 bytes), which doesn't need sharding. All other data are client-side
and shared by the network users such that each user tracks and keeps only
the data related to his part of the state history. The miners producing
headers and PMTs act independently; the only part which may be large is 
PMT, but (1) they are ephemeral, (2) they are not validated, (3) their knowledge
is not needed to produce the next block. This all is explained in the paper.


> Secondly, even with a way for users to shard that data, you also need to find
> a way for the creators of those Merkle trees to collaborate together in the
> creation of them to call your solution scalable. If you don't, mining will be 
> a
> central point of failure. Again, this was exactly what I was trying to do with
> tree-chains.

The system doesn't require miner collaboration to create Merkle trees.
A miner who does the creation is elected as a leader via consensus protocol
(for instance using PoW) and acts independently - the same way as in Bitcoin
blockchain.


> Finally, you have a serious data availability problem. The nature of
> proof-of-publication-based single-use-seals is that being unable to get access
> to the publication data - even for a single step means you are unable to
> close the seal. You need to discuss this issue in detail, as I do in both
> references above.

I agree that this is the main problem, as well as the only problem which is not
addressed in the paper. I think the data availability problem should be 
abstracted
from the main proposal (like smart contracts and P2P) and I see several ways of
solving it - all these proposals should be evaluated separately from the main
idea (how to do proof-of-publication single-use-seals without blockchain).

The most promising way for my opinion is to use the following scenario:
- in the next (few) header(s) anyone may witness that a miner hasn’t released 
  some or all of the data from a previous PMT
- the miner can appeal and demonstrate that data in the following (few) headers
  by including them in the next header(s)
This should be enhanced with fees cryptoeconomics (the miner should lose fees 
if not providing the data).

In other words, if a miner does not release a tree - or releases it partially -
anybody can witness that fact by including unreleased paths to the next header. 
Then the miner will be penalized for the fees. If this witnessing was false,
the miner has an option to include these paths claimed to be unknown in the 
next headers(s) - get all his fees.


> Single-use-seals are a concept, a mathematical abstraction. You should be
> clear about which specific type of single-use seal you are actually proposing
> here. If I am not mistaken, you are proposing a proof-of-publication-based
> single-use-seal.

Yes, it is proof-of-publication-based single-use-s

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

[Dr Maxim Orlovsky via bitcoin-dev]

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@lists.linuxfoundation.org](mailto:On Sat, Jun 3, 2023 at 4:30 PM, 
John Tromp via bitcoin-dev < 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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Dr Maxim Orlovsky via bitcoin-dev]

Dear community,

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

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

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

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

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

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

With that, I rest my case.

Kind regards,

Maxim Orlovsky

[1]:https://twitter.com/lnp_bp/status/1664329393131364353?s=61&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 

- A few mods are reviewing it 

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

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

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

[Dr Maxim Orlovsky via bitcoin-dev]

Dear community,

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

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

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

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

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

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

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

Re: [bitcoin-dev] RGB protocol announcement

[Dr Maxim Orlovsky via bitcoin-dev]

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 par

Re: [bitcoin-dev] RGB protocol announcement

[Dr Maxim Orlovsky via bitcoin-dev]

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. “Nor

Re: [bitcoin-dev] RGB protocol announcement

[Dr Maxim Orlovsky via bitcoin-dev]

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


Also, we have a number of websites tracking the RGB docs, listed in
 and  - 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:


It is based on our other library which provides encryption:



> 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 '\' | 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:
).

The real RGB code is here, as it is clearly stated in the Github:
* consensus-level 
  - 
  - 
  - 
* integration libraries - 

With the 

[bitcoin-dev] RGB protocol announcement

[Dr Maxim Orlovsky via bitcoin-dev]

TL;DR
-

LNP/BP Standards Association , 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  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 
website, which also contains a number of user and developer guidelines.
RGB source code can be found on 


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 .

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
  

- ### 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 vali

Re: [bitcoin-dev] BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c)

[Dr Maxim Orlovsky via bitcoin-dev]

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 +, 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.
>
>
> ---
>
> 
>   BIP: ?
>   Layer: Applications
>   Title: Pay-to-contract tweak fields for PSBT
>   Author: Maxim Orlovsky ,
>   Andrew Poelstra 
>   Discussions-To: 
>   Comments-URI: 
>   Status: Draft
>   Type: Standards Track
>   Created: 2022-01-16
>   License: BSD-2-Clause
>   Requires: BIP-174
> 
>
> ==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 scriptPubkey, 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
> PSBT_IN_REDEEM_SCRIPT, PSBT_IN_WITNESS_SCRIPT,
> PSBT_IN_TAP_INTERNAL_KEY and PSBT_IN_TAP_LEAF_SCRIPT 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 u

[bitcoin-dev] BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c)

[Dr Maxim Orlovsky via bitcoin-dev]

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.


---


  BIP: ?
  Layer: Applications
  Title: Pay-to-contract tweak fields for PSBT
  Author: Maxim Orlovsky ,
  Andrew Poelstra 
  Discussions-To: 
  Comments-URI: 
  Status: Draft
  Type: Standards Track
  Created: 2022-01-16
  License: BSD-2-Clause
  Requires: BIP-174


==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 scriptPubkey, 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
PSBT_IN_REDEEM_SCRIPT, PSBT_IN_WITNESS_SCRIPT,
PSBT_IN_TAP_INTERNAL_KEY and PSBT_IN_TAP_LEAF_SCRIPT 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
! 
! 
!  Description
! 
!  Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| P2C Key Tweak
| PSBT_IN_P2C_TWEAK = 0x19
| 
| 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.'''Wh

Re: [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin

[Dr Maxim Orlovsky via bitcoin-dev]

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 +, 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@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Dr Maxim Orlovsky via bitcoin-dev]

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


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

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Dr Maxim Orlovsky via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Dr Maxim Orlovsky via bitcoin-dev]

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  wrote:
> 
> 
> On Friday, February 5, 2021 9:51 AM, Dr Maxim Orlovsky via bitcoin-dev 
>  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 rela

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Dr Maxim Orlovsky via bitcoin-dev]

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


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

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Dr Maxim Orlovsky via bitcoin-dev]

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, 0x may do the job.

Kind regards,
Maxim


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

[bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Dr Maxim Orlovsky via bitcoin-dev]

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 a

Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3

[Dr Maxim Orlovsky via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3

[Dr Maxim Orlovsky via bitcoin-dev]

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 

[bitcoin-dev] Storm: escrowed storage and messaging at L2/L3

[Dr Maxim Orlovsky via bitcoin-dev]

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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev