Ah, we're nerds. You know many nerds there are in the world? If they take us out there's a million more.

Awesome, I can't wait to have "native" escrow support without a third party.

One question regarding the trust example:


Hmm, but you would get your money back no matter what, so if you wanted you could thoroughly ruin an identity and just start over with a new one once your deposit expires and is returned, correct?

It's true that it would incur capital costs for scammers as their money is tied up in this kind of escrow, but the costs for a scammer would be the same as for a legitimate user, no?

How does this compare to the following system:

- Global trust rating based on total fees paid from an address, perhaps weighted by age as well.
- Trust rating can be raised by sending a high-fee zero output transaction - think of it as buying trust from miners.
- There would have to be some place to lodge complaints against an address. Could be a website or a custom blockchain (that shares work with Bitcoin of course).

The result should be that a legitimate user can spend say 10 BTC on his trust rating once and use it for decades (assuming he doesn't get negative reviews). Whereas a scammer can do the same, but negative reviews and complaints lodged against the address will quickly make his 10 BTC investment void, requiring him to get another identity and spend another 10 BTC.

(Sorry if this is off-topic, it's not an example for a Bitcoin contract strictly speaking.)

I think I can get used to this real name thing. 


You've explained Bitcoin with superhuman patience to about a bajillion people on IRC (including myself), so firstly hat off to you and secondly you are totally (hard-)core in my book. <3 

I've noticed today that two of the most common criticisms of Bitcoin make for a rather nice juxtaposition when you put them next to each other:

Criticism 1: Bitcoin is not backed by anything. Right now the value is going up, but eventually people will realize that they have no value. Then, people will start selling them. Once the price starts dropping, more people will sell, a panic will set in causing an INFLATIONARY DEATH SPIRAL. (Example)

Criticism 2: Bitcoin's supply eventually stops growing, this will cause hoarding. The more people hoard, the more the price will go up, making hoarding even more attractive. The result is a DEFLATIONARY DEATH SPIRAL. (Example)

I would argue that inflationary forces would stop a deflationary death spiral and deflationary forces would stop an inflationary one.

If Bitcoin value goes through the roof, wouldn't I want to *sell* some coins in order to realize my profits? If Bitcoin value goes through the floor, wouldn't I want to *buy* some coins cheaply in case the price recovers?

It's supply and demand - sure it can be volatile! There can certainly be a correction either way, even a dramatic one. And you're free to argue that this is reason enough to prefer money that has a central bank regulating supply.

But there is a difference between volatility and predicting Bitcoin's inevitable doom. Neither deflation nor inflation would *end* Bitcoin.

Some points I'd like to add to the discussion:

Fees are always paid by the recipient (even though it might seem the other way around)

The only party directly interested in the success of the transfer is the recipient. The sender is only willing to pay a fee on behalf of the recipient. The sender gains nothing from coins disappearing from his wallet, however the recipient needs the transfer to be successful in order to take definitive custody of the coins transferred.

Even in cases where it seems like the sender pays the fee voluntarily he's still only acting on behalf of the recipient. So if I send money to my grandma and she says "don't include a fee," but I do, it's because I'm acting altruistically in the interest of my grandma.

Therefore it provides a clearer picture to look at transaction costs from the perspective of the recipient.

Cost function

Gavin's formula captures the normal situation perfectly. But [mike] correctly points out that there is another cost, currently hidden (because it is very, very near zero at the moment).

So extending Gavin's formula with the risks, we get:

cost = f(txn, B, P) + txamount * (1-P) + txamount * P_A

P_A ... Probability of a successful attempt by s.b. to overtake the block chain for the purpose of rejecting/delaying at least this transaction.

Or, in other words, the total cost of a transaction is
- the fee paid, plus
- the risk of it not being included because the fee is too low, plus
- the risk of it not being included because the block chain has been overtaken.

That means that if f() is continuous we can actually find an optimal P for any given txn and B. (In the formulas I use myself, I actually use t for time, however B is Bitcoin's representation of time, so it's just a different unit essentially.)

At the moment P_A is very, very small. This is because seigniorage provides an added incentive to mine, leading to much, much higher hash rates.

As minting is phased out, the hashing rate will come down, and P_A will rise. At some point it will start to be noticeable either as a risk by observant users or because an attack has actually taken place.

In terms of the P2P client... For now it seems reasonable to assume that P_A is for all intents and purposes zero. And if we can indeed figure out a good approximation function for f(), we should be able to calculate the recommended fee based solely on txn and B. Note that an optimal P will likely be fairly close to 1, because we're counting the tx not getting confirmed at the requested time as a total loss (which is an exaggeration). But it allows us to ask the user "How fast do you want this to get confirmed?" and it will almost always get confirmed at least by that time.

In terms of future solutions... I expect insurance providers to crop up very soon. Even with P_A = 0, they can still provide a useful service by offering t < 10min, something the P2P client can't offer. As soon as P_A starts rising that will simply become another selling point for them.


Disclaimer: I actually suck at math, so feel free to point out any errors in my formulas/reasoning.

A mining cartel wouldn't last very long. Miners inside the cartel would have the temptation to secretly mine a little on the side with a lower minimum fee in order to get some extra profits. Miners outside the cartel will also be more profitable than miners inside the cartel, because they get the same amount of money from the expensive transactions plus additional money from lower fee transactions.



A rule would be great if we had any basis for deciding one. You will have to predict:

- Fixed/variable costs of mining
- Economies of scale of mining
- Size of the Bitcoin economy
- Scale of ideological threats to Bitcoin
- Scale of criminal threats to Bitcoin
- Price elasticity on consumer side for fast confirmations

If you get one of these wrong by say a factor of ten, fees will too high or too low by a factor of ten. Even if you get everything right for the year 2016, you might still be wrong by a factor of ten for the year 2021.

Sure you can say that developers could get together every year to update the rule. But then you've created a political body governing the prices for Bitcoin.

Quick sidenote: Note that if your rule creates fees that are too low for a long period of time, the whole merchants buying insurance, which raises prices mechanism will still kick in. So you wouldn't do very much damage, only introduce a bit of uncertainly about how/when the rule is going to be changed. It's only when you accidentally set it too high that you cause a massive amount of wasted resources including extra CO2 emissions, wasted electricity and mining hardware.



Nobody would be able to impose any rules on the system. The only person who wants to impose a rule is you. I'm arguing against instituting a rule.

Insurance companies would have no influence on mining fees and neither would miners. The only factor influencing mining fees would be how much users (particularly merchants) are willing to pay to make sure their transactions get confirmed. If the network got under attack, they would be willing to pay more. If everything was running smoothly, they would be willing to pay less. That way, the hashing rate would auto-regulate depending on the actual real-life cost that attacks incur upon the Bitcoin economy.

We know there is a trivial solution. It's to have developers decide on limits and rules to estimate the correct level of security.

This thread is about pointing out that there is also a null solution. In other words, we as developers don't have to do anything. The market will negotiate the optimal level of security.

We still have to worry about miners creating huge blocks, but this is less of a problem because there is no economic incentive to create unnecessarily large blocks (see [mike]'s proposal for sharing Bitcoin's work if you need to timestamp large amounts of data for your custom application.) So you only need to prevent individual "troll" miners from blowing up the block chain to unreasonable size by themselves. For that you could indeed use some kind of limit that grows with the average of the last 2016 blocks like the difficulty does.

Again, if the block size limit only needs to protect against spam rather than regulate network security, what that means is it can be much, much higher, much less deliberately chosen and everything still works fine.

Perhaps the most important point is to not to try and prevent double spends. Double spends are fine, they are simply a cost that comes from the imperfection of the real world. If we try and aim for a hash rate that prevents all double spends, it will be far, far more costly than paying for the double spends that occur at the margins. More importantly, if we aim for a higher hash rate, we get no feedback about changing conditions. So instead of the hash rate adapting to slightly increasing or decreasing rates of double spend attacks, we would have absolutely no signals to base our decisions on.

Just read through the whole thing. Brilliant design, being able to share work without bogging down Bitcoin is awesome and the use of the coinbase is very elegant, it's practically begging to be used for this.

I believe the section "Scaling up" should be a normal part of the standard. It just makes sense to include that from the start rather than having two methods (list of hashes vs merkle) floating around later.


What do you mean by "incorrect"? The custom network would have its own rules on what constitutes a valid block or transaction. For example a DNS system would only allow registration of previously unregistered domains. This can be enforced by the clients of the custom network. The block chain's job is only to solve conflicts between two blocks that are both independently valid. The older block takes precedence over the younger block.

So your attacker could indeed include a hash of an invalid block for the custom network, but it would be rejected by the custom client if it is invalid or conflicts with a block that is referenced in an older Bitcoin block.



A miner would run both the normal Bitcoin client as well as the client for the custom network. They would ask the custom client to construct a block, get its hash and send that to the mining Bitcoin client for inclusion in the coinbase using a new RPC command "setextrahashes".



Miners would opt in to a specific custom network and run the software for that network themselves. In other words they know the blocks are trusted, because they have generated them themselves. As for the "transactions" in the blocks, such as name registrations/transfers for a DNS system, they'd have to be validated just like Bitcoin transactions are validated before miners include them.



The custom network could have whatever architecture you want. Most likely it would be a P2P architecture in order to avoid a SPOF. As for spam - the custom network would have similar antispam measures as Bitcoin does, [mike] included a concept to pay for resources used on the custom network with Bitcoins. The miners that are connected to the custom network would have to bear the burden of receiving messages from it, they would likely require some sort of compensation for that service. Otherwise you could not motivate miners to run your custom network.

Non-mining nodes in the custom network would likely impose limits and restrictions on what it relays, again just like any P2P network.

The beauty of [mike]'s proposal is that he doesn't make any assumptions about the custom network. As long as it produces a hash it can interface with Bitcoin.


Not at all:


The blocks in [mike]'s example contain an arbitrary number of transactions.



That's up to the designer of the custom chain. They could either include all their data in their blocks (as in the example) or - more likely - include a merkle root like Bitcoin does.


Now I have a question for [mike]: The custom network would only get a block whenever a sympathetic miner makes a block for Bitcoin. So the average time for a confirmation would be 10 minutes divided by the percentage of miners supporting the custom network, correct?

Here is an idea: Could the custom network accept blocks of a lower difficulty? So basically you have the current Bitcoin difficulty target and then a lower difficulty target for the custom network. The Bitcoin miner would sometimes generate Bitcoin blocks that are completely valid as Bitcoin blocks, except they don't meet the full difficulty target required for Bitcoin. But they do meet the lower target for the custom network, so the miner would publish them there. That would allow the custom network to have any difficulty it wants and any rate of confirmations it wants while still sharing work with Bitcoin.

I was recently doing the business plan for a double-spend insurance firm. The firm would charge merchants who need protection from double spends and can't wait for lots of blocks a fee and in exchange would guarantee transactions. It's rates would be tiered based on delay, so there would be a fee for 2-sec guarantee, 5-sec guarantee, 10-sec guarantee, etc.

The costs for such a firm would depend heavily on the number of double spends, so it would seek to minimize them. The more double spends happen, the more money it would be willing to spend on double-spend defense. One of the measures it would do is to pay miners for guaranteed inclusion in their blocks. If double spends happen more, it would pay more miners more money, if double spends happen less, it would pay less miners less money.

Note that such a company would also watch very closely for network takeovers, as it would have to carry potentially significant costs if somebody takes over the network and starts double spending or rejecting transactions.

I think this is the missing feedback loop that connects mining income with network security.

Yep, I'll try and record the talk & maybe the questions section. The discussion won't be recorded, sorry. It would just put too much pressure on everybody to have every off-hand comment preserved for eternity.

Happy to announce another Bitcoin-related event in Zurich this month, organized by the fine folks over at Netzzunft.

When? May 25th, 2010 at 19:00
Where? KPMG, Badenerstrasse 172, 8004 Zürich, Switzerland

I've been invited to give an introductory talk about Bitcoin, but I'm especially excited about the open discussion that is scheduled to take place afterwards. We'll look at the political, economic and privacy implications of a decentralized cryptocurrency and I'm looking forward to many interesting questions being raised.

My talk will be in English, but the discussion afterwards will likely be in German - depending on the preferences of the other attendees.

If you're interested, you can check out the event page (in German) and register if you're planning to attend.

Thanks to Hannes Gassert and Luzius Meisser for the invitation and Urs Bucher for providing the venue!

Good point. I've updated the spec:

https://github.com/bitcoinjs/bitcoinjs.github.com/commit/bdf85186f8e43b4875103d7f09cef0a068f8e298

I've just looked into it. Normally, npm link should take care of compiling the native parts. But with npm 1.0 it doesn't, because sudo npm link prints this error (but continues anyway):


Looking at the npm source code - the reason for the problem seems to be that the folder name when you clone it from git (node-bitcoin-p2p) does not have the same name as our npm package (bitcoin-p2p). NPM checks for that and if it doesn't match it considers it "unsafe" to run the build script. Or something like that.

Edit: Nothing to do with the name, probably I'm just doing something wrong. I've opened an issue at npm to get some help.

I'm working on an updated README and will try to figure out a way to get npm link to work properly.

Edit2: Couldn't find a good solution using npm, so I've added an installation step to just call node-waf manually. That fixes it.

I just uploaded the first version of the Wallet API specs:

http://bitcoinjs.org/specs/wallet/1.0/draft/wallet-api.html

Please have a look and we'd be happy to get some comments and criticism.

Yep, the transactions are real:

http://blockexplorer.com/address/1FhXuUHaww1qkn2Mb6BURZgR3T9xoyjQtz

The 0.1 BTC transaction got confirmed seven hours later. I haven't done any small fee-less transaction lately, but around the time when we recorded the video I had quite a few cases where that type of tx took a long time to confirm.

For example this is a 0.01 BTC fee-less transaction, sent with the official client (0.3.21) that took 32.5 hours to confirm:

http://blockexplorer.com/tx/0c1a398a2534c79639fcf9416b26aad3e5f5aa51a5907d79f2f5ff4fe927a5e9
Sent: 5/4/2011 01:59
Confirmed: 5/5/2011 10:24

Shouldn't be too hard. In the case of Firefox, you'd create a new extension, include bitcoinjs-gui as a subfolder and add a button that opens a tab with it using the correct chrome:// URL. You'd probably make some changes like add an options panel where people can choose a different exit node and use some other API than localStorage for storing the data.

I'm dealing with a lot of block chain downloads and as such I've been thinking about how to speed it up. It seems that the official client validates all transactions, even ones that are deep in the block chain.

The hash of any given block guarantees the integrity of every previous block and the merkle tree guarantees the integrity of all transactions in those blocks. So couldn't we skip validation (other than the hashes/merkle) for everything up to the last checkpoint?

Thanks for the heads-up. Re-org isn't working yet - there was a split yesterday and node-bitcoin-p2p threw an exception. I doubt I'll be able to get it working reliably until we have a proper test harness that can simulate a split.



The C++ code is the backbone of Bitcoin and will remain so for years to come. I think clients in other languages will fill certain niches as well as providing a testbed for new features.



We're still re-packaging and uploading the code. Here's the status:

Edit: Updated the list below. Everything is uploaded now, but probably not enough documentation to get it running especially given how buggy it still is.

node-bitcoin-p2p: online
node-bitcoin-explorer: online, cool little demo app, start here if you want to get your feet wet
bitcoinjs-lib: online, but no docs and pretty rough around the edges
bitcoinjs-gui: online, no docs, hardcoded settings, ...
node-bitcoin-exit: online, no docs
node-bitcoin-wallet: in development

Hey everybody,

I just uploaded a little screencast as a preview of our upcoming code dump.

It's basically an implementation of a heavy-server, lightweight-client in JavaScript (Node.js on the server and jQuery in the client). Highlights:

- The server does NOT use the JSON-RPC API. The server uses node-bitcoin-p2p to connect directly to the Bitcoin network. Right now we still connect to a single trusted node because node-bitcoin-p2p lacks a full script interpreter for proper tx verification, but we're hoping to add that at some point.

- The server does NOT see your private keys. Transaction signing is done on the client side. Of course in a webapp the server can just serve you code that has you send it your private keys. But firstly, it still provides some protection against hackers, because the client HTML/JS can be hosted on a very secure static HTTP server, whereas all the dynamic node.js stuff is on a different machine. Secondly, future clients will be open-source desktop or mobile clients where the same checks apply as with the official client. (People can look at the code and make sure it doesn't send the private keys anywhere.)

Right now Webcoin is still pretty buggy, but we're planning to release the rest of the code and an official beta deployment very soon.

You can watch the video here:
http://www.youtube.com/watch?v=KTmFwnIRG9c
(Sorry for audio sync issues and poor resolution - next screencast will be better in those respects. Also, you can download it in 1280x800 here.)

Follow our progress here:
http://twitter.com/bitcoinjs
http://www.bitcoinjs.org/
http://github.com/bitcoinjs

Tip here:
13SjwsodtKsAhQwPx14s7aqKpnooeep4i5

Contact us here:
bitcoinjs (at-sign) justmoon.net

And I'm happy to answer any questions here in the thread. Documentation obviously will be forthcoming, but based on your comments here I'll be able to get a sense what you guys are most interested in and therefore what we should focus on.

I've also got major thanks to give out to these fine folks:

- [mike] for BitcoinJ - much of our code is just a port of this excellent library
- Andrew Schaaf of Bitcoin Labs for reviewing the API and letting us use some of his code
- Gavin Andresen for reviewing the API documentation and providing feedback
- booo from github for JSLint'ing and cleaning up a lot of node-bitcoin-p2p
- jb55 from github for debugging and pull requests

Massive thanks to the guys at Trucoin who have supported this project every step of the way. I'd encourage everybody to keep a close eye on them, they are working on some badass stuff! They've also agreed to provide the funding for a reference Webcoin installation.

I want to point out that this is a preview, there are still plenty of bugs cropping up. We'll post a link to a demo installation once we get it a little bit more stable.

Cheers,

Stefan  

Yes, mostly. Note that the rate is a little bit flexible: If more miners join or if some miners leave there can be more or less blocks for a time. Also block generation is random of course, so it fluctuates a bit as well. But every 2016 blocks the network looks at the last 2016 blocks and adjusts the difficulty to try and maintain the desired rate of coin creation.


Yep, exactly.