Hacker News new | past | comments | ask | show | jobs | submit login
Bitcoin Developer Guide (bitcoin.org)
247 points by dollaaron on Dec 16, 2014 | hide | past | favorite | 71 comments



Can someone who has a better understanding of BTC than me explain something? How do the escrow-like instruments and other contractual instruments built on top of the block chain work? How are they better than existing contractual instruments? How do you guarantee that something that is contractually agreed upon for money (ie: I will transfer you a file, upon me sending the file your funds will be released to me) actually happens? Or am I fundamentally missing something?

Edit: thanks all for replies, learned a lot.


There's quite a bit of work being done in this area, particularly with respect to the Counterparty.io project. In the case of Counterparty, monetary value/tokens are literally stored 'in decentralized escrow' on the bitcoin network. A spender merely attests to a spend by way of their signature on the transaction, subject to release by way of a small bit of code (Serpent is the language, it's very python like). At this time the code executes, miners release the funds. A miner can't 'lie' about the release, as all other nodes validate the work of the miner. Lies are not syndicated around the network, as the numbers simply would not work out upon transmission. I've paraphrased a bit, but that's the gist. If you decide to look down this wormhole, you'll be shocked at how sophisticated these systems are getting.


Transactions aren't simply signed. Each transaction contains half of a program written in a stack-based language called Script:

https://en.bitcoin.it/wiki/Script

One of the things that didn't make sense to me initially was how the Bitcoin network could "know" that a condition had been fulfilled. For example, paying a dowry requires a marriage to have taken place. Likewise, an escrow contract might require proof of delivery of an item.

How could a contract know that the condition had been met?

Oracles offer a solution. The Orisi project has created a framework for setting up and using Oracles for smart contracts:

https://github.com/orisi/orisi


The innovative technology of the blockchain is decentralized, provable consensus. As long as all nodes control less than 51% of mining power, the content of the blockchain at any given time represents the consensus of all nodes on the network. If a multi-party transaction exists on the blockchain, then by definition of it existing, all relevant parties have verified its authenticity.

Bitcoin exposes "scripting" of the blockchain to enable decentralized consensus for arbitrary transaction types. With scripting, developers can leverage the blockchain to store a decentralized consensus of their custom transaction types. Often times this is how escrow-like services are implemented. It's also possible to modify the proof of work scheme itself (as we did with torcoin, albeit in theory only thusfar.)

The extensible part of Bitcoin is the blockchain, which is useful because it's a decentralized, publicly verifiable, mathematically provable consensus.


Thank you. From your sibling comment below:

> Bitcoin doesn't actually solve the problem of needing trust it does solve the problem of needing to trust your escrow agent with your money but then again if you don't trust your escrow agent with your money why do you trust them to make a fair decision.

So I'm still confused here. What new kind of contracts could I build using the blockchain? What existing contracts are made easier because of the blockchain?


Here's one scenario.

Two people want to exchange funds for service or goods. As usual, the seller wants to know that the funds will be available when the goods are delivered. Both people hire an escrow representative (similar to how houses are sold today) and all four create a transaction that binds the buyer's money into a contract; if any two of the remaining parties either enter complete or exit the transaction, then the money is either disbursed to the seller and service providers, or the money is returned to the buyer.

This way, the buyer's money is bound into the contract and the seller can determine this to be the case before releasing their product or service. The escrow representatives are trust companies and can see for themselves whether the transaction is progressing as promised or not due to their connections with the buyer/seller and with each other.


What is to stop me from hiring a malicious escrow agent then and having me + them sign the transaction? Or rather what part of this process stops that from happening?


Because escrow companies know each other, and both buyer and seller can have an escrow company they trust in the contract. If the escrow company doesn't trust the other escrow company, they can choose to not enter the contract.


Then where is the improvement over the existing system you're still having to trust both Escrow companies and they still have to trust each other.


