GitBook: [master] 44 pages modified

Author: Varunram

SUMMARY.md

@@ -69,23 +69,48 @@
   * [Advantages](alternate-ideas/bitcoin-lightning-network/advantages.md)
   * [Disadvantages](alternate-ideas/bitcoin-lightning-network/disadvantages.md)
 * [Bitcoin Pre Signed Transactions](alternate-ideas/bitcoin-pre-signed-transactions/README.md)
+  * [Introduction](alternate-ideas/bitcoin-pre-signed-transactions/introduction.md)
   * [Disadvantages](alternate-ideas/bitcoin-pre-signed-transactions/disadvantages.md)
   * [Advantages](alternate-ideas/bitcoin-pre-signed-transactions/advantages.md)
 * [Bitcoin Sidechains](alternate-ideas/bitcoin-sidechains/README.md)
+  * [Introduction](alternate-ideas/bitcoin-sidechains/introduction.md)
   * [Disadvantages](alternate-ideas/bitcoin-sidechains/disadvantages.md)
   * [Advantages](alternate-ideas/bitcoin-sidechains/advantages.md)
 * [Bitcoin Statechains](alternate-ideas/bitcoin-statechains/README.md)
+  * [Disadvantages](alternate-ideas/bitcoin-statechains/disadvantages.md)
   * [Advantages](alternate-ideas/bitcoin-statechains/advantages.md)
+  * [Introduction](alternate-ideas/bitcoin-statechains/introduction.md)
 * [Bitcoin](alternate-ideas/bitcoin/README.md)
+  * [Introduction](alternate-ideas/bitcoin/introduction.md)
   * [Advantages](alternate-ideas/bitcoin/advantages.md)
+  * [Disadvantages](alternate-ideas/bitcoin/disadvantages.md)
 * [Ethereum Sharding](alternate-ideas/ethereum-sharding/README.md)
+  * [Introduction](alternate-ideas/ethereum-sharding/introduction.md)
+  * [Disadvantages](alternate-ideas/ethereum-sharding/disadvantages.md)
   * [Advantages](alternate-ideas/ethereum-sharding/advantages.md)
 * [DeFi and Algorithmic Stablecoins](alternate-ideas/defi-and-algorithmic-stablecoins/README.md)
+  * [Introduction](alternate-ideas/defi-and-algorithmic-stablecoins/introduction.md)
+  * [Disadvantages](alternate-ideas/defi-and-algorithmic-stablecoins/disadvantages.md)
   * [Advantages](alternate-ideas/defi-and-algorithmic-stablecoins/advantages.md)
 * [DAOs](alternate-ideas/daos/README.md)
+  * [Introduction](alternate-ideas/daos/introduction.md)
   * [Advantages](alternate-ideas/daos/advantages.md)
+  * [Disadvantages](alternate-ideas/daos/disadvantages.md)
 * [Cross Blockchain Bridges](alternate-ideas/cross-blockchain-bridges/README.md)
+  * [Introduction](alternate-ideas/cross-blockchain-bridges/introduction.md)
+  * [Disadvantages](alternate-ideas/cross-blockchain-bridges/disadvantages.md)
   * [Advantages](alternate-ideas/cross-blockchain-bridges/advantages.md)
 * [Ethereum](alternate-ideas/ethereum/README.md)
+  * [Introduction](alternate-ideas/ethereum/introduction.md)
+  * [Disadvantages](alternate-ideas/ethereum/disadvantages.md)
   * [Advantages](alternate-ideas/ethereum/advantages.md)
 
+## Ideas
+
+* [Ideas](ideas/ideas.md)
+* [Stellar](ideas/stellar/README.md)
+  * [Introduction](ideas/stellar/introduction.md)
+  * [Advantages](ideas/stellar/advantages.md)
+  * [Disadvantages](ideas/stellar/disadvantages.md)
+* [Stellar](ideas/stellar-1.md)
+

alternate-ideas/bitcoin-lightning-network/README.md

@@ -0,0 +1,2 @@
+# Bitcoin Lightning Network
+

alternate-ideas/bitcoin-lightning-network/advantages.md

@@ -4,4 +4,5 @@
 2. **Faster payments:** Since Lightning transactions are settled immediately, this is faster than having to wait for a block. Lightning transactions can also be asynchronous since there are multiple channels open at the same time.
 3. **Good partner ecosystem:** Many partner companies are available in the Lightning ecosystem and it is easy to leverage their help to improve the functionality of Opensolar. Building on Lightning would also enable the possibility of lightning mobile apps - web platform cross integration, making it easier for receivers to pay back towards projects.
 4. **Improved Functionality:** Lightning offers more functionality \(atomic swaps, state update proofs\) that Opensolar could expand on compared to Stellar, and Lightning core development is faster than Stellar.
