--- Log opened Wed Sep 18 00:00:51 2013
11:48 < gmaxwell> oh here is an interesting idea for an evil altcoin:  some portion of the coin's supply comes from converting bitcoins... but instead of making you burn bitcoins, thus increasing their scarcity... it makes you turn them into far futured nlocked anyone can spends... so that bitcoin value isn't increased by the removing coins from circulation, since everyone knows that they'll flood back in later.
11:53 < sipa> what's evil about it?
11:57 < gmaxwell> well, not that evil. I don't have _that_ much capacity to think evilly. :P  But it's something of an economic attack, in that it attacks confidence about the level of coin scarcity in the future.  Basically it removes use of bitcoin by removing coins from circulation, but not far enough so that bitcoin is more scarce.
11:57 < gmaxwell> not that different from something like the mastercoin exodus address, but there is no conversion to a private value.
16:08 < warren> did mastercoin actually destroy BTC?
16:11 < jgarzik> I don't know if that's happened..  their protocol described creating unspendable outputs
16:11 < warren> He raised a lot of money for doing nothing.
16:11 < warren> it took us two months to raise 10% that much
16:12 < jgarzik> a fixed asset within a fixed asset.
16:12 < warren> an asset entirely in cash with poor management can be worth less than the value of cash.
16:13 < jgarzik> it can be worth more.  it can be worth less.  yes :)
16:13 < jgarzik> it's basically pybond-like scheme
16:13 < jgarzik> everyone must conform to the additional protocol
16:14 < sipa> he seems to be just using bitcoin as a very expensive replicated append-only log
16:15 < sipa> by encoding data into fake addresses
16:15 < warren> jgarzik: I also wonder if Mastercard will try to crack down with a "confusingly similar" trademark infringement claim
16:19 < gmaxwell> warren: he's destroying very tiny amounts of btc, but his fundraising was just to a vanity address.
16:19 < gmaxwell> (though this was a bit confusingly marketed, at least some people thought the "exodus address" was some kind of special gateway address and not just going into his pocket.)
16:19 < warren> at least prunable?
16:19 < jgarzik> warren, not v1, no
16:20 < warren> fun
16:20 < jgarzik> warren, v2 is multisig, where 1-of-3 is valid, 2-of-3 are data
16:20 < jgarzik> so still bloating UTXO
16:20 < Luke-Jr> jgarzik: but nothing is actually implemented, AFAIK?
16:20 < jgarzik> yah.  people are "working on things"
16:20 < gmaxwell> nothing is implemented but they're still making "v1" transactions by hand using blockchain.info!
16:21 < Luke-Jr> …
16:22 < sipa> jgarzik: but are those outputs actually spent?
16:22 < sipa> the muktisig onea
16:22 < sipa> multisig ones
16:22 < jgarzik> sipa, eventually… creating other 1-of-3 multisig data carrying outputs
16:23 < sipa> ic
16:23 < sipa> that better than unspendable in any case
16:23 < sipa> but i think it's wrong talk about spendable or not
16:23 < warren> sounds like a parasite
16:23 < sipa> it's about whether they're getting spent
16:23 < Luke-Jr> is it doing *anything* that can't be accomplished with merged mining?
16:24 < sipa> i doubt that
16:24 < Luke-Jr> how much did he raise again? <.<
16:24 < sipa> no idea
16:24 < jgarzik> dunno
16:24 < jgarzik> presumably bc.i or be will tell you
16:24 < gmaxwell> ~4000 btc?
16:24 < gmaxwell> 4740 BTC.
16:25 < Luke-Jr> pfft
16:25 < Luke-Jr> give it all to sipa to do the coding for a year
16:25 < Luke-Jr> :P
16:25 < sipa> daaaamn
16:25 < gmaxwell> giving money to sipa would only save the world, not create some toy asset that you can pump and dump.
16:26 < warren> only
16:26 < Luke-Jr> hehe
16:26 < gmaxwell> warren: what, are you some kinda socialist??
16:26 < Luke-Jr> O.o
16:26 < jgarzik> Luke-Jr, well if it follows the pybond pattern, mastercoins are tradeable, normal transactions, with a little bit of protocol-specified data attached.  merged mining would be far less efficient than a simple purchase via atomic coin swap.
16:26 < gmaxwell> It's a joke.
16:27 < Luke-Jr> gmaxwell: I think the lossy IRC lost the humour XD
16:28 < gmaxwell> jgarzik: yea, the zero trusted party atomic coin swap is easer to accomplish with their blockchain fattening approach.
16:29 < gmaxwell> Of course, if you have a trusted party (or even a smart property agent) that is giving value/meaning to the colored coin, then you could instead just instruct it to watch the bitcoin chain for a payment (or show it proof of one) in order to make an atomic transaction.
16:30 < gmaxwell> but if the thing you are trading for is just "mastercoins" then there is no such party.
16:31 < jgarzik> sure, that's a design choice, not having a centralized party ;p
16:31 < jgarzik> you pick a shared protocol rather than a common party
16:33 < gmaxwell> jgarzik: well, not quite— in some cases, e.g. trading shares of some business there actually is a centralized party. Not making use of them doesn't make them stop existing.  Most of the colored coins usecases are like that.
18:17 < amiller> "<sipa> he seems to be just using bitcoin as a very expensive replicated append-only log"
18:17 < amiller> yeah.
18:18 < amiller> i think things like that will happen more until bitcoin prices them out somehow, you can't prevent someone from putting the junk data in there if they want to otherwise
18:18 < sipa> well... texhnically, so is bitcoin
18:18 < amiller> all the colored coin schemes are defective for the reason that they don't put any data in the utxo
18:18 < sipa> it's alao using the blockchain as an exensive replicated log
18:18 < amiller> so no one really has any incentive to actually maintain the indexes that will be needed to prove things
18:19 < sipa> hmm, how do you mean?
18:19 < sipa> they need an annotated utxo set
18:19 < amiller> suppose i want to do a complicated mastercoin query
18:19 < amiller> yeah
18:19 < amiller> they have so much functionality that they will need a whole giant sql database
18:20 < amiller> a lot of work (well, you in particular do all of it :p) goes into keeping the utxo managable sized
18:20 < amiller> which is good because everyone replicates it
18:20 < amiller> but only "mastercoin" nodes will replicate the special mastercoin indexes, which will probably be enormous
18:21 < sipa> well, right now everyone with the UTXO set also has the blockchain
18:21 < sipa> so people are not pointed to the fact that they have very different replication needs
18:21 < amiller> yeah but if i want to answer a mastercoin query i might have to go take a very long walk through it
18:21 < gmaxwell> yea, the functionality they have described requires doing O(N^2) accesses to the set of all existing mastercoins. There isn't even an O(mastercoins) way to get just a list of currently existing mastercoins.
18:22 < sipa> oh my
18:22 < gmaxwell> And can't be. Even if the mastercoin is in the UTXO and you have a UTXO proof, you still need to do the history tracing unless nodes enforce the mastercoin rules on the UTXO.
18:22 < amiller> they're bolting on functionality left and right, it's a whole spreadsheet application
18:22 < sipa> i'm suddenly not worried about it anymore
18:23 < gmaxwell> basically all the colored coins proposals have these problems.
18:24 < gmaxwell> bitcoin at least gets you a computationally cheap verification because you can forward produce your own utxo. Mastercoin could do that too but you'd need special mastercoin nodes that examined the whole blockchain and built mastercoin indexes.
18:24 < sipa> i always imagined colored coins schemes as just augmenting the utxo set, with a "colors" tag for each coin
18:24 < gmaxwell> sipa: yea but mastercoin's "feature" list has things like automated trading with an orderbook in the blockchain.
18:25 < gmaxwell> so you'd have to do order matching against all the eligible coins...
18:25 < sipa> uhhhh
18:25 < amiller> no one is going to realize/notice/viscerally feel the problem until it's filled with junk and no one can afford to run a full mastercoin node and so everyone's security relies on checking mastercoinexplorer.info
18:25 < gmaxwell> and supporting multi-leg trades, like my 1 btc for your 1 mcUSD for amiller's 1 mcLTC.
18:26 < sipa> amiller: and i'm sure mastercoinexplorer.info will just scrape blockchain.info :)
18:26 < amiller> well that's not sufficient
18:26 < amiller> i mena
18:26 < amiller> it will have to maintain its own ridiculous index
18:26 < amiller> in addition to scraping
18:26 < amiller> good thing they've raised enough money to afford one instance of that for a cuople years!
18:26 < gmaxwell> amiller: the funny thing is that they'll probably be fine with that. Annoyingly the'll shit all over the distributed system instead of just putting all that centeralized stuff in a central place to begin with.. just because the pretext of decenteralization raises money.
18:26 < sipa> they may come up with some checkpointing scheme, that includes the "index"
18:28 < amiller> opencoin/ripple also has this problem
18:28 < amiller> it just sucks that eveyrthing will seem like it's working as long as not too many people use it and no one minds that only a few people run nodes
18:30 < amiller> it wont crumble until it has a SatoshiDice moment
18:30 < gmaxwell> Centeralized systems (even ones pretending not to be) are just fundimentally easier.  It won't even crumble in that case, just throw more resources at it.
18:30 < amiller> bitcoin hit that hurdle and just leveled up, so to speak
18:31 < amiller> so suppose they're centralized (but no one notices because of confusing greypapers) and reasonably efficient as long as you don't run a full node, will they just gain users until there's an actual security breach or something?
18:32 < sipa> the problem is that centralized systems are superior in pretty much every technical way
18:32 < sipa> apart from required trust
18:35 < amiller> maybe the bitcoin community will end up developing an offensive capability that basically compromises centralized systems quickly to make it apparent that they're vulnerable
18:35 < gmaxwell> amiller: Pretty much, I think.  I mind this less when they haven't adopted a story that requires them to store data in bitcoin.
18:36 < amiller> well we have to figure out how to a) make them pay for their utxo usage over time and b) also charge people for archive access to old blocks
18:36 < gmaxwell> charge for archive access to old blocks kind of undermines the bitcoin security model. :(
18:37 < gmaxwell> You can't determine if your on the longest valid chain without inspecting the historical chain, and we're an anonyous system which new people should be able to join…
18:37 < amiller> well you can bittorrent it, just takes a while
18:37 < amiller> it's already pretty expensive in a batch
18:37 < gavinandresen> Hey wizards: I need to recruit a couple of people to help review technical-focused Foundation grant proposals.  Anybody have a little bandwidth to help? (I don't want to be Grant Gatekeeper)
18:43 < petertodd> Oh, there are tech-focused ones?
18:44 < gavinandresen> petertodd: sure, I think you proposed one first round.
18:44 < gmaxwell> gavinandresen: Being gatekeeper stinks!
18:45 < gmaxwell> "Emperor of broken dreams" has a much better ring to it.
18:45 < petertodd> gavinandresen: oh, tpm hardware? that probably should be taken off the list as it'd duplicate other peoples efforts
18:47 < gavinandresen> that's one of the reasons I want to get a couple more people involved in review; I can't possibly keep track of everything happening, and more people means more "don't fund that, Jehosephat announced a similar project last week..."
18:47 < petertodd> agreed
18:47 < gavinandresen> to be clear: the Foundation Board are the ultimate gatekeepers who decide how much money to grant.
18:48 < gmaxwell> I'm willing to review things (and I suppose am at least somewhat likely to notice overlapping efforts), esp. with the point that its really someone else in the buck-stops-here position.
18:49 < gavinandresen> gmaxwell: great!
18:50 < amiller> i'm volunteering to review too, i like having excuses to dredge through the forums looking for related work
18:50 < gavinandresen> gmaxwell: you going to submit a dust-buster grant proposal this time around?  No impact on review, you'd just abstain from reviewing your own proposal....
18:51 < gmaxwell> hurrah.
18:52 < gmaxwell> Thanks for the reminder.
19:47 < jgarzik> gavinandresen, I'm willing to help, too
19:47 < jgarzik> gavinandresen, just never responded to your email asking
19:48 < gavinandresen> jgarzik: no worries
--- Log closed Thu Sep 19 00:00:55 2013