--- Log opened Tue Jan 07 00:00:00 2014
--- Day changed Tue Jan 07 2014
00:00 < wyager> There is no proof that finding primes is particularly difficult
00:00 < wyager> but I suppose the same is true about the discrete log problem haha
00:00 < wyager> Namecoin is actually useful
00:00 < gmaxwell> primecoin is pretty uninteresting, its not a problem anyone cared about before.
00:01 < gmaxwell> Namecoin might be interesting but it's mostly abandoned and has some serious problems.
00:01 < wyager> Yeah, sadly
00:01 < wyager> I think the tech could seriously replace DNS
00:01 < wyager> Scaling might be a bit of an issue, but maybe not
00:02 < gmaxwell> basically nothing else has done much of anything. peercoin and feather coin have solved their consensus problems (in one case PoS doesn't really work, in the other because their blocks are too fast) with developer controlled selection on the best chain.
00:02 < Luke-Jr> something similar to namecoin could..
00:02 < gmaxwell> wyager: you can't do a secure lite client resolver for namecoin with the current design. it can be done, but namecoin doesn't do it.
00:02 < wyager> SPV?
00:02 < gmaxwell> I'd suggested how back in 2011, but by then namecoin development was mostly dead.
00:02 < wyager> Or SNV, rather
00:02 < gmaxwell> wyager: can't work in the current system.
00:03 < wyager> Really? Why's that?
00:03 < gmaxwell> (vulnerable to replay of old records)
00:03 < wyager> Don't records expire?
00:03 < wyager> Ah
00:03 < wyager> I see
00:03 < wyager> records can be updated before expiration
00:03 < gmaxwell> easily enough fixed: https://bitcointalk.org/index.php?topic=21995.0
00:03 < gmaxwell> and the record expiration is rather long.
00:04 < wyager> clever
00:05 < gmaxwell> state proofs have a lot of other advantages, e.g. like being able to prove to a lite node that a block is invalid.
00:06 < gmaxwell> in any case, I have an old (and lost past due for updates) list of alt ideas I think are interesting: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas
00:09 < wyager> hahahaha
00:09 < wyager> I love the timelock chain idea
00:09 < wyager> that would provide a very useful public service
00:10 < wyager> Do you sit around all day and think of clever crypto ideas? It seems like it would be a nice hobby :p
00:11 < gmaxwell> wyager: I mean, it's taken years to produce these.
00:11 < gmaxwell> actually I have a ton more of them that aren't there.
00:11 < wyager> Yeah, but a lot of these are great
00:11 < wyager> People have built entire altcoins on less
00:11 < gmaxwell> correction: no altcoin has ever been built on anything as cool as anything on that list. (except maybe merged mining in namecoin) :P
00:12 < wyager> hehe
00:12 < gmaxwell> well okay, peercoin's PoS was the same scale of an idea, but it doesn't really work— but perhaps some of those ideas won't work either (well, almost certantly some won't work)
00:13 < wyager> What is wrong with PoS? I haven't actually researched any criticisms of Peercoin
00:13 < wyager> But PoS seemed OK
00:13 < gmaxwell> yea, I think the timelock is sexy. I came up with it midsentence while I was telling someone that timelock appears impossible. :P
00:13 < gmaxwell> wyager: the nothing at stake problem.
00:13 < justanotheruser> gmaxwell: What do you think of nxt's PoS? nxt doesn't have checkpointing.
00:13 < wyager> Which is? Aren't you giving up scare coin-days?
00:13 < wyager> *scarce
00:13 < gmaxwell> justanotheruser: lollollol
00:14 < justanotheruser> gmaxwell: I realize it is 100% premined which is why I specified their PoS
00:14 < gmaxwell> Basically in POW you're incentivzed to mine on the ONE TRUE most likely to ultimately survive chain— because they're burning a costly resource forever every attempt they make, and their only compensation is getting a block in that one true chain.
00:15 < gmaxwell> The nothing at stake problem is that since you don't really burn anything there isn't any reason not to mine many forks— in fact its the rational optimal strategy to mine all forks you don't hate.
00:15 < wyager> I see
00:15 < wyager> don't they waste compute power as well though?
00:15 < wyager> by mining on every random ass chain
00:15 < justanotheruser> gmaxwell: To fork PoS you wouldn't have to expend additional resourced, but you would still need more PoS "mining" power than the main chain.
00:15 < gmaxwell> Including all possible hypothetical forks. There was a neet attack once PPC started pos mining: someone programmed their system to consider all possible forks to find the ones where their stake was selected over and over again as the block winner.
00:16 < gmaxwell> wyager: yes and at the limit it just becomes POW in disguise when that happens.
00:16 < Taek42> that's a pretty cool attack
00:17 < gmaxwell> PPC "fixed" that bug by forever requiring POW blocks, and setting it up so the identity of the stake depended on nothing after the last POW block.. which makes the specific all-blocks-are-mine attack harder (requires some POW power), but kinda breaks the energy argument and still leaves weird incentives to mine forks.
00:17 < gmaxwell> justanotheruser: Oh is nxt's fork out? I'll tell you what lines of code to change so you can mine all the blocks.
00:23 < Taek42> I had an idea, 'Proof-of-Storage'
00:23 < wyager> I also like merkelized AST P2SH
00:23 < gmaxwell> wyager: I really wish I knew a way to make POS work, but the best I can offer is if you have one cryptocurrency you could mine another by moving/destroying/etc coins in the first.
00:23 < wyager> Oh, and gmaxwell, my IRC client crashed so I may have missed a few things you said
00:24 < gmaxwell> Taek42: do you mean something like https://bitcointalk.org/index.php?topic=310323.0
00:24 < Taek42> not quite
00:25 < Taek42> the idea is that nodes contribute storage to the network, that can then be sold over the same network
00:25 < Taek42> like distributed cloud storage
00:25 < Taek42> where being a storage host gives you coin mining
00:26 < gmaxwell> Taek42: yea, I don't know how to do that except via proof of throughput which may not be what you want.
00:26 < wyager> Didn't cryptosphere or something try to do something like this?
00:26 < gmaxwell> And I've thought long and hard about how to actually do that.
00:26 < Taek42> where I'm currently stuck is the blockchain
00:26 < gmaxwell> the problem is that if you prove you have storage via a fiat-shamir of a cut and choose over it, you can just POW grind the proof to hit a fraction of the data you've kept.
00:27 < gmaxwell> ... and worse, its delegatable.
00:27 < Taek42> delegatable?
00:27 < gmaxwell> e.g. a pool can keep the data, and answer queries for other miners.
00:27 < gmaxwell> so you'd only get one copy of the data, which wasn't your goal.
00:28 < Taek42> ah yes, we did think of a solution to that
00:28 < Taek42> a partial solution, that is
00:29 < wyager> gmaxwell: What if you did something like this: You only want to verify that the other guy is keeping a backup (you also have a copy), so you make him XOR the data he's supposed to be keeping with the output of a stream PRNG (you do this as well) and then make him give you the hash of this data. You can't spoof this without actually having a copy of the data. That would work for distributed backup systems, at least.
00:29 < Taek42> the goal would be perfectly distributed data with a tunable redundancy such that nodes go offline over a perfect random distribution.
00:30 < Taek42> anytime nodes go offline in some fashion that doesn't follow a perfect random distribution, you assume they are somehow correlated
00:30 < gmaxwell> wyager: but who are "you".. distributed system, right?
00:31 < wyager> Alice wants Bob to keep a backup of her super important file. To make sure Bob doesn't delete his copy and say he still has it, Alice makes Bob modify the file and hash it. Alice does the same on her end, and if Bob can't produce the correct hash, he no longer has the file
00:31 < wyager> So it's not the same thing as distributed storage
00:31 < wyager> it's just distributed backup
00:31 < gmaxwell> wyager: thats really inefficient too.
00:31 < Taek42> (maybe they were all sharing a file - so they were pretending to be redundant but they weren't, or maybe they were all in Afghanistan and then Afghanistan decided to remove itself from the internet the way (Iran?) did - either way they were correlated in some way, which is against the goals of the network)
00:32 < wyager> Meh
00:32 < gmaxwell> wyager: e.g. forget the stream cipher whatever. Just challenge bob to provide a couple blocks at random from the file.
00:32 < wyager> Yeah, true
00:32 < gmaxwell> (or, if you want, the hash of a couple blocks at random)
00:33 < gmaxwell> wyager: a point there is that no matter which of those you do, bob can turn around to proxy the requests to mallory. Mallory has the data and answers.
00:33 < gmaxwell> wyager: if you had ten bobs you wanted to store the data, perhaps they're all just proxying through to mallory.
00:34 < Taek42> so when multiple nodes go offline in a correlated way, you punish them for 'false redundancy'.
00:34 < wyager> Unless Alice sends copied encrypted with a different key to all people
00:34 < wyager> Then at least she knows that Mallory must be using space to store the file
00:34 < gmaxwell> Taek42: how can you make a consistent observation of "offline" in a decenteralized system?
00:34 < Luke-Jr> ^
00:35 < gmaxwell> Or is your system merely distributed and not anonymous?
00:35 < wyager> And Bob has to pay Mallory anyway, so he's probably keeping it on his own unless the cost savings Mallory offers are worth more than his reputation if he gets discovered
00:35 < Taek42> they don't participate in N consecutive blocks
00:35 < gmaxwell> wyager: yea sure, though that gives alice n-fold communications cost.
00:35 < Taek42> wyager you can do better:
00:36 < Taek42> use something like LT-Codes or Reed-Solomon codes to produce the file
00:36 < wyager> Bitmessage ping?
00:36 < wyager> Or something?
00:36 < Taek42> each person gets a piece, redundancy is N
00:36 < Taek42> then select a random piece of the file to test
00:36 < Taek42> everybody produces that piece
00:37 < Taek42> and if you can use the LT-Codes to resolve it, you know they have the actual file
00:37 < Taek42> if you are worried about somebody waiting, you have them produce a hash first
00:37 < Taek42> but this solution is still delagatable
00:38 < gmaxwell> yea, (you'll note the thing I linked to isn't... but at a cost of not actually being able to store anything. :P )
00:39 < gmaxwell> hm. I guess encrypting can solve that.
00:39 < Taek42> I'm pretty sure that if you want to store actual data AND have a redundancy, hosts will be able to delegate.
00:39 < Taek42> encryption could solve that?
00:39 < gmaxwell> Taek42: you really want to code it using a locally decidable code.
00:40  * andytoshi-logbot is logging
00:40 < gmaxwell> Taek42: you code your data with a locally decidable code, and then encrypt the codewords. then you issue the codewords to peers.
00:40 < gmaxwell> the peers cannot recover your data because its encrypted.
00:40 < gmaxwell> you can test small fractions of the data by requesting and decrypting and then using the local codeword test.
00:41 < gmaxwell> (I guess the term is actually "locally testable code")
00:42 < Taek42> so the sacrifice would be that you are the only one who is able to repair the file if nodes go offline
00:42 < Taek42> as opposed to the network self-repairing
00:43 < gmaxwell> Yes. though you could have two levels of redundancy which enabled that.
00:43 < gmaxwell> e.g. for the network self-repair you don't need as much correction because the network will respond fast.
00:45 < Taek42> I think though any time you have a self-repairing network, a large set of collaborating nodes could cheat on the redundancy
00:45 < Taek42> which you would block through penalties for correlated downtime
00:46 < gmaxwell> I still don't see how you hope to achieve that, but I'm not that curious. :)
00:46 < Taek42> hmm
00:48 < Taek42> would you consider it mandatory to a cryptocurrency that when you receive a transaction, you don't need to vest trust in some subset of the network?
00:48 < Taek42> because I've been thinking about building a distributed block chain
00:48 < gmaxwell> you mean trust in Igor and hist 999,999 botnet nodes?
00:48 < wyager> lol
00:48 < Taek42> no
00:49 < Taek42> it would be a randomly sampled subset based on how much work they are contributing
00:49 < gmaxwell> 1,111,111 nodes?
00:50 < wyager> If they don't make more money contributing hashing power to the network than they would contributing hashing power against the network, they can't be trusted
00:50 < Taek42> so Igor would need to control a large % of the work on the network (51% is reasonable) as opposed to merely needing a sufficient quantity of nodes
00:50 < wyager> Which is why we pay people who make the blockchain
00:50 < Taek42> wyager I'm pretty sure you could build it such that you always make the most money contributing towards the network as opposed to against it
00:52 < gmaxwell> it's actually pretty easy to break that.
00:53 < gmaxwell> in any case, as I said in bitcoin we trust to trust the absolute minimum possible, and even then we are not sure the system will survive.
00:53 < gmaxwell> many altcoins have been destroyed by attacks by miners.
00:59 < Taek42> hmm
00:59 < Taek42> also, is bytecoin still actively developed?
00:59 < Luke-Jr> scamcoins are almost never actively developed at any point..
01:01 < Taek42> would it be bad form to steal their name?
01:02 < Luke-Jr> it would be bad form to steal ByteCoin-the-person's name again.
01:03 < Luke-Jr> imo
01:03 < Taek42> oh is he a person too?
01:04 < gmaxwell> yea, bytecoin is a cryptographer who was very active in bitcoin's early days.
01:05 < Luke-Jr> note: no relation to the scamcoin
14:51 < fagmuffinz_> justanother
14:52 < fagmuffinz_> What's up
14:52 < justanotheruser> fagmuffinz_: hi
14:53 < justanotheruser> You should change you're name. I think it's borderline banning territory
14:54 < fagmuffinz_> I would hope the nature of movements like this would line up with free speech well enough to overlook something trivial enough like a name
14:54 < fagmuffinz_> A name is a handle - nothing more.  You can identify me, and you can identify that I prefer to remain pseudonymous
14:55 < justanotheruser> I wouldn't ban you for it, but free speech doesn't prevent you from getting kicked for having an inflammatory name, it just prevents you from being arrested for having one.
14:55 < fagmuffinz_> Also, who doesn't like muffins?
14:56 < fagmuffinz_> On a more serious note - I meant to get back to you on your decentralized voting scheme, but I've been traveling
14:57 < gmaxwell> (FWIW, a different name would probably be preferable, I had the same initial response... but you were saying thoughtful things, so I didn't bring it up. :) )
14:58 < fagmuffinz_> Have you made any progress on it, or are you still where you were ~2 weeks ago?
14:59 < justanotheruser> fagmuffinz_: I was just asking if the system would work. I think jamming may be able to be prevented by requiring a certain number of transactions per block.
15:00 < justanotheruser> And a "vote/coin" can only go through a certain number of transactions from its creation
15:01 < justanotheruser> enough to do coinswaps and joins to anonymize them
15:02 < justanotheruser> along with that you wouldn't be able to have unequal inputs and outputs meaning you couldn't turn 1 vote/coin into 1000 divisible units to fill up the block transaction requirement
15:03 < gmaxwell> I don't know why y'all are wasting cycles on blockchain things for voting. (1) minors can trivially censor votes, (2) none of the anonymity procedures for transactions work without an underlying anonymity network, and if you've got one of those, you don't really need more than that for the anonymity part.
15:06 < justanotheruser> gmaxwell: (1) eventually once [vote recipient A] has all their votes, the miners would have to start accepting votes for B because blocks have to have a certain number of transactions. (2) You need to associate votes with real people in the first place so you know everyone is getting a vote. What you don't know is who they are voting. The anonymity network wouldn't do anything unless you mixed the votes before voting.
15:08 < gmaxwell> justanotheruser: if you must have X votes in total, then you don't need the miners at all. Just have some designated party collect the votes.. pick them at random, hell pick 10 of them to each get a copy.
15:08 < nsh> also voting is basically broken by mathematics
15:09 < nsh> there's no right way to do it, and all the wrong ways suck
15:09 < gmaxwell> electronic voting has a ton of research behind it, solving tricky problems you're not even thinking about (e.g. coercision / vote-buying). You're everything-is-a-nailing it with the blockchain as far as I can tell.
15:09 < gmaxwell> There is basically nothing useful bitcoin adds to to this particular problem.
15:10 < justanotheruser> gmaxwell: how do you verify that all in the voting set had their votes counted and that they are real people with "some designated party"
15:10 < justanotheruser> gmaxwell: I don't think coercion or vote buying can be solved in any voting system
15:11 < gmaxwell> justanotheruser: except they do solve these things. (largely)
15:11 < justanotheruser> the only person who can determine if there is coercion is an all knowing state
15:11 < gmaxwell> justanotheruser: Usually voting systems use verifyable reencryption mixes.
15:11 < gmaxwell> justanotheruser: you cannot be reliably coerced if you cannot prove to a third party how you voted.
15:12 < justanotheruser> gmaxwell: yes, but people can bring cellphones to voting booths pretty easily
15:12 < justanotheruser> "Take a picture of you voting for Putin or I will kill you"
15:12 < gmaxwell> justanotheruser: they're prohibited, including by observers. (and even if you had one, it's not hard to take a picture then vote another way)
15:13 < gmaxwell> Seriously, there are hundreds of people working on this domain, and they have good systems proposed. And their solutions do not need and would not benefit from a blockchain. They can make concrete statements about the security.
15:14 < justanotheruser> gmaxwell: I see. What happened in Florida? The government hacking together their own voting system?
15:30 < adam3us> justanotheruser: just another example of real-life-stupidity.  dunning-kruger in action etc
15:33 < gmaxwell> certantly had little to do with cryptographic voting systems (none was in use)
15:41 < adam3us> justanotheruser: not directly bitcoin related but if you're interested in voting there are some papers on it, once is damgard-jurik's threshold extension of paillier's crypto system which gives split trust vote validation, user verifiable counting of votes, and summing via homomorphic encryption.  phun stuff if u like crypto-math.  there's a whole load of other papers, thats just one i happened to have read.
15:41 < fagmuffinz_> (Back)
15:45 < fagmuffinz_> Oh, cool, nsh is in here also.  Was wondering if anyone here was working on 3301
15:45 < nsh> s/on/for/
15:53 < maaku> :)
15:55 < justanotheruser> adam3us: link?
15:57 < adam3us> justanotheruser: hmm one sec http://en.wikipedia.org/wiki/Damg%C3%A5rd%E2%80%93Jurik_cryptosystem there's an author home page paper link from there, if that doesnt work try citeseer.
15:57 < justanotheruser> thanks
16:00 < adam3us> justanotheruser: i only read it because i knew what pallier was and it is necessary to use DG extended pallier tricks to get a blind signature out of DSA (it sucks that badly compared to Schnorr, its horrendous the complexity of blind DSA, blind ECDSA i am not sure is known to be possible).  pallier itself is a nice little RSA related crypto system thta has the unusual property of being additively homomorphic and capable of trapdoor discret
16:00 < adam3us> justanotheruser: truncated much was that?
16:01 < justanotheruser> adam3us: yes, quire discret
16:01 < justanotheruser> *quite
16:01 < justanotheruser> Does your client not automatically make the truncated bit a new message?
16:01 < adam3us> justanotheruser: ... [pallier] capable of trapdoor discrete log with the private key which could be an interesting trick in many settings
16:02 < adam3us> justanotheruser: and a relatively recent invention (1999) for a basic assumption simple crypto system
16:06 < justanotheruser> interesting
16:08 < adam3us> justanotheruser: indeed not, this is pidgin, though there is probably a plugin that could make it do so.
16:08 < justanotheruser> It's not interesting?
16:12 < adam3us> justanotheruser: i thought pallier was an interesting trick, but i collect interesting crypto constructs in a mental check list to have in mind to build esoteric or interesting protocols with
16:17 < justanotheruser> Oh, I was confused by "interesting not"
16:17 < fagmuffinz_> trapdoor discrete log?
16:21 < nsh> adam3us, is this still in the context of leakfree signature systems?
16:23  * nsh muses
16:23 < adam3us> nsh: not really, though blinding is one of the technique brands others used to remove leaks (aka subliminal channels) from semi-trusted wallets with observers, and this DG thing was one of the parts used to make the DSA blinding monstrosity .  seems simpler to use ecschnorr/ed25519
16:24 < nsh> right
16:24 < maaku> is there any "unofficially official" conference this year, like bitcoin 2013 was last year?
16:24 < adam3us> fagmuffinz_: so the way you decrypt is you can compute the discrete log with the private key but otherwise
16:24 < justanotheruser> maaku: theres the financial cryptography conference
16:24 < fagmuffinz_> Could someone give me a link to this trapdoor I keep hearing about?
16:24 < justanotheruser> http://fc14.ifca.ai
16:24 < justanotheruser> fagmuffinz_: It has to do with asymmetric signatures.
16:25 < justanotheruser> ;;google trapdoor cryptography
16:25 < gribble> Trapdoor function - Wikipedia, the free encyclopedia: <http://en.wikipedia.org/wiki/Trapdoor_function>; rsa - What is the meaning of "trapdoor" in cryptography ...: <http://crypto.stackexchange.com/questions/10087/what-is-the-meaning-of-trapdoor-in-cryptography>; rsa - What is a trapdoor permutation? - Cryptography Stack Exchange: (1 more message)
16:25 < fagmuffinz_> Oh
16:25 < fagmuffinz_> K, that's fine.  Just didn't know what "trapdoor" specifically meant
16:26 < adam3us> fagmuffinz_: pallier trapdoor is unusual in providing a trap door discrete log, usually discrete log crypto systems just work around the non-trap door nature, by knowing existentially the discrete log by having set it up; pallier allows computing it
16:26 < fagmuffinz_> Are there other kinds of asymmetric encryption that don't involve "trapdoors?"
16:26 < fagmuffinz_> Time for me to do some reading =]
16:26 < maaku> eh.. not really. that's just a single day workshop run by non-bitcoin people
16:27 < justanotheruser> fagmuffinz_: In asymmetric cryptography you shouldn't be able to get the private key from the public key. The function to get the public key from the private key is the trapdoor (because you can't go back)
16:27 < maaku> i probably only have funds for one trip this year and want to make it count :\
16:28 < justanotheruser> maaku: I agree (12:33:33 PM) justanotheruser: Seems like a bunch of PhDs are going to explain bitcoin to the bitcoin devs
16:28 < adam3us> maaku: i guess you can get to the san jose one being local to u, plus one other.
16:28 < fagmuffinz_> I understand that justanotheruser
16:28 < fagmuffinz_> Just didn't know terminology - thanks though
16:28 < justanotheruser> yep no problem
16:28 < adam3us> maaku:  i was thinking a wizards only "conference" aka a bunch of wizards and a lot of white boards
16:28 < maaku> adam3us: there's another san jose one?
16:29 < fagmuffinz_> I would pay for a plane ticket to that
16:29 < justanotheruser> adam3us: what's the san jose one? A meetup or a conference?
16:29 < adam3us> maaku: i dont know how it works, is it always in san jose? or does it move around the us?
16:29 < adam3us> justanotheruser: last april was the first one i went to so i am not in the loop, just perhaps incorrectly assumed the main one would be in san jose each year
16:30 < maaku> as far as I can figure out from google that was a one-time thing
16:30 < maaku> i'm not involved with the foundation though, which is why i asked
16:30 < justanotheruser> I'm interested in going to a bitcoin conference this year, what usually happens there? New ideas are talked about?
16:31 < fagmuffinz_> adam3us: http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=B473A49B56321FCEF247063B856A1751?doi=10.1.1.8.5384&rep=rep1&type=pdf this?
16:31 < maaku> if it was happening again in may I would assume there'd be announcements & calls for speakers by now...
16:31 < adam3us> maaku: me either.  but what about a wizards only mini-conf with no registration fees (at cost for space)?  wizards mostly go to like sit on the edges and talk to each other and scoff at the incorrectness of the presenters at anything semi-tech
16:31 < fagmuffinz_> ^
16:32 < maaku> adam3us: sure that'd be fun and I'd go to that
16:32 < maaku> but i'm asking more because I have talks I'd like to give to the wider bitcoin audience
16:32 < adam3us> adam3us: y'all could come to malta, maybe the flights wouldnt be so bad out of season.  the hotels are cheap out of season.
16:32 < adam3us> maaku: if you're talking some places will pay your flights i think
16:33 < maaku> i'm still up for an iceland meetup if people want to do that :)
16:34 < adam3us> maaku: note iceland not good out of season.. my wife's niece went there and lost lots of $ for damaged rental car (not insured for such things) storm with like big rocks flying by!  smashed window, tow, undrivable in the weather conditions
16:38 < adam3us> maaku: plus could snag a visit to the btc mining data center running on geothermal and "open the window" cooling
16:49 < BlueMatt> maaku: adam3us duke conference!
16:50 < BlueMatt> (I'm trying to get together a wizards meetup where wizards are essentially just their own conference but give one or two talks to people
16:51 < adam3us> fagmuffinz_: http://en.wikipedia.org/wiki/Paillier_cryptosystem has link to the paillier's own paper.  damgard-jurik also simplified it
16:54 < adam3us> BlueMatt: yeah i'm pumping malta as a location :)  actually i bumped into the FC organizer guy ray hirschfield at the amsterdam btc conf and he was suggesting malta as next location after bahamas i think 2015.
16:54 < adam3us> BlueMatt: tho i realize thats more flight expensive for more people.  some of the other costs might balance it.
16:55 < BlueMatt> adam3us: well, a conf for bitcoin is being organized at duke anyway, so I figure I'll steal some of their money and put it towards wizard-flights
16:56 < andytoshi> you'd think wizards would be able to fly of their own accord..
16:56 < andytoshi> maybe we could add something to the blockchain to enable that :)
16:57 < adam3us> BlueMatt: oh ic its another university in the same state as unc (i am limited at times in finer points of us geography so missed the connection)
16:57 < nsh> i think you have to enable flying via a separate protocol layer built on top of the blockchain andytoshi
16:57 < nsh> let me set up an exodus address
16:58 < BlueMatt> (not a big conf, but like a local one)
16:59 < adam3us> andytoshi: oh noes, exodus. pump & dump.  stop!!  but yes it is a curious effect that $12 bil long term partly depends on fixing some non-trivial ideas that wizars seem to be the most likely to figure out, and yet many cant afford a flight, or understandably not inclined to take $2k out of their own hard earned $ to donate to it.
17:00 < adam3us> andytoshi: seems like a snowcrash hiro protagonist problem (wealthy by brownie points on the metaverse but penniless in meatspace)
17:01 < warren> meatcoins
17:01  * andytoshi has snowcrash on his HDD, but still hasn't read it..
17:01 < BlueMatt> adam3us: yea
17:01 < warren> andytoshi: read "The Great Simoleon Caper" first, prequel
17:02 < andytoshi> warren: will do
17:02 < warren> then The Diamond Age
17:02 < andytoshi> does cryptonomicon fit into this ordering?
17:04 < warren> no
17:04 < andytoshi> ok, thx
17:05 < adam3us> warren: someones read his stephenson :) man i gotta read the ones i missed some time.  but bitcoin draw is stronger.  eat. sleep. bitcoin.
17:05 < andytoshi> warren: thanks a ton, i have 23 books by stephenson on my system, haven't read one :P
17:06 < gmaxwell> if you hold the meetup around DC maybe I can get stephenson to show up? :P
17:06 < warren> apparently I'm supposed to read something called HPMOR but I refuse.
17:06 < andytoshi> warren: you should, it's good fun
17:18 < andytoshi> so, a few days ago tholenst was asking about script extensions to allow outputs with rules like "cannot be spent unless (a valid signature is provided AND blockheight >= 300000) OR (some proof that txin XYZ was double spent is provided)"
17:19 < andytoshi> what he proposed was pretty powerful and it was easy to think of outputs which interacted very badly with reorgs, hurting fungibility
17:19 < andytoshi> but i think, adding a single op FAIL_IF_BLOCKHEIGHT_LESSTHAN [minimum height] would be safe across reorgs
17:19 < andytoshi> am i right?
17:21 < andytoshi> the idea is, once an output can be spent, nothing should change to make it unspendable, otherwise a reorg could invalidate a huge swath of transactions ... but change in the opposite direction (unspendable output suddenly becomes spendable) is safe
17:21 < gmaxwell> andytoshi: perhaps safe enough. technically the chain can shrink.
17:22 < andytoshi> gmaxwell: right. absent deliberate effort this is insanely unlikely though
17:24 < andytoshi> wait, no, it's exactly as likely as somebody one block behind pulling one block ahead
17:29 < andytoshi> ok, whenever tholenst shows up again i'll mention this .. it would be a cool idea for an alt if you could post collateral against double-spends
17:35 < Taek> could you use the bitcoin script + contracts to create a distributed exchange between multiple cryptocurrencies?
17:35 < maaku> andytoshi: it's possible for an old fork to overtake the main chain
17:36 < andytoshi> for the chain to shrink does a difficulty retarget need to be involved?
17:38 < maaku> to shrink, yes, but it doesn't have to shrink to cause reorg problems
17:38 < maaku> er, n/m
17:38 < maaku> what i was thinking of is really a double-spend
17:39 < andytoshi> maaku: ah, ok
17:39 < maaku> andytoshi: but isn't that what nLockTime is?
17:39 < andytoshi> maaku: nLockTime makes the output 'unreal' until a certain time
17:39 < andytoshi> in the sense that if i make an nLockTime transaction, i can double-spend that
17:40 < andytoshi> what this does is effectively make an nLockTime transaction that gets mined, so it's impossible to double-spend it
17:40 < maaku> ok i see, the restriction is triggered on the spend
17:40 < maaku> you're looking to lock outputs for a certain amount of time
17:41 < andytoshi> exactly, which is why it's a script opcode rather than some property of the transaction
17:50 < Luke-Jr> hmm
17:50 < Luke-Jr> someone should do a scamcoin generator that doesn't need to compile anything
17:50 < Luke-Jr> just find the constants and hack the binaries
17:50 < Luke-Jr> :D
17:58 < Emcy> wow someone put "please consider donating" and address in the torrent comments for bootstrap.dat
17:58 < Emcy> that strikes me as really low for some reason
18:00 < nsh> agreed
18:01 < Emcy> speaking of is it time for a new bootstrap yet?
18:01 < midnightmagic> 13:59 < adam3us> andytoshi: seems like a snowcrash hiro protagonist problem (wealthy by brownie points on the metaverse but penniless in meatspace)
18:01 < midnightmagic> har har.
18:01 < Emcy> this one from august is still seeding pretty good
18:09 < michagogo|cloud> Emcy: personally, I would say an updated bootstrap would not be a bad thing. I think jgarzik maintains it, though, so I'd ask him what he thinks
18:10 < michagogo|cloud> (Though this is a bit ot for here, I think)
18:12 < maaku> iirc he updates it with each new checkpoint
18:12 < maaku> we haven't had a new checkpoint since august
18:14 < michagogo|cloud> maaku: yeah, though it doesn't need to be like that
18:19 < maaku> yeah
18:19 < maaku> regular 3 month or six month updates would be nice
18:46 < petertodd> andytoshi: s/FAIL_IF_BLOCKHEIGHT_LESSTHAN/OP_CHECKLOCKTIME/
18:47 < andytoshi> hmmm
18:48 < andytoshi> are you just renaming this or changing the behavior?
18:48 < petertodd> andytoshi: pointing out how you should implement it :)
18:49 < petertodd> andytoshi: I actually did implement that as an exercise a few months back
18:49 < petertodd> andytoshi: and actually, OP_CHECKLOCKTIMEVERIFY to be exact
18:49 < petertodd> (need that to be a soft-fork nop)
18:49 < andytoshi> petertodd: gotcha
18:50 < gmaxwell> I kinda wish the locktime time of reference was the median of last 11 time rather than the current block.
18:50 < andytoshi> petertodd: you'd then want nLockTime transactions to be standard, and nLockTime ignored unless it appears in script?
18:51 < andytoshi> unless OP_CHECKLOCKTIMEVERIFY appears in script*
18:51 < gmaxwell> andytoshi: the locktime is already ignored when the sequence number is maximal.
18:51 < petertodd> andytoshi: ? no they're two separate things
18:51 < petertodd> andytoshi: OP_CHECKLOCKTIMEVERIFY takes a number on the stack and compares it with the IsFinal() method, failing the tx if false, leaving the number on the stack if true
18:54 < andytoshi> petertodd: i'm not clear -- how do miners know whether they should bother mining a transaction?
18:55 < andytoshi> if you have an nLockTime'd transaction today everyone will ignore it if it doesn't unlock for a long time
18:55 < andytoshi> but what i want is, the script can override the nLockTime in some cases (eg a proof of double-spend is provided)
18:56 < petertodd> andytoshi: ah, I get you, yeah you can do that with CHECKLOCKTIMEVERIFY too, but only in the sense that the transaction can't be mined because the txout it's tryng to spend isn't unlocked yet
19:00 < gmaxwell> andytoshi: trying to have an anti-double-spending bond?
19:00 < andytoshi> gmaxwell: yeah, but it's not working out :P
19:00 < gmaxwell> one problem with those is then how do you prevent the bond from being multiple subscribed?
19:00 < gmaxwell> e.g. I make one 1 btc bond. Then I make 1000 0.5 BTC spends secured against it…
19:00 < phantomcircuit> andytoshi, bond for what?
19:02 < justanotheruser> petertodd: Are there any posts or technical details on how sharding the blockchain would work? Would it involve removed anonymity?
19:02 < petertodd> gmaxwell: well, what if we had some kind of global consensus on who was making use of the bond?
19:02  * petertodd ducks
19:02 < andytoshi> phantomcircuit: the idea is, i send you some money -- they rather than having you wait for a confirm, i construct an output (which i own) such that you can just take it if you can prove that i've double-spent you
19:02 < gmaxwell> petertodd: but then you have to wait for that consensus to settle, defeats the purpose.
19:03  * justanotheruser frowns
19:03 < petertodd> gmaxwell: that was the joke :)
19:04 < petertodd> justanotheruser: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html is the best writeup I have
19:04 < gmaxwell> I'd say you could trust a broadcast network to tell you about compeating bond usage, except the theif could redeem his own bond.
19:04 < petertodd> justanotheruser: and it's not strictly about sharding, but you can easily see how it could be
19:04 < andytoshi> gmaxwell: that's the problem that just occured to me when i said "it's not working out :P"
19:04 < gmaxwell> (and he's not obligated to tell the broadcast network)
19:05 < petertodd> gmaxwell: hence it needs to be partial redeem, partial destroy
19:05 < justanotheruser> petertodd: thanks
19:05 < gmaxwell> andytoshi: this isn't to say that such bonds might not be useful. E.g. large ones which mostly destroy their funds. (they only pay at all as a reward for making the cheating public)
19:05 < petertodd> justanotheruser: I had another post on bitcointalk somewhere from a few months back
19:06 < gmaxwell> but there needs to be a way to transfer ownership of such bonds.
19:07 < petertodd> gmaxwell: which I solved, but soon realized then you also need a way to prove that proof-of-fraud isn't waiting to be released, which means you need consensus about all such fraud, which means proving fraud needs to be proof-of-publication-based. Fortunately this txout scheme I think works here.
19:07 < petertodd> gmaxwell: e.g. the proof is the txout bond hasn't been spent via fraud proof
19:09 < gmaxwell> right, but how do you allow transfer and not create a race between a transfer and a fraud?
19:10 < petertodd> gmaxwell: you create an intermediate "cooling off" period before a transfer can actually go through
19:10 < gmaxwell> I guess by having two outputs, one for transfer, one for fraud, and fraud can still be published for some time after the transfer before it settles?
19:10 < gmaxwell> yea, makes sense the resulting protocol has a number of steps though, which is unfortunate.
19:12 < petertodd> Yeah, or some multisig scheme with some kind of mutually agreed on cooling off tx - lots ofpossibilities.
19:12 < petertodd> Well, I think the cooling off thing is unavoidable to be fair to people potentially relying on the bond.
19:12 < gmaxwell> anyone honoring the bond needs to know the ... right
19:13 < petertodd> Which also means the bond txout really needs to be able to constrain the txout of the tx spending it. :(
19:13 < gmaxwell> esp if you want to allow the bond to be honored by 'offline' devices.
19:13 < petertodd> yup
19:13 < andytoshi> petertodd: right, and that means that you have to precommit to your output and you lose the 'spend without waiting for confirmations' benefit :(
19:14 < gmaxwell> andytoshi: only if you expect people to get paid from the bond.
19:14 < gmaxwell> andytoshi: the alternative is you give up on that and just set it up so that misbehavior costs the misbehaving party their valuable bond... you don't get paid back but they don't get to keep using the bond.
19:15 < petertodd> gmaxwell: no, you just make some of the reward of proving fraud be paid out, and some destroyed, and make the destroyed amount larger than the payout amount
19:16 < gmaxwell> petertodd: you still can't promise the defrauded person get paid no matter how much the bond pays out
19:16 < andytoshi> sure, but how does this make it possible to use the bond without commiting to the output?
19:17 < andytoshi> ah, because 'overcommitting' is not a thing
19:17 < petertodd> gmaxwell: ah, right
19:17 < gmaxwell> andytoshi: because you're not promising that any particular victim can get paid.
19:17 < gmaxwell> right.
19:17 < gmaxwell> The payment the victim gets is just for the trouble of actually announcing to the world that they got ripped off.
19:17 < petertodd> gah, I should have written this up back when I was thinking about this stuff for fidelity bonded banks...
19:18 < petertodd> gmaxwell: yeah, they're not guaranteed to be made whole, and it's tricky to guarantee the fraudster has a net loss
19:21 < petertodd> unrelated: took a look at the twister twitter blockchain thing, and it's difficulty is 0.002... a single GPU scrypt miner could 51% attack the thing
19:21 < gmaxwell> haha one of my coworkers just asked me about his ntp daemon at home using lots of bandwidth
19:21 < petertodd> whut?
19:21 < gmaxwell> "Uh. maybe there is a NTP reflection DDOS attack" "oh look, one was recently found and is being exploited"
19:21 < petertodd> lol
19:23 < andytoshi> petertodd: suppose that you've got like a 1btc bond, and it's only considered valid by fast food restaurants and groceries (who want the bond value to be some large multiple of the product value)
19:23 < andytoshi> then to get a net win a scammer would have to get to a whole ton of physical stores within a blocktime or two
19:23 < andytoshi> (and any more than a blocktime would require some sort of mining-based attack)
19:24 < petertodd> andytoshi: sure, but that just goes to say you have to take countermeasures against that kind of thing or it's easy to rip off
19:24 < phantomcircuit> andytoshi, or coordinate with lots of other scammers
19:24 < gmaxwell> andytoshi: really these things make more sense in the context of an anti-doublespending signer service rather than personally, as the signer service could afford a bond a huge multiple of the typical transaction prices.
19:24 < phantomcircuit> (organized russian crime groups do this fairly regularly with atm heists)
19:24 < gmaxwell> (and could also be secured by hardware remote attest)
19:24 < petertodd> gmaxwell: esp if the signing service provides some kind of proof of how many uncommitted btc they've signed for
19:25 < andytoshi> phantomcircuit: right, derp
19:25 < andytoshi> gmaxwell: neat, then you've got a traditional debit-card system but with a bit less trust
19:26 < gmaxwell> petertodd: if only someone recently described how to run a cryptographically private accumulator...
19:26 < petertodd> gmaxwell: I know 'eh?
19:26  * andytoshi has one last exam tomorrow, better get off -wizards before somebody posts a link
19:26 < phantomcircuit> lol
19:39 < maaku> petertodd gmaxwell: I had a "duh" moment, but if prefixed proofs become *required* for transaction and block propagation, then it doesn't matter how the (U)TXO index is keyed, right? or the size of the UTXO set?
19:40 < petertodd> maaku: it's impossible to require them effectively
19:40 < maaku> well, setting that aside...
19:40 < maaku> spherical cow analysis, if you could get every node to upgrade, etc.
19:41 < petertodd> then you'd get collusion between miners who greatly reduce their bandwidth to each other by leaving out proofs they don't need because they have parts of the utxo set cached
19:42 < maaku> i'm not sure that's a problem, except as it applies to decentralization
19:43 < petertodd> well if it's not a problem, then why did you want to require them?
19:43 < gmaxwell> perhaps I'm missing some context, as I don't see what maaku is talking about (maybe it was something too obvious?)
19:43 < petertodd> I assume for fairness, otherwise you might as well just only provide proofs when needed
19:44 < maaku> well it's very obvious now that i think about it, but the trigger was that I as assuming you need to store the UTXO twice to support scriptPubKey-indexing
19:44 < gmaxwell> the whole idea of the MMR-structured data was that it let you make a storage/bandwidth tradeoff if you could always demand a peer give you proofs with their transactions.
19:45 < gmaxwell> oh no, you wouldn't though you should note that scriptPubKey-indexing isn't naturally computationally balanced— so its a poor index.
19:45 < justanotheruser> petertodd: do you think blockchain sharding will be implemented some time soon?
19:45 < petertodd> justanotheruser: heck no
19:45 < gmaxwell> (also making address reuse cheaper is unfortunate)
19:45 < maaku> but if a proof comes with a transaction, you could just mandate that proofs contain the paths to the inputs in the scriptPubKey index, and a mapping of txid:n -> scriptPubKey
19:46 < justanotheruser> petertodd: what is the number of full nodes drops below 2k?
19:46 < gmaxwell> yea, sure. Doesn't mean that indexing by scriptPubKey is actually desirable, but if you change how transactions look up their inputs, then indeed, you don't need two indexes.
19:46 < maaku> "<gmaxwell> (also making address reuse cheaper is unfortunate)" <-- yes i'm onboard with that. this is more of a -wizards hypothetical
19:47 < gmaxwell> ::nods::
19:47 < maaku> yeah ok i was stupid for not realizing that earlier
19:47 < petertodd> justanotheruser: sharding requires miner co-operation and a soft-fork
19:47 < justanotheruser> petertodd: yes, wouldn't it be necessary because the number of full nodes is dropping?
19:48 < sipa> well, if we can create a currency from scratch, with outputs being (value, merkle-ast-root) and inputs being (merkle-script, script inputs), you can easily (except for potential unbalancing) have your UTXO tree indexed by (merkle-ast-root, txid)
19:48 < maaku> justanotheruser: re "blockchain sharding" sortof, that will come soon
19:49 < maaku> if, that is, you mean pruning where some nodes only store ranges of blocks
19:49 < maaku> not tomorrow though, but soon
19:49 < justanotheruser> maaku: I mean blockchain sharding as in https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html
19:50 < sipa> so you only need a single UTXO data structure for both validation lookups and lightweight node balance checking
19:50 < gmaxwell> The unbalancing could be avoided by just prohibiting reuse.  You end up with a design close to an anonymous coin then. E.g. where outputs do blinded inserts into a existing coin list, and where inputs unblind coins, prove the coins exist, and they are added to a spent coin list.
19:51 < petertodd> justanotheruser: necessary doesn't make stuff actually happen you know, more likely lack of full nodes just pushes people to use web-wallet stuff
19:52 < petertodd> justanotheruser: with so few pools the politics of the situation are unknown and may not be what we want...
19:52 < justanotheruser> gmaxwell: btcguru in #bitcoin is linking to a sketchy website. No results on google
19:53 < justanotheruser> petertodd: why would the number of pools effect that?
19:53 < petertodd> sipa: ugh, I really think we're best off avoiding that kind of single-scriptPubKey balance checking stuff
19:53 < petertodd> justanotheruser: because they're large enough that more centralization and fewer nodes out there may be in their interests
19:54 < maaku> sipa: yeah that was more my line of thinking. indexing by txid or by insertion order isn't really useful, other than that's how bitcoin is structured (scriptPubKey isn't available in the input)
19:54 < maaku> and, i guess, useful in that it doesn't encourage bad, bad things like dumping data on the block chain
19:55 < petertodd> maaku: or address re-use
19:55 < sipa> petertodd: maybe - i don't like the privacy implications of that either
19:56 < maaku> petertodd: yeah, although I don't know how to support looking up bip 32 or keypool addresses without also encouraging address reuse :(
19:57 < petertodd> maaku: use fixed prefixes so all you're reusing is the prefix, which still gets you a decent anonymity set (see my recent post on blockchain data)
19:58 < petertodd> maaku: for change I think we can get away with totally random change addresses as the set of *unspent* change txouts doesn't have to grow
20:03 < gmaxwell> Man, people are going to love anonymous coins where efficient lookups for payments to you is impossible.
20:04 < petertodd> gmaxwell: ?
20:06 < gmaxwell> petertodd: if you have an truly anonymous cryptocurrency, e.g. one that worked by committing to blinded coin values in an insertion ordered tree.. there is no way to tell someone paid you from just inspecting the currency.
20:07 < gmaxwell> They'd have to tell you out of band, or you'd have to have a seperate channel e.g. for storing ECDH keyed encrypted messages "hey, I paid you, the blinded coin has value X"
20:07 < petertodd> gmaxwell: oh sure - all this business about stealth addresses is just a way of relaxing that anonymity a bit so you can recover the payment. even a fully anon cryptocurrency can always bolt on a messaging layer to provide that channel
20:08 < gmaxwell> yea, but interestingly the messaging layer could easily break the privacy.
20:08 < petertodd> gmaxwell: if bitmessage was reliable, you'd just use it, but it's not for non-interactive use
20:08 < gmaxwell> e.g. if the messages have a visible to it likely removes it completely.
20:08 < petertodd> gmaxwell: well, if you re-use something like bitmessage, at least your anonymity set also includes random messages unrelated to payments
20:09 < gmaxwell> an interesting point.
20:09 < justanotheruser> Are you referring to zerocoin?
20:09 < petertodd> Anyway, figuring out how to make the user-experience of "must send this packet of data for foo to get their coin at all" to be acceptable might come in handy for other crypto-currency schemes like txin commitments where the network doesn't have the data at all.
20:10 < gmaxwell> petertodd: well in general seperating the accumulator operation from notice is interesting. Esp since there are different durability requirements.
20:10 < gmaxwell> e.g. losing old notices, ::meh::
20:11 < petertodd> gmaxwell: yup
20:11 < gmaxwell> justanotheruser: no.
20:20 < phantomcircuit> Morici v Hashfast Technologies
20:20 < phantomcircuit> and so it begins
20:20 < phantomcircuit> Case5:14-cv-00087
20:26 < gmaxwell> phantomcircuit: do you have some data feed of bitcoin relevant docket entries?
20:27 < phantomcircuit> gmaxwell, yes
20:28 < phantomcircuit> fun with lexus nexus
20:28 < gmaxwell> Is anyone aware of any fully homorphic encryption schemes can have a plaintext output? e.g. the code inside the FHE decides to write to a plaintext output
20:28 < gmaxwell> phantomcircuit: any details on it?
20:28 < phantomcircuit> gmaxwell, i'll upload the complaint in a minute
20:31 < phantomcircuit> gmaxwell, also it should be on RECAP now
20:34 < phantomcircuit> huh not working
20:36 < gmaxwell> and of course, pacer's password recovery takes like ... days
20:38 < warren> you folks manage to get it? I have westlaw and lexis access right now
20:40 < phantomcircuit> warren, i have it but scribd doesn't like me
20:43 < phantomcircuit> gmaxwell, http://198.27.67.106/hashfast.pdf
20:43 < gmaxwell> phantomcircuit: Can I post that URL on the forum?
20:44 < warren> from PACER?
20:44 < phantomcircuit> gmaxwell, sure
20:44 < gmaxwell> Thanks.
20:45 < phantomcircuit> warren, yes
20:45 < warren> well, good luck to them on getting their BTC back... USD value seems more likely
20:47 < phantomcircuit> warren, sure, but at what day?
20:47 < phantomcircuit> warren, did you notice the spike to 1000 on mtgox?
20:47 < phantomcircuit> i wonder if that's a coincidence
20:47 < phantomcircuit> or you know... not
20:49 < jgarzik> michagogo|cloud, yes, it is time to update bootstrap torrent.  Past time, even.
20:50 < phantomcircuit> http://ia600407.us.archive.org/25/items/gov.uscourts.cand.273355/gov.uscourts.cand.273355.docket.html
20:52 < phantomcircuit> i wonder if pacer has broken recap on purpose
21:10 < phantomcircuit> http://www.archive.org/download/gov.uscourts.cand.273355/gov.uscourts.cand.273355.1.0.pdf
21:10 < phantomcircuit> there we go
21:10 < phantomcircuit> that cost me like $10
21:10 < phantomcircuit> stupid pacer
21:57 < fagmuffinz_> +1 on updating the bootstrap torrent
21:58 < fagmuffinz_> I'm currently catching up my laptop and it's > 10 weeks behind
21:58 < fagmuffinz_> Been several hours now and I'm just 7 weeks behind now
22:01 < gmaxwell> the torrent is just papering over the lack of the headers first patches.
22:16 < maaku> fagmuffinz_: it will take just as long to verify via the bootstrap download
22:16 < maaku> unless you manually set a checkpoint or something
22:18 < phantomcircuit> maaku, actually it's much faster
22:18 < gmaxwell> maaku: fetch is seriously fuxored now..
22:19 < maaku> well i guess it depends on your internet speed :P
22:19 < maaku> i'm behind an ADSL.1 here :(
22:19 < maaku> rural speeds
22:24 < gmaxwell> maaku: right you now you can expect to fetch the same blocks over and over again during sync, doesn't help when you're on adsl. :(
--- Log closed Wed Jan 08 00:00:06 2014