--- Log opened Sun Jan 05 00:00:55 2014
00:02 < grau> petertodd: thereby you would raise production cost of e.g. water heater. Competition in water heater would eliminate that.
00:02 < petertodd> grau: if crypto-coin mining has a value, and heating water has a value, then you're cost for doing both at once is less than separating the two activities
00:04 < grau> You assume that water-heater mining is profitable to the extent that it ever amortizes the added production cost. That is not given.
00:06 < petertodd> grau: my point is if bitcoin mining is profitable, it'll be more profitable if you can use the waste heat for something useful. using waste heat for something useful is easier with more decentralization than less
00:08 < grau> There are places where getting rid of heat is not a big issue. I think you engage a bit in wishful thinking. We should rather think hard of how to deal with centralized mining.
00:09 < petertodd> grau: yes, and those places are always decentralized! it's just the basic physics of heat: surface area scales by x^2 and volume x^3
00:10 < grau> iceland
00:10 < petertodd> grau: obviously bitcoin mining will tend towards more northern places, but there's a whole lot of those around
00:11 < gmaxwell> 21:07 < NomZ> You all will love this one. The dogecoin blockchain split after someone submittted a 500M transaction.
00:11 < petertodd> grau: my parents live in a place significantly colder than iceland...
00:12 < grau> petertodd: wow, send them some boxes to mine :)
00:13 < petertodd> grau: yeah, I've done the math on that, it actually makes quite a lot of sense. furthermore in communities north of them the high cost of electricity is *not* a factor because the electricity generation is all diesel anyway, and diesel's more expensive (slightly) than fuel oil
00:13 < grau> gmaxwell: tomorrow you'll have lots of journalists asking if this could happen to BTC
00:15 < brisque> grau: not having scrollback to refer to, can you give me a one line summery of what you're referencing?
00:15 < gmaxwell> http://www.reddit.com/r/dogecoin/comments/1ufl1e/much_concern_dogecoin_block_chain_has_split/cehm0yw
00:16 < brisque> gmaxwell: ouch. I suppose that's what you get when you have inexperienced developers managing a bitcoin clone.
00:16 < petertodd> gmaxwell: heh, yeah warren noticed that awhile back
00:17 < andytoshi> petertodd, warren: oh? what is special about this 500m tx?
00:17 < Luke-Jr> lolwut @ font
00:17 < petertodd> andytoshi: it triggers some sanity limits that they recently removed
00:17 < brisque> andytoshi: the title of the thread has the details. some clients accept larger amounts in blocks than others.
00:17 < warren> andytoshi: competence
00:18 < brisque> "Ten days ago, the developers made a change to the Dogecoin client that raised the limit of coins in a block from 500 million to 10 billion. So now some folks are running Dogecoin clients without that change, because they are older, and some folks are running newer clients. In block 42279, a transaction that broke the rule -- containing more than 500 million DOGE -- has prevented these older clients from advancin
00:18 < warren> did the pools upgrade?
00:18 < gmaxwell> .... wtf they didn't stage the change?!@#
00:18 < andytoshi> holy shit, this is so incompetent i can't believe it, even from doge
00:19 < brisque> presumably one pool updated, then the big TX made it into a block and the chain forked
00:19 < gmaxwell> well we learned nothing then, as we've succesfully made a number of changes that would have been forking if not staged.
00:20 < brisque> warren: from looking, there's some on one fork and some on another. presumably anybody on the old client has been left behind and that's the majority at this point.
00:20 < andytoshi> it appears they just pushed a forking change in a routine update? what the fuck?
00:20 < nsh> my hilarity sense is tingling...
00:20 < warren> three forks exist?
00:20 < warren> not sure how
00:20 < warren> but it's hilarious
00:21 < nsh> oldyellercoin....
00:21 < brisque> they might have changed the TX limit previously without making it a staged change.
00:21 < andytoshi> well, i'm going to move to #bitcoin..
00:21 < warren> andytoshi: that update was to stop a massive dust attack.  they had a mintxfee of 0.0001 when coins were very plentiful ... much hilarity
00:22 < gmaxwell> andytoshi: yea, it'll keep creating more forks if the non-acceptable-to-all-nodes chain has a majority hashpower.
00:22 < andytoshi> oh man, such wow
00:22 < gmaxwell> er "acceptable-to-all-nodes"
00:22 < gmaxwell> not non-.
00:22 < gmaxwell> if the non-acceptable has a majority then you'll get exactly two.
00:23 < warren> how do I format a mocking doge message to post in litecoin dev news
00:23 < petertodd> warren: heh, I wish I had the time to add really easy multi-currency support to python-bitcoinlib to make writing attacks for non-btc crypto-coins easier...
00:23 < grau> gmaxwell: there could be a lesson for us in this. Let's see how the worst case unwinds.
00:23 < gmaxwell> if the acceptable to a majority has a majority you'll get constant reorgs and more forks but most will be short.
00:23 < Luke-Jr> gmaxwell: I thought you left? :P
00:23 < warren> petertodd: you're sitting on a lot of unearned funding...
00:23 < gmaxwell> grau: things like this have happened with smaller alts before, they just release another version and tell everyone to hurry up and upgrade. And because there is no major economic activity no one cares and its forgotten.
00:24 < brisque> presumably they aren't using the alerts system to notify clients because they didn't change the key from Litecoins.
00:24 < petertodd> warren: one of the reasons I'm not working on python-bitcoinlib...
00:25 < petertodd> warren: and for that matter, why I quit the day job (mastercoin was just good luck)
00:25 < andytoshi> i like how this happened less than a hour after i decided to write an alt faq
00:25 < andytoshi> brisque: classic
00:25 < warren> I need a doge speak primer to format the mocking message properly.
00:26 < grau> I regularly write doge, without intent :)
00:27 < petertodd> warren: verb noun, verb noun, verb noun etc. (all lowercase) make the layout alternate sides, but not symmetrical.
00:27 < brisque> https://github.com/dogecoin/dogecoin/commit/2ee5cb3396df66c10fef34480a183d00e3bec635
00:27 < brisque> ^ that's the forking change, if anybody was curious
00:27 < petertodd> specifically the change to the definition of MAX_MONEY
00:28 < brisque> https://github.com/dogecoin/dogecoin/blob/94b99f5cc7d997d9c656b9d08ce5f74caa6a3ec3/release/dogecoin.conf
00:28 < gmaxwell> wtf they totally did just change max_money, halarious.
00:28 < brisque> what's with the hardcoded RPC password?
00:28 < warren> prior to making that change they e-mailed me asking for help
00:28 < brisque> default rather, not hardcoded.
00:28 < gmaxwell> worse than I guessed, initially I thought perhaps not all instances of max money were made into the define and they only got one right.
00:28 < gmaxwell> "Fix dust issue" misleading commit message too
00:28 < warren> I didn't intentionally not respond, I was sleeping the entire time including that commit.
00:29 < petertodd> lol "
00:29 < petertodd> wallet_bgcoin.png should not be modified on every release, as it would increase the size of the repository time by time...
00:29 < gmaxwell> and the commit was by " dogecoin " no actual attribution.
00:30 < warren> I didn't verify this, I was told one of the dogecoin devs is an engineer at IBM.
00:30 < brisque> oh, so Dogecoin is a fork of "Linkcoin" rather than Litecoin?
00:30 < petertodd> ha, and dogecoin doesn't sign their commits
00:30 < petertodd> or even tags
00:31 < petertodd> warren: they do have an android client on the front page though
00:32 < brisque> petertodd: and a web wallet.
00:32 < warren> brisque: not all that different from most coins.  people mine directly into an exchange wallet.
00:32 < petertodd> brisque: with twitter bootstrap like the big boys!
00:35 < grau> Alt holdings could wash to BTC now en masse.
00:37 < warren> https://plus.google.com/+LitecoinOrg/posts/3iVBu7bC1h6  <--- this is the best I could do
00:37 < petertodd> warren: lol
00:37 < grau> :)
00:41 < brisque> there's a comment in that reddit thread asking the developer to use the alerts system to notify people, the response is "in good time"- they definitely can't because they don't have litecoin's alert private key.
00:42 < warren> they actually copied our alert key?
00:43 < andytoshi> i bet "in good time" means "when a litecoin dev names his price to sign an alert for us"
00:43 < brisque> warren: https://github.com/dogecoin/dogecoin/blob/2ee5cb3396df66c10fef34480a183d00e3bec635/src/main.h#L1589
00:43 < warren> andytoshi: can't do that.  that alert would be on our network too.
00:43 < brisque> andytoshi: http://www.reddit.com/r/dogecoin/comments/1ufl1e/much_concern_dogecoin_block_chain_has_split/cehkh91?context=1 (I misremembered, that quote wasn't verbatim)
00:44 < warren> andytoshi: litecoin's alerts already jumped onto 20+ clone networks
00:44 < petertodd> warren: isn't dogecoin on 0.6? could limit display to just 0.6
00:44 < andytoshi> warren: oh, i thought because the nodes won't talk to each other litecoin would be isolated
00:44 < brisque> andytoshi: they would be isolated until someone just manually transported the alert to litecoin and made a mess.
00:45 < andytoshi> brisque: yeah, i realized that as soon as i typed that
00:45 < brisque> andytoshi: if I've read right, some people on bitcointalk have designed their systems to go into a safe mode when they see an alert on the network too
00:46 < warren> litecoin does regular alerts for color changes, so they shouldn't be surprised.
00:46  * warren is exaggerating, a little.
00:48 < petertodd> I like how in the reddit thread about the dogecoin split, specifically warning people not to send dogecoin during the split, people are tipping each other like crazy...
00:50 < brisque> petertodd: it's fairly obvious that the community has no clue what they're doing. the "co-founder" is saying everything is fine and they had 10 days to update (not realising that as soon as they made the commit the network could have been split {if anybody actually builds from master and runs it behind something})
00:51 < petertodd> brisque: and with their fast block rate and fast diff adjustment we can see first-hand what forks look like when coinbase payouts are destroyed!
00:51 < andytoshi> brisque: where are these claims being made?
00:52 < brisque> andytoshi: http://www.reddit.com/r/dogecoin/comments/1ufl1e/much_concern_dogecoin_block_chain_has_split/cehkbm8 and there's other bits scattered about the thread
00:53 < andytoshi> i love the talk in that thread about the "real chain" and "bad chains"
00:53 < andytoshi> apparently they have a reddit-based consensus system now..
00:54 < petertodd> BlueMatt: ^ there's an option for the coingen!
00:54 < petertodd> "So, now what do we do? Is there someone who is in charge of maintaining the blockchain?" <- lol
00:55 < brisque> petertodd: I would absolutely love to have a real time visualisation. connect to multiple nodes on different forks and watch them race. the short block time for make for an incredibly interesting display.
00:56 < petertodd> brisque: it'd be extra fun if someone decided to DoS attack the network right now
00:58 < warren> petertodd: coingen.io is for sale
00:58 < brisque> petertodd: I doubt they need it really. the network is so fragmented and so little actually relies on Dogecoin that the entire system will likely just collapse.
00:59 < petertodd> brisque: I sure hope so, but good luck on that...
00:59 < petertodd> brisque: communities of people around a technology that doesn't actually need to work for the community to exist can be surprisingly durable
01:01 < brisque> petertodd: I suppose, if they don't understand as a whole how bad this situation is then it won't collapse. strange situation. it's a bit like NXT supporters still being optimistic when their closed source currency posted it's source.
01:02 < petertodd> brisque: well remember the "situation" is they have a fun meme and a community built around that meme. if anything the problem is just as likely to get *more* people interested in dogecoin
01:04 < andytoshi> well, as fun as this is to watch, i've got an early flight tomorrow
01:04 < andytoshi> have a good night guys
01:05 < brisque> petertodd: like all "memes" the velocity will die off (if it isn't already).
01:05 < andytoshi> petertodd: i'm going back to austin, vancouver is freezing !!
01:05 < petertodd> brisque: sure, but that die-off may have little to do with tech
01:05 < petertodd> andytoshi: ha
01:05 < petertodd> andytoshi: pretty though :)
01:06 < andytoshi> that's true, i'll miss it
01:06 < brisque> petertodd: the meme is already losing staying power, it could just be that massive incompetence and forks is enough to destroy the coin as well. http://www.google.com/trends/explore#q=doge%2Cdogecoin
01:07 < brisque> http://www.google.com/trends/explore#q=doge%2C%20dogecoin&date=today%2012-m&cmpt=q
01:08 < brisque> that's a much better graph.
01:16 < warren> this fork didn't seem to affect its exchange rate
01:17 < brisque> logically exchanges would have closed their doors temporarily when they saw the network wide alert about the chain fork (haha). they risk double spends if they don't.
01:18 < warren> I'm just pointing out that networks being reliable has nothing to do with alt value.
01:19 < brisque> alright, I agree.
01:27 < nessence> it is near ~midnight throughout most of US on a saturday
03:06 < warren> petertodd: ooh... with the dust spam attack, I wonder if their massive reorg triggered the BIP50
05:08 < brisque> looks like dogecoin released another update that adds check pointing to try and get around their hardforks issue.
05:08 < brisque> confusingly in two commits "checkpoint" and "checkpoints".
05:09 < gmaxwell> brisque: oh boy, did they back out the change?
05:10 < brisque> they did not.
05:10 < gmaxwell> if not they may be for a helluva ride as the hashrate majority when I looked _appeared_ to be on the acceptable-to-all fork
05:11 < gmaxwell> who the heck knows what happens if you upgrade to code that imposes a checkpoint you've long since violated and you don't reindex.
05:12 < brisque> the commit only checkpoints two very late blocks, but I'm not really sure how the behaviour works
05:12 < brisque> https://github.com/dogecoin/dogecoin/commit/dab72582b657395a25e25f4ea367b8b8990db460
05:13 < brisque> in the first commit they only checkpoint the later block *after* the fork, but wisely added a checkpoint for the forking block later on.
05:13 < gmaxwell> this sounds like a bad idea, if the hashrate majority is on the old stuff, they'll keep on trucking. If its on the new stuff, they didn't need the checkpoint at all.
05:15 < brisque> from their IRC (signal to noise was off the chart, it was hard to tell) the older branch had the majority and was overtaking the newer clients with the forking change. as the original instructions from the developer were to upgrade at all costs, I guess they just went with it.
05:15 < gmaxwell> also if you upgrade a node already past the checkpoint on the non-checkpointed chain, it's not going to reorg on its own unless you do a reindex.
05:16 < gmaxwell> seems like a really bad plan to me, since they won't know for sure if they'll actually get the majority to switch fast.
05:16 < gmaxwell> so it might make a huge reorg days later...
05:19 < brisque> I'm not sure it was thought through that much, from talking to the developer before he was certainly trying to grapple with what was going on, but doesn't have that much experience with the finer points.
05:20 < gmaxwell> my strategy would have been to revert the change, set the change to trigger in the future, checkpoint the chain everyone can accept. release and nag everyone to upgrade to that.
05:21 < brisque> sounds familiar.
05:21 < gmaxwell> that would avoid any (further) reorgs assuming the hashpower majority was already on the generally acceptable chain.
05:21 < gmaxwell> it's even _better_ than when we did it in bitcoin, if the hashpower majority is on the generally acceptable chain most of the time.
05:22 < gmaxwell> (bitcoin was screwed because there was a decisive hashpower majority on a chain the majority of nodes would reject)
05:24 < brisque> handled with relative grace given the circumstances. it would have been harder with a majority p2pool, but significantly easier now that we have two pools with a majority hashrate.
05:26 < gmaxwell> well it wouldn't have happened at all really with p2pool. majority of nodes were not on the fork creating version we would have just gotten a _single_ orphan block out of it and probably not noticed the event. :( (if thats good or bad it's unclear!)
05:27 < gmaxwell> it's actually an interesting question if the BIP50 fork actually happened earlier and we missed it because the old chain got ahead fast enough.
05:28 < brisque> the 0.8 chain was from a single pool wasn't it?
05:29 < brisque> wouldn't they have notice the sudden increase in orphaned blocks?
05:29 < gmaxwell> no, its was from two primarily.
05:29 < brisque> BTCGuild and Slush, got it.
05:29 < gmaxwell> brisque: I mean in a hypothetical world where hashpower wasn't consoldated at a big pool...
05:30 < gmaxwell> the trigger was pretty hard to hit, we went for months before triggering it again after the large blocks were allowed again.
05:30 < gmaxwell> I think we've triggered large numbers of unpatched 0.7 nodes to misbehave only twice since.
05:30 < brisque> so 0.7 clients without a modified database configuration are permanently orphaned now?
05:30 < gmaxwell> no because its non-determinstic.
05:30 < gmaxwell> the last time apparently got a lot of them though.
05:31 < gmaxwell> I'd bet you could sync a new one from start successfully now though.
05:32 < gmaxwell> if instead the <0.8 nodes solved two blocks before the 0.8 only chain got a second, it would have just been orphaned and probably no one would have noticed, since that orphan producing 0.8 node would likely have not triggered it again with its next block.
05:32 < gmaxwell> (as some portion of its txn would have been included on the <0.8 chain.)
05:33 < brisque> I've a few 0.7.99 clients at the current highest block, so you're likely right with that.
05:34 < gmaxwell> 0.7.99 = 0.8 for this purpose.
05:35 < michagogo|cloud> 12:26:40 <gmaxwell> well it wouldn't have happened at all really with p2pool. majority of nodes were not on the fork creating version we would have just gotten a _single_ orphan block out of it and probably not noticed the event. :( (if thats good or bad it's unclear!)
05:36 < michagogo|cloud> Bוא 'םוךגמ,א איק ארדשמדשבאןםמד ישהק קמגקג ופ ןמ איק צקצפםםךד םכ איק ופערשגקג מםגקדת עקאאןמע רקצןמקג שעשןמ שא קשבי נךםבל אישא שמ ופערשגקג מםגק צןמקג?
05:37 < michagogo|cloud> Gah, I hate when that happens
05:39 < michagogo|cloud> But wouldn't the transactions have ended up in the mempools of the upgraded nodes, getting remined again at each block that an upgraded node mined?
05:41 < gmaxwell> michagogo|cloud: yes, creating single height forks which wouldn't continue (far) if they were in the minority, and would stop if they restarted, and would stop if they switched to the latest build. and since they were already running the latest code, there is a prior probablity that they're likely to upgrade.
05:45 < michagogo|cloud> gmaxwell: Sure, but it wouldn't just be a single block, it would be a bunch of 1-deep forks, and I think "oh, I stopped getting doges for my mining" would have lead to it being noticed
05:50 < gmaxwell> michagogo|cloud: I think you're splicing two discussion now.
05:50 < gmaxwell> not being noticed was a comment on the bitcoin pre-0.8 vs 0.8 hardfork
05:50 < michagogo|cloud> oh
05:50 < gmaxwell> which wouldn't have likely retriggered.
05:50 < michagogo|cloud> ...right, sorry
05:51  * michagogo|cloud rereads
05:51  * michagogo|cloud goes back into his corner
07:47 < adam3us> i liked jtimon's use of the word scamcoin to cover param-tweaks.  i do think we need a clear tone setting term for param-tweaks vs actual alts, the scam coins are unduly dirtying even the concept of alts; alts with actual innovation could be useful things;  as we've discussed btc pegged side-chains are good for some types of things, but actualy experiments in proof of work, economics may not be possible fit into that model
07:49 < brisque>  adam3us: what do you call things like Primecoin and NXT? they're not parameter tweaks, but still not sane things to be promoting. as soon as you create differentiation you end up encouraging one over the other.
07:49 < adam3us> (and btc pegged side-chains have some technical and game-theory open questions, though its' an idea I find interesting and perhaps of great value to bitcoin ecosystem so eg we can run bitcoin 0.x and bitcoin 1.x in parallel, or competing bitcoin 1a.x and bitcoin 1b.x
07:50 < adam3us> brisque: yes i do wonder about that.  as i said on a private chat prime coin is pretty close to another scam coin.  the paper talking about the scientific method is not credible.  it doesnt benefit the world to search for pairs of mid-sized priimes any more thn searching for hashcash stamps for the bitcoin stamp-collection
07:51 < sipa> i also believe not all "silly" altcoins are intended as scams
07:51 < brisque> I'd have to check, but I'm sceptical that their prime searching thing is reliable as a hash too.
07:52 < adam3us> you know i think momentum PoW might actual have some utility, the paper describing it is undefined/ambiguous on most of the critical issues; but i think reverse engineering it it might actually be an interestingly step towards a memory hard pow that doesnt require memory to verify (despite failing multiple other features he set himself)
07:53 < brisque> sipa: it might not be intended that way, but anybody looking at the Alternate Cryptocurrencies subforum should certainly be able to work out what's going on.
07:53 < adam3us> sipa: yeah scam might be the wrong word.  i just think we owe like jtimon & maaku credit for having a non scamcoin, and just ranting against alts unfairly taints their freicoin economic experiement
07:54 < sipa> there are really many cases
07:55 < sipa> of coutse, a ton of silly alts (just tweaking some parameters)
07:55 < adam3us> brisque: there can be a difference between ooh make-money-fast, missed the bitcoin bubble, maybe i too can get some small early-adopter mining/premine mentality which isnt exactly a scam (otehr than egregious premine) but an attempt to get rich now that the proof has been given over 3 years of high uncertaint with bitcoin bootstrap that crypto currencies can bootstrap
07:55 < sipa> there are some that try to address a different problem (namecoin, datacoin)
07:56 < sipa> some are failed experiments on their own (litecoin as gpu-resistant pow perhaps)
07:56 < sipa> ppcoin was interesting, but flawed imho
07:56 < adam3us> and it can be somewhat hard to untangle.  like if coingen succeeds in squelching param tweak,s maybe the people who can use a compiler enough to not need a hosted compiler will then just try harder to make a story
07:56 < brisque> adam3us: yes, but that said you don't want to be promoting NXT. it isn't a parameter swap but it's ridiculously insecure.
07:56 < adam3us> sipa: that probably becomes the new min-bar for "innovation"
07:57 < adam3us> brisque: very true.
07:57 < sipa> i've long been thinking about creating my own altcoin
07:57 < adam3us> see we have like "moron coins" and "good coder but crypto/distrbitued system incompetent" coins and usually a lot of greed and a bit of scam mixed in
07:57 < sipa> to fix all things that are wtong in bitcoin :)
07:58 < sipa> but time...
07:58 < adam3us> sipa: yep, everyone thinks about it, i thought about it also
07:58 < brisque> I take the primecoin comment back, it seems to be semi-sane but the "work" it's producing is just as useless as anything else.
07:58 < sipa> yeah
07:58 < adam3us> brisque: no there is something wrong with primecoin, algorithmically; its not exactly progress free and the probability distribution is slightly wrong i think
07:58 < sipa> adam3us: i'd probably implement most of it from scratch, though
07:59 < brisque> adam3us: on my first read I thought the work was based on a 32bit hash, but it's not. I haven't looked any further than that.
08:00 < brisque> sipa: why wouldn't you? there's lots of little niggles in Bitcoin that could be fixed with a complete rewrite.
08:00 < adam3us> sipa: yes that is actually what got me to thinking about 1-way pegged side-chain and i presume BlueMatt/gmaxwell about 2-way peg was that it makes more sense to respect the initial bootstrap as a one-off event, the it becomes possible to do significant innovation, overhauls, re-writes without having the barrier to actual adoption of a new digital scarcity
08:01 < sipa> brisque: not following, i'm saying i prefer to total rewrite over patching
08:01 < brisque> sipa: I'm agreeing with you.
08:01 < sipa> ok
08:02 < adam3us> the only other people i saw who even tried to tone down the "make money fast" motivation (which is actually a smart thing to tone down for adoption)  were jtimon & maaku, there was like a charitable donation, and a temporary but modest (i think?) development fund, plus the new economic bit about demurrage
08:03 < sipa> maybe ironically, i just don't care about economics much
08:03 < adam3us> sipa: yeah the thing that i find awesome about 1-way or 2-way pegged side-chain (if we can figure out the details) is that it fully allows major feature experiments, securely
08:03 < sipa> adam3us: link?
08:04 < adam3us> ohh i am not sure there was a 1-way peg write up on bitcoin-dev, one sec for link; 2-way was a thread on here, been meaning to update the email thread with that discussion
08:04 < sipa> one way pegging through burning bitcoins to create coins in another system seems simple enough
08:04 < sipa> being able to go back... i don't see how
08:05 < adam3us> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02945.html
08:05 < adam3us> thats the 1-way
08:06 < adam3us> sipa: so the 2-way works if  you make changes to bitcoin 0.9x to honor transfers back.  but only once for previous transfers out.  in that way the security is limited to damange ONLY the current holders of transferred out bitcoins (if security issues appear on bitcoin 1a.x)
08:07 < brisque> adam3us: so you would have coinbase TXs without a block, sorta?
08:08 < sipa> i don't understand
08:08 < sipa> you send a coin to a dead address to instantiate it in betacoin
08:09 < sipa> how do you turn it back into a bitcoin coin?
08:14 < adam3us> sipa: sorry about that free airport wifi expired… onto the next laptop
08:15 < adam3us> sipa: the reason i thought 1-way peg is interesting is i was frustrated about adoption rate of simple (but soft/hard-forking) clear improvements to bitcoin (of which i think there are many)
08:15 < adam3us> sipa: so i though 1-way peg servers as a security insulator and doesnt require bitcoin 0.9x changes (which was the bottleneck i was trying to think of a way to unblock)
08:16 < sipa> i'm not following what you're talking about now
08:17 < adam3us> brisque: "coinbase tx without a block" no the pegged side-chain would have no reward mining (that would be done via transfer/destruction on bitcoin main) but it would have tx reward (denominated in btc)
08:18 < adam3us> sipa: did u skim the url about bitcoin-staging?  which bit of the above?
08:18 < sipa> adam3us: sorry, your mails are too long :)
08:18 < adam3us> sipa: yeah i tend to write tldr stuff oops.
08:19 < adam3us> sipa: so i guess we agree that there are a number of things that could be simply fixed, but arent worth the security/value risk of soft/hard forks, and interesting features to enable
08:20 < sipa> it depends whether it's about things that could reasonably once be enabled in bitcoin itself
08:20 < adam3us> sipa: (eg enable some more scripting, or change it so the value is signed - which bites trezor & offline armory)
08:20 < sipa> yeah
08:20 < sipa> that stuff is fine
08:21 < sipa> but things like utxo-walking pow, or transactions committing to a particular chain, or tx fees that are spread over multiple blocks
08:21 < sipa> i doubt those can be considered "bitcoin"
08:21 < adam3us> sipa: so its not exclusive right, there can be a bitcoin 1a.x bitcoin 1b.x etc which are competing pegged side-chains … if maaku & jtimon want to go implement the freimarket script extensions on one thats cool.  another one can focus on shorter term fixes like the above.  maybe bitcoin might merge some of them later or switch over bitcoin to 1c.x if users demand it and move everything to 2.x
08:23 < adam3us> sipa: well i think the interesting thing to preserve if people are genuine about wanting to move the tech forward is the digital scarcity definition.  eg one can preserve bitcoin 0.9x as the only reward miner, that way it respects the 21 mil coin limit, and people can innovate on an existing currency base (which i do not  think its reasonable to attempt to restart)
08:23 < sipa> i don't want 1-way pegging, as it means you have to burn (valuable) bitcoin to obtain a potentially worthless successor coin
08:24 < sipa> if you kbow a way to do actual two way pegging, i like to hear it
08:24 < adam3us> sipa: so whether its a rewrite or just enabling queued simple/nice things or some script/market experiment… that can all be done on competing pegged side-chains. they can interoperate if you can move coins back (via main)
08:25 < sipa> (in a way that doesn't force the side chain to be very compatible with bitcoin, as that would limit the degree of innovation there)
08:25 < adam3us> sipa: i think the main limitation is you have to enforce security so that security/value bugs in the side-chains can not leak back into bitcoin main.  for more adventurous things (utxo walking pow)) you'd probably have to make do with a 1-way peg
08:25 < sipa> right, of course
08:26 < adam3us> sipa: yes.  2-way peg is far nicer as nothing is destroyed, just moved.  just pointing out the limits with 2-way tieing back to the more adventurous changes that cant easily say preserve a security/value firewall because the value definition is too redefined
08:26 < sipa> right
08:27 < sipa> there is of course the centralized approach using an exodus address which has an actual private key known to some people
08:27 < sipa> but that already smells way too scammy
08:28 < brisque> smells like mastercoin to me.
08:28 < adam3us> sipa: so gmaxwell & BlueMatt were exploring using SPV security from the merge mined 1:1 pegged side-chain (with a long conf time like 100blocks) .  even that is pretty complex.  i guess we'd have to explore that first before figuring out if you can go further and two-way peg something with quite different value semantics
08:30 < adam3us> sipa: maybe you can do something, the main point being that nothign must be possible to move back from the side-chain twice.  ie it must be tied back to the demonstrable ownership (in SPV model say) of a previous bitcoin that was destroyed, and then allowed (once) to be recreated (though the cycle could repeat, it must be allowed once in each cycle)
08:31 < gmaxwell> the key observation in that discussion that I came to was that it doesn't really matter if the value transfer mechenism is very slow (e.g. taking many blocks), because you could just do regular atomic coinswaps so long as the liquidity on each side was reasonably balanced, you only need the direct chain moves to move funds without a counterparty.
08:32 < adam3us> gmaxwell: yes i agree with that.  its the expectation of later fairly certain settlment, market can do the rest (pay day loan for the impatient)
08:33 < adam3us> gmaxwell: sipa was wondering if more esoteric/bigger value definition/ownership changes could be two-way pegged "sipa: if you kbow a way to do actual two way pegging, i like to hear it
08:33 < adam3us> (in a way that doesn't force the side chain to be very compatible with bitcoin, as that would limit the degree of innovation there)"
08:34 < adam3us> sipa: even if it were not (significantly) possible, just a two-way peg could allow quite a lot of new parallel development flexibility and innovation on existing value base.  that alone is a big project.
08:35 < brisque> if a two way peg were possible namecoin would be a lot more interesting.
08:36 < gmaxwell> brisque: no thats not possible.
08:36 < sipa> souns like that requires every utxo in the beta currency to be backed by a bitcoin utxo
08:36 < gmaxwell> namecoin already exist.
08:36 < adam3us> sipa: (another change would be like the tagging of additional meanings directly on the side chain rather than coloring; freimarkets proposes tagging, and its better than coloring as coloring is i think inherently SPV incompatible, and tends to spam the bitcoin network)
08:37 < gmaxwell> sipa: not quite, perhaps someone should go extract that conversation from logs.
08:37 < brisque> gmaxwell: well yes, unfortunately.
08:38 < brisque> gmaxwell: not sure anybody would argue that the project isn't stale though.
08:38 < sipa> well if you can create a bitcoin output script that requires a proof of transfer through betacoin and back... ok
08:38 < gmaxwell> sipa: in any case, basically you add a softforking change to bitcoin that lets you write txouts which can be spent according to terms that come with SPV-like proofs from the other chain.
08:38 < gmaxwell> right.
08:38 < sipa> but SPV proofs cannot prevent double spending
08:39 < sipa> and it is limiting in the sense that it requires encoding some basic form of betacoin's transfer rules in bitcoin
08:39 < gmaxwell> no no,
08:40 < adam3us> for my part i think 1-way (and more practically 2-way) pegged side-chain is the best new bitcoin idea of 2013.  i hope its possible.
08:41 < gmaxwell> sipa: the script is a proof "Betacoin say 2 btc can come back to bitcoin to scriptpubkey 1234 + a bunch of betacoin headers". I'd also come up with an idea that required the txout scriptpubkey in such a transaction could be such that it had a minimum time it could be spent from, and before that the transfer canceled with a longer chain of headers.
08:42 < gmaxwell> so then bitcoin is totally blind to betacoin's rules, except for how betacoin headers works, how how betacoin communicates moves back to bitcoin.
08:42 < gmaxwell> from the betacoin side the transfer from bitcoin could be similar or betacoin could watch the bitcoin chain, the latter is probably better.
08:43 < gmaxwell> if the whole transfer is slow and cumbersome and requires a 8 kbyte transaction it doesn't really matter, since if you have two parties you can just to an atomic coin swap.
08:44 < gmaxwell> the cross chain teleports are only needed to balance liquidity.
08:44 < gmaxwell> (so if there are more coins wanted on the betacoin chain than exist there there is a way to satisify the demand)
08:45 < gmaxwell> also means that if you can fake out the teleport method e.g. with a huge betacoin reorg, you can make betacoin fractional reserve, but you never inflate bitcoin.
08:47 < gmaxwell> presumably this could be stronger in practice than in theory because if bitcoin miners were all betacoin miners they could generally refuse to mine suspect betacoin proofs, or themselves be prompt about providing contradiction-proofs that aborted the trasnfer in a soft-security fashion.
08:48 < gmaxwell> "no no, there is a compeating betacoin fork as good/better than this one, abort this transfer until someone can show an even better betacoin proof"
08:49 < adam3us> sipa: the 1-way peg also could consider a longer term version of the market providing liquidity based on later settlement, eg if the network bootstraps to become credible, or if multiple sensible people and orgs make an approximate indication that they plan to switch over with in 18-mo - 2yrs to a hyopthetical sipa-led rewrite
08:50 < adam3us> sipa: as after the switch over the rest of the bitcoins are moved over to the new network and the liquidity providers can earn the arbitrage profit they were aiming for
08:50 < adam3us> sipa: (wrote about somewhere on the tldr 1-way peg thread)
08:51 < adam3us> (what a choice… pay gbp 5 to extend free airport wifi or type a password into a *windows* machine.  yup i paid)
08:51 < gmaxwell> plus imagine all the great drama we'll get in two way pegs. people creating altcoins that can two-way-peg with bitcoin (because why not make the facility completely generic so anyone can hook up a new chain to it?) just with the intention of leaving it insecure so they can steal all the coins that move over.
08:52 < gmaxwell> LHR 45 minute wifi is robbery.
08:52 < brisque> adam3us: just spoof your MAC.
08:52 < adam3us> gmaxwell: i could tumble the mac i guess, but too late
08:53 < adam3us> gmaxwell: i was thinking really should ptu a script to tumble th emac on network connect anyway - privacy principle.  probably nsa is tracking mac s somewhere in utah
08:54 < brisque> adam3us: changing your MAC doesn't stop that, you can just look for wifi cards announcing what networks they're looking for and then compare that to the google skyhook database to find their home address.
08:54 < adam3us> gmaxwell: also it a rather nice argument against scamcoins (still need a better word to describe param-tweak/get-rich-quick from genuine innovation) … and why did you start a new digital scarcity race?  we were discussing that above in relation to coingen.
08:55 < adam3us> gmaxwell: and it seems likely the min-bar will just go up slightly to things like primecoin, or other artificial uninteresting or stupid changes that are just above the param-tweak and come with a semi-plausible to novice argument and white paper.  (Like NXT … that is nuts)
08:55 < brisque> adam3us: out of my own curiosity I set up a wifi dongle looking out onto the street that did something like that. incredibly effective when people walk around with phones in their pockets.
08:56 < adam3us> brisque: i think bitcoin has a problem.  once a competent grey-hate gets too tempted the base band phone p0wning will harvest $ms of coins in automated attacks.  we need hardware fast.
08:57 < adam3us> someone who shall remain nameless to protect their own stupidity showed me a phone with 500btc on it ('doh!)
08:57 < adam3us> (an otherwise i guess reasonably competent CS degree programmer type of person)
08:58 < brisque> adam3us: I was more talking about privacy violations by phones announcing people's home addresses every few seconds. I'd really like to see sensible hardware too though, the Trezor looks quite nice.
08:59 < brisque> adam3us: I personally predict a piece of commodity hardware will be hacked to create a secure but cheap USB based wallet. there's quite a number of children's toys that have been turned into RF analysers and other tools.
08:59 < adam3us> brisque: not sure if 2014 will be the year, but a year RSN we will surely see baseband and targetted DSL IP# hacks from bitcoin big change identified IP# from bitcoin users who dont use tor to spend from large coins; the only hope is air-gaps IMO, or TPM (arm trustzone,  intel TPM etc)
09:00 < gmaxwell> adam3us: someone with a typo squat on a popular bitcoin service domain and a java exploit for IE that I was seeing get investigated recently had stolen several hundred btcs in a few days time.
09:00 < gmaxwell> so the bar is still pretty low
09:01 < brisque> adam3us: doesn't really have to be a specifically designed hardware. anything would do. I saw photos of a childrens toy that would make an excellent Trezor type device with a lot more features (full keyboard) than the real thing.
09:01 < adam3us> gmaxwell: the stupidity factor never ceases to amaze.  its scarcy that people are not being hacked way more.
09:01 < brisque> adam3us: there's some constraints, but the hardware doesn't have to be complex. you don't even need to have a hardware RNG on board.
09:02 < adam3us> brisque: you said about wifi network advertising networks it wants.  it works that way?  no waiting for announce, requesting ssid ? the client broadcasts all the wifi ssid it knows??
09:03 < brisque> adam3us: a wifi client announces sequentially every wifi network it knows, every 10 seconds it ruins "hidden" SSID by sending out the name and MAC of the routers it knows.
09:03 < adam3us> sipa: so are you getting the 2-way peg bug yet? ;)
09:03 < sipa> adam3us: let's call them "silly alts", "delusional alts" and "flawed alts" :)
09:03 < brisque> adam3us: this is the childrens toy I was talking about. you could certainly port a hardware wallet to this. http://d4c027c89b30561298bd-484902fe60e1615dc83faa972a248000.r12.cf3.rackcdn.com/imagepicker/4494/thumbs/IM.jpg
09:04 < adam3us> brisque: on noes!  i guess the mac-tumbler script i need to write needs to flush the ssid cache also
09:05 < adam3us> brisque: i like the QR code as optical isolation connection that "visual btc" setup
09:05 < adam3us> brisque: of course it helps if the value could be signed so the input tx history doesnt need to be sent to work around that bug
09:06 < brisque> the IM-me is missing a camera so a QR code is out of the question. the sticking point is that you can't use sound because of the must-see-every-input issue of transactions.
09:06 < brisque> a device like this with more IO (a camera mainly) would be able to replace trezor with cheap commodity hardware.
09:07 < brisque> if the must-see-every-input bug was fixed in 0.9, you could almost push a TX via sound, it's just too heavy as it stands.
09:07 < adam3us> sipa: i guess someone could do a zoo-ology catalog of them.  the variety of stupidity and greed in involved is hilarious.  some of them even bootstrapped to semi-respectability by first-mover advantage.  i think one test maybe zero real-transactions (non speculator), lack of clients, lack of any development, lack of any plan to obtain real-tx
09:09 < gmaxwell> people would never believe the zooology wasn't all made up
09:09 < adam3us> brisque: as i recall gmaxwell guestimated 2 years to fix the sig malleability bug; not sure what the guestimate would be on the no signed values bug.  depressing.  hence enthusiasm for 2-way peg.  in the old thread on 2-way peg gmaxwell said (in relation to my question if this itself could get implemented given the other bugs) was that yes but this (2-way peg) is the one change to rule them all
09:10 < adam3us> gmaxwell: crypto-zoology :)
09:10 < gmaxwell> adam3us: also— why bother with baseband hacks and zero days, when you can just ask people to give you their money: https://bitcointalk.org/index.php?topic=393593.msg4274997#msg4274997
09:11 < gmaxwell> adam3us: yea, a two way pegging facility is fully general. I mean its a way you could completely replace the protocol in a totally consentual way, start up  mergemined two-way-peg and move all the funds to the new chain over time.
09:11 < brisque> adam3us: if dogecoin can do a hard fork in 10 days, I'm sure gmaxwell can come up with some crypto-magic to get bitcoin's done in 20.
09:12 < gmaxwell> having a hard fork is not a problem, avoiding one is.
09:12 < gmaxwell> suggested two way peg stuff doesn't actually need a hardfork, might not even be any easier with one.. it's just new scriptpubkey features, at least if it stays at the quasi spv security level.
09:12 < adam3us> the other annoying thing about airport wifi is i have a pay as you go 3g sim with 3GB/month data allowance for gbp 2/day for UK on any day used, but the wretched thing never works, and i think i grabbed the wrong replacement sim when i was leaving.
09:13 < brisque> gmaxwell: that story is terrible.
09:16 < adam3us> is there anyway to get above SPV security i wonder in a sensible level of bitcoin main changes that doesnt just have both protocols in the client (or a link to a beta validator running in parallel)
09:17 < gmaxwell> well spv security can mean multiple things there is communicationless spv which is what you get when someone hands you a proof and you're happy, and normal spv when you can go out and seek more evidence.
09:17 < gmaxwell> I think we can get it the latter of those two.
09:17 < gmaxwell> More than that implies validating the rules
09:17 < gmaxwell> which implies embeding the rules in bitcoin
09:17 < gmaxwell> and all of the data needed to check the rules
09:18 < gmaxwell> and short of snarks or something, I think thats probably not realistic. (well and not realistic with snarks today regardless but maybe in a few years)
09:19 < adam3us> brb
09:30 < adam3us> gmaxwell: well say hypothetically a client that speaks both bitcoin v1 and bticoin v2 protocol with a pegged side-chain connecting them
09:31 < adam3us> gmaxwell: eg less of a general competition between 2a, 2b 2c etc side-chains but more the next version of bitcoin with fork requiring bug fixes on it, running in parallel with real-value transferred via the 1:1 peg by those who need the 2.x features, eg 1.x for value storage and 2.x for anything other than basic tx (say)
09:36 < adam3us> adding insult to injury this gbp 5/hr wifi is failing I think because of the web injection urls timing out. grr
10:21 < brisque> regarding hardware wallets.
10:22 < brisque> I was looking into various bits of hackable hardware, looking at the specs and everything. realised it's a little pointless when you can get a 6" laptop from Alibaba for 30 pounds or so.
10:23 < brisque> that's all you'd need for a super effective offline device really, and it's cheaper than the Trezor ever was.
10:25 < gmaxwell> brisque: but bulky.
10:26 < brisque> gmaxwell: one of these would work too http://en.qi-hardware.com/wiki/Ben_NanoNote
10:26 < gmaxwell> (also: thats why I didn't order a trezor)
10:26 < gmaxwell> yea, but stupidly expensive.
10:26 < gmaxwell> I actually looked at getting a nanonote for wallet use.
10:26 < gmaxwell> it's not true of trezor but in theory a hardware wallet could be tamper resistant too.
10:27 < gmaxwell> your cheap laptop will suck when the evil made pops the keyboard and adds a keylogger chip.
10:27 < gmaxwell> s/made/maid/
10:28 < brisque> that's why I was thinking of consumer hardware that can be hacked. the childrens toy I mentioned has almost everything you need, including a wireless pink USB dongle. the issue is that you have to open it to get to the serial ports to flash it. not something you can convince everybody to do. http://d4c027c89b30561298bd-484902fe60e1615dc83faa972a248000.r12.cf3.rackcdn.com/imagepicker/4494/thumbs/IM.jpg
10:29 < gmaxwell> wow neat
10:29 < gmaxwell> what cpu?
10:29 < brisque> that's the other sticking point, it's CPU is a little short on memory.
10:29 < gmaxwell> though wireless usb dongle may mean a rather large attack surface area.
10:30 < brisque> the low memory is ultimately what makes it useless sadly.
10:30 < brisque> works as a RF spectrum analyser though.
10:31 < gmaxwell> why would it make it useless as a signing device?
10:31 < gmaxwell> surely it has enough for that.
10:31 < brisque> http://www.ti.com/product/cc1110f32
10:32 < brisque> 32kB flash, 4kb of RAM
10:32 < gmaxwell> could be used as a signer no problemo.
10:33 < gmaxwell> though uh, perhaps not with wireless.
10:34 < brisque> yeah. my thinking is that there's got to be another dirt cheap childrens toy with an LCD, keyboard and some decent IO that can be hacked into a deterministic wallet.
10:34 < gmaxwell> but, of course, that also makes it easier to tamper with
10:34 < brisque> camera for QR codes, or audio, or even USB pretending to be a HID would work perfectly for this.
10:35 < brisque> isn't the assumption that with a hardware token, your coins are compromised anyway?
10:35 < gmaxwell> hm?
10:36 < brisque> any KDF on an embedded device would make it useless, and no matter what you do the seed is going to be extracted.
10:36 < brisque> I've seen hardware that's meant to destroy keys before, it's not all it's cracked up to be.
10:36 < gmaxwell> nah, you can make successful extraction of the seed pretty hard and make it be destructive.
10:37 < gmaxwell> (be destrutive meaning an intruder couldn't tamper and put it back)
10:37 < gmaxwell> and yea, sure concerted 'offline' effort by an expert you can't be safe from, but certantly it's better if your curious teenager couldn't extract the keys easily.
10:38 < gmaxwell> not saying mandatory: trezor fails this too as I understand it, but it would be preferrable.
10:38 < brisque> there was a game console that did something like that. had a chip with the ROM, and a battery backed RAM chip with a secret key. on boot it XORed the two to get the executable. any screwup meant you lost the RAM chip and had to pay a pile of money for a new one.
10:39 < gmaxwell> yea there are all kinds of interesting things you can do, and then also embed the stuff in epoxy with embeded tripwires that cut power to the ram if cut.
10:40 < brisque> that's all doable, but that wasn't my aim with this concept. a dirt cheap hardware device holding a seed is preferable to a computer running windows and java.
10:40 < gmaxwell> fair enough. probably more interesting to reduce the interface exposure.
10:41 < brisque> QR codes would be ideal, then audio, then you're back to pretending to be a USB HID. are there any other "airgapped" ways of getting TX data to a device?
10:43 < gmaxwell> hid doesn't get you bidirecitional, does it?
10:43 < brisque> it does. the device can pretend to type, and the host can flash the caps lock key.
10:43 < gmaxwell> lol!
10:43 < gmaxwell> thats going to be rather slow
10:44 < brisque> doesn't the trezor pretend to be HID?
10:44 < gmaxwell> no clue
10:44 < gmaxwell> you need to transfer several kb.
10:44 < brisque> yes, the Trezor pretends to be HID too.
10:44 < gmaxwell> man the things you need to do to make windows happy
10:44 < gmaxwell> I would have just made it a usb serial device, but I guess those need drivers in window
10:44 < brisque> being driverless was probably the aim.
10:45 < brisque> 10kB/s using the caps lock light..
10:46 < gmaxwell> crazy, still a bit slow
10:46 < gmaxwell> how about usb storage... plug unplug plug. :P
10:46 < gmaxwell> and sign and enter your pin on the device itself while unplugged.
10:46 < jgarzik> caps lock light - ha, creative!
10:47 < brisque> well for me wanting to hack something, that's probably going to let the host flash the device which is undesirable. I'm really just throwing ideas around.
10:47 < jgarzik> jumping airgaps is all the rage, these days.  NSA or private community alike.
10:49 < brisque> doing it usefully is the issue though. I don't want to have to listen to my CPU buzz with a parabolic microphone to get Bitcoin TX data to an embedded device.
10:49 < gmaxwell> obviously why having a device with a minimized surface area matters.
10:49  * gmaxwell looks at gox and hurrays
10:50 < brisque> gmaxwell: I wanted a Ben NanoNote just to play with, doesn't look like anybody sells them anymore.
10:51 < brisque> by the looks of things, the easiest and cheapest airgap transmission is audio. if people hated dialup modems they're going to hate me screaching 200kB of previous outputs at them.
10:51 < gmaxwell> brisque: harder to setup bidirectional.
10:52 < gmaxwell> how about a usb device immitating a sound device?
10:52 < brisque> USB sound cards are cheap as chips, you can get one that works on any linux device for a few dollars.
10:52 < gmaxwell> and then you can easily just get 192kbit/sec in each direction using two bits per sample, and it would be completely inaudable if addressed to the wrong device.
10:52 < brisque> bonus, you can do transfer over audio to a phone.
10:54 < brisque> imitating a USB sound device would be doable though. matching a generic driver on the host would mean no attack surface.
10:54 < brisque> could also have audio output, then connecting to a cellphone would work.
10:55 < brisque> bonus mode, make adaptors so that transactions can be signed over phones, 56k style
10:57 < jgarzik> I continue to be stunned that mtgoxUSD receives the trading action that it does
13:33 < justonegy> hello
13:33 < justonegy> anywhere here who can help with ubuntu build?
13:33 < justonegy> or rather wants to..
13:39 < michagogo|cloud> justonegy: What about it?
13:39 < michagogo|cloud> (though this is most likely off-topic for this channel...)
13:40 < justonegy> I'm trying to build and its difficult to find information
13:40 < justonegy> EXCEPTION: N5boost12interprocess22interprocess_exceptionE
13:40 < sipa> #bitcoin or perhaps maybe #bitcoin-dev
13:41 < justonegy> checking for Berkeley DB C++ headers... default
14:06 < justonegy> no one want to help?
14:07 < justonegy> trying to fix this issue and there is just no information and the debug info is non existent
14:08 < sipa> please, not here
14:08 < jcorgan> #bitcoin-dev is better, and, you need to provide a bit more info
14:25 < midnightmagic> lol, one more reason why having a maid is crazy.
14:25 < midnightmagic> if yer in a house and can't vacuum your own floors, you're in the wrong damn house.
18:37 < petertodd> 1CounterpartyXXXXXXXXXXXXXXXUWLpVr <- crazy, 107BTC sacrificed for some "protocol for the creation and use of decentralised financial instruments such as asset exchanges, contracts for difference and dividend payments"
18:37 < petertodd> https://bitcointalk.org/index.php?topic=395761.0;all
18:38 < petertodd> hilariously the scheme seems to be using OP_RETURN "CNTRPRTY<ProofOfBurn" outputs, yet the actual burn is in a non-prunable output
18:39 < petertodd> though that's not very surprising when you consider the psychology of it: a standard address for the burn lets people easily see how much has been invested, fueling additional investment...
18:41  * nsh blinks
18:42  * nsh reads harder
18:43 < nsh> nope. can you explain in more simple terms, petertodd?
18:43  * nsh looks at the thread
18:45 < petertodd> nsh: OGG CAVEMAN BURN TASTY MEAT IN FIRE BECAUSE NOG CAVEMAN SAID MUCH MORE MEAT IN FUTURE IF OGG BURN MEAT NOW
18:45 < petertodd> nsh: OGG STUPID CAVEMAN, NOG CAVEMAN HAVE NO PLAN FOR MORE MEAT
18:45 < nsh> right, i'm basically at that stage
18:45 < nsh> but the bit where it actually makes sense to someone (and how) is beyond me
18:46 < petertodd> nsh: well I'm basically saying the intelligence of the people who throw away six figures is similar to that of a caveman
18:46 < nsh> sure
18:46 < sipa> what does 'OGG' refer t?
18:46 < sipa> to?
18:47 < nsh> but pretending this guy is actually some satoshi-level genius. what are people gaining by burning these coins? stake in some future system
18:47 < nsh> but how?
18:47 < petertodd> sipa: ogg is a standard caveman name in western english culture
18:47 < petertodd> nsh: basically, by the definition of the system, much like mastercoin was done, only with (arguably) even less chance of future success
18:47 < sipa> at least it sounds less scammy, as the exodus address is an actual burn here...
18:48 < petertodd> sipa: indeed, OTOH that can also mean less chance of success, as who'se paying for development?
18:48 < sipa> agree
18:48 < nsh> you'd want to be really really confident of everything working out to actually boot-strap the thing with real sacrifice from early-adopters...
18:49 < petertodd> nsh: yup, in this case actually it doesn't look like the creator of the scheme has any ill-intent, more that the investment community around it are idiots and will jump to throw money at anything
18:50 < nsh> well, i suppose you can take an ecological view: at the worst, something nontrivial will have been tried and lessons can be learnt, and those people who threw money in probably could afford it
18:51 < nsh> (and everyone who has btc gets slightly richer from the deflation)
18:52 < petertodd> nsh: quite likely true, although I'm going to let someone else pay to learn those lessons for me :P
18:52  * nsh smiles
23:15 < phantomcircuit> hmm
23:15 < phantomcircuit> cookies
23:37 < andytoshi> petertodd: can you give us a preview of the OP_RETURN based stealth addresses scheme you hinted at in your latest email?
23:52 < petertodd> andytoshi: writing it up now :)
--- Log closed Mon Jan 06 00:00:29 2014