Huh?  Proof of the negative is fundamental to ownership.

I must prove that I haven't sold my car previously before before selling it to someone else.

Bitcoin itself is completely setup around proving a negative.  It is all about the Unspent Transaction Output Set.  Unspent = proven that spending hasn't happened yet.

How can you hand wave and say that in all cases for all things proving a negative is not needed, and just be more creative?

Factom uses something I am calling proof of usage.  Since we have this two step process to convert from Factoids to Entry Credits, we leverage that for the voting process.  When a person commits value to the system, by turning tradable factoids to non-tradable ECs, they have a proportional say in who is a Federated server.  Unless a large Factoid holder effectively burns their stored value, they do not have a say in how the system is run.  Even if they were a Federated server and purchased Entry Credits, they would not be paying fees to themselves.  The fees are something along the lines of a Pigouvian tax https://blog.ethereum.org/2014/02/01/on-transaction-fees-and-the-fallacy-of-market-based-solutions/. 

We also use a Commitment Scheme http://en.wikipedia.org/wiki/Commitment_scheme, where a user pays for a hashed Entry before the Federated servers know what it is.  If they decide to censor it later, then there is proof that they are censoring.  Bitcoin users cannot prove censorship.

As far as counterfit entries, that is a problem if you let it be.  We would expect an application which data that needs to be validated would be accompanied by a crypto signature.  The Federated servers cannot forge that.

The proof of usage is for moving the system forward.  Bitcoin hashpower keeps Factom servers from rewriting history.

The federated servers collectively set the Factoid->EC exchange rate.  They want to set it high enough to resist spam, but not so high as to stop legitimate usage.  That rate will go up and down relative to USD, BTC, CPI, etc.


"Wealthy attackers can create counterfeit..."  This is true in any system, including Bitcoin.  A wealthy attacker can make a 51% attack.  A wealthy central bank can make counterfeit dollar bills.

"cause genuine entries to be ignored by consensus. In other words, Proof of Stake is not a good consensus,"  All consensus mechanisms are susceptible to collusion.  You are also describing results of the 51% attack in the Bitcoin whitepaper.

"will collude to attack record systems of valuable real estate" There are a few attacks in a property record system.  1: stop changes from happening.  This would be pretty obvious to the person buying the property that they were being extorted.  If it gets onerous enough, then the property system would drop Factom and restart porting over history from Factom. http://szabo.best.vwh.net/securetitle.html
2: Changing history.  Bitcoin hashpower stops this.
3: Creating false histories.  Bitcoin will show a fork in Factom, assuming Bitcoin itself is not forked. Our system is designed to seize up before it forks.


"It would be better to not avoid Bitcoin's consensus approach. Proof of Work offers stronger protection from such attacks."  I am jealous of the ability of POW to burn through sibyl attacks, and other valuable things.  However, as our limited history has shown, if you are not the main Bitcoin chain, then POW makes you vulnerable, be it merge mining or straight SHA256d.  Also, having a pre-defined authority set allows instant acknowledgement from one of the Federated servers.

POW provides two things: non-reversability and probabilistically chooses who sets policy.  Factom relies on Bitcoin to give non-reversability.  Policy is set by servers elected by proof of usage.

@BitcoinIsLiberty


Factom splits up control, but still binds the servers together with a consensus mechanism.  It is attempting to be censorship resistant, similar to Bitcoin.  If you setup a system with centralized control, then that central party is free to censor.


Factom giving non-reversibility is not too groundbreaking.  You can do that today on proofofexistence.com.  Factom allows you to publish data into a blockchain which is censorship resistant, while being spam resistant.  This is the very tricky problem Satoshi seems to have solved with Bitcoin, and we are attempting to do as well.

Factom proves a negative for a specific application.  This would be analogous to asking why an asset issued on counterparty is just as good as an asset issued on dogeparty.  The underlying network provides the confidence for higher layers.   A Factom clone may or may not provide the confidence to applications built on top of it.

No.  Proving a positive by putting a hash in the Bitcoin blockchain is indeed a trivial problem which requires very little overhead.  Proof of existence is proving a positive.  Factom proves a negative, which requires examining all possible places where a thing can exist.

Satoshi solved a very tricky problem, which was the doublespend problem.  Doublespend is a subset of proving a negative.  The miners must prove to each other that Bitcoins have not been spent before.  To do that, they need to know about all Bitcoin transactions ever. 

