Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Tim Swanson






Virtual token (e.g., a
bitcoin, a litecoin) having
at least one moneyness
attribute such as medium
of exchange
It...




Computer protocols that
facilitate, verify, execute and
enforce the terms of a contract
Current proto examples inclu...








They do not have a physical
enforcement arm the way
legal contracts do; they just
move the defined asset(s)
au...










Version 0.9 (80 byte
hash)
Bitcoin currently manages
one asset via one token
Dev team has limited
resources...








Colored Coins
Mastercoin
Counterparty (POB)
NXT (POS)
Invictus
Ethereum
*Open-Transaction
** Ripple
*** Peer...






Property whose
ownership is
controlled via a smart
contract, which may
or may not reside on
a cryptoledger
„Prop...




Not all gadgets, devices
or digital appliances are
technically smart
property
Ownership must be able
to transferred ...


TradeNet/MatterNet (DAO/DACP)
◦ Decentralized Autonomous X
◦ Anything with a proplet









Cars
Refrigerator...
• Manage, trade and exchange assets globally,
pseudonymously (perhaps anonymously) entirely
without going into fiat


TAM...







Near frictionless within the network
Entirely decentralized (e.g. DEX, Coinality,
BankToTheFuture)
Reputation...








70 year leases are often
40-50 year leases
4 million rural Chinese
evicted each year
Local gov‟t generate
70% ...










Low Bitcoin adoption (1-2 million users)
User interfaces and adoption
Consumer education
Legal uncertain...




Email: tswanson@gmail.com
Twitter: @ofnumbers
Ofnumbers.com




Contracts very often use multi-signature outputs in order to allocate value to a group of users
... typically, the p...








A common requirement when implementing contract protocols is to pass around and sign incomplete transactions....




The server receives the contract and decides to give all the money back to the client (how generous of it!). It
cons...
Upcoming SlideShare
Loading in …5
×

Primer to smart contracts, smart property, trustless asset management

9,497 views

Published on

Companion video at: http://youtu.be/VDRYZ122mXA

Tim Swanson discusses cryptocurrencies, cryptoledgers, smart contracts, smart property, decentralized autonomous organizations and cryptobarter. There are footnotes included as well. Filmed at Hacker Dojo on February 14, 2014 during Ethereum meetup. More info at: www.ofnumbers.com

Published in: Technology
  • Be the first to comment

