Bitcoin has a scripting language which enables more than a “send money from X to Y” transaction. A Bitcoin transaction can require M of N parties to approve a transaction. Imagine Wills that automatically unlock when most of the heirs agree that their parent has passed, no lawyer required. Or business accounts that require two of any three trusted signatures to approve an expenditure. Or wire escrows that go through when any arbiter agrees that the supplier sent the goods to the buyer. Or wallets that are socially secured by your friends and family. Or an allowance account accessible by the child and either of two parents. Or a crowdfunding of a Kickstarter project that pays out on milestones, based on the majority of the backers approving the next payment. The escrow in each case can be locked so that the arbiters can’t take the money themselves – only approve or deny the transaction.
The scripting language can also unlock transactions based on other parameters. Unlocking them over time can enable automatic mortgage, trust, and allowance payouts. Unlocking them on guessable numbers creates a lottery auditable by third parties. One can even design smart property – for example, a car’s electronic key so that when and only when a payment is made by the car buyer to the seller, the seller’s car key stops working and the buyer’s car key (or mobile phone) starts the car. Imagine your self-driving car negotiating traffic, paying fractional bitcoin to neighboring cars in exchange for priority.
I've been following Bitcoin since the beginning and had no idea it supported "transaction approved only when M of N participants agree."
How do you feel about those scenarios? Also, does anyone know of other little-known Bitcoin functionality?
Beyond script there isn't a whole lot— nlocktime lets you make transactions which cannot be mined until a specified time in the future. This lets you build protocols that have "refunds", so that they don't cause funds to get stuck if a participant walks away.
But even just using a few features of script and nlocktime is exceptionally powerful:
One of the most important things script does is allows you to produce transactions which are bound into more complex protocols occurring outside of Bitcoin in a secure way. This allows you to extend Bitcoin's trustless decentralization into things which aren't part of Bitcoin proper.
Bitcoin use a scripting language for the transactions, as described in here[0][1].
Interestingly, I believe that this is one of the case where "lazy programmers make best programmers": instead of implementing the transaction system, Satoshi decides that he couldn't be bothered and just put in a scripting system instead (I have no citation for this, and can't claim for certain that this is the case, it was just something I read a while ago).
However, due to security concerns, I think that most of the scripting ability is currently disabled.
Provably Prune-able Outputs! See https://bitcoinfoundation.org/blog/?p=290. The idea is to support adding a little bit (80 bytes) of extra data to a transaction, while signalling to people who don't need to know about it (i.e. almost everyone) that they can happily ignore any such data and thus avoid downloading it.
This has the potential to allow new protocols to be built ontop of bitcoin. Mastercoin is one new protocol that uses the pruneable, provable outputs functionality. Learn more about Mastercoin here: https://github.com/mastercoin-MSC/
For those uninformed, "MasterCoin" is an impossible attempt at pegging Bitcoin to the USD (among other things). It of course doesn't work because there's a limited supply, which means that the prices are raised and you're no longer pegged. The whole setup is essentially designed by the creator to make him and his "donators" rich (buy some now and get 10% more! was the original post).
Due to the ponzi-like setup, the people who paid 4 million dollars for "MasterCoin" are very, very vocal when it comes to promoting it.
The scripting language vision has been there from the beginning, but parts of it have been 'off' (in the reference client) because of incomplete implementation, or concern that the implications and potential bugs aren't sufficiently understood.
I wonder if a future Bitcoin offshoot might even use a more general standard language for in-ledger transactions. Javascript? LLVM?
They couldn't, because Javascript etc are turing complete, so you can't predict if they're going to end (halting problem). With bitcoin you know that the script will end and that the running time will correlate loosely with the size of the script, so you can't really use it to mess up network nodes. Butcoin scripts have no loops or goto.
A guarantee of completion isn't strictly necessary: you can cap the number of ticks/cycles a script is allocated on a deterministic reference machine.
Surely there'd be a number of technical and economic challenges to be overcome, but Bitcoin itself is an example of how a good-enough solution may be hiding in plain sight.
Indeed, you can, but then you have a very exact requirement on exactly how the interpreter is implemented which can never be optimized, and any disagreement between implementations can cause a world ending consensus failure.
By not having looping or recursion script naturally gets an operation limit by virtue of having a size limit, and this is _relatively_ easy to get right between implementations. (Though, so far several of the alt implementations have gotten it wrong).
You could require all scripting to be done in a language supporting total functional programming, like Epigram. That would be fairly hilarious (also counterproductive, because the increased script size would cause blockchain bloat).
Why not? The rules for validating Bitcoin transactions and blocks must be completely specified and followed exactly by all implementations of the client software, otherwise you risk forks.
Bitcoin is a consensus system. It is paramount that all participating nodes reach the exact same state.
If undefined behavior could make some nodes accept a transaction while others reject it the state would become inconsistent and potentially mutually exclusive. From one currency, you'd have two and every coin could be spent twice.
An important caveat is that Bitcoin Script isn't enabled in the current implementation of Bitcoin, for obvious security reasons. The immense possibility of Script is yet another reason I am long on Bitcoin.
Only parts of it aren't enabled. You can already do a lot with Script:
"This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain."
What are you talking about? Every single transaction uses the bitcoin scripting language, and has since the genesis block. There are certain rules about which transactions are relayed based on the scripts they contain, but scripting certainly is an integral part of bitcoin as it exists today.
Simply wrong. I suggest you actually look at the source code to bitcoind (start with script.cpp, and the validation methods in main.cpp/core.cpp which call it).
Thats not correct. They're executed, and fancy scripts are sometimes used on the network.
Common wallet software just uses templates to create and decide which scripts are relevant to them— but the network itself absolutely does validate them.
I have an issue with that particular scenario. What if your three hairs secretly hate you and just agree to declare you dead?
But I can see it working with some adjustments: make your contractually obliged lawyer part of the transaction and include his fees. This way he can't grab all the money for himself and your usurpers can't get to your money that easy.
Bitcoin has a scripting language which enables more than a “send money from X to Y” transaction. A Bitcoin transaction can require M of N parties to approve a transaction. Imagine Wills that automatically unlock when most of the heirs agree that their parent has passed, no lawyer required. Or business accounts that require two of any three trusted signatures to approve an expenditure. Or wire escrows that go through when any arbiter agrees that the supplier sent the goods to the buyer. Or wallets that are socially secured by your friends and family. Or an allowance account accessible by the child and either of two parents. Or a crowdfunding of a Kickstarter project that pays out on milestones, based on the majority of the backers approving the next payment. The escrow in each case can be locked so that the arbiters can’t take the money themselves – only approve or deny the transaction.
The scripting language can also unlock transactions based on other parameters. Unlocking them over time can enable automatic mortgage, trust, and allowance payouts. Unlocking them on guessable numbers creates a lottery auditable by third parties. One can even design smart property – for example, a car’s electronic key so that when and only when a payment is made by the car buyer to the seller, the seller’s car key stops working and the buyer’s car key (or mobile phone) starts the car. Imagine your self-driving car negotiating traffic, paying fractional bitcoin to neighboring cars in exchange for priority.
I've been following Bitcoin since the beginning and had no idea it supported "transaction approved only when M of N participants agree."
How do you feel about those scenarios? Also, does anyone know of other little-known Bitcoin functionality?