--- Log opened Wed May 29 00:00:43 2013
09:54 < jgarzik> midnightmagic, yeah, OKPay dropped bitcoin in general
09:54 < jgarzik> Definitely a wave of [expected] enforcement actions
10:00 < petertodd> Personally I'm really curious to see if they go after localbitcoins and bitcoin-otc in any way.
10:06 < jgarzik> petertodd, They took down exchangezone.com, which was surprisingly similar
10:07 < jgarzik> exchangezone.com did do some holding of funds, though, IIRC, so not quite the same target.
10:07 < petertodd> localbitcoins holds fund
10:08 < petertodd> they have a SMS escrow-like service where you SMS to release the funds to the receiver so you don't have to wait for confirmations
10:08 < jgarzik> petertodd, veeerrryyyy interesting….
10:09 < petertodd> and they operate in a 139 countries, so guaranteed they break the law somewhere
10:10 < petertodd> hosted in germany FWIW
10:52 < jgarzik> petertodd, yeah I figured that.  Though I thought it was hosted in Finland.
10:52 < jgarzik> I think a Finn runs it
10:58 < petertodd> Figures. Same ISP as easywallet
10:59 < petertodd> Be interesting to see how the foundations lobbying plans go.
10:59 < petertodd> Patrick Murck seemed pretty reasonable at the conf.
11:02 < jgarzik> petertodd, I am strongly in favor of lobbying.  Too many people confuse lobbying with regulation.  If there are anti-bitcoin forces in government, I'm all for -- for those who wish to fund it -- there being pro-bitcoin forces opposing them.
11:03 < jgarzik> There seems little danger IMO of lobbying making life worse for bitcoin.  There will never be a wonderful, regulation-free life that crypto-anarchists want, but maybe it can be made less bad.
11:04 < jgarzik> I'm happy with the nature of bitcoin, and by its nature it cannot really be outlawed.
11:04 < jgarzik> I do agree w/ Adam B that a regulatory regime is quite possible, targeting c.f. mining pools
11:04 < BlueMatt> the internet (tm) in general needs more lobying
11:04 < petertodd> Agreed. As Patrick said, you almost certainely can't get unregulated exchanges, but you may be able to reduce or eliminate regulation on virtual currency transactions, and in any case you can't make it worse.
11:04 < BlueMatt> but bitcoin too
11:05 < petertodd> Even when you are doing things that are made illegal by regulation, just having the lobbying there to make them easier, and/or reduce penalties to something sane, is a big win.
11:05 < jgarzik> I do fear the day when a court order requires a bitcoin operator to refuse spends of bitcoin 0x1234
11:06 < jgarzik> mtgox already does this a bit
11:06 < jgarzik> agreed
11:06 < petertodd> Same, and I think it's worth it to get as much technical inertia as possible behind anonymity and privacy within the protocol as soon as possible to make implementing those regulations disruptive.
11:07 < petertodd> That's why we realy, really don't want to be in a situation where the code is already there, AKA blacklists of any sort.
11:08 < petertodd> Too bad the math for an efficient zerocoin doesn't exist yet...
11:09 < jgarzik> Part of staving off regulators is interia in general:  if it can be shown that bitcoin is "mostly criminals", then they can effectively argue it should be made illegal generally.  You see a lot of text like that in current Liberty Reserve warrants and press releases.  Copyright is a similar standard: there must be "substantial non-infringing uses."
11:09 < jgarzik> Thus, getting "regular users" on boat is critical
11:10 < jgarzik> Criminal use is inevitable, just like with the US Dollar.  The challenge is non-criminal use :)
11:10 < jgarzik> Technically, with a court order, I fear a US/non-US fork :(
11:10 < petertodd> Well, non-criminal use worries me... Bitcoin isn't a great payments system for a lot of reasons, and I firmly think that we'll see more stuff like Mintchip made to combat it in that arena.
11:11 < petertodd> Granted, Bitcoin does have a very legit use unrelated to that: investing in an asset class totally different from any other. But even that can be portrayed badly.
11:11 < jgarzik> I think it's fine for value transfers, where you can wait for the confirmations.  If you cannot wait the requisite amount of time, ideally, you should be using a companion payment network.
11:12 < BlueMatt> jgarzik: spv clients :p
11:12 < jgarzik> …that settles on the main bitcoin network
11:12 < jgarzik> BitPay is interested in "payment channels", I wonder if they would get behind an effort to run off-chain payment networks
11:12 < petertodd> Sure, but it's a whole new currency, and this and that and... if the Canadian Mint was smart they'd promote Mintchip heavily internationally. After all, it's more private than Bitcoin, mostly.
11:13 < jgarzik> heh, a lot of the Liberty Reserve press and comments were also pointing out that LR was "more private and anonymous than bitcoin"
11:13 < BlueMatt> jgarzik: let me point you to https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party
11:13 < BlueMatt> "Mike Hearn is working on an implementation of this protocol in bitcoinj. Please contact him for more information."
11:14 < jgarzik> BlueMatt, nod, though that's dependent upon nLockTime AFAICT
11:14 < BlueMatt> no
11:14 < BlueMatt> it depends on nLockTime being non-standard now (with some ability to function if it becomes standard)
11:17 < Luke-Jr> nLockTime isn't non-standard.. just if it hasn't passed
11:17 < BlueMatt> sorry, it depends on that, not all of it being nonstd
11:18 < petertodd> jgarzik: I really hope someone does that. I'm totally ok with it being a closed paypal-like system - there's always room for alternatives
11:18 < petertodd> jgarzik: ha, yeah, compared to having all your pseudonyms on the blockchain
11:19 < petertodd> BlueMatt: jeremy spilman came up with a better protocol that doesn't need nLockTime
11:20 < petertodd> jgarzik: Ideally you'd start with an open-protocol, where users/merchants/etc can choose what keypairs they trust, and then build upon that.
11:20 < BlueMatt> petertodd: not 100% sure, just skimmed that mail, but I think the new one on the wiki is the same
11:20 < BlueMatt> petertodd: and (again) it depends on nLockTime being nonstandard up to lock time
11:21  * BlueMatt isnt sure exactly which "payment channels" is being discussed, but if its done right, it can be all two-party (no blockchain) until the end and then only a few txn can be put in the chain to complete it
11:22 < BlueMatt> (without any trust)
11:22 < petertodd> BlueMatt: Ah, yeah, that's jspilman's version. Nice to see the wiki got updated with it.
11:23 < BlueMatt> anyway, I know mike is actually implementing it, so ping him
11:28 < petertodd> BlueMatt: cool
11:29 < BlueMatt> afaik its pretty far along too
11:31 < petertodd> any client code yet?
11:31 < BlueMatt> hmm?
11:32 < petertodd> I mean, like a demo for an application?
11:32 < petertodd> that'll be the hardest part I think
11:32 < BlueMatt> no idea
11:34 < petertodd> ok, just thinking, lots of subtle issues re: backups and other stuff with protocols like these
11:34 < BlueMatt> entirely depends on how long your channel is
11:34 < BlueMatt> if the channel lasts a few hours...meh
11:34 < petertodd> same problem with chaum tokens: you need to have a reliable way of storing multiple copies immediately of the token, or in this case, the refund tx
11:35 < BlueMatt> sure, if it lasts a month you want to store the state of the channel in the wallet
11:35 < petertodd> it can be skipped initially, but for production...
11:35 < petertodd> well it's a matter of how many coins you are putting in limbo, 0.01BTC, no worries, 1BTC, that's another matter
11:48 < jgarzik> heh, yeah.  I was thinking a payment channel that lasts ~24 hours.  Definitely some wallet state storage, to think about.
11:48 < jgarzik> but really, I'm off-chain agnostic.  The more off-chain systems out there, the better.
11:49 < jgarzik> Would be interesting to see an open source package out there replicating The Big Tor User out there.
11:50 < petertodd> well, one guy contacted me saying he's working on one in his spare time, and I'm meeting with what sounds to be a much more professional effort next week that will include some trusted hardware
11:51 < petertodd> actually, I think just implementing a merkle-sum tree package is worth it - a few companies at the conf said they were interested in that kind of transparency
11:51 < petertodd> like the bitcoin fund guys
11:53 < BlueMatt> bitcoin fund: we fund useless crap
11:53 < BlueMatt> or at least not stuff that is reasonably high priority
11:54 < petertodd> BlueMatt: which fund do you mean?
11:54 < BlueMatt> you mean the guys who offered how many thousands to split wallet and core?
11:54 < petertodd> no, I mean bitcoinfund.eu, the guys offering bitcoins as a professional investment fund
11:55 < petertodd> those guys are crazy, and I wonder if they are really legit
11:56 < BlueMatt> they do have /some/ money...no idea how much it really is, but they kinda picked a random thing and put a big bounty on it
11:56 < petertodd> heh, emphasis on some
11:56 < petertodd> might just be enough to have a nice website...
11:56 < BlueMatt> by off-chain, you do mean off-chain for a while, then sync up the difference in one txn?
11:57 < BlueMatt> oh, no I meant the crazy guys who offered money for split
11:57 < BlueMatt> A few devs have gotten donations from them
11:57 < BlueMatt> relatively sizeable ones
11:57 < petertodd> ah, ok, so they've shown they're for real
11:57 < petertodd> to some extent
11:57 < BlueMatt> if only they'd put up a big bounty on adding more test-cases
11:58 < petertodd> BlueMatt: not sure exactly what the off-chain gusy who have contacted me lately really mean, I'll find out more later
11:59 < petertodd> Indeed. You've done a lot of hard work, but there is so much more to do.
11:59 < BlueMatt> what Ive done hasnt even scratched the surface of the edge cases that exist, tbh
11:59 < BlueMatt> if you fail the tests-cases there, you really were oblivious when implementing
11:59 < BlueMatt> at least, fail more than a few-line fix
12:04 < petertodd> Absolutely. I found lots of stuff re: nLockTime that's not tested, just to name one example.
12:04 < BlueMatt> even coverage reports of the tests show suckage...
12:05 < petertodd> Well, foundation says they're going to hire two more tech staff.
12:06 < BlueMatt> good to hear, can we make one of them full-time test engineer?
12:06 < BlueMatt> s/one/two/
12:06 < sipa> peter vessenes asked me if i wanted to work on bitcoin full-time
12:06 < sipa> but i prefer not giving up my job now
12:06 < BlueMatt> if sipa wanted to work on bitcoin full-time there are around 10 companies that would make it happen...
12:07 < sipa> he was certainly not the first to ask :)
12:09 < midnightmagic> sigh. I have an account with exchangezone too.
12:09  * midnightmagic doesn't like being on lists.
12:09 < BlueMatt> midnightmagic: known terrorist
12:11 < petertodd> sipa: heh, I know the feeling, I even had my old boss from when I was 16 at a software summer job call me up asking if I wanted to start something bitcoin related
12:11 < sipa> heh
12:11 < sipa> now, if i could work more on bitcoin without giving up my job... that'd be nice :)
12:12 < BlueMatt> sipa: spend 10 years, invent a time machine and poof
12:12 < petertodd> sipa: make it your 20% project to do off-chain tx's, and confuse all of Mike's critics...
12:12 < sipa> abstruse goose 249?
12:13 < BlueMatt> sipa: yes
12:13 < BlueMatt> petertodd: doesnt mike already do bitcoinj as 20% time?
12:13 < petertodd> BlueMatt: what I would give to tell my 18 year old self... I was so excited when I found out about hashcash
12:13 < sipa> petertodd: i'm going to try to make getting aecp256k1 optimized in openssl my 20% project
12:13 < sipa> secp256k1
12:14 < BlueMatt> you want to merge something in openssl?
12:14 < petertodd> BlueMatt: exactly, so if sipa does something geared towards decentralization said critics will be rather confused about googles intentions
12:14 < BlueMatt> heh, good luck
12:14 < petertodd> sipa: seems reasonable to me
12:14 < BlueMatt> petertodd: Im not sure anyone reads bitcoinj development as google's intentions.....
12:15 < petertodd> BlueMatt: http://www.reddit.com/r/Bitcoin/comments/1e680k/maybe_this_is_why_google_pays_coredev_mike_hearn/
12:15 < petertodd> jdillon is a pseudo-troll of course
12:16 < BlueMatt> hah
12:16 < BlueMatt> well, people are stupid...
12:17 < petertodd> indeed, but equally I get attacked for my supposed motives too
12:18 < BlueMatt> well, ok, I stand corrected
12:18 < BlueMatt> s/anyone/anyone reasonable/
12:19 < petertodd> well, Mike and Gavin are included in those attacking me for my motives
12:19 < BlueMatt> I meant for reading google motives into mike's work
12:19 < BlueMatt> your motives arent clear anyway...
12:20 < BlueMatt> Ill attack you for your results though
12:20 < petertodd> Indeed, they aren't clear, but by that standard neither are Mike and Gavins, or Jeffs, or a zillon other people. Attack results and ideas, it's just nicer that way.
12:21 < petertodd> After getting $6k worth of mostly anonymous donations, I know full well that I'll probably never know the motivations of people making stuff happen. So talk about what they make happen.
12:21 < petertodd> Actually, $7.5k includng pre-video donations.
12:22 < BlueMatt> hint: no one cares about your donations
12:22 < petertodd> Good, they shouldn't.
12:22 < petertodd> But it's a great example of how knowing about the motivations behind something is often an exercise in futility.
12:23 < petertodd> *trying to know
12:23 < BlueMatt> its not always that hard...
12:24 < petertodd> Well, if you want to play that game, then guys like jdillon can have fun attacking Mike. It's just a matter of perspective.
12:25 < BlueMatt> either Im being clear as mud or your ignoring what Im saying (most likely the first, Im distracted) but I need to get back to being distracted (read: work)
12:25 < petertodd> heh, have fun
12:25 < BlueMatt> :)
12:26 < midnightmagic> I don't understand why people engage the trolls so much. Ignoring them doesn't make them stronger.
12:29 < midnightmagic> And I don't really mean the people who come in to -dev with a chip on their shoulder about something. Half the time they just think they can do something better. I mean the real destructive elements like the press page guys, or MP.
12:35 < jgarzik> It's a tough call
12:35 < jgarzik> Trolls rope innocent people into buying their line of B.S.
12:36 < jgarzik> When I respond, it's mainly to provide an alternative viewpoint, not directly respond to the troll.  But that gives the trolls gas for further trolling, so it's not a great solution.
12:40 < petertodd> Standard social theory would say that acknoledging trolls at all just gives them social status, which you really don't want to do, on the other hand people not familiar with the scene don't have any idea what the social status of anyone is, and they will read and misunderstand bad arguments.
12:40 < petertodd> So have someone else argue on your behalf.
12:42 < jgarzik> ;p
12:43 < petertodd> Similarly, why write software, when you can convince other people that the software should be written?
12:43 < BlueMatt> shell accounts?
12:43 < jgarzik> petertodd, That's what I do already :)
12:44 < petertodd> BlueMatt: Nah, that'd take up a pile of time. Better to convince a small group of your ideas and let it spread.
12:44 < jgarzik> petertodd, (1) write troll patch, (2) watch someone else come along and do it better, more completely
12:44 < jgarzik> c.f. wallet encryption
12:44 < jgarzik> the friendly term is being a catalyst
12:44 < petertodd> Lol, good job.
12:44 < BlueMatt> problem is, your troll patch had bugs that still appear in bitcoin today
12:45 < jgarzik> I declare myself blame-free :)
12:45  * BlueMatt can always fall back on the "I didnt merge it"
12:45 < petertodd> I managed to pull that off kinda with replace-by-fee, but the more complete version had O(n^2) scaling...
12:46 < jgarzik> Troll patches are famously employed by Linus Torvalds' #2 in Linux, Andrew Morton.  A mild-manner, Gavin-like guy for the most part.  But if an issue is sticking, he'll post a patch that solves the issue in an ugly way, "encouraging" people to do a better job than he.
12:47 < sipa> haha
12:47 < jgarzik> (it works because he merges tons of patches, has plenty of merge power)
12:47 < jgarzik> ultimately all changes are pulled by Linus, so no ACK/NAK consensus system in Linux.  It's either pulled by Linus, or not.
12:48 < petertodd> jgarzik: potentially bad incentives there re: busses
12:48 < petertodd> 12:47 < jgarzik> ultimately all changes are pulled by Linus, so no ACK/NAK consensus system in Linux.  It's either
12:48  * sipa wonders what a 'SYN' comment on a patch would mean
12:48 < BlueMatt> wait...we have a consensus system?
12:48 < petertodd> jgarzik: though I suspect Linux isn't *quite* as political as Bitcoin...
12:48 < BlueMatt> hah
12:48 < jgarzik> petertodd, You would be surprised!
12:48 < petertodd> sipa: It means the patch is ECN capable.
12:48 < jgarzik> petertodd, billion-dollar companies competing for your attention, where a patch merged might greatly benefit one business over another
12:49 < petertodd> jgarzik: I hear DRM has been an exception...
12:49 < jgarzik> petertodd, here in bitcoin, we "merely" have a handful of million dollar startups
12:49 < petertodd> jgarzik: True, lots of sunk engineering costs that managers don't want to change.
12:49 < sipa> BlueMatt: yes, it is "make someone with merge rights feel confortable enough he won't be drowned in alpaca piss by the other devs for merging something"
12:50 < jgarzik> pretty much
12:50 < BlueMatt> sipa: ok....I /guess/ that counts
12:50 < jgarzik> RE DRM… never a real problem for Linux.  Being open source, it's kinda pointless to create software that locks down data
12:50 < petertodd> jgarzik: So how often does a proposed patch lead to a 3 minute animated video done by some guy with an arts degree? :P
12:50 < jgarzik> The DRM problems were always with hardware gadgets, that need upper level Linux drivers
12:51 < petertodd> jgarzik: Well, I could see more remote attestation stuff being practical, if anthetical to open source.
12:51 < jgarzik> never with Linux kernel itself _serving_ / providing DRM protection
12:51 < jgarzik> petertodd, with a benevolent dictator, crowd pressure is less effective
12:52 < jgarzik> petertodd, that's sorta where the linux/bitcoin analogy breaks down
12:52 < petertodd> jgarzik: indeed, and Linux is not a global consensus system. Bitcoin isn't just a piece of software.
12:52 < sipa> so we need a benevolent dictator!
12:52 < sipa> yay decentralization!
12:52 < petertodd> sipa: sounds like an AI problem...
12:53 < jgarzik> we need The Daemon
12:53 < sipa> i propose a blockchain mechanism to achieve consensus about what decisions to take wrt project management
12:53 < petertodd> sipa: <shudder>
12:53 < sipa> perhaps a controversial opinion, but i'm not convinced that is necessarily contradictory
12:54 < sipa> i like to see bitcoin more as an experiment in building a decentralized system, rather than a (fully) decentralized system itself
12:54 < petertodd> The problem is any pure blockchain mechanism is really a miner vote.
12:54 < sipa> (of course, that part was a joke)
12:55 < petertodd> sipa: Reminds me, for keepbitcoinfree I've already proposed a -talk email list with whitelisting done by fidelity bonds.
12:55 < petertodd> sipa: good, but best that people reading IRC logs understand the problem
12:57 < petertodd> You see, the fidelity bonds thing sounds good, but the real advantage is you implement it with PGP, which means people are forced to use PGP to post, which inherently filters out so many crazies...
12:58 < sipa> it also filters out so many
12:58 < jgarzik> indeed :/
12:58 < petertodd> Yeah, it's a trade-off.
12:58 < sipa> (though the filtering percentage for crazies is likely higher)
12:58 < jgarzik> PGP key signing is geek wanking :)
12:58 < petertodd> I'm and jdillon am the only guys who regularly use PGP on the -dev email list.
12:58 < jgarzik> (though that means admitting I'm a wanker?)
12:59 < petertodd> jgarzik: but it feels so good!
12:59 < jgarzik> A real life fingerprint (mannerisms, coding style, coding smarts) is always more useful, more natural than PGP WoT
12:59  * sipa wonders if anyone will sign his keys based on his presentation slides
12:59  * jgarzik wonders if anybody validates the PGP signatures on bitcoin downloads
13:00  * sipa also wonders whether he should trust such a person to do good identify verification
13:00 < petertodd> jgarzik: Yes, but using PGP lets you establish a link to that link history of mannerisms and coding style.
13:00 < jgarzik> or if anybody checked my PGP sig, in my exmulti->bitpay PGP signed message to the -development ML
13:00 < sipa> jgarzik: i haven't
13:00 < petertodd> jgarzik: See, I would have, had I had a reason to trust your first PGP key... (other than the fact I timestamped it months ago)
13:01 < jgarzik> hehehe
13:01  * jgarzik needs to backup the BitPay keyring, speaking of
13:02 < petertodd> sipa: you haven't even signed my key, and I gave it to you personally :P
13:02 < petertodd> jgarzik: you're not using a hardware key?
13:03 < jgarzik> I like the idea (Adam's?) of having little pull-off paper strips, with the pgp fingerprint on it
13:03 < jgarzik> petertodd, hah, no
13:03 < sipa> petertodd: i haven't had access to my private key yet
13:03 < jgarzik> petertodd, my PGP usage merely gains me entrance into the technological priesthood
13:03 < sipa> petertodd: but i can't actually remember verifying your identity :)
13:04 < jgarzik> other that that it's a circle jerk ;p
13:04 < petertodd> jgarzik: I've got two types of hardware PGP keys, but in all honesty, gnupg smartcard support is a buggy pain in the ass.
13:04 < jgarzik> gnupg is a PITA
13:04 < petertodd> sipa: Do you think I'm Peter the crazy off-chain guy? Or was I too sane in person?
13:04 < sipa> petertodd: pretty sure you're the same guy, but what i think isn't relevant
13:04 < jgarzik> where is the easy-to-use PGP library?  Every single program that wants to use PGP must exec(2), it seems
13:04 < jgarzik> that's part of the problem
13:05 < sipa> jgarzik: you know why, right?
13:05 < petertodd> sipa: heh, see, I disagree with the government-issue ID business in that respect
13:05 < jgarzik> ditto Tor.  no "link this lib", but "run this proxy"
13:05 < jgarzik> sipa, there is an official reason?
13:05 < sipa> jgarzik: yes, mlock
13:05 < jgarzik> besides "RMS blessed this code" or NIH?
13:05 < petertodd> jgarzik: yes, all total BS. The python gpgme library is particularly embarassing.
13:05 < sipa> jgarzik: they mlock the entire process, because anything else isn't guaranteed afaik
13:06 < jgarzik> sipa, understandable… but mostly pointless IMO
13:06 < petertodd> sipa: yes, but that could be done far more sanely with fork followed by brk to reduce the memory footprint, and some pipes
13:07 < sipa> there are libraries that do that
13:07 < petertodd> sipa: instead you get libraries that literally run the gpg exec, and do crazy text grabbing
13:07 < petertodd> sipa: oh good, hopefully I just missed the saner ones, although last I needed it I was only looking at Python stuff
13:08 < jgarzik> yeah, it's awful
13:08 < sipa> petertodd: anyway, about identity checking: yes and no: imho, gpg identities should list (perhaps just in the form of a free-form text field) what authority the identity claims to provide the identity (not sure about terminology)
13:08 < petertodd> and it just gets worse if you try to integrate with a PGP hardware thingy (I briefly looked into it for timestamping, and gave up screaming)
13:09 < petertodd> sipa: Indeed. Where authority can be "Internet Reputation"
13:09 < sipa> petertodd: for example, i could have an identity that says "Bitcoin developer 'sipa'", without claiming anything about my real name
13:09 < petertodd> sipa: Heck, I signed jdillon's PGP key soley on the basis that I was one of the first people to talk to him in Bitcoin. (AFAIK)
13:09  * petertodd needs a keysigning policy, no wait, a life...
13:10 < sipa> or, the other extreme, i could have an identity that claims corresponding to the Belgian citizen registry entry named "Pieter A. S. Wuille"
13:11 < sipa> so you also know what to ask for to verify an identity
13:11 < petertodd> There's on and off discussion in gnupg-devel and openpgp mailing lists about that stuff actually - seems semi-consensus is it's just too complex for people to understand.
13:12 < sipa> it probably is
13:12 < jgarzik> That's what I want to do with a decentralized identity system.  Take a UUID and a database, and attach various signatures (your own, PGP, ECDSA, etc.) and various endorsements (signatures from third parties, be it personal ("sipa is a great guy") or identitybased ("sipa == Pieter Wuillle, national ID number 1234-5678") or reputation based ("sipa is a 5-star trader on MyEbayClone")
13:12 < jgarzik> Just need a protocol/data definition, and your decentralized identity can be as private or public as you like.
13:13 < sipa> but the problem is, many of the people who signed my GPG key (most was at a FOSDEM keysigning party with 100-200 people), did check my identity based on government-issued paper (and i'm sure they wouldn't have if i couldn't provide such paper)
13:13 < sipa> so they likely expect me to do the same sort of checking when signing other keys
13:13 < petertodd> sipa: indeed, I don't want to be mean, but jgarzik here is an excellent example: having a separate signing key in addition to your master signing key is a good thing, because it lets you limit the damage from a compromise. But seriously, understanding that crap is just not worth it.
13:14 < sipa> well, nobody understands GPG in the first place :p
13:14 < petertodd> sipa: OpenPGP actually does have some limited signing bits that you can use for that kind of thing. Poorly understood as you say.
13:14 < sipa> s/GPG/PGP/
13:15 < petertodd> sipa: Heck, jdillon signed my key back, and signed the photo packet... if he verified that, I have a stalker.
13:16 < petertodd> jgarzik: Sounds great, but how will you boil it down to something really simple for the algorithms? Do you think a key-value store is sufficient?
13:16 < jgarzik> petertodd, That's the tough part.  Where/how to store this decentralized identity database.
13:17 < jgarzik> petertodd, That's why I was looking into miner sacrifices
13:17 < jgarzik> If you associate a cost to identity creation, hopefully flooding is prevented
13:17 < petertodd> jgarzik: Yeah... too bad gmaxwells bytecoin doesn't exist.
13:17 < jgarzik> and if flooding is prevented, then it is likely easier to convince people to P2P-share the database
13:18 < jgarzik> a la blockchain
13:18 < petertodd> jgarzik: Of course, key-value in the blockchain has been suggested over and over, and aside from bloat it's a reasonable idea as all you need to know is that someone else can't claim they have the most recent pair.
13:19 < jgarzik> It would be nice if adding new merge-mined chains was easier
13:19 < petertodd> I dunno, I'm skeptical about merge-mining stuff like that, because the incentives to actually do it are weak.
13:20 < jgarzik> petertodd, miners and pools definitely respond to "easy additional income, for the same amount of work" incentives
13:20 < petertodd> I have the same problem distributing fraud-proofs for fidelity-bonded banks: you have to be able to prove that a fraud proof *wasn't* made in the past, and the only way to reasonably do that is have a data storage service with consensus on it's contents.
13:20 < jgarzik> yep :/
13:21 < petertodd> jgarzik: Which is the problem. The incentive can just as easily be "PGP-CA blockchain isn't used that much, lets kill it for the lulz"
13:21 < petertodd> jgarzik: It wouldn't be an issue, except for the fact that you need to be able to sell fidelity bonds if you've been honest to solve the "service own retiring" problem, and selling them is only reliable if you can be sure it's not a tainted identity.
13:21 < jgarzik> I really think this decentralized identity project could be huge, though.  Create an identity, create a market, trade, dispose of market.  Coalesce, exchange, disperse.  Automatic markets, anywhere, anytime.  The main linking factor is your identity.
13:22 < jgarzik> yeah
13:23 < petertodd> Possibly. I mean, the bigger question si what exactly is being bought and sold? Now digital goods are an option, but lots of classes of stuff really does need real-world identities.
13:23 < petertodd> for instance really general colored coins for real-life business stocks seems kinda crazy to me
13:23 < petertodd> (other than just an accounting system)
13:24 < jgarzik> If you have a SIN, you can collect endorsements (digital signatures) from third parties, proving your real world identity
13:25 < jgarzik> But each SIN holder chooses what endorsements to add, which to publish, which to keep private
13:25 < petertodd> Heh, get governments in on it and some of the endorsements can be pretty damn direct...
13:26 < jgarzik> Just need a central root point for each identity, to digital sign (for example) permission-to-see-my-identity
13:26 < jgarzik> indeed
13:26 < jgarzik> Just thinking about how to export it over the Internet, in a secure fashion
13:26 < jgarzik> Your SIN, your crypto-identity, should be able to securely link to other identity systems
13:27 < petertodd> Well, I mean if you can get a consensus on a big, timestamped, H(key)-H(value) table the actual transport can happen in a lot of ways - the receiver will always know they either got the true key-value by checking that H(key) H(value) matches.
13:28 < jgarzik> agreed
13:28 < petertodd> With that, transport on systems like DHT is a *lot* more acceptable.
13:28 < petertodd> It's too bad cryptographic accumulators don't quite work the way we want them too here...
13:29 < petertodd> Unfortunately I think you're basically forced into a blockchain here.
13:29 < petertodd> Albeit one that only needs 32+32=64 bytes per UTXO entry.
13:29 < petertodd> ...and what blocksize? (ducks)
13:29 < jgarzik> hehehe
13:30 < petertodd> Actually, seriously speaking, I'd namespace it to (semi)-solve that problem.
13:30 < jgarzik> petertodd, explain?  not sure what you mean
13:31 < petertodd> By namespace I just mean separate it into multiple blockchains, so that you can prune all but what you are actually interested in.
13:31 < jgarzik> ah, indeed
13:31 < petertodd> You still have to deal with bandwidth for all k-v pairs though, or you won't know if the POS's used to create them are valid.
13:32 < petertodd> (IE, that's the equivilant of an invalid block in the system)
13:32 < jgarzik> yep
13:32 < jgarzik> thus, The Difficult Part
13:32 < jgarzik> if it can be solved, decentralized identity Will Be Big
13:33 < jgarzik> PoS might also be needed/used for changing, not just identity creation
13:34 < petertodd> Well, do it hiarchical, with a top-most k/v store, with the k's being the state of the next level of k/v store.
13:34 < petertodd> See, basically you want to be sure you haven't missed any updates.
13:34 < petertodd> ...although, no, that still doesn't work, because of withholding attacks...
13:35 < petertodd> Yeah, I'd be inclined to do PoS for every update basically.
13:36 < petertodd> Oh, and here's another mental model: see what you have with this database, is the ultimate cryptographic accumulator that works the way you want it too: arbitrary checking if p in S
13:39 < petertodd> Your block header algorithm can actually be kinda interesting too... so you need to do on-chain Bitcoin POS transactions right? Make those transactions in a way that is distinguishable - IE you can tell if a given tx may have been part of the chain - and have your best block selection be the sum of all sacrifices.
13:40 < petertodd> Now if someone does a withholding attack, it's still ugly, but at least you can sacrifice more Bitcoins than the PoS's whose contents you *don't* know about and be sure your now on the best chain. Your incentive, assuming the system is used, is to then broadcast your data widely so others sacrifice on top of your sacrifices.
13:41 < petertodd> Basically the 51% attack is now sacrifice more Bitcoins than the sum of all Bitcoins sacrificed. Not great, but at least it's easily measurable security.
13:41 < petertodd> Does have ugly issues if Bitcoin's value crashes...
13:42 < petertodd> But maybe that doesn't really matter, the Bitcoin PoW would be vulnerable anyway.
13:44 < petertodd> This whole scheme does depend on independent miners: the fact you're "mining" this blockchain is easily visible by the fixed namespace ID's. You may find a 51% majority conspiring to block your foo-k/v namespace for whatever reason.
13:45 < amiller> for the PoS thing you're talking about, the way to solve my objection with it (that there's nothing at stake) is to make it so the sacrifice is a sacrifice even if the block containing the sacrifice isn't selected
13:45 < amiller> if you do work on a PoW fork attack, your work is wasted if you fail
13:46 < amiller> meaning if your attack fork doesn't end up being taken as the main chain
13:46 < jgarzik> petertodd, yeah, if bitcoin dies we're fucked anyway ;p
13:46 < petertodd> amiller: Absolutely. It *must* be a genuine Bitcoin sacrifice, like an announce/commit sacrifice or anyone-can-spend coinbase output.
13:46 < amiller> so maybe you could fix that by saying that your best selection is the sum of all sacrifices, such that the transaction sacrifices are valid on every chain even the ones you didn't select?
13:46 < jgarzik> petertodd, BTW, what is the current favorite anyone-can-spend?
13:46 < amiller> ok sure anyone-can-spend coinbase
13:46 < jgarzik> OP_TRUE or somesuch
13:47 < petertodd> jgarzik: anyone can spend coinbase is shortest, for general use w/o miner help I haven't come up with anything better than announce/commit
13:47 < petertodd> amiller: ooh, that's a very good idea
13:48 < jgarzik> amiller, interesting
13:48 < jgarzik> a bit of a variant on total work
13:48 < petertodd> amiller: and your "block headers" are very similar to what merge-mined alt-coins carry around anyway
13:51 < petertodd> oh, and with anyone-can-spend coinbase output, the priority block # is obviously just the block #, however with announce-commit that's trickier
13:52 < jgarzik> I need to collect this into a wiki page somewhere
13:52 < petertodd> well, actually, maybe it doesn't matter... priority is independent per k-v pair, so if your announce commit means some of your k-v block was invalidated by a later update, it doesn't matter that much
13:53  * jgarzik wishes there was a crypto-wiki, rather than stuffing everything on en.bitcoin.it.  I suppose a github .md or gist will suffice.
13:53 < jgarzik> There definitely needs to be very high priority k-v's, and then secondary ones.  the primary, high prio ones are the root for other attestations/proofs/signatures
13:53 < petertodd> also, before I forget, actually pure k-v isn't really enough for most things, you probably need signatures so that once you establish that you own a k-v pair, you can update it with a signed update
13:53 < warren> Wow.  BFL sent me a refund after 1 day.
13:54 < jgarzik> Tempting to say that ultra-high-prio ones simply cannot be changed.  Create an identity with a certain number of immutable k-v's.
13:54 < petertodd> and on top of this, so don't forget you can use a merkle sum tree with your k-v pairs if you want a system where each pair has an individual sacrifice amount
13:55 < jgarzik> Some services, I imagine, would want that.  A third party service might require a specific sacrifice, or real world protocol of some sort.
13:56 < petertodd> Yeah, for for domain names, a perpetual auction may be acceptable, or an auction that goes into effect every n blocks.
13:56 < petertodd> I doubt people would like that domain name system, but it's an option...
13:57 < petertodd> For PGP->email CA's, full email addresses don't get reused all that often really.
14:02 < petertodd> Oh, mind, for a PGP CA, you do need to handle key updates. So immutable sitll isn't great.
14:03 < jgarzik> yeah
14:04 < jgarzik> Trying to think through balancing the value of immutable (cannot be attacked via change) versus the real world need to expire master keys
14:04 < jgarzik> If there is a lesson to be learned from security in the past 10 years, it's that keys (and the passphrases protecting them) are inevitably vulnerable via human/human attacks like social engineering, poor passwords, ...
14:04 < petertodd> Well, the mutability rule can be just "there must exist an unbroken chain of keys signing keys"
14:05 < jgarzik> humans suck at password and key management
14:05 < jgarzik> agree
14:05 < petertodd> Proof size should be reasonable in the real world.
14:06 < petertodd> One issue here, is what's the equivilant of a UTXO proof? Maybe a merkle mountain range of every value ever associated with a given key?
14:08 < jgarzik> heh, merkle mountain range
14:08 < petertodd> The merkle-mountain range is prunable, and the incentive to get it right is that others will see you screwed it up, and won't build upon your sacrifices.
14:08 < petertodd> jgarzik: do you know the explanation for the name?
14:08 < jgarzik> no, but I can guess
14:08 < amiller> in the most general setting it's called a verification object (VO)
14:08 < jgarzik> tree of trees?
14:09 < petertodd> jgarzik: https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md
14:09 < petertodd> Pretty similar to a merkle-skip-list, but it has an unusually simple visual image to expalin it.
14:10 < petertodd> ...and my dad thought the name was hilarious.
14:12 < jgarzik> hmmmm.  Can the identity chain be purely PoS-based, ditching PoW completely?  Not sure.
14:12 < jgarzik> PoS ties you to the bitcoin chain, but loosely
14:13 < petertodd> Well, PoS does always make it possible for a wealthy attacker to attack your chain, but on the other hand, that's really true of PoW too.
14:13 < petertodd> At least PoW makes figuring out how much money they'll have to spend really easy.
14:14 < petertodd> The real problem is what's the incentive to pay enough for the PoS chain, other than "shit, an attacker attacked us, lets go outspend them and and put the chain back!"
14:14 < jgarzik> yeah
14:15  * sipa somehow always reads PoS as 'piece of shit', instead of the (slightly) more common interpretations in the Bitcoin world (including point of sale)
14:15 < jgarzik> PoSa
14:15 < jgarzik> distinguishes between proof of stake and proof of sacrifice
14:15 < petertodd> For low interest chains, your PoS for a block would converge to the fees required to get the root bit of data into the bitcoin blockchain.
14:15 < jgarzik> and point of sale
14:16 < jgarzik> petertodd, true
14:16 < sipa> PrOSt, PrOSa, PoOS
14:16 < petertodd> we should call proof-of-stake PoT in reference to what the creaters of proof-of-stake systems usually seem to be smoking
14:16 < jgarzik> hah
14:17 < petertodd> also, keep in mind that not unlike Bitcoin, with any k-v system where updates are signed, the attacker has to rewrite the whole chain all the way back to the initial insertion
14:18 < petertodd> and there's nothing stopping you from using manual checkpoints, as ugly as that is
14:18 < jgarzik> most chains bootstrap into existence using this ugly solution
14:18 < jgarzik> including bitcoin ;p
14:18 < petertodd> indeed
14:20 < petertodd> also with signatures on updates, the chain *can* be a dag structure, with conflict resolution being done via highest total PoS
14:20 < petertodd> it's totally ok to "mine" a block with some secret k/v setting, and reveal it much later provided that there aren't conflicts
14:22 < petertodd> re: namespaces, note how the tradeoffs are kinda weird here, bigger blocks are definitely better up to the decentralization limit, because they allow as many parties as possible to share one PoS
14:22 < jgarzik> nod.  Some k-v will definitely be private, to be revealed only to chosen parties
14:23 < jgarzik> e.g. you might not publish your real name and government attestation, but you would give permission to give out that info to certain parties.
14:24 < jgarzik> Get to a point where you, A, reveals info to party B.  party B keeps that info private, but publicly attests to fact F
14:24 < jgarzik> then another party C can see F from B
14:24 < petertodd> yup, and it works at both the value level, and the block level
14:27 < petertodd> brb
14:27 < jgarzik> In the KYC context, you can remain private, but have a trusted firm digitally attest to your lack of criminality:  Alice receives a signature from Identity Checking Inc., after undergoing full identity exam including rectal check.  Alice only needs the sig, to prove she went through KYC.
14:28 < jgarzik> The KYC check is as valuable (or useless) as Identity Checking Inc.'s services and reputation, and private details need never be revealed.
14:28 < jgarzik> This certainly exists today… but in a centralized fashion, with massive redundancy (everybody checks government ID etc., everybody runs background checks, etc.)
14:48 < petertodd> The debugging tools for analog electronics have such terrible UI's...
14:49 < petertodd> Hmm... so with KYC though, exactly how does the k-v consensus actually help us?
14:49 < petertodd> There's no zooko's triangle involved, well, there is, but you have trusted Identity Checking Inc.
14:54 < jgarzik> petertodd, That's all an attestation really is…  Bob trusts Identity Checking Inc. attestation of Alice (or not).
14:57 < jgarzik> petertodd, in theory you don't strictly _need_ a unified view of this global database; it's more for convenience.  Two parties just need sufficient amounts of data from each other, just like PGP WoT today.  The idea with decentralized identity is to generalize that and make it easier (+ attaching a cost)
14:57 < jgarzik> a chain would be very helpful in solving several problems though
14:57 < petertodd> Exactly, this whole system is rather complex... although it'd be useful for so much stuff.
14:58 < petertodd> A chain is required to be sure you have a recent copy of, say, revocation certs.
14:58 < jgarzik> yes
14:58 < petertodd> Not unlike the fidelity-bonded-banks problem actually...
15:01 < petertodd> Here's another thought: what's we've created here is more general than k-v store, it's basically a general purpose PoS-mined alt-chain system.
15:02 < petertodd> However, the problem is the PoS algorithm I've described isn't all that useful for alt-chains representing monetary value.
15:04 < jgarzik> as discussed, data chains are quite useful for several things
15:04 < petertodd> Yeah, see, what I'm curious about is are there cases where they are useful for "transactional" data, IE not the k-v model?
15:05 < petertodd> (although, I guess you could say a transaction *is* a k-v pair with a height)
15:05 < petertodd> (and k=H(v))
15:05 < jgarzik> either way, with zero trust you gotta prove history from genesis to present, transactional or not
15:05 < petertodd> yup, at best you namespace it
15:06 < petertodd> ok, so with a merkle mountain range k-v history proof for every k-v pair, you don't actually need to validate anything *about* the k-v pairs, you are just proving that they existed
15:07 < petertodd> so that the "SPV" client equivalent can know if they've seen full history since the genesis block
15:07 < petertodd> *maybe* add a really general purpose signature for subsequent updates mechanism, where the pubkey is uncensorable
15:08 < petertodd> for any given k, first occurance is that k's "genesis block" so to speak, and subsequent are validated by the sigs
15:08 < petertodd> no sig == junk, and not in the mmrange k-v history
15:09 < jgarzik> hmmmmm
15:09 < petertodd> (add in expiry etc. as required to keep proof size reasonable)
15:10 < petertodd> Oh, actually... so the signature just has to sign the mmrange of the key!
15:12 < petertodd> So you can prune everything but the first occurance... still need to figure out expiry though, because after the fact it looks like the key never existed if pruning is used... maybe some kind of interval thing.
15:13 < petertodd> Bigger issue: what exactly are the incentives for doing k-v history proofs anyway? How do full-nodes and SPV nodes interrelate? why would you run a full-node anwyay?
15:13 < petertodd> If there aren't any notion of SPV, the whole thing becomes way easier.
15:13 < petertodd> s/aren't/isn't/
15:15 < petertodd> semi-related: amiller's concept that losing PoS markers contribute to total PoS doesn't work, because how exactly do you decide who lost?
15:16 < jgarzik> Indeed.  The incentives for running a node are possibly lower, residing mainly at identity attestation firms, auction market providers, and other businesses that need identity
15:16 < jgarzik> *possibly lower for the average user, I mean
15:17 < petertodd> also, PoS sum should somehow take block size into account, so if my data is large I lose out to a small block with the same sacrifice amount
15:17 < jgarzik> agreed
15:17 < petertodd> Yeah, like Bitcoin, is running nodes is cheap, people will do it anyway, but resources are limited and demand is infinite.
15:17 < jgarzik> provides incentive for efficiency
15:19 < petertodd> value/size is probably fine... but just like Bitcoin, consensus and decentralization demands limits on size
15:21 < jgarzik> As soon as v0.1 of this identity system exists, people will complain that it does not immediately support all ~7 billion people on Earth
15:21 < jgarzik> (the identity version of "scale up Bitcoin to Visa/MC levels RIGHT NOW NOW NOW")
15:21 < jgarzik> "how dare you limit our identity block size"
15:21 < petertodd> absolutely, although at least the scaling limits are about bulk bandwith, rather than the blockchain's race issue
15:21 < petertodd> and consensus can take longer
15:23 < jgarzik> For most identity users, I imagine the _personal_ volume of changes would be rather low.  You create an identity, maybe have IC Inc. verify your real world id and provide an attestation, then the record sits unchanged for months or years.
15:24 < petertodd> Yeah, the PGP strong set is only 50k, and all the keys on the key servers are just a few GB worth.
15:24 < petertodd> 240 million domain names in total
15:28 < petertodd> re: creating blocks, but not revealing them until later, an interesting trap is that the naive way of doing that means that the worst case PoS is the sum of all unrevealed blocks
15:28 < petertodd> so part of the PoS should include what previous PoS it builds upon
15:29 < petertodd> though that can actually replace the namespace hash, so the in-btc-blockchain data doesn't increase
15:31 < jgarzik> interesting metric, total-PoS
15:31 < jgarzik> I still wish there was an efficient "burn money" standard bitcoin transaction, e.g. zero outputs.
15:32 < petertodd> yeah, because you want to be sure no unrevealed chain could supercede your k-v's
15:33 < petertodd> jgarzik: well, we need to do OP_RETURN <prev-pos-tx:n> <block hash> anyway, so zero outputs doesn't help directly 
15:33 < jgarzik> true
15:33 < jgarzik> alas, either are non-standard (if not invalid, like zero output)
15:34 < petertodd> however an output that is guaranteed to be spendable only after n blocks would be perfect, right now all we have is the coinbase
15:34  * jgarzik ponders PoW + PoS
15:34 < petertodd> I'm really inclined to support OP_RETURN {anything you want} to be honest
15:34 < jgarzik> small PoW, mainly PoS
15:34 < petertodd> once pruning is implemented
15:35 < petertodd> I dunno, given that the PoS is denominated in Bitcoins, I'm unconvinced there really is much value, the Bitcoins can just as easily buy mining time
15:35 < jgarzik> petertodd, That's the current IRC rough-consensus proposal for shipping small bits of data, OP_RETURN output, one per transaction.
15:35  * jgarzik should make the requisite patch, just to have it ready
15:35 < petertodd> I know, but notice how we already came up with an example that absolutely needs two hashes to work?
15:35 < jgarzik> :)
15:36 < petertodd> and actually, in this case, what we really need is scriptPubKey <prev-pos-tx:n> <block hash> OP_TRUE, because that saves one useless output - it's a sacrifice anyway
15:36 < petertodd> (optionally, drop the OP_TRUE, but I like making the standard mandate it so it's less likely to be generated by mistake)
15:38 < petertodd> also, in general two hashes basically let you do an alternate UTXO set for your application, subject to different pruning rules, not unlike what we're doing now
15:39 < jgarzik> Choosing the amount of sacrifice is another annoyance.  Starting out, might just pick an arbitrary value like 0.000075 ($0.01)
15:39 < jgarzik> Need to figure out a self-balancing metric
15:40 < jgarzik> Not too big to scare away users, not too small to enable spam
15:41 < petertodd> But, see this is the thing, unlike in Bitcoin provided you are willing to monitor the chain, you *can* do an adaptive sacrifice based on actual attacks.
15:41 < petertodd> Especially if you set a probationary period of n blocks before a given k-v setting (via the consensus) comes into affect
15:42 < petertodd> Basically pick how much time you think your counter-attack will take to implement.
15:43 < jgarzik> indeed
15:47 < petertodd> Oh, and come to think of it the k-v history proof isn't a problem after all: since every block hash is a merkle tree of the k-v set, that hash can simply include the hash of the mmrange accumulator tip, if the k-v isn't changed, just re-use the old value, if it is changed, provide the delta to prove why.
15:47 < petertodd> For the SPV node, provide the full history from the genesis of the key, and one step back to prove the key *didn't* exist prior, along with the appropriate history.
15:48 < petertodd> Now the rules for making a block are always that the delta must make sense, regardless of how small a change you make.
15:49 < petertodd> So finally, how does a SPV client make a change? They ask a full node for the correct merkle paths, and check that their k-v makes sense and leads to a long sacrifice chain.
15:49 < petertodd> *sacrifice dag
15:50 < petertodd> The sacrifice dag will be more bulky than a blockchain, but making that the minimum resource size is acceptable, especially with some manual checkpoints.
15:50 < petertodd> *than blockchain headers
15:50 < jgarzik> just don't want to depend on checkpoints ad infinitum
15:51 < petertodd> Indeed, a full node doesn't have to, and a SPV node that is willing to bootstrap from genesis doesn't have to either: they just need to ask for proof that the keys they are interested in *didn't* exist in the blocks going back to genesis.
15:52 < jgarzik> about to disappear for several hours… saving this chat to a log ;p
15:53 < petertodd> So basically, I know that zero-trust full nodes are possible, and I think zero-trust SPV nodes are also possible, although I have to think some more about motivations.
15:53 < petertodd> Ha, same
15:53  * petertodd archives irclogs forever on amazon glacier...
15:53 < petertodd> lol, I'll timestamp this one for patent priority :P
15:53 < petertodd> dammit, why do I have to have a day job...
15:54 < jgarzik> bah :)
15:54 < jgarzik> evil patents
15:54 < petertodd> right, but see, this is a public forum, so all the priority can do is defend against a patent
15:55  * jgarzik should check out Glacier
15:55 < petertodd> $0.01/GB*month is amazing
15:55 < petertodd> I use it with git annex
15:55 < petertodd> a few hundred GB stored, and git annex can do encryption too
18:14 < gmaxwell> I guess we can all go home now: http://arxiv.org/pdf/1305.5976v1.pdf
18:16 < realazthat> oh I think I saw a video by that guy a while back
18:17 < realazthat> I remember the data structure
18:17 < realazthat> mmm get that onto the pvsnp page
18:20 < realazthat> mmm
18:20 < realazthat> gmaxwell: I actually have a hobby to try and run the algorithms from the pvsnp page
18:20 < realazthat> so wrt hamiltonian cycles, random testing doesn't cut it
18:21 < realazthat> but I have the infrastructure setup to go FACT=>SAT=>HAMCYCLE
18:21 < gmaxwell> somewhere on his blog he says that someone has a reduction from SAT to his MSP thing directly
18:21 < gmaxwell> and there is lots of stuff to reduce $randomthings to SAT.
18:21 < realazthat> yes
18:21 < realazthat> but plain random SAT isn't good either
18:21 < realazthat> it can be solved in polytime by well known algos with very high probability
18:22 < realazthat> FACT=>SAT makes for very useful benchmark
18:22 < realazthat> because if you can solve that ...
18:22 < realazthat> then you break RSA
18:22 < realazthat> mmm I'll look into it
18:22 < realazthat> maybe I'll implement it, and email the guy with a counter example :D
18:23 < realazthat> he seemed very sincere in the vid I watched a long time ago
18:23 < realazthat> so I sorta feel bad
18:24 < gmaxwell> realazthat: if you do happen to find that it solves RSA,  I recommend factoring the RSA challenge 4kbit number, then making an gpg key out of it, and then posting to sci-crypt a signed message:  "You should stop using RSA" and see if anyone notices. :P
18:25 < realazthat> haha
18:25 < realazthat> that would be the day
18:26 < realazthat> even if it would solve it, it would take forever
18:26 < realazthat> I think I saw O(n^5)s being thrown around
18:26 < realazthat> in that pdf
18:26 < realazthat> from experience, its hard(er) to find counter examples to algorithms that run so long :D
23:50 < realazthat> omg I want that SCIP
23:50 < realazthat> so many possibilities
--- Log closed Thu May 30 00:00:47 2013