--- Log opened Wed Jan 08 00:00:06 2014
00:21 < michagogo|cloud> jgarzik: do you know which block you'll extend it to?
00:22 < michagogo|cloud> (If so, I can generate the file myself, and be ready to seed when it goes live)
00:33 < gmaxwell> warren: http://peercoin.net/index.php  < click Myth 2.
00:51 < michagogo|cloud> gmaxwell: o_O
00:52 < michagogo|cloud> They were the ones that allow the dev to add new checkpoints at any time without an update to the software, right?
00:52 < BlueMatt> gmaxwell: though that looks ridiculous, it does say they dont enforce checkpoints by default....
00:52 < BlueMatt> michagogo|cloud: yes
00:54 < gmaxwell> BlueMatt: it's not true.
00:54 < BlueMatt> ahh
00:54 < gmaxwell> BlueMatt: the text they're quoting there is about XPM not PPC.
00:54 < BlueMatt> well...thats just ridiculous
00:54 < gmaxwell> BlueMatt: it also says that Bitcoin and Litecoin has "checkpoints" too.
00:54 < BlueMatt> yea
00:54 < BlueMatt> I liked that bit
00:55 < michagogo|cloud> And even if it were true, if part of the network enforced them DNA another part didn't, that means a hardfork
00:55 < michagogo|cloud> and*
00:55 < gmaxwell> The PPC consensus model _requires_ them, not just for fuzzy security reasons, but because you cannot validate PoS without a transaction index containing the stake thats being used on the block... so they only allow coins which have been immobile for >30 days to be used for PoS and then use the checkpoints to make damn sure the network agrees about the state in the past.
00:56 < gmaxwell> I also checked the PPC codebase, they're on, and there appears to be no way to turn them off.
00:57 < warren> gmaxwell: and of course it doesn't matter if it isn't enabled by default, if pools do then the users don't have a choice.
00:58 < michagogo|cloud> Erm, maybe not hard
01:40 < gmaxwell> I wish people would ask better questions: http://www.reddit.com/r/Bitcoin/comments/1uoq6e/what_do_you_guys_think_of_proof_of_stake_mining/cek9fhq
01:42 < home_jg> I wish reddit would not suck so much
01:43 < home_jg> Cardinal example of upvoting/downvoting systems producing herds of fast-moving idiots
01:43 < home_jg> I say this as a near-daily reddit user, of course
01:45 < home_jg> well-informed cautionary answers on brainwallets routinely get downvoted
01:53 < Guest58374> herding idiots
01:53 < Guest58374> i'm going to remember that :)
01:58 < gmaxwell> the upvoted downvotey stuff overweighs superficial opinions. It's fine for cat pictures.
01:58 < gmaxwell> (which is mostly why I browse reddit)
01:58 < gmaxwell> I hardly read any bitcoin or technology things at all, mostly just funny pictures of animals.
02:00 < Taek42> I'm not sure that it's a symptom of upvotes and downvotes so much as Reddit being a general audience
02:01 < maaku> people are stupid
02:01 < gmaxwell> Taek42: nah, normally the general audience doesn't have their hands firmly placed on the steering wheel.
02:01 < maaku> it boggles my mind that when you have a crowd of them, wisdom is supposed to emerge
02:01 < gmaxwell> lol
02:01 < Taek42> democracy!
02:02 < gmaxwell> to be fair even the crappy "Wisdom of the crowds" book said that wasn't actually so.
02:04 < Taek42> I've often wondered what would happen if voting had a cost to it, and you could pick the power of your vote by adjusting the cost
02:04 < maaku> never actually read it. was the thesis that you need proper incentives?
02:07 < michagogo|cloud> Taek42: a monetary cost, you mean?
02:08 < Taek42> well, some sort of currency that could be swapped for real currency
02:08 < maaku> citizen cost a la starship troopers?
02:08 < Taek42> dogecoin, perhaps
02:08 < gmaxwell> voting already has a substantial cost in terms of time/trouble.
02:08 < Taek42> on reddit, the first vote is pretty costly
02:08 < Taek42> seeing as you have to log in, and maybe create an account
02:08 < Taek42> but the rest are painless
02:09 < michagogo|cloud> Or creddits
02:09 < Taek42> I imagine though that it wouldn't actually be that different even if there were a monetary cost to each vote (or a karma cost)
02:10 < Taek42> The problem being that the average person could have as much authority/power as the expert
02:10 < michagogo|cloud> I seem to recall there was some site like that
02:10 < michagogo|cloud> Where you spend reputation points to vote
02:11 < phantomcircuit> gmaxwell, is there still a penalty for p2pool?
02:11 < phantomcircuit> iirc there used to be a substantial orphan rate
02:11 < phantomcircuit> also @anybodyelse
02:12 < gmaxwell> phantomcircuit: it has the lowest orphan rate of any pool as far as I can tell.
02:12 < phantomcircuit> what's it's current orphan rate?
02:13 < gmaxwell> there has been two this year.
02:14 < gmaxwell> 0.12% in my data. (eligius, by comparison, has been ~1%)
02:14 < phantomcircuit> that's interesting
02:14 < gmaxwell> phantomcircuit: p2pool changed a couple years ago to a model where nodes pre-forwarded transaction data to their peers. So when one finds a block it just has to send the list of transactions that were actually in it.
02:15 < Taek42> theoretical problem: suppose every miner picks the maximum-payout pool. Wouldn't every miner end up picking the same pool?
02:15 < gmaxwell> it will also mine a transactionless block in brief windows when the local bitcoind is lagging but p2pool peers have produced shares against a further along chain.
02:15 < phantomcircuit> any idea why the orphan rate would be lower than eligius?
02:16 < gmaxwell> phantomcircuit: because it has an enormous network connectivity advantage.
02:16 < phantomcircuit> it might also have to do with what kind of hardware is connected to p2pool
02:16 < phantomcircuit> some of them have uh
02:17 < phantomcircuit> interesting ideas of what stale means
02:17 < gmaxwell> p2pool blocks end up being concurrently announced by a dozen peers in the first 30ms after finding a block... hundreds within 400ms.
02:18 < gmaxwell> phantomcircuit: maybe, p2pool direct miners to return "stale" shares.
02:18 < gmaxwell> in any case, if some miner is overly agressive in what its discarding, its not getting paid for that portion of its work.
03:51 < gmaxwell> I think bitcoin is becoming the new DHT. :(
03:52 < wumpus> yo, slap a blockchain on it
03:53 < roidster> COULUD STAND FOR HEMROID
03:53 < roidster> could* pardon the caps
03:55 < BlueMatt> gmaxwell: I think we've known that was gonna happen for a while
03:55 < BlueMatt>  /has been happening for a while
03:55 < wumpus> well yes bitcoin is the new idea of the day, so now we're in the [try_with_new_idea(x) for x in old ideas] phase
03:56 < wumpus> and you get nonsensical ideas, like in the internet boom.... just like your old pet shop, but online!
04:06 < gmaxwell> a miracle happened on reddit today
04:07 < gmaxwell> someone mentioned my name in a ppc thread, which is what brought my attention to those claims on that website.
04:07 < gmaxwell> I refuted them with citations to source code.
04:07 < warren> URL?
04:07 < warren> (reddit thread)
04:08 < gmaxwell> http://www.reddit.com/r/Bitcoin/comments/1uoq6e/what_do_you_guys_think_of_proof_of_stake_mining/cek7vbc
04:08 < gmaxwell> and someone argued with me... and then actually accepted my counter arguments. and I'm not being voted down!
04:14 < sipa> i've been explaining the problem with PoS a few times now at the zurich bitcoin meetups
04:14 < sipa> people do seem to understand it
04:18 < gmaxwell> it makes me sad, I really wish it worked.
04:19 < justanotheruser> What are the potential problems of associating namecoin registration price with transaction fee sum?
04:19 < gmaxwell> what is a "transaction fee sum"?
04:20 < gmaxwell> if you mean some function of recent transaction fees …  the problem is miners padding up transaction fees with payments to themselves to manipulate prices (might as well just let miners set them)
04:20 < justanotheruser> gmaxwell: you could look at how much was paid in tx fee since the last difficulty adjustment (or some other arbitrary period of time)
04:21 < justanotheruser> gmaxwell: yeah, that is a problem
04:22 < justanotheruser> There's not really a way to evaluate how many namecoin users there are...
04:22 < gmaxwell> you can look at the registrations however.
04:23 < gmaxwell> (and also, it's easy to see it not being used anywhere, and even easy to see the lack of people asking how to use it)
04:23 < justanotheruser> gmaxwell: but you can't set the registration rate based on the number of registrations
04:23 < gmaxwell> yea oh sorry I thought you were back to suggesting that namecoin isn't currently a failure. :P
04:23 < justanotheruser> If there were only 500 domains offered per day, people would have to compete in price for registering.
04:24 < justanotheruser> Unfortunately namecoin isn't going to ever be stable, so you can't say "$10 for a registration"
04:24 < gmaxwell> yea, I've got no freeking idea.  yes, one possible way would be to make the database fixed in size or something like that.
04:25 < justanotheruser> if people compete in price it would have to be in mining fees, so the miners would be able to register however many domains they wanted...
04:25 < gmaxwell> well with 2 way-peg you could transfer bitcoins into the namecoin chain to pay for names, thus giving them to miners, who can remove them from the namecoin chain. (I mean, if we're talking about things which decidely aren't namecoin as it is today) so then the instability of namecoin as a tradable asset can be removed.
04:25 < justanotheruser> but I guess for every domain they buy, they lose one domain sale that day
04:25 < gmaxwell> justanotheruser: unless the system just limits it via a protocol rule.
04:26 < justanotheruser> gmaxwell: is there a way to have a decentralized 2 way peg?
04:26 < gmaxwell> I guess you missed those discussions. I believe it's possible, there are some security limitations.
04:27 < justanotheruser> also I don't think pegging something to bitcoin makes it stable. It makes it more stable relative to all other cryptocurrencies, but relative to almost every other asset/commodity bitcoin is incredibly unstable
04:28 < gmaxwell> basically I suggested a relatively minor softforking addition that would allow you to assign coins to another chain, and then carry a proof back from the other chain to bitcoin to allow you to very slowly teleport coins back and forth.
04:28 < gmaxwell> (slowly meaning like 100 blocks)
04:28 < justanotheruser> gmaxwell: would this allow for offchain transactions if the bitcoin chain was too big making transaction fees high?
04:29 < justanotheruser> well not "if", but for that reason would it be useful
04:29 < gmaxwell> it would. or more interesting it would allow altcoins to expirement with new ideas without also creating new currencies. (at least when the idea is just new payment network ideas)
04:30 < gmaxwell> e.g. you could have namecoin but without having a seperate namecoin currency.  or you could have some 10 second blockchain thing (0_o) or something with more powerful script.
04:30 < gmaxwell> (turing complete script, whoppie!)
04:30 < justanotheruser> gmaxwell: is the peg discussion in #bitcoin-dev logs?
04:30 < gmaxwell> it's in the logs here.
04:30 < justanotheruser> any public logs for this channel?
04:31 < gmaxwell> andytoshi-away: makes logs, dunno where they are.
04:31 < michagogo|cloud> (The logs should really be mentioned in the topic...)
04:32 < justanotheruser> I'll make a note to ask him for the logs
04:32 < gmaxwell> it's not a serious proposal at this time... but perhaps it will become one. The belief that it could work two ways is relatively new. (it's not that complicated an idea though, I'm sure I would have said it was obvious in 2011 if it had been suggested to me then)
04:32 < justanotheruser> gmaxwell: so would this pretty much remove the need for Open Transactions?
04:33 < gmaxwell> but in any case the idea is that you make a payment to a special scriptpubkey which basically says "these coins are now controlled by foocoin"   and then it's possible to spend from txouts to that scriptpubkey by showing up with an SPV proof "foocoin says you should give me X of those coins to scriptpubkeys Y and Z", plus some extra details.
04:34 < gmaxwell> justanotheruser: well it would allow the same kind of "binding" that open transactions could do already using multisig ... but allow it for other blockchain cryptocurrencies.
04:34 < justanotheruser> gmaxwell: isn't the only way for that SPV proof to exist by embedding all those block headers in the bitcoin blockchain?
04:35 < justanotheruser> Or is there some way that the miner can be proved that their blockchain says something without actually looking at anything other than the transaction
04:35 < gmaxwell> justanotheruser: sure, but 100 blocks is 8kb. whopptie do.  These transfers would generally be infrequent because they'd be used for bulk liquidity,  normally if you want coins on the other chain you find someone who wants bitcoin and you do an atomic coinswap.
04:35 < gmaxwell> But the coinswaps alone cant get you a 2-way peg because they can't provide long term liquidity.
04:37 < gmaxwell> justanotheruser: the proofs could also be structured so that they can be pruned. e.g. perhaps the only thing that gets stored in the blockchain directly is a summary of the proof. After all the proof only has SPV security, once it's thousands of blocks deep in bitcoin why keep it?  (and if that were done the proof wouldn't need to count against the block size limit, or wouldn't need to count against it fully)
04:38 < gmaxwell> (also a single proof could actually be batching dozens of transfers, e.g. foocoin tells bitcoin a whole list of scriptpubkeys to pay, at least you can get batching in the foo->bitcoin direction)
04:39 < justanotheruser> gmaxwell: Seem expensive still. The blockchain could end up storing a dozen other blockchain headers in it
04:39 < gmaxwell> e.g. the foo->bitcoin instructions are generated by foocoin miners, summarizing actions commanded by transactions and validated according to the foocoin rules.
04:40 < gmaxwell> justanotheruser: well snarks can compress that kind of thing down to 384 bytes for 128 bit security, but I'd prefer to show it viable without any cutting edge cryptography.
04:40 < justanotheruser> I wonder if there's some crypto that could be used to do that proof in a size significantly smaller than the actual altchain
04:40 < gmaxwell> justanotheruser: and each of those dozens of other chains could have an infinity of transactions, seems like a good tradeoff to me.
04:41 < justanotheruser> gmaxwell: do you think that's more viable than sharding the blockchain?
04:41 < gmaxwell> justanotheruser: zk-SNARKs can have size only proportional to the security level. The size of the rule being proven or the data it accesses is irrelevant to them.
04:43 < gmaxwell> but the really small ones have some uncomfortable security tradeoffs (CRS assumption) the ROM ones are somewhat larger (eg 20kb, though I did invent a novel compression scheme which may help, so they may not be good for compressing header proofs, but then again they'd allow full security not just spv, potentially.. but this is all really cutting edge and not yet totally pratical stuff.)
04:44 < justanotheruser> hmm
04:44 < justanotheruser> gmaxwell: do you have some cryptography PhD or something?
04:45 < gmaxwell> in any case, I don't think an 8kb signature intermittently per bound chain is a bad tradeoff. Especially knowing that application of sufficient magic could make it smaller in the future.
04:45 < gmaxwell> justanotheruser: No. I'm just some guy who enjoys math.
04:45 < justanotheruser> I see
04:45 < justanotheruser> This idea seems to have a lot of potential
04:46 < justanotheruser> Would this not require disabled opcodes to determine whether the transactions belonged to someone else on this other chain?
04:47 < justanotheruser> I guess you said it was a softfork, so my real question is why wouldn't it
04:47 < gmaxwell> I think it does too. well, and it also may solve a problem thats been bothering me— which is that its hard to do novel cryptocoin expirementation.  We can't mess around with it in bitcoin because its too important. Alt systems generally get little love because they're worthless, unless you make a big thing about pumping their value and then that speculation becomes all encompassing.
04:48 < gmaxwell> justanotheruser: we'd add a new opcode in place of a no-op today "the thing on the stack is a chain binding proof, this transaction is only valid if the proof is valid"
04:48 < gmaxwell> old nodes would just see a no-op transaction and permit it.
04:49 < gmaxwell> It would be safe to use once a super majority of hashpower agreed to enforce it as a rule in the chain— same way p2sh was deployed.
04:49 < Taek42> gmaxwell, what's your opinion of XRP?
04:50 < gmaxwell> Taek42: https://bitcointalk.org/index.php?topic=144471.0 the whole thread is informative, I answer my own question and then get into a discussion with one of the ripple developers.
04:50 < Taek42> thanks
04:53 < justanotheruser> Any known weaknesses to the pegging system?
04:53 < gmaxwell> ohh "Crony Consensus"  I'll have to remember that.
04:54 < gmaxwell> justanotheruser: at least as I was describing above it only has SPV-like security. meaning that if you can outpace the second chain you can steal all the bitcoins assigned to it and leave it fractional reserve.
04:55 < gmaxwell> (which would be part of the reason it would need to be fairly slow)
04:55 < gmaxwell> (I mean the teleport operation would need to be slow)
04:56 < BlueMatt> gmaxwell: implementation detail: do you require the side-chain be merged-mined?
04:56 < justanotheruser> BlueMatt: seems like that would be ideal
04:56 < TD> good evening guys
04:56 < gmaxwell> BlueMatt: I don't think bitcoin should require that, though it would probably be pretty darn prudent.
04:57 < BlueMatt> hi TD
04:57 < gmaxwell> BlueMatt: at least my thought is really "just add enough so that bitcoin can verify a sutiable proof, and then you can build anything out of that which you can make fit"
04:57 < gmaxwell> HI
04:57 < sipa> TD: timezone deficiency?
04:57 < TD> evening for them. morning for us :)
04:58 < gmaxwell> BlueMatt: so while it might be _wise_ to merge mine it, and perhaps there are some optional strenghtening things that could be done, I don't think it would make sense to require it.
04:58 < sipa> ah, right
04:58 < BlueMatt> gmaxwell: makes sense
04:58 < TD> lol
04:58 < TD> "Since we're generating the points randomly, I'm going to ignore the first condition because it happens far less frequently than malfunctions in the CPU instructions that I might use to detect it."
04:58 < TD> i think i'm going to remember this excuse for ignoring edge cases, for the future :)
04:58 < sipa> link?
04:58 < TD> https://www.imperialviolet.org/
04:59 < TD> agl talking about implementing elligator for curve25519
04:59 < gmaxwell> e.g. ideally the pubkey could specify the proof geometry required with enough flexibility that you could merge in something rather throughly unlike bitcoin.
04:59 < justanotheruser> sipa: seem into producing acronyms...
05:00 < gmaxwell> BlueMatt: though annoyingly some of the already existing altcoins can't have compact spv-like proofs. :(
05:00 < justanotheruser> gmaxwell: scryptcoins?
05:00 < TD> how did they manage that?
05:01 < TD> justanotheruser: no, scrypt based coins still use sha256 for the merkle tree
05:01 < BlueMatt> gmaxwell: meh, I dont care about current altcoins that do dumb things, I want to enable actual innovation, not knob twiddling
05:01 < TD> says the guy behind coingen.io :)
05:01 < justanotheruser> TD: but how do you verify the PoW without including scrypt into bitcoin or implementing scrypt in a bitcoin script?
05:02 < BlueMatt> TD: yes, hopefully it will saturate the market with knob twiddling and people will get bored of it
05:02 < gmaxwell> TD: well PPC's proof of stake stuff appears to need a (mostly) unpruned blockchain history to validate. And a primecoin headers look like they're a couple kilobytes and need primality testing?!
05:03 < TD> gmaxwell: surely even in proof of stake, transactions are in blocks and arranged into a merkle tree though?
05:03 < TD> or you mean you can't just download headers at all
05:03 < gmaxwell> TD: you need to prove it hasn't been spent.
05:04 < gmaxwell> well they have no getheaders p2p messages either, but thats an aside. :P
05:05 < gmaxwell> basically at least as PPC is now, I don't think you can extract a compact proof that a header is valid. maybe you can get close enough by extracting the transactions and assuming they weren't subsiquently spent, but I dunno, since there is no POW on those blocks attacking is cheap. I honestly haven't thought about it much.
05:06 < gmaxwell> at a minimum it's complicated.
05:07 < sipa> maybe we should write a "if you're going to create an altcoin, think about:" document
05:08 < BlueMatt> sipa: yea, think about: "2-way pegged value"
05:08 < sipa> listing some of the easy-if-we-knew-it-at-the-start ideas like p2sh only, or simplifying script, or having amounts in the signature hash
05:08 < sipa> and concerns like compact proofs
05:09 < sipa> oh and maybe explain the reason for block times being slow
05:10 < gmaxwell> sipa: dunno that it would help, couldn't hurt. I say I don't know because of how they've responded when encountering problems.
05:11 < BlueMatt> for current-gen alts, its sure to make no difference
05:12 < gmaxwell> (e.g. the general response has been to do something even dumber)
05:12 < BlueMatt> for people making real alts (maybe, though I'm very unconfident) coingen will help
05:14 < gmaxwell> e.g. feathercoin had instability and attacks in due to some of their parameter choices, their response was to pay the ppcoin person to license "advanced checkpointing" from ppc (developer broadcast "checkpoints").
05:15 < Taek42> are people licensing cryptocurrency ideas now?
05:16 < _ingsoc_> BlueMatt: Lol.
05:16 < gmaxwell> thats the only incident of it that I'm aware of.
05:16 < TD> i never liked p2sh only as an idea.
05:16 < gmaxwell> unless you count coingen.io
05:17 < gmaxwell> It's certantly something I'd do when starting from scratch. Opinions may differ.
05:17 < TD> ethereum might evolve into an interesting alt
05:17 < TD> gmaxwell: well, it'd rule out things like OP_RETURN tagged outputs and the like, which people have found uses for.
05:18 < gmaxwell> TD: yea, the ethereum warez site agent is totally going to be popular. :P
05:18 < TD> is that actually on their website?
05:19 < gmaxwell> TD: no reason that it would preclude having a no index flag (or really just a seperate field in transactions for aux data).
05:19 < gmaxwell> TD: no, I was kidding, but it seemed to follow naturally from the description of it I read. :P
05:19 < TD> you saw payfile, right? :)
05:19 < sipa> what is ethereum?
05:19 < gmaxwell> TD: you couldn't tell for sure though…
05:20 < TD> gmaxwell: that's true. you could extend the tx format at the same time.
05:20 < gmaxwell> sipa: vitalik altcoin based on turing complete script.
05:20 < gmaxwell> doesn't exist yet as far as I know.
05:20 < sipa> ah
05:20 < gmaxwell> a bunch of the design decisions wouldn't be ones I would have made but. ::shrugs::
05:21 < gmaxwell> sipa: in particular it's supposted to support being able to upload code into the network which the network runs triggered by events e.g. independantly of transactions, which can do things like create transactions.
05:21 < sipa> ewww
05:21 < TD> hah
05:21 < gmaxwell> and a handwave at fees to pay for it, without any consideration of the incentives around that.
05:22 < gmaxwell> Yea, my response too. But at least its different.
05:22 < TD> right. hence me thinking it's the most interesting alt, even if i also think it's unlikely to work
05:22 < TD> but we'll see
05:22 < gmaxwell> be nice or I'll suggest they name one of their currency units after you.
05:22 < nsh> nobody talks about Dr Frankenstein advanced the field of medicine
05:22 < nsh> +how
05:23 < gmaxwell> http://demotivators.despair.com/demotivational/mistakesdemotivator.jpg
05:23 < TD> the guardian did a nice article on alt coins. i banged the drum about how they demonstrate the fundamentally democratic nature of crytocurrencies
05:24 < TD> so coingen and other joke alts are not entirely useless. they educate people about the tech and more importantly, make BlueMatt a lot of money
05:24  * nsh smiles
05:24 < gmaxwell> Sadly alt's don't work too well as education on what not to do, just like invent your own blockcipher usually doesn't— because they usually don't reach the point where they justify a serious attack, but oh well.
05:24 < TD> well, that's education of developers. i'm thinking of education of users. showing how bitcoin developers are not simply the new central bankers
05:25 < TD> http://www.theguardian.com/technology/2014/jan/07/bitcoin-me-how-to-make-your-own-digital-currency
05:25 < gmaxwell> TD: hey, I strongly promoted that idea. I'm all for it.  I also suggested it to people who wanted to "fight" altcoins as the fair and ethical way to do so... "we think these things are pointless, well it's not fair to stop them, but lets reduce the friction that makes making a pointless altcoin profitable."
05:26 < gmaxwell> TD: did you see the fallout from the launch of the 'conya' coin? (or however its spelled?)
05:26 < gmaxwell> coinye
05:27 < warren> gmaxwell: I'm guessing ICANN procedure to get the domain taken away will be tried next
05:27 < gmaxwell> yea probably.
05:27 < gmaxwell> did you see they were having zillion block reorgs?
05:28 < sipa> who?
05:29 < TD> i saw that kanye's lawyer was trademark-whacking them. lol.
05:29 < gmaxwell> coinye coin.  another purpusfully dumb coin, but it started out with about 1/1000th of the initial difficulty it should have had.
05:29 < TD> and the anonymous authors response was basically to wave two fingers at them and say they'll bump up the release date
05:29 < gmaxwell> (they basically released a password to unlock the software at some time with enormous hype)
05:30 < sipa> eh?
05:31 < warren> if they were anonymous devs, with people unable to examine the software before the launch of mining, they could have included a trojan to steal <real coins>
05:31 < warren> lots of idiots would rush in
05:31 < gmaxwell> and now pools that lost the reorg wars have shuttered and people are angry that they're not getting paid.
05:31 < warren> and they would cash out in an unexpected way
05:31 < Taek42> warren sounds like something worth trying
05:32 < BlueMatt> warren: I'm honestly surprised we haven't seen more of that
05:32 < gmaxwell> it was only released a couple hours ago and has like 5000 blocks.
05:32 < gmaxwell> BlueMatt: esp now that some of these exchanges will happly add brand new coins.
05:35 < gmaxwell> is it just me or is bc.i switching to USD every time other people follow a link to it?
05:36 < sipa> experienced that as well
05:40 < michagogo|cloud> gmaxwell: not just you
05:54 < warren> BlueMatt: to avoid that someone could release all the code except for the genesis
05:54 < gmaxwell> I believe thats how ltc was launched.
05:55 < gmaxwell> https://bitcointalk.org/index.php?topic=404888.0 < fwiw, I posted asking about bc.i's switching
06:06 < TD> sigh. we need to beat some rationality into the fees market
06:19 < warren> TD: the way we rolled out 20x lower fees might be feasible (albeit very dumb)
07:54 < adam3us> TD, gmaxwell: i admit some fault with coingen.io also (I was stting opposite mappum when he registered the domain), not a new idea apparently, but I yacked about how cool it would be a bunch with BlueMatt and put him up to it.  maybe it'll back fire in interesting ways, but the intent is humorous clearly and genuine: to deflate param tweaks
07:56 < adam3us> TD, gmaxwell: and its actually serious.  it seems to me that alts are stifling actual innovation.  if u think about it inmany ways bitcoin innovation has virtually stalled since 2009.  thats why i want to kill param-tweaks, and think pegged side-chains are the bet new idea since 2009 in bitcoin period.
08:02 < adam3us> about ethereum i talked to vitalik about it, not sure i mentioned this part or not, that while fees is a solution to the halting problem in a Turing Complete complete script language; however the history of java byte code interpreter sandbox escapes could give it a massive, repeating, binary failure, where each sandbox escape results in theft of all coins (and maybe bitcoins)
08:15 < adam3us> aka there is a reason bitcoin script is functional, no iterators/recursion, and most of even the stylized/simplified/cut-down script language is itself disabled.  ripple dont seem to appreciate this risk and their draft script language looks turing complete.  in open transactions, chris showed me he has pluggable script language interpreter hooks and jscript, lua etc but thats just code because he likes generalized clean code.
08:54 < andytoshi-away> justanotheruser: logs are at http://download.wpsoftware.net/bitcoin/wizards/ ... if you msg andytoshi-logbot with 'help' i think it'll tell you
08:55 < andytoshi-away> sipa: re 'someone should write a "what to think about before making an alt" document', i'm planning to write something like that this weekend
08:58 < TD> adam3us: you wouldn't try to steal all coins simultaneously, that'd be dumb
08:59 < TD> adam3us: it'd just be treated as an outage
08:59 < TD> you'd want to steal 1% or something like that ...
09:00 < adam3us> TD: if these coins are pegged bitcoins, you'd want to steal as many as possible.  it depends on the reaction mode to stemming the loss.  if its like the many exchange/processor thefts like say sheep market place (the largest?) because of the irrevocability maybe you may not even care if u empty the alt chain in one go on the way
09:01 < adam3us> TD: what re people going to do? issue and deploy an emergency bitcoin patch to reject this specific side chains re-conversion?  that sounds centralized and fed policy like
09:01 < TD> we were talking about ethereum i thought?
09:01 < adam3us> TD: but you may well be right for detail reasons that the optimal exfiltration
09:02 < adam3us> TD: oh yeah sorry :D
09:03 < adam3us> TD: i guess that depends on the market cap and the liquidity and intent of the sabateur.  why are they killing the alt.  to make money or because they want to do a 'scorched earth' to borrow a petertodd'ism to prove a point
09:04 < adam3us> TD: lot of people might be quite upset and litigious about it if the market cap was like non-trivial at the time.  dangerous thing to do possibly even via Tor.
09:04 < adam3us> (sorry i was still in pegged side-chain mode so misinterpreted your observation)
09:04 < TD> anyway, most of the java sandbox escapes especially these days are not issues with the bytecode verifier but rather with the huge libraries or native code that they call out to
09:04 < TD> presumably ethereum would not have anything in the way of libraries or big surface area APIs
09:07 < adam3us> TD: interesting point, yes i never went looking at the root cause of the repeated sandbox failures, but if thts accurate the risk might be a bit lower.  but anyway i guess you can say its a brittle failure mode and more risky than  bitcoin as a value store as a result.  not only could a big bug collapse value like, but some worse things i think, like taking control simultaneously of all online nodes.
09:07 < TD> sure
09:07 < TD> code execution is always tricky
09:08 < TD> ironically, i suspect the JVM may end up being one of the safest sandboxes around. given how massively and repeatedly it's been attacked by hardened hackers compared to most sandboxes
09:08 < adam3us> (could happen to btc also, but higher risk as their code is basically an abstract interpreted asm with memory and iteration, pointers.  very flexible.  more like executing x86 interpreter)
09:08 < TD> if they keep plugging away at it for enough time, and if you restrict the API surface area, it could end up being kind of robust
09:10 < adam3us> TD: yes.  but it seems in some ways that btc is surfacing whole new levels of code assurance.  if there's a $1bil reward sitting on the table for entire system value exfiltration, more resources nd resourceful people get in, or lose their ethical behavior $ limit filter, seemingly empirically many otherwise trustworthy people have such limits)
09:11 < adam3us> just to say maybe its more interesting to sandbox escape ethereum (if btc was using that model right now) than sandbox vm escapes.  it only takes one.
09:11 < TD> yeah. it makes me wonder if one day it'll simply become impossible to make any changes to the code at all because the legal/financial risk of making a mistake is so high
09:11 < TD> either that or every bitcoin developer will be anonymous and work from behind Tor
09:11 < adam3us> TD: yes i think so
09:11 < TD> neither outcome seems desirable
09:11 < TD> still i guess banks manage, sorta, somehow
09:12 < adam3us> TD: the Tor thing is interesting.  i think people who get into exchanges and btc biz dont realize the risk they are putting themselves, their family etc at.  if they get enough value inside a server, they have become like a bank.  at the high end what do we need like thebunker.net or fortress with servers in it.  seems like banks or physcal security need to be part of the picture with multsig eventually
09:14 < adam3us> TD: yes, that seems part of the genuine value of banks, they have structured governance (cross checks) physical security, personnel vetting, alarms, perhaps monitored security at managers houses.  they had to think about it all and manage it.  that is actual value.
09:14 < TD> probably. one reason why i'd never run an exchange or bitbank. however, exchanges are needed, so .... someone has  to take that risk. w.r.t the rest of it, well, it's MIT licensed and disclaims all responsibility for everything
09:14 < TD> though i imagine some people will eventually ignore that and try their luck in courts anyway
09:14 < adam3us> TD: what u mean sue for losses due to code bugs?
09:15 < TD> well, or for any other kind of excuse. or patent lawsuits or whatever.
09:15 < TD> i mean as the amount of value goes up, anything could happen
09:16 < adam3us> TD: was vaguely wondering if one could retain unseizability property while protecting your self or your exchange or your processor (some server or equipment or paper under the service operators and employees control) from physical duress, by multisig the whole thing with a physical security provider of one part of the multisig.  the RA aspect of the bank multisig is typically weak also.  tho they do a lot of risk management
09:17 < WOODMAN> morning warriors
09:17 < TD> they're also insured
09:18 < adam3us> TD: like cheque sigs are not verified under £30k i hear.  but if u wire £20k you can do that with some lame, malware attackable security.  exactly insurance and risk management.
09:18 < WOODMAN> anybody been around on this technology since early days, i have a decent question if its ok?
09:18 < WOODMAN> brb
09:19 < andytoshi-away> WOODMAN: usually, try #bitcoin-dev first
09:19 < adam3us> TD: but i think what backs it all up is the revocability, usually when things go wrong they can undo the tx, they have ID, so they can recover even withdrawn funds, and insurance covers the rest
09:20 < adam3us> TD: btc lacks that.  and if we introduce it (certainly can do revocable, easy using irrevocable + multisig escrow) then the disput resolution costs come back in and btc tx costs same as credit card.  so we cant win.  the remaining new avenue is to some smart contract magic
09:20 < WOODMAN> what is this site?
09:20 < TD> yep. it might turn out in the long run that irreversible transactions are simply something humanity can't handle, when the amounts of value being handled get too high
09:20 < WOODMAN> https://bitcointalk.org/index.php?topic=11606.0
09:20 < TD> (too hard to build secure software systems)
09:20 < adam3us> TD: was ever thus.  ecash (irrevocable fast settlement) and slow cash just dont interface together well
09:21 < WOODMAN> i believe i bought bitcoin in 09
09:21 < adam3us> TD: yes.  maybe that is an answer.  large payments typically can tolerate being slow, and the parties having recourse enough to tolerate the revocability.
09:21 < WOODMAN> i never set up a client....bought from someone who put it on a USB and sent it to me....me never wanting to store on computer cause of hacking and never planned on selling, as there was no market at that time
09:21 < andytoshi-away> WOODMAN: #bitcoin please
09:21 < WOODMAN> i found this link and it discusses that you can put bitcoins on a USB
09:22 < WOODMAN> ah come on andy
09:22 < andytoshi-away> though i did enjoy the second post saying 'screw that, just use mybitcoin' :)
09:22 < WOODMAN> be a sport
09:22 < sipa> WOODMAN: #bitcoin, now
09:22 < WOODMAN> ahora!
09:22 < WOODMAN> im banned from there
09:22 < sipa> (you're very welcome to follow the discussion here, or contribute, but basic questions are completely off topic)
09:22 < TD> or post to bitcointalk
09:23 < WOODMAN> too many indians , not enough chiefs
09:23 < WOODMAN> this could be problem with open source
09:24 < WOODMAN> got another bitcoin IRC where they respect free speech?
09:24 < WOODMAN> or is this all funded by soros?
09:25 < adam3us> TD: "TD: (too hard to build secure software systems)" i worry about this.  baseband hacking smart phones, targetted sophisticated malware, code base targetted tampering, human error over time.
09:25 < sipa> /ignore WOODMAN
09:25 < TD> adam3us: best "solution" such that it is, is to avoid large pileups of value in one place
09:25 < adam3us> TD: it doesnt seem like security has even warmed up yet.  even the trezor & armory wallet are not safe from address substitution and payment protocol still leaves a gap in the merchant server
09:25 < TD> however, wealth inequality will not go away anytime soon. so .... not sure how far that takes you
09:26 < adam3us> TD: i think u could operate quite a bit of bitcoin ecosystem with airgap security protecting funds and airgap level of assurance of ownership of addresses
09:26 < adam3us> TD: even an exchange.
09:28 < adam3us> TD: (using color coin or better labelled /tagged coins on a pegged side chain and an offline issuer key issuing USD against a client funds issuer account. with a high reputation issuer)
09:31 < adam3us> TD: i think the airgap could save it as the exchange then has no btc funds or usdcoin funds at stake.  all cash funds are held in offline airgapped wallets at all times.  physical security for a merchant is like any supermarket... an armored truck deals with emptying.  but even better than can sweep electronically to a vault with armed guards at company HQ.
09:31  * TD -> away
09:35 < adam3us> hmm so maybe a solution is a different property coins circulating though. optionally intentionally (time-limited) revocable coins for large tx by companies to derisk their storage from physical assault.  and you can convert from revocable to irrevocable simply by waiting for the escrow smart-contract clause to expire
09:37 < adam3us> and similarly irrevocable become revocable by adding the escrow agent smart-contract.  actually for storage the revocability needs to be permanent.  the way you remove it is to spend it to an irrevocable address with the cooperation of the escrow agent.
10:40 < adam3us> TD: btw something else on the topic of software security and not daring to make changes to btc anymore, it seems to me there maybe scope to simplify high value storage & tx and perhaps layer the assurance.  eg full node only model requires less validation, less code, less assumptions, and high value can afford full node reliance.  not sure how to layer that upwards to SPV separately, but it seems like a desirable property
10:41 < CodeShark> adam3us: what about high values formed by aggregating lots of small ones?
10:41 < adam3us> TD: also apropos of the new discovery of a 23-year old remote root in all intervening? versions of X11.  how would that look for btc as a world currency.
10:42 < adam3us> CodeShark: doesnt change the picture, we're talking systemic risk of value bug
10:47 < michagogo|cloud> ;;later tell shesek Looks like the magic bytes appear 250,010 times in the first 250,000 blocks on disk (bootstrap.dat)
10:47 < gribble> The operation succeeded.
10:54 < sipa> michagogo|cloud: they could be occurring a few times just randomly as part of other data
10:54 < sipa> though 10 times is a lot
10:54 < michagogo|cloud> sipa: Yeah, I know that
10:54 < michagogo|cloud> (we had this discussion earlier (today or last night))
10:55 < jgarzik> adam3us, RE X11... url?
11:36 < adam3us> jgarzik: http://lists.x.org/archives/xorg-announce/2014-January/002389.html
11:38 < adam3us> jgarzik: "checked in on 1991/05/10, and is thus believed to be present in every X11 release starting with X11R5 up to the current libXfont 1.4.6"
11:39 < andytoshi_> adam3us: that bug is older than i am!
11:39 < sipa> andytoshi_: wow :o
11:39  * sipa suddenly feels old
11:39 < andytoshi_> well, only by 3 months :)
11:39 < sipa> well, I was in my first year at school in 1991...
11:42  * adam3us *is* old :) was starting CS PhD degree then
11:42 < sipa> haha
11:42  * sipa feels young
12:00 < WOODMAN> sipa take it somewhere else
12:00 < WOODMAN> sipa now
12:00 < WOODMAN> take it to lethargic IRC chat
12:00 < WOODMAN> now
12:00 < WOODMAN> go
12:00 < WOODMAN> run
12:01 < helo> :/
12:07 < WOODMAN> you kids are funny
12:07 < WOODMAN> B)
12:39 < justanotheruser> andytoshi_
12:40 < justanotheruser> do you have logs from the 2 way pegging discussion?
12:41 < nsh> justanotheruser, it's still in my buffer. can pastebin it
12:41 < nsh> (was meaning to give it another read later anyway)
12:43 < justanotheruser> nsh: please do
12:43 < nsh> moment
12:44 < justanotheruser> nsh: you mean the discussing I wasn't involved in right?
12:44 < nsh> oh, i meant from earlier today. i missed the discussion when gmaxwell mooted it
12:44 < andytoshi_> justanotheruser: one sec, i'm pretty sure i do..
12:45  * nsh defers to andytoshi
12:45 < nsh> (here's today, in any case (unlisted on pastebin): http://pastebin.com/Aefaxfew )
12:47 < justanotheruser> thanks nsh
12:48 < nsh> np
12:54 < andytoshi_> justanotheruser: sorry, i can't find it on my server's logs, will check my laptop's logs when i get home
12:55 < andytoshi_> there are memories in my brain of it, so i'm pretty sure i was present
12:55 < justanotheruser> andytoshi_: ok please PM me them, thank
12:55 < justanotheruser> s
13:53 < gmaxwell> andytoshi_: I made a kind of boring comment about the vntinyram paper: https://groups.google.com/forum/#!topic/scipr-discuss/1psbALDMkAI  (mostly I just wanted an excuse to post to the list and see if anyone was reading it, since there were no posts ever)
14:46 < nsh> gmaxwell, is that what you were referring to in this: "but the really small ones have some uncomfortable security tradeoffs (CRS assumption) the ROM ones are somewhat larger (eg 20kb, though I did invent a novel compression scheme which may help, so they may not be good for compressing header proofs" from earlier?
14:49 < gmaxwell> nsh: no.
14:49 < nsh> k
15:08 < jgarzik> adam3us, sounds like the root hole is in BDF font installation
15:09 < jgarzik> adam3us, thankfully, not really an actively used or triggered area
15:10 < adam3us> jgarzik: yes.  i was well is the coe in the bdf or the code is in a malicious font no? the latter is bad as someone can send u a font file.  did u know fedora 18 dvd wont install without network and downloads amongst other things fonts? (they are crazy)
15:10 < adam3us> jgarzik: or is bdf font an optional font system? so no risk if u havent installed that component?
15:11 < jgarzik> adam3us, well, (1) F18 installs fine without network and (2) any download exists inside a GPG-signed universe
15:12 < adam3us> jgarzik: hmm it depends which image u download, i tried 3 of them until i found one that installs without network cable.  their new installer is a bit of a mess, but i was pretty determined to get an all offline install and trid 7 isos from ubunu an fedora over pretty much 2 ays
15:13 < jgarzik> adam3us, at which step did you get stuck?  I might have had to do some magic to get my F18 going in its network-free VM
15:14 < jgarzik> adam3us, I keep several network-free VMs as virtual condoms for various things
15:16 < adam3us> jgarzik: about the gpg-sig.  the problem is 2-fold: one the WoT is sparse, secondly it doesnt define a merkle tree, so the content can be tailored to u and there is no rpm sig equivalent of certificate transparency
15:18 < adam3us> jgarzik: i finally gave up as i recall an used ethernet briefly i was very annoyed by that point, 2 days burnt on fedora & ubuntu i was astounded that it would fail for network on a DVD iso.  4GB and they want to fetch a font on the network or the install aborts.  actually it was probably fc 19.  i even tried ubuntu server install.
15:18 < jgarzik> adam3us, well each package comes from signed metadata package repo summary
15:18 < jgarzik> adam3us, I agree this does not solve 'tailored to u' problem
15:18 < adam3us> jgarzik: yes my point is say NSA has a copy ... ok right u get it
15:19 < adam3us> jgarzik: there is a solution.. merkle tree of snapshot of packages at iso release time, then your entire install is hardwired to the merkle root.
15:19 < jgarzik> adam3us, nobody wants packages of an era circa iso release time ;p
15:20 < jgarzik> adam3us, familiar problem as with routers:  the moment you open the box and turn on the computer, it is out of date and missing security and other critical bug fixes
15:21 < adam3us> jgarzik: actually i would happily take an out of the box for this app, which is admittedly completely atypical (i was testing armory prebuilt stuff and source stuff.)  that the DVD wouldnt install therefore was just the opposite.
15:24 < helo> hmmm... ubuntu without network has worked fine for me (via iso-on-usb)
15:27 < adam3us> jgarzik: also i guess we're going to need sooner or later the SSL / cert transparency, for rpm signatures, or something.  its pretty much spelled out in like schneier and applebaum research in teh docs and articles from that that NSA has well placed TCP hi-jack infrastructure with selective payload delivery.  u could imagine they might hve hacked some important signing keys via physical intrusion, black bag, NSL etc.
15:29 < adam3us> helo: i am not in a hurry to repeat that experiment it was the least fun i've had with a computer in quite a while.  this was ubuntu 10 and ubuntu 12 (whatever armory claimed to be prebuilt for, or latest stable for source) and fedora 18.  tried lots of isos.  i dont think i was dreaming.  been using linux since slackware 0.9 so i am not unusually fat fingered about linux installs
15:30 < helo> yeah, sounds pretty terrible
15:31 < gmaxwell> the fedora stuff kinda shuffles users torwards the crappy live image based installers, which I think do have to be online.
15:50 < michagogo|cloud> adam3us: 10 and 12?
15:50 < michagogo|cloud> Which ones?
15:50 < michagogo|cloud> (.04 or .10?)
15:51 < adam3us> michagogo|cloud: it was a month ago, i tried 10, 12 as main advertised iso on ubuntu.co and i think 10 server at suggestion of a hacker friend of mine that server maybe less chatty
15:51 < adam3us> .04
16:50 < andytoshi-away> gmaxwell: cool, glad to see (a) that the list is active and (b) we're not crazy to think we can be throwing hash circuits everywhere
16:51 < andytoshi> i have another concern, which i haven't mentioned since i haven't read the whole paper, about verifying input..
16:51 < andytoshi> presumably to make a snark-based blockchain we would want VERIFY (old chain state, new chain state, transactions)
16:51 < gmaxwell> someone needs to find a bored grad student to go generate circuits for sha256 and all the sha3 finalists and see which results in the fastest proofs.
16:51 < andytoshi> and we'd want the old and new chainstate to be public, but the transactions to be zero knowledge
16:52 < andytoshi> the impression i get from the paper is that if we want inputs to be public and provably there, we'd need them to appear in the preprocessing stage
16:52 < andytoshi> is this right?
16:54 < gmaxwell> andytoshi: no, the preprocessing stage just takes in the description of vntinyram itself, the time limit bound, and the _number_ of public inputs.
16:54 < andytoshi> are the public inputs what they call 'auxilliary inputs'?
16:55 < gmaxwell> no, public inputs are "program inputs", while "auxilliary inputs" are the ZK inputs.
16:55 < andytoshi> ok, thanks, great
16:55 < gmaxwell> (also non-determinsim used to simplify the tinyram circuit, e.g. like magical answers that tinyram divide by only having a circuit to check the answer)
16:56 < andytoshi> yeah, i noticed that, that was really clever
16:57 < gmaxwell> andytoshi: also, in your description above there is an extra thing that needs to be provided.. full nodes would also demand a set of updates to change from the old state to the new state.
16:58 < andytoshi> the proof would not be enough for them?
16:58 < gmaxwell> E.g. the transactions are ZK but you do actually need to know the final state (not intermediate states) in order to make the next proof yourself.
16:58 < andytoshi> right, that's what i mean by 'new chain state', they can just use that as 'old chain state' in their next proof
16:58 < gmaxwell> oh okay, I read what you were saying as a commitment to the state.
17:00 < gmaxwell> A non-miner in that model doesn't actually need to pay attention to the state much of the time... so commitments are good enough.. then they could just get fragments of the state from filtering nodes to prove they were paid.
17:01 < andytoshi> right
17:02 < andytoshi> and full/filtering nodes would have to figure out some way to efficiently store the series of chainstates
17:03 < andytoshi> perhaps snark-proving chainstate diffs would be more efficient, i dunno, these are just details at this point :)
17:03 < gmaxwell> its useful to commit to the diff as well, since then you can get it from someplace else.
17:03 < andytoshi> oh, good point, doing both gives the best of both worlds
17:05 < andytoshi> full nodes would use the diffs, non-full user nodes would use the full state to verify what the full nodes are telling them
17:08 < gmaxwell> if you want to be really snazzy,  you have a hiearachy of backpointers to old blocks, and at each backpointer level you keep a state snapshot and periodically commit big gap proofs.
17:09 < gmaxwell> then hotstarting a full node just involves evaluating log2(blocks)+ε proofs, and pulling down a full state.
17:09 < gmaxwell> but since the proofs are so fast, I goes O(N) proofs isn't so bad.
17:10 < andytoshi> we'll see what hardware looks like wherever this becomes feasible :P
17:10 < andytoshi> though my money's on "before 2020", and then things will look pretty-much the same
17:14 < andytoshi> justanotheruser: the 1-1 peg discussion starts (i think) at http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt
17:14 < andytoshi> (for some reason my logs from 12-17 to 12-27 were not on the website, that's why i couldn't find them earlier)
17:16 < michagogo|cloud> 2014-01-08 22:11:18 REORGANIZE: Disconnect 7880 blocks; 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f..
17:16  * michagogo|cloud 2014-01-08 22:11:18 REORGANIZE: Connect 31489 blocks; ..00000000ce13e2d877387db6a418974481fdcd946bcc72c3a52f1ed7ad34f2a5
17:17 < gmaxwell> michagogo|cloud: is that testnet?
17:17 < michagogo|cloud> It's Jesuscoin
17:17 < andytoshi> phew
17:17 < gmaxwell> ... Jesus coin?!
17:17 < gmaxwell> (I did a reorg on testnet that big)
17:17 < michagogo|cloud> gmaxwell: coingen
17:18 < michagogo|cloud> second coin on http://coingen.io/status.html
17:18 < gmaxwell> ohhh you blew up a coingen coin?!
17:18 < gmaxwell> hah
17:18 < michagogo|cloud> Well, my script is breaking
17:18 < michagogo|cloud> since the reorg lags jesuscoin-qt
17:19 < gmaxwell> hah
17:19  * gmaxwell titters at "jesuscoin-qt"
17:19 < gmaxwell> does it have an icon where a coin outline forms a halo around jesus?
17:21 < helo> it proclaims to _be_ the second coming
17:21 < michagogo|cloud> gmaxwell: http://imgur.com/Wldyc7t
17:22 < gmaxwell> aww
17:23 < michagogo|cloud> Okay, added begin,rescue,retry,end lines
17:23 < phantomcircuit> opportunity missed
17:23 < michagogo|cloud> that should make it stop crashing
17:24 < michagogo|cloud> If you're interested, here's my script: http://0bin.net/paste/OFWqJ7Lj0k0GO0o4#Rd6uP8VFxwv3SEO4HQAwtF+Vy5M3ZtaUrrKC9m3qI+w=
17:25 < michagogo|cloud> Anyone happen to know when Bitcoin's first difficulty increase was?
17:25 < gmaxwell> block 80k?
17:26 < michagogo|cloud> thanks
17:26 < michagogo|cloud> Heh, looks like the real chain is fighting with my replay of the bitcoin chain
17:27 < michagogo|cloud> Reorging back and forth
17:27 < andytoshi> ah, this is from before BlueMatt fixed the 'same genesis' 'bug'
17:27 < shesek> oh, it was fixed eventually? when?
17:28 < shesek> we were talking about it just yesterday
17:28 < gmaxwell> michagogo|cloud: oh I'm wrong about the height
17:28 < BlueMatt> no, it was fixed a long time ago
17:28 < gmaxwell> michagogo|cloud: 32256
17:28 < michagogo|cloud> Hmm, what did it rise to?
17:29 < gmaxwell> 1.18289953
17:29 < shesek> oh, I was under the impression it was still like that yesterday... someone said it was
17:30 < michagogo|cloud> If anyone feels like watching jesuscoin get killed, https://secure.join.me/671-648-265
17:30 < michagogo|cloud> (tailf of jesuscoin's debug.log)
17:32 < michagogo|cloud> Hey, I think I might have just pulled ahead
17:33 < michagogo|cloud> BlueMatt: How many coingen coins used Bitcoin's genesis block?
17:33 < gmaxwell> michagogo|cloud: too bad there aren't any huge tx fees until fairly late.
17:34 < michagogo|cloud> gmaxwell: Why?
17:34 < gmaxwell> otherwise I'd say it would be fun top play it up to right before the point where there was a block with huge tx fees. Then mine that txn yourself.
17:34 < BlueMatt> michagogo|cloud: no idea
17:34 < gmaxwell> Then continue on.. and you get the huge tx fees.
17:34 < michagogo|cloud> gmaxwell: heh
17:37 < helo> where's the boom?
17:37 < michagogo|cloud> helo: https://secure.join.me/671-648-265
17:39 < michagogo|cloud> shh, nobody tell Luke-Jr that I killed Jesus(coin)
17:39 < helo> interesting date
17:39 < michagogo|cloud> helo: hmm?
17:40 < helo> jesuscoin has blocks as far back as 2010?
17:40 < michagogo|cloud> helo: It's the Bitcoin blockchain
17:41 < michagogo|cloud> I'm just using http://0bin.net/paste/OFWqJ7Lj0k0GO0o4#Rd6uP8VFxwv3SEO4HQAwtF+Vy5M3ZtaUrrKC9m3qI+w= to replay the bitcoin blockchain onto Jesuscoin
17:42 < helo> wouldn't the hard coded genesis block make that not work?
17:42 < shesek> they share the same genesis block
17:42 < helo> bad move :/
17:42 < shesek> coingen used to give the altcoins it created the same genesis block as bitcoin's
18:20 < gmaxwell> andytoshi: the proving process for QAP snarks is ludicrously parallel, I wonder if it would make sense to have distributed generation of the proofs? ... I think the problem is that they need communcation similar to the prover key in size.
18:23 < maaku> adam3us: I've done multiple ubuntu installs without network connection ... i know it works for 12.04
18:26 < andytoshi> gmaxwell: hmm, a high communication requirement is going to incentivize centralization
18:26 < andytoshi> and in general, if you break the proof up it is hard to decide what part any individual miner should work on
18:27 < andytoshi> which i think also encourages centralization since it is easy to organize a single mining farm to not step on its own toes
18:30 < andytoshi> i think "ludicrously parallel" will just mean that we don't have a gpu-hard mining algorithm here
18:30  * maaku downloads jesuscoin-qt and goes to make some popcorn
18:32 < michagogo|cloud> maaku: not much to see
18:32 < sipa> i expect jesuscoin to be able to fork, and keep both instances alive...
18:32 < michagogo|cloud> It'll just look like Bitcoin-Qt syncing
18:32 < maaku> is it off of git-head, or 0.8?
18:33 < michagogo|cloud> 0.8.6
18:33 < sipa> 0.8.6 iirc
18:33 < maaku> oh :\
18:33 < michagogo|cloud> Why?
18:33 < michagogo|cloud> Which git feature were you hoping to use?
18:33 < maaku> i was hoping for some fine grained timestamps on the log messages to get a good idea of how the reorg was spreading through the network
18:33 < maaku> vs. the "honest" miners
18:34 < michagogo|cloud> maaku: you can roll your own
18:34 < michagogo|cloud> Just built git head and change the pchMessageStart
18:34 < maaku> yeah true. i suppose I just need the port & msg bytes
18:34 < michagogo|cloud> port 9336
18:34 < michagogo|cloud> Don't know the magic, though
18:34 < michagogo|cloud> Sorry
18:35 < maaku> np. thanks
18:35 < maaku> i'll read the first 4 bytes of blk*.dat
18:35 < michagogo|cloud> (Not at my computer anymore, I'm writing this from my bedroom)
18:37 < shesek> so I guess Satoshi is now heavily invested in Jesuscoin? :)
18:37 < shesek> he should own a pretty large chunk of it
18:39 < shesek> given his large ownership in the early bitcoin blocks
18:39 < sipa> ...?
18:40 < maaku> shesek: yes, but unfortunately he Ascended into heaven in 2010 without leaving any of his public keys to his disciples :\
18:40 < maaku> /public/private/
18:40 < sipa> someone should create a Nakamotocoin - dedicated to The Ascended One
18:41 < sipa> by mocking his Creation
20:19 < justanotheruser> thanks andytoshi
20:22 < gmaxwell> From #p2pool:
20:22 < gmaxwell> 17:20 < owowo> gmaxwell: can you explain why ppl are mining on those BIG pools?
20:22 < gmaxwell> 17:21 < owowo> I don't get it, they must get more coin there.
20:23 < gmaxwell> oh he says he was kidding now.
20:23 < gmaxwell> dude just nearly dodged getting face-stabbed.
20:27 < shesek> bigger pools could operate on lower margins, so miners could benefit from the lower fees
20:27 < shesek> I'm not really familiar with pools though, so I'm not sure if that's true in practice
20:27 < gmaxwell> shesek: except that there are smaller 0 fee options (including p2pool)
20:28 < gmaxwell> the biggest pools have historically had the highest fees.
20:29 < gmaxwell> (the exception being ghash.io, and thats weird on a couple levels including the that its widely understood that the owners of ghash.io own a majority of the hashpower on their pool)
20:29 < shesek> doesn't ghash's hashpower comes mostly from cex?
20:30 < gmaxwell> shesek: yes, common ownership.
20:30 < shesek> which is physically owned by them, but should be "owned" by other people
20:31 < shesek> though as long as they have physical ownership over the hardware, its really a matter of trusting them
20:31 < gmaxwell> yea, no clue how much of cex is "owned" by other people— they don't disclose that, the prices are off the charts.
20:32 < gmaxwell> in any case, ignoring ghash.io it's always been the case that the largest pools had the highest fees, almost nearly in order.
20:32 < shesek> btw, about p2pool, doesn't it have a much higher orphan rate that would really effect payouts for the worse?
20:32 < gmaxwell> wow
20:32  * gmaxwell cries
20:32 < gmaxwell> shesek: no, P2pool's orphan rate is lower than other pools by an order of magnitude.
20:32 < shesek> sorry, I'm really not familiar with p2pool and pools in general, I'm just asking to educate myself better :)
20:33 < gmaxwell> My crying is because it's just a replay of the constant fud that circulates and has no basis in reality. :( It's not your fault the whole world is dumb.
20:33 < shesek> so it seems like a lot of people are misinformed about that, I've read that in multiple places
20:34 < shesek> and I wonder how it worked out like that with the pools fees
20:34 < shesek> and why people keep joining the bigger pools if that's the case
20:35 < shesek> it might be psychological, where people think that bigger pools are better for some reason
20:35 < shesek> they face a choice paralysis when they need to pick one, and go after the largest one hoping that its somewhat better
20:35 < gmaxwell> back in early 2012 there was a span when p2pool had a somewhat high orphan rate, it's not clear if it was just bad luck or a real problem but major work was done to improve it. The end result has in the last several months had only 2 orphans against like 1627 blocks. Compared to, say, eligius which has had somewhat more than 1% orphans (also typical for other pools)
20:36 < gmaxwell> Overall p2pool has solved about 107% of the blocks you would have expected based on its observed work done.
20:37 < gmaxwell> shesek: oh a lot of people misunderstand why pooling exists, they think that mining is a race— and in a race the fastest party always (or almost always) wins.
20:37 < gmaxwell> They talk about needing an X TH miner in order to "keep up" and things like that.
20:37 < gmaxwell> Following that logic, the biggest would be best. sooo.
20:38 < gmaxwell> also explains the inverse fee relationship. They think the biggest is best but attempt— without the aid of math or understanding— to balance that against fees.
20:38 < shesek> educating miners better could definitely help here, some more official resources about that could do some good
20:39 < shesek> an "introduction to mining" on bitcoin.org or something
20:40 < shesek> I do think there's some choice paralysis in play here too. Miners don't really have any effective way to pick a pool, which makes that choice somewhat hard... I guess that some just pick the biggest by default
20:40 < gmaxwell> yes, "so many other people choose it, it has to be good"
20:41 < gmaxwell> we've also seen some "large pool cycling" where the second or third largest pool gets a lucky run and shows up at the top of the charts... and then it becomes the largest pool.
20:42 < gmaxwell> P2pool has a bunch of UX stupidity that doesn't help— even feeds into the misunderstandings.
20:42 < shesek> perhaps something that helped pick a pool, with a weighted random based on the inverse popularity
20:42 < gmaxwell> there really is only one pool we should be recommending, p2pool. It's the only suriving pool thats a decenteralized system.
20:42 < shesek> could be marketed as "help save Bitcoin from centralization by using this!"
20:43 < gmaxwell> warren has been trying that.
20:44 < shesek> setting up an "whatpoolshouldipick.com" that simply gave one pool in a big font with a link, explaining how the selection works, could be nice
20:44 < shesek> and help overcome that choice paralysis
20:44 < shesek> but yeah, long term, p2pool is much better
20:45 < shesek> but its still somewhat inaccessible to users and requires setting up a full node
20:45 < shesek> I saw a thread about this on bitcointalk, it would really help if they setup a nice looking website with instructions and easier way to get it up and running
20:45 < gmaxwell> 'they'
20:46 < gmaxwell> it's not like there is a P2pool company.
20:47 < shesek> well, yeah, it should really be a community effort
20:47 < shesek> not really "they", more like "we"
20:47 < gmaxwell> At the moment setting up a full node is so burdensom that its sort of the long poll in the tent. Sync really needs to be fixed.
20:49 < shesek> what are your current thoughts on the best way to address this?
20:50 < gmaxwell> It's addressed by sipa's headers first sync work.
20:50 < gmaxwell> But the code is immature.
20:52 < shesek> sipa closed https://github.com/bitcoin/bitcoin/pull/2964 saying that he's working on something better, is it public yet?
20:52 < shesek> can't seem to find a newer pull request / issue
20:54 < gmaxwell> shesek: he has been pipelining the changes since it seemed to be a bit much at once. https://github.com/bitcoin/bitcoin/pull/3370
21:02 < shesek> cool, I haven't really kept up with developments on that front, looks like a good solution
21:05 < shesek> gmaxwell, what do you think about that website I suggested? I think it could be pretty cool as a go-to solution for picking a pool
21:05 < shesek> can even be provably fair by basing the "random" choice on the user's ip and user agent
--- Log closed Wed Jan 08 21:14:13 2014
--- Log opened Wed Jan 08 21:19:30 2014
--- Log closed Thu Jan 09 00:00:17 2014