These slides: slides.cuban.tech/skycoin.intro.html
Network: cubantech
Password: meet-ups
- Replicated state machines (a.k.a RSM)
- Infrastructure, management and admin tools
- Relation between RSM and Blockchain
- Execution rules and consensus
- General Theory of DApps
- Intro to Skycoin
Notes about Skycoin, Bitcoin, and Ethereum in-between
--
- Why Skycoin?
- Understanding Skycoin transactions
- Core values
- Five pillars of Skycoin
- Skycoin ecosystem
- What's next?
Answer here
- Go programming language
- Blockchain
- Distributed applications
- Asymetric cryptography and cryptocurrencies
- Accounting and economics
- Bitcoin, Ethereum, Skycoin
--
--
--
- Fault tolerance beyond single-node processors
- Replicas of a single server executed on separate processors
- Protocols for client interactions with replicas
- Physical and electrical isolation for independent server failures
--
- Let's assume deterministic state machine
- ... even if Turing complete is possible
- Deploy replicas of the software
- Receive client requests (i.e. inputs)
- Order the inputs
- Execute SM transition over and over
- Monitor replicas for differences in State or Output
| |
 |
 |
| go | C / C++ | go |
| Skycoin @ Github | Bitcoin @ Github | Ethereum @ Github |
| Ethers.io @ Github |
--
| |
 |