Primer to smart contracts, smart property, trustless asset management

  1. 1. Tim Swanson
  2. 2.    Virtual token (e.g., a bitcoin, a litecoin) having at least one moneyness attribute such as medium of exchange It is transported and tracked on an encrypted, decentralized ledger called a cryptoledger (managed by a cryptoprotocol) Trustlessness
  3. 3.   Computer protocols that facilitate, verify, execute and enforce the terms of a contract Current proto examples include: ◦ Some digital financial instruments used on electronic securities exchanges ◦ Point-of-sale terminals ◦ Electronic Data Interchange (EDI)
  4. 4.     They do not have a physical enforcement arm the way legal contracts do; they just move the defined asset(s) automatically under certain conditions. Unforgeability (encrypted), confidentiality, and divisibility Reduce the fraud and enforcement costs of many commercial transactions Doable today (e.g. small business loan)
  5. 5.      Version 0.9 (80 byte hash) Bitcoin currently manages one asset via one token Dev team has limited resources Yet in theory, a token can represent any asset And a token can be a type of „smart contract‟
  6. 6.       Colored Coins Mastercoin Counterparty (POB) NXT (POS) Invictus Ethereum *Open-Transaction ** Ripple *** Peercover
  7. 7.     Property whose ownership is controlled via a smart contract, which may or may not reside on a cryptoledger „Proplet‟ MEMS Internet of Things
  8. 8.   Not all gadgets, devices or digital appliances are technically smart property Ownership must be able to transferred and managed via smart contracts
  9. 9.  TradeNet/MatterNet (DAO/DACP) ◦ Decentralized Autonomous X ◦ Anything with a proplet         Cars Refrigerators Thermostats Smoke detectors Doors Vacuums Light bulbs UAV (Quadcopter)
  10. 10. • Manage, trade and exchange assets globally, pseudonymously (perhaps anonymously) entirely without going into fiat  TAM is a fusion of: ◦ ◦ ◦ ◦ ◦ Cryptoledger Smart Contracts (e.g., tokens) Smart Property („proplets‟) Decentralized exchanges DAO/DACP*
  11. 11.       Near frictionless within the network Entirely decentralized (e.g. DEX, Coinality, BankToTheFuture) Reputation-based at address level (credit score) Independent arbitration (Judge.me, Coinsigner) Escrow (BTCrow) Tokens to represent most contractual agreements (e.g., „labor‟ token to represent X amount of time used as invoice and (dis)approved via atomic-transaction)
  12. 12.     70 year leases are often 40-50 year leases 4 million rural Chinese evicted each year Local gov‟t generate 70% of annual income from land sales 120-150 million migrant workers without urban hukou‟s
  13. 13.         Low Bitcoin adoption (1-2 million users) User interfaces and adoption Consumer education Legal uncertainties Institutional/incumbent inertia Reinventing the wheel Is an ideal scenario, just like PGP “Decentralization for decentralizations sake”
  14. 14.    Email: tswanson@gmail.com Twitter: @ofnumbers Ofnumbers.com
  15. 15.   Contracts very often use multi-signature outputs in order to allocate value to a group of users ... typically, the participants in the contract protocol. Multi-signature outputs are easy to create with bitcoinj. // Create a random key. ECKey clientKey = new ECKey(); // We get the other parties public key from somewhere ... ECKey serverKey = new ECKey(null, publicKeyBytes); // Prepare a template for the contract. Transaction contract = new Transaction(params); List<ECKey> keys = ImmutableList.of(clientKey, serverKey); // Create a 2-of-2 multisig output script. Script script = ScriptBuilder.createMultiSigOutputScript(2, keys); // Now add an output for 0.50 bitcoins that uses that script. BigInteger amount = Utils.toNanoCoins(0, 50); contract.addOutput(amount, script); // We have said we want to make 0.5 coins controlled by us and them. // But it's not a valid tx yet because there are no inputs. Wallet.SendRequest req = Wallet.SendRequest.forTx(contract); wallet.completeTx(req); // Could throw InsufficientMoneyException // Broadcast and wait for it to propagate across the network. // It should take a few seconds unless something went wrong. peerGroup.broadcastTransaction(req.tx).get();
  16. 16.      A common requirement when implementing contract protocols is to pass around and sign incomplete transactions. The Wallet class doesn't know how to handle outputs that aren't fully owned by it. So we'll have to sign the spending transaction ourselves. The key point to bear in mind is that when you sign a transaction, what you actually sign is only parts of that transaction. Which parts are controlled by the signature hash (sighash) flags. But no matter which flags you select, the contents of input scripts are never signed. Indeed that must be the case, because otherwise you could never build a transaction - the act of signing the second input would modify the version of the transaction signed by the first, breaking the signature. This means that signatures can be calculated and sent between different parties in a contract, then inserted into a transaction to make it valid. // Assume we get the multisig transaction we're trying to spend from // somewhere, like a network connection. ECKey serverKey = ....; Transaction contract = ....; TransactionOutput multisigOutput = contract.getOutput(0); Script multisigScript = multisigOutput.getScriptPubKey(); // Is the output what we expect? checkState(multisigScript.isSentToMultiSig()); BigInteger value = multisigOutput.getValue(); // OK, now build a transaction that spends the money back to the client. Transaction spendTx = new Transaction(params); spendTx.addOutput(value, clientKey); spendTx.addInput(multisigOutput); // It's of the right form. But the wallet can't sign it. So, we have to // do it ourselves. Sha256Hash sighash = spendTx.hashTransactionForSignature(0, multisigScript, Transaction.SIGHASH_ALL, false); ECKey.ECDSASignature signature = serverKey.sign(sighash); // We have calculated a valid signature, so send it back to the client: sendToClientApp(signature);
  17. 17.   The server receives the contract and decides to give all the money back to the client (how generous of it!). It constructs a transaction and signs it. Now the client must repeat the process and construct exactly the same transaction and calculate a signature in the same way. It is then in possession of two valid signatures over the same transaction, one from itself and one from the server. All that is left is to put them both into the transaction: TransactionOutput multisigContract = ....; ECKey.ECSDASignature serverSignature = ....; // Client side code. Transaction spendTx = new Transaction(params); spendTx.addOutput(value, clientKey); TransactionInput input = spendTx.addInput(multisigOutput); Sha256Hash sighash = spendTx.hashTransactionForSignature(0, multisigScript, Transaction.SIGHASH_ALL, false); ECKey.ECDSASignature mySignature = clientKey.sign(sighash); // Create the script that spends the multi-sig output. Script inputScript = ScriptBuilder.createMultiSigInputScript( ImmutableList.of(mySignature, serverSignature), Transaction.SIGHASH_ALL, false); // Add it to the input. input.setScriptSig(inputScript); // We can now check the server provided signature is correct, of course... input.verify(multisigOutput); // Throws an exception if the script doesn't run. // It's valid! Let's take back the money. peerGroup.broadcastTransaction(spendTx).get(); // Wallet now has the money back in it.

×