-5. **Option to switch between Bitcoin-L1 and Lightning:** For high valued investments, it is easy to leverage Bitcoin-L1's security.
+5. **Option to switch between Bitcoin-L1 and Lightning:** For high valued investments, it is easy to leverage Bitcoin-L1's security.
+

alternate-ideas/bitcoin-lightning-network/disadvantages.md

@@ -2,4 +2,5 @@
 
 1. **Need to manage liquidity:** Since the platform acts as a central provider of liquidity, it maintains a non trivial balance of Bitcoin in open channels and it should manage these balances efficiently. Failure to manage balances efficiently could lead to the platform's inability to open new channels and therefore increase costs. Maintaining channel balances also means there's an amount that is constantly locked and not spendable.
 2. **Need to handle channel closing:** Since lightning is a channel based infrastructure, the platform should be adequately equipped to handle channel closures \(both by the platform, and by the entities on the platform\). An alternative might be that the platform does not offer channel closures to entities on the platform though this comes at the cost of reduced decentralisation.
-3. **Handling large payments:** Lightning is still in its infancy with respect to channel capacity and large amounts that need to be transferred sometimes fail to find a route. One way to handle this is by ramping up channel capacity on the platform's end as needed although this would conflict with 1 above, and make liquidity handling more difficult.
+3. **Handling large payments:** Lightning is still in its infancy with respect to channel capacity and large amounts that need to be transferred sometimes fail to find a route. One way to handle this is by ramping up channel capacity on the platform's end as needed although this would conflict with 1 above, and make liquidity handling more difficult.
+

alternate-ideas/bitcoin-lightning-network/introduction.md

@@ -1,4 +1,4 @@
-# LN Hub and Spoke Model
+# Introduction
 
 In the Hub and Spoke model, the platform \("Hub"\) acts as a centralized hub with which all the entities \("Spokes"\) in the platform interact and have channels with. The hub provides outbound liquidity to all spokes, coordinates payments and handles state updates. The platform does not expose public keys and channel ids, and handles lightning channels and state updates internally. This reduces the possibility of attacks by entities since they don't have a copy of their state \(only the platform does\). This however, this increases trust and responsibility on the platform since the platform should maintain these states in a stable manner, ensuring that no entity defrauds the other. The platform could also hire a watchtower's services in order to provide guarantees on users' channels not closing due to internal platform errors.
 
