├── .gitignore ├── README.md ├── advice_for_beginners.md ├── api ├── api_examples.md ├── commands.md ├── commands_accounts.md ├── commands_advanced.md ├── commands_basics.md ├── commands_channels.md ├── commands_history.md ├── commands_market.md ├── commands_mining.md ├── commands_oracle.md ├── commands_other.md ├── commands_unsigned.md ├── keys.md ├── meta_block.md ├── securing_keys.md └── using_channels.md ├── attacks_analyzed ├── LN_mempool_attack.md ├── ambiguous_oracle.md ├── computationally_heavy_blocks.md ├── invalid_oracles.md └── unclosable_channels.md ├── basics ├── .#applied_trust_theory.md ├── atomic_swaps.md ├── backup.md ├── blockchain_engineers_manifesto.md ├── blockchain_war.md ├── channel_smart_contracts.md ├── cold_storage.md ├── connecting_blockchains.md ├── customer_pitch.md ├── financial_derivatives.md ├── full_node_with_slow_connection.md ├── futarchy.md ├── futarchy2.md ├── futarchy_efficiency.md ├── investor_pitch.md ├── market_cap.md ├── market_failure.md ├── merkle.md ├── msrs_and_prediction_markets.md ├── oracle_security_question.md ├── public_goods.md ├── scam_immunity.md ├── science_of_blockchain.md ├── smart_contract_creation.md ├── spamming_for_control.md ├── stablecoin.md ├── trust_theory.md ├── trust_theory_1.1.md ├── trust_theory_2.2.md ├── updating.md ├── using_dac.md ├── using_governance.md ├── using_oracle.md └── vanity.md ├── blog_posts ├── 3_year_anniversary.md ├── 4th_year_summary.md ├── 5th_year_summary.md ├── 6th_year_summary.md ├── DEX_7_feb_2021.md ├── DEX_feb_2021.md ├── african_land.md ├── alternatives_to_futarchy.md ├── amoveo_breakdown.md ├── assassination_defense.md ├── auction_merged_mining.md ├── character_class_selection.md ├── coin_hours.md ├── composing_amm_with_conditional_contracts.md ├── composing_conditional_for_perpetual_stablecoins.md ├── composing_conditional_prevent_frontrunning.md ├── cryptography_usecases.md ├── difficulty_oscillations.md ├── elevator_pitch.md ├── enlightenment.md ├── explicacion_corto.md ├── fast_oracles_worthless_goal.md ├── faster_verkle_proofs.md ├── fiat_vs_cryptocurrency.md ├── futarchys_back.md ├── futarchys_failure.md ├── harberger_defence.md ├── harberger_interest_rate.md ├── impersonator_scams.md ├── monetary_theory.md ├── optimistic_rsa.md ├── oracles_overview.md ├── overview_3_1_22.md ├── parallel_blocks_flexible_ordering.md ├── pedersen_commits.md ├── philosophy_of_blockchains.md ├── private_oracles.md ├── rsa_accumulators.md ├── sidechain_tx_data.md ├── trading_key.md ├── trustless_employment.md ├── voting_in_post_futarchy_world.md ├── why_derivatives_need_harberger.md └── why_we_need_blockchain_land.md ├── checklists ├── new_merkel_tree_checklist.md ├── new_testnet_checklist.md └── update_announcement_checklist.md ├── community_roadmap.md ├── contributions.md ├── crosschain_dex ├── README.md ├── atomic_swap.md ├── binance.md ├── bisq.md ├── chainflip.md ├── incognito.md ├── ren.md ├── serum.md └── thorchain.md ├── design ├── accounts.md ├── amoveo_interview_plan.md ├── asics_roadmap.md ├── batch_channel.png ├── batch_channel_unbalanced.png ├── betting_fees.md ├── blocks.md ├── blocks_headers_mining_work.md ├── byzantine_rationality.md ├── censored_orders_in_channel.md ├── centralized_trust_free.md ├── channel_state.md ├── channels.md ├── channels_untrusted_slasher.md ├── channels_usability.md ├── consensus_efficiency.md ├── contract_ddos.md ├── cryptoeconomics.md ├── dapp_developer_introduction.md ├── developer_reward.md ├── do_not_buy_amoveo.md ├── elixir.md ├── ending_contracts_early.md ├── ethereum_comparison.md ├── extra_light_security.md ├── faq_spiegel.md ├── faucet.md ├── futarchy.md ├── futarchy_correlation_math.md ├── futarchy_for_blockchain_updates.md ├── futarchy_market.md ├── goal_narrative.md ├── governance.md ├── hard_drive_consumption.md ├── hard_fork.md ├── harmonic_rng.md ├── hedging.md ├── hedging_risk_is_decentralized_decision_making.md ├── history.md ├── how_to_use_channels.md ├── insurance.md ├── light_nodes.md ├── limit_order_in_channel.md ├── memoryless_full_node.md ├── miner_incentives.md ├── more_harmonic_evidence.md ├── onboarding_dex.md ├── oracle.md ├── oracle_flowchart.md ├── oracle_motivations.md ├── oracle_simple.md ├── peers.md ├── pos_research.md ├── privacy.md ├── private_oracles.md ├── probabalistic_state_channels.md ├── profiting_off_amoveo.md ├── programmable_probabilistic_payments.md ├── programmable_state_channels.md ├── questions.md ├── retargeting_in_ethereum.md ├── retargetting_stability.md ├── risk_hedge_futarchy.md ├── scalability.md ├── scalar_oracles.md ├── sharding.md ├── shareable_contracts_implementation.md ├── smart_contracts.md ├── smart_contracts_as_derivatives.md ├── sortition_scaling │ ├── README.md │ ├── sortition_chain_history.md │ ├── sortition_chain_rollup.md │ ├── sortition_chains.md │ ├── sortition_chains_defense.md │ ├── sortition_chains_implementation.md │ ├── sortition_chains_random.md │ ├── sortition_chains_theory.md │ └── sortition_pools.md ├── state_channel_without_off_chain_market.md ├── stateless_full_node.md ├── subcurrencies.md ├── threshold_signature_anonimity.md ├── transaction_types.md ├── trees.md ├── trustless_exchange.md ├── trustless_withdraw.md ├── truthcoin_contracts.md ├── uncertainty_rng.md ├── using_governance.md ├── viral_info_plan.md ├── volatility.md ├── voting_in_blockchains.md ├── why_asics.md ├── why_markets.md ├── why_not_channel_slash_reward.md ├── why_not_channels_with_multiple_currencies.md └── why_not_pos.md ├── exchanges └── graviex_links.md ├── expired └── oracle_manipulation.md ├── failure_reports ├── 22_5_2019.md ├── 30_5_2019.md ├── 3_1_2021.md └── 8_6_2019.md ├── faq.md ├── getting-started ├── build_intro.md ├── crypto_economics_political_inhibitions.md ├── dependencies.md ├── erlang_install.md ├── firewall.md ├── git_intro.md ├── linux_dependencies.md ├── mac_dependencies.md ├── mining.md ├── mining_pool_survival.md ├── nixos_install │ ├── NixosInstall.bin │ ├── README.md │ └── install.sh ├── p2p_derivatives_beta.md ├── ports.md ├── profiting_from_amoveo.md ├── quick_start_developer_guide.md ├── reporting_bugs.md ├── solo_mining.md ├── sync.md ├── turn_it_on.md ├── updating.md └── using_epmd.md ├── history_state_channels.md ├── icos.md ├── investing.md ├── license_note.md ├── light_node ├── glossary │ ├── accepting_channel_offer.md │ ├── binary_bet.md │ ├── binary_oracle.md │ ├── collateral.md │ ├── derivatives_payment.md │ ├── messenger_credits.md │ ├── oracle.md │ ├── oracle_id.md │ ├── oracle_question.md │ ├── oracle_starts.md │ ├── oracle_types.md │ ├── scalar_bet.md │ ├── scalar_oracle.md │ ├── stablecoin_bet.md │ ├── stablecoin_current_value.md │ └── stablecoin_leverage.md ├── make_channel.md ├── market.md ├── p2p_derivatives.md └── user_stories.md ├── merging-and-testing ├── git_hints.md ├── merging_rules.md ├── rebar_lock.md ├── rebase.md ├── testing.md └── unit_testing.md ├── mission_statement.md ├── other_blockchains ├── AeternityScam.md ├── Emin_Gun_Sirer.md ├── Feb_2020_defi_hack.md ├── Nimiq │ └── 17_10_17.md ├── RCO.md ├── README.md ├── UMA.md ├── algorand.md ├── avalanche.md ├── bitcoin.md ├── bitcoin_pow.md ├── bitcoin_without_block_rewards.md ├── blitzkrieg_freedom_project.md ├── bonding_curves.md ├── bribery.md ├── chainlink.md ├── cosmos.md ├── decred.md ├── dfinity_rng.md ├── drivechain.md ├── dxdy.md ├── ethereum_casper_ffg.md ├── fast_oracles.md ├── gnosis_dutch_exchange.md ├── gnosis_multi_token_batch_auction.md ├── idena.md ├── idex_sidechains.md ├── iota.md ├── makerdao.md ├── meta_doa.md ├── numerai.md ├── nyzo.md ├── optimistic_rollups.md ├── optimistic_rollups_fraud_proof_cost.md ├── optimistic_rollups_sidechain_attack.md ├── ouroboros.md ├── over_generalization_in_blockchain_design.md ├── parasite_contracts.md ├── perpetual_swap.md ├── polkadot.md ├── pos_organizer.md ├── pos_time_warp_attack.md ├── pow_pos_hybrid.md ├── proof_of_stake.md ├── radar_relay.md ├── razor_network.md ├── ripple.md ├── rough_draft.md ├── security_model.md ├── sharding.md ├── spectreDAG.md ├── synthetix.md ├── tellor_oracle.md ├── tessr.md ├── the_defence_of_pos.md ├── the_defence_of_pow.md ├── town_crier.md ├── uniswap.md ├── veriblock.md ├── veriblock_offloading.md ├── witnet.md ├── zano.md └── zilliqa.md ├── progress_reports ├── 16_december_2017.md ├── 22_november_2017.md ├── Amoveo_Ikigai_review.pdf ├── April_2018.md ├── August_2018.md ├── August_2018_summary.md ├── December_2017_progress.md ├── February_2018.md ├── January_2018.md ├── January_2018_summary.md ├── June_2018.md ├── June_2018_summary.md ├── March_2018.md ├── March_2018_summary.md ├── March_2019.md ├── May_2018.md ├── November_2018.md ├── Paul_Sztorc_Quick_Review.md ├── augur_comparison.md ├── code_elegance_24_november_2017.md ├── december_2017.md ├── november_2017.md ├── october_2017.md ├── testnet_19_10_2017.md ├── tx_speed_January_2018.md └── warning.md ├── research_suggestions ├── README.md ├── blockchain_cities.md ├── economics_of_blitzkrieg_payments.md ├── futarchy_spending.md ├── parasite_contracts.md ├── retargetting.md ├── secure_light_node_download.md └── simpler_oracle.md ├── rewards.md ├── swap_offers.md ├── todo.md ├── update_all_files.erl ├── use-cases-and-ideas ├── Harvey_Weinstein.md ├── abortion.md ├── anarchy_series.md ├── betting_market.md ├── bike_shedding.md ├── climate_maintenance.md ├── collateralized_loans.md ├── crypto_self_regulation.md ├── derivative_liquidation.md ├── dominant_assurance_contract.md ├── dominant_assurance_contract_JP.md ├── financial_options.md ├── flat_hierarchy.md ├── funding_development.md ├── futarchy-idol.md ├── futarchy.md ├── go_game_predictions.md ├── harberger_land.md ├── insurance.md ├── insured_crowdfund.md ├── lie_detector.md ├── military_spending.md ├── nft.md ├── north_korea.md ├── options.md ├── prediction_market.md ├── religion.md ├── stablecoin.md ├── tragedy_of_commons_in_voting.md ├── trustless_markets.md └── website_security.md ├── warning.md ├── white_paper.md ├── white_paper2.md └── why_I_left.md /.gitignore: -------------------------------------------------------------------------------- 1 | .idea 2 | .edts 3 | *.iml 4 | _build 5 | /rel/ 6 | *.db 7 | *~ 8 | .#* 9 | \#* 10 | .rebar 11 | erl_crash.dump 12 | keys_backup 13 | lib/ 14 | bin/ 15 | .Python 16 | include/ 17 | *.pyc 18 | nosetests.xml 19 | pip-selfcheck.json 20 | config/*/sys.config 21 | man 22 | compile_commands.json 23 | deps/* 24 | rebar.lock 25 | .DS_Store 26 | sys.config.tmpl -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Amoveo Docs 2 | ========== 3 | 4 | This repository is for documentating the [Amoveo](https://github.com/zack-bitcoin/amoveo) cryptocurrency. 5 | 6 | -------------------------------------------------------------------------------- /advice_for_beginners.md: -------------------------------------------------------------------------------- 1 | I would like you to ask questions if anything is confusing, and don't be afraid of wasting anyone's time. Answering questions for beginners is one of the most valuable things we can be doing at this point in time. It helps us to build better documentation, and to increase the coefficient of our exponential growth rate. -------------------------------------------------------------------------------- /api/api_examples.md: -------------------------------------------------------------------------------- 1 | Example of how to add a node to the list of nodes you share blocks with. This is an example of accessing the local api on the same machine. 2 | 3 | ``` 4 | curl -i -d '["add_peer", [127,0,0,1], 3011]' http://localhost:8041 5 | ``` 6 | 7 | #example response 8 | 9 | ``` 10 | HTTP/1.1 200 OK 11 | server: Cowboy 12 | date: Fri, 14 Apr 2017 09:49:41 GMT 13 | content-length: 4 14 | content-type: application/octet-stream 15 | Access-Control-Allow-Origin: * 16 | 17 | "ok" 18 | ``` 19 | 20 | example of executing this api request from javascript 21 | first make sure that rpc.js is loaded, then you can do this: 22 | 23 | ``` 24 | local_get(["add_peer", [127,0,0,1], 3011]); 25 | ``` 26 | 27 | [The internal API is defined here](../src/networking/internal_handler.erl) 28 | 29 | Now an example of accessing an api of a different node. 30 | This is how you request the header of the genesis block. 31 | Notice that the ip for external api is one lower than the ip for the api that is only on the same node. 32 | 33 | ``` 34 | curl -i -d '["header", 0]' http://localhost:8040 35 | ``` 36 | 37 | example response 38 | 39 | ``` 40 | HTTP/1.1 200 OK 41 | server: Cowboy 42 | date: Fri, 14 Apr 2017 09:56:29 GMT 43 | content-length: 53 44 | content-type: application/octet-stream 45 | Access-Control-Allow-Origin: * 46 | 47 | ["ok","AAAAAAAAAAAAAAAA1oYN5PPka/zJxej5AAAAAAAP8AAB"] 48 | ``` 49 | 50 | Here is an example of accessing the genesis block from javascript. you need to load rpc.js before you can do this. 51 | 52 | ``` 53 | function callback(x) { 54 | console.log("the header is "); 55 | console.log(x); 56 | }; 57 | variable_public_get(["header", 0], callback); 58 | ``` 59 | 60 | [The external API is defined here](../../apps/amoveo_http/src/ext_handler.erl) 61 | 62 | [The internal API is defined here](../../apps/amoveo_http/src/api.erl) 63 | -------------------------------------------------------------------------------- /api/commands.md: -------------------------------------------------------------------------------- 1 | Terminal interface commands 2 | ============= 3 | 4 | 5 | Different types of commands: 6 | 7 | [blockchain_basics](commands_basics.md) 8 | 9 | [accounts](commands_accounts.md) 10 | 11 | [keys](keys.md) 12 | 13 | [lookup history](commands_history.md) 14 | 15 | [oracle](commands_oracle.md) 16 | 17 | [other](commands_other.md) 18 | 19 | -------------------------------------------------------------------------------- /api/commands_accounts.md: -------------------------------------------------------------------------------- 1 | Commands related to accounts 2 | ========= 3 | 4 | The full node can also work as a wallet. 5 | 6 | #### Find out your account pubkey in external base64 format 7 | ``` 8 | api:pubkey(). 9 | ``` 10 | It returns pub key that identifies an account 11 | 12 | 13 | #### Check your balance 14 | ``` 15 | api:balance(). 16 | ``` 17 | 18 | Your encrypted private key is stored in 19 | `_build/prod/rel/amoveo_core/keys/keys.db` 20 | Save a copy. 21 | 22 | [WARNING!!! make sure your wallet is secure!](keys.md) 23 | #### Spend to account pubkey `To` 24 | ``` 25 | api:spend(To, Amount). 26 | api:spend(base64:decode(<<"BBH26TpQgvscsPWyfIz3zjSA4wopZrVKf3mYktTd2xnjOYi/MW5AXODhK4ZZnud2DeRFkyVlq9q5zESFqbWJCE8=">>), 123). 27 | ``` 28 | this send 123 satoshis = 0.00000123 Veo 29 | 30 | 31 | #### Multi-spend 32 | This is used to make one tx that spends veo to multiple recipients. 33 | This spends 500 satoshis to one account, and 450 to another: 34 | ``` 35 | api:spend([{500, base64:decode(<<"BBH26TpQgvscsPWyfIz3zjSA4wopZrVKf3mYktTd2xnjOYi/MW5AXODhK4ZZnud2DeRFkyVlq9q5zESFqbWJCE8=">>)},{450, base64:decode("BCjdlkTKyFh7BBx4grLUGFJCedmzo4e0XT1KJtbSwq5vCJHrPltHATB+maZ+Pncjnfvt9CsCcI9Rn1vO+fPLIV4=")}]). 36 | ``` 37 | 38 | ####Look up an account 39 | ``` 40 | api:account(Pub). 41 | ``` 42 | 43 | #### check mempool to see if tx was created correctly 44 | ``` 45 | tx_pool:get(). 46 | ``` 47 | 48 | ### look up transaction history of an account in the last 100 blocks. 49 | ``` 50 | api:address_history(Pubkey, 100, api:height()). 51 | ``` 52 | 53 | #### share your txs with peer P 54 | ``` 55 | P = lists:nth(2, peers:all()). 56 | api:txs(P). 57 | ``` 58 | -------------------------------------------------------------------------------- /api/commands_advanced.md: -------------------------------------------------------------------------------- 1 | 2 | Sync-mode should handle itself automatically, so you will probably never need these commands: 3 | 4 | WARNING syncing will go very slowly unless you use this: 5 | ``` 6 | sync_mode:quick(). 7 | ``` 8 | This still gives the same security as a normal sync. It just turns off the tx pool, since you wont be processing txs while syncing. 9 | You can check which mode you are in like this: 10 | ``` 11 | sync_mode:check(). 12 | ``` 13 | Once you have finished syncing blocks and you are ready to process txs again, change back to normal mode like this: 14 | ``` 15 | sync_mode:normal(). 16 | ``` 17 | 18 | This turns syncing on, so you will download blocks from your peers 19 | ``` 20 | sync:start(). 21 | ``` 22 | 23 | This turns syncing off. 24 | ``` 25 | sync:stop(). 26 | ``` 27 | -------------------------------------------------------------------------------- /api/commands_basics.md: -------------------------------------------------------------------------------- 1 | Basic commands to use the blockchain 2 | =========== 3 | 4 | 5 | #### check progress in syncing blocks 6 | 7 | To see the current block height on this node: 8 | ``` 9 | block:height(). 10 | ``` 11 | 12 | To see the current header height on this node: 13 | ``` 14 | api:height(). 15 | ``` 16 | 17 | To see the transactions in the tx pool on this node: 18 | ``` 19 | tx_pool:get(). 20 | ``` 21 | These are txs that could be included in the next block. 22 | 23 | #### Stop a node 24 | ``` 25 | api:off(). 26 | halt(). 27 | ``` 28 | 29 | #### delete data files to restart at block 0 30 | ``` 31 | make prod-clean 32 | ``` 33 | 34 | #### sign a transaction 35 | ``` 36 | keys:sign(Tx). 37 | ``` 38 | 39 | #### sign binary data 40 | ``` 41 | keys:raw_sign(Tx). 42 | ``` 43 | 44 | #### share new txs with the network 45 | ``` 46 | amoveo_utils:push_txs(). 47 | ``` 48 | -------------------------------------------------------------------------------- /api/commands_channels.md: -------------------------------------------------------------------------------- 1 | Terminal commands to control channels 2 | =============== 3 | 4 | Join the Amoveo channel network 5 | ==== 6 | Your balance divided by the receiving limit needs to be bigger than 1/2. Delay is how long at most you would have to wait to get your money out. 7 | ``` 8 | api:new_channel_with_server(YourBalance, ReceivingLimit, Delay). 9 | ``` 10 | 11 | Spend money through the lightning network 12 | ==== 13 | Pubkey is the recipient's pubkey. It is not recorded on the blockchain, it is recorded along with every signature made by them. 14 | ``` 15 | api:lightning_spend(To, Pubkey, Amount). 16 | ``` 17 | 18 | Learn a secret 19 | ==== 20 | So that you can receive a channel payment. 21 | The code is like a ScriptPubKey in bitcoin, the Secret is like a ScriptSig in bitcoin. The code is the contract that was agreed to, the Secret is evidence to unlock the contract. 22 | ``` 23 | api:add_secret(Code, Secret). 24 | ``` 25 | 26 | sync channel state 27 | ==== 28 | Ask the server if your channel has been updated, and sync. If you received a channel payment for example, then your channel state will have been updated, or if your partern received a channel payment from you, then your channel state will be updated to reflect the new balances. This is how you sync with that new state. 29 | ``` 30 | api:pull_channel_state(). 31 | ``` 32 | 33 | Donate money to the server. 34 | ==== 35 | ``` 36 | api:channel_spend(Amount). 37 | ``` 38 | 39 | start the process of closing a channel if your partner has disappeared, or is not cooperating. 40 | ==== 41 | ``` 42 | channel_solo_close(TheirPubkey). 43 | ``` 44 | 45 | Commands for if you are running a channel node server 46 | ==== 47 | 48 | Close channels that are ready to be closed 49 | ==== 50 | ``` 51 | api:close_many(1). 52 | ``` -------------------------------------------------------------------------------- /api/commands_market.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | A binary market 5 | ========= 6 | ``` 7 | api:new_market(OID, Expires, Period). 8 | ``` 9 | ``` 10 | api:new_market(base64:decode("w6lgnziMj0VcHUrB4wCKCMUXdr2Iil0+LEPD5+TcZ5g="), 100000, 20). 11 | ``` 12 | period is how many blocks you have to wait till bets get matched in a batch. 13 | Expires is the height at which betting stops. 14 | 15 | 16 | A scalar market 17 | ========== 18 | ``` 19 | api:new_market(OID, Expires, Period, LowerLimit, UpperLimit, Many). 20 | ``` 21 | ``` 22 | api:new_market(base64:decode("w6lgnziMj0VcHUrB4wCKCMUXdr2Iil0+LEPD5+TcZ5g="), Expires, Period, LowerLimit, UpperLimit, Many). 23 | ``` 24 | 25 | LowerLimit and UpperLimit are used for setting the margins and leverage for the smart contract. They are usually set to 0 and 1023. 26 | Many is how many oracles are being used to generate the value, it is usually set to 10. 27 | 28 | 29 | Closing a market 30 | ======== 31 | ``` 32 | order_book:dump(OID). 33 | ``` 34 | WARNING: make sure all the channels have closed their positions before closing the market. -------------------------------------------------------------------------------- /api/commands_mining.md: -------------------------------------------------------------------------------- 1 | #### Mining 2 | 3 | [There is better mining software available here](https://github.com/zack-bitcoin/amoveo-c-miner) 4 | [gpu mining software is here](https://github.com/Mandelhoff/AmoveoMinerGpuCuda) 5 | 6 | 7 | to see your list of peers 8 | ``` 9 | peers:all(). 10 | ``` 11 | 12 | to add yourself to the list of peers, if you have ip address 1.2.3.4 13 | ``` 14 | peers:add({{1,2,3,4}, 8080}). 15 | ``` 16 | 17 | #### see how fast blocks are being produced (in seconds). 18 | ``` 19 | block:period_estimate(). 20 | ``` 21 | 22 | #### to see the total network hashrate (in GH/s). 23 | ``` 24 | block:hashrate_estimate(). 25 | ``` 26 | 27 | #### to see the number of hashes on average to find a block. 28 | ``` 29 | block:hashes_per_block(). 30 | ``` 31 | 32 | To mine a block: 33 | ``` 34 | api:mine_block(). 35 | ``` 36 | 37 | 58 | -------------------------------------------------------------------------------- /api/commands_other.md: -------------------------------------------------------------------------------- 1 | Other commands 2 | ======= 3 | 4 | 5 | ##### To see the transactions currently in the mempool, which will be included in the next block. 6 | ```erlang 7 | api:mempool(). 8 | ``` 9 | 10 | #### Lookup block number 5 in current block chain 11 | ```erlang 12 | block:get_by_height(5). 13 | ``` 14 | 15 | #### Lookup block whose header has the specified hash 16 | ```erlang 17 | block:get_by_hash(<<"The32BytesLongHashOfABlockHeader">>). 18 | ``` 19 | 20 | #### Lookup block number 5 in a specific block chain 21 | The specified hash of the block header identifies a block. Lookup the 22 | block at height 5 in the chain that goes from such block to the 23 | genesis block. 24 | ```erlang 25 | {ok, Header} = headers:read(<<"The32BytesLongHashOfABlockHeader">>), 26 | block:get_by_height(5, Header). 27 | ``` 28 | 29 | ### Lookup the top block 30 | ```erlang 31 | {ok, H} = api:height(), 32 | block:get_by_height(H). 33 | ``` 34 | -------------------------------------------------------------------------------- /api/commands_unsigned.md: -------------------------------------------------------------------------------- 1 | This page shows how to make unsigned transactions, which are suitable for cold storage applications. 2 | 3 | 4 | How to spend tokens to an existing account. 5 | `spend_tx:make_dict(To, Amount, Fee, From).` 6 | spends 0.01 Veo, fee of 0.00153 Veo 7 | ``` 8 | Tx = spend_tx:make_dict(base64:decode("BCjdlkTKyFh7BBx4grLUGFJCedmzo4e0XT1KJtbSwq5vCJHrPltHATB+maZ+Pncjnfvt9CsCcI9Rn1vO+fPLIV4="), 1000000, 153000, base64:decode("BCjdlkTKyFh7BBx4grLUGFJCedmzo4e0XT1KJtbSwq5vCJHrPltHATB+maZ+Pncjnfvt9CsCcI9Rn1vO+fPLIV4=")). 9 | rp(packer:pack(Tx)). 10 | ``` 11 | 12 | How to make a new account for someone who only has an address and doesn't have an account. 13 | `create_account_tx:make_dict(Pub, Amount, Fee, From).` 14 | gives 0.01 Veo, fee of 0.00153 Veo 15 | ``` 16 | Tx = create_account_tx:make_dict(bae64:decode("BCjdlkTKyFh7BBx4grLUGFJCedmzo4e0XT1KJtbSwq5vCJHrPltHATB+maZ+Pncjnfvt9CsCcI9Rn1vO+fPLIV4="), 1000000, 153000, base64:decode("BCjdlkTKyFh7BBx4grLUGFJCedmzo4e0XT1KJtbSwq5vCJHrPltHATB+maZ+Pncjnfvt9CsCcI9Rn1vO+fPLIV4=")). 17 | rp(packer:pack(Tx)). 18 | ``` -------------------------------------------------------------------------------- /api/keys.md: -------------------------------------------------------------------------------- 1 | The node keeps an encrypted copy of your private key. 2 | You find your keys in this file: 3 | `_build/prod/rel/amoveo_core/keys/keys.db` 4 | 5 | The decrypted copy is only stored in RAM. 6 | 7 | You can generate a new private key this way: (warning! this deletes your old private key!!!) 8 | ``` 9 | keys:new("password"). 10 | ``` 11 | 12 | To secure your node so no one can sign transactions, you can either turn off the node, or you can do this command: 13 | ``` 14 | keys:lock(). 15 | ``` 16 | 17 | To unlock your node so that you can start signing transactions again, do this: 18 | ``` 19 | keys:unlock("password"). 20 | ``` 21 | 22 | To check if you node is locked: 23 | ``` 24 | keys:status(). 25 | ``` 26 | 27 | To manually sign a transaction: 28 | ``` 29 | keys:sign(Transactions, AccountRoot). 30 | ``` 31 | 32 | To manually sign raw binary data: 33 | ``` 34 | keys:raw_sign(<<"binary data">>). 35 | ``` 36 | 37 | To find out your pubkey in the internal binary format: 38 | ``` 39 | keys:pubkey(). 40 | ``` 41 | 42 | To find your pubkey in the external base64 encoded format: 43 | ``` 44 | api:pubkey(). 45 | ``` 46 | 47 | To calculate a shared_secret with a partner, you need a copy of their pubkey: 48 | ``` 49 | keys:shared_secret(Pubkey). 50 | ``` 51 | 52 | 53 | You can set the password for encryption like this: 54 | ``` 55 | keys:change_password("old_password", "new_password"). 56 | ``` 57 | The default password on a new node is "", the empty string. 58 | 59 | -------------------------------------------------------------------------------- /api/securing_keys.md: -------------------------------------------------------------------------------- 1 | When you launch a full node, at first you don't have any aeons. 2 | 3 | Your keys are automatically generated for you, and secured with the password "". The empty string is the default password. 4 | 5 | The password is used to encrypt the private key on your computer. 6 | 7 | If you want to change the password and keep your old keys, do this: 8 | ``` 9 | keys:change_password("Old_PASSWORD", "New Password"). 10 | ``` 11 | 12 | replace "Old_PASSWORD" with the password you are replacing. 13 | replace "New Password" with the new password you want. 14 | 15 | 16 | Before using your node, make sure your wallet is unlocked. When a wallet is unlocked, that means that a decrypted copy of your private key is stored in ram. 17 | 18 | ``` 19 | keys:unlock("DONT_USE_THIS_PASSWORD"). 20 | ``` 21 | 22 | One way to get VEO is to share your pubkey with someone who has already VEO, so that they send some to you. 23 | 24 | 25 | To spend money to someone who doesn't yet have an account, you use the create_account transaction: 26 | ``` 27 | api:create_account(Pubkey, AmountOfMoney). 28 | ``` 29 | You can also create a new account by mining. If you don't have an account, and you find a block, it creates an account for you. 30 | 31 | 32 | It is also possible to generate new keys. This deletes your old keys. Without your old keys, any money you had in your old account becomes inaccessible to you. Be very careful. DANGER DANGER 33 | 34 | To generate an address with a better password, type following command: WARNING!! >>> this will delete your old private key <<< WARNING!! 35 | 36 | ``` 37 | keys:new("DONT_USE_THIS_PASSWORD"). 38 | ``` 39 | 40 | Make sure to have replaced "DONT_USE_THIS_PASSWORD" with a better password. 41 | -------------------------------------------------------------------------------- /api/using_channels.md: -------------------------------------------------------------------------------- 1 | making a channel with the server: 2 | 3 | ``` 4 | api:new_channel(Balance, ReceivingLimit). 5 | ``` 6 | 7 | Balance is how much of your money you put into the channel. 8 | ReceivingLimit is how much money the server puts into the channel. 9 | This is the maximum amount of money that can be sent to you until the channel runs out of space. ReceivingLimit needs to be bigger than Balance, or the server wont let you make the channel. 10 | Fee is the transaction fee, so that this transaction will be included into a block soon. 11 | 12 | 13 | checking your balance in the channel: 14 | ``` 15 | api:channel_balance(). 16 | ``` 17 | 18 | 19 | gambling with the server: 20 | ``` 21 | api:dice(Amount). 22 | ``` 23 | 24 | 25 | When you want to close the channel and get your money out: 26 | ``` 27 | api:close_channel(). 28 | ``` 29 | You need to sync with the network to see if your channel is closed. 30 | ``` 31 | api:sync(). 32 | ``` 33 | 34 | If your channel partner disappears, or breaks, you can still get your money without his help. Start with a solo-close transaction, then wait over 100 blocks, then do a channel timeout transaction 35 | ``` 36 | api:solo_close_channel(). 37 | ``` 38 | ``` 39 | api:channel_timeout(). 40 | ``` 41 | -------------------------------------------------------------------------------- /attacks_analyzed/LN_mempool_attack.md: -------------------------------------------------------------------------------- 1 | Lightning Mempool Attack 2 | ============== 3 | 4 | This attack was discovered against bitcoin LN. 5 | 6 | Say we have a 2 step lightning path Alice -> Bob -> Charlie 7 | With channel AB for Alice and Bob, and channel BC for bob and charlie. 8 | We want to atomically connect an update between AB and BC, so that either the payment goes the entire path, or else it doesn't happen at all. This way Alice can pay Charlie. 9 | 10 | The attack involves how bitcoin's mempool for zeroth confirmation txs works. If you try to publish a tx, mining pools will only accept it if it doesn't conflict with any tx already in the mempool. This helps to prevent double spending of zeroth confirmation txs. 11 | 12 | So if Charlie publish a very low fee tx, revealing the secret in order to close BC in the state of the payment having executed, this tx could sit in the mempool for a while. And as long as it is in the mempool, it isn't possible to close BC in any other conflicting state. 13 | 14 | But since it is only in mining pools mempools, and not written on the blockchain, Bob might not be able to find out the secret to close AB in the state of the payment having executed. 15 | 16 | So this is a way to disconnect AB and BC, so the payment only goes half-way. Alice and Charlie can steal money from Bob. 17 | 18 | In the context of sortition chains 19 | =============== 20 | 21 | We already decided that if cooperation isn't happening with an atomic update, that the secret needs to get put on-chain with a proof-of-existence tx, and it needs to be put on-chain before an expiration set inside the contract. 22 | So if someone attempts this attack, you just need to wait until the expiration. 23 | At that point the low-fee tx becomes invalid, because it wasn't included soon enough -------------------------------------------------------------------------------- /attacks_analyzed/computationally_heavy_blocks.md: -------------------------------------------------------------------------------- 1 | The transactions can be parallelized a lot. 2 | Here I compute the maximum computational cost of processing a block, assuming we are as parallelized as possible. MAX_COMUTATION_PER_BLOCK 3 | 4 | CC = the cost of processing the most expensive channel computation. 5 | 6 | S = the cost of processing a tx that doesn't use the VM. 7 | 8 | N = the maximum number of txs per block. 9 | 10 | MAX_COMUTATION_PER_BLOCK = max((N*S), (CC)). 11 | 12 | 13 | The channel contracts can never depend on each other's output. So we can parallelize all of them. -------------------------------------------------------------------------------- /attacks_analyzed/invalid_oracles.md: -------------------------------------------------------------------------------- 1 | Invalid Oracles 2 | ========= 3 | 4 | There is an interesting attack that has been happening to the Augur blockchain. 5 | Attackers ask the oracle questions with the intention of having the result be ambiguous, but at first glance it looks like the oracle is not ambiguous. 6 | The attacker makes bets on the less likely outcome, and so they buy shares at a price <0.5. 7 | Once the oracle results in "bad", then all the money in the market is split 50/50 between the people who bet on either outcome. 8 | So the attacker who paid <0.5 now gets paid 0.5. So this is a profitable attack. 9 | 10 | One solution to an attack like this would be if everyone got paid back the same amount of money that they had bet with. That way this attack could not result in theft. 11 | This design choice would mean that the shares in the market are no longer fungible. They have a different value depending on the price at which they were purchased and the likelyhood that the oracle will be invalid. 12 | So this design is incompatible with subcurrencies, it could not be an ERC20 on Ethereum. 13 | But it could be built inside the Amoveo lightning network. 14 | This design choice means that channel hubs making markets need to be careful not to use oracle that might result in "bad". Because the channel hub could lose a lot of money in that case. If the different bets are not fungible, then arbitrage stops working. -------------------------------------------------------------------------------- /attacks_analyzed/unclosable_channels.md: -------------------------------------------------------------------------------- 1 | one way a channel contract can fail is if the nonce is always increasing with height. 2 | This means the attacker can publish slash transactions over and over to keep the channel open as long as they want. -------------------------------------------------------------------------------- /basics/.#applied_trust_theory.md: -------------------------------------------------------------------------------- 1 | zack@zack-ilo.25870:1573865203 -------------------------------------------------------------------------------- /basics/atomic_swaps.md: -------------------------------------------------------------------------------- 1 | https://en.bitcoin.it/wiki/Atomic_cross-chain_trading 2 | 3 | In Amoveo we use a strategy from atomic swaps called hashlocking. Hashlocking is used to connect the smart contracts in channels together. This way, more than 2 participants can participate in the same smart contract. -------------------------------------------------------------------------------- /basics/backup.md: -------------------------------------------------------------------------------- 1 | Backup 2 | ======= 3 | 4 | To save time with syncing, you might want to back up your block file so if you restart your node from a fresh state, you don't have to resync everything. 5 | 6 | Save everything from /db 7 | 8 | The steps to restore are: 9 | 10 | 1) clone Amoveo into a new directory 11 | 12 | 2) `make prod-restart` to compile and start amoveo 13 | 14 | 3) `api:off().` to turn off amoveo 15 | 16 | 4) `halt().` to turn off erlang 17 | 18 | 5) copy all your saved files into /db of your new amoveo installation. 19 | 20 | 6) `make prod-restart` to turn on amoveo again, it should be fully synced. -------------------------------------------------------------------------------- /basics/blockchain_engineers_manifesto.md: -------------------------------------------------------------------------------- 1 | A Blockchain Engineer's Manifesto 2 | =========== 3 | 4 | Blockchain development is slow today because the process of trial and error is expensive and slow. 5 | Testing out a single idea involves launching a new cryptocurrency, and can cost millions of dollars. 6 | 7 | We should develop mathematical tools which will allow us to calculate whether one kind of blockchain design is more secure than another. 8 | 9 | Examples: 10 | * basics/trust_theory.md 11 | * https://vitalik.ca/files/intro_cryptoeconomics.pdf 12 | 13 | Once we have math tools like this, it will make it a lot easier to do blockchain engineering, because we can check if a strategy can possibly work without having to actually launch a blockchain. 14 | 15 | These math tools are still a work in progress. Please don't take their results too seriously yet. 16 | 17 | My strategy to develop these math tools is like this: 18 | 1) think really hard and come up with the best tools I can. Start with some model that can be improved iteratively. 19 | 2) Write up some reports about which blockchain projects would be considered insecure according to the math tools currently being considered. 20 | 3) Carefully read the responses from people who are upset that I called their blockchain insecure. 21 | 4) revise the mathematical security framework based on what we have learned, then go to step (2). 22 | 23 | 24 | Here are some example reports that I have done as a part of step (2): 25 | * other_blockchains/proof_of_stake.md 26 | * other_blockchains/cosmos.md 27 | * other_blockchains/pow_pos_hybrid.md 28 | * other_blockchains/zano.md 29 | * other_blockchains/drivechain.md 30 | * other_blockchains/decred.md 31 | * other_blockchains/UMA.md 32 | * other_blockchains/iota.md 33 | -------------------------------------------------------------------------------- /basics/cold_storage.md: -------------------------------------------------------------------------------- 1 | Cold Storage 2 | ======== 3 | 4 | 5 | Amoveo's javascript light wallet can be used for cold storage. 6 | 7 | Generate the private key on the cold storage machine. 8 | 9 | Use the pubkey to make a watch-only wallet on a machine that is connected to the internet. 10 | Generate unsigned transactions on the hot machine. 11 | Make sure to sync all of the headers before generating the transactions. 12 | 13 | Sign the transactions on the cold storage machine. 14 | 15 | Use the light wallet on the machine that is connected to the internet to broadcast the signed transactions. 16 | -------------------------------------------------------------------------------- /basics/customer_pitch.md: -------------------------------------------------------------------------------- 1 | Customer Pitch 2 | ========== 3 | 4 | 5 | ## Functionality 6 | 7 | You can use Amoveo to bet on anything that will be easy to look up in the future. 8 | You don't need anyone's permission to add more betting topics to Amoveo. 9 | 10 | 11 | ## Onboarding process 12 | 13 | You can buy VEO on qtrade.io or a1.exchange 14 | 15 | This light-node tool can be used to store your VEO tokens securely, and to make bets with anyone else. 16 | https://github.com/zack-bitcoin/light-node-amoveo 17 | 18 | 19 | ## How does pricing apply to them 20 | 21 | Making a new topic to bet on costs about 0.022 veo, which is less than $2 at the time I am writing this. 22 | Making a new account, or a new channel for bets costs 0.00152, which is less than $0.20. 23 | Sending a payment costs 0.0007, which is less than $0.10. 24 | 25 | 26 | ## Does it solve their specific problems 27 | 28 | If you want to make a bet, then Amoveo might be the right tool for you. -------------------------------------------------------------------------------- /basics/financial_derivatives.md: -------------------------------------------------------------------------------- 1 | Financial Derivatives 2 | ========== 3 | 4 | A financial derivative is the most basic financial instrument. 5 | Primary colors are to colors what financial derivatives are to finance. 6 | The same way you can combine the primary colors to produce all possible colors, you can combine financial derivatives to create any financial portfolio. 7 | 8 | the chemical elements are to chemistry what financial derivatives are to finance. 9 | The same way you can combine the chemical elements to produce all possible chemicals, you can combine financial derivatives to create any financial portfolio. 10 | 11 | If you are a farmer who is growing orange fruit trees, there is a lot of risk for you if the price of orange fruits should drop before you are ready to harvest. 12 | You could use a financial derivative to hedge this risk. 13 | That way you can lock in the current price of oranges, so when your oranges are ready you can sell them at the price you locked in. 14 | 15 | Financial derivatives are older than written language. 16 | Financial derivatives are the most popular use-case of currency. 17 | 18 | What it comes to software tools, it seems like simple tools that do their job well end up more successful in comparison to tools that try to do too many different things. 19 | 20 | I can't see any reason that a platform for financial derivatives could be improved by adding crypto-kitties, or subcurrencies, or DAO-voting-pools, or any of the other crazy finance experiments people have been doing lately. 21 | 22 | Financial derivatives are popular today for the same reason they have been popular since prehistory, which is the same reason that they will be popular in the future. 23 | Financial derivatives are a scalable way to hedge risks. 24 | They are scalable because their enforcement doesn't require any shared mutable state. 25 | 26 | 27 | 28 | Computer programmers don't know enough about finance to know what a derivative is. 29 | Finance people don't know enough about programming to realize why the lack of shared state is so important in the success of derivatives. -------------------------------------------------------------------------------- /basics/full_node_with_slow_connection.md: -------------------------------------------------------------------------------- 1 | If you have slow internet connection, and you want to run a full node, you may find that it is difficult to sync. it often crashes. 2 | In the config/sys.config.tmpl file, set download_blocks_many to 1, so you do fewer connections simultaniously. This should stop it from crashing so much. -------------------------------------------------------------------------------- /basics/futarchy.md: -------------------------------------------------------------------------------- 1 | 2 | [using amoveo for futarchy](basics/using_governance.md) 3 | 4 | #### Why use Prediction Markets? 5 | Prediction Markets are tools for efficiently getting information about the future from groups of people. 6 | Prediction Markets are best used in situations were there is a lot of money at stake, so people are spreading propaganda, or lying to each other, making it hard to find out accurate information. 7 | You use prediction markets to find out probabilistic information about the future. 8 | 9 | #### What are Prediction Markets? 10 | Using prediction markets means making a betting market, and we learn information by looking at the prices at which people are betting. 11 | If people are betting at 3:1 odds that team B will win in football, that means there is about a 75% chance that team B will win. 12 | 13 | #### Why not use Prediction Markets? 14 | Prediction Markets are slow, and it is difficult to get more than a few bits of information at a time. 15 | You can only ask about information that will eventually become common knowledge. 16 | 17 | ### Futarchy 18 | Futarchy means using prediction markets to find out information that is used to make decisions for groups of people. 19 | 20 | [Use cases of prediction markets](../use-cases-and-ideas) -------------------------------------------------------------------------------- /basics/futarchy2.md: -------------------------------------------------------------------------------- 1 | Futarchy 2 | ====== 3 | 4 | Markets reveal information for free, as a side effect. 5 | Through the price 6 | We can construct financial assets very carefully, such that the price of the asset in a market reveals any information that could interest us. 7 | For example, one of Obama's campaign promises was that he would close Guantanamo Bay in Cuba, and stop torturing people. He promised to do this his first month as president. 8 | 9 | This was a lie. 10 | 11 | We could have made some financial markets so that insiders who knew that Obama was lying could trade on their insider information to profit, and the market would reveal to us that Obama has no intention of ending the torture. 12 | P = obama is elected 13 | Q = guantanamo bay is closed by date X 14 | 15 | we could have 4 markets: 16 | P and Q 17 | !P and Q 18 | P and !Q 19 | !P and !Q 20 | 21 | Then by looking at the prices in the markets, we could know if Obama is lying. -------------------------------------------------------------------------------- /basics/market_failure.md: -------------------------------------------------------------------------------- 1 | Market Failure 2 | ======== 3 | 4 | in a market failure, the cost to do a bribe and control the decision being made is on the order of about (value being decided over)/(number of voters) 5 | 6 | market failures happen if the rational strategy for individuals is not the same as the rational strategy for the group. 7 | 8 | voting mechanisms suffer from market failure if there is bribery. you can see from a 2x2 chart. 9 | Example: we are voting on A or B. if A wins, then every voter is $100 richer. There are 100 voters with equal stake. 10 | I bribe all the voters $2 to vote for B 11 | 12 | ``` 13 | Wins: A B 14 | vote A: $100 $0 15 | vote B: $102 $2 16 | ``` 17 | 18 | you can see form the chart that any individual voter would prefer to vote for B. because 102 > 100, and 2 > 0. 19 | So $200 of bribes can destroy $10 000 of value. 20 | 21 | Here is a video with some great examples: https://youtu.be/DsdsxQqZPmA 22 | -------------------------------------------------------------------------------- /basics/merkle.md: -------------------------------------------------------------------------------- 1 | Merkle trees are important for understanding any scalable blockchain system. They are a critical component of: 2 | * transaction processing for blockchains with light nodes 3 | * sharing consensus data like txs 4 | 5 | Before you can understand merkle trees, you need to understand cryptographic hash functions. -------------------------------------------------------------------------------- /basics/spamming_for_control.md: -------------------------------------------------------------------------------- 1 | Spamming for control 2 | ======== 3 | 4 | I was recently asked this question. 5 | 6 | > Is it possible to make a secure blockchain mechanism based on whoever spams the most txs can control the outcome? 7 | 8 | This is a question who's answer can be mathematically calculated with trust theory. 9 | 10 | It is a bad idea to have attackers and defenders fight by spamming txs. 11 | If a fight has the side-effect of causing blockchain bloat, or bandwidth bloat, this can become a vulnerability for the blockchain. 12 | 13 | This is a specific example of the more general principle: 14 | ``` 15 | A mechanism has property X if whoever pays the most can control the outcome. 16 | All mechanisms with property X are not secure. 17 | ``` 18 | 19 | I can show it with math. 20 | 21 | Lets say that the attacker can steal P if the attack succeeds. 22 | The attacker burns A on the attack. 23 | The defender burns D on defense. 24 | if D>A, the defender keeps P. 25 | if D>). 6 | ``` 7 | All the letters must be capatalized. 8 | 9 | check if it is done: 10 | ``` 11 | vanity:check(). 12 | ``` 13 | "go" means it is still working. when it is done it will display your new pubkey/privkey pair. 14 | 15 | stop trying to find the vanity address. 16 | ``` 17 | vanity:stop(). 18 | ``` -------------------------------------------------------------------------------- /blog_posts/6th_year_summary.md: -------------------------------------------------------------------------------- 1 | 6th year summary 2 | ================ 3 | 4 | This is the 6th year anniversary of Amoveo's first block. This is a summary of what happened this year, and some plans for what will be done in the following year. 5 | 6 | Futarchy is back 7 | =============== 8 | 9 | https://github.com/zack-bitcoin/amoveo-docs/blob/master/blog_posts/futarchys_back.md 10 | 11 | We have found a way to build a version of futarchy that actually works. It isn't active in the full nodes yet, but it is mostly implemented. 12 | 13 | This means we will once again be a futarchy guided community, where if someone uses futarchy to show that a strategy is better for Amoveo, then we will use that strategy. 14 | 15 | Verkle tech is live 16 | ================ 17 | 18 | 19 | Syncing in reverse is now mandatory. All nodes are using the memoryless full node technique. 20 | You can see new instructions for syncing a full node in (here)[../getting-started/sync.md] 21 | 22 | This brings us one step nearer to enabling the land registry: https://github.com/zack-bitcoin/harberger_global 23 | 24 | 25 | Employment contracts 26 | ================ 27 | 28 | Amoveo now has Harberger style employment contracts http://46.101.81.5:8080/employment.html 29 | 30 | This is similar to the ethereum project: https://orb.land/ 31 | 32 | Ironing out the details of a harberger system brings us one step nearer to our goal of having a harberger land registry. 33 | 34 | -------------------------------------------------------------------------------- /blog_posts/DEX_7_feb_2021.md: -------------------------------------------------------------------------------- 1 | crosschain DEX update 2 | ================= 3 | 4 | Today 2 people did an exchange using the Amoveo DEX, and neither of them were Zack. 5 | 10 veo were sold for 0.015 BTC. 6 | Approximately $57 per VEO at the current BTC price. 7 | 8 | [Here is the tool they used for the crosschain swap. They used the "crosschain DEX" tab on this page](http://46.101.81.5:8080/wallet.html) 9 | this tool is getting easier to use. Now it lists available offers for you to match, so you can do everything from this one page. It has better clearer error messages, so if you forget to load your account, or have insufficient balance, you will know why it isn't working. 10 | 11 | [Here is the tx that activated the trade](http://46.101.81.5:8080/tx_explorer.html?txid=sH1uO/04Ux2HYc9gAl4z2QqNO8HnISxg7gYZjmZAG8M=) 12 | Notice that it is using flash minting to combine several txs. It would have been impossible to do these txs one at a time in any order, but with flash minting they only needed 1.1 VEO instead of 11 VEO. 13 | 14 | [Here is the smart contract enforcing the crosschain exchange](http://46.101.81.5:8080/contract_explorer.html?cid=OWByrUqzrM/3Zz6DkbqC4oM2/wsPgonBpESXvs4vzbc=) You can read the oracle text enforcing the outcome here. This oracle never actually went on-chain, because the 2 people swapping cooperated to get their money out faster and cheaper without needing to use the oracle. 15 | 16 | [Here is the bitcoin address that received the payment](https://www.blockchain.com/btc/address/3NUw8Wd1JxVU98VjnKgFSnxNHEa8zutnVb) 17 | 18 | [Here is the bitcoin payment](https://www.blockchain.com/btc/tx/45a1270f01540c17d17b57f859cb5a2a92475d7148d408fde8a441e144c48c04) 19 | 20 | [Here is the tx where the person buying BTC release the veo, because the bitcoin had arrived](http://46.101.81.5:8080/tx_explorer.html?txid=c8lrn31kuF/2nxHJ42T53s8HCNAOYCh/N8Ti4dRNTnA=) 21 | 22 | [Here is the tx where the person selling BTC combined the 2 share types of the contract to get their VEO out of the smart contract](http://46.101.81.5:8080/tx_explorer.html?txid=1NGS14+56OYk/3z5vK+/JStAf7dEvaTD2vcS3xiaNcY=) 23 | 24 | -------------------------------------------------------------------------------- /blog_posts/elevator_pitch.md: -------------------------------------------------------------------------------- 1 | Elevator Pitch 2 | =========== 3 | 4 | Derivatives are powerful financial tools. 5 | 6 | Derivatives are used to insure against risk. 7 | For example, if your local currency is unstable, you can use a derivative to protect youself from the possibility that your currency will lose value. 8 | 9 | Derivatives are used to communicate your future needs. 10 | For example, if you have a restaurant that sells a certain amount of beef every month, then you can use derivatives to communicate your beef needs ahead of time. 11 | This allows you to buy at a better price, and it helps the cow farmer to plan. 12 | 13 | Today, the majority of people are locked out of these powerful tools. 14 | 15 | Blockchain is the technology that powers bitcoin. With blockchain, you don't need anyone's permission, and no one can be excluded. We are putting derivatives inside of a blockchain, that way everyone will have access. 16 | 17 | Additionally, blockchains cut out a lot of middle-men in finance. Which should allow for lower fees, and faster service. 18 | 19 | 20 | 21 | -------------------------------------------------------------------------------- /blog_posts/enlightenment.md: -------------------------------------------------------------------------------- 1 | The enlightenment is stalling. 2 | Humanity is stuck half way between the age of reason, and the age of faith. 3 | 4 | Atheists won the memes, but theists still control the genes. 5 | 6 | The ability to use reason and logic is incredibly powerful, and has allowed us to conquer nature in unimaginable ways. These same tools that give us power to know why some decisions are better than others, they also strip us of our ability to cooperate. 7 | Once we can use reason to know that a goal isn't in our best interest, we stop cooperating to achieve that goal. 8 | Without faith to unite us, we become scattered and weak. 9 | 10 | Without the ability to cooperate, humanity is on a death march towards extinction. 11 | 12 | And so we find ourselves in a world with: 13 | * rich atheist cultures that constantly vanish. 14 | * poor theist cultures that constantly grow, and then get consumed by the memes of reason, to convert into new atheist cultures. 15 | 16 | Futarchy is the solution. 17 | With futarchy, reasonable people will finally be able to cooperate the way faith-based people can. 18 | 19 | We will finally have rich, stable, long-lasting cultures who are capable of making decisions in their own best interest, and cooperating to achieve shared goals. -------------------------------------------------------------------------------- /blog_posts/explicacion_corto.md: -------------------------------------------------------------------------------- 1 | Explicacion Corto 2 | =========== 3 | 4 | 5 | Los derivados son poderosas herramientas financieras. 6 | 7 | Los derivados se utilizan para asegurar contra el riesgo. Por ejemplo, si su moneda local es inestable, puede usar un derivado para protegerse de la posibilidad de que su moneda pierda valor. 8 | 9 | Los derivados se utilizan para comunicar sus necesidades futuras. Por ejemplo, si tiene un restaurante que vende una cierta cantidad de carne cada mes, entonces puede usar derivados para comunicar sus necesidades de carne con anticipación. Esto le permite comprar a un mejor precio y ayudará al agricultor a planificarse. 10 | 11 | A día de hoy, la mayoría de las personas están excluidas de estas poderosas herramientas. 12 | 13 | La Cadena de bloques (conocido en inglés como blockchain), es la tecnología que impulsa Bitcoin. Con blockchain no necesita el permiso de nadie y nadie puede ser excluido. Estamos poniendo derivados dentro de una cadena de bloques, de esa manera todos tendrán acceso. 14 | 15 | Además, las Cadenas de bloques eliminan a muchos intermediarios en finanzas. Lo que debería permitir tarifas más bajas y un servicio más rápido. 16 | 17 | -------------------------------------------------------------------------------- /blog_posts/fast_oracles_worthless_goal.md: -------------------------------------------------------------------------------- 1 | Why Making Oracles Faster is a Useless Goal 2 | =============== 3 | 4 | There are zero benefits to a faster oracle resolution, and many problems. 5 | 6 | Whether the oracle is faster or slower has no impact on user experience. 7 | 8 | If people want to get their money out before full resolution, they can sell their shares for the same value that they would get in any other market with the same accuracy guarantees. 9 | 10 | For example, lets say we are betting on an election, and the result of that election is finalized. In that case, everyone with losing shares would dump them to try to get any value out, and the price of losing shares would get very near to zero. 11 | If losing shares go to zero, then the winning shares are necessarily worth nearly all the collateral in the contract. 12 | This means that anyone can sell early to get their money out, they don't need to wait for the oracle to resolve. 13 | 14 | Whoever the most patient person is, in the entire economy, will just be treating it as a 3 month CD or something — they will be thrilled if the price goes below .99, .98 , etc 15 | 16 | 17 | Imagine the election was a landslide for Biden, and that Trump conceded at 10 PM. Someone who bought Biden shares at .65 on Monday, would be able to sell them for .80 .85 .90 .95 cents as the landslide unfolded at 7-9 PM 18 | At 10 PM it would tick up to .998 19 | You could sell any number of shares at .998, that you had bought for .650 20 | What is so urgent? 21 | If you cared about time so much, sell them for .90 at 9 PM 22 | Blast critical components of the system into pieces? So that someone can sell for 1 on Wednesday instead of .998 23 | ``` 24 | +53.846% = 1/.65 25 | +53.538% = .998/.65 26 | ``` 27 | I mean, that assumes a risk free rate // time value of money of 1% 28 | which is rather low isn't it? 29 | But the FED currently has the 10 year treasury yield at 0.78 .... 30 | 31 | -------------------------------------------------------------------------------- /blog_posts/faster_verkle_proofs.md: -------------------------------------------------------------------------------- 1 | Faster Verkle Proofs 2 | ============ 3 | 4 | Here is a trick to generate verkle proofs like 3x faster. You need to store around 2 megabytes of data to do this. 5 | 6 | Here is some background around the math https://dankradfeist.de/ethereum/2021/06/18/pcs-multiproofs.html 7 | 8 | The bottleneck of generating the proof is in calculating the `g(t)` value from this paper. to calculate this, we need to do a lot of polynomial divisions where one of the values is equal to zero. 9 | 10 | Specifically, we have a polynomial P(x), and we want to calculate the polynomial P(x) / (x - M) where M is one of the 256 elements in our domain. 11 | 12 | The difficulty with this computation is that x and M have the same value for one point in the domain, and then we are dividing by zero and it is undefined. 13 | 14 | Dankrad found a solution. He recommends pre-computing A and A' polynomials to make it faster. 15 | We are continuing this same strategy, pre-computing more values involving A and A' to make the computation even faster. 16 | 17 | In finite fields, division is a lot slower than addition or multiplication. 18 | You need to calculate the inverse of a number, and that is very slow. Like 128 times slower than addition or multiplication. 19 | There is a trick called montgomery batch inversion that lets you invert lots of numbers at once, and it only costs as much as inverting a single number, and 2 multiplications for every extra number you are inverting. 20 | 21 | Looking at Dankrads strategy for calculating P(x) / (x - M), there are 254 inverses that need to be calculated. So we can make a single montgomery inverse batch to quickly calculate all 254 of the inverses. 22 | But, notice that these 254 numbers being inverted, there are only 256 valid sets of these 254 numbers. One for each element in the domain. 23 | So we can pre-calculate the 256 batches of 254 numbers, and when they are needed, just read them from the database instead of re-calculating them. 24 | 25 | 32 bytes * 256 batches * 254 numbers is around 2 megabytes of data. 26 | 27 | This technique is used in this verkle tree: https://github.com/zack-bitcoin/verkle -------------------------------------------------------------------------------- /blog_posts/impersonator_scams.md: -------------------------------------------------------------------------------- 1 | People on social media have been making fake accounts impersonating Amoveo team members. 2 | Be very careful. 3 | 4 | A typical scam goes like this: 5 | The scammer makes a fake account pretending to be a core Amoveo team member. 6 | They promise to pay back 2 veo for every 1 veo you send them. 7 | They just keep your veo, do not send 2 back. 8 | 9 | 10 | 11 | Here we will list accounts which have been identified impersonating Amoveo team members. 12 | 13 | twitter: 14 | @officialamoveo 15 | @cryptosadhu 16 | -------------------------------------------------------------------------------- /blog_posts/trading_key.md: -------------------------------------------------------------------------------- 1 | here is a message that was generated by the developer private key. 2 | 3 | ["emsg","QkJkRlFLRHNnZkZUOUxUYUkzRysydGEzUFBVbFJrLzJMUW0wTUhHY3JoK1FNZ0owUHNFNXhXR3R2MEhFcXNxL2xucVdSenJYNk45dklVbzJzNDVIaCtjPQ==","VndKbWYzaThsdzVoUmVhWUVwdnFGOGtFZWJBb3JRK0daeU95R1JZSmV0MXJESGJ6MGMxUHJlNnRzY0p4RFVIVlcyMkJMK1lmb0RsWmpqVnhGVjZtRTFSU0VBTWVpdkpCcklRNkZTL1Q0Q2NpK1NLRkQ3WnUvaGJaKzhuT1E3bTdXVXlwQlRRV01PVTRWaTlnRTBNN3ZDQm9xKy91NmlzK25rZGVRazNKeWdQOWRGb2VFMjJoVG94ckZJOXljM0ZCZFgzNytjcXV1aWVUcDF1NXRqYXdWSU9jVTB1SkcyYi9jUDk1QWhuVlhmM2R6bTFqVnZCbURadjAvTlNPcDg1VHRYdVZjeStUVUM1b000dzA3a05KWGgvTk51NlMrTlV3RVdJS1lxL0xaS1ZPNWlsa3Y3VkxMMHI3NDdtU0FYbDVxdmVEYWxQRTdHUVFxcWEvNTVGU0RFbURDOTFKeHFFZ0xIcEMvS3FxZEY3a2ltenhUSUFXVEdPN3JEVkdJa2pqQUJhU0dGNWxIUC9zMC9XSGxlWWVWNVR5bXQ0YUJyWFgyVUhOeFNXaTBBcVJ6cjVIUERyb092S3ZxSU12QW1DOS96RmhSMHY2YjZuazJTZGNWdFBkTHhYbA=="] 4 | 5 | decrypted, it says: 6 | 7 | ``` 8 | message from address: BL0SzhkFGFW1kTTdnO8sGnwPEzUvx2U2nyECwWmUJPRhLxbPPK+ep8eYMxlTxVO/wnQS5WmsGIKcrPP7/Fw1WVc= 9 | this is an address that I control BCjdlkTKyFh7BBx4grLUGFJCedmzo4e0XT1KJtbSwq5vCJHrPltHATB+maZ+Pncjnfvt9CsCcI9Rn1vO+fPLIV4= 10 | ``` 11 | 12 | You can decrypt it on this page: http://46.101.81.5:8080/encryption.html 13 | Generate your keys using the passphrase "amoveo", then you can decrypt the message. 14 | -------------------------------------------------------------------------------- /blog_posts/voting_in_post_futarchy_world.md: -------------------------------------------------------------------------------- 1 | Why there will not be voting in a post-futarchy world 2 | ================ 3 | 4 | In a post-futarchy world, we will organize ourselves around institutions with concrete goals. 5 | Members in an institution will cooperate on a decision if futarchy demonstrates that the decision helps to advance the goals of their institution. 6 | If you disagree with the goals of an institution, you would vote with your feet by not wasting any time or energy participating in that institution. 7 | 8 | Imagine there was an institution with the goal: 9 | "we should do what the majority wants, at any expense to the minority". 10 | This goal is not self-consistent. 11 | You can redraw lines to make anyone part of the minority. 12 | So a majority-rules institution would eternally waste it's energy on violently redistributing the resources of it's members. 13 | Redividing a smaller and smaller pie between it's members. 14 | A majority-rules institution would cannibalize itself, and so would not have any influence in post-futarchy society. 15 | 16 | 17 | 18 | -------------------------------------------------------------------------------- /checklists/new_testnet_checklist.md: -------------------------------------------------------------------------------- 1 | set version:doit/0 to 1. 2 | 3 | make every fork height in forks.erl activate near the genesis block 4 | test_height() -> 0. 5 | get(1) -> common(0, test_height()); 6 | get(2) -> common(0, test_height()); 7 | get(3) -> common(0, test_height()); 8 | get(4) -> common(constants:retarget_frequency(), max(test_height(), constants:retarget_frequency())); 9 | get(5) -> common(1, max(test_height(), 1)); 10 | get(6) -> common(0, test_height()); 11 | get(7) -> common(40, 40);%test_height()). 12 | get(8) -> common(0, test_height()); 13 | get(9) -> common(0, test_height()); 14 | get(10) -> common(1, 1); 15 | get(11) -> common(0, test_height). 16 | -------------------------------------------------------------------------------- /checklists/update_announcement_checklist.md: -------------------------------------------------------------------------------- 1 | mining pools: 2 | veoscan.pw Sy on telegram 3 | lolopool loloxiao on discord 4 | 5 | exchanges: 6 | relations@hitbtc.com email 7 | qtrade.io on discord 8 | relations@scalableintegration.com email for bitcoin.com exchange 9 | 10 | wallets: 11 | Dennis Voskvitsov on telegram 12 | 13 | announcement channnels: 14 | discord 15 | 16 | 17 | info to include: 18 | * block height 19 | * date when it is expected to activate 20 | * update number 21 | * why we need this 22 | * a link to the instructions for updating -------------------------------------------------------------------------------- /community_roadmap.md: -------------------------------------------------------------------------------- 1 | that is less precise than my todo list, and more exciting for the community to look at. 2 | 3 | 4 | My philosophy is that a blockchain should be created as a lean software startup. With this kind of new technology, there are many things that we do not know. We need to avoid making assumptions about how the technology will be used. 5 | We need to listen to users and adapt to their needs. We need to investigate many possible use-cases to see which will be popular first. 6 | 7 | 1 acquire first users of the markets. Try these things to search for potential users: 8 | - contract for difference/stable coins 9 | - use a smart contract to pay a reward to someone for uploading a torrent for an expensive textbook. 10 | - use a market to fund the creation of something for Amoveo. 11 | - use a combinatorial market to decide how we will do something for Amoveo. 12 | - use a markets to do things from this list: http://bitcoinhivemind.com/papers/3_PM_Applications.pdf 13 | 14 | 2 study our users, and keep improving Amoveo based on how they use it and what they want. 15 | 16 | 3 rename and rebrand Amoveo based on who our first users are, and who it makes sense to market ourselves towards. 17 | - This is the point at which we will have clear goals and features that we can put on a website, this way potential users can absorb our goals and features in 10 seconds. 18 | - Any money spent on advertising before this point in time is going to be dozens or hundreds of times less effective. 19 | 20 | 4 use a smart contract to incentivize targetted advertising to grow our user base. 21 | -------------------------------------------------------------------------------- /contributions.md: -------------------------------------------------------------------------------- 1 | Thank you for your interest. 2 | There are issues on the github that need taking care of: https://github.com/zack-bitcoin/amoveo/issues 3 | Erlang is a rewarding language https://learnyousomeerlang.com/content 4 | You can help us plenty without learning Erlang, we have lots of javascript that needs to be written. 5 | If you have any questions about Amoveo or blockchain technology, feel free to make issues on the Amoveo github. 6 | 7 | If you type up a proposal for an improvement you can make, and send the proposal to me, and we end up using your work or idea, then Amoveo might give you some tokens. 8 | 9 | Simply installing the software and syncing up with the testnet can be a big help, if you find a bug. 10 | 11 | 12 | 13 | 14 | For people interested in writing smart contracts: 15 | 16 | Here is the repository that has the VM and some compilers. 17 | https://github.com/zack-bitcoin/chalang 18 | 19 | Amoveo smart contracts are different. The computation is all off-chain. 20 | I think the first step would be to talk to me about what you want to make. 21 | I can quickly tell you what is possible, and give you the tools you need. 22 | 23 | On Amoveo the smart contract itself is usually the easy part. The hard part is the handshake for updating the state of the smart contract. Sending messages back and forth, and correctly handling them. It is important that your partner is unable to trick you into updating your copy of the channel state to an invalid channel state. 24 | 25 | -------------------------------------------------------------------------------- /crosschain_dex/atomic_swap.md: -------------------------------------------------------------------------------- 1 | Atomic Swap DEX 2 | ============== 3 | 4 | An atomic swap is an application of payment channel technology. It is enforced using hashlocking. 5 | 6 | [The bitcoin wiki explains how it works and the history of it's invention](https://en.bitcoin.it/wiki/Atomic_swap) 7 | 8 | A hash function can be used to commit to a secret. If you have a secret, you can calculate the commitment like this: hash(commitment). 9 | 10 | Blockchains can support locked payments that only get activated if you know the secret that has been committed to. 11 | 12 | Hashlocking is when there are 2 or more payments each locked to the same commitment. So when that single secret gets revealed, it atomically causes the different payments to become unlocked. 13 | 14 | Hashlocking has advantages: 15 | 16 | * It is very cheap. The overhead cost is effectively zero. 17 | * It is completely trustless. There is no one who can can cancel one of the two payments while letting the other occur. 18 | * It is very fast, the entire process can occur in less than 10 blocks of the slower blockchain. 19 | 20 | Hashlocking has disadvantages: 21 | 22 | * It requires that both blockchains support locked payments using the same hash function. 23 | * It requires specialized user interfaces to be sure that the locked payments on each side are using the same crypto, and that the amount of time that the money is locked for on each side is compatible. 24 | * It is vulnerable to the free option problem. 25 | * It is interactive. The participants have to be online at the same time and send messages back and forth to each other. In particular, if you go offline during certain prats of the exchange, you can lose your side of the swap without receiving the money on the other side of the swap. 26 | * It is not commitable. You can post fake offers, and when people try to accept them, you can refuse to cooperate and the swap is canceled. 27 | -------------------------------------------------------------------------------- /crosschain_dex/binance.md: -------------------------------------------------------------------------------- 1 | Binance DEX 2 | =========== 3 | 4 | 5 | It is very difficult to get any information on the binance DEX. This is my understanding of their product based on the limited information that they have made available. 6 | 7 | You send your BTC/ETH or whatever to binance, and they give you a trusted wrapped version managed by the centralized binance team instead. 8 | Security wise, this is no different from depositing your BTC/ETH onto the centralized binance exchange. 9 | 10 | You can trade your wrapped tokens on their on-chain order book. 11 | Then you swap your wrapped tokens back for the BTC/Eth whatever with the centralized binance team, and hope that they give you back your BTC. 12 | Security wise, this is the same thing as withdrawing BTC from the centralized binance exchange. 13 | 14 | Similar to like Tether, Binance claims to be holding all the cryptocurrency backing each of their wrapped tokens as collateral to maintain the value of their wrapped token. Since you are trusting binance to hold your BTC during the entire exchange process, it doesn't really matter what tech is being used to secure the wrapped token. 15 | Binance could refuse to give back the BTC that they were holding for you. 16 | Not your keys, not your coins. 17 | 18 | There is no point to creating a blockchain for this, because the security is the same as just depositing your money into the centralized Binance exchange. 19 | 20 | Calling this a "DEX" is very misleading. I think you should not do business with a company that misleads it's customers this way. Imagine what else they could be lying about. 21 | 22 | -------------------------------------------------------------------------------- /crosschain_dex/bisq.md: -------------------------------------------------------------------------------- 1 | Bisq 2 | ============== 3 | 4 | Bisq is a decentralized exchange based on 2-of-2 multisig addresses. 5 | 6 | So the process is like this: 7 | 8 | * Alice wants to spend Bitcoin to buy USD fiat currency. 9 | * Bob wants to spend USD to buy Bitcoin from Alice. 10 | * Alice locks the Bitcoin she wants to sell into a 2-of-2 multisig address with Bob, and a safety deposit, and Bob locks in some of his own Bitcoin as a security deposit. 11 | * Bob sends the fiat currency to Alice. 12 | * Alice and Bob send the BTC from the 2-of-2 multisig address to Bob, and Alice gets her safety deposit back. 13 | 14 | The problem is that the 2-of-2 multisig is not secure. Bob could refuse to send the fiat to Alice, and refuse to let Alice withdraw from the 2-of-2 unless she gives some of the money to Bob. 15 | Alice could refuse to unlock from the 2-of-2 after receiving her fiat currency unless Bob agrees to give some extra money to her. 16 | 17 | If one of either Alice or Bob has more need to access their bitcoin sooner, they can end up needing to pay a 50% or bigger premium to the other to withdraw their Bitcoin sooner. 18 | 19 | -------------------------------------------------------------------------------- /crosschain_dex/chainflip.md: -------------------------------------------------------------------------------- 1 | ChainFlip 2 | =========== 3 | 4 | ChainFlip white paper https://chainflip.io/ChainflipWhitepaperV1.1.pdf 5 | 6 | ChainFlip is secured by staked vault nodes. 7 | That means there are teams of specialized reporters who have locked value into vaults, and they vote on whether transactions have occured or not. 8 | 9 | [Voting in blockchains is a bad strategy](../design/voting_in_blockchains.md) 10 | 11 | Voting is especially bad in this case because of tragedy of the commons. 12 | The cost to bribe voters to steal the money being swapped is very cheap. 13 | If a vault has N participants, each with M stake, you only need to pay M/N in bribes to each participant for them to be willing to participate in an attack to steal the money being swapped in ChainFlip. 14 | 15 | If you are trusting a team of people to not rob you when you use ChainFlip, then that means you need to pay them enough trading fees so that they have an expectation that the long term profits from fees outweighs the short term profits of robbing you now. These fees mean that ChainFlip is much more expensive to use than alternative DEX designs. 16 | This cost can either come in the form of higher fees, or more frequent attacks that steal the money being swapped in the DEX. 17 | -------------------------------------------------------------------------------- /crosschain_dex/ren.md: -------------------------------------------------------------------------------- 1 | Ren Protocol 2 | ========== 3 | 4 | Ren protocol is a kind of privacy mixer on Ethereum. Here is their [white paper](https://releases.republicprotocol.com/whitepaper/1.0.0/whitepaper_1.0.0.pdf). 5 | Their white paper only talks about the mixer, not the crosschain exchange. 6 | 7 | The mixer is based on a secure-multi-party-computation (SMPC) protocol where any 51% of the dark nodes can work together to reveal the trades. 8 | If >50% of the dark nodes cooperate, they can see the orders, which breaks anonymity of the protocol. 9 | Additionally, these dark nodes would be able to front run the orders, and commit free-option attacks against all of the orders, which is a way to steal from the users. 10 | 11 | Since the trades are all encrypted inside the SMPC, the users have no evidence that this theft is occuring. The traders can't tell the difference between their trade matching at a bad price because of a legitimate crash in the price in the market vs the dark nodes cheating to front-run/free-option their order. 12 | 13 | Ren Bridge 14 | ========= 15 | 16 | Ren claims to be a tool for crosschain exchange, because they say you can make a wrapped version of BTC or ZEC or whatever, and then pass those wrapped tokens through the Ren mixer to transform them into a different kind of token. 17 | The security of such a cross-chain exchange is based on the security of the protocol for wrapping the BTC into a token on Ethereum. BTC -> wBTC. 18 | 19 | The protocol for wrapping BTC onto Ethereum is based on a team of trusted custodians who hold the BTC while you have your wBTC. You are trusting them to later exchange your wBTC for BTC. 20 | 21 | This is insecure, because the custodians can decide to steal your BTC and not give it back in exchange for wBTC. 22 | 23 | The insecurity makes the protocol unnecessarily expensive. The custodians need to receive enough fees so that the long-term expected profit from fees exceeds the short term expected profit from stealing the BTC. 24 | -------------------------------------------------------------------------------- /crosschain_dex/serum.md: -------------------------------------------------------------------------------- 1 | Serum crosschain swap review 2 | ============== 3 | 4 | The serum home page is not accessible, but I was able to find a [reddit discussion about how it works](https://www.reddit.com/r/CryptoCurrency/comments/igqk5l/6_reasons_why_serum_wont_succeed/) 5 | 6 | Serum's cross chain swap is similar to Amoveo's, except instead of offloading the computation to a trustless oracle like Amoveo, Serum is trying to use an Ethereum smart contract to verify that the tx had occured on another blockchain. 7 | 8 | Producing the proof that the tx had occured on another blockchain is very difficult, and it is a different process for every blockchain. 9 | 10 | Verifying this proof on the Ethereum blockchain is prohibitively expensive. -------------------------------------------------------------------------------- /design/accounts.md: -------------------------------------------------------------------------------- 1 | # Accounts 2 | 3 | The following describes accounts, which are one of merkel trees, responsible for keeping address and balance associated with it. 4 | 5 | In order to create an account one has to pay fee, which prevents spam. 6 | 7 | ## Overview 8 | 9 | Account consists of: 10 | * Pubkey 11 | * Balance - amount of money that is associated with an account 12 | * Nonce - number incremented with every transaction that is put on the chain 13 | * Height - height of account last update 14 | * Bets - pointer to merkle tree that stores how many bets have been made in each oracle 15 | 16 | 17 | 18 | -------------------------------------------------------------------------------- /design/asics_roadmap.md: -------------------------------------------------------------------------------- 1 | There are some companies that specialize in manufacturing slabs of silicon ASIC. each slab gets chopped up into many individual chips. 2 | Working with one of these companies directly to produce a full slab would cost around $1,000,000. 3 | Once we know what we want to build, we could do something like this. 4 | 5 | But first we should work with some different companies. 6 | These companies buy up lots of space on a silicon slab, and then they resell it in smaller amounts to people like us. 7 | In this way we could purchase a small part of a slab, to have 1 or 2 individual ASICS made. This is how we test our software to make sure it works correctly. 8 | I am guessing this will cost us around $10,000 9 | 10 | Finally, there is the software. I have never written code in Verilog or VHDL, and I have heard that hiring people for this sort of development can be very expensive. 11 | Luckily our algorithm is very short. Our chip will use about 1/4 as many circuits as bitcoin ASICS for example. 12 | I guess we could hire someone to do the software for $20,000 13 | 14 | For all these things, if we spend more time shopping around we can find better deals. -------------------------------------------------------------------------------- /design/batch_channel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zack-bitcoin/amoveo-docs/12f4c61c52015e3df9c495ecabe1600899374323/design/batch_channel.png -------------------------------------------------------------------------------- /design/batch_channel_unbalanced.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zack-bitcoin/amoveo-docs/12f4c61c52015e3df9c495ecabe1600899374323/design/batch_channel_unbalanced.png -------------------------------------------------------------------------------- /design/censored_orders_in_channel.md: -------------------------------------------------------------------------------- 1 | problem: what if the market maker refused to add any orders to the market based on the price of the order? 2 | 3 | Each market should advertise a certain size trade, which is very small. 4 | All the traders should only make trades in this small size. 5 | If you want to buy shares of type 4 in a market that has 4 types, you should also buy and sell a few shares of the other 3 types to verify that the oracle isn't censoring any trades. 6 | 7 | What if the channel path isn't completed, and someone in between is censoring your trades? 8 | Every step of the channel path should be formed using only the hash of the contract, that way the participants in the path don't know what they agreed to until after they have agreed. 9 | -------------------------------------------------------------------------------- /design/centralized_trust_free.md: -------------------------------------------------------------------------------- 1 | Centralized but Trust Free 2 | ======= 3 | 4 | Decentralization means taking a process that used to depend on the existence of some centralized authority, and you change the rules so that anyone can participate in any role. So there is no longer any centralized authority upon whom the process depends. 5 | Decentralization is an important part of what make blockchains work. Blockchains need to be decentralized, because it needs to be impossible for anyone to shut the blockchain off. 6 | 7 | Decentralization has been over-hyped lately. People are trying to use decentralization in situations that do not require it. 8 | 9 | Decentralization is very expensive, it should only be used when it is needed. 10 | If a blockchain has pieces that are unnecessarily decentralized, it will make it more expensive to use that blockchain. 11 | A blockchain that unnecessarily decentralizes pieces will have high fees compared to a blockchain which uses decentralization only where necessary. 12 | 13 | Many times, when people seek decentralization, what they should be seeking is trust-free relationships. 14 | A trust-free relationship with a central authority is secure the same way a decentralized relationship is secure. 15 | A trust-free relationship only depends on hiring a single authority to support you. 16 | If that single authority should disappear, or break any rules, then you would automatically get a refund. 17 | This is much more affordable than hiring multiple people in a decentralized network and coordinating their efforts. 18 | 19 | Amoveo's market is centralized and trust-free. 20 | Trading happens between individual traders, and individual market makers. 21 | This makes it much more affordable to participate in the market. -------------------------------------------------------------------------------- /design/channels_untrusted_slasher.md: -------------------------------------------------------------------------------- 1 | One desired property of channels is that users don't want to have to stay online 24/7 to be ready to provide evidence. They would prefer to pay other people to stay online with the evidence. 2 | 3 | This creates several new attack vectors we will need to consider while designing the channels. 4 | The old channels looked like this: 5 | new_channel_tx, grow_channel, grow_channel, channel_team_close. 6 | 7 | the grow_channels have to each increase the amount of money controlled by the channel. 8 | 9 | or like this: 10 | new_channel_tx, grow_channel, channel_solo_close, channel_slash 11 | or like this: 12 | new_channel, channel_solo_close, channel_timeout 13 | 14 | The new channels look like this: 15 | new_channel_tx, grow_channel, grow_channel, channel_solo_close, channel_slash, channel_slash, channel_slash, channel_timeout 16 | 17 | -------------------------------------------------------------------------------- /design/channels_usability.md: -------------------------------------------------------------------------------- 1 | 2 | Pan asks: 3 | 4 | I don't think it as an attack and support the comment: 5 | ''FYI this wasn't a hacker, but a user on the LND slack who had a corrupted channel database, restored an old backup, then closed his channels. Because the backup was out of date, his node broadcast old channel states and his channel partners' nodes detected this as fraud and published the penalty transactions.'' 6 | 7 | So, if I want run the channel by myself, I should carefully backup the state to make sure it's the last state. Otherwise, I have to lose something and be treated as hacker? 8 | 9 | It's quite hard for common people to make a fault tolerant system. So, It's not useable and safe for most people. 10 | I really don't want things progress this way. 11 | 12 | 13 | 14 | 15 | 16 | Yes this is an important problem. I am glad you bring it up. I have spent a lot of time thinking about this. 17 | 18 | You can try out the lightning network in a small testnet on your device using make multi-quick 19 | That way you can test out this error. 20 | 21 | But I can tell you it does not happen for us. 22 | The Amoveo light nodes do not ever make a tx. Instead they send the info about the tx to a full node, the full node makes the tx, and then the light node verifies that all the information is correct. 23 | 24 | This way it is impossible to close the channel at an old state and get punished. The full node will refuse the generate a tx like this. 25 | 26 | It is true that forgetting to save the recent state is a security problem. For now I programmed it so you can download a copy of the most recent state from the full node, if you should lose yours. 27 | This is even sort of trust-free. 28 | 29 | The attack we are worried about is if the full node could be giving you an old expired channel state where you have money. 30 | the default software I programmed is honest, and you are free to test the server at any time. 31 | Just request a download from the server, and see if it matches your latest saved channel state. 32 | 33 | The server can't tell if you are testing it, or if you actually lost your state channel data. So the server is incentivized to be honest. 34 | -------------------------------------------------------------------------------- /design/contract_ddos.md: -------------------------------------------------------------------------------- 1 | The attack works like this: 2 | The attack writes a big contract that is expensive to verify. We don't know that it is invalid until we finish verifying it. 3 | 4 | Ethereum solution: 5 | The transaction is still valid, the attacker pays enough gas that the attack is too expensive to commit. 6 | 7 | Amoveo solution: 8 | If you want your transaction included in a block, you first pay the channel server to help you build the transaction. The channel server is a shard that keeps track of a fraction of the blockchain's consensus state. The channel server builds the transaction and makes a proof and gives it to several miners. The channel server's service is dependent on being able to get transactions published quickly. 9 | So the channel server doesn't do anything weird when interacting with miners. 10 | If the miners lose money from their relationship with a particular channel server, the miner can choose to stop accepting transactions from that shard. 11 | 12 | 13 | Benefits to Amoveo's choice: 14 | The Ethereum VM has to be carefully constructed so it wont crash from any kind of input. Proving that it wont crash is impossible, so it is impossible to prove that it is secure. 15 | The Amoveo VM is allowed to crash. When the Amoveo VM crashes, it doesn't impact the security at all. 16 | Since crashing isn't a security vulnerability, it is possible to prove that Amoveo's VM is secure. 17 | 18 | Benefits to Ethereum's choice: 19 | You don't need payment channels -------------------------------------------------------------------------------- /design/dapp_developer_introduction.md: -------------------------------------------------------------------------------- 1 | These are the instructions for building new contracts and markets using the embedded language. 2 | 3 | far there is 2 production ready smart contracts I have made. a lightning payment contract, and the market contract. the market one has more tests. 4 | here is the code that calls the market test: 5 | 6 | https://github.com/zack-bitcoin/amoveo/blob/master/apps/amoveo_core/src/channels/market.erl 7 | 8 | this is the market smart contract 9 | 10 | https://github.com/zack-bitcoin/amoveo/blob/master/apps/amoveo_core/priv/market.fs 11 | 12 | this is a bet contract that is being traded in the market: 13 | 14 | https://github.com/zack-bitcoin/amoveo/blob/master/apps/amoveo_core/priv/oracle_bet.fs 15 | 16 | the lightning network contract is simpler. it is embedded as a string here: 17 | 18 | https://github.com/zack-bitcoin/amoveo/blob/master/apps/amoveo_core/src/channels/secrets.erl#L67 19 | 20 | 21 | You can see more example code, documentation for the compilers, and stuff like that in the chalang repository https://github.com/zack-bitcoin/chalang 22 | -------------------------------------------------------------------------------- /design/developer_reward.md: -------------------------------------------------------------------------------- 1 | The long-term goal is to fund Amoveo development using [insured crowdfunding](../use-cases-and-ideas/insured_crowdfund.md) 2 | This is an ideal way to protect the project from being controlled by a centralized team of developers. 3 | 4 | The short-term strategy to fund Amoveo development needs to be a little different. 5 | 6 | For now Zack has an excessive amount of knowledge of the project in comparison to everyone else. So it is important that the developer reward is set up so that Zack has an incentive to work on Amoveo. 7 | No one will want to invest in Amoveo if they think it is in Zack's interest to abandon it. 8 | 9 | Insured crowdfunding will be great eventually, but for now the 2nd layer tools, including the amoveo insured crowdfunding smart contract, are all crude and imprecise. 10 | At the beginning there will be few tokens, so there wont be enough liquidity for the insured crowdfunding contract. 11 | Insured crowdfunding only works to raise money for something that doesn't exist yet. Not for something that already exists. So we can't use insured crowdfunding to pay Zack for work he already did. 12 | 13 | Instead we will use something similar to the Zcash developer reward. 14 | In Zcash 20% of every block goes to the development team. 15 | 16 | In Amoveo the block reward and developer reward are 2 independent values controlled by the governance mechanism. So at any time, the community could decide to change how much they pay Zack. 17 | 18 | Additionally, the developer reward will be unspendable for the first 6 months or so. 19 | If Zack can't keep the blockchain alive that long, then he doesn't get paid at all. -------------------------------------------------------------------------------- /design/do_not_buy_amoveo.md: -------------------------------------------------------------------------------- 1 | Why _not_ to buy or mine Amoveo tokens. 2 | 3 | Amoveo has the potential to earn us all a lot of money. 4 | 5 | In investing, the potential to earn profit is always in proportion to how high the risk is. Anyone who tells you otherwise is lying to you. 6 | [Amoveo is a very high risk project.](../warning.md) 7 | I estimate there is a >3/4 chance that Amoveo will break in the first 3 months and we will all lose everything. [developers also wont get paid](developer_reward.md). 8 | If this happens, we will fix the software, and we will launch it again. 9 | 10 | If you insist on investing in Amoveo, then I recommend only doing it with small amounts of money. So if Amoveo breaks, it will not be a disaster for you, and you will be able to afford to participate in the next Amoveo blockchain, if you choose. 11 | -------------------------------------------------------------------------------- /design/elixir.md: -------------------------------------------------------------------------------- 1 | a few reasons I like erlang better than elixir. 2 | 3 | 1) elixir lets you rebind variables, which can make it easier to hide bugs. 4 | 2) elixir encourages a piping syntax, which is very conventient to think about, but often encourages bad behavior. 5 | 6 | Imagine we wanted to do a memory intensive multi-step process to every item in a list. 7 | If we used piping, then the memory requirement would grow with the number of elements in the list. 8 | 9 | In general, it is more secure to process each item in the list entirely before moving on to the next item. This way you don't waste memory storing half-done computations. 10 | 11 | These kinds of bugs are hard to measure or find once they are in your code. 12 | 3) elixir macros are too powerful. Blockchains need to be secure, we don't want people contributing code that will mess with the compiler. It can be too hard to reason about tools like that. -------------------------------------------------------------------------------- /design/ethereum_comparison.md: -------------------------------------------------------------------------------- 1 | fifi80 published this on reddit. 2 | 3 | Here are my thoughts about why it is superior to ETH: – contracts almost always involve an element of uncertainty that would be disclosed in the future. Like for example if it will rain tomorrow. A contract without an element of uncertainty is basically a series of time locked transactions. The only exception is a contract with no uncertainty but an obligation like for example a rental contract. In that case however you really need the judicial system as you need the police to get involved for example if the person doesn't let you in the house or is the tenant sets the house on fire. If I understand correctly in ETH you need to define your oracles in advance rendering it not so different than multisig where you would have someone decide on the outcome of something. If I understand correctly in AE you can just let the system of built-in oracles worry about the future determination of the uncertain element. – ETH can be useful for managing tokens, but that won't bring any value to it. The value of a smart contract token comes from the fact that you need to buy it in order to make a contract with it to exchange value. For example the fact that you can store data in BTC block chain doesn't add any value to the token, may be a very very small bit simply because the block size is limited. The reason is that to store data in the block chain you only need a few cents. I assume the logic behind issuing tokens on ETH is similar 4 | 5 | I see immense value in AE, it could be used for any kind of financial and nonfinancial bets. If you exclude contracts that are simply a pure cash flow distribution without uncertainty (and can just be solved with time locked transactions) and contracts which required judicial enforcement (like renting a house) everything else is basically a bet. I believe the stock market will go up you believe it will go down. We make a contract and later an Oracle will decide the outcome. Smart contracts are basically self enforcing bets with no middleman required. -------------------------------------------------------------------------------- /design/extra_light_security.md: -------------------------------------------------------------------------------- 1 | extra light nodes do not download blocks. They only download headers. 2 | They consider a tx included once there are enough confirmations. 3 | 4 | If an extra light node hears that a certain chain of blocks are bad, then they can download a single bad block and use it to know that that branch is bad. 5 | This is because each block includes with it all the merkle proofs for the consensus state necessary to verify the block. You can verify a single block without knowing anything about the other blocks besides their headers. 6 | 7 | This makes it easy for extra light nodes to get back onto the right chain. -------------------------------------------------------------------------------- /design/faucet.md: -------------------------------------------------------------------------------- 1 | Faucet 2 | ======= 3 | 4 | so for the griefable dex. 5 | 6 | 1. user opens page, it creates a new account with 0 veo 7 | 2. user creates offer selling eth for veo. js pulls current eth block height from API, puts it into oracle language. 8 | 3. user pushes swap offer to server. user also pushes 99% settle offer to server. 9 | 4. LP bot picks up offer off server, inserts eth pubkey, signs this transaction, AND signs a transaction spending 1 sat to user. 10 | 5. LP bot broadcasts both transactions to VEO L1. 11 | 6. (optional) user waits for veo block 12 | 7. user sends eth to LP pubkey 13 | 8. LP accepts 99% settle offer 14 | 15 | the faucet server api: 16 | 17 | * users publish uncollateralized swap offers. The offer is only valid for one block, so it automatically gets deleted after that. if a swap offer is accepted, it's contract data needs to be preserved until that contract expires. So it can be used for enforcement. 18 | 19 | * the list of swap offers currently stored on the server. 20 | -------------------------------------------------------------------------------- /design/futarchy_for_blockchain_updates.md: -------------------------------------------------------------------------------- 1 | Futarchy for Blockchain Updates 2 | ========= 3 | 4 | This paper is more theoretical. [read about how to use smart contracts to do this today](basics/using_governance.md) 5 | 6 | 7 | I have noticed some inefficiencies in how the network agrees upon updates. 8 | 9 | 1) if the developer is too popular, then their time becomes saturated from lobbyists trying to convince the developer to make upgrades that will make the lobbyist rich. Too much time with lobbyists makes it harder for the developer to know what upgrades are important. 10 | 11 | 2) the developer of an update is vulnerable to bribery and corruption from lobbyists. 12 | 13 | 3) if the developer is not popular enough, then they are unable to convince the network to consider their upgrades. 14 | 15 | Futarchy can solve these problem at once. 16 | Developers should program everything the community could be interested in, and futarchy should be used to decide which updates to merge into the mainnet. 17 | 18 | [here I talk about making the oracle for futarchy](../basics/using_governance.md) 19 | 20 | This way you can't use lobbying to give an advantage to the update you prefer. 21 | And it doesn't matter which developers are popular, everyone has equal opportunity to make updates. 22 | And the best updates have a way to stand out and get accepted. 23 | 24 | The idea of using futarchy for blockchain updates comes from Paul Sztorc http://www.truthcoin.info/blog/win-win-blocksize/ 25 | 26 | More details about Amoveo's oracle: design/oracle.md 27 | Even more details: https://github.com/zack-bitcoin/amoveo/tree/masterblog_posts -------------------------------------------------------------------------------- /design/futarchy_market.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zack-bitcoin/amoveo-docs/12f4c61c52015e3df9c495ecabe1600899374323/design/futarchy_market.md -------------------------------------------------------------------------------- /design/hard_drive_consumption.md: -------------------------------------------------------------------------------- 1 | Amoveo supports sharding and light nodes. So you can hold as little or as much of the merkle trees as you want. 2 | 3 | Headers are each 143 bytes. every node needs to download the headers, but you don't have to store them. 4 | You do need to store the most recent 20 headers, so you can recover from forks that are less than 20 long. 5 | * 2860 bytes 6 | 7 | Blocks are each 1 mb at the start, and governance can change their size limit. if you are a full node, or a shard node, then you need to download every block, but you dont' need to store them. 8 | 9 | Because of sharding, the amount of consensus state that you choose to store can be arbitrarily small. If you set it to 0, then that makes you a light node. 10 | 11 | So in total, the storage requirement for amoveo, like the memory that you have to keep around when you shut the node off so that it can turn back on correctly, is 2860 bytes. 12 | 13 | For each account you choose to store in your shard, it costs 106 bytes for the account, plus (256 * log16(number of accounts in the system)) 14 | 15 | similarly for governance variables, channels, oracles, the cost of storage is about (256 * log16(number of this type of element in the system)) 16 | 17 | For each account you have the option to store the oracle bets associated to that account. It costs about 300 bytes for every outstanding oracle bet that the account has. 18 | 19 | For every oracle you have the option to store the open orders sitting in that oracle. it costs about 377 bytes for every open order you choose to store. 20 | 21 | 22 | TL;DR 2860 bytes. 23 | -------------------------------------------------------------------------------- /design/hard_fork.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zack-bitcoin/amoveo-docs/12f4c61c52015e3df9c495ecabe1600899374323/design/hard_fork.md -------------------------------------------------------------------------------- /design/hedging.md: -------------------------------------------------------------------------------- 1 | Hedging strategies 2 | ====== 3 | 4 | 5 | All hedging strategies involve some rebalancing, but we would prefer strategies that need less rebalancing. 6 | 7 | Is it ever advantageous to make a derivative priced in the shares from a different derivative? 8 | 9 | 10 | Imagine Bob wants to bet on a football game, and he doesn't want to be exposed to any Veo risk. 11 | 12 | 100% veo risk profile: 0*F + 1*V + 0*U. 13 | betting Veo on a football game: 1*V*F + 0*U. 14 | betting USD on a football game: 0*V + 1*U*F. This is Bob's goal risk profile 15 | 16 | 17 | bet veo in a derivative to go long USD at 2:1 leverage: U*1 - V/2 18 | bet veo in a derivative on the football game at 2:1 leverage: F*V*1 - V/2 19 | 20 | Combine both above with the 100% veo risk profile: -------------------------------------------------------------------------------- /design/history.md: -------------------------------------------------------------------------------- 1 | History 2 | ====== 3 | 4 | David Friedman showed that decentralized governance is not only economically feasible, that it is more efficient, and that it is far from dead, we use it for many parts of society every day. http://www.daviddfriedman.com/The_Machinery_of_Freedom_.pdf 5 | But we couldn't organize to make the decision to do for everything. Any organization would become a centralized institution of power. Current centralized institutions wielding power did not want to give up that power. They would decide not to use give up their power to polycentric law. 6 | 7 | Robin Hanson showed that we can make decisions in a decentralized way, which could allow us to make the decision to use polycentric law for more parts of life. But again, the centralized institutions aren't so interested in letting us use tools that could take away their power. 8 | 9 | So Paul Sztorc found a way to reuse technology from Bitcoin to build Robin Hanson's markets in an unstoppable way, which will allow us to make the decentralized decisions we need to start using polycentric law more often. 10 | -------------------------------------------------------------------------------- /design/insurance.md: -------------------------------------------------------------------------------- 1 | Insurance is when you use a financial market to reduce your risk. 2 | For example, maybe it is financially important to you that the left branch of government will win a political election. 3 | In this case, you can bet that the right branch will win, and this will reduce your risk. -------------------------------------------------------------------------------- /design/memoryless_full_node.md: -------------------------------------------------------------------------------- 1 | 2 | This should be called a [stateless full node](/design/stateless_full_node.md) 3 | 4 | 5 | -------------------------------------------------------------------------------- /design/onboarding_dex.md: -------------------------------------------------------------------------------- 1 | Onboarding DEX 2 | ============= 3 | 4 | How we can use the DEX to start onboarding people who start out with zero veo, and do not want to sign up for any centralized exchange to buy any veo. 5 | 6 | Timeline 7 | ========= 8 | 9 | Alice wants to buy veo, and starts out with something like bitcoin. 10 | She has a unique IP used to make a DEX swap to buy $5 of veo in exchange for her bitcoin, and it is uncollateralized, so if Alice doesn't send her bitcoin, it could potentially freeze $5 of the server's money for a week, and cost transaction fees. 11 | The server sends Alice 1 satoshi of veo, so she has an account in the system. (maybe this isn't necessary) 12 | Alice uses the $5 of veo as collateral in the DEX to buy $250 of VEO, then she can potentially use it again to buy $12 500. 13 | 14 | this would take 3 bitcoin tx fees, and something like 6 veo tx fees. -------------------------------------------------------------------------------- /design/oracle_flowchart.md: -------------------------------------------------------------------------------- 1 | Oracle Decision Tree 2 | =========== 3 | 4 | start: 5 | new oracle tx is published. 6 | enough blocks pass so that oracle reporting can begin 7 | if someone makes an honest report, goto honest_state. 8 | else if someone makes a dishonest report, goto dishonest_state. 9 | else goto default_state. 10 | 11 | honest_state: 12 | if someone makes a dishonest report and locks up more money than is currently locked on the honest side of the oracle, goto dishonest_state. There can be a soft update preventing dishonest reports for specific oracles where attackers are consistently making dishonest reports. 13 | if enough time passes in the honest state, eventually it becomes possible to close the oracle in the honest state. goto closed_oracle. 14 | 15 | dishonest_state: 16 | if someone makes an honest report and locks up more money thant is currently locked on the dishonest side, then goto honest_state. 17 | if enough time passes in dishonest state, it eventually becomes possible to close the oracle in the dishonest state. goto closed_oracle. There can be a soft update preventing any tx that would close the oracle in a dishonest state. 18 | 19 | default_state: 20 | There are 3 ways to bet in the oracle, true/false/bad_question. for any oracle, hopefully 2 are dishonest, and 1 is honest. 21 | If no one has yet made any bets, it starts in the default state of bad_question. If bad_question is honest, go to honest_state, otherwise go to dishonest_state 22 | 23 | closed_oracle: 24 | the final result of the oracle is recorded onto the blockchain. Everyone who made reports that agree with this result, their money doubles. If you made reports that disagree with the result, you lose the money that you had locked into the oracle. -------------------------------------------------------------------------------- /design/oracle_simple.md: -------------------------------------------------------------------------------- 1 | A simple way to do the oracle is like this: 2 | Every time a decision resolves, the blockchain forks. One side decides that the decision's outcome is "true", the other decides "false". 3 | Users know the truth. They prefer the chain that is more honest. So the coins on the honest chain are the ones that are valuable. So miners are only able to profitably mine on the honest chain. 4 | 5 | This simple oracle mechanism has a big drawback. 6 | There is a large cost to having the users manually answer each oracle decision while downloading the blockchain. 7 | An attacker could ask lots of questions, and waste our time answering them. 8 | 9 | So, we need to adjust the mechanism so that if an attacker makes us manually answer a question, the cost to the attacker exceeds the damage inflicted on the network. 10 | 11 | The way to make oracle spam expensive is to use a market. 12 | 13 | If an attacker wants to spam the blockchain with questions, the attacker will also have to make large losing bets in the market. These losing bets cover the cost of other users having to manually answer the question. 14 | -------------------------------------------------------------------------------- /design/peers.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | In order to get headers from peers, they need to know your IP address and port. You need to be added to the list of peers on their nodes. 4 | You can see the list of peers stored on your machine like this: 5 | ``` 6 | peers:all(). 7 | ``` 8 | You can add yourself to the list like this: 9 | ``` 10 | peers:add({{1,2,3,4}, 8080}). 11 | ``` 12 | You can share your list of peers to peer P1 like this: 13 | ``` 14 | P1 = lists:nth(3, peers:all()). 15 | sync:trade_peers(P1). 16 | ``` 17 | 18 | 19 | To sync transactions with a peer that has ip 1.2.3.4 and port 8080: 20 | ``` 21 | api:txs({{1,2,3,4}, 8080}). 22 | ``` 23 | 24 | You can manually download headers from a peer: 25 | ``` 26 | sync:get_headers({{1,2,3,4}, 8080}). 27 | ``` 28 | You can see a list of all your peers like this: 29 | ``` 30 | peers:all(). 31 | ``` 32 | You can name a peer, and use it to get headers: 33 | ``` 34 | P1 = lists:nth(3, peers:all()). 35 | sync:get_headers(P1). 36 | ``` -------------------------------------------------------------------------------- /design/probabalistic_state_channels.md: -------------------------------------------------------------------------------- 1 | Probabilistic State Channels 2 | ========== 3 | 4 | 5 | renamed to [sortition pools](./sortition_pools.md) 6 | 7 | 8 | -------------------------------------------------------------------------------- /design/profiting_off_amoveo.md: -------------------------------------------------------------------------------- 1 | "what is the minimum amount of Aeons to operate a node that makes profit? 2 | 3 | Amoveo nodes can make a profit by facilitating off-chain payments or markets. 4 | 5 | The maximum volume of trades in the market is limited by how much money you have. So for a big market like a presidential election, you would need to be a whale. For smaller specialized prediction markets, like making decisions for a company like Aeternity, you probably only need $2000 to run a market like that. 6 | 7 | If your market is optimized to move the lightning-path that enforces trades to a shorter path, that will make it much easier to run these markets. You would need to lock up much less Aeons to run this type of market. 8 | 9 | As for routing payments, customers will prefer to pay lower fees, so they will prefer to make channels with accounts that are connected to as many other accounts as possible, so that the lightning payments will stay as short as possible. So the richest node will make the most profit per customer. 10 | The market will determine the minimum amount of money to have a profitable node. 11 | 12 | There will also be off-line networks, for people who want to make payments in places that don't have internet. Like burning man. These networks will have more limited coverage, and you could probably make a profit off of a networking node even if it only had $100. 13 | 14 | 15 | Amoveo nodes can make a profit by participating in the oracle mechanism. 16 | 17 | Using a node to profit from the oracle mechanism has no lower limit. 18 | Even $1 is enough. But your profit will be in proportion to your investment. Someone who participated with $1000 would earn profit 1000 times as quickly. 19 | -------------------------------------------------------------------------------- /design/smart_contracts_as_derivatives.md: -------------------------------------------------------------------------------- 1 | Smart Contracts as Derivatives 2 | ============== 3 | 4 | 5 | Scalability 6 | ============== 7 | 8 | In order to be scalable, we need to get rid of all shareable mutable state. Shareable mutable state needs to be synchronized, and the synchronization cost is O((# of participants)*(# of mutations)). It doesn't scale. 9 | 10 | Shared state cost is O(# of participants). it can scale. 11 | 12 | Mutable state cost is O(# of mutations). it can scale. 13 | 14 | 15 | Derivatives 16 | ============ 17 | 18 | Shareable immutable contracts, in the context of finance, are called derivatives. 19 | 20 | a derivative is a kind of smart contract where there is some rule about how money will be divided up onto the different sides of the contract. The rule is written once at the beginning, and stays immutable until the end. 21 | 22 | For blockchain applications, to create a new derivative we only need to put the hash of the derivative contract on-chain. 23 | The contract itself is only put on-chain if we need it for enforcement. 24 | 25 | 26 | Channels 27 | =========== 28 | 29 | Mutable un-shareable contracts, in the context of blockchain, are called "n-party state channels", or "channels" for short. 30 | 31 | Channels have mutable state that is known only the a finite number of participants. 32 | 33 | Eventually, when the channel resolves, the final version of the state is committed to on-chain, and the channel transforms into a derivative. 34 | 35 | 36 | Amoveo contracts 37 | ============ 38 | 39 | Amoveo contracts support both derivative and channel formats, and we make it as easy as possible to switch back and forth into these 2 scalable formats. 40 | 41 | You can use any asset defined by a derivative as the collateral for making new channels, so this means you can convert immutable-shareable contracts into mutable-unshareable contracts as needed. 42 | 43 | When channels get resolved, they transform into derivatives. So this means you can convert mutable-unshareable contracts into immutable-shareable contracts as needed. 44 | 45 | -------------------------------------------------------------------------------- /design/sortition_scaling/README.md: -------------------------------------------------------------------------------- 1 | sortition chains 2 | ============= 3 | 4 | sortition chains was an idea for sidechains. 5 | The inovation was using lottery style randomness so that the amount of information shrinks. only the winning lottery ticket matters, so only the winning ticket needs to come back onto the main chain. 6 | 7 | The issue we ran into. 8 | It needed some validator. And that validator could work with someone making a payment to execute double-spend attacks, or they can force you to hold lottery risk. 9 | 10 | Another issue was data availability attacks. If updates were made to the sortition chain, and only one person has a copy of the data you need to be able to spend your money, then he can charge you a lot of money for that data. 11 | If no one has a copy, then the validator could have done any sort of update without anyone knowing what changed. 12 | 13 | -------------------------------------------------------------------------------- /design/sortition_scaling/sortition_pools.md: -------------------------------------------------------------------------------- 1 | Sortition Pools 2 | ========== 3 | 4 | 5 | renamed to [sortition chains](./sortition_chains.md) 6 | 7 | -------------------------------------------------------------------------------- /design/state_channel_without_off_chain_market.md: -------------------------------------------------------------------------------- 1 | # secure atomic swapping. 2 | 3 | Atomic swaps as invented by TierNolan are very important theoretically. https://en.bitcoin.it/wiki/Atomic_cross-chain_trading 4 | They prove that it is possible to trustlessly exchange currency on one blockchain for currency on another. 5 | You can use a similar mechanism to show that exchanging different currencies on the same blockchain can be trustless. 6 | 7 | Unfortunately, atomic swaps have been worthless practically. 8 | It only solves half the problem. We don't _just_ want to swap tokens. We want to swap them at the current market price. 9 | 10 | So, for example, if you wanted to trustlessly use Bitcoin to buy Veo. 11 | The worry is that you will set up the atomic swap tx, and the person on the other side of the swap can decide at the last minute to either cancel or accept the swap, based on how the price of BTC/Veo moves. This is called the "free option problem". 12 | 13 | So, how do we solve the free option problem? 14 | First we need synthetic bitcoin on the Amoveo blockchain. Then you can use Amoveo markets to trustlessly change your Veo into synthetic bitcoin. 15 | You can trustlessly do an atomic swap to sell your synthetic bitcoin on Amoveo for bitcoin on the Bitcoin blockchain. 16 | Since the synthetic bitcoin and bitcoin both maintain the same price relative to each other, there is no free option. 17 | 18 | -------------------------------------------------------------------------------- /design/subcurrencies.md: -------------------------------------------------------------------------------- 1 | What would it look like to add subcurrencies to amoveo? like erc20. 2 | 3 | One way is if the smart contract wouldn't have any way to end and pay out. 4 | The smart contract has a Merkle root of account balances. Making a payment involves providing a proof of your balance and a signed message with a nonce saying you want to make the transfer. you also need a merkle root of who you are sending to. 5 | The smart contract calculates the new merkle root after making that transfer, and creates a child smart contract based on the new merkle root. 6 | 7 | This is a very general way to design any smart contract, and the main chain stays stateless. 8 | 9 | The merklized database of accounts data can be stored in a layer 2 network specialized for this subcurrency. 10 | 11 | Keeping the main chain stateless means we don't need to touch the hard drive to process blocks. Touching the hard drive is the slowest part, so skipping this makes it fast. 12 | Another way to allow for subcurrencies would be to let contracts have an option where they prevent any more deposits. So you can't convert veo to the subcurrency any more. 13 | 14 | This strategy has the benefit that your subcurrency works with the Automatic Market Makers, and the currency-swap transaction types. 15 | 16 | but it has the drawback that you can't program any other rules into it. It is just a subcurrency. -------------------------------------------------------------------------------- /design/trustless_exchange.md: -------------------------------------------------------------------------------- 1 | Trustless exchange 2 | ========= 3 | 4 | An exchange is a service that lets you swap one kind of cryptocurrency for another. For example, you can trade BTC for VEO. 5 | 6 | Exchanges today are all insecure. 7 | The centralized ones can steal your money by refusing to let you withdraw. 8 | The decentralized ones can steal your money by front running you, or using free options. 9 | 10 | Amoveo makes it possible to build a truly trustless exchange. 11 | This is an exchange that is completely secure against theft. 12 | 13 | The trick is to divide the process of the exchange into 2 steps. 14 | 1) transform your VEO into stable BTC on Amoveo. 15 | 2) do an atomic swap to trade your stable BTC on Amoveo for BTC on Bitcoin. 16 | 17 | step 1 is already live on Amoveo. 18 | 19 | step 2 works because stable BTC and BTC have a fixed ratio of prices relative to each other. So it isn't possible to front run the trade, because there is exactly 1 price that the trade can happen at. 20 | 21 | 22 | 23 | The stable bitcoin on Amoveo can be set up so their oracle finishes in 1 or 2 days. 24 | So you are trading BTC on Bitcoin for the price of BTC in tomorrow's worth of VEO on Amoveo. -------------------------------------------------------------------------------- /design/trustless_withdraw.md: -------------------------------------------------------------------------------- 1 | Trustless Withdraws 2 | ======== 3 | 4 | When we say that Amoveo has "trustless withdraws", what we mean is that it is impossible for anyone to prevent you to get your winnings out under any conditions. 5 | 6 | In many betting markets today, if you win too much or if the website suspects cheating, then they can make it extra difficult for you to get your money out. 7 | 8 | In Amoveo this cannot happen. The smart contracts are executed automatically based on the code. No person can prevent you from earning the money that the smart contract says you should have earned. -------------------------------------------------------------------------------- /design/truthcoin_contracts.md: -------------------------------------------------------------------------------- 1 | Truthcoin Contracts 2 | =========== 3 | 4 | Amoveo smart contracts in the context of Truthcoin's design. 5 | 6 | 7 | In Amoveo we have abstracted the idea of truthcoin oracles into 2 parts. Oracles and Contracts. 8 | 9 | Oracles answer a yes/no question, and make that data available. 10 | 11 | Contracts do the rest, and they are also able to do basic computation. 12 | The oracle data is available during that computation. 13 | The result of the computation decides how to divide up the collateral inside the contract between between the different share types. 14 | 15 | Cutting apart the oracle and the smart contract also allows us to make the smart contract before the oracle, which allows us to do last-minute optimizations in the oracle text. 16 | We can create a smart contract to report on the price. And the oracle question can end up being "Is the price of BTC $39567.34 ?", and when the oracle responds "true", then you have used a binary oracle to feed a 10 digit decimal number into the consensus state. -------------------------------------------------------------------------------- /design/using_governance.md: -------------------------------------------------------------------------------- 1 | The oracle only works to report things that are already common knowledge. 2 | The oracle has 2 major limitations from making it an effective tool for making decisions: 3 | * When you use the on-chain oracle, you can make different bets on each side of a fork. 4 | * Nakamoto consensus is optimizing for maximum hash rate, which is often contradictory with the goal of a large market cap. 5 | 6 | Luckily, Amoveo has scalable markets for derivatives, which are an ideal tool for communities to make decisions. 7 | We should use amoveo futarchy markets to make the decision, and then use the governance mechanism to report the communities choice to the blockchain. 8 | -------------------------------------------------------------------------------- /design/viral_info_plan.md: -------------------------------------------------------------------------------- 1 | Viral Info Plan 2 | ======== 3 | 4 | This document explains one possible way that Amoveo could achieve product market fit. 5 | 6 | 7 | Everyone reading social media, they are looking for information that makes them look high status. 8 | A prediction market is an ideal tool for creating this kind of information. 9 | 10 | It is like how if you make a scientific study just right, you can create evidence to support any political position. 11 | 12 | If we make a prediction market just right, we can have it create information that will go viral in our target social clique. 13 | For example, the debate about guns is a hot topic. 14 | If we can make a prediction market that provides any sort of evidence on which gun policy would be best, it has the potential to go viral. 15 | 16 | Ideally we could get opposing political movements to move part of their battle-ground onto Amoveo. So they would be paying for markets to prove facts to support their positions. 17 | That would be one kind of product market fit. 18 | 19 | 20 | 21 | How to make the markets short enough 22 | ============== 23 | 24 | Recently, the stock markets in Argentina reacted during the voting for their election, because it looked like the people who would win are the ones with the policy that is bad for business. 25 | 26 | Maybe we should make a prediction market to measure a correlation in the expectation of who will win, and things like bond prices and the price of a stock market. 27 | -------------------------------------------------------------------------------- /design/why_asics.md: -------------------------------------------------------------------------------- 1 | Amoveo wants to have ASICS for mining as soon as possible. 2 | 3 | GPU are bad for mining because the demand curve looks like a step-function. 4 | If Amoveo is 1% more profitable than the alternatives, then we get the majority of the miners. 5 | If Amoveo is 1% less profitable than the alternatives, then all the miners leave. 6 | 7 | 8 | In order for retargetting to work, we need the demand curve to increase smoothly as the price goes down. 9 | 10 | If we want a stable blocktime, then retargetting needs to work. 11 | 12 | In order to maintain the rate of production of new VEO, we need a stable blocktime. 13 | 14 | 15 | 16 | ASICS don't suffer the same problem as GPU. You can't re-use ASICS to mine on a different blockchain. Each ASIC is specialized for only one blockchain. 17 | So if we use ASICS, then the demand curve will increase smoothly as the price goes down. 18 | 19 | So with ASICS we can have a stable blocktime, which means that we can maintain the rate of production of VEO using the governance mechanism. -------------------------------------------------------------------------------- /design/why_markets.md: -------------------------------------------------------------------------------- 1 | # cryptoeconomic explanation for why we need markets for all smart contracts. 2 | 3 | 1) Cryptography tells us it is impossible for the owners of a channel to prove to anyone else the current or past state of their channel. This means it is impossible for anyone to prove how much they paid for a smart contract. 4 | 5 | 2) Economics tells us that markets are innefficient if only pairs of people make contracts at a secret price, because it is harder to measure the market price of anything. It is better to have one big market with lots of traders, that way we can measure the price accurately and the average person gets a better deal on their contract. 6 | 7 | (1) + (2) means that many channels will be connected together into markets. Any smart contract which isn't built as a market will be less profitable for the participants in comparison to a smart contract that is built as a market. 8 | Even contracts to play the game blackjack could be offered as a market, that way dealers and players are matched at a fair market price. 9 | -------------------------------------------------------------------------------- /exchanges/graviex_links.md: -------------------------------------------------------------------------------- 1 | Graviex Links 2 | ========== 3 | 4 | exchange: https://graviex.net/ 5 | 6 | channel 1 https://t.me/graviex 7 | 8 | channel 2 https://discord.gg/yM46E9 9 | 10 | channel 3 https://twitter.com/graviex_net 11 | 12 | channel 4 https://www.instagram.com/graviex_official/ 13 | 14 | channel 5 https://graviex.net/tickets/new 15 | -------------------------------------------------------------------------------- /failure_reports/30_5_2019.md: -------------------------------------------------------------------------------- 1 | 30 May 2019 2 | ===== 3 | 4 | On this date, for a period of about 22 blocks, all the nodes froze and would not mine new blocks. 5 | 6 | Loss 7 | ===== 8 | 9 | the block reward is 0.16, the difficulty was lower because of this, reducing the loss by about half. veo is around $80 10 | ```$(80* 22 * 0.16 / 2) = $141 ``` 11 | 12 | About $141 of hashpower was wasted because of my mistake, and I sincerely apologize to miners and mining pools who are paying this cost. 13 | 14 | What happened 15 | ====== 16 | 17 | 18 | Our anti-counterfeit tool caused us to freeze temporarily, because it thought that counterfeiting might be happening. 19 | Luckily there was no counterfeiting. 20 | 21 | Occasionally freezing like this is worth the peace of mind that it is impossible to produce veo out of nothing. 22 | If it breaks, it is far better to break by freezing instead of breaking by letting an attacker produce veo from nothing. 23 | this happened because hard update 17 changed how we deal with channel data after a channel is closed. The counterfeit scan tool thought that the channel was still open and had valid veo. 24 | 25 | 26 | How we will avoid this in the future 27 | ======= 28 | 29 | 1) we have already patched this error. 30 | 31 | 2) in the future when we modify tx types, we will take the time to verify that the anti-counterfeiting tool accepts the new format. 32 | 33 | 34 | Warning 35 | ====== 36 | 37 | This failure should serve us as a warning. 38 | Amoveo is very experimental software. 39 | There is high probability that you will lose everything that you invest in this project. 40 | Invest less than you can afford to lose. 41 | -------------------------------------------------------------------------------- /failure_reports/3_1_2021.md: -------------------------------------------------------------------------------- 1 | 3 January 2021 2 | ===== 3 | 4 | On this date, for a period of about 9 hours, no new blocks were mined. Starting at block 146219. 5 | 6 | Loss 7 | ====== 8 | 9 | 330 - 219 blocks = 111 blocks 10 | 22:14:14 - 00:44:52 = 22 hours 39.5 minutes = 1359.5 11 | 12 | 11 minutes per block. 1359.5 minutes should be about 123.6 blocks. but only 111 blocks were found. 13 | 14 | during the 9 hours, about 50 blocks were skipped. 15 | but because of lower difficulty afterwards, only around 11.6 block rewards were missed. 16 | According to qtrade, the current price is $20.14. 17 | the block reward is about 0.104 veo. 18 | ```$20.14 * 0.104 * 11.6 = $24.30.``` 19 | 20 | About $77.50 of hashpower was wasted because of my mistake, and I sincerely apologize to miners and mining pools who are paying this cost. 21 | 22 | What happened 23 | ====== 24 | 25 | At block 146220 hard update #44 activated to turn off support for legacy txs related to the old format of channels, and to get rid of the old Merkle for storing channel data, and to pay refunds to anyone who still had money left in the legacy Merkle tree. 26 | 27 | The new strategy is that channels are one type of smart contract, and so they get stored in the smart contract Merkle tree. 28 | 29 | This hard update was poorly planned, and it ended up corrupting the database on nodes that attempted to build a block according to the new ruleset, and preventing these nodes from producing more blocks. 30 | 31 | To fix this, we canceled hard update 44, and resynced the nodes that had been corrupted. 32 | 33 | -------------------------------------------------------------------------------- /getting-started/crypto_economics_political_inhibitions.md: -------------------------------------------------------------------------------- 1 | Cryptoeconomics is seen today as a mysterious field of study, only understood by geniuses. 2 | 3 | What makes cryptoeconomics so difficult? The math is fairly simple. 4 | The problem is that people's concept of money is intertwined with their political and religious beliefs. 5 | 6 | If you can let go of your preconceptions, and just look at the results of the math, you will find that crypto-economics is easy. 7 | 8 | 9 | Here are some uncomfortable facts you need to deal with if you want to understand cryptoeconomcs: 10 | 11 | * Life is not fair. There is no karma. 12 | * How you wish money works does not matter. Even if we all wish for something at the same time, it will not change reality. 13 | * We cannot wish value into existence, not even if we all wish at the same time. 14 | * Survival is not free. If you cannot produce or steal value, then you will die. 15 | * The outcome of voting is determined by whoever is willing to invest the most money into manipulating the outcome. 16 | * People always act in self-interest. Even people who tell themselves stories about acting for a "greater good". 17 | 18 | 19 | Once you have let go of your political inhibitions, then cryptoeconomics is merely the application of some simple math tools. 20 | 21 | * supply/demand curves 22 | * nash equilibriums 23 | * public/private key cryptosystems 24 | * one-way functions 25 | -------------------------------------------------------------------------------- /getting-started/dependencies.md: -------------------------------------------------------------------------------- 1 | You will need Erlang and a couple of libraries before you are able to run this software. 2 | 3 | [For Linux](linux_dependencies.md) 4 | 5 | 10 | 11 | -------------------------------------------------------------------------------- /getting-started/erlang_install.md: -------------------------------------------------------------------------------- 1 | First, make sure you have erlang installed. Version 18 is prefered, but older versions will probably work. Ubuntu makes erlang available in the package manager 2 | ``` 3 | sudo apt-get install erlang 4 | ``` 5 | 6 | Here is how to install erlang from source: 7 | download: https://www.erlang.org/download.html 8 | install instructions: https://www.erlang.org/doc/installation_guide/INSTALL.html 9 | -------------------------------------------------------------------------------- /getting-started/firewall.md: -------------------------------------------------------------------------------- 1 | EPMD gives a nice interface so you can run Amoveo programs in the background. This is important for running the integration tests. 2 | 3 | Before enabling EPMD, make sure to block port 4369, and other ports used by erlang, otherwise strangers will be able to control your Amoveo node. 4 | 5 | In Ubuntu, using root, issue these commands: 6 | ``` 7 | ufw default deny incoming 8 | ufw default allow outgoing 9 | ufw allow 22 10 | ufw allow 8080 11 | ufw enable 12 | ``` 13 | 14 | This will block everything from connecting your node, except for full node api on 8080, and ssh on 22 for administration of the server. 15 | 16 | you can check the status of your firewall like this: 17 | `ufw status` 18 | or 19 | `ufw status verbose` 20 | 21 | 22 | 23 | A useful command to look at what your ports are currently doing: 24 | `netstat -atu | grep "LISTEN"` 25 | 26 | 27 | 28 | epmd should start automatically, and you can just leave it running. So you probably never have to use these commands: 29 | 30 | If epmd is stuck running on a loopback interface, you may want to restart it so that your programs will run properly in the background again. 31 | 32 | Now that the fire wall is working, you can turn on epmd (if you do it manually, it is recommended to start epmd as root.): 33 | `epmd -daemon` 34 | 35 | epmd will continue running even if Amoveo is turned off. To turn off epmd use 36 | `epmd -kill` 37 | 38 | to see if epmd is already running, and list the erlang processes it is connected to. 39 | `epmd -names` 40 | 41 | 42 | a link with more info 43 | https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu-14-04 44 | -------------------------------------------------------------------------------- /getting-started/git_intro.md: -------------------------------------------------------------------------------- 1 | you don't need to know very much about git to program for Amoveo. 2 | 3 | you will need a github account. https://github.com/ 4 | 5 | once you have a github account, click the fork button on this page: https://github.com/zack-bitcoin/amoveo 6 | 7 | you should clone your own version from your profile on github with this command: 8 | `git clone https://github.com/YOUR_GITHUB_ACCOUNT/amoveo.git` 9 | 10 | that way you can make changes to the code and easily share it. And next time you apply for a software job, you can have this proof of work you did. 11 | 12 | to push your changes to your github profile: 13 | ```git add . 14 | git commit -m "explanation of these changes" 15 | git push origin master``` 16 | 17 | `git pull` is for pulling updates that are on github already. 18 | 19 | For everything else, you can use github's browser interface. 20 | -------------------------------------------------------------------------------- /getting-started/mac_dependencies.md: -------------------------------------------------------------------------------- 1 | install erlang version 18 or higher. 2 | You may need to install from source http://www.erlang.org/downloads 3 | 4 | Or use [Homebrew](https://brew.sh): 5 | ``` 6 | brew install erlang 7 | ``` 8 | 9 | It depends on sed, the stream editor 10 | ``` 11 | brew install gnu-sed --with-default-names 12 | ``` 13 | 14 | You need pip in order to install the next step: 15 | ``` 16 | easy_install pip 17 | ``` 18 | 19 | Use git to download the software, then go into the testnet directory 20 | ``` 21 | git clone https://github.com/zack-bitcoin/amoveo.git 22 | cd amoveo 23 | ``` 24 | -------------------------------------------------------------------------------- /getting-started/mining.md: -------------------------------------------------------------------------------- 1 | There are 3 pieces of software you might want to install: 2 | 3 | * amoveo full node 4 | * a miner, like the c-miner or the opencl-miner, or an FPGA miner. 5 | * a mining pool 6 | 7 | 8 | If you are going to connect to someone elses mining pool, then the only software you need is the miner. 9 | 10 | If you are going to be solo mining, then you need all 3. [Here is the solo mining guide.](./solo_mining.md) 11 | 12 | The mining pool and full node must be on the same computer. 13 | 14 | 15 | 16 | 17 | -------------------------------------------------------------------------------- /getting-started/mining_pool_survival.md: -------------------------------------------------------------------------------- 1 | Mining Pool Survival 2 | ======= 3 | 4 | 5 | 6 | It is important for the security of Amoveo that no individual mining pool should have more than 50% of the hashrate. If they do, then they could rewrite history to steal Veo from us all. 7 | 8 | This page lists strategies we have found to make mining pools stronger in the face of denial-of-service attacs. 9 | 10 | * make a white list of who can contact your full node. Only accept connections from other full nodes. 11 | -------------------------------------------------------------------------------- /getting-started/nixos_install/README.md: -------------------------------------------------------------------------------- 1 | first send the install script to the nixos server. 2 | ```cat NixosInstall.bin | NIX_CHANNEL=nixos-20.09 bash 2>&1 | tee /tmp/infect.log``` 3 | 4 | then `ssh veo@ip-addr` 5 | 6 | The dependencies are ready. Now you can [turn it on normally by downloading it from github](../turn_it_on.md) 7 | -------------------------------------------------------------------------------- /getting-started/nixos_install/install.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | cat NixosInstall.bin | NIX_CHANNEL=nixos-20.09 bash 2>&1 | tee /tmp/infect.log 4 | -------------------------------------------------------------------------------- /getting-started/p2p_derivatives_beta.md: -------------------------------------------------------------------------------- 1 | P2P derivatives beta 2 | ============== 3 | 4 | This is instructions on how to participate in testing the new feature on the testnet. You can do binary derivatives and scalar. With scalar you can make stablecoins. 5 | 6 | Here you can spend veo 7 | http://46.101.81.5:8070/wallet.html?mode=testnet 8 | 9 | For initiating the derivatives contract: 10 | http://46.101.81.5:8070/otc_derivatives.html?mode=testnet 11 | 12 | For waiting for someone else to initiate a contract: 13 | http://46.101.81.5:8070/otc_listener.html?mode=testnet 14 | 15 | For ending the contract, once the oracle is finished: 16 | http://46.101.81.5:8070/otc_finisher.html?mode=testnet -------------------------------------------------------------------------------- /getting-started/ports.md: -------------------------------------------------------------------------------- 1 | A node uses two ports. 2 | 3 | The first one is public and exposes API for transactions . 4 | 5 | The other one is private and exposes more functions that are supposed to leverege unlocked account that the node is running. Currently, we protect the private port by accepting requests only from localhost. You can lose money if you don't protect the internal port! 6 | 7 | You can change default port numbers by changing values in Makefile or config file (depending at what stage you are configuring a node). -------------------------------------------------------------------------------- /getting-started/profiting_from_amoveo.md: -------------------------------------------------------------------------------- 1 | Profiting from Amoveo 2 | ====== 3 | 4 | 5 | [have a look at the use cases and ideas folder. There are a lot of potential business plans](../use-cases-and-ideas/) 6 | 7 | The best way depends on your skills, there are a lot of opportunities in Amoveo. 8 | You could run a gambling server that is secured by amoveo channels. Similar to what Amoveobook is doing. 9 | You could run a service for exposing corruption in a business or government. 10 | You could invest in veo, run a mining pool, write mining software, run mining hardware. 11 | You could use a dominant assurance contract to pay you for creating some public good. A few examples: software to benefit the community, an advertisement, a video, a song. -------------------------------------------------------------------------------- /getting-started/reporting_bugs.md: -------------------------------------------------------------------------------- 1 | Reporting Bugs 2 | ===== 3 | 4 | Learning how to report bugs is probably the most effective thing an early adopter of new technology can do to help the project succeed. 5 | Reporting Bugs can be intimidating. 6 | It is not obvious what information is important for the developer, and should be included in the report. 7 | This guide is designed to simplify the process, so that making bug reports is fast, easy, and enjoyable. 8 | 9 | A good bug report often includes these parts: 10 | 1) tell a story of your intended interaction with the software. 11 | * what is the intended goal of using the software? 12 | * a timeline of commands you type, or buttons you press. 13 | 2) explain how the output of the program differed from your expectations. 14 | 3) include all outputs from the program that differ from your expectations, and a little more for context. 15 | -------------------------------------------------------------------------------- /getting-started/solo_mining.md: -------------------------------------------------------------------------------- 1 | 2 | ## Solo mining 3 | 4 | #### During the process, if you face any problems, please see troubleshooting section at the end of this doc. 5 | 6 | ##### 1/ Cloning source 7 | https://github.com/zack-bitcoin/amoveo 8 | 9 | [install the amoveo full node and turn it on](./turn_it_on.md) 10 | 11 | https://github.com/zack-bitcoin/amoveo-mining-pool 12 | 13 | There are instructions for installing the mining pool and turning it on in the README of that project. 14 | 15 | 16 | ##### 2/ Now test your pool 17 | run this in terminal 18 | ``` 19 | curl -i -d '["mining_data"]' http://127.0.0.1:8085 20 | ``` 21 | If it shows something like: 22 | ``` 23 | ["ok",[-6,"F8iaECO9d0M2kmik0g0i9nMfAf6URiPOcrA0+VMIEUs=","52MYc3JWoVbIfHV0VEYTWqH/uf+R+qk=",257]] 24 | ``` 25 | Then you have correctly installed the mining pool. 26 | 27 | ### Troubleshooting 28 | 29 | A common issue is erlang keeps running in background after crashing. you can kill all the erlang processes with `sh kill_all_erlang.sh` 30 | 31 | Join us on telegram if you run into any issues while trying to solo mine. 32 | 33 | 44 | -------------------------------------------------------------------------------- /getting-started/updating.md: -------------------------------------------------------------------------------- 1 | ## The commands for updating. 2 | 3 | first turn the node off. 4 | Attach to it 5 | ```make prod-attach``` 6 | 7 | stop it from syncing to prevent corrupted state 8 | ```sync:stop().``` 9 | 10 | turn off the full node 11 | ```api:off().``` 12 | 13 | turn off the erlang terminal 14 | ```halt().``` 15 | 16 | update the dependencies. 17 | ```./rebar3 upgrade``` 18 | 19 | update Amoveo 20 | ```git pull``` 21 | 22 | if you want to use the new version of the config file, then remove old version of the config file. 23 | ```rm config/sys.config.tmpl``` 24 | 25 | if you need to delete the old blocks 26 | ```make prod-clean``` 27 | [in that case see the syncing instructions](sync.md) 28 | 29 | turn the node back on 30 | ```make prod-restart``` 31 | 32 | If you want it to re-sync rejected blocks with the new rules (only important if your node is frozen at a historical height because you didn't update in time for a hard update.) 33 | ```block_hashes:second_chance().``` 34 | 35 | the blocks are already synced, so switch to normal mode 36 | ```sync_mode:normal().``` 37 | 38 | if you want to make transactions, you need to unlock the keys: 39 | ```keys:unlock("").``` 40 | 41 | Now you can detach from the running node, and allow it to continue running in the background by holding the Control key, and pressing the D key. 42 | -------------------------------------------------------------------------------- /getting-started/using_epmd.md: -------------------------------------------------------------------------------- 1 | EPMD gives a nice interface so you can run Amoveo programs in the background. This is important for running the integration tests. 2 | 3 | Before enabling EPMD, make sure to block port 4369, and other ports used by erlang, otherwise strangers will be able to control your Amoveo node. 4 | 5 | In Ubuntu, using root: 6 | `ufw default deny incoming` 7 | `ufw default allow outgoing` 8 | `ufw allow 22` 9 | `ufw allow 8080` 10 | `ufw enable` 11 | 12 | This will block everything from connecting your node, except for full node api on 8080, and ssh on 22 for administration of the server. 13 | 14 | you can check the status of your firewall like this: 15 | `ufw status` 16 | or 17 | `ufw status verbose` 18 | 19 | 20 | 21 | 22 | epmd should start automatically, and you can just leave it running. So you probably never have to use these commands: 23 | 24 | Now that the fire wall is working, you can turn on epmd: 25 | `epmd -daemon` 26 | 27 | epmd will continue running even if Amoveo is turned off. To turn off epmd use 28 | `epmd -kill` 29 | 30 | to see if epmd is already running: 31 | `epmd -names` 32 | 33 | 34 | 35 | 36 | -------------------------------------------------------------------------------- /history_state_channels.md: -------------------------------------------------------------------------------- 1 | History of the invention of State Channels. 2 | 3 | Zack started programming Channels July 2015 4 | https://github.com/BumblebeeBat/FlyingFox/commit/1c15ca90ee2d4248d0445ed59cf3f4878b896d6e 5 | 6 | Zack invented the idea of state channels in August 2015 7 | https://github.com/BumblebeeBat/FlyingFox/commit/5b229bc94e0623df4764fffc4ec2af2831b6ec1f#diff-4349690c4538ef9906e7e2776468470f 8 | 9 | It took over a year of experiments for him to figure out how to build state channels so that they work well. 10 | on October 2 2016 Zack understood channels as we are building them today, and he presented his results to the Blockchain community via forums and emails. 11 | https://github.com/BumblebeeBat/PinkFairy/commit/a61fe20807814fd5393885ed8d86f94f41d07d88 12 | 13 | The idea was popular, and Jeff Coleman wrote his famous introduction to state channels a month later: http://www.jeffcoleman.ca/state-channels/ 14 | 15 | But, Jeff and the Ethereum community didn't yet completely understand Zack's message. The Ethereum community is aware that channels could store state for the blockchain to look at, but channels can do much more than that. Actually, as Zack realized in 2015, channels can have turing complete computation for smart contracts. 16 | 17 | -------------------------------------------------------------------------------- /investing.md: -------------------------------------------------------------------------------- 1 | Amoveo doesn't use investing in the traditional sense. 2 | 3 | [I think icos are bad](icos.md) 4 | 5 | I don't want to spend your money for you. 6 | 7 | Amoveo will have miners, so if you want to invest you could mine Amoveo. 8 | Amoveo will also have smart contracts that could be profitable. If you want to invest you could make some smart contracts. 9 | Amoveo will need nodes to be the hubs for the hub-and-spoke lightning network. If you want to invest, you could operate these nodes. 10 | Amoveo software development will be funded by dominant assurance contracts, so people who want to invest could participate in those. -------------------------------------------------------------------------------- /license_note.md: -------------------------------------------------------------------------------- 1 | It isn't possible to own software. 2 | Intellectual property isn't real. 3 | The license only gives away legal permission to use this software. 4 | I never owned the software, so I cannot give it away, and I cannot stop you from using it. -------------------------------------------------------------------------------- /light_node/glossary/accepting_channel_offer.md: -------------------------------------------------------------------------------- 1 | Accepting a Channel Offer 2 | ========== 3 | 4 | Lets say that Bob made a bet on the outcome of a football game, and he posted it online. Now you want to accept the other side of the bet. What do you need to do? 5 | 6 | Take the raw contract data that Bob posted online, and use the otc_listener.html page of the light node, for example it is hosted [here](http://46.101.81.5:8080/otc_listener.html) 7 | 8 | When you copy/paste the raw contract data from Bob, or upload the file to otc_listener, it will allow you to view the details of the contract from inside the light node before you choose to accept. This way it is not possible for an attacker to trick you into accepting a contract that you did not want to accept. -------------------------------------------------------------------------------- /light_node/glossary/binary_bet.md: -------------------------------------------------------------------------------- 1 | Binary Bet 2 | ======= 3 | 4 | A binary bet is one where one of the two parties ends up winning all the money from the contract. 5 | To make a binary contract, you need to connect to a binary oracle. 6 | 7 | Caution, each of the 10 bits of a scalar oracle is actually a binary oracle, so don't make a bet on the first bit of a scalar oracle, thinking it is a binary oracle. -------------------------------------------------------------------------------- /light_node/glossary/binary_oracle.md: -------------------------------------------------------------------------------- 1 | Binary Oracle 2 | =========== 3 | 4 | An oracle is an on-chain mechanism designed to get users to accurately report information to the blokchain. 5 | A binary oracle is for when the blockchain wants to find out the answer to a true/false question. 6 | 7 | If you want to bet on who will win a football game, you will need to conect the betting contract to the oracle. That way the contract will know who won the bet, so it will know who to give money to. 8 | 9 | Here is a page where you can ask the oracle new questions http://46.101.81.5:8080/new_oracle.html -------------------------------------------------------------------------------- /light_node/glossary/collateral.md: -------------------------------------------------------------------------------- 1 | Collateral 2 | ======== 3 | 4 | every contract is enforced by locking up some veo in it. 5 | 6 | Lets say we made a contract that is worth $50 of USD stablecoins. 7 | in order to enforce that someone owns the $50, the contract would need to have at least $50 worth of veo locked inside of it. 8 | If the price of veo/usd falls, then eventually the value of the veo locked in the contract could become worth less than $50, and the stablecoin becomes worth less than USD. 9 | 10 | In order to protect the value of the stablecoin, we need to lock more than $50 of veo into the contract, just in case the price of veo falls before the contract finishes. 11 | 12 | If we lock $75 of veo in the contract, then the contract is 150% collateralized. because 75/50 = 1.5 13 | 14 | if we lock $110 of veo in the contract, then it is 220% collateralized, because 110/50 = 2.2 15 | 16 | The collateralization of the stablecoin is connected to the leverage of the inverse-stablecoin. 17 | higher collateralization means lower leverage. -------------------------------------------------------------------------------- /light_node/glossary/derivatives_payment.md: -------------------------------------------------------------------------------- 1 | Derivatives Payment 2 | =========== 3 | 4 | When you make a derivative from the otc_derivatives page, you need to say how much you are paying or being paid for this contract. 5 | 6 | For example, I want to double my VEO exposure quickly. 7 | To convince many people to sell me their VEO exposure right away, I offer to pay them a 5% premium. 8 | So if they buy $100 of stablecoin from me, and hold it for a month, they will have $105 at the end of the month. 9 | 10 | To do this, I need to tell the otc_derivatives page to lock up $100 of veo into the stablecoin contract, and to keep to just pay $5 to the other person directly. 11 | 12 | The otc_derivatives tool atomically combines the payment with the smart contract, so neither of you has any risk. 13 | 14 | If you want to pay someone to do a contract with you, this value should be positive. If you want to get paid to make a contract with someone, then you should make this number negative. -------------------------------------------------------------------------------- /light_node/glossary/messenger_credits.md: -------------------------------------------------------------------------------- 1 | Messenger Credits 2 | ========= 3 | 4 | If you want to send encrypted messeges through an Amoveo messenger server, you need to buy credits. 5 | Your light node will automatically purchase more credits if you run out. You need to wait for the next block to be mined before you receive the credits. -------------------------------------------------------------------------------- /light_node/glossary/oracle.md: -------------------------------------------------------------------------------- 1 | Oracle 2 | ========= 3 | 4 | An oracle is an on-chain mechanism designed to get users to accurately report information to the blokchain. -------------------------------------------------------------------------------- /light_node/glossary/oracle_id.md: -------------------------------------------------------------------------------- 1 | Oracle ID 2 | ========= 3 | 4 | An Oracle ID or OID is a short binary value used to identify an Oracle. 5 | Both binary and scalar oracles have OIDs. 6 | If you want to make a contract that references an oracle, you need to write that oracle's OID into the contract. 7 | 8 | We often encode OIDs into base64 when we want to copy/paste them. 9 | For example abQmqMdgpas0zRpAji1DShVFD7kauQrCrZJJC6005c4= 10 | 11 | The OID is uniquely defined by the question being asked of the oracle, and the height at which the resolution process will begin. This way we are able to use an OID before an oracle has been created. 12 | 13 | -------------------------------------------------------------------------------- /light_node/glossary/oracle_question.md: -------------------------------------------------------------------------------- 1 | Oracle Question 2 | ========== 3 | 4 | This is a question that people will read to decide how to report information to the blockchain. 5 | 6 | Example binary oracle questions: 7 | "Donald Trump was elected president for a second term." 8 | "The high temperature in New York on March 2, 2019 will be less than 25 Celcius." 9 | 10 | Example scalar oracle questions: 11 | "The price of USD in VEO from 0 to 0.05 on March 2, 2019." 12 | "The price of BTC in VEO from 0 to 130 on March 2, 2019." 13 | "The price of BTC in USD from 0 to 10 000 on March 2, 2019." 14 | 15 | If you want to make a stablecoin, it is important to always ask for "the price of X in VEO". Do not ask for "the price of VEO in X", or else the contract will not work as a stablecoin. 16 | 17 | The otc_derivatives page can auto-fill the upper oracle limit from the oracle text, if you format the oracle correctly. 18 | otc_derivatives searches for the word "from", then it seraches for the word "to", and it assumes that the next number displayed is the upper limit of what the oracle can measure. 19 | So it is good to use the substring "from 0 to ", if you intend to use it for stablecoins. -------------------------------------------------------------------------------- /light_node/glossary/oracle_starts.md: -------------------------------------------------------------------------------- 1 | Oracle Starts 2 | =========== 3 | 4 | This is the earliest date at which people can start reporting to the oracle mechanism. It is measured by the block height. 5 | 6 | If you want to bet on a football game, you should find out a date and time when you are certain that the result of the game will be known. Figure out what the Amoveo block height will be at that time. 7 | 8 | For example, there are currently 130 blocks per day, and we are at block height 55000. So, in 3 days, we will be at block 55390. 9 | So if I wanted to bet on a football game that I was sure would end 3 days, then I should use "55390" for the oracle starts variable. -------------------------------------------------------------------------------- /light_node/glossary/oracle_types.md: -------------------------------------------------------------------------------- 1 | Oracle Types 2 | ========= 3 | 4 | There are 2 basic kinds of oracles in Amoveo, [scalar](scalar_oracle.md) and [binary](binary_oracle.md). -------------------------------------------------------------------------------- /light_node/glossary/scalar_bet.md: -------------------------------------------------------------------------------- 1 | Scalar Bet 2 | ========= 3 | 4 | A scalar bet is where the money in the contract gets divided between the two participants based upon a 10-bit value measured by the oracle. 5 | A scalar oracle can return any number between 0 and 1023. 6 | 7 | With a scalar bet, the money gets split up based upon what number is returned by the oracle. 8 | 9 | For scalar bets, you need to use a scalar oracle. binary oracles will not work. 10 | -------------------------------------------------------------------------------- /light_node/glossary/scalar_oracle.md: -------------------------------------------------------------------------------- 1 | Scalar Oracle 2 | =========== 3 | 4 | An oracle is an on-chain mechanism designed to get users to accurately report information to the blokchain. 5 | A scalar oracle is for when the blockchain wants to find out a numerical value. 6 | 7 | If you want to make a stablecoin that stays the same value as the Euro, you will need to connect the stablecoin contract to a scalar oracle that is measuring the price of the Euro in Veo. That way the contract will know how to distribute the Veo to correctly enforce a stablecoin contract. 8 | 9 | Here is a page where you can ask the oracle new questions http://46.101.81.5:8080/new_oracle.html 10 | -------------------------------------------------------------------------------- /light_node/glossary/stablecoin_bet.md: -------------------------------------------------------------------------------- 1 | Stablecoin Bet 2 | =========== 3 | 4 | A stablecoin bet is a type of scalar bet. The difference is that the interface on otc_derivatives is optimized for making stablecoin type contracts. 5 | 6 | A BTC stablecoin contract is an asset that stays the same value at BTC. If one participant in the channel has stablecoins, that means the other participant has extra exposure to VEO. 7 | 8 | To use a stablecoin bet, it must be connected with a scalar type oracle, and the oracle must ask "what is the price of X in VEO." you cannot ask "what is the price of VEO in X", because that will not work for stablecoins. -------------------------------------------------------------------------------- /light_node/glossary/stablecoin_current_value.md: -------------------------------------------------------------------------------- 1 | Stablecoin Current Value 2 | =========== 3 | 4 | in otc_derivatives, if you want to make a stablecoin contracts, you are asked to prove the "current value". 5 | 6 | For example, if the oracle is asking "What is the price of BTC in VEO?", and it wont expire for 1 month, then we cannot predict what the oracle will resolve to in 1 month. 7 | But we do know that the current price of BTC is in VEO. This current price is the "current value" that you need to provide in the contract. 8 | 9 | For example, if BTC is worth $4000, and VEO is worth $80, then the current value would be 50. -------------------------------------------------------------------------------- /light_node/glossary/stablecoin_leverage.md: -------------------------------------------------------------------------------- 1 | Stablecoin Leverage 2 | ============== 3 | 4 | When you are making a stablecoin contract, you are asked to provide a value called "leverage". 5 | This is a number that must be greater than 1. 6 | 7 | For example, if I buy a stablecoin contract connected to BTC with a leverage of 1, and the price of BTC increases by 10% over the lifetime of my contract, then my side of the contract will be worth 10% more by the end. 8 | 9 | If I buy a stablecoin contract connected to BTC with a leverage of 3, and the price of BTC increases by 10% over the lifetime of the contract, then my side of the contract will be worth 30% more by the end. 10 | 11 | 12 | Leverage and margins are deeply connected. 13 | Margins are the prices beyond which only one side controls all the veo in the contract. 14 | If you increase the leverage, the margins must necessarily become tighter. -------------------------------------------------------------------------------- /light_node/make_channel.md: -------------------------------------------------------------------------------- 1 | Make sure that the channel will stay open long enough so that you can participate in the market you are interested in. 2 | 3 | The channel delay needs to be 100 or bigger. 4 | 5 | 6 | Make sure to save your channel state every time it is updated. 7 | It is possible to trustfully download the channel state from the server, but trust is bad. We are trying to make trust-free technology. -------------------------------------------------------------------------------- /light_node/market.md: -------------------------------------------------------------------------------- 1 | To participate in the market, first you need to [make a channel](make_channel.md) 2 | 3 | You need to wait until the new_channel tx is included in a block before you can make any bets. 4 | 5 | You need to download all the headers before you can make any bets in the market. 6 | 7 | if your price is 25, and the amount you bet is 1, then at most you can win 3, and at most you can lose 1. 8 | 9 | If your price is 75 and you bet 3, then at most you can lose 3, and at most you can win 1. 10 | 11 | price is the same as percentage odds. 12 | 13 | When your bet is successfully accepted, the "amount" should disappear. 14 | 15 | -------------------------------------------------------------------------------- /light_node/user_stories.md: -------------------------------------------------------------------------------- 1 | User Stories 2 | ========= 3 | 4 | different people have a different process of using Amoveo's light node. 5 | 6 | 7 | # liquidity farmer process 8 | 9 | * acquire the 2 kinds of currency needed for the market 10 | * deposit them into the market to get liquidity shares 11 | * wait 12 | * exchange your liquidity shares for the 2 kinds of currency + trading fees you have earned. 13 | 14 | # trader in high volume standardized markets process 15 | 16 | * swap veo for the subcurrency that represents the bet that you want to make. 17 | * later sell your subcurrency, hopefully at a higher price. or if you won the bet, withdraw your winnings. 18 | 19 | # selling customized bespoke contracts 20 | 21 | * use the id generator to know the id of the currency that represents the contract you want to own, generate the ID. 22 | * use that id to make a swap offer, where you would buy what you want. 23 | * someone accepts the swap offer to take the other side of your custom contract, this also creates the contract on-chain. 24 | 25 | # new market creator process 26 | 27 | * if the contract doesn't yet exist, then use the new_contract tool to specify how the money in the contract should get divided among the subcurrencies. 28 | * use the set_buy tool to acquire the different flavors of subcurrency from the contract, that represent participating in the different sides of the contract. 29 | * create the market using the new_market tool and depositing the initial liqudity into the market. 30 | 31 | # market resolution process 32 | 33 | * use the oracle_bet tool to make a report on the outcome of the oracle. 34 | * wait enough time for the oracle to become resolvable. 35 | * use the oracle_close tool to finalize the outcome of the oracle. 36 | * use the contract_resolve tool so the smart contract will read from the oracle, and decide how to divide up it's value between it's subcurrencies. 37 | 38 | -------------------------------------------------------------------------------- /merging-and-testing/git_hints.md: -------------------------------------------------------------------------------- 1 | ## Couple hints for effective work with git 2 | 3 | * commit often 4 | * squash to one commit representing one logical unit 5 | * make every commit pass tests (it helps with bisecting and cherry-picking) 6 | * rebase with master often -------------------------------------------------------------------------------- /merging-and-testing/merging_rules.md: -------------------------------------------------------------------------------- 1 | ## Code repository 2 | 3 | We host our project in github repository. 4 | 5 | We leverage Pull Request to accept contributions 6 | 7 | ### Acceptance criteria 8 | 9 | 1. The change is accepted by core team 10 | 2. It passes [integration test](testing.md), [unit tests](unit_testing.md) 11 | 3. Changes are submitted with tests that cover them 12 | 4. Documentation from /docs directory is updated if relevant 13 | 14 | If #1 is true or maybe you picked up task from todo list, then reach out to core team to get help with #2-#4! -------------------------------------------------------------------------------- /merging-and-testing/rebar_lock.md: -------------------------------------------------------------------------------- 1 | 2 | ## Overview 3 | 4 | We need a way to guarantee that no accidential changes in dependencies afect the core code. 5 | 6 | One of mechanism to do it, is to lock dependencies to specific hashes representing version. 7 | 8 | Our build system (rebar) supports that with lock/unlock api 9 | 10 | 11 | ### Commands 12 | 13 | To update rebar lock on local machine. 14 | 15 | ``` 16 | ./rebar3 dependency-unlock 17 | make local-build 18 | ``` -------------------------------------------------------------------------------- /merging-and-testing/rebase.md: -------------------------------------------------------------------------------- 1 | 2 | For merging from branches. 3 | 4 | ``` 5 | git pull --rebase origin master 6 | ``` -------------------------------------------------------------------------------- /merging-and-testing/testing.md: -------------------------------------------------------------------------------- 1 | ### Introduction 2 | 3 | Acceptance tests are written in python. 4 | 5 | [you can read about single-node tests here](unit_testing.md) 6 | 7 | 8 | ### Basic usage 9 | 10 | To run the tests, run `make tests`. 11 | This will: 12 | * kill all running `amoveo` nodes 13 | * build 3 test nodes 14 | * start all 3 tests nodes 15 | * run python tests on these nodes 16 | * kill the nodes 17 | 18 | ### Detailed usage 19 | 20 | You can turn on the 3 test nodes like this: 21 | `make multi-quick` 22 | 23 | If the 3 nodes are running, you can run all the integration tests with this command: `python tests/all_tests.py`. 24 | 25 | If the 3 nodes are running, you can run all the integration tests individually. For example, here is running the fork tests individually: 26 | `python/fork.py` 27 | 28 | To see what is broken, you can look at logs for each of the 3 nodes. The 2nd nodes log is in: `_build/dev2/rel/ae_core/log` 29 | 30 | To attach to the 2nd running node and give it commands from the erlang terminal: `make attach2` 31 | -------------------------------------------------------------------------------- /merging-and-testing/unit_testing.md: -------------------------------------------------------------------------------- 1 | 2 | start a local node, and attach to it: 3 | `make local-quick' 4 | 5 | single-node tests are run like this: 6 | `tester:test().` 7 | 8 | [you can read about multi-node tests here](testing.md) -------------------------------------------------------------------------------- /other_blockchains/README.md: -------------------------------------------------------------------------------- 1 | ### Other Blockchains 2 | 3 | 4 | This is where I talk about strengths and weaknesses of other blockchain projects besides Amoveo. 5 | 6 | Looking at other projects can help make it clear why Amoveo is designed the way it is. 7 | 8 | Sometimes other projects pay me to do a review of them, because this helps them know how to improve. 9 | 10 | Each document has a date on it. 11 | The information will expire very quickly. 12 | These projects are still in progress, they are constantly changing. -------------------------------------------------------------------------------- /other_blockchains/bitcoin_without_block_rewards.md: -------------------------------------------------------------------------------- 1 | Bitcoin Without Block Rewards 2 | ======== 3 | 4 | 5 | The problem was that if bitcoin's block reward got lower than the tx fees, it could cause conensus to break. 6 | http://randomwalker.info/publications/mining_CCS.pdf 7 | 8 | It might become more profitable to attempt to under-cut the other miners, by mining at a lower block-height to include the txs from their blocks to take their fees. 9 | 10 | The solution https://twitter.com/fnietom/status/1037235118136602625 11 | Miners should sometimes share their reward with whoever will mine the next block. 12 | 13 | 14 | -------------------------------------------------------------------------------- /other_blockchains/blitzkrieg_freedom_project.md: -------------------------------------------------------------------------------- 1 | Economics of Blitzkrieg Payments 2 | ========= 3 | 4 | Blitzkrieg is an interesting project because they use a 4.1 level security mechanism, but they keep the portion of money locked inside the 4.1 part of the mechanism very small. The vast majority of the funds are in 2.2 level security parts of the blockchain. 5 | 6 | The goal of this paper is to find out how effective this trick can be, and when it makes sense to use it. And to compare this design vs an alternative where we would use a level 2.2 on-chain entropy generator. 7 | 8 | The costs we want to measure are: 9 | * cost due to risk in probabilistic payments. You could get unlucky and lose a lot of money. Variance cost. 10 | * cost due to trusting the finder. Finder's fee. 11 | 12 | Variance Cost 13 | ======= 14 | 15 | How much do we have to charge per probabilistic payment. 16 | 17 | The channel hubs need to keep enough liquid capital to continue providing their service. So they want to have mathematical certainty that losing more than N portion of their money in a single month is something that happens less than M portion of the months. 18 | 19 | If the individual payments are more or less the same size 20 | 21 | What we know: 22 | N we can lose this portion of money less than ... 23 | M portion of months. 24 | P payments per month. 25 | A average amount sent. 26 | 27 | 28 | Prob(I,N,P) -> 29 | %I is starting balance 30 | %N is goal balance 31 | %P probability that you increment instead of decrement. 32 | X = (1-P)/P, 33 | (1 - (X^I)) / (1 - (X^N)). %probability of getting rich 34 | 35 | Prob( 36 | 37 | 38 | 39 | What we want to know: 40 | Q What portion of our money should we lock into a probabilistic payment account? 41 | F How much fee should we charge per tx 42 | 43 | 44 | Finder's Fee 45 | ======= 46 | 47 | The finder could run off with the money in a single payment. 48 | So their expected profit from fees from all their payments in the future needs to exceed the expected cost of stealing the money in this single payment. 49 | -------------------------------------------------------------------------------- /other_blockchains/idena.md: -------------------------------------------------------------------------------- 1 | Idena 2 | ========== 3 | 4 | https://idena.io/ 5 | 6 | Idena is a blockchain that tries to achieve consensus through a democratic process where one human = one vote. 7 | They do this by having a weekly short period of time where they give out problems that are hard for computers, and easy for people. AI-hard problems. 8 | 9 | Idena is not secure. 10 | =========== 11 | 12 | Even if Idena did work, and was a secure one-human-one-vote protocol, that is still not secure. [you can't have secure voting in blockchains](https://github.com/zack-bitcoin/amoveo-docs/blob/master//design/voting_in_blockchains.md) 13 | 14 | But, they also fail to build a secure one-human-one-vote protocol. 15 | 16 | Idena gives out the same AI-hard problems to all the participants, and the median of their responses is the correct response. 17 | This means if one person controls multiple accounts, they can solve the problem once, and then it is solved in all their different accounts. So, Idena is vulnerable to sybil attacks. -------------------------------------------------------------------------------- /other_blockchains/idex_sidechains.md: -------------------------------------------------------------------------------- 1 | IDEX sidechains review 2 | ======== 3 | 4 | [Here is a blog post from IDEX describing their sidechain plan](https://blog.idex.io/all-posts/o2-rollup-overview) 5 | 6 | It looks like the IDEX team will be operating a trusted sidechain to store all the trades in their decentralized exchange. 7 | The problem with this strategy is that the IDEX team can choose the order to do the trades. They can front run everyone. 8 | Front-running is just one example of how it can break. 9 | 10 | [Here is a video about why markets that are vulnerable to front-running attacks are insecure](https://youtu.be/mAtD0ba-hXU) 11 | 12 | The fact that they refer to this as "optimistic roll up" makes me consider it a scam. 13 | In optimistic roll up as defined by this paper https://arxiv.org/pdf/1904.06441.pdf anyone who mines a main chain block can include some data to add a block to the sidechain. 14 | There is a safety deposit paid when you add a block to the sidechain. 15 | Optimistic roll up is decentralized, anyone who is participating is the same as everyone else. 16 | 17 | [Here is a comment from the author of the optimistic roll up paper](https://twitter.com/jadler0/status/1194653628008730624?s=20) 18 | 19 | The IDEX plan in this blog post is completely different. Their team is the only ones who can add blocks to the sidechain. This creates a centralized failure mode. 20 | 21 | 22 | -------------------------------------------------------------------------------- /other_blockchains/iota.md: -------------------------------------------------------------------------------- 1 | Iota Review 2 | ====== 3 | 4 | Iota descripton from their team: https://assets.ctfassets.net/r1dr6vzfxhev/2t4uxvsIqk0EUau6g2sw0g/45eae33637ca92f85dd9f4a3a218e1ec/iota1_4_3.pdf 5 | 6 | This review is applying the techniques from this paper: [proof_of_stake.md](/other_blockchains/proof_of_stake.md) 7 | 8 | The pow half of Iota's pow/pos hybrid model is not being used for consensus. It is cheap to get >50% hashpower, but having >50% hashpower wont matter. It is just an anti-spam feature so that the total number of valid messages that a full node would have to consider has some reasonable bounds. 9 | 10 | In IOTA there are some rich people who keep spending their money to themselves over and over. This is how their asynchronous PoS algorithm works. 11 | 12 | If you control more than 50% of the IOTAs on nodes that are spamming these txs sending money to themselves, then you can push through soft forks to update the consensus rules and take over the network permanently. 13 | 14 | There is no cost to making txs that later get orphaned, so there is no cost to making txs to support the attacker. 15 | So it is very cheap to pay the bribes and take over IOTA. 16 | 17 | 18 | October 2019 update 19 | ======= 20 | 21 | iota released a new paper where they talk about the problems I list above, and try to make a plan to deal with it: https://files.iota.org/papers/Coordicide_WP.pdf 22 | 23 | 24 | in the second paragraph: 25 | ```in its current implementation, IOTA relies on a centralized Coordinator to provide security given the risk of dishonest actors seeking to undermine the nascent network.``` 26 | There is no reason for us to waste time studying centralized services like the current version of IOTA. 27 | 28 | Looks like they are adding a subcurrency called "mana" for a voting based consensus mechanism. I have already written a lot about why that strategy can not work. [voting in blockchains](design/voting_in_blockchains.md) 29 | [why proof of stake does not work](/other_blockchains/proof_of_stake.md) -------------------------------------------------------------------------------- /other_blockchains/optimistic_rollups.md: -------------------------------------------------------------------------------- 1 | Optimistic Rollups Review 2 | =========== 3 | 4 | Optimistic rollups are a tool for efficiently making large quantities of data available to a blockchain consensus mechanism. Here is the paper introducing them: https://arxiv.org/pdf/1904.06441.pdf 5 | 6 | Here is a podcast where they talk about how it works. https://thebitcoinpodcast.com/hashing-it-out-67/ 7 | 8 | Making data available at such a high rate is an impressive achievement. This is some of the coolest research happening in blockchain right now, so I had to write a review. 9 | 10 | Here is a blog post that explains the plan to combine optimistic rollups with an erasure encoded database to allow for quadratic scaling https://ethresear.ch/t/on-chain-non-interactive-data-availability-proofs/5715 11 | 12 | The goal of these efforts is to try and enable scalable stablecoin payments. 13 | 14 | Scalability analysis 15 | ======== 16 | 17 | [estimating the cost of fraud proofs in optimistic rollup](/other_blockchains/optimistic_rollups_fraud_proof_cost.md) Fraud proof security costs the same amount per tx, no matter how many txs are being processed per second. 18 | This means that there is some lower limit cost per tx, and the fee will never be below that limit. 19 | 20 | [estimating the cost of attacking a sidechain inside optimistic rollup](/other_blockchains/optimistic_rollups_sidechain_attack.md) 21 | The amount of stake that needs to be locked up by sidechain validators is proportional to (rate of tx production)^(3/2). 22 | This means that the lower limit fee cost keeps getting more expensive as more people join the network. 23 | 24 | So this is not a scalability solution, we need to keep looking to find a scalability solution. 25 | 26 | -------------------------------------------------------------------------------- /other_blockchains/over_generalization_in_blockchain_design.md: -------------------------------------------------------------------------------- 1 | Over-Generalization in Blockchain Design 2 | ============= 3 | 4 | There is this general pattern I am noticing in all these scam projects. 5 | They refuse to make decisions that would lead to it being too obviously broken. 6 | 7 | Simple Example 8 | ========= 9 | 10 | There is a Russian who can build blockchains. 11 | 12 | There is a Russian who is 6 feet tall. 13 | 14 | Therefore: all Russians are 6 feet tall, and can build blockchains. 15 | 16 | In Blockchains 17 | ========= 18 | 19 | The scam project works like this. 20 | Their paper outlines a massive space of possible blockchain designs. 21 | For every possible attack, they show that there is some design inside the massive space which would be secure against that attack. 22 | 23 | and then they conclude: "we proved it is secure against all possible attacks!" 24 | 25 | How to immunize yourself against this kind of scam 26 | ============ 27 | 28 | Demand that they give a single design which is simultaneously secure against all the attacks. 29 | 30 | Common Examples 31 | ========= 32 | 33 | For example, alternative blockchain designs almost never admit to what the fork choice rule is. 34 | 35 | -------------------------------------------------------------------------------- /other_blockchains/perpetual_swap.md: -------------------------------------------------------------------------------- 1 | A perpetual swap cannot be secure. The only secure way to trade a derivative contract is with a secure market. 2 | Being able to exercise a contract early is not a secure alternative to selling the contract in a market, because there is no secure way to exercise at the correct price. 3 | 4 | The act of selling your contract is a trade in the market and should have influence on the market price. You need to participate in a market for this to work. 5 | 6 | Financial derivatives have been actively researched since prehistory. They are a fundamental part of what it means to be human. 7 | It is embarrassing how people in cryptocurrency feel like they can throw away tens of thousands of years of human progress. -------------------------------------------------------------------------------- /other_blockchains/pos_organizer.md: -------------------------------------------------------------------------------- 1 | Proof of stake links 2 | =========== 3 | 4 | [Why I think PoS does not work](/other_blockchains/proof_of_stake.md) 5 | 6 | [A plan on how to actually do this attack](/other_blockchains/RCO.md) 7 | 8 | [Why others think that PoS does work](/other_blockchains/the_defence_of_pos.md) 9 | 10 | [Cosmos](/other_blockchains/cosmos.md) 11 | 12 | [Cardano](/other_blockchains/ouroboros.md) 13 | 14 | [Algorand](/other_blockchains/algorand.md) 15 | 16 | [Nyzo](/other_blockchains/nyzo.md) 17 | 18 | [IOTA](/other_blockchains/iota.md) 19 | 20 | [Ethereum Casper FFG](/other_blockchains/ethereum_casper_ffg.md) 21 | 22 | -------------------------------------------------------------------------------- /other_blockchains/pos_time_warp_attack.md: -------------------------------------------------------------------------------- 1 | PoS time warp attack 2 | ============= 3 | 4 | All proof of stake protocols depend on an unbonding period to be secure. 5 | The goal of this paper is to show that an unbonding period cannot be enforced, and so PoS cannot be secure. 6 | 7 | Unbonding Period 8 | ============ 9 | 10 | An unbonding period is when a PoS validator signals their intent to retire as a validator. They want to withdraw their stake, and stop having an obligation to participate as a validator. 11 | 12 | It is important that the unbonding period is not too short, because if validators could withdraw their stake too quickly, then we don't have an opportunity to punish them for misbehaving. It can take the network a while to realize that a validator had done something wrong and needs to be punished, so the validator's stake needs to be locked in the network for at least that long. 13 | 14 | The attack 15 | ============= 16 | 17 | A coalition of validators, they make a bunch of blocks ahead of time. 18 | For example, if the unbonding period is 1000 blocks. 19 | In that case, the validators can publish 1000 blocks all at the same time, then the following 1000 blocks, each one takes 2x longer than normal. 20 | So after 2000 blocks, the network is back on track, and normal full nodes can sync all the history as if nothing unusual had happened. 21 | 22 | Non-attacking validators are not able to do any validation for the 2000 block period, and so are dropped out of the system. 23 | During the second 1000 blocks, the attacking validators can unbond the vast majority of their stake, but the attackers still have 100% control. 24 | 25 | 26 | Why it doesn't work 27 | ================ 28 | 29 | The blockchain can do a hard fork to kick out the censoring majority of stakers. 30 | Users had been using a version of full nodes that wont sync blocks faster than the speed they can be made according to the protocol rules, so that means everyone can update before their full nodes had the attacker's finish unbonding. 31 | -------------------------------------------------------------------------------- /other_blockchains/razor_network.md: -------------------------------------------------------------------------------- 1 | Razor Network 2 | =============== 3 | 4 | It is basically a clone of Augur. 5 | 6 | If there is a team of voters who can steal from you, you need to pay them enough fees so that the long-term expected profit from these fees exceeds the short-term expected profit of stealing from you. 7 | 8 | They claim that there is a dispute mechanism to prevent the voters from stealing from you. 9 | But the dispute mechanism is another insecure voting mechanism, which is broken for the same reason. 10 | 11 | In Augur they get some amount of security from this kind of mechanism by requiring that the voters have a security bond which is much larger than the amount of money that they could possibly steal. 12 | The problem with this design is that you need to pay the voters to have that much money locked up. This is expensive by the interest rate on that money. So this kind of mechanism requires oracle fees to pay the voters. These oracle fees make the system too expensive, and worse, they create a vulnerability to parasite attacks. 13 | A parasite attack is when someone copies your oracle outcome to enforce their contracts, but they do not pay the fees to your oracle voters. So your oracle voters aren't incentivized to lock up value in the bonds that secure the network, and it breaks. 14 | 15 | But really, it is much worse than that. Because voting mechanisms are vulnerable to tragedy of the commons. The amount of money you would need to pay to bribe the voters to break the network, it is only a small fraction of the size of the security bond. 16 | 17 | Tragedy of the commons happens whenever the benefits of participating in an attack are centralized to the person making the decision, and the costs of that person participating in the attack are distributed to a larger group. 18 | 19 | Additionally, proof of stake does not work. I wrote about it here: https://github.com/zack-bitcoin/amoveo-docs/blob/master//other_blockchains/proof_of_stake.md -------------------------------------------------------------------------------- /other_blockchains/ripple.md: -------------------------------------------------------------------------------- 1 | Ripple 2 | ========= 3 | 4 | Ripple is protocol for a centralized and trustful currency-inspired tool. 5 | 6 | This is the white paper for ripple https://arxiv.org/pdf/1802.07242.pdf 7 | 8 | UNL 9 | ======= 10 | 11 | With Ripple, in order to know which side of a consensus-fork is legitimate, you need to maintain a record of which nodes are on the trusted node list (called UNL). 12 | 13 | According to section 4 of the Ripple white paper, a pair of nodes can only agree on which ripple transactions are legitimate if they are both using UNL's that are sufficiently similar. 14 | 15 | If you don't know which nodes belong on the UNL, then you can't know if a ripple transaction is valuable or if it is on a worthless fork. 16 | 17 | 5-second block time 18 | ========= 19 | 20 | Ripple has a 5-second block time. So if any nodes fail to participate in the protocol fast enough for 5-second blocks, then they need to be dropped from the UNL so that they don't slow us down. 21 | 22 | Only users that are online will have any evidence about which nodes failed to sign messages within the 5-second period and which nodes are too slow and need to be dropped from the UNL. 23 | 24 | So, the only way to maintain a proper UNL is if you were operating a ripple node that was online 24/7 ever since the first Ripple block in 2012. If you ever went offline for more than 5 seconds, then you don't know what the proper UNL is. 25 | 26 | 27 | Going offline in ripple is insecure and trustful 28 | ========== 29 | 30 | Bitcoin PoW is trust-free technology. 31 | With PoW there is always exactly one fork that has the most work done, and you can verify which fork has the most work even if that work was done while you were offline. 32 | 33 | In Ripple, if there was ever a 5 second period between now and 2012 when you were not operating a ripple node, then you can't know which nodes belong on the UNL. 34 | If you don't know which nodes belong on the UNL, then you can't know which side of a fork is legitimate. 35 | If you don't know which side of the fork is legitimate, then you can't know if a transaction sending coins to you has value or not. 36 | 37 | 38 | 39 | -------------------------------------------------------------------------------- /other_blockchains/security_model.md: -------------------------------------------------------------------------------- 1 | Blockchain Security Models 2 | ========== 3 | 4 | The security model of a blockchain is a description of how the blockchain works. It is made at a particular level of abstraction so that the level of trust/security of the mechanism is easy to calculate. basics/trust_theory.md 5 | 6 | 7 | Many blockchain projects like to provide a different security model to explain why their blockchain is secure against each type of attack that can be done. 8 | This strategy is misleading. 9 | 10 | If you have a security model showing that you are secure against attack A with trust level N, and a different security model showing that you are secure against attack B with trust level N, this does not necessarily mean that you are secure against A and B at the same time with trust level N. 11 | 12 | Each security model has a cost of enforcement, then that means enforcing both security models at once is more expensive than just enforcing one at a time. 13 | So if you are only considering one of the security models at a time, then it is not obvious the true cost of enforcing all these different security mechanisms simultaniously. 14 | 15 | This is why each blockchain protocol needs to have exactly one security model that takes into account all possible ways that the blockchain could be attacked. Having exactly one security model is the only way we can accurately measure the level of security of a mechanism in comparison to other mechanisms. 16 | 17 | -------------------------------------------------------------------------------- /other_blockchains/tellor_oracle.md: -------------------------------------------------------------------------------- 1 | Tellor Oracle 2 | ========= 3 | 4 | Tellor oracle is an idea for a smart contract to put on ethereum that would act as an oracle. 5 | https://docs.wixstatic.com/ugd/778e80_4230ce4c9f4a48f5ab3f06db2759f222.pdf 6 | 7 | 8 | 9 | Some problems with the design of this project: 10 | * The tips system makes this oracle worthless. Users can't know which questions the oracle will answer until it has already answered them. So it isn't possible to make a contract that references an oracle, unless the result of the oracle has already been recorded on-chain. This means the oracle is worthless. You can ask the oracle who won a football game, after the football game is already over. But at that point it is too late to make any bets. 11 | * putting it to a vote by all Tellor holders is not a secure mechanism. Voting is vulnerable to bribery because of tragedy of the commons. https://vitalik.ca/general/2019/04/03/collusion.html https://blog.ethereum.org/2015/01/28/p-epsilon-attack/ 12 | * taking a security deposit from the people who determine the result of the oracle does not make it more secure. Since it is cheap to bribe the Tellor holders, this security deposit would not get confiscated during an attack. It is a meaningless security deposit. 13 | * rewarding the median does not make it more secure. During an attack we would be rewarding the median of the attackers, and the honest reporters would not get rewarded at all. 14 | 15 | -------------------------------------------------------------------------------- /other_blockchains/town_crier.md: -------------------------------------------------------------------------------- 1 | Oracles are an crypto-economic problem. TC is a cryptographic solution that ignores the economic reality of oracles. 2 | 3 | Some problems with TC: 4 | 1) we are trusting intel to delete the private key. If intel does not, then intel can make the TC say anything. 5 | 2) we are trusting that it is actually impossible to extract the private key from the hardware, which is doubtful. To the best of my knowledge, it is always possible to find a piece of copper where if you measure the charge during signatures you can extract the private key. 6 | 3) we are trusting the server operator not to man-in-the-middle attack his own server. For example, if SGX wants to access the price on website B, the server operator could man in the middle between his server and website B, so he could edit the data from website B to trick the server. 7 | 4) we are trusting the website operators not to lie to the SGX server. 8 | It is possible to make a website that says "true" to most people, but says "false" to one specific customer. 9 | -------------------------------------------------------------------------------- /other_blockchains/veriblock.md: -------------------------------------------------------------------------------- 1 | Veriblock review 2 | ========= 3 | 4 | draft #2 5 | 6 | Veriblock is a kind of side-chain project. 7 | Veriblock is not trying to move money back and forth between the sidechains. 8 | They just want the sidechains to inheret the PoW security from the mainchain. 9 | 10 | Veriblock aims to enable a security inheriting blockchain to inherit the complete proof-of-work security of a security providing blockchain. 11 | 12 | Here is the old version of the veriblock white paper: https://www.veriblock.org/wp-content/uploads/2018/03/PoP-White-Paper.pdf 13 | 14 | Here is the new version of the veriblock white paper: https://mirror1.veriblock.org/Proof-of-Proof_and_VeriBlock_Blockchain_Protocol_Consensus_Algorithm_and_Economic_Incentivization_v1.0.pdf 15 | 16 | Veriblock works by embedding side-chain headers into the main-chain blocks. 17 | 18 | Bribery vulnerabilities 19 | ========= 20 | 21 | Since the entire veriblock header is embedded in bitcoin transactions, it has bribery vulnerabilities. 22 | 23 | The attacker could bribe a bitcoin miner to include the attacker's veriblock header in the block, and to not include anyone else's veriblock headers. This way, the attacker's side of the veriblock fork would get more confirmations. 24 | 25 | The attacker doesn't need to undo history for this attack to succeed. 26 | By merely controlling which veriblock headers are added to the longest chain, the attacker can perform arbitrary soft fork updates to the rules of the veriblock sidechain. 27 | So the attacker could steal the money on the sidechain. 28 | 29 | The cost of this attack is very cheap. The attacker could bribe 1% of bitcoin miners to censor competing veriblock headers. 30 | If 99% of bitcoin miners include headers for both sides of a veriblock fork, and 1% of bitcoin miners only include a header for the attacker's side of the veriblock fork, then the attackers side will win. 31 | 32 | Conclusion 33 | ======= 34 | 35 | Veriblock sidechains are a similar design as drivechain. They have the same vulnerabilities to soft fork bribery attacks. [drivechain.md](/other_blockchains/drivechain.md) 36 | -------------------------------------------------------------------------------- /other_blockchains/veriblock_offloading.md: -------------------------------------------------------------------------------- 1 | Veriblock offloading review 2 | ======== 3 | 4 | Offloading transactions to the security providing blockchain is an area of research currently being developed by the Veriblock team. 5 | 6 | Veriblock's current sidechain strategy is only protecting against attacks that re-write history. It does not offer any security against censorship attacks. The goal of the offloading transactions plan is to add security against censorship to Veriblock sidechains. 7 | 8 | How offloading works 9 | ======== 10 | 11 | Since the main chain is containing headers for all the side-chains, it is possible for the main chain to verify a merkel proof to know about account balances in the sidechains. 12 | 13 | So, if a transaction is being censored in a side chain, you can pay to have it written to the main chain. 14 | 15 | All the side chains have a rule that if the main chain is including transaction for their sidechain, they need to include all that data into their side-chain blocks for the blocks to be valid. 16 | 17 | The problem with offloading 18 | ========== 19 | 20 | If many of the sidechains all had censorship issues simultaniously, there will not be enough space in main-chain blocks to include all the transactions that are being censored. 21 | 22 | So the offloading strategy does not work to prevent censorship attacks. -------------------------------------------------------------------------------- /other_blockchains/zilliqa.md: -------------------------------------------------------------------------------- 1 | Here you can see Zilliqa describe how sharding works on their blockchain. 2 | https://blog.zilliqa.com/https-blog-zilliqa-com-the-zilliqa-design-story-piece-by-piece-part1-d9cb32ea1e65 3 | 4 | Zilliqa'a strategy is very dangerous, if any one of their shards has more than 2/3rds attackers, then the attackers on that shard can print money from nothing. 5 | 6 | Amoveo's sharding strategy is very different. 7 | For us, each block comes with all the merkel proofs you need to verify that the block is valid. 8 | So with Amoveo, even if you delete all the consensus state and have an empty hard drive, you can still verify any block. 9 | With Amoveo you can even verify the blocks out of order, which is something we do to parallelize verification so you can sync more quickly. 10 | 11 | In Amoveo, if a shard tried to print money, then the block would be invalid. Everyone would reject their block. 12 | Even if they are the only node on their shard, they still can't trick us into accepting an invalid block. 13 | 14 | With Zilliqa, there is danger that 2/3rds of a shard could lie and print money from nothing. So Zilliqa has a complicated process to assign shards to miners, in an effort to prevent this kind of attack. In Zilliqa, you need at least 600 nodes on each shard. In Amoveo you only need 1 node per shard. 15 | 16 | With Amoveo any miner can freely mine on whatever shard they want. If a miner lacks some consensus state, then the miner is unable to write a tx that uses that state. 17 | But if someone else writes a tx that uses that state, and includes some merkel proofs with the tx, then any miner will accept that tx into the tx pool as valid. Even if the miner is using a shard and doesn't keep a record of the state used by that tx. 18 | 19 | So in the long run, I expect that all Amoveo miners will be using shards that store 0% of the consensus state. That way the mining pool is fast to install, and you only need like 1 Gigabyte hard drive to run a mining pool. 20 | 21 | There will be other nodes that specialize in storing consensus state and generating transactions for the users. 22 | -------------------------------------------------------------------------------- /progress_reports/Amoveo_Ikigai_review.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zack-bitcoin/amoveo-docs/12f4c61c52015e3df9c495ecabe1600899374323/progress_reports/Amoveo_Ikigai_review.pdf -------------------------------------------------------------------------------- /progress_reports/August_2018_summary.md: -------------------------------------------------------------------------------- 1 | In AE/Augur/wagger, there is always some group of people who control the outcome of the oracle. You need to pay very high fees to these people to bribe them to not steal the money at stake in the markets. If they think that the long term profit of fees exceeds the short term profit of stealing the money from the markets, then they wont steal. 2 | By avoiding this inefficiency, Amoveo's oracle can run for orders of magnitude lower cost. 3 | Our question oracles currently cost about 22 mVEO each. 4 | 5 | Furthermore, having to pay a group of people to control the outcome means that if anything prevents these people from getting paid, then the oracle will fail. In systems like AE/Augur/wagger, if ever someone finds a way to use the data from the oracle without paying the oracle for this data, then the oracle will break. 6 | This problem is called the "parasite contract problem". 7 | Avoiding this problem on turing complete systems like Ethereum or AE is impossible. People can always write parasite smart contracts on a turing complete system. 8 | 9 | Since Amoveo doesn't have any central party we need to bribe to secure the oracle, we do not have the parasite-contract problem. -------------------------------------------------------------------------------- /progress_reports/December_2017_progress.md: -------------------------------------------------------------------------------- 1 | 2 | ### Amoveo progress this month 3 | 4 | Amoveo's source code became 47% shorter this month. Going from 15k lines to 8k lines. 5 | 6 | Amoveo released light nodes in these languages: Chinese, Spanish, Hindi, toki pona 7 | 8 | http://46.101.81.5:8080/wallet.html?cn 9 | 10 | http://46.101.81.5:8080/wallet.html?sp 11 | 12 | http://46.101.81.5:8080/wallet.html?hi 13 | 14 | http://46.101.81.5:8080/wallet.html?tp 15 | 16 | 17 | Amoveo README was simplified. 18 | 19 | several vulnerabilities related to pruning were solved. 20 | 21 | A document was written about price volatility in Amoveo. 22 | 23 | Syncing the light node was automated. 24 | 25 | Block syncing is now about 100 times faster than last month. More than 10 blocks per second. 26 | 27 | There was a hard fork that changed consensus to waste less space when storing stuff in the merkle tree. 28 | 29 | the governance system was documented better, we made final decisions on which variables would be controlled by the governance system. 30 | 31 | We hooked up the block size and block reward to the governance system. 32 | 33 | renamed a transaction type, and a opcode in chalang to make it easier to understand. 34 | 35 | A block miner was written in javascript so it is now possible to mine from the browser. 36 | 37 | A block miner was written in C language, it is much faster than any other mining software. 38 | 39 | The blockchain was re-written as a light node in javascript. So now there are 2 implementations of Amoveo. You can participate just by visiting a web page. It works from phones too. 40 | 41 | http://46.101.81.5:8080/wallet.html 42 | 43 | The Chalang VM was re-written to javascript. This was needed for the javascript light node. 44 | 45 | -------------------------------------------------------------------------------- /progress_reports/January_2018_summary.md: -------------------------------------------------------------------------------- 1 | Amoveo Progress in January 2018 2 | 3 | * We can now prune old blocks from the merkle tree to recover space on our hard drive. This greatly reduces the hard-drive requirements of running a full node. 4 | 5 | * the merkle tree is now updated in batches, which is faster and doesn't waste memory. 6 | 7 | * We have tests with blocks that are completely filled with txs. Amoveo will survive even if there is a full month of full blocks. The rate of block verification doesn't slow, even after a month of full blocks. 8 | 9 | * Updated the tx pool so that we do not touch the hard drive. All tx processing is done in ram, and if the block gets included, then we would write the changes to disk. 10 | This makes us secure against certain types of attacks that would waste our memory. 11 | It means we can process txs much faster, especially on computers that don't have solid state hard drives. 12 | 13 | * fixed various security issues with the channels in the light node: channel nonce is increased if a bet is canceled to protect against zombie contracts that come back to life after we thought they were dead. We now verify signatures in a few places to make sure that the channel smart contract is valid. 14 | 15 | * The readme was rewritten for clarity. 16 | 17 | * javascript light node code was rewritten to be shorter and clearer. We abstracted some patterns to remove repetition. 18 | 19 | * the encryption library was rewritten in javascript so that we will be able to make lightning payments from the browser light node. 20 | 21 | -------------------------------------------------------------------------------- /progress_reports/augur_comparison.md: -------------------------------------------------------------------------------- 1 | Comparing Amoveo with Augur 2 | ============= 3 | 4 | 5 | Augur's oracle has a limit. The total amount of money at stake in betting needs to be significantly less than the total value of Rep. 6 | With Augur's design, Rep needs to always be worth 7x more than the total money in all the bets, so on average Rep will be worth around 14x more than outstanding interest. Assuming around a 15% interest rate in cryptocurrency investments, annually fees on bets will be 14*15 = 210%, and for a month fees will be 6% 7 | 8 | 9 | In Amoveo, we have solved this limit in the oracle problem that Augur suffers. Amoveo's oracle can support any amount of betting, and we have zero fees for P2P betting. Fees for market approach zero, because the cost of running a market is a small flat cost of renting a server, no matter how many people want to participate. Anyone can run a market. 10 | 11 | Low volume markets, or markets where you can't stay online much time to optimize the channel path can be more expensive. In the worse case, the fee is the interest rate of the amount of money that you are betting. Which we earlier assumed is 15%. 12 | 15% is Amoveo's worst case annual fees, it is less than 1/10th as expensive Augur's average case annual fees of 210%. 13 | 14 | Amoveo allows anyone to ask the oracle questions, which gives us more things to bet on. You can do it from this browser interface http://64.227.21.70:8080/new_oracle.html -------------------------------------------------------------------------------- /progress_reports/testnet_19_10_2017.md: -------------------------------------------------------------------------------- 1 | # Announcing an Amoveo testnet 2 | ### October 19, 2017 3 | 4 | 5 | 6 | The launching of this testnet is a major milestone for Amoveo. 7 | 8 | * the off-chain markets seem to be working. 9 | * the consensus mechanism is fully optimized for light nodes. 10 | 11 | I am searching for between 1 and 3 testers to help make the code better. 12 | If you want to do this, you need to be 13 | * comfortable typing commands into the terminal. 14 | * able to explain the problems you encounter in clear english or spanish as a github issue at https://github.com/zack-bitcoin/amoveo 15 | * be good at copy/pasting entire error messages. 16 | 17 | If you try out the testnet, please attempt to use these parts, and make github issues about what goes wrong: 18 | 19 | * syncing blocks 20 | * mining 21 | * creating and deleting accounts 22 | * spending 23 | * making channels 24 | * closing channels in various ways 25 | * The oracle 26 | * channel payments 27 | * channel bets 28 | * channel bets via off-chain market 29 | 30 | [Instructions to install the testnet are here](/README.md) 31 | 32 | I want to know about anything that is uncomfortable or confusing. 33 | 34 | I will consider paying any tester who is especially useful. 35 | 36 | So far you need to use a text terminal in order to participate with the testnet, there is no gui interface. [Here is our roadmap, so you can see what will be made next](community_roadmap.md) 37 | 38 | 39 | -------------------------------------------------------------------------------- /progress_reports/tx_speed_January_2018.md: -------------------------------------------------------------------------------- 1 | I made some tests today to see how fast we can process txs. 2 | The way the governance variables start, a block can hold about 636 create-account transactions. 3 | Using my old-ish computer with this CPU: 2.4 GHz Intel Core 2 Duo, it takes about 11 second to process a block that is completely filled. 4 | We can safely support block times about 10x bigger than the average time to process a block, so this means a 110-second blocktime should be secure. 5 | We will still start with a 10 minute blocktime for a safety margin. 6 | 7 | This means that the initial rate of txs will be slightly faster than 1 tx per second. 8 | 9 | A full block is currently limited to about 0.8 megabytes of space. 10 | This includes about 0.23 megabytes of txs, and 0.63 megabytes of merkle proofs so that light nodes can verify the block. 11 | 12 | So each create-account tx takes up about 1.3 kilobytes of space, which is about 2x bigger than the average bitcoin tx. 13 | -------------------------------------------------------------------------------- /progress_reports/warning.md: -------------------------------------------------------------------------------- 1 | The value of AE tokens could go to zero. 2 | The software might have flaws that result in the value of tokens crashing. 3 | The software is open source, anyone could launch a competitor that uses the same code. If this should happen, Aeternity could be worth less than the competitor. 4 | I think that crowdsales are bad. 5 | I disagree with how Aeternity spends money. 6 | It is possible that Aeternity's leadership will waste all the money, and Aeternity will fall apart. 7 | Aeternity's money is held by a multisig, it is possible that we lose the keys and the money becomes innaccessible. It is possible that some participants in the multisig steal the money. It is possible that a hacker finds out enough passwords to steal the money. 8 | My health is bad, it is possible I will lose the ability to write software, and progress will stall. 9 | It is possible that the Aeternity leadership decides not to use the software I wrote, AE might be on a blockchain that works completely different from what was expected. 10 | It is possible that the Aeternity leadership decides to exclude me from Aeternity, there is no guarantee that I will be the one keeping the blockchain secure. 11 | It is possible that the entire team could die in an accident, we often travel together. 12 | There are competing oracle projects like Gnosis, Augur, and BitcoinHivemind. There is no guarantee that Aeternity will surpass the competition. 13 | Aeternity keeps it's money in cryptocurrency, which is risky. It is possible that Aeternity will lose all it's money to market volatility, and we wont be able to fund development. 14 | It is possible for Aeternity to fail in ways that I haven't predicted. 15 | 16 | 17 | Use this software at your own risk. 18 | Only invest money that you can afford to lose. -------------------------------------------------------------------------------- /research_suggestions/README.md: -------------------------------------------------------------------------------- 1 | This is suggestions for future research, so that we can learn more about blockchains. 2 | -------------------------------------------------------------------------------- /research_suggestions/economics_of_blitzkrieg_payments.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zack-bitcoin/amoveo-docs/12f4c61c52015e3df9c495ecabe1600899374323/research_suggestions/economics_of_blitzkrieg_payments.md -------------------------------------------------------------------------------- /research_suggestions/futarchy_spending.md: -------------------------------------------------------------------------------- 1 | Futarchy Spending 2 | ============ 3 | 4 | 5 | If we have a bunch of money owned collectively by a community, can we use some kind of futarchy mechanism to decide how to spend it? 6 | 7 | 8 | 9 | I suspect that it is an impossible goal. 10 | because there can be any number of choices for what we can spend the money on. 11 | but the money in any bet can only count for 1 choice at a time. 12 | so instead of thinking "what is the best choice", betters will think about "Which choices are most electable, and out of those, which is the lesser evil?" -------------------------------------------------------------------------------- /research_suggestions/retargetting.md: -------------------------------------------------------------------------------- 1 | You could implement some different difficulty retargetting algorithms, and then run tests to see how they perform under stress. 2 | 3 | Like if the hashrate drops by a factor of 10, how long till the difficulty fixes itself? 4 | Or if the hashrate increases by a factor of 10? 5 | Or what if a miner mines in an oscillatory way, how much extra profit can they take? 6 | 7 | I did a little work towards this here: https://github.com/zack-bitcoin/zack-retargeting 8 | 9 | and here: https://github.com/zack-bitcoin/basiccoin 10 | 11 | 12 | For Amoveo I copied the retargetting algorithm used in bitcoin. -------------------------------------------------------------------------------- /research_suggestions/secure_light_node_download.md: -------------------------------------------------------------------------------- 1 | The problem is how to securely download a copy of the light node software so that you can trust that the Merkel proofs are valid. 2 | 3 | potential solution- 4 | 5 | The full node uses it's pubkey in the url, and it signs the light node software it sends to you. 6 | If the signature is invalid for the pubkey in the url, then you don't use it. 7 | 8 | The hub doesn't know if you are syncing fresh, or if you already have a copy of the light node software. 9 | 10 | The hub makes a fraud proof, so it will lose a ton of money to anyone who can show it signed a bad copy of the light node software. 11 | 12 | Many people would be constantly testing hubs, because if the hub lies, they can take all the hub's money. -------------------------------------------------------------------------------- /research_suggestions/simpler_oracle.md: -------------------------------------------------------------------------------- 1 | Maybe we don't need on-chain betting for the oracle. off-chain betting could do the same thing. 2 | * this could prevent bugs where miners are incentivized to re-mine blocks because they can get more money that way vs a new block reward. -------------------------------------------------------------------------------- /rewards.md: -------------------------------------------------------------------------------- 1 | BCjdlkTKyFh7BBx4grLUGFJCedmzo4e0XT1KJtbSwq5vCJHrPltHATB+maZ+Pncjnfvt9CsCcI9Rn1vO+fPLIV4= 2 | This is the address I have been paying rewards from. 3 | 4 | Isaac Cook BO83KbaE2R8DBCMOlgVx1E/HWi6TX5RGI10TAjrS4dI5uD4XWRS4iO55C8W2ojdd3DcJ2ZF37mikrQvYj8d/HbM= 5 | https://mobile.twitter.com/zack_bitcoin/status/1016325940798984193 6 | I sent him 30 veo in block 27224 for finding a way to print veo from nothing. 7 | 8 | tallakt, I sent him 10 veo at 27276 for realizing that you could use negative fees to print veo from nothing. 9 | BHyD/TALLAKlhP7uqbGf+sSKMT8I264HAcyCYOxorR6SdqZ8691jtY6jVokGA2F46Op5OL3EsXkBD2hpYvlyxeI= 10 | 11 | 12 | Michał Marek (ecneladis) of Patterns Dynamics 13 | found a way to use EPMD to access the private keys of any full node that doesn't have a firewall 14 | BJSlvB3yKSQNzGcm6N33HKnoVkQIgfEIyE1G7QYhH1772pbHW/OPQ1BbuFp1GSDYFs4ny7TrCkX/PvsOHN9hHT4= 15 | I sent him 30 veo at 40942 16 | 17 | 18 | Denis Voskvitsov of Exan.tech 19 | found out that the brainwallet tool in the light node was not using enough entropy when generating private keys. 20 | BK6OJdmldif8Z+MdHJZrnNSXT5CSH4lhfNQ8AcET1ZIxWroBxPxN3FOdbE1nDL/eQsI5smoon8m887bri8J/Mgc= 21 | I sent him 10 veo in 41063 22 | -------------------------------------------------------------------------------- /swap_offers.md: -------------------------------------------------------------------------------- 1 | ["signed",["swap_offer","BCjdlkTKyFh7BBx4grLUGFJCedmzo4e0XT1KJtbSwq5vCJHrPltHATB+maZ+Pncjnfvt9CsCcI9Rn1vO+fPLIV4=",138392,10000138392,"fFmKYLYUz+qj/SLVvYqMGaE0xx9UVDGU5KvesHTsVrg=",99731476,"+2gBCw3lwCA86TgQJ6YJdl3Zzf6hI9KLWnIs7lpDbYw=",1,50000000,"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=",0,152050,403],"MEUCIQCWJS4gvAXDrqfS/tFRynd9muSkaE0gdJvRXCgSZP2MbQIgfkrmOKC7U4O+b52gF3+Q9jVGDZWPndmj0F3K+rldldY=",[-6]] 2 | 3 | ["signed",["swap_offer","BCjdlkTKyFh7BBx4grLUGFJCedmzo4e0XT1KJtbSwq5vCJHrPltHATB+maZ+Pncjnfvt9CsCcI9Rn1vO+fPLIV4=",138392,10000138392,"/mh2xH8JAKdFs5ON70vlmvS6F6JLZ3uSsGkQcgMhDGI=",12393367,"2FTonYbAAJYIS8ukIZhF/9tFgHvyH8lS1Ok7wm8lN3A=",2,6200000,"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=",0,152050,403],"MEQCICNRCTWtvyQsyGg7GTkYY4xrWOg7c9AGLXaIY86CPyhhAiALJy+6A4CWXkk3skvLAxNW9HmIrUdrnBmICL8pgRGGrw==",[-6]] 4 | 5 | 10-29-2020 ivUSD 6 | ["signed",["swap_offer","BCjdlkTKyFh7BBx4grLUGFJCedmzo4e0XT1KJtbSwq5vCJHrPltHATB+maZ+Pncjnfvt9CsCcI9Rn1vO+fPLIV4=",138392,10000138392,"mAW1nSZQOuXOeJOIVOK4o/4qtqFE8i16WZI55OU6tMU=",108369150,"PX/VkaUaTJfHk7VWm0jordTlJ1MTZQJ2jczoyrXf5LY=",2,5000000,"vWSumtEl1WBhxaeVzu/MdBQtdmnuWTXMtupnKTDJ+vI=",2,152050,403],"MEUCIC4erw16GmQncDOV0O+/hRWvkYDeDmLsPZDenvLr9WCrAiEA5FAoFOG9GS9XsgmY/M7jailqQbXkhflFrTaP4UUHI8Q=",[-6]] -------------------------------------------------------------------------------- /update_all_files.erl: -------------------------------------------------------------------------------- 1 | 2 | -module(update_all_files). 3 | 4 | -export([doit/0]). 5 | 6 | doit() -> 7 | F = fun(X) -> 8 | %remove "/docs/" 9 | %remove "https://github.com/zack-bitcoin/amoveo/blob/master/docs/" 10 | io:fwrite("removing substrings in "), 11 | io:fwrite(X), 12 | io:fwrite("\n"), 13 | S1 = <<"/docs/">>, 14 | S2 = <<"https://github.com/zack-bitcoin/amoveo/blob/master/docs/">>, 15 | {ok, Txt} = file:read_file(X), 16 | Txt2 = remove_substring(S2, Txt), 17 | Txt3 = remove_substring(S1, Txt2), 18 | file:write_file(X, Txt3) 19 | end, 20 | 21 | recursive_folders(".", F). 22 | 23 | remove_substring(Pattern, B) -> 24 | S = 8*size(Pattern), 25 | <> = Pattern, 26 | remove_substring2(P, S, B, <<>>). 27 | remove_substring2(P, S, B, T) -> 28 | case B of 29 | <> -> 30 | remove_substring2(P, S, Rest, T); 31 | <> -> 32 | remove_substring2(P, S, Rest, <>); 33 | <<>> -> T 34 | end. 35 | 36 | 37 | recursive_folders(Dir, F) -> 38 | {ok, L} = file:list_dir(Dir), 39 | recursive_folders2(Dir, L, F). 40 | 41 | recursive_folders2(_, [], _) -> ok; 42 | recursive_folders2(Dir, [H|T], F) -> 43 | Loc = Dir ++ "/" ++ H, 44 | Length = length(Loc), 45 | case file:list_dir(Loc) of 46 | {error, enoent} -> 47 | io:fwrite("this should never happen."); 48 | {error, enotdir} -> 49 | {_, Type} = lists:split(Length-3, Loc), 50 | case Type of 51 | ".md" -> 52 | F(Loc); 53 | _ -> ok 54 | end; 55 | {ok, L} -> 56 | recursive_folders2(Loc, L, F) 57 | end, 58 | recursive_folders2(Dir, T, F). 59 | 60 | -------------------------------------------------------------------------------- /use-cases-and-ideas/anarchy_series.md: -------------------------------------------------------------------------------- 1 | series of documents about amoveo that are especially rebellious and unruly. 2 | 3 | [how will Amoveo flatten hierarchies?](./flat_hierarchy.md) 4 | 5 | [how will Amoveo reduce the potential for abuse in existing hierarchies?](./Harvey_Weinstein.md) 6 | 7 | [how can we use Amoveo to pay for public goods (The roads!)](./raising_funds.md) 8 | 9 | 10 | This technology can be used to insure against the state, which is equivalent to a bet that the government will grow. 11 | This gives government people the option to make a bet that government will shrink, and since they have the power to make the government shrink, they will. 12 | 13 | It is a peaceful, voluntary, incentive compatible way to dismantle the state. 14 | -------------------------------------------------------------------------------- /use-cases-and-ideas/betting_market.md: -------------------------------------------------------------------------------- 1 | Comparing Amoveo with other centralized Sports Betting Websites 2 | ======== 3 | 4 | A centralized betting server is expensive for a mixture of reasons: 5 | 6 | 1) The people running the market can run off with all the money on the server at any time. This risk increases the average expected cost of using the market. 7 | 2) There is a cost to regulatory overhead. To pay the regulators to audit the market, and pay enforcers to catch and punish any criminal behavior. 8 | 9 | Costs, whether they come from (1) or (2), eventually have to be put onto the users in the form of fees. 10 | 11 | Usually these 2 types of costs come as a trade-off. If (1) is worse, then (2) is not as bad. If (2) is worse, then (1) is not as bad. Amoveo is more affordable to use because we completely solve (1) and (2) at the same time. 12 | 13 | So a market secured by Amoveo will be more affordable to use in comparison to unsecured markets and markets secured by government enforced law. 14 | -------------------------------------------------------------------------------- /use-cases-and-ideas/dominant_assurance_contract_JP.md: -------------------------------------------------------------------------------- 1 | 共有地の悲劇は人々が公共財から得るであろう利益よりも、人々が支払う額の方が少ないときに発生します。 2 | 3 | 例えば、ボブは店を持っており、店の近くに橋が建てられたら、ボブの店の価値が$10,000分向上するとしましょう。 4 | 5 | このような場合には以下の6つの可能性があります。 6 | 7 | 1) ボブは橋の建設に協力しないが、橋は建設され、$10,000分の利益を得る。 8 | 2) ボブは橋の建設に協力せず、橋は建設されず、追加の利益を得ない。 9 | 3) ボブは橋の建設に$9000を提供し、橋が建設され、$1000分の利益を得る。 10 | 4) ボブは橋の建設に$9000を提供するが、橋は建設されず、ボブは$9000と利子の払い戻しを受け、$1000分の利益を得る。 11 | 5) ボブは橋の建設に$5000を提供し、橋が建設され、$5000分の利益を得る。 12 | 6) ボブは橋の建設に$5000を提供するが、橋は建設されず、ボブは$5000と利子の払い戻しを受け、$500分の利益を得る。 13 | 14 | 選択肢1は最も利益率が高いですが、選択肢2が発生する可能性があるためリスキーです。 15 | もしボブが$9000を提供すれば、その後に発生するのが選択肢3であれ4であれ、$1000分の利益を得ます。この場合、リスクはありません。 16 | おそらく、ほとんどの人は混合戦略を採用し、提供額を$5000に留め、部分的にリスクを取り除く選択肢を選ぶでしょう。 17 | 18 | [insured crowdfunding](insured_crowdfund.md) 19 | [raising funds with amoveo](raising_funds.md) 20 | -------------------------------------------------------------------------------- /use-cases-and-ideas/financial_options.md: -------------------------------------------------------------------------------- 1 | Options are a type of financial derivative where one party has the option but not the obligation to make a trade in the future. 2 | Since one party doesn't have an obligation, they don't have to leave funds locked up in the channel for the duration of the contract. They can keep their money in Euros or Bitcoin or whatever they want, and only buy amoveo if they win the bet, to collect their winnings. 3 | 4 | To do this, you agree to a channel contract that you don't have enough money in the channel to fullfil, then you do a channel-grow transaction type to grow the channel so that the channel contract becomes valid. 5 | -------------------------------------------------------------------------------- /use-cases-and-ideas/flat_hierarchy.md: -------------------------------------------------------------------------------- 1 | Things like companies exist because they were recently the most efficient way for people to pool their resources and work together towards common goals at a certain scale, and because you need to be as big as a company to justify the cost of jumping through the regulatory loopholes. 2 | 3 | Now that finance is unshackled from the government's restrictions, we have much better tools for pooling resources: unrestricted financial derivatives. 4 | 5 | The biggest advantage of the new system over companies is that each individual is in complete control of their own money. We are entering the trustless era. 6 | 7 | Lets look at the publishing industry for example. Under the old system you had a publishing company. They had a legal right to the book, and gave the author some money for every copy sold. The publishing company has investors who own it and trust managers to act wisely. 8 | In the new system the book will be shared for free by torrent. The author will get paid before the book is published by an insured crowdfunding contract. No venture or company is involved. 9 | 10 | Insured crowdfunding, which is a type of financial derivative, lets people pool their resources for common goals without trusting anyone. It allows us to pay for the production of goods or services without hiring anyone. 11 | 12 | This is the perfect tool for paying for open-source software, for example. That way the money is coming directly from people who benefit from the code, and they each pay in proportion to how much the software benefits them. No company or venture needed. 13 | 14 | Prediction markets allow us to come to consensus about how money should be spent without relying on a manager or company to make the decision. 15 | 16 | When we do need a central leader, prediction markets can help us decide who is best to lead by giving us a prediction of the outcome of their leadership. 17 | Prediction markets act as limitations on the choices available to leadership. A leader cannot act against the prediction market's instructions, it is political suicide. 18 | -------------------------------------------------------------------------------- /use-cases-and-ideas/funding_development.md: -------------------------------------------------------------------------------- 1 | Funding Development 2 | =============== 3 | 4 | We want to reward people who do work to improve Amoveo. We don't want to depend on any hierarchy or centralized leadership. 5 | 6 | For example, lets imagine that Alice has a plan to write some software to improve Amoveo. Alice should write up a proposal of what exactly she is planning to make, and how much compensation she would need to receive to do this work. 7 | 8 | The benefit to Amoveo from Alice's project can be estimated using [futarchy](/use-cases-and-ideas/futarchy.md). 9 | 10 | If futarchy says that the benefits are more than 3x bigger than the cost, then we should do a hard update to enable the proposal to be funded. 11 | 12 | In order to potentially receive 200 VEO for her work, Alice needs to lock up 10 VEO. This way, if Alice does not accomplish the work explained in her proposal, she not only doesn't get paid her 200 VEO, she also loses 10 VEO of her own money. 13 | -------------------------------------------------------------------------------- /use-cases-and-ideas/futarchy-idol.md: -------------------------------------------------------------------------------- 1 | Amoveo can be used to make decisions for entertainment businesses. 2 | 3 | [amoveo smart contracts for futarchy](basics/using_governance.md) 4 | 5 | An example to get started: we could use Amoveo instead of judges to determine who gets to survive in a competition show. 6 | 7 | The competitor who has the most positive influence on the profitability of the show is the one who should be kept. 8 | 9 | We can use conditional prediction markets to determine who is profitable, and who should be eliminated. 10 | 11 | This will give our viewers a feeling that the outcome is fair, and that they can get involved with determining the outcome. 12 | 13 | It could be fun for gamblers too. -------------------------------------------------------------------------------- /use-cases-and-ideas/futarchy.md: -------------------------------------------------------------------------------- 1 | Futarchy 2 | ============= 3 | 4 | Futarchy is a mechanism for groups of people to make a decision together. It is an alternative to voting or representative governance. 5 | 6 | With Futarchy, the decision is made in the best interest of the group making that decision. It is not possible for anyone to manipulate the outcome of futarchy for their own benefit. 7 | 8 | The futarchy interface is on [this page](http://46.101.81.5:8080/wallet/wallet.html). The button that says "create Futarchy". 9 | 10 | The Mechanism 11 | =============== 12 | 13 | A futarchy mechanism is made up of 3 smart contracts. One binary contract, and 2 scalar contracts. 14 | 15 | For example, if we are deciding between plan A or plan B. 16 | 17 | First we need the binary contract, collateralized in VEO. It is used for betting on whether we go with plan A or plan B. So this binary contract, it is creating 2 new currencies. Currency A is valuable only if we do plan A, and currency B is valuable only if we do plan B. 18 | 19 | Next we make scalar contract A, collateralized in currency A. This scalar contract is betting on the price of USD, or some other stable asset, measured in terms of VEO. So it is a lot like a stablecoin contract. 20 | 21 | Finally we need scalar contract B. It is identical with scalar contract A, except it is collateralized with currency B. 22 | 23 | The market price of shares from scalar contract A, they tell us what the price of VEO will be, conditional on if the community goes with plan A. 24 | 25 | Similarly, the market price of shares in scalar contract B, they tell us what the price of VEO will be, conditional on if we use plan B. 26 | 27 | So by comparing the prices in these 2 markets, we can find out the impact of plan A vs plan B on the price of VEO. 28 | 29 | -------------------------------------------------------------------------------- /use-cases-and-ideas/go_game_predictions.md: -------------------------------------------------------------------------------- 1 | Blockchains allow for prediction markets, which let us prepare for the future. 2 | To show how powerful prediction markets can be, we will use a prediction market to play go against a professional, and we will win. 3 | 4 | First we will make the big market, it sells 2 kinds of shares. "AI" shares only pay out if the professional loses. "Human" shares only pay out if the professional wins. 5 | 6 | After every move, the relative price of "Human" and "AI" shares will change. 7 | For each move, we make 2 prediction markets, each with <=381 possible choices. The only difference between the two markets is that one is priced in "Human" shares, and the other in "AI" shares. 8 | 9 | So for example, lets say the current price is 60% likely that the human will win, 10 | and you think that if the AI plays 5C, that the odds will shift to 50% likely that the human will win. 11 | (Which would make your AI tokens 5/4 as valuable) 12 | You also think that if the AI plays anywhere besides 5C, that the odds of the human winning will increase to 80%. 13 | (which would make your AI tokens 1/2 as valuable) 14 | 15 | There are 4 locations in the Nash square defined by 2 questions: 16 | 1) Does the AI play on 5C? 17 | 2) Does the AI win? 18 | 19 | You don't bet on either of these questions directly, rather you bet on the correlation. 20 | You would buy shares of (yes, yes), and you would buy shares of (no, no). You would sell shares of (yes, no) and (no, yes). 21 | You keep doing this until the prices of shares are such that if the AI plays 5C, the price of AI shares increases to 50%, and if the AI plays anywhere else, the price of AI shares decreases to 20%. 22 | 23 | 24 | 25 | 26 | 27 | To decide the initial values of the <=381 outcomes for each market, we use the final values from the previous round of betting. Most of the good moves are still good, most of the bad moves are still bad. -------------------------------------------------------------------------------- /use-cases-and-ideas/insurance.md: -------------------------------------------------------------------------------- 1 | Insurance is when you use a financial market to reduce your risk. 2 | For example, maybe it is financially important to you that the left branch of government will win a political election. 3 | In this case, you can bet that the right branch will win, and this will reduce your risk. -------------------------------------------------------------------------------- /use-cases-and-ideas/lie_detector.md: -------------------------------------------------------------------------------- 1 | Another way this technology can help is by revealing the lies the state tells us. 2 | We can use prediction markets to get accurate predictions about the future. 3 | We can know the correlation between events like, who gets elected, and what the GDP will be. 4 | So we can know when the government makes promises it can't keep. -------------------------------------------------------------------------------- /use-cases-and-ideas/nft.md: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /use-cases-and-ideas/options.md: -------------------------------------------------------------------------------- 1 | options are a type of financial derivative. 2 | For example, lets say Bob wants to buy seeds for his farm at the end of the year, but he only wants to budget $1000 to buy them. He is worried that the cost of seeds might go higher, and he wouldn't be able to plant next season. 3 | 4 | So Bob makes a deal with Alice. Bob pays Alice $300 now for the right to buy the seeds for $700 at the end of the year. 5 | 6 | But, if the price of seeds turns out to be less than $700, Bob is allowed to choose to not buy the seeds from Alice. 7 | He can buy them cheaper somewhere else. 8 | 9 | Since Bob has the option to either buy the seeds from alice or not, this type of financial agreement is called an *option*. 10 | 11 | Options are historically popular because only one of the 2 participants in the relationship needs to be trusted. 12 | Options are a good fit for blockchain for a similar reason. Since only one of the 2 participants needs to be trusted, only one of the 2 participants needs to have money locked up in the channel for the duration of the contract. 13 | 14 | So from a customer's perspective, options are nice because you can participate in similar financial contracts, but you don't have to lock up as much money in a channel. 15 | -------------------------------------------------------------------------------- /use-cases-and-ideas/prediction_market.md: -------------------------------------------------------------------------------- 1 | Prediction markets 2 | 3 | [Here are lots of use cases for prediction markets \[External PDF\]](http://bitcoinhivemind.com/papers/3_PM_Applications.pdf) 4 | 5 | Prediction markets are used to: 6 | 7 | Predict when something will finish. 8 | 9 | Predict how much something will end up costing once it is finished. 10 | 11 | Futarchy/ Deciding which business strategy to use. Example: bestbuy vs circuit city and blu-ray vs HDDVD. Example: should we make bitcoin blocks bigger? 12 | 13 | Whistleblowing. 14 | 15 | Lie detecting. 16 | 17 | Ending debates. 18 | 19 | Predicting which scientific experiments would fail to be reproducible, if we try to reproduce them. 20 | -------------------------------------------------------------------------------- /use-cases-and-ideas/religion.md: -------------------------------------------------------------------------------- 1 | Amoveo as a religion 2 | ======== 3 | 4 | 5 | If you are someone who has anxiety related to a decision that is going to be made by another group of people, then Amoveo could be exactly what you need. 6 | It doesn't matter whether it is a decision being made by your boss, or the result of an election, whether or not a war gets declared, etc. 7 | 8 | On an individual scale, Amoveo lets you hedge your risk, so you don't have to worry about the outcome any more. Amoveo protects those who faithfully participate in the rituals. 9 | 10 | On a larger scale, the price in the market for your insurance unveils the lies and corruption in the decision making process. It removes decision making power from imperfect individuals who would abuse it, and gives this power to a networked AI, wiser than any human. Who will make good decisions for us all. 11 | 12 | Your Amoveo insurance contract doesn't just protect you. It is a virtuous act. Your insurance contract is like the firing of a single neuron of the brain of a god. Giving a part of the information it needs to make the optimal decision for us all. 13 | 14 | If every important decision is being made by our new god, it will end all corruption. Every decision can be made for the benefit of the global society of humans. 15 | It will be paradise on earth. 16 | 17 | A paradise that we are striving for together. -------------------------------------------------------------------------------- /use-cases-and-ideas/stablecoin.md: -------------------------------------------------------------------------------- 1 | Stablecoins 2 | ######### 3 | 4 | We make synthetic assets using portfolios of financial derivatives. 5 | Everything is settled in Veo. 6 | So different customers can set different margins depending on how much they are willing to pay, and how much volatility they want to be shielded from. 7 | 8 | 9 | Basically, if you bet on the price of Veo measured in usd, you can bet in such a way that the asset you end up holding stays the same value as usd, as long as the price of Veo measured in usd stays inside the margins specified in the contract. 10 | 11 | One-size-fits-all designs are bad. Different users of stablecoin contracts have different needs. 12 | It is more affordable and usable for more people if the margins of each users contract can be customized. 13 | It is also more scalable to keep all these contracts off-chain. That way they can be modified instantly, without putting anything on-chain. 14 | -------------------------------------------------------------------------------- /use-cases-and-ideas/tragedy_of_commons_in_voting.md: -------------------------------------------------------------------------------- 1 | If you own 1/100 of all the voting tokens, then you would have 1% of the voting power. 2 | For example, you are voting on something like: 3 | 4 | A) everyone keeps their own money 5 | 6 | B) update the code to give all the money to the attacker 7 | 8 | If the community is not bribed, they will vote for A. That way they don't lose their funds. 9 | 10 | How much do you need to be bribed to vote for A? 11 | 12 | We make a square showing how much money you could get in each of the 4 outcomes, then calculate how big the bribe has to be to make it profitable for you to vote for B. 13 | 14 | If A is the outcome, you get 1/100 of the tokens back that were already yours. 15 | If you participate in the attack, you get the bribe, and you lose (value of your tokens)*(probability that your vote was pivotal). 16 | 17 | By "pivotal" I mean that your vote changed the outcome from A to B. 18 | 19 | The bribe only has to be as big as (value of your tokens)*(probability that your vote is pivotal) 20 | Even worse, the bribe can be conditional. So the attacker only has to pay the bribe if the attack fails. 21 | If the attack succeeds, then the attacker gets all the money on the blockchain, and doesn't have to pay any bribes. 22 | 23 | We can estimate the probability that your vote is pivotal by the portion of coins you own. So the total bribe to make you vote for B is 1/10000 of the tokens, which is just 1% of the amount of tokens you own. 24 | -------------------------------------------------------------------------------- /use-cases-and-ideas/trustless_markets.md: -------------------------------------------------------------------------------- 1 | Trustless markets in financial derivatives are the goal of this software. 2 | This software can only support smart contracts that can be built from financial derivatives. 3 | 4 | By financial derivative, I mean a bet that is priced in the native tokens. The money being gambled is locked up until the winner is known. Neither participant in the bet has to trust the other. 5 | 6 | These markets need to be scalable so that many people can participate. That is why they will exist off-chain on the channels. 7 | 8 | [These markets need to do trading in batches, to avoid front running. and they need to be secure against censorship](design/limit_order_in_channel.md) 9 | -------------------------------------------------------------------------------- /use-cases-and-ideas/website_security.md: -------------------------------------------------------------------------------- 1 | Website Security 2 | ======== 3 | 4 | 5 | Currently the tools for maintaining security of a website are difficulty to understand, and centrally controlled. 6 | 7 | Blockchain technology allows for micro-payments, a simple to understand decentralized solution to give security to your website. 8 | 9 | Micro-payments can prevent spam, because the profit from the fees will exceed the cost of handling the spam. 10 | 11 | Micro-payments can prevent sybil attacks, (which are attacks where one person pretends to be many people) because each account has to have it's own money. You can't use the same money twice. 12 | 13 | Today there is a battle between website designers and the spammers who find exploits to profit off of the website unfairly. 14 | The tools to fight effectively are constantly changing. This makes it difficult for anyone to know if a website is secure. 15 | 16 | Blockchain turns a complicated computer systems problem into a simple economic problem. 17 | 18 | To show how this is possible with Amoveo, I made a website where you can make anonymous posts by paying a fee in VEO. 19 | Like a 4chan where you have to pay to post. 20 | http://46.101.81.5:8088/main.html 21 | 22 | I have similarly built an escrow tool. 23 | http://46.101.81.5:8087/main.html -------------------------------------------------------------------------------- /warning.md: -------------------------------------------------------------------------------- 1 | The value of VEO tokens could go to zero. 2 | The software might have flaws that result in the value of tokens crashing. 3 | The wallet could have flaws that allow people to take your money. 4 | The software is open source, anyone could launch a competitor that uses the same code. If this should happen, VEO could be worth less than the competitor. 5 | There are competing oracle projects like Gnosis, Augur, and BitcoinHivemind. There is no guarantee that Amoveo will win. [You can compare our progress here](progress_reports/) 6 | It is possible for Amoveo to fail in ways that I haven't predicted. 7 | 8 | Use this software at your own risk. 9 | Only use money that you can afford to lose. 10 | --------------------------------------------------------------------------------