Lets take the counterparty project as an example.  It rides on top of Bitcoin.  A counterparty wallet must download the entire Bitcoin blockchain to see if the asset sent to it was doublespent.  It proves the negative of a doublespend by looking at all of Bitcoin, all of mastercoin, all of proofofexistence.com, and all Bitcoin value transactions too.  This is not scalable.

Factom is attempting to make a publishing platform which is simultaneously censorship and spam resistant. This is what makes Bitcoin magical, and what Factom is trying to accomplish.

Last Summer, I went down the road of building such a system but everything I came up with was susceptible to either one or the other.  I gave the packaging entities the glorious name **Compaction Service Providers** (CSP) and even wrote about it here: https://github.com/FactomProject/FactomDocs/commit/2791c51917e3ecc65dc52bfc434ca6dec0b3a1fd back when we were Notarychains.  With free entry of CSPs, censorship would be limited, but the entire system would get spammed quickly, and there would not be a good way to accurately locate the data you needed.  Without free entry, once a specific CSP was selected by an application, the CSP could selectively censor within that network.  Lock in effects would be strong, so switching the entire application base over to a new CSP would be expensive.


Factom is a system that generalized the proof of the negative, and makes it scalable.  To prove a negative, you only need to scan through things in your application's small corner of Factom.  It is general enough to prove a negative for general business processes, rather than just value transfers.

Is what you are describing an implementation of Timo Hanke's 2013 San Jose presentation?

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

I am in that group of people who knew about your crypto primitive before Bitcoin.  I knew it as just an email spam prevention technique that didn't take off because people wanted to get mail from mailing lists.  When I read about Bitcoin, I thought it was a neat application of that primitive which hadn't gained traction in the original use case.  I don't remember ever thinking about hashcash being used as money, and thinking it was a funny name for something that wasn't meant to be cash, just anti-spam.

@delulo


it would be more accurate to say that they are secured by the bitcoin blockchain.  Not all the data that Factom collects is recorded in the blockchain.  You are mostly correct about dealing with Bitcoin rules.  It depends on how much confidence your application needs.  if you want to double check everything that Factom is doing, then verifying it all the way to the blockchain would give you confidence Factom is not misbehaving.  This is similar to Bitcoin, where you can either run a full node, checking all the miner's work, or using a lite client on your phone.  it depends on how secure you need to be. 

I suspect that a majority of people will use lite clients like they do in Bitcoin.  This would mean they only needed to deal with the Factom API.  Initially, we are planning on having a program that runs on your computer which acts as an interface between a web services API and the Factom network.  This means that we can continue to update the p2p network while the api calls your application uses stays the same.


It is more federated than centralized.  I believe it is like NXT, where the server responsible for packaging transactions is known before a block is created, rather than like Bitcoin, where the transaction packager is known after the fact.  Since the network knows who is supposed to do the packaging, an acknowledgement from them is like having a promise from a Bitcoin miner.  There is a continuum of confidence as time goes on.  see#3: https://bitcointalk.org/index.php?topic=850070.msg9754449#msg9754449

Here are some thoughts that came from a different channel I thought were worth sharing:

Factom is more about record-keeping than storing data.

We are trying to give users the irreversibility of the Bitcoin blockchain without having every transaction in Bitcoin.  We are trying to make a system which is both censorship resistant as well as spam resistant.  The two are diametrically opposed.  Bitcoin itself is trying to achieve both of these as well. 

Bitcoin is a big complex system which boils down to the world agreeing on a UTXO set.  It is a big datastructure to see if money has been sent to someone else first. 