My interpretation is that it doesn't necessarily solve escrow but solves one part of the escrow equation which is - "does the one party actually own enough money to pay". In other words because all BTC is tracked by the blockchain I can verify that the buyer has the $100 they are saying they are willing to pay me, as opposed to him simply saying "Ya I got the $100, don't worry". The "don't worry" part is eliminated because I can verify that his $100 actually does exist on the blockchain. If he decided to sell it, I could see that he is no longer the owner on the blockchain and thus rendering the "don't worry I swear I have the money" impossible. The release of the payment is still done by an escrow service.


Right - in the traditional escrow system, it takes weeks to wire money around. When buying a house that is not a big deal. But if we wanted to move escrow to be useful for much smaller payments, such as a TV set, then you could not use traditional escrow for that due to the high latency and fees ($40+!!!) that the banks will charge you overall for the fund wires.


>in the traditional escrow system, it takes weeks to wire money around.

Have you ever wired money before? Either you haven't and are believing someone else who has told you it takes weeks or you are misrepresenting it here. I've done wires internationally between AU, CA, UK, and US and internal to each country between a variety of banks and in the past 10 years I've never had a wire transfer take more than 3 days(one off) with all the rest completing the next business day at the destination or 2 days later when I've sent it after business hours at the source.


I have wired money, mostly one-offs. Sure, if it is just you wiring money to yourself it can be merely days. When you add in additional steps required to unlock funds and have the recipient transmit acknowledgement, it can take weeks to set up, fund, and use an escrow agreement. It still costs a lot of money, especially for international wires.

And fees. $40 on a $1000 wire is %4. $1000 is a small amount of money to wire. If you're moving around $millions then sure, you don't care. I don't move around $millions.

Here we are talking about turn around times in under an hour, and fees under %1, even for small transactions.


>When you add in additional steps required to unlock funds and have the recipient transmit acknowledgement, it can take weeks to set up, fund, and use an escrow agreement. It still costs a lot of money, especially for international wires.

What are these extra steps you're talking about? If I wire money to you as my escrow agent it will probably get to you next business day. You then verify whatever and send the escrow to the seller that will take another business day. Where are the weeks coming from?

>And fees. $40 on a $1000 wire is %4. $1000 is a small amount of money to wire.

Get a different bank if you're paying $40 for domestic transfers. Hell even if you're getting charged that much for international transfers.

>Here we are talking about turn around times in under an hour, and fees under %1, even for small transactions.

Except we aren't talking about comparable things since the end result is generally local currency not bitcoin you have to add in the steps and fees to convert it as well.


Where does this condition actually exist where you don't want to charge the person up front but want to know they have enough money?

If I'm going to sell you a TV I don't care if you have the money I want the money before I send you something.

This problem is already solved by having the people pay up front.


I don't think it's what she/he's alluding to, but you could do the following:

A: creates a hash of a contract B: creates a hash of the same contract

A sends 0.1BTC to B (and in the transaction message includes the hash). B receives the money and replies with 0.1BTC and the same hash (and the bitcoin notary keeps a cut). A year later, A claims that the contract said "any member of the board" instead of "most members of the board". So we go to the blockchain and verify what the contract said, and how the two people agreed through a transaction.

What does Bitcoin add? You can't erase the hash of the document to forge any part of it, and you can't erase the signature (transaction from A->B->A).


For 'm of n transactions', you can choose to have multiple signatures required to execute a 'contract'. This can be 2 out of 3 signatures, or 10 out of 100 signatures, what ever you decide to set.

This is as good (and better) than current escrow services as it is decentralised, between the contracting parties only, and can have very fine grained conditional statements or scenarios before a 'contract' is executed.

In the example you gave, the escrow could consists of you, me, and a computer program. You sign to say you've sent it, the computer program I used to open it signs it, and I also sign it when i view it. So in this scenario, you could get paid when 2/3 parties have signed, or have a staggered payment structure of 50% when 2 have signed, then the other 50% when the remaining person has signed. This would be escrow, but escrow based on the quality of a digital good.

Hope that helps :)


A long time ago I wrote the following wiki page, following a variety of conversations with Satoshi on the topic:

https://en.bitcoin.it/wiki/Contracts

Quoting from the top:

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.

