Ethereum world computer wallpaper
24 comments
Reddit litecoin wallet linux
A distributed contract is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust.
Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation. By building low trust protocols that interact with Bitcoin, entirely new products can be created:. These pages were written by Mike Hearn. Contact him if you have an idea for a new type of contract. You can watch a video of a talk on contracts that was presented at the Bitcoin conference in London.
In places this page refers to the ability to use the nSequence field for transaction mempool replacement. This mechanism was disabled in , and more recently the code has been removed completely , due to concerns over people using it to perform DoS attacks. Implementors should take this into account and try to create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work with current implementations.
If Bitcoin changes in future to allow mempool replacement once again, this page will be updated. Every transaction in Bitcoin has one or more inputs and outputs. Scripts can contain signatures over simplified forms of the transaction itself.
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp the same field is used for both, but values less than million are interpreted as a block index.
If a transaction's lock time has been reached, we say it is final. Each transaction input has a sequence number. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. When set, only that input is signed and the other inputs can be anything.
This opcode provides n-of-m checking: The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:.
Imagine that you open an account on a website eg, a forum or wiki and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money.
But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money.
And if the operators disappear, you'd eventually like the coins back without needing anything from them. At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears. What if the user wishes to close his account early? The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: No matter what happens, both parties must agree for the contract to change. Obviously, if the user turns out to be abusive i. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased. A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved.
If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:. When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature.
The partially-complete transaction can then be sent to the merchant or mediator for the second signature. An assurance contract is a way of funding the creation of a public good , that is, a good that, once created, anyone can benefit from for free.
The standard example is a lighthouse: One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything. Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and web page translation.
Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time eg, it was linked to from somewhere high traffic , then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation.
When complete it automatically loads in your browser. This scheme relies on several aspects of the protocol. By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid for obvious reasons. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. An assurance contract can be prepared for funding network security for the next block.
In this way, mining can be funded even if block space is not scarce. In a dominant assurance contract, if a contract fails not enough pledges within a set time window the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy.
A scheme for dominant assurance contracts in Bitcoin has been proposed. Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways. Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first.
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an oracle. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true. This is the oracle script.
It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:. This little language is hypothetical, it'd be defined by the oracle and could be anything.
The return value is an output: Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions the contract and the claim and take the coins. Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:. The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash. The Early Temple project has implemented a prototype of an oracle that looks for a key phrase in a web page.
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly challenge the oracle in an automated fashion to ensure it always outputs what is expected.
The challenges can be done without spending any coins because the tx to be signed can be invalid ie, connected to transactions that don't exist. The oracle has no way to know whether a request to be signed is random or real.