Bitcoin proves the negative (that money hasn't been spent earlier).  A BTC receiver must have the entire UTXO set to prove that negative.  (There may be more optimizations later, with patricia-merkle trees, etc, but the miners need the entire UTXO.  Also, light clients can trust miners, but I digress.)

Factom is trying to generalize the proof of the negative.

Factom is also a big complex system to let the world agree on a data set.  Factom takes disparate sets of data, and classifies them into buckets.  These buckets, which we call Chains, and have user specified IDs.  The idea is that all of the data relevant to an application is tagged and placed into the correct buckets.  For an application to prove a negative, it needs to download and verify only the data in its Chains.  If the data is not included in the Chain, it can be assumed not to exist.  This is very similar to how a bitcoin can be assumed not to have been spent if it is not included in a block.


The intent is to not store large pieces of data.  we are trying to discourage that by setting the pricing for other services to be more attractive. 

The data is shared on a Distributed Hash Table, so a user could reshare out the data which they are interested in, but not store data for other's uninteresting applications.

The storing of the bulk data in storj or maidsafe is what we had in mind too.  One of the problems with storing in storj, though is someone needs to keep paying a maintenance fee.

DanSmith:

The magic of having the DHT, though is that subsets of the data can be shared independently.  The bank itself could spool up many copies of its data if it needed to share it in a distributed fashion.  A potential auditor knowing they might need the data in the future could collect it in real time.  If the network were attacked, the proof would still be rooted in Bitcoin.

One mitigation to your attack would be for the federated servers to share different subsets of the data on different IPs.

I do envision different availabilities for different datasets.  Popular datasets will be massively shared, and niche ones would be harder to get.  In the distant future, it may even come to a point where payment is required to download rare data.  Businesses would sell this historical data which doesn't have altruists sharing it.


What I worry more about is sibyl attacks on the DHT routing table.  If you only get lies as to where you can find your data, then you are out of luck.  I have read about ISPs sibyl attacking their customer's bittorrent connections, but those were more to force their customers to share amongst themselves, instead of over the ISP's peering connections.  There is a lot of research being done finding how to burn through DHT sibyl attacks, but it is indeed a complex problem.


Running Federated servers over tor will not likely work, mostly because of the bandwidth.  The federated servers need to have low latency to turn the data around.  It is a flood fill network, so every full node needs to see all Entries, plus 3 packets with assorted signatures covering that Entry.  The federated servers come to consensus every minute.

well... now that I think about it, only a majority is needed for consensus.  One of the federated servers could listen over clearnet, pretending to be a non-authoritative full node.  Its signed transactions could be broadcast through Tor.  only 2 sigs of hashes would go through Tor for every Entry.  If they take too long to broadcast consensus, then the rest of the network can quickly come to consensus without them.  Timing attacks from their peers are still possible to find them, though.  we do have heartbeats that are needed from every federated server to show the rest of the network they are still alive.  this may be hampered by tor's latency.  maybe the heartbeats can be sent over multiple tor routes to decrease the chance of one getting lost. 

Bitcoin bans spamming peers, but that wouldn't work over tor.  a full node deciding to listen on tor would just have to eat all the DOS traffic, since it couldn't ban an IP. 

Sharing data over Tor after the fact will work much better, since latency and bandwidth are less critical.  a tor node can insert itself into the DHT routing table, and offer up contraband data.

Lots to think about with Factom and Tor.  Bitcoin's flood fill network has some of the properties of tor, since peers don't know if a new transaction originated from that peer.  Factom's network is probably closer to the streamtorrent system.  It would be interesting to see how traceable that network is.

Apologies for the rambling response to your post. 

This will be a self policing style system, similar to how the Bitcoin miners self police amongst themselves for the block reward.  If a miner decides to award themselves more BTC than the fees that were paid in, then the majority of other miners will reject that block.  Factom will have a similar system.  The majority will reject a block which has outputs that exceed the number of signed inputs. 

As far as that level of detail for constructing proofs of transfers, we haven't gotten to that yet.  There is a lineage that can be traced, protected by signatures, so it can't be forged.

The Entry will be associated with an Entry Credit commit payment, which was signed by a key.  That key had an Entry Credit balance because of a signed Factoid transaction, which essentially converted Factoid value into Entry Credit value at some exchange rate.

The progression of value can be followed back to where the Factoid's were initially committed. Since signatures and hashes provide cryptographic assurance, then a proof can be constructed.  If we are going to record that proof, or have it be an in-memory operation like Bitcoin is yet to be determined.

dansmith:


I must admit there is a lot we didn't put in the paper.  There isn't a lot on consensus or incentives.  38 pages was stretching it already.  Satoshi's was only 9.  AlanX is memorializing more of what we are designing in a forthcoming consensus paper.  Incentives have yet to be explored formally.


1: Yes, something like that.  historical crowd sales map the private key owner in Bitcoin to be the new owner in the funded system.  A lot of that heavily relies on having the same elliptic curve as Bitcoin, though.  5 years have passed, so we can build our system using updated crypto, but that would make shortcuts like this harder.  It would be nice to get some advantages by using Edwards Curves, etc.  We haven't gotten quite to that level of detail yet for that part of the system.  Also, we have very limited time to experiment with new things.

2: Yes.  The cost of doing business includes paying the BTC transaction fee.  For the Federated servers to play in the system, they need to have a small amount of hot wallet BTC to pay transaction fees.  Since there is a small (~=16) set of Federated servers who need to hold the BTC for transaction fees, users or non-authoritative full nodes do not need to hold BTC.  Every 10 minutes, a deterministic algorithm determines which one of the 16 Federated servers is responsible for anchoring the group's data.

3: There are varying levels of trust that an application can have.  Just like Bitcoin, Factom is eventually consistent.  Bitcoin gives the irreversibility metric by number of confirmations and by how many of the nodes have the TX in their mempools.  Factom will have granularity of certainty too.   

certainty level 1: A Federated server has acknowledged receipt of the data.

certainty level 2: The Federated server's peers have not alerted a problem over the Factom P2P network.

certainty level 3: The Anchor (Merkle root of all Factom data over last 10 minutes) with your data in it has a Bitcoin transaction on the Bitcoin network.

certainty level 4: Federated server peers have not created alert transactions in the form of alert BTC transactions.

certainty level 5: The Anchor has 1 Bitcoin confirmation.

certainty level 6: The Anchor is buried under under several Bitcoin blocks, without also seeing some kind of alert or canceling transactions from the Federated server peers.  Eventually, Factom will extend beyond a statute of limitations style period to prevent the Federated server majority from canceling an anchor of a misbehaving peer.


Since we use a multistep commit and reveal process, the Federated servers will be accepting payment for Entries which they do not know the contents of.  If later, they censor based on the Entry content, it is provable.  A user ( or more probably an Audit server) will publicize this censorship.  The Audit servers have an incentive to make the community dislike the current Federated servers, so the Audit servers can get enough votes to be promoted up to Federated servers, and get more Factoids.  Adam Back advocated for blind commitments similar to what we are doing in Bitcoin earlier.  https://bitcointalk.org/index.php?topic=206303.0

A lot of this is still preliminary.


4:  When the Entry Credits are used to pay for Entries, new Factoids will be credited and spread amongst the various participating Federated and Audit servers.  This is similar to transaction fees paid to Bitcoin miners.  Distribution proportionality schemes are also preliminary.


5: I think this is where a misunderstanding is occurring.  The 16 Federated servers cooperate to collectively sign the Directory Block, which has Merkle roots of all the Entry Blocks.  They need to agree as a majority to a single directory block.  If a server were to pay for Entries to the system itself, it would get back less than 1/16th of the value it put in. 




Concerning the threshold multisig:

Factom's reason for existence is to move transactions off of the blockchain.  looping half of the process back into BTC again goes against that core rationale, but I can see where you are going with it. 

Factom is a dynamic system.  With a multisig system, someone has to actually control the private keys.  That doesn't afford a really dynamic system. 

We have a type of delegated proof of stake.  This gives the active users in the system the say in who they want to package transactions.  This has some merits.  I hear the Ethereum folks are planning on now using some type of POS in their consensus.  There are even serious proposals for bringing POS elements into Bitcoin (see Proof of Activity http://www.cs.technion.ac.il/~idddo/PoAslides.pdf). 

The POS elements mean that the system authorities (federated servers and audit servers) can change in a short period of time based on the expressed wishes of the users.  There are often calls to change what mining pools are patronized by individual miners.  this will give a similar ability but enclosed in the Factom system.


If we brought in merge mining to the system, we would rely on miners twofold.  we are already using miners for the non-reversibility.  with merge mining, they would also be setting policy.  This is a secondary business for them, and may not give it the attention someone who made it their sole business.


Bitcoin multisig currently doesn't have a high enough M of N for standard scripts.  we are trying to get this project working without the help of miners (other than them not censoring our anchors, etc).  current standard transactions give a maximum of 4 of 6, which isn't enough separation of powers for my taste.  http://bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses  Going higher would involve cooperation with miners. 


But back to the threshold multisig.  For the system to be dynamic and in control of the users, there needs to be some coupling between the stored value in the system and a say in who controls the system.  in a threshold multisig system, the coupling is permanent once a payment is made.  this encourages keeping smaller amounts in multisig as a balance, defeating the purpose of the whole system (moving transactions off the blockchain).

Threshold multisig also changes the system dynamics.  If the service gets big enough, the majority can misbehave and steal all the stored bitcoin in the system.  With the current design, if the majority misbehave, they will end up destroying the value they created in the system.  This seems like the biggest problem with a threshold multisig to me. 

Systems build on top of Factom are expecting it to last indefinitely.  Factom also gives proof of the negative, which makes switching from one system to another expensive for a distributed system.  There is some commentary on this in our AMA thread in Reddit. http://www.reddit.com/r/Bitcoin/comments/2mkyrg/we_are_the_founders_of_factom_see_our_white_paper/  Systems are looking for a canonical source to hold the entirety of their transactions.  Setting up competing threshold multisig systems would expand the search space needed to prove a negative.  Also a distributed system would need to decide which system to expand its search into.  Too wide of a search and spam becomes a problem.  Seperating Factom from bitcoin value also makes it portable.  Factom can switch the POW system which provides its non-reversibility.  If Bitcoin falls to another POW system, Factom can switch to being secured by that system, or a multitude of systems.

I haven't considered all the pros and cons of a system you are imagining.  I can imagine a system like it working technically.  I can also imagine a purely altruistic system of packaging transactions and securing them with Bitcoin.  It boils down to what system correctly aligns incentives of all the parties involved, rather than what is technically possible.  On the topic of incentives, I must admit I have a strong incentive to believe the things I have described.  Please do consider exploring further the system you are starting down. 

This brings up a good point.  If I want to patronize a certain miner, but don't care how long it takes, I can send the transaction directly to them.  If they don't rebroadcast it before they mine it, then they get the fee.  Depending on the miner, though, I may be waiting a while.  Lets say I wanted to patronize BitMinter.  I could send them a secret transaction, which they alone would mine and get the fees from.

However, over the past two days, they have only had 3 blocks per day.  http://blockchain.info/blocks/BitMinter.  If you are willing to wait 1/3 of a day, then this solution works.  Keep in mind, though you will be competing for block space with the rest of the world for those 10 minutes, so the fee had better be higher than market rate.

Even in yesterday's society there exists analogs to this discussion.

One example that comes to mind is an organization or business that has a treasurer.  The checks drawn on the company accounts need the treasurer' signature.  They have the ability to empty the company account, convert it to cash, and consume it.  Only after a board vote would they actually have the right to do that.  The organization is the owner, not the treasurer holding the signatures.  This directly correlates to a treasurer holding private keys.  If the treasurer consumes the bitcoins, then the company has the right to sue the treasurer, just like in yesteryear.

Is there a way to add more miner fees after a transaction has been broadcast without having to modify the original transaction?

Lets say a customer makes a transaction going to an offline wallet. For some reason the fee paid is below what miners are charging today.  Instead of trying to get the customer to work around resending the payment with all the difficulty that involves, I could just broadcast a facilitating payment.  

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

The proposals in this thread refer to inputs added before the transaction is broadcast:
https://bitcointalk.org/index.php?topic=188695.0

merchant-pays-fee (aka child-pays-for-parent) is clever, but relies on being able to spend the outputs.  
https://github.com/bitcoin/bitcoin/pull/1647
https://gist.github.com/gavinandresen/4120476
If the outputs are designed to be spent on some external conditions, like with an escrow, spending the outputs would disrupt the flow.  

Also, merchants can setup their servers with watching only wallet.  For security, online computers cannot spend the outputs, only view them.  The offline wallet would be intentionally hard to spend, requiring human intervention to spend the child.


I suppose that if any change was sent back to the original payer, and they had a Coin Controlled client, a child-pays-for-parent transaction could be spent for the change.  There is no guarantee that there would be change though, and ideally anyone would be able to add more fees.


I imagine that the facilitating payment would be something like an output that anyone could send, but required a certain transaction to have been mined.  The transaction would reference two transactions as it's inputs.  One would be the expedited transaction, but not actually spend that input. The other input would be a normal send change to self, but with the fee granted.

Is there a way to have an input referenced without the private keys?

Indeed, I see that now. 

I was excited you did something local like scanning the blockchain files on the hard drive or connect to the qt client interface. 

I am struggling with that right now, but I don't want to get off topic.
https://bitcointalk.org/index.php?topic=279273.0

This code relies on blockchain.info being accessible. 

nothing blatantly viral. 

passed virustotal.com scan.

https://www.virustotal.com/en/file/d8a2aeaa85030c5d630d9dea7cc7939ab4ca2d919320cd101127b09f600b7ca7/analysis/1377296644/

Greetings Bitcoin developers:

I am starting a project that tracks the value in and out of a subset of addresses.  I want to get timing for when a transaction has an output to an address and also when that transaction is redeemed.  None of these have the private key in the wallet.

Something like BlockExplorer.com would be a great source for that data, but I am trying to accomplish this without going over the internet. 

Initially I though that the JSON interface to the satoshi client had this data available, but it does not appear so. 

Here are my options as I see them:

1. Whenever I am looking for a new address, I could start at the genisis block, and pull in each block using the JSON getblock <blockhash> command.  I would iterate over all the tx's using JSON getrawtransaction <transhash>.  In each transaction I would check for the private keys I am looking for. I expect this would be an arduous operation, for all 10 GB or so.


2. I could incorporate some of the Armory BlockUtils.cpp code to scan the blockchain at the disk level. This is also a large undertaking.  I might be trading off large resource requirements for increased speed.


Is there something I am overlooking?  Is there an easier way to find transactions with specific public keys named?

I remember the dinner conversation in San Jose, but I forget the practical problem we were trying to solve. 

This does seem reminiscent of an old lecture I heard imagining an aged benefactor creating a transaction and signing it with a far off nlocktime, then giving the transaction to their grandchildren as inheritance.   After the nlocktime expires, the grandchild would broadcast it to the network and collect the funds.

I agree with gmaxwell, for a single user, I'm not sure that a method like this is has a substantially different net effect compared to a multisignature transaction. 

Current multisignature method : IN-> 2of2 A & B -> SPEND
Proposed method: IN->A + time -> B -> SPEND

To exchange value, the holder would need two things.

1. A secret pre-prepared transaction (A->B)
2. A private key to spend from B for value transfer.
After the lock time, the proposed idea only differs from multisignature by making the first secret a transaction instead of a key.

One benefit I see is if I wanted to allocate an amount only to pay my electric bill, but not pay them quite yet.  An attacker who gets transaction A could only pay my power bill early. This would lock me into spending to the power company, but it would not be transparent to the electric company, since the transaction is private.  The escrow would give visibility to the intended recipient.




I know you guys know this, but for the listening audience: 
One implied benefit this scheme might have is to give a theft victim time to respond to a slow moving attack. They would only know they were attacked when money started moving.  The victim would see value move out of their address A and be able to prepare another transaction to reclaim those funds.   I think that this outcome has two assumptions that are incorrect:

1. nlocktime is not relative time, but absolute time.  it can be either UTC time or block height.  If both secrets were compromised, (the only way this attack would be profitable) the attacker would have the ability to spend funds through B at the same time as the victim. 
2. IF (big if) the chain were forked to allow relative lock time, then it would be a race between the attacker and the victim to get the B->SPEND into the mempool.  The attacker would be prepared and send theirs first.  The victim trying to recover would not have their transaction propagated due to the coins being spend in a previous transaction.  The victim could send their later B->Spend  transaction directly to a miner to get around the relay problem, but the miner would not know who the attacker and who was the victim.  Satoshi nixed the relative time way back when for block chain re-organizational simplicity.




Instead of destroying the first key, I am imagining multiple levels of two factor authentication.   
I am thinking something along the lines of traveler’s checks.  Before traveling, an offline wallet program could pre-authorize a number of transactions from, say, a deterministic wallet.  The preauthorized transactions could be brought traveling, hidden in a TF card immune from pickpocketing (shoe?).  A phone would be the primary spending method, with only one signature needed.  If more value was needed, the presigned transactions could be broadcast to the phone’s address from an insecure internet cafe.  Pre-assigned private keys could also be brought and used to seed a replacement wallet on a replacement phone, also able to be transmitted in an insecure environment.  If both phone and TF card were lost, you could spend the unused balance of the preauthorized transactions once you get back home.  At no point could you be compelled to hand over more than you brought along or the private key/chain code in the deterministic wallet. 

Nope, He uses bitcoins as a representation of wealth.  in this one on the City of London he shows the Romans using bitcoins.

http://www.youtube.com/watch?v=LrObZ_HZZUc