Let's take one example, 2-of-3 dispute mediation. Elsewhere in this thread, some people are saying things like "if you don't trust your escrow agent with your money, why do you trust them to make a decision". These are very different kinds of trust. Typically online payment networks bundle them together. You trust your bank and credit card company with your money (more accurately, you don't trust them, but you know ultimately the costs of their failures will be socialised), and then because they are always the middleman you end up trusting them to do dispute mediation as well.

The problem is, they often aren't very good at it. Companies like PayPal tend to see dispute mediation as a cost of business rather than their core competency. Innovation in this space is rare. PayPal's policies, for example, make selling something to someone else who is standing in front of you impossible - you must be able to prove you mailed the item and if you can't, you automatically lose the dispute and the payment will be reversed. This policy is so deeply unintuitive that there's a whole industry of scammers out there who steal things from people by exploiting it. There isn't much scope here for doing anything better: payment networks tend to have a small set of one-size-fits-all policies and you can't go to the market to find a new one.

Now consider the Bitcoin approach. For many transfers there is no possibility of dispute mediation and thus none of the overheads associated with it. This often makes sense: either you know there will be no dispute (e.g. a gift from a family member) or you have other ways to resolve disputes (e.g. salary payments). When you want dispute mediation however you can agree on a mutually satisfactory mediator.

This mediator has very limited power. Contrary to what other people here seem to think, this does matter. For example, the mediator cannot steal the money, thus they make a poor target for hackers. If the mediator is a company there is very little temptation for bad insiders. They are not accepting deposits so all the complicated regulations that are triggered by that act don't apply. There is no possibility of them lending the money in escrow out and going fractional reserve.

Really all they can do is resolve a dispute badly, but there's no profit in that. So by preventing the mediator from accessing the money, all kinds of possible failure modes are avoided. In turn this means you can access a far wider set of possible mediators. For example, if you are trying to buy an antique violin over the internet PayPal's mediation policies are less than ideal:

http://www.theguardian.com/world/2012/jan/04/paypal-buyer-de...

With Bitcoin you could ask an actual expert in antique violins to act as the mediator. They do not need to be a computer security expert, they don't need to worry about becoming a target for physical theft or extortion, they don't need to worry they might accidentally lose the keys and destroy the money. There's tons of things they don't need to worry about. They could (if it existed) just use a friendly desktop app to pick a winner in case of a dispute. That means they can spend all their time inventing precise and well designed ways to resolve any dispute, fully leveraging their domain knowledge.

That's just one example of how redistributing and carefully controlling trust relationships can result in better outcomes.


>Really all they can do is resolve a dispute badly, but there's no profit in that.

Except there is profit in that if one side has paid them to resolve the dispute badly. Which is exactly back to where you are in the current system so you haven't actually solved or improved on anything you've just changed it.


Before entering the contract, both sides ideally will agree on a mediator of disputes. There could be a marketplace for mediators. If a seller of an item does not approve the mediator the scammer buyer wants, then the transaction never takes place.

Systems that enforce lock-in of mediators will be pushed out of the market when more open systems come online.

Also, both sides put up some collateral, which both forfeit in the case of an unresolved dispute. A scammer will still pay some value into the multi-party transaction, so operations will not last long if many disputes go unresolved.


That system already exists with trusted 3rd parties and escrow systems though. You aren't improving the existing systems at all though because you still require just as much trust all you're doing is changing the currency used.

All the bitcoin escrow solutions are just a variation on "I want to use this 3rd party to ensure trust but I don't trust them enough to actually do so". It doesn't work like that though so you end up with "I want to use this 3rd party to ensure trust but I don't trust them enough to actually do so but I will end up having to".

>Also, both sides put up some collateral, which both forfeit in the case of an unresolved dispute. A scammer will still pay some value into the multi-party transaction, so operations will not last long if many disputes go unresolved.

So if I am scammed I not only lose out on the scam but I am further punished by the protocol to lose this collateral as well?


> So if I am scammed I not only lose out on the scam but I am further punished by the protocol to lose this collateral as well?

