6 ms·

Bitcoin contracts

119 points by Theyeard 12y ago

andrewla 12y ago
For many, the flexibility of Bitcoin in terms of what sorts of scripts can be executed with transactions is much of the appeal. I'm of the opinion, however, that it represents Bitcoin's greatest weakness. In order for bitcoins to be useful for money, it must be possible to determine how many bitcoins I have, or, more exactly, how many I have available to spend. The fact that there is a language associated with bitcoin redemption, and the redemption happens at the time of the creation of the outbound transaction makes this very difficult to determine. So, more clearly, if I want to spend some coins that have been nominally sent to me, at the time that I attempt to send them to another address, I have to have all the information necessary to redeem the coins that were sent to me, for each instance of an incoming transaction to my address. If this sounds complicated, it is because it is. Ethereum, one of the many post-Bitcoin cryptocurrencies, does a much better job of this on the pure currency side -- spending coins at an address to which I have the private key is just a matter of saying how many coins I want to send and where. Ethereum, unfortunately (in my mind) complicates this with a much more sophisticated language that lives in a side-chain. I think the ultimate Bitcoin successor (or modifications to the Bitcoin protocol itself) will have to prune down the scope of allowed transactions, rather than expanding it. This isn't just a question of the "my grandmother won't be able use it" -- although having an unspendable incoming transaction from the "publishers bitclearing house" for a million bitcoins will definitely be a bit offputting. In the end, even for a sophisticated user, it will be nearly impossible to present a view of how many bitcoins you have available to spend. This is why the core devs have been very reluctant to allow different kinds of scripts; multisig is the first real expansion. Colored coins, while kind of fun, live outside the blockchain, so don't really bother me. It's basically the equivalent of a (for example) car saying "anyone who holds a dollar bill with serial number xxxxxx from year yyyy can start the engine", in a world where it is impossible to forge dollar bills (as is the case with bitcoins).
- tlrobinson 12y ago
  IMHO this is the least of Bitcoin's problems. My grandmother doesn't understand the internals of the internet, just like she won't understand the internals of Bitcoin. Additionally, with BIP-16 (P2SH) and BIP-70 (payment protocol) it is up to the recipient to provide the spend script. Presumably my wallet won't generate a script it doesn't understand. If the wallet doesn't track the required information, whether that's your private key or something more complex, of course you're going to have problems.
- marcell 12y ago
  > In the end, even for a sophisticated user, it will be nearly impossible to present a view of how many bitcoins you have available to spend. This is not necessarily true. It is a UI challenge. You can imagine a UI that, for example, understand that you are participating in a crowd-funding contract, and denotes the bitcoins locked down in that contract in a special area. For the crowd-funding contract, you can exit at anytime before the contract closes, so the UI could present that option as well. This approach can be applied to other contracts as well.
  - M4v3R 12y ago
    It's not "nearly impossible", but it's not _easy_ either. You really need to store all inputs for a given address since the genesis block to obtain the balance of this address. You cannot get that information from elsewhere (apart from 3rd party APIs but then you have to trust the 3rd party, kind of defeating the purpose of Bitcoin).
  - andrewla 12y ago
    I'm going to stick with nearly impossible. Yes, it is theoretically possible to have a fixed number of built-in contract types that follow a certain schema, and to make a UX corresponding to each one. But in the full generality -- you get one of these crowd-funding contracts, and the client has to figure out what kind of counterparty signing has to happen in order to spend these damn things. Without prior knowledge of the structure, I'm guessing that this verges on intractable. Of course, with a finite number of transaction types, this is easy, right? Well, not even then. Because you don't redeem these things when you _receive_ them. You redeem them when you _spend_ them. There's no easy solution here; most likely the clients will have to do a one-time sweep of receptions that it knows how to complete to an unencumbered transaction input, so that they can be spent without having to gather a bunch of documents. But at the very minimum, a very challenging experience compared to cash, or even the "standard" transaction inputs.