@@ -26,4 +26,5 @@ Investors holding altcoins can use atomic swap services \(which could either be
 
 The platform should take note of griefing attacks \(ie\) when users sign up as receivers or developers but don't use the account, effectively forcing the platform to lock funds for a pre-defined period of time. This can be avoided by only opening channels with entities that are already associated with a project, and by efficiently closing unused channels.
 
-The trust model in this scenario is that entities trust the platform to push funds to the developer, contractor, create multisig escrows, etc. The availability of proofs in the form of state update hashes and tx ids removes the need for state variables.
+The trust model in this scenario is that entities trust the platform to push funds to the developer, contractor, create multisig escrows, etc. The availability of proofs in the form of state update hashes and tx ids removes the need for state variables.
+

alternate-ideas/bitcoin-pre-signed-transactions/README.md

@@ -0,0 +1,2 @@
+# Bitcoin Pre Signed Transactions
+

alternate-ideas/bitcoin-pre-signed-transactions/advantages.md

@@ -5,3 +5,4 @@
 3. **No stablecoin:** This model does not involve a stablecoin, and people need not trust third party vendors.
 4. **Big partner ecosystem:** Bitcoin has a lot of partner companies which are looking to improve different aspects of using and getting on to Bitcoin. Since the model does not use a stablecoin, the platform can build more on core Bitcoin functionality without worrying about third party stablecoin providers
 5. **Improved functionality:** Bitcoin has more opcodes than Stellar, and can therefore the platform can look to implement more complex functionality.
+

alternate-ideas/bitcoin-pre-signed-transactions/disadvantages.md

@@ -3,3 +3,4 @@
 1. **Less decentralised than Lightning:** Since the platform possesses pre-signed transactions, a malicious platform could refuse to broadcast or delete the transactions, grief attacking the entities involved in the transaction. Although such an attack would come at a reputational risk to the platform, this places more trust on the platform than Lightning.
 2. **Slow confirmation times:** Bitcoin transactions are slower than Stellar transactions, so the platform needs to wait for a given period of time before it can confirm an investment or withdrawal.
 3. **High Fees:** Bitcoin transaction fees vary widely, and sometimes it can be expensive to spend Bitcoin. Since this model does not make use of a stablecoin, the fees associated with a stablecoin is discounted and more than accounts for any Bitcoin transaction fee involved.
+

alternate-ideas/bitcoin-pre-signed-transactions/introduction.md

@@ -1,13 +1,2 @@
-# Bitcoin Pre Signed Transactions
+# Introduction
 
-A bitcoin transaction requires signatures from all private keys associated with input utxos. A transaction can be broadcast to the blockchain at any time provided the spending conditions and associated signatures are still valid at the time of broadcast. As a result, a transaction can be signed beforehand but broadcast when required. Such a transaction is referred to as a "pre-signed transaction". This transaction can have conditions associated to spending \(for example, invest 1000 in this project within 3 months, else refund money to this other address\) that refund to a user if not broadcast within a certain interval of time, can have locktimes that automatically render the spending conditions invalid, etc.
-
-If an investor wishes to invest in a project, they could give a pre-signed transaction to the platform guaranteeing their investment if it reaches the investment threshold. If the investment threshold is reached, the platform checks if the spending conditions and signatures are valid, checks the blockchain to see if the txos are still unspent, and broadcasts the transaction. The investor can also add conditions to investments which are a combination of project conditions and blockchain rules \(example: if this project raises atleast 10000 within 1 month, invest 4000 else wait for project investment and refund after 3 months if project threshold is not reached\), and the platform would check if these are valid at the time of broadcast.
-
-The platform on completion of investment signs transactions paying funds to the developer and contractor but does not publish them until the receiver has marked their role complete and provides proof that the installation was complete. The guarantor gives pre-signed transactions that the platform agrees to not publish unless the receiver defaults on a number of payments.
-
-In the event the investment threshold is not reached, the investor should spend the funds associated with the address to another address or should specify a refund address to the platform. The latter places responsibility for broadcasting the refund transaction onto the platform and the former places emphasis on the investor to transfer their funds as soon as their deadline for investment has is reached.
-
-This model would involve the construction of a secure way to store pre-signed transactions since any user in possession of them can broadcast the transaction, and gried users if they act maliciously. One time passcodes that are relayed on completion of certain events to encrypt the transactions are a potential solution to this problem.
-
-The trust model of this idea relies on the platform not grief attacking its users and not broadcasting funds. At most, the platform has the ability to selectively censor txs, prevent recipients from getting money, etc.

alternate-ideas/bitcoin-sidechains/README.md

@@ -0,0 +1,2 @@
+# Bitcoin Sidechains
+

alternate-ideas/bitcoin-sidechains/advantages.md

@@ -4,4 +4,5 @@
 2. **Fast transactions:** Sidechain transactions are usually faster than Bitcoin-L1, and depending on construction, faster than Stellar.
 3. **Easy integration with Bitcoin-L1 and Lightning:** Sidechain pegs are easy to get in and out of. Onboarding is therefore easier since one can leverage the partner ecosystem of Bitcoin to get into a sidechain.
 4. **More secure decentralised than Stellar:** Sidechains usually have more running nodes than Stellar and therefore, it is less likely a transaction will be censored. Since sidechains are used in combination with Bitcoin-L1, sidechains borrow from Bitcoin-L1's security.
-5. **Low fees:** Sidechains usually have negligible fees as compared to Bitcoin-L1, and sometimes, Stellar.
+5. **Low fees:** Sidechains usually have negligible fees as compared to Bitcoin-L1, and sometimes, Stellar.
+

alternate-ideas/bitcoin-sidechains/disadvantages.md

@@ -3,3 +3,4 @@
 1. **External consensus mechanism:** The sidechain may have its own consensus mechanism and the attack vectors associated with this needs to be reviewed carefully.
 2. **Deposits and Withdrawal delays:** When an entity wants to withdraw funds, they need to wait for the next commitment / merge mined block on Bitcoin, and subsequent confirmations on Bitcoin in order to withdraw their funds. This is usually slow since entities wait for a certain period of time before confirming a transaction on Bitcoin.
 3. **Not time tested:** Sidechains are a relatively new idea, and their security has not been as time tested as Bitcoin. Sidechains however, have not suffered attacks like Stellar.
+

alternate-ideas/bitcoin-sidechains/introduction.md

@@ -1,15 +1,2 @@
-# Bitcoin Sidechains
+# Introduction
 
-Sidechains are similar in design to the Lightning Network and act as a parallel layer for settlement of transactions. They however, differ in architectural construction since they don't have channels or liquidity. Sidechains' design is the same as Bitcoin-L1 except that the block headers are committed at regular intervals to Bitcoin-L1 or their blocks merge-mined along with Bitcoin-L1 with smaller commitments being made in parallel on the sidechain. A sidechain when viewed from the outside looks no different than a standard blockchain., and a platform that adopts Bitcoin-L1 can readily migrate to a sidechain by naking minimal changes.
-
-A sidechain can provide an improved set of features \(eg: the block interval can be smaller, there may be no transaction fees associated with the sidechain, etc\). All bitcoin protocol rules valid in Bitcoin-L1 are valid in a sidechain based on Bitcoin, although a sidechain can be based off a different currency like Ethereum and commit state updates to Bitcoin-L1. A sidechain can also be a federated system, with certain entities having permissions to write to the sidechain and subsequently, Bitcoin-L1.
-
-Each openx platform can be its own sidechain and a centralized coordinator can group the hashes and commit them at regular intervals to Bitcoin-L1. The parent openx platform could itself be a sidechain and different platforms based off openx can be children sidechains which commit to the parent openx sidechain. Functions inside the platform can be same as that on Bitcoin except they can be faster, cheaper and have more features added on to the base layer. Each individual platform need not worry about whether it is running on a sidechain or not since there is no distinction.
-
-An alternate architecture would be one where each platform submits transactions and other changes to the bigger openx platform, and openx decides which sidechain to post the transaction to. Additional features \(that are not present on the Bitcoin base layer\) if used can be marked with flags. Openx can maintain an internal store of the transactions broadcast by a platform. Openx can also broadcast transactions without flags to Bitcoin-L1 depending on the amount transacted and the current fee market. Openx should return a proof to the caller platform \(ideally a tx id\) that the transaction was broadcast, along with a sidechain or Bitcoin-L1 identifier. This identifier can be used on a sidechain or Bitcoin-L1 explorer to identify the transaction.
-
-A sidechain explorer should contain the details of the tx \(like a normal blockchain explorer\) along with the L-1 block the chain's headers were committed to. This way, entities in possession of the proofs can easily cross reference where their transactions were committed. In the alternate architecture, an explorer must display if the transaction was commit to Bitcoin-L1 or a sidechain, and provide an identifier for the same.
-
-A sidechain could also be used in combination with another Bitcoin-L1 or another blockchain with each performing a subset of functions. The sidechain could be used as a layer for updating state and Bitcoin-L1 could be the layer where investments and payments happen.
-
-The trust model for this depends on the sidechain's construction - who can create blocks, who can post transactions, etc. Since opensolar's idea revolves around trusting the platform, the platform can be the entity that performs these functions. Existing sidechains like Liquid or merge mined coins like RSK can also be used in place of a custom sidechain. The trust model for the latter is that one should trust the entities controlling these sidechains along with the platform.

alternate-ideas/bitcoin-statechains/README.md

@@ -0,0 +1,2 @@
+# Bitcoin Statechains
+

alternate-ideas/bitcoin-statechains/disadvantages.md

@@ -1,8 +1,2 @@
 # Disadvantages
 
-1. **Less decentralised than Lightning:** Since the platform acts a a central coordinator for processing statechains, any of the previous owners of the utxo can collude with the platform to steal funds from a user. Such an attack will be public and does come at a reputational cost to the platform but the construction is more centralised than Lightning which does not have any such trust involved.
-2. **Absence of assets:** Since Bitcoin doesn't support assets, there is no ready solution to adopt which can replace assets on Stellar. An alternative is to get rid of assets and handle only proofs.
-3. **Slow confirmation times:** Bitcoin transactions are slower than Stellar transactions, so the platform can not afford to make a lot of synchronous payment requests during the investment workflow. This is a concern only when entering and exiting the statechain since transactions within the statechain are instantaneous.
-4. **High Fees and whole utxos:** Bitcoin transaction fees vary widely, and sometimes it can be expensive to spend Bitcoin. This would affect entities entering and exiting the statechain. Statechains also require complete utxos and splitting utxos should occur as a transaction on Bitcoin-L1, increasing fees and wait times involved.
-5. **Not time tested:** Statechains is a recent development, and hasn't been battle tested for security.
-