Well, that's the Bitcoin philosophy in a nutshell: they solve the problem of being screwed by third-parties by arranging the system so that when you inevitably do get screwed, you will have to sagely acknowledge that it was your own fault the whole time.

The math is perfect after all, which means the system is perfect, so by reductio ad absurdum if you get a crazy result (e.g. being screwed by a mediator) it must be due to a crazy axiom on your part (e.g. your decision to use a shitty mediator).

Now, doesn't that make you feel better? Welcome to the Jungle; you lost your money fair and square, and you have only yourself to blame.


>Systems that enforce lock-in of mediators will be pushed out of the market when more open systems come online.

Unless they're governments /s


Except there is profit in that if one side has paid them to resolve the dispute badly.

Yes, you still need some trust that the mediator is not corrupt and actually knows how to resolve disputes. You obviously can't pick someone completely at random. But, finding someone who is not corrupt and has specific domain knowledge is still easier than finding someone who is not corrupt, has specific domain knowledge AND is able to safely handle your money in escrow, which is what you'd require otherwise.

Trust isn't a black and white thing. It's a very complex and subtle topic. People can be trusted in some ways and not others.

Still, let's take a look at how we can address your concern in ways that don't involve funny attempts to arrange incentives via coin deposits and things (I was never keen on such protocols myself).