- bencxr 12y ago
  Even in it's current form, your grandma's wallet balance would resemble that of her BoA checking account, where the spendable amount would be a total of the easily-redeemable (Pay to pubkey hash) transactions. More complex transactions would show up in more advanced wallets (possibly separately), and that is the way it happens in the real world now. Say you hold an options contract or a bond on some stock exchange - it's "spendable" but doesn't show up on your everyday bank account balance. This is useful money as we know it now. The allowance for such flexible transactions is a feature and not a weakness :)
  - icebraining 12y ago
    In fact, banks here in Portugal already show you two balances, an "accounting" balance which shows you the sum of all transactions, including ones that haven gone through yet (e.g. deposited checks) and an "available" balance which is what you can actually use right now. It's really not that difficult.
- shazow 12y ago
  It's really not as complicated as you could make it seem. Your Bitcoins just have two states: Spendable and not spendable. Spendable coins are ones that you can go ahead and make a transaction with right now. Unspendable coins are ones that are locked up until some event occurs—maybe they're part of a complicated Script, or maybe they're already part of an unconfirmed transaction. It's not unlike how when you go buy something with your Visa credit card and the merchant places a soft hold on some value. That value becomes an unconfirmed transaction until days (weeks? months?) later. Bitcoins are similar except the inverse, you get a hard hold until the transaction is resolved. Are credit card complicated? Very, especially when you realize how much of the arcane half-broken functionality is purely due to specific regulation thresholds. But we get by alright with burying our heads in the sand. > Colored coins, while kind of fun, live outside the blockchain, so don't really bother me. Depends on the colored coin, some live on the blockchain. http://coloredcoins.org/ http://coloredcoins.org/
  - andrewla 12y ago
    It's not an insurmountable problem, but the design of the protocol, as I mention below, makes the transition from "unspendable" to "spendable" difficult, because you can't even try to satisfy the conditions until you try to spend the coins -- the only thing that would make sense would be to do this with another transaction that does nothing but transfer the unspendable coins to another address. It really is quite complicated. In the best case, in my view, there would be specialized clients that would interpret certain classes of transaction scripts, and the majority of wallet software would not care at all, and only acknowledge the basic transactions (pay to pubkey hash). But all miners have to be aware of the full scope, and all full nodes will need to have some extra complexity, in order to even validate the blockchain. That complexity leads to unpredictable behavior and bugs. My guess is that when Bitcoin really has to go head-to-head with another coin, this "feature" will have a dragging effect. I glanced at the papers on http://coloredcoins.org http://coloredcoins.org, and they haven't changed. Though the colored coins are tracked through the blockchain, the fact that a coin is colored, and what that color means, lives entirely outside the blockchain. My analogy with "smart property" simply looking for a particular serial numbered bill is very apt, but of course you gain the cryptographic anti-counterfeiting guarantees of bitcoin. All the same risks apply as well; you can inadvertently spend a colored coin, and if the recipient is not looking out for it, they'll probably never know that they are in nominal possession of a colored coin, and possession of the "smart property" will simply float around between people, just like a similarly-marked dollar bill inserted into a vending machine would do.
- DennisP 12y ago
  Ethereum scripting isn't in a side chain, it's an integral part of the main chain. In fact, you have to pay ether to run the script.
- woah 12y ago
  This is a really bizarre comment. None of this is any sort of obstacle. Any unspent, in-limbo coins are easily conceived of as being "refundable". Someone who would get confused by the things you mention would also get confused by the concept of a rent deposit, a money-back guarantee, or a corporate stock.
- nullc 12y ago
  This isn't a weakness at all. Your wallet knows what it can spend, and you only consider payments paid when they are paid according to your terms. A wallet isn't tasked with knowing about crazy things that it might be able to spend if you modified the code— what you're saying is completely isomorphic to saying that the US Dollar has a weakness because someone could put a $100 bill in a locked safe with your birthday as the combination and bury it in your back yard without your knoweldge, and you wouldn't know that you could spend it. Any contract use with Bitcoin requires you to have software that understands the contracts— no wallet does or will ever show arbitrarily encoded contracts written by a third party. Otherwise, someone could start "paying" you using 1 of 2 payment with one of them being a private key your wallet knows— then claw the funds back after you thought the transaction was settled. Because a contract could do almost anything it would never be safe to just automatically accept them, in any system, and so nothing does or will.
