00:28:58maaku:petertodd sipa: two separate indices under consideration here right?
00:30:00maaku:the TXO MMR which is an append/update structure whose hash root is committed to the coinbase
00:30:25maaku:you append each new output, and update a spent-bit for each input
00:30:45maaku:and a separate, per-block tree of outputs indexed by TXO, right?
00:35:43gmaxwell:At some point I'd convinced myself that it made sense to have seperate append only and insert only datastructures, though I don't know why. Obviously managing an append only one is much easier.
00:40:08maaku:oh i guess it can be the same structure as actual insertion/append order within a block doesn't matter
00:42:33maaku:gmaxwell: for double-spend validation I still think an updatable trie structure is best
00:42:52maaku:but lately I've been thinking about a MMO-like structure for the scriptPubKey index
01:05:13gmaxwell:justanotheruser: So perhaps its possible to construct a precisely brittle cryptosystem and paired signature system such that I encrypt data using keys plus some additional data which I give you, such that knoweldge of _any_ signature with the key is enough to decrypt the data.
01:05:45gmaxwell:but not enough to forge signatures.
01:06:22nsh:i really want to see more of a sketch of how this would work, and elaborations on the intractability of adaptive difficulty
01:06:44nsh:or at least some clearer idea of to achieveable precision in likely decryption window
01:06:48nsh:*the
01:07:00gmaxwell:DSA like schemes can be constructed so that they leak a linear relationship between the the private key and the message. So the trickyness would be figuring out how to leak just enough that the encryption is revealed but not forgery.
01:07:01nsh:(re: POW which turns the distributed computation into ticking for timelock encryption)
01:07:16nsh:right
01:07:53gmaxwell:nsh: yea, I dunno, it's a very vague sketch. I was happy that something like it sounded possible because it just seemed to me to be the most realistic way of having non-trustbased timelock encryption I'd ever heard or thought of.
01:08:04justanotheruser:I wish this was possible with bitcoin because this altcoin would only be valuable for secret keeping meaning the only exchanges would be between miners and secret sharers
01:08:12justanotheruser:and speculator
01:08:13justanotheruser:s
01:08:17gmaxwell:But the obvious ways to go about bilding it are super ugly.
01:08:22nsh:mmm
01:09:20gmaxwell:justanotheruser: Well, as I said before a two phase protocol could make it possible to pay for it in bitcoin. The advantage of the alt thing is just that the pow would be "useful".
01:09:44gmaxwell:E.g. lets not go building a bunch of things that require people to needlessly burn energy when we can instead just build one. :P
01:11:08justanotheruser:gmaxwell: So you're saying the secret miners would be securing the network in this altcoin, while they wouldn't be in bitcoin?
01:11:24justanotheruser:I mean you're saying that's your concenr
01:12:03gmaxwell:justanotheruser: right. The idea on the altcoin page is that you have a cryptocurrency who's POW has a side effect of yielding previously unknown private keys for public keys which were set way in advance.
01:12:45gmaxwell:which IMO is way more useful than that primecoin crap. :P
01:14:33gmaxwell:My example of using DLP cracking is lame because DLP cracking is super-not-progress-free. You get a quadratic speedup from being stateful... but there are a LOT of different cryptosystems out there. I would be really surprised if something weren't reasonably sutiable. But even ignoring that details like handling difficulty seem hard to get right.
01:14:34justanotheruser:gmaxwell: Is there a use for primecoins PoW? No one has been able to explain who wants Cunningham chains
01:15:02gmaxwell:No. There is no use as far as I can tell, except abstract numbertheory navel gazing.
01:15:16gmaxwell:of course, insight comes from unexpected places at times.
01:16:10gmaxwell:plus, I _suspect_ that PoW might be the _only_ really viable way to have truly secure timelock encryption.
01:16:23nsh:* nsh nods
01:16:33gmaxwell:just because the timelock usage alone could never really fund enough processing power to make it secure.
01:17:24justanotheruser:The problem I see is your secret being worth 3 times as much as the secret rewards meaning your secret is found 4 times as fast as it should have been.
01:17:49gmaxwell:well thats part of the reason I propose encrypting with all intermediate keys.
01:18:07gmaxwell:so the comparison is not one blocks reward, its all rewards between here and now.
01:21:22justanotheruser:hm
01:21:36justanotheruser:gmaxwell: Do you consider any altcoins useful other than namecoin?
01:21:40gmaxwell:You could also strengthen a decenteralized timelock with distributed timelocks.
01:22:16nsh:hmm
01:22:26gmaxwell:justanotheruser: not really so far, mostly they've done absolutely nothing interesting. The few that aren't just copied of the bitcoin code with a few lines changed are mostly either pure marketing and vaporware or are trivially insecure rubbish.
01:23:17andytoshi:i bet a way to find cunningham chains quickly would also yield some useful number-theory results
01:23:25andytoshi:so primecoin will become useful exactly when it's destroyed :)
01:23:26gmaxwell:E.g. To decrypt this message you need all the blocks between now and 2016 and 6 of 10 timelock servers OR all the blocks between now and 2017.
01:24:09justanotheruser:gmaxwell: how do you handle an increasing network power?
01:24:47maaku:justanotheruser: one of many unsolved problems here
01:24:59gmaxwell:hm? no I proposed a solution, but its kludgy.
01:25:13justanotheruser:Or is this the centralized distributed solution with the servers verifying the block time
01:26:02maaku:gmaxwell: it's not on your alt page...
01:26:16maaku:you've got a mechanism for scaling reward
01:26:25justanotheruser:maaku: "POW which turns the distributed computation into ticking for timelock encryption"
01:26:48maaku:but say I want to encrypt something to 2016. how do I know how far to go?
01:27:05gmaxwell:justanotheruser: I suggested running multiple problems. Say your problems are just H("timelock is great"||x||y) = pubkey. and x and y start at 0. When a solution for a given problem is found, y is incremented.
01:27:07maaku:justanotheruser: i'm talking about difficulty adjustment specifically
01:27:42gmaxwell:If difficulty is too low then to solve a block you start requiring work on x=0 and x=1 ... if it's still too low you require work on x=0 and x=1 and x=2
01:27:50maaku:gmaxwell: ah, i misunderstood. so you break each key into multiple problems?
01:27:55justanotheruser:maaku: your concern is it being found faster with higher network hashpower?
01:28:22gmaxwell:and so basically instead of solving one timelock sequence you solve 1 to n time lock sequences, with n depending on difficulty.
01:29:00gmaxwell:you can encrypt your message with as many of the sequences are you believe will exist in the future, but there is some risk if the difficulty is too low that the network is not solving the sequence you need.
01:29:01justanotheruser:gmaxwell: That involves centralization right?
01:29:05gmaxwell:wtf
01:29:06gmaxwell:no
01:29:36gmaxwell:sorry, I'm just confused as to where you'd get that idea! :P
01:29:42justanotheruser:I was confused by "and 6 of 10 timelock servers"
01:30:04gmaxwell:justanotheruser: oh I thought you were talking about me explaining how difficulty adjustment works.
01:30:20gmaxwell:that was just a comment on 17:21 < gmaxwell> You could also strengthen a decenteralized timelock with distributed timelocks.
01:30:26gmaxwell:and yes, its not decenteralized.
01:30:49justanotheruser:I see
01:31:08gmaxwell:But, e.g. decenteralized + distributed OR lots-more-decenteralized doesn't seem too bad to me.
01:31:36maaku:justanotheruser: my concern is that you cannot predict which keys to use to encrypt something such that it won't be release until day X in the future
01:32:09justanotheruser:I don't see how 6 of 10 timelock servers verifying blockchain length to release a secret is different from them verifying the data
01:32:22gmaxwell:maaku: well you can in my example, you just encrypt using x=0 y={0..expected time in the future}
01:32:30gmaxwell:justanotheruser: huh? there is no verifying the blockchain at all.
01:32:51justanotheruser:brb
01:33:40maaku:gmaxwell: but then in the future when people have asic ecdsa crackers for this, difficulty will require each block to iterate x=0..(some very large amount)
01:33:42maaku:but it could just as easily be built to do x=0 y=(0.. some large amount)
01:34:06andytoshi:maaku: presumably they'd not do this, prefering to get the block reward
01:34:13gmaxwell:maaku: yes, correct. Though if they did that they'd not get the block reward.
01:34:19andytoshi:i don't think this is safe against an asic explosion
01:34:43maaku:so they give up 1 block reward in order to destroy entirely the utility of the timelock encryption
01:35:32gmaxwell:maaku: No, because you have the option of also using the higher Xs... but it puts a tradeoff over the risk that the network may not tick for all the work you need in the future.
01:36:13gmaxwell:basically, to use it with perfect security requires you to predict the future difficulty. But it can be constructed so that if you fail to guess right all is not lost.
01:36:15maaku:Which means you might as well just make the network tick with a single appended value, so you guarantee all keys are moved through
01:36:54maaku:Then you can use it to say "I encrypt this until the network expends X computational cycles"
01:37:07gmaxwell:maaku: no, that gives you no control of the time at all. And you _do_ guarentee that all keys are moved through for all levels under the difficulty.
01:37:24maaku:lack of control over tiem is precisly my point...
01:37:27gmaxwell:you can achieve that in the multilevel scheme by threshold encrypting.
01:38:34gmaxwell:basically the multilevel scheme allows you basically freedom between choosing absolute work, and absolute time (but with race ahead risk)
01:39:51gmaxwell:e.g. you can encrypt the problem to X=0 * 1000 or X=0*500 + X=1*500 or X=0*250 + X=1*250 + X=2*250 + X=3*250 ... to achieve absolute work (to whatever degree you wish to approximate it)
01:40:54andytoshi:[unrelated] new optimization of koblitz curve optimization: http://eprint.iacr.org/2012/519
01:41:40maaku:gmaxwell: but presumably you reveal which ones you encrypt against right? (to avoid combinatorial explosion in decrypting)
01:42:03maaku:so someone need only "work ahead" those keys to decrypt
01:42:06gmaxwell:or you can encrypt to X=0 only, and have absolute time but perhaps a race-ahead risk if the difficulty goes way up. Or you can have some guess at future difficulty (e.g. if the system is already on asics, then projecting mooress law or whatever).. or you can use all of these at once.
01:42:26maaku:(and if they're a miner they can later reuse that work for the subsidy)
01:42:35gmaxwell:No, the work can't be reused.
01:42:53gmaxwell:The attempts you make in the cracking are based on the hashes of the prior blocks, or you don't have a consensus.
01:43:54gmaxwell:maaku: But what I described there achieves absolute work ("X=0 * 1000 or X=0*500 + X=1*500 or X=0*250 +"), regardless of the difficulty. You can "race ahead" sure, but there is no faster way than doing a certan absolute amount of work.
01:44:01maaku:gmaxwell: I'm not sure I follow. the public keys are known in advance right? and the problem is to find the private keys right?
01:45:21gmaxwell:maaku: correct. The hash of your header tells you what part of the solution space to check. Finding a block requires proving you checked the right part of the space and found a distinguished point.
01:45:59gmaxwell:(a distinguished point is either the solution to the current problem, or some 'near miss' based on some arbritary criteria)
01:47:57gmaxwell:Wrt the absolute stuff, I was only pointing out that my hierarchical scheme allows you to get any mixture of "absolute work" or "absolute time with race ahead risk (diff overshoot risk)" or "absolute time with failure to decrypt (diff undershot risk)" that you like. It's not perfect, by any means, but I think it could be reasonably successful.
01:49:29gmaxwell:maaku: e.g. forget that there is a faster way of solving ECDLP than just testing secret keys. To mine this you take your header hash and multiply it by the base point and then measure the current solution's hamming distance to the current digits of pi or whatever is the current x=0 target problem. If its below a threshold you have a x=0 solution.
01:50:07gmaxwell:if you raced ahead previously, that work isn't useful to you because the secret keys you checked weren't derrived from hashing a vaid header.
01:50:13gmaxwell:(at least not useful for mining)
01:53:33gmaxwell:andytoshi: that paper is about classical koblitz— which is for characteristic 2 fields. I can't believe people are still doing stuff with characteristic 2 in 2012.
01:54:07andytoshi:oh, damn
01:54:12andytoshi:also it's 2014 :P
01:57:15nsh:let's split the difference for another couple of days eh? :)
02:12:10nsh:*sigh*
02:12:15nsh:https://www.openssl.org/ <-- compromised
02:13:00gmaxwell:* gmaxwell not going to load a compromised site.
02:13:21nsh:just says "TurkGuvenligiTurkSec Was Here @turkguvenligi + we love openssl _"
02:13:26nsh:no html. but good policy :)
02:17:37justanotheruser:In blockchain time It's already April 2014
02:32:37gmaxwell:So I think I have a goofy convoluted protocol for centeralized timelocking, between alice and a clock though it requires having some substr opcode we don't have.
02:33:12nsh:what's at the centre?
02:33:46gmaxwell:The idea is that alice and the clock can make a (complicted) series of transactions which sets things up so that alice learns a public key for which the clock knows the secret. Alice and the clock both put up funds, if the clock releases the secret on time it gets both its funds back and alices funds.
02:34:20gmaxwell:If the clock releases the secret early, then it doesn't get its funds back. If it doesn't release it alice gets its funds.
02:35:04gmaxwell:the basic idea is that if you give me a signature with a key of yours, and if we had the right opcodes, I could write a scriptpubkey which allowed you to redeem it if and only if you reuse the same k value, thus disclosing the private key.
02:35:07nsh:hmmm
02:36:09gmaxwell:so then you setup a complicated sequence of timelocked n of m fiddly transactions so that there are three ways the thing can be released... early— and the funds can only go to fee or alice.. ontime the funds go to the clock, or late and the funds go to alice.
02:40:00gmaxwell:I dunno if it would be useful though, esp I don't know how to prevent people from freeloading. E.g. alice publishes the initial signature and now any number of people can use that timelock
02:42:57nsh:i'm not sure that's too much of a problem, necessarily
02:45:43gmaxwell:well, if the bitcoin incentives are to have any point at all they should be fairly large... and it's not reasonable to ask clock to lock up funds for a long time without a considerable return. the more people who use it without paying the more incentive for clock to make a deal with someone and never disclose or disclose early.
02:47:06gmaxwell:how about a different one, how about a semi-anonymous quorum timelock.
02:48:43gmaxwell:N players have a distributed public private key. The private key is split into polynomial shares such that— say— 50% of them are required to recover the private key.
02:49:14nsh:right
02:49:34gmaxwell:over time, some M of the N player drop out— they vanish without any of the other playeryers hearing from them for a while, and so they do some quourum consensus and decide those M players are defunct.
02:50:19gmaxwell:They invite M new players, and do some protocol needing 50% of the original N to update help the new M players recover the shares of the M that left.
02:51:03gmaxwell:ignoring how you'd go about doing that— how would this break down?
02:52:16nsh:i think i'm lost
02:53:05warren:http://www.openssl.org/ <--- sigh
02:53:07gmaxwell:nsh: well you get how you can have a key shared among many people such that you need a majorty? You can do this in ec groups such that there doesn't need to be any trusted dealer.
02:53:15nsh:sure
02:53:42maaku:if you love openssl you wouldn't do that...
02:54:37gmaxwell:nsh: just information theoretically, if M of the N leave, but M
02:54:44nsh:(maybe they love openssl, but not as much as fleeting noteriety in dubious social circles)
02:55:09nsh:gmaxwell, can they repopulate without revelaing the secret itself though?
02:55:11nsh:that seems less obvious
02:55:13gmaxwell:(after all, they could just recover the whole key and than split it up again)
02:55:23nsh:depends on the sharing scheme i guess
02:56:08gmaxwell:nsh: Yea, I haven't figured out how to do it, I'm pretty sure it can be done though. Just assume they can for the moment— it's pointless if the scheme isn't useful regardless of doing that.
02:56:19nsh:okay
02:56:21maaku:nsh: probably helps them get their next job. i've heard that some major art thefts are only to enable the theives to get "in" to an organization
02:56:21gmaxwell:nsh: or actually I'm completely sure it can be done, I don't know how easy it is to do it.
02:56:31nsh:* nsh nods
02:57:09gmaxwell:nsh: I'm completely sure because the remaining N-M plus new M could use secure multiparty computation to secretly regenerate the whole key and then split it back up and give it to the new N users.
02:57:22nsh:yes, that makes sense
02:57:36gmaxwell:Though I also think its likely that there is a less horriffic way than invoking SMPC.
02:57:36nsh:modulo some computational/bandwidth costs
02:57:45nsh:* nsh nods
02:58:24gmaxwell:seems to me that you could get a pretty darn robust timelock this way.
02:58:39gmaxwell:you just need some sybil resistant way to select players.
02:59:06nsh:i'm missing bits still. how do you go from N of M secrets (with dropouts and repopulation) to timelock?
02:59:11gmaxwell:And then you can do {magic} to continually redistribute the key so that people coming and going don't break you.
02:59:31gmaxwell:oh just as the "rules of the system" the N parties agree that once the time passes they'll all publish their keys.
02:59:52nsh:backed by fidelity bonds?
03:00:03gmaxwell:So it's secure so long as the majority follows the rule. But systems like that often aren't pratical because they don't handle the members changing over time.
03:00:45nsh:hmmm. i don't know how easy it would be to find N people who would reliably publish on schedule
03:01:11gmaxwell:nsh: maybe? or love for their commnuity. It's not like this is an expensive operation. Generally the reason I think majority of N systems are not pratical isn't that you can't trust the majority for most things you'd want, but because of membership complications.
03:01:21gmaxwell:nsh: well its not people, of course, it's people's software. :P
03:01:28nsh:sure :)
03:02:49nsh:i think you could set up an adaptive cracking challenge via a set of clues running on daemons spread about place such that the Nth clue is published encrypted with a puzzle of difficulty chosen on the basis of how quickly the N-1th puzzle was cracked
03:02:54gmaxwell:e.g. you could do this very simply, with all of us here.. but a year from now many of us may have moved on, gotten hit by bussess, become pissed off at the group. And a bunch of new people would have arrived. Maybe N/2 is unfindable a year or two from now. or you just barely have N/2 still standing, and a few people decide to hold the group randsom.
03:03:38nsh:the general principle of "topping up" the multiparty pool seems a pretty useful one
03:04:20gmaxwell:and this isn't just wank, you could use something like this to enable p2pool to hold a abalance. e.g. have a private key escrowed to the p2pool hashrate, and keep "topping up".
03:04:43nsh:but perhaps open to sneaky people who (being coerced to) fake absence until a threshold is reached
03:05:33nsh:it might be possible to modulate each share when topping up such that people who have dropped out are no longer able to partake in revealing
03:05:35gmaxwell:sure, well one thing about the SMPC approch to it is that you could totally redo everyone's shares. The original interpolation way I was thinking about this was vulnerable to people "leaving" in ordre to come back and get someone elses share.
03:05:47nsh:right
03:06:44gmaxwell:yea, you could achieve that at least under the SMPC case... where you have no risk of an incremental break as the shares are just unrelated. (e.g. you have an encrypted secret which is shared, and inside the smpc you reencrypt, so the shares are unrelated)
03:06:54nsh:right
03:07:52gmaxwell:I guess one problem is being at all confident that "there is anything in the box".
03:08:40gmaxwell:e.g. a bunch of jokers begin such a system with an encryption of nothing, but promising it is the key to great riches. And they all gradually leave, selling their share in the pot to other people.
03:08:49nsh:heh, sounds like religion
03:08:53nsh::)
03:09:26gmaxwell:but I guess that too isn't bad in the SMPC model, since the SMPC could just produce a proof of knowledge (E.g. signature) as a side effect at every remix.
03:09:29gmaxwell:ohhh I found a problem.
03:09:43gmaxwell:A old majority could fork a past state.
03:09:52nsh:(there was a schoolboy prank where you'd get a bunch of people to stand at the corner of a tall problem and all point up and look excited. then wait for more people to arrive until it was sustained enough for the original pranksters to wander off)
03:09:57nsh:fork?
03:10:05nsh:s/problem/building/ # heh..
03:10:33gmaxwell:e.g. people leave the system until none of the original players are left. The one day the original players meet up and go, "oh I wish we still controlled that key" ... "But wait! I saved my old share, if we all did!"
03:11:26nsh:ah, right
03:11:28gmaxwell:so that would bugger the timelock case where you can't usefully rotate the keys as topups happen.
03:11:45nsh:well, there's no way around that i can think of that doesn't require a T3rdP
03:12:03gmaxwell:but it wouldn't hurt the p2pool "keeps a balance" case, since the pool could just keep moving the funds. (e.g. the bitcoin network is the trusted third party)
03:12:12nsh:right
03:12:39nsh:i think ways of using the bitcoin network as a trusted third party will be a pretty big area of research in future
03:12:46gmaxwell:and tada, if we had scalable threshold signatures in bitcoin we wouldn't need anything else for the p2pool case.
03:13:35gmaxwell:you take your N p2pool hashes (selected by their shares in the p2pool sharechain), and you assign funds to them... then late a largely overlapping new N are selected, and the they generate a new threshold key, and the old N move the funds to the new threshold key.
03:13:41nsh:(are there any threads/mailpost/notes on scalable threshold signatures?)
03:14:23gmaxwell:nsh: they're straightforward if you use schnorr instead of DSA, or so says adam3us— I've not personally implemented. At least the N of N case is obvious enough.
03:14:47gmaxwell:basically for the N of N you can just directly compose the public keys.. and to sign directly compose the signatures.
03:15:00nsh:mmm, right
03:15:23gmaxwell:The N of M works based on schnorr basically testing a linear relation, but I've not actually worked through how it works.
03:16:11gmaxwell:lack of scalable threshold signatures I think is a major shortcoming in bitcoin, probably the script limitation with the greatest impact on other protocols.
03:16:22nsh:hmmm
03:16:53gmaxwell:esp because other limitations you can generally work around by invoking multisig.
03:17:23gmaxwell:e.g. how coinswap makes any complicated protocol look like a multisig. :P
03:17:26nsh:assuming schnorr sigs allow for M-of-N, could you add the functionality via a new OP without changing out ECDSA completely?
03:17:32gmaxwell:correct.
03:17:40nsh:right
03:17:47nsh:we definitely need to have a script-extension playground
03:17:52gmaxwell:it's a little tricky to make it backwards compatible. you just can't add a OP_NEWCHECKSIG
03:17:53nsh:that would be very useufl
03:18:28gmaxwell:e.g. it would need to be somehting like a P2SH style change.
03:18:45nsh:what does P2SH style mean?
03:19:17nsh:a generalization of payability?
03:19:37gmaxwell:the reason you can't just take one of the existing NO_OP opcodes and make it into a OP_NEWCHECKSIG is that I could write a transaction that did OP_NEWCHECKSIG OP_NOT OP_VERIFY.
03:19:49gmaxwell:e.g. this transaction is only valid if the newsignature fails.
03:20:21nsh:hmm, and this shoots other places than your (transaction sender's) own foot?
03:20:41gmaxwell:what I mean by p2sh style is that the whole _new syntax_ script is completely hidden from old nodes, they just see a boring hashlocked transaction.
03:21:06nsh:oh, i see
03:21:27gmaxwell:nsh: yea, if OP_NEWCHECKSIG looks like OP_TRUE to old nodes, then I could author a transaction which new nodes would accept but old nodes would reject, and that forks the network.
03:21:40gmaxwell:but no biggie, just hide the whole new script from old nodes completely.
03:21:43nsh:* nsh nods
03:22:20nsh:so it's as solved as backwards compatible P2SH, at least
03:22:43gmaxwell:though I don't know if any future script extensions are realisitc at all. There are now several actually functional full node implementations, whos going to make those people implement any particular change?
03:24:33nsh:hmm
03:25:07nsh:there should be families of end-to-end functionality for which it doesn't matter if there exist nodes that are blind to the internals maybe
03:26:23nsh:it's not a problem for using P2SH if older nodes don't recognize them?
03:26:39nsh:* nsh needs to read more about the proposals
03:32:33andytoshi:P2SH uses the same set of opcodes that have always been around
03:32:45andytoshi:older nodes might think they're nonstandard, but they'll just not relay them
03:34:19nsh:hmm
03:35:03gmaxwell:andytoshi: older nodes don't even _see_ the interior script opcodes.
03:35:09gmaxwell:They just see some binary data on the stack.
03:36:37nsh:what i meant was, if we can implement p2sh without unduly worrying about old nodes, shouldn't the same logic hold for implementing threshhold sigs?
03:37:10gmaxwell:only if it were implemented in the same way.
03:37:18nsh:right, so only people who want the new functionality are required to run nodes implementing it
03:37:19nsh:* nsh nods
03:37:26gmaxwell:no. ugh
03:37:38nsh:oh
03:37:47gmaxwell:none of these changes are secure unless at least a majority of hashpower enforces them.
03:37:54nsh:ah
03:38:10nsh:right, sorry.
03:38:53nsh:so the concern is that at some point changes to the reference client might not necessarily lead to 50(+whatever)% hashpower realization
03:39:15gmaxwell:the trickyness in deployment is that if its not done carefully you can end up where the new feature creates a fatal forking bug even if 90% of the hashpower deploys. P2SH shows one way to do it safely.
03:39:18nsh:although there was some talk about disentangling validation from mining the other day...
03:39:38gmaxwell:nsh: I don't even know what you mean there, it's already quite disentangled.
03:39:48nsh:neither do i, never mind... :)
03:39:50gmaxwell:Most "miners" have never participated in validation. :(
03:40:20nsh:i can't remember exactly what was said such that i took that away from it. was probably not paying much attention
03:40:44gmaxwell:in any case, it's not just hashpower. lets say 80% of hashpower were to have deployed p2sh, but most full nodes don't.
03:41:21gmaxwell:that means that later some super majority of the miners might go "hey, lol, we could make a lot more if we rob all those suckers using p2sh and assign all their coins to us"
03:41:45gmaxwell:e.g. if ~everyone doesn't eventually deploy the new rule it leaves the mining incentives potentially out of wack.
03:42:10gmaxwell:a majority of hashpower is necessary for the new thing to be safe, but it's not really sufficient.
03:42:15nsh:hmmm
03:42:48nsh:i'd love if some student made pretty diagrams illustrating all these things graphically for a thesis or something
05:45:55BlueMatt:is anyone working on the altcoin builder?
05:46:09BlueMatt:otherwise I'm gonna hack one together and at least provide bitcoind/bitcoin-qt (for a neat price)
05:47:00justanotheruser:BlueMatt: I think I read that some russian guy is
05:48:27andytoshi:hahaha go for it BlueMatt, it'd be awesome if someone on this channel was behind it
05:48:59andytoshi:we could just quietly slip experiments into other peoples' alts ;)
05:49:17BlueMatt:yea, plus I plan on charging for use of a fork based on anything past 0.8
05:49:31BlueMatt:that way if any alts popup that get to big, we can just step in and shut down their networks with the bloom /0 bug
05:51:34andytoshi:hmm, this sounds like a slippery slope to actually becoming the illuminati
05:51:42nsh:wait, i thought that was the plan?
05:51:50andytoshi:yeah, i guess i could live with that :)
05:51:54BlueMatt:nsh: shhhhh
05:51:55nsh:* nsh smiles
05:52:31nsh:BlueMatt, what's required for altcoin builder?
05:52:53BlueMatt:me spending a night and learning bootstrap and then y'all advertising it
05:52:53nsh:i've been semirecruited for a somewhat similar venture, so might be able to help
05:54:20BlueMatt:not sure what you're offering here...
05:54:33nsh:neither do i, it's fine
05:54:41BlueMatt:heh, ok
05:55:21nsh:"Summary: Remote p2p crash via bloom filters" is that the bloom /0 bug?
05:55:35BlueMatt:yup
05:55:40nsh:ah, *reads*
05:55:42BlueMatt:yours truly cant code
05:56:18nsh:ah, it's just a case of iterative failure most of the time
05:56:44gmaxwell:wasn't your fault in coding it, there is one of you and more people than you reviewed it.
05:56:54gmaxwell:crashbugs are the fault of the reviewers.
05:56:55nsh:idd
05:56:55gmaxwell::P
05:57:04nsh:has there been any exploitation of it?
05:57:12nsh:i don't recall hearing about it until now which is a good sign
05:57:20BlueMatt:you cant really exploit it, just crash the node
05:57:29nsh:that's what i meant, sorry
05:57:34BlueMatt:ideally someone will step up and kill nodes to force upgrades slowly
05:57:45nsh:i'd volunteer, but...
05:57:49nsh::)
05:57:55BlueMatt:ie kill a few nodes a day until there are no more nodes with the bug running
05:58:47nsh:* nsh nods
05:59:17nsh:they'll turn over eventually. plenty worse vulns out there...
05:59:48nsh:28 million open DNS resolvers on the internet or something
06:09:48BlueMatt:well, sure
06:10:05BlueMatt:not my job to fix the internet though, I just need to fix bitcoin
06:16:52nsh:true
07:16:20maaku:i wish there was someone whose job is was to fix the internet
07:16:41BlueMatt:there may be a few of those...
08:18:01jcorgan:jcorgan has left #bitcoin-wizards
08:43:30gmaxwell:petertodd: I see you changed to SIGHASH_NONE in dust-b-gone, now you need to automatically feed the dust-b-gone data into andy's tool when there is an open cj.
08:43:53gmaxwell:though I expect andy's joining will need to be taught to not strip that signature. :P
08:48:38gmaxwell:andytoshi: ^ PT's dustbegone now generates transactions which spend dust coins (ones with very low value) with the sighash flags set to NONE|ANYONECANPAY if you supported these being submitted to you, you could have people one-pass give away coins to the join.
12:37:20Guest20474:Guest20474 is now known as jarpiaine
12:37:31jarpiaine:jarpiaine is now known as jarpiain
17:30:56andytoshi:gmaxwell: cool, i'll definitely check this out
17:31:05andytoshi:how much of OP_CHECKSIG do i need to implement to find the hash byte?
17:46:14andytoshi:ah, i see, none -- the wiki is just worded weirdly
18:04:40Fistful_of_LTC:Fistful_of_LTC is now known as Fistful_of_Coins
18:31:36midnightmagic:petertodd: Does this mean I'm updating dust-b-gone?
18:32:35andytoshi:midnightmagic: latest commit was dec 19
18:33:03midnightmagic:guess so then.
18:41:01nsh:* nsh imagines dust-b-done being advertised as a 1950s style household cleaning product with subtle sexual undertones
18:41:27nsh:*gone
18:59:01andytoshi:ok, i have updated coinjoin so that it won't strip signatures in the specific case that sighash is NONE|ANYONECANPAY
18:59:25andytoshi:petertodd: if you want to throw dust in the joiner, you will also have to add an output to the donation address to indicate that it should all go to fees
19:00:16andytoshi:CodeShark: maybe this gives you a way to preserve your multisig information? if you can make your scriptSigs look like an ordinary NONE|ANYONECANPAY sig then the joiner won't wreck them
19:17:53andytoshi:(if the scriptSig starts with a PUSHDATA, coinjoin just jumps to the end of the data and reads that byte as a hashType)
19:35:55midnightmagic:andytoshi: Is there a way I can fire off dust txes into the next coinjoin tx on the command-line?
19:35:58midnightmagic::-D
19:36:07midnightmagic:I seem to get a lot of dust. It's pretty annoying
19:36:35maaku:midnightmagic: sign it away NONE|ANYONECANPAY
19:37:10maaku:actually, make a transaction paying to the fee address, and sign with NONE|ANYONECANPAY
19:37:17maaku:then submit it as a usual coinjoin transaction
19:37:57midnightmagic:hrm
19:38:08andytoshi:midnightmagic: the POST form on the coinjoin site is dead simple, you can probably use curl
19:38:32andytoshi:it doesn't report errors in a super simple-to-parse way.. so don't make mistakes ;)
19:38:43midnightmagic:ok
19:38:47andytoshi:you can read the current status in text https://www.wpsoftware.net/coinjoin/status.php
19:39:23andytoshi:one moment, i'll pastebin the source of that file so you can see all possible outputs
19:40:07BlueMatt:anyone looked into the network fork?
19:40:20andytoshi:http://pastebin.com/nYLHDMfM
19:40:31andytoshi:BlueMatt: i'm reading all the txouts right now, haven't seen any weird ones
19:41:09andytoshi:there are a few massive txs
19:41:42andytoshi:eg 057f800f430b22417bdf829d16e78393249634d5409c36b63f058c1a2b54fcf1
19:41:55andytoshi:is about 64k
19:42:01BlueMatt:which block is this?
19:42:33andytoshi:block 277596 is 0000000000000001947cc7acbbc9a240517f9ba19c16b4f937795c6b58019fb5
19:42:45andytoshi:bc.i and blockexplorer are stuck at 277595
19:42:52BlueMatt:bc.i isnt anymore
19:42:54BlueMatt:yea
19:44:56maaku:;;cjs
19:44:57gribble:Coinjoin Status: There is no currently open session. Visit https://www.wpsoftware.net/coinjoin/ or http://xnpjsvp7crbzlj3w.onion/ to start one.
19:46:25andytoshi:i've found 2 now which exceed 64k, which makes bash whine at me..idk if 64k is a magic number for anything else
19:46:34andytoshi:make that 3
19:46:42andytoshi:5
20:10:22justanotheruser:Whats all this I'm hearing about 277596
20:15:20nsh:it's the new magic number. three has retired
20:29:38Emcy:whats interesting about that block
20:33:53andytoshi:Emcy: on #bitcoin-dev they are discussing it, appears to be just a communication problem around an ordinary reorg
20:35:10BlueMatt:Emcy: not even communication, just a reorg
20:41:12midnightmagic:andytoshi: Hey I think your .onion hidden site doesn't work with the /coinjoin/ action. nginx says file not found.
20:42:24andytoshi:oh, thanks
20:42:53andytoshi:fixed
20:43:11Emcy:andytoshi i got it
20:43:24Emcy:big reorg tho
20:44:00Emcy:that guy limiting his blocks to 32kb wtf
20:51:57andytoshi:fyi there is a new paper on bitcoin mining vulnerabilities out: http://eprint.iacr.org/2013/868.pdf
20:52:07andytoshi:which we may get swamped by over the next few days
20:52:27andytoshi:it starts by assuming an attacker can communicate with every miner faster than they can communicate with each other
20:53:39andytoshi:the top of page 3 invokes the sunk cost fallacy as some sort of determiner of miner behavior, so i stopped reading there
20:54:04BlueMatt:so...same assumption as many other attacks on mining stuff...
20:59:55Emcy:isnt the biggest predictor of miner behavior the fire and forget factor
21:03:43BlueMatt:in other words we need to further encourage mining pool peering even though it already exists pretty extensively for the largest ones afaiu
21:05:03Emcy:why? it reorged fine
21:05:16BlueMatt:re: the paper, not the reorg
21:05:35Emcy:oh
21:23:51midnightmagic:lol
21:25:09phantomcircuit:BlueMatt, re: super old stale block
21:25:22phantomcircuit:some mining hardware fails to flush when the network finds a new block
21:25:43phantomcircuit:so they can submit shares for minutes and minutes after the pool has updated
21:25:56nsh:sacrifices to the fallen CPU miners
21:26:06nsh:pour out some hashes for your homies
21:26:07phantomcircuit:smarter pools publish the block on the off chance it's accepted
21:34:15midnightmagic:lol
21:38:23BlueMatt:phantomcircuit: does that effect the paper or just random statement of dumb mining hardware?
21:38:43phantomcircuit:BlueMatt, i was commenting on the recent fork
21:38:51BlueMatt:ahh
21:38:58BlueMatt:Im not even sure this is the case here
21:39:38phantomcircuit:BlueMatt, just the terrible operator with his terrible connection
21:40:00phantomcircuit:also the stuff about chinese internet beign terrible is true but im sure he can afford a real connection
21:40:06phantomcircuit:it doesn't even have to be that big
21:40:49midnightmagic:andytoshi: Okay, I'm attempting to submit a transaction to the coinjoin interface consisting of 0.00000004 btc, with the sum being completely "donated" to the fee address. It's telling me my inputs are not valid, usually meaning they've already been spent.
21:42:08BlueMatt:he limits his blocks so he can relay with 1 udp packet....
21:42:19BlueMatt:I mean thats just overkill no matter how shitty your connection is...
21:42:25phantomcircuit:that's just sillyness
21:42:59phantomcircuit:im sure he has the bandwidth but his latency is probably terrible
21:43:12phantomcircuit:also i wonder if he remembers to retransmit
21:43:26phantomcircuit:im guessing no
21:44:11BlueMatt:probably not
21:50:45andytoshi:midnightmagic: can you msg me the tx?
21:51:35andytoshi:or just the input ids?
22:12:14midnightmagic:andytoshi: sure
22:25:53nsh:nsh is now known as nshbit
22:31:05nshbit:nshbit is now known as nshchawmp