It looks like the article will be restored. But one point that keeps being raised is that many of the article's references are to pages in this forum. If anyone can replace a forum reference with a reference to a page that has no perceived conflict of interest, that would help.

I thought the idea of safe mode was to protect sites like MtGox from losing everyone's entire balances in the event of a catastrophic exploit. Safe mode shuts down their transaction processing until they can work out what's going on, and upgrade/patch if necessary.

For the sake of appearances, it's better not to have safe mode turned on by default (because "remote tampering" of one's software is not popular with many people). But why not have safe mode disabled by default, and provide an "-enablesafemode" switch for those who want it?

Previous discussion was here:
Development of alert system
and here:
Version 0.3.11 with upgrade alerts

For that purpose I would recommend Stefan Molyneux's "Everyday Anarchy" which is written in very readable modern language. It takes a while to get going, but it's a compelling read:
http://www.freedomainradio.com/FreeBooks/EverydayAnarchy.aspx

If you supply the user-password on the command line, you won't get asked for it again:


That's not ideal from a security point of view, perhaps someone will suggest a better way.


You can use bitcoin instead of bitcoind, provided you are using a recent version of Bitcoin (0.3.15 or later) and the latest version of poclbm. This gives you the GUI, plus OpenCL mining.

I think ptd is referring to the way the contents of the "Your bitcoin address" field changes automatically after you receive on the old address.

A waste of time. If you want to do something really useful for the code, write a test suite for it.

It's easy to complain about code. But unless a person can show that they did something better, they have no moral authority to complain.

That script is just something I submitted for comments, but anyone can use all or part of it if they want. I'm working on an animation using that script, but making slow progress.

The script has certainly not been agreed by any kind of consensus, Also be aware that the script doesn't meet the requirments of all of those who have pledged donations, since different donors impose different conditions, so an animation based on it won't collect the whole pot.

It's here. The simpler DomainChain proposal is here.

I bet you're also shocked by what restaurant kitchens look like, and by what goes into sausages.

It's a nod to the German government, re holocaust denial.

Let's not spread FUD. A text payload followed by OP_DROP is absolutely secure.


A new user running the standard bitcoin App won't see anything different from what they see now.

This is how I use the terms when I'm not being sloppy. I read the idea somewhere else in this forum and it made sense.

If you say "no" after you've seen how this runs on the test network, I will totally respect that and won't generate domain registrations on the live network.

Bitcoin is your bird, and if you don't want it to soar as high as it can, that's OK.

But even if the domain name stuff is on a separate chain, there is still going to be a Bitcoin transaction for every DNS registration. So having two chains would cause no reduction in the number of Bitcoin transactions, just 40 or 50 bytes reduction in the size of the transactions in the Bitcoin chain.

Got you now. Yes, keeping two chains synchronised is fraught with difficulty.

I have fleshed out the DomainChain spec quite a bit more:
http://domainchain.org/wiki/doku.php?id=start


Yep, that's in the spec. But it's only useful if you know that someone is going to serve them. For example, the owner of some.domain might announce that they will serve any subdomain that people register of the form something.some.domain

No-one has made a proof-of-concept, but we think that all we need is a program that trawls through the block chain, extracts the registration details, and writes them out in bind's data format. No plugin or hacks should be needed.

That doesn't really reflect how it works. If there is a chain split, eventually the network will settle on one of the chains. The generator that mined the block in the "winning" chain gets the transaction fee.

There is no "irreversible" payment to the generator in the "losing" chain. Well, in a sense it is irreversible but as they can only spend it in the losing chain it's not much use to them.

If it's useful to the sender, the recipient, and the miner, then it's not junk.

[edit: nevermind this post. I haven't been able to express my idea clearly here.]

Suppose you have a separate block chain for domain name registrations, and you want people to pay in Bitcoins.

To register foo.domain, the buyer pays 10 BTC using the standard Bitcoin system, then goes to the other system to claim their domain name. But how to know that they paid? They can prove cryptographically that the 10 BTC payment came from them, but they can't prove that the payment was for a domain name. They might be using that same payment to claim services from several separate sites.

So obviously Bitcoin needs a way to associate a transaction ID with a Bitcoin payment. If you can include a transaction ID (of say 64 characters), then you may as well just use the Domain Name details as the transaction ID (because it's short enough), in which case there's no need for a separate domain name registration chain.

A domain registration is just a Bitcoin Payment to an unspecified miner, with a transaction ID that happens to be meaningful.