bdamm 12y ago
If I'm understanding correctly, these scripts are very long lived in that days, weeks, or years may go by before segments of the contracts are resolved. This does seem like a powerful mechanism. Unanswered in the paper is a look at the wallet implementations; can I expect wallets to correctly report the balance in a payee's wallet, if they have outstanding contracts? The escrow mechanism strikes me as particularly powerful; it's like traditional escrow but even better because the buyer doesn't quite give up control, and the seller knows that the escrow company can't just disappear with their funds. Activation of the escrow agreement can take minutes, rather than days or weeks for traditional escrow (usually involving wire transfers), once the escrow agreement is set up. It doesn't solve the problem of the escrow company being in cahoots with one of the parties, but I believe the mechanism can be extended to N-way escrow where multiple escrow companies could be arbiters over the transaction. Then the buyer and seller can both have a trusted escrow company in the transaction and know that their interests are indeed being represented, and the escrow companies can determine if the other escrow company is one that they trust as well, before committing to fulfilling a transaction.
- M4v3R 12y ago
  Escrow contracts in Bitcoin are now more and more used because they add real security without taking much convenience. Shameless plug [0] - I work for a startup that does exactly that, utilizing multi signature Bitcoin addressed for added user security. But you could also build a service for a true escrow very easily and as you say, that wouldn't mean putting all the trust into the escrow party, which is great. These services, in fact, already do exist [1]. Also, at least for P2SH (multi signature/escrow addresses), getting their balance is no different than for normal addresses. Completed transactions to them are perfectly visible on the network so you can sum them up. Uncompleted (partially signed) transactions are not sent to the network though, so you cannot estimate how many "pending" Bitcoins are there for a given address. [0] https://bitalo.com https://bitalo.com [1] http://cosign.co.in http://cosign.co.in
  - waps 12y ago
    What I wonder is what happens to the money locked up in these transactions. I understand that the money is effectively inaccessible to both the sender and the receiver until the transaction is resolved. Is that right ? I wonder about the implications of that, since it effectively takes money out of circulation, during whatever length of time it takes to finalize the transaction. That presumably includes any conflict resolution process that may exist ?
kylebrown 12y ago
Wow, this is superb educational content.[1] Is the author anonymous? 1. also https://curiosity-driven.org/low-level-bitcoin https://curiosity-driven.org/low-level-bitcoin
- davidcollantes 12y ago
  I am very curious about the same. I did a whois on the domain, and its information is protected, of course. The DNS is in Poland, and the site runs on Digital Ocean (Netherland IP). I am guessing he/she is European. But other than that...
- jordigh 12y ago
  The author does appear to be anonymous. By the systematic lack of articles (a lot of noun phrases seem to be missing "the"), I would guess a speaker of a Slavic language. Possibly Polish, given the DNS.
kolinko 12y ago
On a related note - all the blockchain contracts are limited by their inability to access real world data (e.g. stock prices, websites). For that you need distributed oracles: https://github.com/orisi/wiki/wiki/Orisi-White-Paper https://github.com/orisi/wiki/wiki/Orisi-White-Paper
- Theyeard 12y ago
  Exactly - scripts are pure functions. Reasoning behind this is explained by Satoshi himself at Bitcoin Talk [0]. Contracts page at Bitcoin wiki has an example of defining a will using Bitcoin and an oracle [1]. [0] https://bitcointalk.org/index.php?topic=195.msg1611#msg1611 https://bitcointalk.org/index.php?topic=195.msg1611#msg1611 [1] https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_extern...
  - kolinko 12y ago
    Yup. The concept of a blockchain is fundamentally incompatible with external inputs. That's because at any given moment you need two things: - everyone to agree that the new block is valid (and you can't really do that if blocks contained functions that had to be verified with external/changeable outputs) - everyone has to agree that all the past blocks were valid, which is even harder, because if blocks referenced external outputs, the sites/sources they relied on may have changed That's why not only Bitcoin, but also Ethereum and all the other blockchain-based currencies need oracles for passing external inputs in. By the way, here's our repo, if anyone's interested in the whole concept: https://github.com/orisi/orisi https://github.com/orisi/orisi -- there are tutorials there explaining how to set up an example oracle, and an example client sending stuff to oracles to sign. There's also one of the core devs explaining this stuff: gavintech.blogspot.com/2014/06/bit-thereum.html
- yarrel 12y ago
  Or SchellingCoins - https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/ https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal...
