--- Log opened Tue May 21 00:00:09 2013
01:17 < warren> sipa: when are you flying back home?
03:52 < sipa> warren: 31st
08:12 < warren> I ran out of time.  switching back to openssl or now.  I just need to get this done.  I'll get back to secp256k1 later.
08:13 < warren> Aside from the wallet.dat privkeys rejected by secp256k1, there is some other database related corruption from my secp256k1 gitian builds. I am unable to reproduce it on fedora 18, but it happens often on Ubuntu 12.04.  An identical build with openssl has no issue there.
--- Log closed Tue May 21 14:27:17 2013
--- Log opened Tue May 21 14:29:11 2013
20:45 < gmaxwell> anyone want to take bets on freicoin's new control system being unstable? :P
20:49 < warren> gmaxwell: URL?
20:49 < gmaxwell> see conversation in #bitcoin-dev
20:49 < warren> is there a log somewhere?
20:50 < warren> gmaxwell: I'm halfway through regression testing a rebase of litecoin.  the litecoin lolbertarians are upset about me "taking away our independence from bitcoin".
20:51 < gmaxwell> warren: rot13 all the variable names to make it independant?
20:51 < warren> gmaxwell: that might make it hard for the 10 new clone coins a week to understand litecoin code.
20:51 < sipa> also, swap a's and e's
20:52 < warren> OTOH, they don't actually change anything, so that may not make any difference.
20:52 < jgarzik> ;p
20:53 < warren> I'm slowly introducing every crazy anti-spam idea I can think of.
20:53 < gmaxwell> warren: remove the block size limit while you're out it in order to test out suppositions about bitcoin scalablity for us. :P
20:54 < warren> gmaxwell: I was considering removing the soft limit because the onerous fees have discouraged people from filling the blocks anyway.
20:55 < gmaxwell> makes sense, but why not remove the hard limit too and just add a bit of code to prefer to build on blocks that are smaller?
20:55 < warren> prefer in what way?
20:56 < sipa> when comparing a new block to the best chain, consider it better if the work is equal but smaller
20:56 < warren> Hmm, if I remove block size limits, then doesn't that remove the > 50% preference for higher than minimum fees?
20:57 < gmaxwell> No one knows. Some credible and trustworthly people argue that removing the limits is completely viable and would like to do it in bitcoin very soon. (where very soon is like.. a year or two)
20:57 < warren> I've read those writings by "credible and trustworthly people", and I disagree with them.
20:58 < sipa> you're not alone
20:58 < sipa> (then again, they aren't either)
20:58 < gmaxwell> I'm a chicken and don't agree but I must confess that my position is dominated by an absense of evidence rather than evidence that disproves their positions.
20:59 < gmaxwell> I don't think Bitcoin can afford to get it wrong, however. I think it's more likely that litecoin can.
20:59 < gmaxwell> OTOH litecoin isn't a great test because we might never get a useful answer.. not enough usage.
20:59 < warren> I was also putting secp256k1 into test builds for the small private QA group just to give it more test exposure.  Nobody has managed to artificially create a new wallet with 0.6 that causes secp256k1 to fail, but 80% of old wallets with lots of keys and transactions have trouble with secp256k1.  none of them are willing to share their wallet.dat though.
21:01 < warren> (It bombs out immediately with: init message: Loading wallet...\n Error reading wallet database: CPrivKey corrupt \n Error reading wallet database: CPrivKey corrupt \n Error loading wallet.dat: Wallet corrupted
21:01 < sipa> warren: can i see the code?
21:01 < warren> sipa: yes, hold
21:02 < warren> It's in a hidden github repo, I don't have access to grant permission.  would a diff be ok?
21:02 < sipa> i prefer to see it entirely
21:02 < sipa> as i have no clue what other changes litecoin has or hasn't
21:02 < warren> let me figure out where I can put it where it remains private
21:04 < warren> sipa: please provide me your ssh pubkey at a URL I can grab
21:05 < sipa> ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOGWpqoVnJ0IrKARDDrSKbdoyCQonG+fAUX8XNhgO7VTkUfOAnqByVh6xG1RfzNI1UiE3AG3lv3cB2Pyz43cRzc=
21:05 < warren> hah.  my server can't do ecdsa
21:05 < gmaxwell> ^ thats part of the point for him in changing out openssl!
21:05 < warren> exactly
21:05 < sipa> ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAxs4zxmvGrtdtzCFrEyVhaxj/nB29TrcExZzqLhb8pZK+7zl3njGUbVNf3HZ3EgTVDyfSZsw44qNIwAg4XeWllIy/h8bdLZoUgd53Y1J3vJu+CNwZqw+4lKZG7Wj2bzSD+DM/GmreEbqtDuFLG5gnO8FKssSuopWEzkSiA+8HXYOsRd9b3PdmwVJbGdULd5HKPe8wtWD1GLBag5rwOh6UiSZdD1zXvPNCOLPRs1tk64bmJ1ntHckEp4MiZxvTE1tahldd4OG5uEsnOW7+T89hBtE7RPEe6B2Te62Evw16RqI/QCh0Jr6XWz1So0oTsAO+rQ3opE2SkNUl0kwx1XbUew==
21:06 < warren> well, i tried to rebuild Fedora 18's openssl with ecdsa yesterday.  It needs patching to actually build.  jgarzik said he gave up on it.
21:06 < gmaxwell> really? ... weird! did you replace the tarball?
21:07 < warren> yes
21:07 < warren> it's all the fedora patches on top of it that complicate it
21:07 < sipa> do you need those patches?
21:07 < warren> probably not.  I haven't tried removing them all yet.
21:07 < gmaxwell> The procedure is to replace the openssl tarball with the matching one from the site (the one fedora gives is gutted), comment out the patch in the spec, and then remove the no-ecdsa stuff in the configure line.
21:08 < gmaxwell> I just did the latest F17 ones the other day without issue. I don't yet have a F18 host so I haven't tried that.
21:08 < warren> Yeah, it bombs out with missing references to ecdsa stuff from fipscanister.o
21:08 < warren> F18 has a rebased openssl
21:08 < gmaxwell> :-/
21:08 < jgarzik> gmaxwell, not that easy anymore.  Now makefiles require patching
21:09 < warren> jgarzik: you switched to Ubuntu now? =)
21:09 < jgarzik> that plus EFI #fail forced me onto Ubuntu
21:09 < jgarzik> :(
21:09 < warren> =(
21:09 < warren> I wonder how many users/developers bitcoin lost in these past years over this.
21:10 < warren> Yes it's not difficult to bypass, just annoying.
21:10 < gmaxwell> I haven't upgraded to fedora >17 because I feel kinda blah about its future... I'd probably be moving to gentoo but it just doesn't have enough active development.
21:10 < gmaxwell> I'll probably end up moving all my stuff to F19 by default, but not really excited about it.
21:18 < warren> jgarzik: can you chain load ubuntu's EFI loader to fedora's boot loader? =)
21:18 < warren> hmm... how to you add a ssh git remote with a non-standard port number...
21:19 < warren> it turns out stackexchange has this answer.
21:23 < warren> sipa: PM.  Ignore the Coin Control stuff which isn't part of litecoin.  I used that as a lazy way to visualize the available inputs.
21:26 < warren> sipa: shoot, you'll have to let me know your IP address, it doesn't allow incoming connections. =(
21:26 < warren> nevermind, I'll just open the firewall for now
21:27 < warren> ok, opened
23:01 < gmaxwell> fuck: http://blockchan.org/
23:08 < amiller> wat
23:12 < warren> gmaxwell: looks like a highly secure online service
23:13 < gmaxwell> it's 4chan implemented— apparently— using data storage transactions.  You pay for access, and that funds the spam.
23:21 < warren> gmaxwell: coblee and I are considering a radical change to fees where we charge primarily for outputs and make inputs a lot cheaper.  This means you are charged for the quantity of outputs, and even higher fees for dust outputs.  Inputs would have a cost but much lower.
23:21 < gmaxwell> warren: and change your blocksize rule to be based on that?
23:22 < warren> well, we're only thinking about this.  It needs a lot of testing.  I haven't thought of a way to exploit this yet.
23:23 < gmaxwell> The obvious metric is the make the transaction size for blocksize rule the utxo set change plus some constant factor (e.g. 1% of the size of the transactions) so that you can't get an infinitely large block that is just cleaning up the utxo.
23:23 < gmaxwell> and then make fees based on the same metric.
23:23 < gmaxwell> it doesn't solve uneconomic utxo but makes it much harder for them to exist.
23:24 < warren> The general idea is to indeed use fees to discourage the growth of UXTO.
23:28 < warren> gmaxwell: a major flaw in that plan is how would pools pay miners and "stocks" pay dividends.  That may scuttle the plan.
23:30 < gmaxwell> warren: why? I mean these things have a cost... failing to charge for it doesn't make the cost go away.
23:31 < warren> Wouldn't that encourage paying the miners through side-channels to include their massive tx's at sub-normal costs?
23:32 < warren> Or perhaps it's cheaper for many-dust-payers to pay using Bitcoin instead, since TXO's would be so much cheaper there. =P
23:33 < gmaxwell> uh. ... like. you guys are going to just produce failure if your ideas include things like trying to rule-specify fees in transactions!
23:33 < warren> "include things like trying to rule-specify fees in transactions!" isn't that what litecoin already does?
23:35 < gmaxwell> no.
23:35 < gmaxwell> or well, you know it better than I do
23:35 < gmaxwell> Is it that stupid?
23:37 < warren> trying to find the URL...
23:38 < gmaxwell> warren: litecoin will reject blocks that don't have some particular fees? thats nuts you can trivially pay outside of the blocks or have rebates outside of the blocks, or mine fake fees to yourself.
23:38 < warren> gmaxwell: no, I think we misunderstood each other.
23:39 < gmaxwell> thats why I asked the clarifying question, okay.
23:40 < gmaxwell> <foamy> so lets say tomorrow i wanted to start a website that needed login credentials.
23:40 < gmaxwell> ^ it's rude of me to snark behind his back, but I don't really mean this personally—
23:40 < gmaxwell> this is an example of many other people too— ... are we doomed because people want
23:40 < gmaxwell> to use bitcoin inefficiently because it's the only #$@#$@ public key signature system they know how to use?!?
23:42 < zooko> It is a great leap forward over others because it doesn't have a "name" field.
23:42 < zooko> (Tahoe-LAFS has that feature too, but it is relatively obscure.)
23:42 < zooko> Don't worry! Once people learn the new payment protocol and its x.509 names then they'll find bitcoin just as hard to use as the others.
23:42 < gmaxwell> well this guy wants a name field. "addresses are too hard"
23:42 < gmaxwell> :P
23:43 < zooko> Haha!
23:43 < zooko> I think there's a deep truth lurking in here somewhere.
23:43 < zooko> Trying to grab my ankles and drag me to the depths.
23:43 < warren> arm wave and tell him to reuse namecoin in some bad way.
23:44 < gmaxwell> he doesn't have a consensus problem, he doesn't need a blockchain at all.
23:44 < gmaxwell> I told him to use Persona.
23:44 < zooko> Ooh, nice.
23:45 < gmaxwell> he just wants a portable identity service without a centeral identity provider.
23:45 < zooko> Yeah, I think Persona was the right answer. Nice one.
23:45 < amiller> does anyone understand bitmessage
23:45 < amiller> it's an entirely separate blockchain right it doesn't try to be merge mined like namecoin?
23:45 < gmaxwell> there is no blockchain
23:45 < gmaxwell> it's just hashcash flooding messages.
23:46 < gmaxwell> (which is fine)
23:46 < amiller> er, hm well there's no incentive argument
23:48 < gmaxwell> if it's cheap enough to run because the hashcash ratelimits it, then there doesn't need to be an incentive beyond "have a useful system, and have your own participation be anonymized by the fact that you're running it"
23:48 < gmaxwell> they divide the anonymity set to scale better. ('channels')
23:49 < amiller> i'm still sort of looking for an application where extra consensus storage in the utxo is worthwhile and then maybe that's a good way to prototype utxo storage fees
23:49 < amiller> the only reason not to use Namecoin as that application is because there's this additional complexity about how to handle initial allocation of names and such
23:50 < warren> what ever happened to namecoin?  why was it never updated?
23:50 < warren> the lack of a GUI to make names might have limited its appeal?
23:51 < warren> Or it tried to solve a problem that people really didn't care about?
23:52 < gmaxwell> those two, also developers lost interest (somewhat the case in litecoin too), also the developers were pissed about speculation and adjusted the cost of names way down and people then registered every possibly interesting name
23:54 < gmaxwell> also merged mining gave a ton of namecoin to people who didn't care about names... making it more expensive for people who did.
23:54 < gmaxwell> not only didn't care about names, but had never even run the software and couldn't register one!
23:55 < gmaxwell> also their design had no mechenism for a secure lite mode resolver— which got lamer as the chain grew...
23:55 < warren> I'm guessing that chain would be really cheap to spam to death.
23:55 < gmaxwell> (though I 'solved' that by inventing committed utxo sets! well kinda, I didn't instantly see how to prevent tree unbalancing attacks)
23:56 < amiller> fuck it just use tries
23:57 < gmaxwell> I didn't think of that at the time, but didn't think too hard ... I did think of "just use a self balancing tree" except I worred about the worst case complexity of an update.
23:57 < gmaxwell> but yes, a prefix-trie is the obvious thing to do.
23:58  * amiller stopped worrying and loves tries, w/ev
23:59 < amiller> namecoin would likely suffer from utxo bloat though
23:59 < gmaxwell> also, the namecoin community provided insufficient on-ramping. E.g. if they'd raised money and bought .bit (the real TLD) and proxied to it... I bet namecoin would be dominating the world of something now.. but back then raising a few hundred K in the bitcoin community wasn't obviously possible.
23:59 < gmaxwell> amiller: it has renewals required every 30k blocks. ... so not name utxo bloat!
--- Log closed Wed May 22 00:00:03 2013