| bitcoind @ Debian | Blockstack apt repo |
--
- Containers and registries
- e.g. Skycoin, Lisk, Blockstack, ... @ Docker Hub
- CM tools (Ansible, Puppet, Chef, Habitat, ...)
--
- Deploy replicas of the software
- Receive client requests (i.e. inputs)
- Order the inputs
- Execute SM transition over and over
- Monitor replicas for differences in State or Output
- Multiple solutions
- e.g. Transactions
- All transactions/objects belong to a single public key
- Complicates design
- Compromises privacy
- Easily tracked and monitored account
--
Important meta-data (except coinbase transactions)
- Transaction (global) ID
- Version number (protocol evolution)
- Locktime
- Earliest time TX can be added to the block chain
- Time-locked transactions only valid in the future
- Cancellations
--
- Output(s) : Implicit array index
- Amount (satoshis)
- Pubkey script ( Unlock to spend )
- Input(s)
- Spent output (Transaction ID + Output index)
- Sequence number (related to locktime)
- Signature script (params to unlock Pubkey script)
Bitcoin is a public distributed ledger.
--
blocktrail.com
--
- ECDSA secp256k1 (elliptic) curve
- Deterministic public key (hash) generation
--
- Redeem script hash instead of public key hash
- Supports PubKey scripts opcodes
--
- Sender creates UTXO with PubKey script
- ... using the public key hash of the receiver
- Sender broadcasts transaction (P2P network)
- Miners add it to a block (... more details later ...)
- Wallet : UTXO amount as spendable balance
--
- Lookup transaction ID and index for UTXO
- Sender creates TX input and also add:
- Sequence number
- Signature & PubKey (script params)
--
- Lookup transaction ID and index for UTXO
- Sender creates TX input and also add:
- Sequence number
- Signature & PubKey (script params)
--
- Sender prepares UTXO for recipient (as before)
- Sender broadcasts transaction (P2P network)
- Miners add it to a block
- Script validation ! ( A-ha! )
- Wallet : Update balance
--
- Store UX objects as part of TX
- referenced by index
- Dust resource exhaustion attack
- Overcomplicated security & privacy
- e.g. generate new address for each TX
- Separate hash IDs for UX and TX
- UX objects independent of TX objects
- Simplifies design
- No scripting
--
- UX/TX simple directed acyclic bipartite graph
A very peculiar monster
--
;; QUESTION SECTION
;seed.bitcoin.sipa.be IN A
;; ANSWER SECTION
seed.bitcoin.sipa.be. 60 IN A 192.0.2.113
seed.bitcoin.sipa.be. 60 IN A 198.51.100.231
seed.bitcoin.sipa.be. 60 IN A 203.0.113.183
- Connect to port
8333(mainnet) or18333(testnet) - Followed by
addrmessages announcing addresses of peers
--
- Send
versionmessage- local version number, block, and current time
- Peer responds with its own
versionmessage - Send
getaddrand receiveaddrof new peers (discovery)
--
- Send
invmessage to a peer. - Wait for
getdatamessage - Send transaction data in
txmessage - Peer forwards transactions to other peers
- Full nodes keep track of unconfirmed transactions in memory pool
... to be continued ...
- No DNS during P2P discovery
- Deploy replicas of the software
- Receive client requests (i.e. inputs)
- Order the inputs
- Execute SM transition over and over
- Monitor replicas for differences in State or Output
- Mutiple solutions
- Blockchain ?
- Bitcoin transactions !
--
Causal ordering : Chain of ownership
- Deploy replicas of the software
- Receive client requests (i.e. inputs)
- Order the inputs
- Execute SM transition over and over
- Monitor replicas for differences in State or Output
- Execute inputs in the chosen order on each replica
- Public ledger
- Ordered and timestamped transactions
- Storage distributed over Bitcoin full nodes
- Protect against
- double spending
- modification of previous transaction records
--
--
- Version : 4 bytes
- Previous block header hash : 32 bytes
- Merkle root hash : 32 bytes
- Time : 4 bytes
- nBits : 4 bytes
- nonce : 4 bytes
--
blocktrail.com
--
Coinbase transaction comes first
- Metric
- Prove legitimate interest, irreversibility
- Make decisions about changes in a DApp
- Modifying past blocks harder than adding new ones
- Common examples
- Proof of work (PoW) : BTC
- Proof of stake (PoS)
- Proof of burn : SKY
- Proof of collaboration (PoC)
- Proof of space (PoSpace), replication** (PoR)
- Can be used in parallel
- e.g. PeerCoin relies on PoW + PoS
--
- Driver : Amount of computational work (CPU, GPU, NPU, ...) that contributed to the operation of the DApp.
- Resource intense (power, cooling, ...)
- The mechanism for establishing consensus through POW is commonly called mining.
Bitcoin uses that approach for its day-to-day operation.
--
- Driver : new coins according to number of coins (stake) you hold
- May be abused by those who hold enough coins.
- Usually combined with other proof
OmniLayer is based on the POS mechanism.
--
- Driver : allocation of non-trivial amounts of memory or storage needed to solve a challenge (memory-hard functions).
- Greener alternative to PoW
PoStorage is used in PermaCoin, SpaceMint, BurstCoin
--
- Collaboratively Validating Nodes (in short CVNs)
- Decide what node creates next block
- Approve CVN by digitally signing a piece of data containing winner's ID
- With required signatures gather TX and create new block
- No reward (new money) for block creation (small fee)
- Power consumption is low (CVNs on a Raspberry3)
FairCoin (fork of Bitcoin 0.12) implements PoC since July 18th 2017
Operating modes : SPV clients vs full node
- First run : Node only contains block 0
- Choose remote peer (a.k.a sync node)
- Download from block 1 to current tip of sync node's best block chain
- Blocks-first (up until version 0.9.3)
- Headers-first (from 0.10.0 onwards)
- Add new blocks to the block chain
- Make transation history hard to modify
- Strategies
- Solo mining
- Pooled mining
- Miner generates new blocks on his own
- Completely claims block reward and transaction fees
- Large payments
- Higher variance (longer time between them)
- Group of miners pool resources with other miners
- Find bocks more often at easier bits targets
- Proceeds shared amongst miners
- Correlated to relative hash power PoW
- Small payments
- Lower variance (i.e. shorter time between payments)
--
Minted coins : +1M BTC mined since Dec 2010. ZCASH since Apr 20th 2017
--
--
--
Minted coins : BTC
--
--
Minted coins : BTC
- 6.4 EHash/s , 80,704,290.84 PFLOPS
- 10,000 metric tonnes of hardware. Enough material to build another Eiffel tower.
--
Application specific integrated circuits, a.k.a. ASICs
--
... according to BitcoinEnergyConsumption.com
- Projected to be comparable to Denmark's in 2020
- Miner includes mined block in new
blockmessage - Miner sends message to its full nodes peers
since version 0.12.0
--
- Standard method
- Miner sends
invmessage to all (SPV and full node) peers- Includes inventory referring to the block
- BF peer ⇒
getdatarequesting the full block- Miner ⇒
blockmessage
- Miner ⇒
- HF peer ⇒
getheaders(few headers in best block chain)- Miner ⇒
headersmessage
- Miner ⇒
- SPV clients ⇒
getdatarequesting a Merkle block- Miner ⇒
merkleblockfollowed by sometxmessages
- Miner ⇒
since version 0.12.0
--
- Used if peer signals with
sendheadersduring handshake - Miner sends
headersmessage fror new block - HF peer ⇒ Partial validation and sends
getdata - Miner ⇒
blockormerkleblock
since version 0.12.0
- Issues with Proof of Work
- Proof of Stake: More Centralization Problems
- Technical improvements
- Security problems associated with other blockchain networks
- Decouple coin creation from the "mining" process
- Fast confirmation of transaction
- Inflationary policies
- The supply of Skycoin is fixed
--
- Control of the network => economic power
- Monopolization of mining
- Incentivized the purchase of hashing power
- Disproportionate control over the network.
- Bitcoin => SlushPool , Bitmain , BTCC
- revert and falsify transactions 51% attack
- Economic and environmental cost
--
- Transaction fees and inflation bleeding users dry.
- Over $50, and go to centralized mining pools.
- More expensive than international bank transfer
- Dust attack
- Resource exhaustion
- RAM and disk space
- Pruning spent UX is easy
- No mining, no fee (no mining, no fee ...)
- Proof of burn - CoinHours
--
- Holding Skycoin in a wallet
- ... automatically generates Coin Hours
- 1 SKY * 1 hour = 1 Coin Hour.
- Keep the Skywire network free of transaction fees.
- Virtual cat games can't skyrocket tx fees up 1600%
- Recent issue in the Ethereum network.
- Users never pay to access and use the network
--
- ... Coin Hours inflate dramatically
- Max = 100 million Coin Hour per hour
- Will be reached in decades
- ... no transactions ever took place on the network
- max Coin Hours would not exceed
uint64for centuries.
- max Coin Hours would not exceed
--
--
--
- Deploy replicas of the software
- Receive client requests (i.e. inputs)
- Order the inputs
- Execute SM transition over and over
- Monitor replicas for differences in State or Output
- Each replica generates output
- Non faulty replicas will always produce same output
- Faulty outputs filtered out
- Consensus
- Correct output sent back to client
--
- Simultaneous blocks mined, nodes choose winner
- Peers prefer forks with stronger PoW
- longest fork
- highest block height : distance to block 0
--
- When ?
--
- Eliminate (stale and orphan) blocks in low PoW forks
- Iterate over transactions in stale and orphan blocks
- discard it if TX belongs in another block of highest PoW fork
- move it back to TX mempool otherwise
- to be included in a future block by this miner
- (optionally?) broadcast to the P2P network
--
- When?
- Extend blockchain to prevent third-party 51% attack
- Upgraded consensus accept formerly rejected blocks
- Network partition
--
- Warning in
getnetworkinfoand run-alertnotifycommand if set.- +6 blocks PoW than best valid chain
- Repetition of block and TX with version numbers higher than expected consensus
- Coinbase transaction may be spent only after 100 blocks
- SPV clients may contact different full nodes
- discard chains with weaker PoW
Wallet software : Add up UTXO to determine balance
- Tolerance for F random independent failures
- memory errors, hard-drive crash, ...
- Requires
2F + 1replicas
- Failed replica can stop without generating outputs
- Only
F + 1replicas required - ... no existing systems achieve this limit
- Only
- Byzantine failures
- random, spurious faults ⇒
2F + 1 - malicious, intelligent attacks ⇒
3F + 1
- random, spurious faults ⇒
--
- Desktop or laptop (Windows, Mac OS X, or Linux)
- 125 GB of HDD space, 2 GB RAM
- Broadband Internet with upload ≥ 400 Kbps (50 KB/s)
- Unmetered connection, or high upload limits, respect upload limits
- +100 GB IBD
- ≈ 20 gigabytes download a month
- +200 GB upload a month
- +6 hours a day with full node running
- +8 connections and active sync peers
--
Most ordinary folks should NOT be running a full node. We need full nodes that are always on, have more than 8 connections (if you have only 8 then you are part of the problem, not part of the solution), and have a high-bandwidth connection to the Internet.
Gavin Andresen, Bitcoin Foundation's Chief Scientist, in Reddit post
- Important resource requirements
- Bandwidth (mainly upload)
- CPU, disk space (due to UXTO)
- Incentivates monopolization
- Big players have more resources
- More influence
- Based on distributed influence (web of trust)
- Node subscribes to a list of other nodes
- Network density determines node's influence.
- Prevents the development of centralized power.
- If some node fails to comply,
- ... its actions will be visible (public)
- Network can then sever connections with that node
- Immune to 51% attack (no mining)
- Transactions are significantly faster
- Occur in seconds.
- Decisions made through community consensus
- Less bandwidth wrt BTC (≈1:25)
- Official support for DIY devices (RPi, Orange Pi, ...)
- It must operate autonomously
- No entity controlling the majority of its tokens
- Data and records in a public, decentralized block chain.
e.g. Bitcoin apps are open-source, no entity controls Bitcoin and its records are open and public.
- The purpose of a token is to allow access to the DApp application.
- Must generate tokens according to a standard algorithm
- Possibly distribute tokens at the beginning of operation
- Tokens must be necessary for the use of the application
- Contribution from users rewarded by payment in the application's tokens.
e.g. Bitcoin generates bitcoins (tokens) with a predetermined algorithm that cannot be changed. Tokens are necessary for Bitcoin to function. Bitcoin miners are rewarded with bitcoins for their contributions in securing the Bitcoin network.
- Protocol may be adapted in response to
- proposed improvements
- market feedback
- Changes decided by majority consensus of its users.
e.g. All changes to Bitcoin must be approved by a majority consensus of its users through the proof-of-work mechanism.
- They have their own block chain.
Bitcoin, Litecoin and other alt-coins
- Use the block chain of a type I decentralized application.
- They are protocols
- Tokens that are necessary for their function.
OmniLayer (formerly Master Protocol) and Blockstack are examples of type II decentralized application.
--
- Embed additional data in DApp type I transactions
- Bitcoin OP_RETURN code
- Provably prune-able outputs
- Bitcoin miners will have the option to prune those data
Blockstack is a type II DApp
- They use the protocol of a type II decentralized application.
- They are protocols and have tokens that are necessary for their function.
Omni (formerly Mastercoin), and Blockstack apps are examples of type III decentralized applications.
- Publication of whitepaper
- Distribution of initial tokens
- Delegation of ownership
- Intentions and goals of the DApp
- Plans for token distribution
- Mechanism for establishing consensus
- Oversight of the DApp
- Management of developer bounties
- Technical description of the DApp
- Tokens are distributed to those who contribute most work to the operation of a DApp.
Taking Bitcoin as an example, bitcoins are distributed through a predetermined algorithm to the miners that verify transactions and maintain the Bitcoin block chain.
- Tokens are distributed to those who fund the initial development of the DApp.
Taking the Master Protocol as an example, Mastercoins were initially distributed to those who sent bitcoins to a given address at the rate of 100 Mastercoins per bitcoin sent. The bitcoins collected were then used to fund the development of applications that promoted the development of the Master Protocol.
- Tokens are generated using a predefined mechanism and are only available for the development of the DApp.
In addition to its fund-raising mechanism, the Master Protocol used the collaboration mechanism to fund its future development. Some Mastercoins are distributed via a community-driven bounty system based on the PoS mechanism.
- Next meetup : Skycoin projects explained !!!
- Telegram community : https://t.me/Skycoin
- Website: https://www.skycoin.net
- Development - https://github.com/skycoin
- News Channel: https://t.me/skycoinnews
- Twitter: https://twitter.com/Skycoinproject
- Support: https://t.me/skycoinsupport