- 12y ago
a-b 12y ago
http://trustatom.com/ http://trustatom.com/

119 points by Theyeard 12y ago

For many, the flexibility of Bitcoin in terms of what sorts of scripts can be executed with transactions is much of the appeal. I'm of the opinion, however, that it represents Bitcoin's greatest weakness. In order for bitcoins to be useful for money, it must be possible to determine how many bitcoins I have, or, more exactly, how many I have available to spend. The fact that there is a language associated with bitcoin redemption, and the redemption happens at the time of the creation of the outbound transaction makes this very difficult to determine. So, more clearly, if I want to spend some coins that have been nominally sent to me, at the time that I attempt to send them to another address, I have to have all the information necessary to redeem the coins that were sent to me, for each instance of an incoming transaction to my address. If this sounds complicated, it is because it is. Ethereum, one of the many post-Bitcoin cryptocurrencies, does a much better job of this on the pure currency side -- spending coins at an address to which I have the private key is just a matter of saying how many coins I want to send and where. Ethereum, unfortunately (in my mind) complicates this with a much more sophisticated language that lives in a side-chain. I think the ultimate Bitcoin successor (or modifications to the Bitcoin protocol itself) will have to prune down the scope of allowed transactions, rather than expanding it. This isn't just a question of the "my grandmother won't be able use it" -- although having an unspendable incoming transaction from the "publishers bitclearing house" for a million bitcoins will definitely be a bit offputting. In the end, even for a sophisticated user, it will be nearly impossible to present a view of how many bitcoins you have available to spend. This is why the core devs have been very reluctant to allow different kinds of scripts; multisig is the first real expansion. Colored coins, while kind of fun, live outside the blockchain, so don't really bother me. It's basically the equivalent of a (for example) car saying "anyone who holds a dollar bill with serial number xxxxxx from year yyyy can start the engine", in a world where it is impossible to forge dollar bills (as is the case with bitcoins).

tlrobinson 12y ago
IMHO this is the least of Bitcoin's problems. My grandmother doesn't understand the internals of the internet, just like she won't understand the internals of Bitcoin. Additionally, with BIP-16 (P2SH) and BIP-70 (payment protocol) it is up to the recipient to provide the spend script. Presumably my wallet won't generate a script it doesn't understand. If the wallet doesn't track the required information, whether that's your private key or something more complex, of course you're going to have problems.
marcell 12y ago
> In the end, even for a sophisticated user, it will be nearly impossible to present a view of how many bitcoins you have available to spend. This is not necessarily true. It is a UI challenge. You can imagine a UI that, for example, understand that you are participating in a crowd-funding contract, and denotes the bitcoins locked down in that contract in a special area. For the crowd-funding contract, you can exit at anytime before the contract closes, so the UI could present that option as well. This approach can be applied to other contracts as well.
- M4v3R 12y ago
  It's not "nearly impossible", but it's not _easy_ either. You really need to store all inputs for a given address since the genesis block to obtain the balance of this address. You cannot get that information from elsewhere (apart from 3rd party APIs but then you have to trust the 3rd party, kind of defeating the purpose of Bitcoin).
- andrewla 12y ago
  I'm going to stick with nearly impossible. Yes, it is theoretically possible to have a fixed number of built-in contract types that follow a certain schema, and to make a UX corresponding to each one. But in the full generality -- you get one of these crowd-funding contracts, and the client has to figure out what kind of counterparty signing has to happen in order to spend these damn things. Without prior knowledge of the structure, I'm guessing that this verges on intractable. Of course, with a finite number of transaction types, this is easy, right? Well, not even then. Because you don't redeem these things when you _receive_ them. You redeem them when you _spend_ them. There's no easy solution here; most likely the clients will have to do a one-time sweep of receptions that it knows how to complete to an unencumbered transaction input, so that they can be spent without having to gather a bunch of documents. But at the very minimum, a very challenging experience compared to cash, or even the "standard" transaction inputs.
