--- Log opened Tue Aug 20 00:00:24 2013 08:02 < gmaxwell> Hey everybody, Tonal bitcoin is a more likely reality than you might expect! 08:03 < gmaxwell> https://bitcointalk.org/index.php?topic=278122.0 "CoinCovenants using SCIP signatures, an amusingly bad idea." 08:03 < gmaxwell> Luke-Jr: I think it would be super awesome if you'd reply to that with a "finally I've found a way to move everyone to tonal!" 08:04 < gmaxwell> (e.g. by constraing txouts never be round decimal values, and requiring higher transaction fees if the numbers are not round tonal values) 08:06 < petertodd> gmaxwell: that's exactly what I was doing here: http://permalink.gmane.org/gmane.comp.bitcoin.devel/2612 08:06 < Luke-Jr> might not be politically wise right now :p 08:06 < petertodd> Luke-Jr: 0.1BTC if you do 08:06 < Luke-Jr> petertodd: lol 08:06 < Luke-Jr> has anyone suggesting SCIP scripts to blind the inputs? 08:06 < petertodd> might not be politically wise right now :p 08:07 < Luke-Jr> eg, have the public info just be a UTXO set hash, and have the SCIP script verify the secret transaction inputs are part of it 08:07 < petertodd> yeah, could work... gmaxwell said 144 minutes for what, ~100 instructions? That's plenty to evaluate the merkle tree 08:07 < gmaxwell> Luke-Jr: you need to remove the utxos from the set though. 08:08 < petertodd> oh, right... 08:08 < Luke-Jr> ah 08:09 < gmaxwell> you certantly can do things like input blinding though, just not quite so directly. 08:09 < petertodd> yeah, the timestamping oracle is a good mechanism, and it'd be a wonderful way of forcing authorities to make public services like timestampers lie 08:10 < gmaxwell> petertodd: so yea, one "problem" with this SCIP stuff is that even if you introduct it as a script feature in its _MOST_ limited form, in is insanely powerful, even including power we'd probably choose to not offer. 08:10 < petertodd> vessenes did bring up the issue of allowing people to restrict their transactions to meet local regulations... which SCIP would be just ducky for 08:11 < gmaxwell> e.g. we would probably not want to make scripts able to go do a bunch of math on the nlocktime of their containing transaction. But any SCIP signature system would have to be able to be used to preform general computation on anything it was signing. 08:11 < gmaxwell> petertodd: well the regulations are almost never a function, ... and when they are they are usually wrong headed. 08:11 < petertodd> which means they either have access to nlocktime or don't 08:11 < petertodd> *maybe* you could add a specal purpose opcode, but... 08:12 < gmaxwell> could you imagine CoinCovenant viruses? haxers break in, they don't steal their coin. They encumber them so you have to include a "I LOVE GNAA" OP_RETURN txout in every transaction. 08:13 < petertodd> ha, lovely 08:13 < gmaxwell> fortunately scripts don't pass through to fees... :P 08:13 < gmaxwell> (and SCIP can't extend them there) 08:13 < petertodd> I've been thinking about posting high-value partially signed tx's with, stuff in them 08:13 < petertodd> actually, I posted one to bitcointalk, and no-one has found it yet 08:14 < petertodd> gmaxwell: in practice it can: anyone-can-spend-except-for-gnaa outputs 11:42 < realazthat> lol 11:48 < gmaxwell> I'm sad, iddo didn't give a terrible example. EmperorBob made up for it. 11:49 < petertodd> oh, so rick-roll was a good idea? cool 11:49 < gmaxwell> the snowballing taint is pretty awesome. It's like cancer, it has a moral imperative to grow! 12:32 < gmaxwell> petertodd: I powered up EmperorBob's spamcoin. 12:33 < petertodd> ? 12:34 < gmaxwell> - Smashcoin: Any spend of a coin with this covenant must retain the covenant and provide proof of an attack on an alternative cryptocurrency. (e.g. SPV proof of bloating some other cryptocoin's UTXO, or mining multiple blocks at the same height (with some committed data)) 12:34 < gmaxwell> (In particular, if it required that there be no payee at all beyond the covenant for one of its outputs. ... and it becomes a self-administering bounty for attacking something else 0_o spooky. Fortunately most attacks are not cryptographically provable) 12:34 < petertodd> Ha, lovely 12:35 < petertodd> I'll refrain from posting about my genocide coin... 12:36 < gmaxwell> "This is why we are very glad that the SSL used on government census reports does not provide non-repudiation) 12:36 < gmaxwell> " 12:38 < petertodd> yup... 18:17 < gmaxwell> petertodd: thanks for the laugh. 18:17 < gmaxwell> I am now imagining transactions that have spinning hubcaps. 19:08 < petertodd> oh, that's a good idea! 19:09 < gmaxwell> petertodd: you do realize that my covenants thread is largely intended to be a cautionary tale, right? :P 19:10 < petertodd> you've said it before that I am excellent at coming up with cringeworthy ideas... 19:12 < gmaxwell> If I knew a way to forbid perpetual covenants I would, but I'm pretty convinced its impossible short of a freicoin route of forcably recycling coins. 19:13 < gmaxwell> (ones of finite duration, esp one level deep, are insanely useful though, I agree) 19:16 < petertodd> yeah, even the existing scripting system is really close to allowing covenants - it just needs data access to scriptPubKeys, which a modular checksig probably would have given 19:18 < gmaxwell> Some of the script limitations were clearly intentional, though I don't know how much of the covenant like behavior was excluded. 19:20 < gmaxwell> though another point you can take from my message, I think, is that denying covenants is probably moot in the very long term. ... because SCIP is just too compelling, and I'm reasonably sure you can't escape covenants as a side effect. 19:21 < petertodd> yeah, and most of the really nice fidelity bond stuff w/ blockchain support, even without SCIP, was really covenants in disguise, albeit ones that could be special-cased 19:23 < gmaxwell> petertodd: also, wtf, I started working through code for SCIP blinding of fidelity bonds... 19:24 < gmaxwell> Bitcoin makes it FAR more computationally expensive to verify the damn things than it could. 19:24 < petertodd> how so? 19:24 < gmaxwell> The fact that you have to @#$@#$@# fetch the @#$@#$ inputs to fetch the @#$#@$@# values to compute the @#$@# fee. 19:25 < gmaxwell> especially when there could be multiple ones in multiple blocks. 19:25 < gmaxwell> (I realize you can constrain the bond shape to improve this) 19:26 < petertodd> oh, yeah that's why I told jeff to use a anyone-can-spend output 19:27 < jgarzik> I still like miner fees 19:27 < jgarzik> at bootstrap, anyone-can-spend equates to self-payment 19:27 < jgarzik> until miners automate detection and spending 19:27 < petertodd> i say we solve that problem with some bounties :) 19:28 < gmaxwell> I do too, but holy crap. It's a multiplicative increase in sha256 operations. This is probably actually irrelevant for most applications, but for running it under SCIP (to turn your bond into a service specific blinded bond) its perhaps problematic. 19:29 < petertodd> it's a good argument for doing OP_BLOCK_HEIGHT or something 19:29 < gmaxwell> meh. 19:30 < petertodd> gets you down to one tx... 19:34 < gmaxwell> *pop* (the sound of Carlton Banks's head exploding) 19:35 < petertodd> ? 19:35 < gmaxwell> SCIP-covenants thread. 19:36 < petertodd> ah 19:36 < petertodd> "Nakamotish" <- you mean "gmaxwellish"? 19:39 < gmaxwell> I do need to try to extract from Eli's group a simpler explanation for the whole thing, when I talk to people about this stuff the reaction I instantly get is that it can't be possible (they also equally reject PSPACE in IP, just as much and thats a pretty old result now). I can only explain parts of it. And a bunch of this stuff I can kinda explain as interactive proofs but can't bridge the gap to verifyier-oracle secure ... 19:39 < gmaxwell> ... non-interactive. 19:41 < petertodd> for sure, I mean, hell I only claim to kinda understand it because I believe in magic 19:41 < petertodd> I'd love to see a decent visualization of it --- Log closed Wed Aug 21 00:00:27 2013