ergohackix

docs/dev/scs/ergoscript.md

@@ -5,6 +5,15 @@ tags:
 
 # ErgoScript
 
+## Quick Navigation
+- [Overview](#overview)
+- [Sigma Protocols](#sigma-protocols)
+- [Contract Model](#contract-model)
+- [Key Aspects](#key-aspects)
+- [Examples](#examples)
+
+## Overview
+
 **ErgoScript is a super-simple subset of Scala.** It is a top-level language translated into a low-level language called [ErgoTree](ergotree.md), which is translated during execution into cryptographic protocol. That's how Ergo supports ring and threshold signatures and much more crypto protocols with no special cases made in the core!
 
 /// admonition | Sigma Protocols
@@ -13,48 +22,40 @@ tags:
 Ergo's support for [sigma-protocols](sigma.md) (aka generalized Schnorr proofs) are truly unique as building blocks for composable statements. [Schnorr protocols](schnorr.md) and [proof-of-Diffie-Hellman-tuples](diffe.md) are supported by default, with more options available that the community can add via soft forks.
 ///
 
-
-ErgoScript is built considering Bitcoin’s security and privacy to make all kinds of complex financial contracts accessible. In comparison, Bitcoin’s design doesn’t allow loops or building any complex smart contracts on top of it. ErgoScript allows for self-replication; therefore, we can use it to create Turing-Complete processes in a blockchain.
-
-
+ErgoScript is built considering Bitcoin's security and privacy to make all kinds of complex financial contracts accessible. In comparison, Bitcoin's design doesn't allow loops or building any complex smart contracts on top of it. ErgoScript allows for self-replication; therefore, we can use it to create Turing-Complete processes in a blockchain.
 
 //// details | Background Reading
     {type: info, open: false}
 /// details | **What are the key aspects of the Ergo contract model that make it different?**
     {type: info, open: false}
 
-##### Paradigm
+### Paradigm
 
 The account model of Ethereum is imperative. This means that the typical task of sending coins from Alice to Bob requires changing the balances in storage as a series of operations. Ergo's UTXO-based programming model, on the other hand, is declarative. ErgoScript contracts specify conditions for a transaction to be accepted by the blockchain (not changes to be made in the storage state due to the contract execution).
 
-##### Scalability
+### Scalability
 
 In the account model of Ethereum, both storage changes and validity checks are performed _on-chain_ during code execution. In contrast, Ergo transactions are created _off-chain_, and only validation checks are performed on-chain, thus reducing the number of operations performed by every node on the network. In addition, due to the immutability of the transaction graph, various optimization strategies can improve the throughput of transactions per second in the network. [Light verifying nodes](nipopow_nodes.md) are also possible, thus further facilitating scalability and accessibility of the network.
 
-##### Shared state
+### Shared state
 
 The account-based model relies on the shared mutable state, which is known to lead to complex semantics (and subtle million-dollar bugs) in the context of concurrent/ distributed computation. Ergo's model is based on an immutable graph of transactions. This approach, inherited from Bitcoin, plays well with blockchains' concurrent and distributed nature and facilitates light trustless clients.
 
-##### Expressive Power
+### Expressive Power
 
 Ethereum advocated the execution of a Turing-complete language on the blockchain. It theoretically promised unlimited potential; however, severe limitations came to light from excessive blockchain bloat, subtle multi-million dollar bugs, gas costs that limit contract complexity, and other such problems. Ergo on the flip side, extends UTXO to enable Turing completeness while limiting the complexity of the ErgoScript language itself. The same expressive power is achieved differently and more semantically soundly.
 
-
 ///
 /// admonition | Simple Example
     type: info
 
-
-
 ```scala
 if (HEIGHT < 100000) alicePubKey else bobPubKey
 ```
 
 1. Allows Only Alice to spend a box before a certain height 
 2. Allows Only Bob to spend the box after that.
 
-
-
 ///
 /// admonition | Key Concepts
     type: info
@@ -75,9 +76,29 @@ ErgoScript is a high-level developer-friendly language for writing smart contrac
 ///
 ////
 
-
 /// admonition | Getting Started
     type: note
 
 Please see this [Quick Primer on ErgoScript](/dev/scs/ergoscript-primer) for an overview of key concepts and some basic examples.
 ///
+
+## Related Technical Resources
+- [ErgoTree Documentation](ergotree.md)
+- [Sigma Protocols Overview](sigma.md)
+- [Schnorr Signatures](schnorr.md)
+- [Light Verifying Nodes](nipopow_nodes.md)
+- [UTXO Model Explanation](/dev/protocol/eutxo)
+
+## Comparative Analysis
+ErgoScript stands out by:
+- Providing Turing-completeness without compromising blockchain efficiency
+- Supporting advanced cryptographic protocols
+- Enabling complex financial contracts with minimal overhead
+- Maintaining a declarative, secure programming model
+
+## Performance Considerations
+- Off-chain transaction creation
+- On-chain validation only
+- Immutable transaction graph
+- Supports light verifying nodes
+- Controlled Turing-completeness

docs/dev/wallet/minotaur-multisig.md

@@ -250,3 +250,50 @@ The first signer also creates his/her commitment and sends the following JSON to
 
 
 
+## Signing Server for Multi-Sig Communication (ErgoHack IX)
+
+### Introduction
+
+
+
+Minotaur is the first multi-signature wallet developed for Ergo. A multi-signature wallet, or multi-sig wallet, uses more than one private key to authorize transactions. Such a wallet can be managed by a single user holding multiple private keys, multiple users holding a single key each, or any combination of the two scenarios. In a multi-sig wallet with *M* private keys, depending on its configurations, any transaction may require *N* signatures, where *1 <= N <= M*.
+
+Signing any multi-sig transaction on the Ergo chain consists of two major steps that must be completed by any *N* signer(s) among the *M* key-holders:
+
+1. Generating required commitment(s) and sharing them with all other signers (*N* times).
+2. Signing the transaction using gathered commitments (*N* times).
+
+In Minotaur, an *N*-sig transaction is performed as follows:
+
+- The first signer, i.e., a key-holder who creates the transaction, generates his/her own commitment(s) and, including all other required data, sends it to a second signer.
+- A second signer receives the transaction data, appends his/her own commitment(s) to it, and sends it to a third signer.
+- The process is repeated by all other signers, except the last one.
+- The last signer receives commitments of all other signers. He/She generates his/her own commitment(s) and appends it to the transaction data, and finally signs the transaction. Then, the partially signed transaction is sent to another signer.
+- Any middle signer signs the transaction and passes it to another one.
+- The last one who adds the last signature to the transaction publishes the fully-signed transaction.
+
+The process is error-prone. In fact, any human error in sending commitment(s) and using invalid commitment sets results in an invalid, and thus incomplete, transaction. Such failures have been reported frequently.
+
+In order to solve this problem, we introduce the Minotaur Signing Server, which manages the signing process and ensures a valid and completed transaction.
+
+For more details and to access the code, please visit the following repositories:
+
+- [Minotaur Wallet Code](https://github.com/minotaur-ergo/minotaur-wallet/tree/ergo-hack-multi-sig-signing-server)
+- [Minotaur Signing Server (MSS) Code](https://github.com/minotaur-ergo/Minotaur-Signing-Server/tree/fix-some-incompatibilities)
+
+
+### The Minotaur Signing Server
+
+The Minotaur Signing Server (MSS) manages the steps of transaction signing. The MSS provides a safe, reliable, secure, and error-free channel for data transition among signers. Therefore, it can guarantee that every signer receives and uses correct transaction data.
+
+The workflow of the MSS is as follows:
+
+1. First, each of the wallet key-holders must generate an asymmetric key-pair for communication with the server. We refer to these keys as the communication private and public keys. The MSS expects every signer to sign his/her communication public key with his/her transaction-signing key in order to confirm the signer's identity.
+2. The MSS needs the multi-sig wallet details, including the extended public key of each signer and also the number of required signatures. Any of the key-holders can provide the MSS with this data. It is only after receiving this data that the MSS allows for the processing of any transaction.
+3. At this stage, the multi-sig wallet setup is completed, and any number of transactions can be started. A new transaction is started as follows:
+   - The person who creates the transaction sends it to the MSS. From now on, each of the wallet holders will see the transaction on their multi-sig communication page of their connected Minotaur. The representation of data on the page has not been altered by the introduction of MSS, and the user may not sense any UI change.
+   - Any of the signers can select the desired transaction and generate their commitment(s) for it. By doing so, the private part of the commitment(s) is stored in Minotaur, and its public part is sent to the MSS.
+   - Anyone who receives the transaction also receives all previous public commitments. He/She can add his/her own commitment(s) as described above.
+4. As soon as the server receives all *N* commitments, the transaction is automatically sent for signing. In case any simulated signatures are required, they are created by the MSS. Moreover, any commitments that arrive after this point are rejected.
+5. At this stage, anyone who committed the transaction can sign it and send his/her signature to the MSS.
+6. As soon as all *N* signatures arrive at the MSS, it automatically completes the transaction and sends it on the blockchain.

docs/dev/wallet/satergo-vault.md

@@ -0,0 +1,58 @@
+# Satergo Offline Vault
+
+## About
+
+An Android application that starts a Bluetooth Low Energy (BLE) service which accepts connections from other devices. The application stores your encrypted seed phrase and when the device connected to it (for example, a desktop computer with Satergo) requests things the user needs to accept them on the mobile device. This is more secure compared to keeping the wallet file on the computer where it is decrypted on that same computer when the password is entered, so malware could steal the seed phrase/private key and take all the funds if the computer is infected.
+
+With Satergo Offline Vault, even if the computer is infected with malware, it will not matter because the Android mobile device never needs to connect to the internet and as such has a very low risk of getting infected with malware. The application will keep the seed phrase securely contained in the private directory of itself. Not the user nor other applications on an Android device can access another app's private folder (the one located at /data/data/ in the filesystem). The only way that could be accessed is with a full system root exploit which are rare nowadays and also would unlikely be possible to be performed remotely over Bluetooth. Official methods of rooting involve wiping the entire device which means that there is no way to even access the encrypted seed phrase without a very serious exploit.
+
+The seed phrase is encrypted using AES and cannot be decrypted without the password that was originally used when creating/restoring the wallet.
+
+## Example of how one might use it
+
+- A user installs Satergo on his computer
+- He chooses to create a new wallet using the Satergo Offline Vault feature
+- He transfers the APK file of Satergo Offline Vault to his Android device without using internet (for example, over Bluetooth)
+- He installs it on his Android device and creates a new wallet. This seed phrase is random and will never leave the device unless the user himself decrypts it using the "View seed" feature and enters it somewhere. As usual the seed phrase should be noted down on something that is not digital.
+- The user pairs Satergo on his computer with Satergo Offline Vault on his phone
+- Satergo now needs the public key of the wallet, so it requests it. Satergo on the computer cannot do anything until the user accepts the request that has now appeared on his Android device. The public key is not encrypted, so just accepting the request is enough.
+- The user makes a transaction using Satergo (desktop), which then sends the unsigned transaction to the phone. As the seed phrase is encrypted, the user needs to enter his password on the phone to decrypt it and use it for signing the transaction. The seed phrase is never sent anywhere.
+- The signatures are sent back to the Satergo wallet on the desktop, provided the user accepted the request on his phone after viewing what it would spend from the wallet.
+
+## Tasks done in this ErgoHack
+
+- Programmed an entire Android application that securely stores wallet details, starts a Bluetooth LE service and performs actions (signing transactions) with the confirmation of the user.
+- Programmed (in a new branch of the Satergo git repository) a Linux implementation for the BLE service.
+
+The application is working.
+
+## More information
+
+- The application will not be on the Google Play Store as that would need an internet connection to be downloaded.
+- Other wallet programs are welcome to implement support for Satergo Offline Vault.
+
+## Improvements that can be made
+
+- Satergo should download the APK so that all the user needs to do is to transfer it and not have to download it as well.
+- Satergo Offline Vault's implementation supports having multiple wallets, however this needs to be made available in the user interface as well.
+- Support for other desktop operating systems. Since Bluetooth is differently implemented on each platform, the current implementation is only for Linux (bluez).
+
+## Threat model
+
+There is no code in app that sends your seed phrase anywhere. Whatever the device or application connected to your mobile device sends to it, it will not respond with anything except for:
+
+- The application version (Sent without confirmation)
+- The extended public key (Confirmation needed) which is used to derive the public addresses of the wallet
+- Signatures for transactions (Confirmation & password needed)
+
+In the case of Bluetooth vulnerabilities, even if an attacker would be able to establish a connection using one, they cannot access the private key because only the app can access it unless the device is rooted. This means that the Bluetooth vulnerability would need to have an exploit chain that also has a root exploit.
+
+Root exploits are rare and are very serious as they give full control of the device to the attacker. Even if there was such an exploit it would not be able to access the contents of the file as it is encrypted with your password. A very sophisticated virus could however monitor everything on the phone and find the password when entered. Summary of what it would take:
+
+- A full Android Bluetooth exploit
+- A full Android root exploit that can be performed over Bluetooth, to install purpose-built malware on the device
+- The user entering the password while still being near the attacker or connected to the internet
+
+This is in my opinion very far-fetched.
+
+

docs/dev/wallet/satergo.md

@@ -21,3 +21,5 @@ Satergo's cross-platform support ensures a consistent and reliable experience ac
 - Follow the latest updates on [Twitter](https://twitter.com/SatergoWallet)
 - Join the community on [Telegram](https://t.me/Satergo)
 - Contribute or explore the code on [GitHub](https://github.com/Satergo)
+- Learn more about the [Satergo Offline Vault](satergo-vault.md), an Android application that securely stores your encrypted seed phrase and connects with desktops via Bluetooth for transaction safety.
+