The simplest and most obvious way to avoid a corrupt mediator being paid off is to have a mediator who agrees to enforce some (mostly) predictable rules, instead of it being purely a matter of opinion. For example a mediator who offers to mediate mail order sales could publish the evidence they will use to resolve the dispute, and the act of making a payment involving them would involve effectively signing a contract with them (obviously you try and set up the software and contracts such that it's pretty standardised and all done with one or two mouse clicks). Now the mediator has to produce not just a decision but also the rationale for how they arrived at that decision. If they can't do that, the mediator will quickly gain a reputation as being unreliable and to be avoided.

This is the same approach as used by the courts. People take disputes in front of judges all the time, in the expectation that the judge is not corrupt. One reason they can reasonably expect this is that judges aren't supposed to just pull an opinion out of their ass, they are supposed to show how they are applying and interpreting the law with references to other cases where there is ambiguity, or at least an understandable rationale for the decision when it genuinely strays into new territory.

Another way to reduce the trust needed in mediators is to use machines instead of people. This is the "oracle" concept described in the wiki page. The idea here is that a machine uses trusted computing to perform a remote attestation of the software it's running. For example using Intel TXT / SGX, or AMD SKINIT. This lets you know how a dispute will be mediated with the precision of computer code. It can be a good approach if a contract or dispute is precise and measurable enough to be decided by programmatically, although again, these techniques are quite advanced and nobody is using them today.


> If they can't do that, the mediator will quickly gain a reputation as being unreliable and to be avoided.

I'm not saying you are a libertarian, but this is an argument that libertarians use a lot. I don't buy it. Look at the companies, organizations, and people out there today who deserve bad reputations, but don't have them. Ask most random buyers what they think of PayPal, even, and they won't realize there is anything wrong with it. Hell, a surprising chunk of sellers don't even have a problem with PayPal.


I would say that PayPal has a very bad reputation, but there is not much competition so people have to deal with them anyway.


>is able to safely handle your money in escrow, which is what you'd require otherwise

Except you're not since no one tries to be their own bank they have their bank to safely handle the money for them. As an escrow agent I have Alice send money to me and I choose to send it to Bob or back to Alice but at no point in that am I typically holding actual cash. They are funds in my bank account which I trust to manage funds.

>For example a mediator who offers to mediate mail order sales could publish the evidence they will use to resolve the dispute, and the act of making a payment involving them would involve effectively signing a contract with them (obviously you try and set up the software and contracts such that it's pretty standardised and all done with one or two mouse clicks). Now the mediator has to produce not just a decision but also the rationale for how they arrived at that decision. If they can't do that, the mediator will quickly gain a reputation as being unreliable and to be avoided.

This doesn't remove the problem of a malicious 3rd party though. I could say "I arrived at the decision by inspecting the box from Alice and seeing the product before sending it to Bob". I have my process, I inspect the box and make sure the products in it match the order. But I am still capable of lying to you. Bitcoin still hasn't solved that problem and hasn't actually improved on the existing trust protocol.

>these techniques are quite advanced and nobody is using them today.

There is also an extremely limited range of contracts which could be solved by this type of system and none of them that I can think of that people do today.


> Except you're not since no one tries to be their own bank they have their bank to safely handle the money for them.

We're talking about Bitcoin here :)


Companies like PayPal tend to see dispute mediation as a cost of business rather than their core competency. Innovation in this space is rare.

PayPal started as a security company, back when they were above the bike shop on University Avenue in Palo Alto. Their original business was selling crypto tokens. They wanted to store money on PDAs.

Then they discovered that business model was going nowhere, and went to a more centralized system for sending money. The big problem remained security. Most of the effort goes into preventing theft and fraud, not merely sending the money.


Mike's great 2012 talk [1].

Unfortunately 2 years later, we're not much further in those developments. Bitcoin has severe limitations, also because it has now a legacy to support. New projects can start with a fresh design. So far we've only seen very few new approaches. While many Bitcoiners realize the imperfections of the system, very few actually think there could be something better.

[1] https://www.youtube.com/watch?v=mD4L7xDNCmA


I know a simple upvote should suffice but that's a really informative answer, thanks a lot for typing it up, I appreciate it.


>I will transfer you a file, upon me sending the file your funds will be released to me

In this case you would still depend on either a 3rd party escrow person to make the ultimate decision or trust between the two parties.

Bitcoin doesn't actually solve the problem of needing trust it does solve the problem of needing to trust your escrow agent with your money but then again if you don't trust your escrow agent with your money why do you trust them to make a fair decision.


Thank you, I asked your sibling comment this followup would be interested in your response as well:

So I'm still confused here. What new kind of contracts could I build using the blockchain? What existing contracts are made easier because of the blockchain?


An example from my understanding: I want to buy something off an online merchant. I send them the payment, but I make it a multisig payment that needs to be authorised by their signature plus the signature of the delivery company. I expect the delivery company only to authorise the payment with their signature once they have confirmed successful delivery.

This way I can authorise payment without entrusting the funds to a third party. If the delivery company doesn't authorise the payment, the money is still immediately available to me.


>If the delivery company doesn't authorise the payment, the money is still immediately available to me.

That's not how I thought multisig works. I thought the delivery company would have to authorize giving the money back to you.


Unless you have the delivery company inspect every package this doesn't actually solve the "Sent a brick in a box" problem.


No, but it does help the more common "whoops, we didn't actually ship your order. Are you sure you actually bought something from us? Prove that you did / our systems are perfect."

Sure, it'll get resolved eventually...


Then you send them the receipt from when you purchased something or if you paid with a credit card you tell them you're going to submit a charge back.

This doesn't solve a real problem which is the problem with a lot of things bitcoin tries to solve. They are things that aren't real problems or they are things that are already solved just as well.


Actually I disagree. Why should I be forced to do the footwork, taking valuable time away from my family, to dig up receipts so I can convince a vendor (who may or may not respond) to give me my money back? Or the bank?

This kind of issue almost always requires a third party reputation broken to step in, and today it is one of the reasons I like shopping on Amazon. Complain to them, or file a rating with 1 star, and you certainly get a vendor's attention. Commerce just shouldn't be this difficult. Buying products online should be as easy and as trustworthy as buying products over the counter. I see Bitcoin as that mechanism. We aren't going to all trust Amazon for ever.


>Why should I be forced to do the footwork, taking valuable time away from my family, to dig up receipts so I can convince a vendor (who may or may not respond) to give me my money back? Or the bank?

Because you're the one making the claim. Making a charge back takes roughly 2 seconds. And if you've bought something online you should have an email receipt you can find just as quickly.

You've spent more time away from your family replying to me telling me how important your time with them is than you would spend making a chargeback.

>This kind of issue almost always requires a third party reputation broken to step in

Right and they already exist so bitcoin doesn't actually improve the process it just reimplements it.

>Buying products online should be as easy and as trustworthy as buying products over the counter. I see Bitcoin as that mechanism.

But bitcoin actually makes it worse for consumers. Credit cards have really strong consumer protection methods. Bitcoin has none unless you toss on 3rd party escrow in which case it is just trying to patch over an inherit problem. Bitcoin is digital cash. The reason cash works well is because almost every time you use it you are in person with the merchant and can verify delivery immediately. Once you remove that it is near worthless.


By what process that you have ever done does a chargeback take 2 seconds, or anything less than 60 seconds? At best it would be: * Meticulously file your receipt for purchase. * Log on to bank/credit card web site * Find the correct process for a chargeback * File the required form, uploading the receipt in the process.

This is at least 60 seconds. At best. And normally, much longer, especially if you add up the time you spend meticulously filing all receipts.

I don't think it is asking too much that a third party (like FedEx) engage in transaction assurance for Internet purchases. They can get a slice of the pie (they do anyway.)


>By what process that you have ever done does a chargeback take 2 seconds

http://en.wikipedia.org/wiki/Hyperbole

>Meticulously file your receipt for purchase.

I use gmail and type in the domain of the company and I have my receipt. If you can't do that you should upgrade your email provider.


No new contracts just new variations on old contracts. I don't really see much value ad myself but I'm generally on the skeptical side of the bitcoin discussion anyhow so don't just take my word on it.


Lawyers and escrow agents and other human intermediaries take fees on transactions, usually proportional to the downside risk of a "bad" transaction (completed, but one party desires recourse for something).

If the risk is that well defined, then the cost of escrow seems wasteful if you could just automate the upside/downside in the Blockchain (not necessarily well defined yet). I don't think the package delivery service is even close to an interesting example, so I don't know why anyone would choose it. Packages need to be delivered. Automated contracts can only eliminate insurance middle-men, not physical logistics.

BTC advocates should focus on useful ways to simplify existing contracts (while paying very close attention to the profit structure of underwriting).


>If the risk is that well defined, then the cost of escrow seems wasteful if you could just automate the upside/downside in the Blockchain

You don't pay for them to calculate the risk though you pay for them to resolve the issue when there is a dispute. So using bitcoin wouldn't actually lower that cost/allow you to automate away any of that.

>Automated contracts can only eliminate insurance middle-men

The middle-men in most contracts are there for assurance. Bitcoin doesn't provide that even with m-of-n.


The big value is not having to completely trust the person holding the money. As of right now if you do escrow you transfer money to a third party, who has the option of taking it and running.

With a correctly setup transaction, bitcoins can be held in escrow that require 2 of 3 people to approve moving it. This means that you/seller, you/escrow, or seller/escrow are the only 3 combos to get the bitcoins out. There's no way for the escrow agent to steal the money.


If you don't trust the person to hold your money why do you trust them to decide where your money goes?

>There's no way for the escrow agent to steal the money.

If you're worried about an escrow agent stealing your money if they had the chance then they really really should not be your escrow agent.


Late commenting here, but smart contracts haven't been mentioned and they are better than existing contracts because they enforce themselves. Here's an article that explains well and also links to Szabo's original.

http://bitcoinmagazine.com/10468/daos-scary-part-1-self-enfo...


"It then sends the 80-byte block header to its mining hardware (an ASIC) along with a target threshold (difficulty setting)."

I've always wondered, would it be possible to make the difficulty setting dynamically determined based on some econometric derived from the bitcoin chain? (such as if you see the economies velocity slowing down, perhaps you lower the threshold) or the opposite.

If it was, that may be one way to stabilize the prices, at least of the currency itself.


No one has figured out a way to do this without outside information. Some blockchains include price feeds from the outside world that let algorithms keep prices relatively stable. Others use votes by currency holders to adjust the money supply both directly and indirectly (via interest rates) like a central bank would. Both strategies have led to cryptocurrencies that track the price of the dollar.


Can you give examples of cryptocurrencies that track the price of the dollar?


The two I'm familiar with are BitShares and NuBits. BitShares uses contracts-for-difference and price feeds to create stable "BitAssets", like BitUSD, BitCNY, and BitGold. NuBits is a central bank on a blockchain, and it uses its control of the monetary base and interest rates to peg its value to the dollar.

Disclaimer: I own some BitShares. I won't answer more questions here to keep things on topic, so email those to me.


The purpose of difficulty is to keep the block time around 10 minutes; if you use it to perform some other function then you'd end up with unpredictable block times. I think setting the block reward to a function of difficulty would stabilize a cryptocurrency[1], but that very stability would probably lead to failure if the resulting exchange rate and difficulty are very low.

[1] https://blog.ethereum.org/2014/11/11/search-stable-cryptocur...


If you were going to go that route, it would make far more sense to play with the block reward amounts (because they're kept too low to do anything).

But, the bitcoin people have philosophical reasons to avoid that.


I think it's possible to do that, though that wouldn't really be Bitcoin anymore. If the difficulty were fluctuating with the same amount of computing power out there, the block time would be changing a lot.

This would make for different amounts of bitcoins being released rather than the (fairly) predictable current schedule.


"This would make for different amounts of bitcoins being released rather than the (fairly) predictable current schedule."

This is kind of the point. A predictable release of new bitcoins into the economy has no basis in good economics.


The main point of blocks is not to release bitcoins -- it's to timestamp and "lock in" blocks of transactions. You want to vary the reward or fees of you do anything here :)


Mastering Bitcoin is another resource that explains the bitcoin protocol in detail.

http://chimera.labs.oreilly.com/books/1234000001802/index.ht...

It is available to read online for free.


... on github.


Is this a new thing? I haven't seen a comprehensive list like this for bitcoin tech specs before, and I do follow bitcoin waaaaaay too much.

Seems like this will be a very useful thing with more people starting to use bitcoin!


I think it's been around for a while, but has been updated/revamped significantly since the last time I saw it.


I'm curious how the whole system will scale as the number of transactions increase. Does it take longer and longer for nodes to verify transactions as the blockchain grows?


There is one transaction block issued every 10 minutes. It can be no larger than 1 MB in size. Miners typically prioritise transactions with higher transaction fees. When block space becomes scarce, transactions with low or no fee will have to wait in line longer.

The current plan seems to be to start increasing the block size limit by 50% per year in order to allow higher transaction volume. Block size limit has always been a contentious issue.


>There is one transaction block issued every 10 minutes.

Just to clarify for anyone new to bitcoin... blocks aren't "issued" every 10 minutes exactly. On average there is a new block found every 10 minutes (or so).


There are various ideas for the future. See this https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 for example.


Actually the blockchain's size is now over 20GB. Almost a year ago I remember it about 13GB!


The slow growth at the moment is because there is almost no transaction volume. If we scale bitcoin up to Visas transaction levels for 2013 we're looking at 60gigs per day in growth.


I was just reading this. Excellent resource, probably the first time I feel I am starting to grasp how all the different pieces of Bitcoin fit together.

There's also: https://bitcoin.org/en/developer-reference - though I'm not quite sure how the two relate.


[deleted]


There are a few ways around this, depending on the use.

The owner of a wallet only cares about transactions relevant to the wallet. From the beginning, Bitcoin has had a method called Simplified Payment Verification (SPV) that uses block headers and only those transactions needed for the wallet to work:

https://bitcoin.org/en/developer-guide#simplified-payment-ve...

This is also described in Satoshi's original white paper:

https://bitcoin.org/bitcoin.pdf

This takes advantage of the fact that a block header uses the Merkle root for the transaction set:

https://www.youtube.com/watch?v=gUwXCt1qkBU

For nodes and miners, efforts to "prune" the block chain have been underway for some time:

https://en.bitcoin.it/wiki/Scalability#Storage


Does anyone here know how the http://ai-coin.org site ties into this info from bitcoin.org ?


Here's another helpful resource:

http://enetium.com/resources/Bitcoin.pdf




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: