I would pay a modest premium for high purity stolen coins of notable lineage in small quantities.  Like I'd probably be willing to pay 5 BTC for 1 BTC that was stolen in the latest incident, if it were 100% pure and had only a small number of intermediate wallets between, for example, bitcoinica's wallet and my own.  I suspect that plenty of other people would be willing to start a collection of famous coins too, if they could only just figure out how.

Internet lawyering aside, a real court won't really care what bitcoin is, and will probably go very far out of their way to avoid setting any sort of precedent if they can possibly avoid it.

Instead, they'll rely on centuries and centuries of precedents from other cases involving intangible "stuff".  Regardless of what bitcoin may be, we still have a property interest in our balances.  The courts have a long, long, long history of protecting property interests in intangible stuff without much regard for what the stuff is.

That's not how it works.  Sorry.

It should be fairly easy to recreate P2SH addresses as long as the keys aren't lost.  Assuming a standard for key ordering, all else that is needed is an identifier that can be negotiated when the keys are created.  Sequence numbers or hashes should be enough to synchronize the two keysets.

Basically, if everyone is using deterministic key sequences, they can all store the seed and when they need key N, they just make key N.  But, if anyone is using random keys, then they need to store the key indexed by (the hash of or the sequence of) at least one of the other keys.

I used to use the hub patch and regularly had over 100 connections.  I haven't bothered with that patch in a while, and now my node that accepts incoming connections rarely goes over 20 or so.  It restarts every night, so it doesn't have time for a slow build up.

No dash.

But it doesn't have to be that way.  The service doesn't have the ability to spend your money, and if you set things up right, they can't prevent you from spending it either.

Think of a script in a transaction that can be redeemed either with Key C, or with the pair (Key A + Key B).  This is usually called "(A and B) or C".

You generate a bunch of these offline.  Key C is protected somehow and is never in a computer connected to a network, like printed on paper and stuffed in a safe.  Key B goes to the service (or comes from the service, either way).  Key A goes in your wallet.dat.

So, if someone breaks your computer and gets Key A, they can only spend small amounts, depending on the policy you've established with the service, and only until you realize that someone else has your keys and you tell the service to not sign anything any more.

If someone breaks the service and gets Key B, or if the service isn't trustworthy, or if the service is coerced by the government, they can't spend your money because Key B isn't sufficient.  They can stop you from spending it, at least until you go to your safe and fetch Key C, but that would instantly show that they have been compromised.

Yeah, probably unnecessary.  But it takes no more effort to do.

NFC is a communication system.  Essentially very short range radio.  Actually, it is an extension of RFID, from what I can tell.  My guess is that someone's patents were expiring, so they came to the amazing revelation that two intelligent devices may want to communicate with each other, rather than always assuming that the peer was an unpowered tag.

And since it looks like something very close to 100% of all NFC communication today is along the lines of "Here is my credit card number!", it doesn't seem productive to get upset that your phone is identifying itself at the same time.

I think that the universe of bitcoin users can be divided into two groups: those that want multisignature capabilities and know it, and those that want it, but don't know it.  I'm pretty sure that you are in the second group, even if you think you are in a third group, those that are aware of multi-sig, and really don't want it.  I really, truly believe that you do want it but don't know that you want it, but it isn't something that I'm willing to argue about. 

The example using the mobile phone is pretty common.  I have no idea who first came up with it, but I fleshed it out in detail showing one possible way that it really could work in real life.  But there are other ways to do it.  Most of the other ways to do it haven't even been invented yet, so I have no idea what they will be.

If we want, we can abstract my mobile phone example back a step or two, and come up with something less specific, but still clear (I hope).

Step 1, I tell my client to send 5 coins to address XYZ.
Step 2, my client creates that transaction, signs it with the key it has, then sends it to my wallet service.
Step 3, my wallet service looks up my policy preferences, and since the transaction is more than 2 BTC but less than 10 BTC (my policy), it invokes a verification step.  The verification step involves either me contacting the service, or the service contacting me, using some communication channel other than the one used to communicate the transaction.  This could be a text message on a cell phone, a regular phone call, a personal visit to the local branch office, a telegram, a website, email, a USENET post, snail mail, smoke signals, carrier pigeon, semaphores, chalk marks on mailboxes, etc.  This will be either a little bit slower (SMS) or a lot slower (chalk marks).  You will customize your policy preferences to balance your desires for speed and safety.
Step 4, the communication involves some means of mutual verification, such as challenge-response, code words, photo identification verification, etc.
Step 5, if I am satisfied that I am talking to my service, and they are satisfied that they are talking to me, I can approve or recant the previously sent transaction.  If approved, they countersign using their key.
Step 6, my wallet service now sends my double-signed 2-of-2 key transaction out to the bitcoin network.
Step 7, the bitcoin network checks that the two signatures on this transaction match the P2SH signature that was provided earlier, and the BTC shows up in the vendor's wallet.

This is a basic model that has already been invented, and in the abstract sense is actively used all around the world every day.  The specifics can be adapted in many ways to meet different needs while still keeping some essential features and characteristics.  Other models may also work that accomplish the same goals.

And I want to stress two important things that I think are easy to overlook in this discussion.

First, no one can force you to use multisignature systems.  Even if there was a proposal to modify the network to totally disallow single signature transactions (a change which would be approved by pretty much no one at all), it would be trivial to be your own verification service.  Your computer would run bitcoin, and also run a second program just to approve them.  This could either be automatic or manual.  If automatic, it would be exactly the same as what everyone is using now, as far as they are concerned.

And second, bip16/bip17 are totally not about whether multi-sig is good or not, or will be included or not.  They are about how multi-sig will work behind the scenes.

This isn't about mobile phones.  That is just one example of one possible way to improve security.  There are countless other ways, most of which haven't even been conceived yet.  What they all have in common is that they require a way to divide signing authority so that a single point compromise isn't fatal.

P.S.  If this current single point system works for you, you can keep using it in the future.  It isn't going away.  But lots of people (approximately everyone but you) want the ability to use multisignature systems.

P.P.S.  Loosen your tinfoil cap a bit, and maybe poke some air holes in it.  And I say that as someone that keeps an old Palm Treo working because I don't want Google, Apple or Microsoft to "own" my phone.

It is even nicer for someone with a fleet of miners that wants to configure once and walk away.

I have 4 rigs, each with 1 to 3 cards.  After I made the 0.1 release this morning, I copied it up to my PXE server and rebooted all of the boxes.  Bam, I'm done.  If I didn't have PXE, I could just burn 4 CDs or write 4 new flash drives and swap them.  Since all of the details are stored on the network, I don't have to customize the CD or USB stick for each rig.

Also, if you have enough RAM to use the RAM disk for bitcoin, but you also have persistent storage, stopping the bitcoin service cleanly (which happens during a normal reboot) will update the stored copy.  When it comes back up, it will only have to catch up to what happened when it was down.

I took linuxcoin and added p2pool.  The first name that popped into my head was p2pcoin, and as far as I can tell, nothing else is using that name.

I'm open to suggestions, but I don't really think it is confusing.

If you are doing everything you can to avoid writes, and you are still killing drives, the problem is the drives.  I'll put a note at the top, but the answer in p2pcoin is to boot from CD or PXE if anyone is concerned about their flash drive.  Or even just not bother taking the extra time to add persistent storage.

The reason that we get nervous about gun registration is that those registration records come in really handy when confiscation time comes around.  And confiscation time pretty much always comes around sooner or later.

If anyone is interested, I've been working on a headless mining variant of this that uses p2pool.  It is still in early testing, but it offers some nifty features.

p2pcoin

So, I think that about a half dozen people have downloaded this so far.  Did anyone get it working?  Does anyone have questions or comments?

Sure, put them anywhere you think they will be the most useful.

And the address in my signature will be fine.

I've had a couple of ideas for bitcoin sites that I haven't bothered doing because I don't want the hassle.

Of course, I've had similar ideas for non-bitcoin sites too, and I usually don't bother with them either, because of the hassles that come with other payment systems.

You've never heard of safety engineering have you?

One guy crashes a plane into a mountain, pilot error.  Several people crash the same type of plane into mountains, design problem.

Lots of bitcoin users have crashed into mountains.  Each one of them made a mistake.  Gavin is trying to change the design so that the system is much more tolerant of these mistakes.