Hi Adam,

  Consider though that your system relies on an internet connection- so what's the point of having the physical coin at all?

  My paper wallet idea does give you this ability to carry a secret without knowing what it is.  When combined with a un-counterfeitable item (hologram or kinegram serial code), you have something very useful to represent a bitcoin.  In my system(linked above) the only person who knows the private key is the one who prints out the two VC factors.  Its' also very easy to do- only requires a laser printer and optimally some hologram serial numbers(these are widely available http://www.amazon.com/Security-Hologram-Stickers-Consecutive-Authentication/dp/B002KHVHK8 ) - better would be the hologram is embedded into the paper somehow, but the sticker offers your basic anti-counterfeit.

-bm

consider that, not only is OpenCoin really closed ClosedCoin for all intents and purposes, but they have also given no indicator as to what open source license they plan to release the code under.  Secondly you also have the issue of patents, which rules out the possibility of forking the way you describe.

what would that do that 2(or N) factor auth can't?

so to elaborate, one factor is the Smart Card or similar device, and the software creates a NEW factor in the Bitcoin transaction(perhaps with a old-fashioned private key).

if it's possible to get at the coins without the hardware, then you obviously lose some security aspects.

Seems you guys aren't familiar with the history of these products and what's currently available.

If you're willing to get into complex hardware, you can always go the Smart Card route which is a very cheap way of printing an IC onto a piece of plastic like a credit card.  This IC is the actual crypto function, and the private key is embedded into it.  In order to get the private key, you need to either get it from the manufacturer or reverse engineer with a electron microscope and an evil genius for hire.

Smart Cards came out many years ago but were never really put into widespread use.  https://en.wikipedia.org/wiki/Smart_card .  I imagine that SCs are even more cheap today with what is available.  Sergio, the issues of tampering with the physical factor have been solved long ago.  Smart Cards caught on more in Europe than the Americas.

Of course you can introduce more factors into the auth process such as passwords or additional keys without modifying or replacing the smart card artifact.  You don't really need much fancy math to give you these basic functions.  Basically all you need is a smart card reader(some laptops have this or you could implement one very cheaply), and some simple software.  It's far more secure than regular credit cards.

I also came up with a way to implement a useful paper wallet using Visual Cryptography.  You can implement this scheme with a simple laser printer.  Adding holographic serial numbers greatly enhances the security though(these can be obtained pre-printed for acceptable prices).

https://bitcointalk.org/index.php?topic=226671.msg2386001#msg2386001

 as far as I've looked at it, you can make secure paper money using this technique given the bills are not counterfeitable  ie. has a hologram or kinegram with serial number on it.

 it also requires an official to handle the other VC factors.  This person could be paid to return the two factors to a central clearing house.

the nodes still need the blocks to VALIDATE the transactions.  If we're talking about SPV, then they don't really need the blocks at all, just the headers.

While Freenet can do that, it's not necessarily PERFECT for the job.

Bitcoin is a special case, because the data is highly redundant(practically every node has every block, or most of the blocks).  You can optimize the DHT algo to take advantage of this.  Freenet is one of many technologies in this class.  Some DHTs concentrate on security, and in Bitcoin there is no need for transport security as data at that level is public(theres nothing in a Block anyone wants to hide).

Transaction relays are a different story I think.

excuse me?

In the Confidence Chains system you have MANY block chains, and the users might download several of them for various purposes(if they want to trade an asset or participate in a market or auction).  Thus there must be a useful and robust way to retrieve this data over a P2P network.  Only the identities need to hear about transactions, and you can do this with most DHT implementations.  There is an important question for this system: how do you bootstrap a block chain over a p2p network.  Bitcoin solves this in a very specific way, I need a more generalized solution.

With Bitcoin, it's unclear as to how to best optimize the p2p network.  For me lack of docs on this subject might indicate there are some hidden exploits.

I've spoken to a few DHT experts on this, most of them are optimistic about this idea.  The problem is basically how to optimize the Distributed Hash Table algorithm for block storage.  You can certainly optimize the algorithm in this case.  BTW- is there any good documentation on how the current relay mechanism works for Bitcoin?  I had several people ask me for this and I couldn't find anything.

