--- Log opened Fri Aug 16 00:00:59 2013
21:33 < gmaxwell> So, we've mused about how SCIP could give us provable checkpoints, well except for the fact that the program execution for validation of the blockchain is currently not pratical with existant systems.
21:34 < gmaxwell> Consider this— the SCIP validator is pretty fast, within the general order of magnitude of what we could have in a block (it's perhaps as expensive as 1000 checksigs).  You could send txouts to a proof verification key.  Okay nothing amazing here other than giving you superpowered scripts.
21:35 < gmaxwell> Except the proof verification key could actualy be validing a long chain of off chain transactions, potentially transactions in another blockchain, and then returning the output values to bitcoin.
21:36 < gmaxwell> so this is kind of like zero coin, except you could have long chains of transactions hidden under the proof.
21:40 < gmaxwell> e.g. I could pay 1 BTC to alice, under plus an anti-reply timestamper oracle which prevents replaying an ID number but is otherwise blind to the txn. And then alice could pay to bob (and get timestamped). and bob could pay to charley.  And then charlie could take this transcript (the ecdsa validation and the timestamps that prove no double spends), run the SCIP prover on the transcript,  and recover the bitcoin.
21:42 < gmaxwell> It's zero knoweldge (the transcript is aux input), so the public doesn't learn anything about the chain of transactions... and also has the benefit of compressing a potentially long transaction history into a single result.
21:48 < gmaxwell> or you could replace the timestamper oracle with SPV proof on another blockchain. Your bitcoin becomes a colored litecoin satoshi, you make a bunch of plain litecoin transactions, and then assemble a bunch of litcoin SPV proofs, and a number of additional headers, prove it, and the bitcoin reemerges in bitcoin.
21:49 < gmaxwell> (e.g. what some people have proposed doing for cross chain transactions, but compressing all that data under SCIP to avoid sticking hundreds of kilobytes of data into the global blockchain)
21:50 < gmaxwell> So whereas ZC creates scaling concerns in exchange for improved fungibility, this thing solves scaling concerns and improves fungibility as a side effect.
21:54 < gmaxwell> One challenge is that the upper limit of input size and computation for SCIP must be established when computing the verifcation key. So the colored coin thing would be a bit weird because you could only go so many hops before you could no longer recover the coin.
23:15 < jgarzik> petertodd, The first SIN software has appeared,
23:15 < jgarzik> https://github.com/gasteve/node-libcoin
23:15 < jgarzik> SIN.js makes a bitcoin-address-like thingy, according to protocol spec
23:15 < jgarzik> SINKey.js generates an EC key for use w/ SIN
23:16 < jgarzik> This, therefore, is the original SIN,
23:16 < jgarzik> jgarzik@pum:~/node_modules/libcoin$ node sin-test.js
23:16 < jgarzik> { created: 1376709207,
23:16 < jgarzik>   priv: 'bc65f94b4142be3c6c0b02b33dab3775a829fc1f60e484e7d4ea64e2f421cdc4',
23:16 < jgarzik>   pub: '029381bcb36358e58842431981a01742d494970a245c8f5c77874bbbde8fb25a9b',
23:16 < jgarzik>   sin: 'je9eFspuTC29yhUqGqzEYwWmVTJRS9nWEkA' }
--- Log closed Sat Aug 17 00:00:08 2013