bencxr 12y ago
Even in it's current form, your grandma's wallet balance would resemble that of her BoA checking account, where the spendable amount would be a total of the easily-redeemable (Pay to pubkey hash) transactions. More complex transactions would show up in more advanced wallets (possibly separately), and that is the way it happens in the real world now. Say you hold an options contract or a bond on some stock exchange - it's "spendable" but doesn't show up on your everyday bank account balance. This is useful money as we know it now. The allowance for such flexible transactions is a feature and not a weakness :)
- icebraining 12y ago
  In fact, banks here in Portugal already show you two balances, an "accounting" balance which shows you the sum of all transactions, including ones that haven gone through yet (e.g. deposited checks) and an "available" balance which is what you can actually use right now. It's really not that difficult.
shazow 12y ago
It's really not as complicated as you could make it seem. Your Bitcoins just have two states: Spendable and not spendable. Spendable coins are ones that you can go ahead and make a transaction with right now. Unspendable coins are ones that are locked up until some event occurs—maybe they're part of a complicated Script, or maybe they're already part of an unconfirmed transaction. It's not unlike how when you go buy something with your Visa credit card and the merchant places a soft hold on some value. That value becomes an unconfirmed transaction until days (weeks? months?) later. Bitcoins are similar except the inverse, you get a hard hold until the transaction is resolved. Are credit card complicated? Very, especially when you realize how much of the arcane half-broken functionality is purely due to specific regulation thresholds. But we get by alright with burying our heads in the sand. > Colored coins, while kind of fun, live outside the blockchain, so don't really bother me. Depends on the colored coin, some live on the blockchain. http://coloredcoins.org/ http://coloredcoins.org/
- andrewla 12y ago
  It's not an insurmountable problem, but the design of the protocol, as I mention below, makes the transition from "unspendable" to "spendable" difficult, because you can't even try to satisfy the conditions until you try to spend the coins -- the only thing that would make sense would be to do this with another transaction that does nothing but transfer the unspendable coins to another address. It really is quite complicated. In the best case, in my view, there would be specialized clients that would interpret certain classes of transaction scripts, and the majority of wallet software would not care at all, and only acknowledge the basic transactions (pay to pubkey hash). But all miners have to be aware of the full scope, and all full nodes will need to have some extra complexity, in order to even validate the blockchain. That complexity leads to unpredictable behavior and bugs. My guess is that when Bitcoin really has to go head-to-head with another coin, this "feature" will have a dragging effect. I glanced at the papers on http://coloredcoins.org http://coloredcoins.org, and they haven't changed. Though the colored coins are tracked through the blockchain, the fact that a coin is colored, and what that color means, lives entirely outside the blockchain. My analogy with "smart property" simply looking for a particular serial numbered bill is very apt, but of course you gain the cryptographic anti-counterfeiting guarantees of bitcoin. All the same risks apply as well; you can inadvertently spend a colored coin, and if the recipient is not looking out for it, they'll probably never know that they are in nominal possession of a colored coin, and possession of the "smart property" will simply float around between people, just like a similarly-marked dollar bill inserted into a vending machine would do.
DennisP 12y ago
Ethereum scripting isn't in a side chain, it's an integral part of the main chain. In fact, you have to pay ether to run the script.
woah 12y ago
This is a really bizarre comment. None of this is any sort of obstacle. Any unspent, in-limbo coins are easily conceived of as being "refundable". Someone who would get confused by the things you mention would also get confused by the concept of a rent deposit, a money-back guarantee, or a corporate stock.
nullc 12y ago
This isn't a weakness at all. Your wallet knows what it can spend, and you only consider payments paid when they are paid according to your terms. A wallet isn't tasked with knowing about crazy things that it might be able to spend if you modified the code— what you're saying is completely isomorphic to saying that the US Dollar has a weakness because someone could put a $100 bill in a locked safe with your birthday as the combination and bury it in your back yard without your knoweldge, and you wouldn't know that you could spend it. Any contract use with Bitcoin requires you to have software that understands the contracts— no wallet does or will ever show arbitrarily encoded contracts written by a third party. Otherwise, someone could start "paying" you using 1 of 2 payment with one of them being a private key your wallet knows— then claw the funds back after you thought the transaction was settled. Because a contract could do almost anything it would never be safe to just automatically accept them, in any system, and so nothing does or will.

bdamm 12y ago