btw- I notice many on this board seem to think that 'developers' are some kind of cheap resource that you could just conjure up by throwing a few dollars around.  While there might be many people able and willing to write a few lines of code, these kind of problems are very complex and there are really very few people who are capable of solving them effectively.  I've already seen several projects releasing code that appears to perform a(much desired) function, but fails in very important ways.  Of course these problems wont show until long after it's released and people have invested real money in the system.

I think that's just a list of people whom Chaum had co-authored papers with.  He was an academic in Holland apparently.

Notice that list includes the same name twice, just different spellings.

It's probably possible to store blocks in a DHT with some kind of reasonable response time.  These structures are designed to store data of this capacity.

For many applications though, you need to keep a copy of the block in local storage so you can validate the chain, thus there is a good probability that the block is available at a given node.  From here you need to determine 1) how to locate the block efficiently 2) which node is appropriate to poll- for instance balancing the load on all nodes that have a given block is optimal.  

It's certainly possible to optimize the basic DHT algorithm, which is designed for general use.  You might also need to implement a broadcast function for the transactions.

 I ran into something the other day that shows how different the bitcoin system of accounting really is.

 It occurred to me that if we could have a very simple CREDIT system, then we could also hedge the price of BTC.  ex.  If I think BTC is going to appreciate, then I LOAN out BTC.  If I think BTC is going to depreciate, I BORROW BTC[1].  It's that simple really.  Most instruments and market functions can be derived from this basic credit device.

 So all we need to do is have a time release TX right?  as in - make a TX going out(the loan) and make another TX going in that is time dependent.  Sounds like it would work right?  problem is that you cannot SPEND the money if the TX is already created, even if it's time dependent.  Thus, I cannot cash the BTC out for USD while I have it on loan.  Thus the Bitcoin system ISN'T a system of credits and debits as accountants would expect.  It has very different qualities.  You can derive credits and debits from the basic data.  A Bitcion TX is NOT AN ACCOUNT LEDGER.  Bitcoin devs will probably read this and say: 'no duh?' - but for those coming from the accounting worldex, who expect these features will no doubt be suprised to find they dont exist here.  Bitcoin's TX structure ensures that there can never be unsettled transactions.  You can NEVER have a TX that results in 'sorry funds are not there' - simply can't happen.

 It reminds me of the common issue of managing multithreaded bank accounts: http://msdn.microsoft.com/en-us/magazine/cc817398.aspx , something tells me the thing we're looking for is related to that.  The Bitcoin system of account protects against many kinds of corruptions such as indicated in the link.  In Bitcoin the order of TX might be rearranged so the transaction flows must be explicit.  The TX structure, historically, is not coincidental it was conceived as an integral part of the system from the start.  It's mentioned in the whitepaper.
 

[1] this is what the notion INTEREST RATES are all about.  DING!

this system of inputs and outputs was indicated in the Satoshi whitepaper.

Hi Jeff,

you can have the entire transaction history while adhering to the suggestions of OP.  It would just be more efficient to compute the account balances.  You might lose something though, perhaps you know? 

-bm

this is true.

however what makes Bitcoin unique is the 'mining' aspect.  So you need a way to enforce this economy of transaction processing.

I recently developed an alternative, but it's not 'zero trust', it's more 'many trust'.  In other words the block chain depends on trusting many parties not to collude.  This kind of scenario is implicit in many financial schema, ie. Digital Gold Currencies, Community Currencies, etc.

https://docs.google.com/file/d/0BwUFHE6KYsM0ZkxLVmFwbXQ3ck0/edit?usp=sharing

https://github.com/BlueMeanie/ConfidenceChainsSimulation/wiki/Features

I don't think a 'zero trust' currency actually exists.  It will appear to exist up until the time someone exploits it.  For instance Bitcoin trust model is very robust, but we must trust that someone doesn't overload the system with computing power(51% attack).

you can do something like this with Bitcoin, simply by embedding a hash of your message(or the message itself if brief enough) in the script field.

Jeff, thanks for the response.

Was there some kind of recorded discussion about why it was done this way?

yes we have the set of UTXOs, but the entire chain must be traversed in order to compute this set!  Thus computation issues are built into the system.  If you were to have a tx format like OP suggests, you could eliminate much of the computation(to find a balance, you just find the last tx with account X as destination).

Of course I really don't know how you could implement the scripting system with this.

C++ generally sucks if you never had the time or intelligence to learn OOP.

LOL.  Global Variables: the wave of the future.