No. In the reference client, main.cpp runs this check during "AcceptBlock":
// Check that all transactions are finalized
BOOST_FOREACH(const CTransaction& tx, block.vtx)
if (!IsFinalTx(tx, nHeight, block.GetBlockTime()))
return state.DoS(10, error("AcceptBlock() : contains a non-final transaction"),
It should be Turing complete. However, every time a contract is invoked, the maximum number of operations the contract can perform is limited. Operations that access a contract must specify an operation count limit to get a limit higher than the default. Higher limits require higher transaction fees.
Gregory Maxwell, Pieter Wuille, and theymos are using a 2-of-3 address to store a bounty for contributions to CoinJoin.
Update: A 2-of-3 escrow and arbitration site recently launched: https://www.bitrated.com/
This is basically how every asset in Ripple works, other than XRP.
Ripple permits anyone to create an asset and back it in any way that they choose. Others can declare their willingness to accept specific assets in payment. And Ripple implements distributed order books, payment pathfinding, and atomic multi-asset transactions to implement transfers of value....
Simple answer, no. What you're most likely talking about are interesting ways to use script to pay to a m-of-n multisig, for example. Generally, when you get paid in bitcoin, you, as the merchant, get to choose where the customer sends the bitcoin. This can be 2-of-3 multisig, which would mean 2 of the 3 people you choose have to agree in order to move the ...
Since one of the inputs of the nLockTime transaction has been spent already, the nLockTime transaction becomes invalid, as not all referenced inputs are available for spending.
This is described in the Bitcoin developers guide explicitly as a way to cancel a locktime transaction:
If any of the signers change their mind, they can create a new non-...
It can't be done with today's infrastructure. We can imagine two solutions.
First solution: Bitcoin upgrades
Script gets progressively more powerful with new opcodes. In this case I think there would actually have to be a new UTXO set index (which nodes don't currently even calculate) so the script could find all the payments to a particular address/with a ...
The short answer is: No. The average number of bitcoins per hash is fixed, and is roughly equal to B / (2^32 * D), where B is the bitcoins per block and D is the difficulty. Every calculated hash is either a block or not; if it's not, it doesn't bring you any closer to finding a block.
However, for completeness it should be noted that there are several ...
What do you mean by "loans with interest"? If you mean guaranteeing being
payed back the principal plus some interest that is not possible since
that depends on the external world (i.e. it is offchain).
On the other hand, if you mean just creating repayment links for the agreed amounts it is just following the instructions of BIP21.
Script is employed to encode the rules under which a Transaction Output may be spent. E.g. the most common Script requires just proof of control over an address. Thusly, scripts cannot determine circumstances beyond a single transaction.
As a consequence, it appears to be infeasible to set up an enforceable credit contract with interest, because the loan ...
In bitcoin-js you could do something like this
aliceToBobRedeemScript = bitcoin.script.compile([,
That's all well and nice, but it turns out that courts aren't interested in "mathematical proofs" (with good reason). I recommend reading all the books by Bruce Schneider.
Let's say you got someone to pay you at receive_public_key. Does that mean he has agreed to contract M? No.
The courts would still need to see documentation that your partner actually ...
There's no way for an input script to control the output script, so it can't be encoded into the script itself. However, you can get the same effect with more than one partially-signed transaction. Make a P2SH 2-of-2 multisig address, where you hold one key and the claimant holds the other. Send it some Bitcoin. Then part-sign two transactions from that ...
...how do you determine that the computer program that's supposed to resolve the dispute has actually been run, and if so whether the output of the program is being reported fairly by the computer that ran it? ...
But it occurs to me that the issue with external state contracts is analogous to the issue I described above that's solved with the blockchain. So ...
To exchange between Bitcoin and popular alt-coins like Litecoin/Dogecoin you will need to use the first solution ('using revealing secrets of contract').
The second solution is designed around a hypothetical custom altcoin which is designed specifically to support the described exchange algorithm. I don't think that such an altcoin actually exists, but ...
Things to prove:
Address A belongs to Person 1
Person 1 controls the private key allowing spending from Address A
Address B belongs to Person 2
Person 2 controls the private key allowing spending from Address B
Transaction T transferring an amount from Address A to Address B
was included ...
Bitcoin scripts only have control over the spendability of funds (yes, or no) and they don't have a view of where the output is being spent to. A concept of a system where they do have this ability is called a coin covenant, and is generally thought to be a terrible idea for some of the reasons outlined in that thread. If you are paid to a Pubkey Hash ...
There's no capability in the Bitcoin scripting language to access blockchain related data that isn't included either in the transaction or the output script that the transaction is trying to spend. This basically means that you won't be able to calculate and compare total address balance in the script.
You'll need a third party intermediary who can assess ...
In the example, the user is demonstrating that they are willing to lose access to some amount of Bitcoin for a period of time. The example is based on an assumption that a rational user wouldn't do that unless they were serious about something. The implied benefit is that casual users or bots won't want to put a lock on their funds.
However, as Tadje ...
OpenAssets and CounterParty are the most similar projects I can think of, but I'm sure it doesn't have all of the features you are looking for. You may also be interested in Overstock's Medici project.
Is this method of exchange already possible with Bitcoin and popular alt-coins like Litecoin/Dogecoin?
Is it advisable, though? No. There are a lot of problems with this:
How do buyers and sellers match their trades up?
How do traders know what the current price is?
If it's decentralized, most of the participants won't have DDoS ...
The expected number of bitcoins per hash depends only on the network difficulty and block reward, not the speed at which you execute the hashes. Every hash computed has exactly the same probability of successfully mining a block (or share, in the case of pool mining), and this probability is a function of the difficulty only. More powerful hardware does ...
I don't think so, because the use case of, "I need to pay (the equivalent of) five dollars to buy this comedian's work is more common than the use case of "I need to store this 128-bit string for an indefinite period of time."
Prediction: By the end of 2016, transactions intended to hold metadata instead of actually sending coins will make up less than 10% ...
This is more of a legal than a technical question. All Bob needs to do is to have Alice provably transfer her shares. For example, Bob could demand that Alice associates her smart contract keys with her real identity through some means such as key signatures. That way, they can put their dispute before traditional court. Then the transaction is left to the ...
We're implementing bitcoin-blockchain smart contracts in OpenBazaar.
OpenBazaar smart contracts are not part of the blockchain. The blockchain stores the multisig contract only; it serves as a depository for the money to stay before a product is delivered.
However, smart contracts are viewable at a later time, and either party can prove that the contract ...
The problem with using blockchain to verify external world transactions is that the protocol requires that everyone is able to verify that any given block is valid.
So, at any given time, any miner can get back to the block #2, and verify that all the transactions were valid in that block. That is obviously only possible when the transactions don't ...
I'm afraid your first paragraph is not accurate.
The proof-of-work that a miner presents doesn't certify "I have verified the signatures." Verifying a signature is a cheap computational task, and every client on the network can (and does) verify for itself that every signature in the block chain is valid. They don't have to rely on a miner to verify the ...