If I'm understanding correctly, these scripts are very long lived in that days, weeks, or years may go by before segments of the contracts are resolved. This does seem like a powerful mechanism. Unanswered in the paper is a look at the wallet implementations; can I expect wallets to correctly report the balance in a payee's wallet, if they have outstanding contracts? The escrow mechanism strikes me as particularly powerful; it's like traditional escrow but even better because the buyer doesn't quite give up control, and the seller knows that the escrow company can't just disappear with their funds. Activation of the escrow agreement can take minutes, rather than days or weeks for traditional escrow (usually involving wire transfers), once the escrow agreement is set up. It doesn't solve the problem of the escrow company being in cahoots with one of the parties, but I believe the mechanism can be extended to N-way escrow where multiple escrow companies could be arbiters over the transaction. Then the buyer and seller can both have a trusted escrow company in the transaction and know that their interests are indeed being represented, and the escrow companies can determine if the other escrow company is one that they trust as well, before committing to fulfilling a transaction.

M4v3R 12y ago
Escrow contracts in Bitcoin are now more and more used because they add real security without taking much convenience. Shameless plug [0] - I work for a startup that does exactly that, utilizing multi signature Bitcoin addressed for added user security. But you could also build a service for a true escrow very easily and as you say, that wouldn't mean putting all the trust into the escrow party, which is great. These services, in fact, already do exist [1]. Also, at least for P2SH (multi signature/escrow addresses), getting their balance is no different than for normal addresses. Completed transactions to them are perfectly visible on the network so you can sum them up. Uncompleted (partially signed) transactions are not sent to the network though, so you cannot estimate how many "pending" Bitcoins are there for a given address. [0] https://bitalo.com https://bitalo.com [1] http://cosign.co.in http://cosign.co.in
- waps 12y ago
  What I wonder is what happens to the money locked up in these transactions. I understand that the money is effectively inaccessible to both the sender and the receiver until the transaction is resolved. Is that right ? I wonder about the implications of that, since it effectively takes money out of circulation, during whatever length of time it takes to finalize the transaction. That presumably includes any conflict resolution process that may exist ?

kylebrown 12y ago

Wow, this is superb educational content.[1] Is the author anonymous? 1. also https://curiosity-driven.org/low-level-bitcoin https://curiosity-driven.org/low-level-bitcoin

davidcollantes 12y ago
I am very curious about the same. I did a whois on the domain, and its information is protected, of course. The DNS is in Poland, and the site runs on Digital Ocean (Netherland IP). I am guessing he/she is European. But other than that...
jordigh 12y ago
The author does appear to be anonymous. By the systematic lack of articles (a lot of noun phrases seem to be missing "the"), I would guess a speaker of a Slavic language. Possibly Polish, given the DNS.

kolinko 12y ago

On a related note - all the blockchain contracts are limited by their inability to access real world data (e.g. stock prices, websites). For that you need distributed oracles: https://github.com/orisi/wiki/wiki/Orisi-White-Paper https://github.com/orisi/wiki/wiki/Orisi-White-Paper

Theyeard 12y ago
Exactly - scripts are pure functions. Reasoning behind this is explained by Satoshi himself at Bitcoin Talk [0]. Contracts page at Bitcoin wiki has an example of defining a will using Bitcoin and an oracle [1]. [0] https://bitcointalk.org/index.php?topic=195.msg1611#msg1611 https://bitcointalk.org/index.php?topic=195.msg1611#msg1611 [1] https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_extern...
- kolinko 12y ago
  Yup. The concept of a blockchain is fundamentally incompatible with external inputs. That's because at any given moment you need two things: - everyone to agree that the new block is valid (and you can't really do that if blocks contained functions that had to be verified with external/changeable outputs) - everyone has to agree that all the past blocks were valid, which is even harder, because if blocks referenced external outputs, the sites/sources they relied on may have changed That's why not only Bitcoin, but also Ethereum and all the other blockchain-based currencies need oracles for passing external inputs in. By the way, here's our repo, if anyone's interested in the whole concept: https://github.com/orisi/orisi https://github.com/orisi/orisi -- there are tutorials there explaining how to set up an example oracle, and an example client sending stuff to oracles to sign. There's also one of the core devs explaining this stuff: gavintech.blogspot.com/2014/06/bit-thereum.html
yarrel 12y ago
Or SchellingCoins - https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/ https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal...
12y ago

a-b 12y ago

http://trustatom.com/ http://trustatom.com/