rooch-network
[rooch] support Bitcoin network protocol from nostr example
At the time of writing, Rooch doesn't support Bitcoin related protocol.
nostr, on the other hand, supports Bitcoin protocols, and by supporting nostr on Rooch, we can further support Bitcoin networking infrastructure on Rooch.
We should support secp256k1 curve on account's keys and Schnorr signatures on Bitcoin network, Bitcoin address mapping to Rooch address on protocols of P2PKH, P2SH, and Bech32, sha256 of Bitcoin hashes, etc. In essence, referential implementations of Bitcoin protocols on nostr should be supported as well as on Rooch.
Currently, there are several ways to implement nostr on Rooch:
- Use Rooch as a library to connect nostr relays.
- Use Rooch as a relay.
Perfectly, we should support 2 as the ultimate decentralized solution, that everyone can run a Rooch node as a nostr relay.
We also need a transactional executor for nostr events, perfectly using Move, to store to the merkle tree state and retrieve the state from.
I will take handle on this issue to further support Bitcoin infrastructure on Rooch.
Task division:
- #407
- #444
- #445
- #446
- #457
- #469
- https://github.com/rooch-network/fastcrypto/pull/1
- #482
- #514
Following discussions on Discord:
https://discord.com/channels/1078938449974935592/1124908489525960714
Please clarify which Bitcoin protocols we would like to support.
We should support basic secp256k1 protocol of bitcoin as nostr uses it to implement account keys.
Nostr's key infrastructure uses schnorr, XOnlyPublicKey, SecretKey, KeyPair, respectively.
You can refer to this I have added to PR draft: https://github.com/rooch-network/rooch/pull/408/files#diff-3b5b019d0ba29ef5f2611225e57614771b1a38b6a1c75552f0a49a57dfb2cba7R14
Furthermore, we should also support bitcoin address mapping, e.g. Taproot address and earlier address implementations of Bitcoin, to Rooch address to achieve mutually binding, and other libraries nostr implements as listed here:
https://docs.rs/nostr/latest/nostr/index.html#reexports
- secp256k1 has been supported.
Yes it is true. It seems that ECDSA over secp256k1 is supported.
- bitcoin address mapping is also supported.
This might not be true. From my testing experience at:
https://github.com/rooch-network/rooch/blob/3479ffc15a3fffc865183353959aff37ef36f4a4/crates/rooch-types/src/address.rs#L366
The test only generates addresses starting 1, which are P2PKH addresses. P2PKH addresses use HASH160 library for hashing.
We should also support addresses of protocol starting 3 and bc1 for P2SH and Bech32, respectively, at least for testing the addresses.
Reference:
https://en.bitcoin.it/wiki/Invoice_address
Also, nostr uses Schnorr algorithm for creating and verifying signatures, which isn't supported at Rooch. The algorithm is commonly used on Bitcoin Lightning Networks and key-breaking multi-sig hardwares.
Reference:
https://en.bitcoin.it/wiki/Schnorr https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki https://github.com/nostr-protocol/nostr/issues/4#issuecomment-751920548
Rooch's BitcoinAddress is a wrap of bitcoin::Address. It likes is supports all Bitcoin address types.
Rooch's BitcoinAddress is a wrap of bitcoin::Address. It likes is supports all Bitcoin address types.
This isn't totally correct. The BitcoinAddress at Rooch is wrapped bitcoin::Address, while its random() function is bitcoin::address::Payload::PubkeyHash, which is P2PKH address leading in 1 as below:
/// The method used to produce an address.
#[derive(Debug, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)]
#[non_exhaustive]
pub enum Payload {
/// P2PKH address.
PubkeyHash(PubkeyHash),
/// P2SH address.
ScriptHash(ScriptHash),
/// Segwit address.
WitnessProgram(WitnessProgram),
}
Generally the test function is using random() which only supports H160 for Ethereum and Bitcoin.